Oracle Database — мощная платформа, но лицензирование, резервное копирование, аварийное восстановление и управление производительностью требуют экспертизы. Простым языком объясняем риски лицензирования в виртуальных средах, RMAN, Data Guard, установку патчей, AWR и модель внешнего DBA.
Oracle Database работает за многими критически важными приложениями — от банковской сферы и производства до госсектора и розничной торговли. Это мощная, зрелая и гибкая платформа. Но за эту мощь приходится платить: неправильное лицензирование создаёт серьёзные финансовые риски, неправильное резервное копирование приносит неприятные сюрпризы во время аварии, а слабый мониторинг приводит к проблемам с производительностью, которые замедляют бизнес-процессы.
В этой статье мы рассмотрим четыре ключевых направления управления базами данных Oracle — лицензирование, резервное копирование, производительность и поддержку — и обсудим, чем штатный DBA отличается от внешней услуги DBA.
Лицензирование Oracle: самый недооценённый риск
Лицензирование не кажется технической темой, но напрямую влияет на инфраструктурные решения. Установить Oracle технически несложно; правильно рассчитать потребность в лицензиях — задача для специалиста.
Редакции и метрики
В целом Oracle Database предлагается в редакциях Standard Edition 2 и Enterprise Edition. Лицензирование может основываться на метриках Processor или Named User Plus. Для Standard Edition 2 действуют ограничения на мощность сервера, на котором она может работать. Enterprise Edition предлагает более широкий набор функций, причём многие расширенные возможности поставляются как отдельно лицензируемые опции и пакеты.
Осторожно с виртуализацией
Наибольшие риски обычно возникают в виртуальных средах. Oracle может не признавать некоторые технологии виртуализации методом разделения, ограничивающим лицензирование. В таком случае в расчёт лицензий могут попасть не только процессоры виртуальной машины с Oracle, но и все физические хосты, на которых эта виртуальная машина способна работать. В большом кластере виртуализации это может означать потребность в лицензиях намного выше ожидаемой.
Правила могут зависеть от вашего договора, используемой технологии виртуализации и действующей политики лицензирования. Прежде чем переносить Oracle в виртуальную среду или строить новый кластер, настоятельно рекомендуем проконсультироваться со специалистом по лицензированию. Наша задача как технической команды — помочь разместить нагрузки Oracle так, чтобы их можно было изолировать с точки зрения лицензирования, и сравнить архитектурные варианты.
Функции и лицензии
Некоторые инструменты устанавливаются по умолчанию, но для их использования требуется отдельная лицензия. Например, ряд диагностических инструментов, часто применяемых при анализе производительности, в Enterprise Edition требует лицензии на дополнительный пакет. Неосознанное использование таких функций может обернуться проблемами при лицензионном аудите. Хороший DBA знает, какую функцию можно использовать по какой лицензии, и настраивает среду соответствующим образом.
Резервное копирование: правильная стратегия с RMAN
RMAN (Recovery Manager), встроенный инструмент резервного копирования Oracle, — стандартный способ получать согласованные копии, пригодные для восстановления. Копирование файлов базы данных на уровне операционной системы при открытой базе ненадёжно.
Грамотная стратегия RMAN обычно включает:
- Режим ARCHIVELOG: хранение архивных журналов повторов (redo logs) делает возможным восстановление на момент времени. Для производственных баз он требуется практически всегда.
- Полные и инкрементальные копии: распространённая базовая схема — еженедельная копия уровня 0 и ежедневные инкрементальные копии уровня 1.
- Копии архивных журналов: создаются часто в течение дня, чтобы сузить окно потери данных.
- Копии управляющего файла и файла параметров: автоматическое резервирование управляющего файла должно быть включено.
- Политика хранения: определяет, насколько далеко назад можно вернуться, и обеспечивает очистку старых копий.
Копию резервных копий RMAN необходимо выносить за пределы сервера, желательно в неизменяемое хранилище. Вымогатель или ошибочная команда могут уничтожить и копии на самом сервере.
Наконец, резервные копии нужно проверять и регулярно восстанавливать в отдельной среде. Команды проверки RMAN полезны, но не заменяют реального тестового восстановления.
Аварийное восстановление: Data Guard
Восстановление большой базы данных из резервной копии может занять часы. Когда критичным системам нужен более короткий простой, на помощь приходит Oracle Data Guard. Data Guard непрерывно передаёт изменения с основной базы на резервную (standby). При проблемах с основной базой резервную можно быстро ввести в работу.
- Physical standby: поблочная копия основной базы данных и наиболее распространённая модель.
- Режимы защиты: разные варианты баланса между производительностью и нулевой потерей данных. Выбор должен учитывать расстояние и сетевую задержку между площадками.
- Switchover и failover: оба сценария необходимо регулярно тестировать.
Data Guard доступен в Enterprise Edition, а для некоторых расширенных сценариев, например использования резервной базы для отчётов, может потребоваться дополнительная лицензия. Для сред Standard Edition 2 можно рассмотреть альтернативные подходы на основе передачи архивных журналов вручную или с помощью сторонних инструментов. Размещение резервной базы в другом дата-центре — основа плана аварийного восстановления.
Управление патчами
Oracle регулярно выпускает патчи для устранения уязвимостей и ошибок. Слишком долгое откладывание патчей повышает риски безопасности, а их установка без плана может нарушить работу приложений. Сбалансированный процесс установки патчей включает:
- Оценку того, насколько выпущенные патчи касаются вашей среды.
- Установку сначала в тестовой среде и проверку вместе с командой приложения.
- Планирование окна обслуживания в производственной среде и подготовку шагов отката.
- В средах с Data Guard — установку патчей сначала на резервную базу для сокращения простоя.
- Отслеживание версий, у которых заканчивается поддержка, и планирование обновлений.
Управление производительностью
Жалобы на производительность обычно звучат как «система тормозит». Причина может быть в базе данных, приложении, хранилище или сети. Для правильной диагностики нужны измерения.
- Отчёты AWR и ASH: в Enterprise Edition при наличии лицензии на соответствующий диагностический пакет они подробно показывают, чем была занята база данных за определённый период. Если ваша лицензия их не покрывает, можно использовать альтернативы, например Statspack.
- События ожидания: показывают, на что база данных тратит время. Чтение с диска, блокировки и сетевые ожидания требуют разных решений.
- Настройка SQL: большинство замедлений обычно вызывает несколько запросов. Исправить отсутствующий индекс или неудачный план выполнения гораздо дешевле, чем добавлять оборудование.
- Память и хранилище: настройки SGA и PGA, а также задержки хранилища нужно регулярно отслеживать.
Цель работы над производительностью — убедиться, что имеющиеся ресурсы используются эффективно, прежде чем увеличивать бюджет на оборудование. В средах Oracle с лицензированием по ядрам это напрямую превращается в экономию.
Мониторинг и проактивные проверки
В хорошо управляемой среде Oracle большинство проблем выявляется раньше, чем их заметят пользователи. Ключевые параметры для мониторинга:
- Заполненность табличных пространств и места для архивных журналов
- Статус выполнения заданий резервного копирования
- Отставание синхронизации Data Guard
- Ошибки в alert log
- Долго выполняющиеся сеансы и блокировки
- Учётные записи пользователей, привилегии и парольные политики
Безопасность и управление доступом
Базы данных — главная цель злоумышленника. Типичные бреши в безопасности сред Oracle редко бывают изощрёнными: учётные записи с неизменёнными паролями по умолчанию, пользователи приложений с избыточными привилегиями или порты listener, открытые для всей сети. Базовые меры:
- Блокировка неиспользуемых учётных записей по умолчанию и строгая парольная политика
- Предоставление пользователям приложений только необходимых привилегий
- Ограничение доступа к портам базы данных только с серверов приложений с помощью межсетевого экрана
- Включение аудита критичных операций и его регулярный просмотр
- Шифрование резервных копий и конфиденциальных данных с предварительной проверкой лицензионных требований к функциям шифрования
Штатный DBA или внешний DBA?
Найти и удержать опытного штатного DBA по Oracle непросто. Зависимость от одного человека сама по себе риск: отпуск, болезнь или увольнение могут привести к потере критически важных знаний. Модель внешнего DBA решает эти проблемы иначе:
| Критерий | Штатный DBA | Внешняя услуга DBA |
|---|---|---|
| Широта экспертизы | Ограничена опытом одного человека | Команда с опытом во множестве сценариев |
| Непрерывность | Риски во время отпусков и при увольнении | Взаимозаменяемая команда, задокументированные процессы |
| Стоимость | Полная зарплата и обучение | Услуга в объёме ваших потребностей |
| Поддержка в нерабочее время | Сложно организовать дежурства | Определяется уровнем обслуживания |
| Знание бизнеса | Очень высокое | Накапливается со временем, подкрепляется документацией |
Для многих организаций наиболее эффективна гибридная модель: внутренняя команда, хорошо знающая приложение, плюс внешняя поддержка DBA для регулярного обслуживания, резервного копирования, мониторинга и экстренных ситуаций.
Часто задаваемые вопросы
Увеличатся ли мои расходы на лицензии, если запустить Oracle в облаке?
Это зависит от используемой инфраструктуры и условий вашего лицензионного соглашения. В одних средах расходы можно контролировать за счёт правильной архитектуры, в других возможен неожиданный рост. Перед решением о миграции проконсультируйтесь со специалистом по лицензированию.
Достаточно ли резервной копии виртуальной машины вместо RMAN?
Копия ВМ полезна для восстановления всего сервера, но не рекомендуется как единственная защита Oracle. RMAN даёт специфичные для базы данных возможности, такие как восстановление на момент времени и поблочная проверка. Оптимальный подход — использовать оба метода вместе.
Нужен ли Data Guard в каждой среде?
Нет. Это зависит от того, какой простой допустим для системы. Если простой в несколько часов приемлем, хорошо протестированных копий RMAN может быть достаточно.
Как формируется цена внешней услуги DBA?
Объём определяется количеством, размером и критичностью баз данных, а также ожидаемыми часами поддержки. В CloudRUX услуги по базам данных рассчитываются по запросу.
Услуги CloudRUX для Oracle Database
Арендовать сервер для Oracle вам может кто угодно; настоящая ценность — в уверенности, что резервные копии проверены, патчи устанавливаются по графику, а при проблемах есть инженер, который знает вашу систему. CloudRUX предоставляет услуги мониторинга, резервного копирования, оптимизации производительности и аварийного восстановления для Oracle и других платформ баз данных силами инженеров, говорящих на русском и турецком языках, а ваши данные остаются в Турции. Подробности — на нашей странице решений для баз данных, или свяжитесь с нами для оценки вашей среды.