Вера Крыгина,
АБД Oracle,
ГИАЦ МВД России

Опыт использования опций Oracle Enterprise Manager Grid Control

Источник: статья подготовлена по материалам и в продолжении одноимеенной презентации Романова А.Н. (начальник ЦИТиС ГИАЦ МВД России) и Моренко И.Л. (начальник отдела ЗАО «ИНФОСЕТЬ-С») на Oracle TechForum2008, секция "Database and Options – что там внутри?", ноябрь 2008.

Специфика нашей организации состоит в том, что продуктивные базы данных, которые представляют собой централизованное хранилище (общим объемом 1 Тбайт текстовой и графической информации), работают в круглосуточном режиме 7 дней в неделю, причем пользователи находятся во всех регионах России и в разных часовых поясах от Калининграда до Владивостока. В сутки обрабатывается несколько тысяч запросов для получения оперативно-справочной информации. Еще один существенный момент, осложняющий жизнь сисадмина, это наличие большого парка « разноплатформенных» серверов. В нашем случае это и FujitsuSiemens PrimePower под ОС Solaris 9, и IBM System p570 под ОС AIX 5.3.

Oracle EM Grid Control работает не только с 11g версией СУБД, но и с предыдущими: 9i, 10g, а так же с СУБД, установленными на разных платформах: Solaris, AIX, Windows. Для этого достаточно только установить и настроить нужную версию Oracle Management Agent. Теперь процесс управления всеми ресурсами можно осуществлять с одного рабочего места, так как администратор видит работу всех установленных БД и приложений в масштабах всей организации на одной странице.

Рабочий день системного администратора в компании, имеющей в своем активе несколько продуктивных баз, установленных на различных платформах, под различными версиями ОС и СУБД, частенько начинается с риторического вопроса: «Ну-с, что у нас плохого?». Раньше для получения ответа нужно было быстренько открыть несколько (по числу баз) экранов EM Console, пробежаться по нескольким вкладкам, оценить состояние и работоспособность, найти критические точки. Вспомните, как было тяжело обнаружить, почему снизилась производительность системы, почему она стала работать медленно. Как приходилось собирать статистику с помощью пакета STATSPACK и потом с лупой изучать все цифры, которые он нам выдал. Справиться с этим мог только очень опытный специалист. И еще: все визуальные средства показывали картинку online. А чтобы отловить проблему, нужно было часами наблюдать за картинкой на экране. С использованием же Oracle Diagnostic Pack стало жить куда легче. Теперь появилась возможность разобраться с проблемой, которая возникла по времени раньше, чем ее заметил администратор. И если гневные пользователи говорят, что «система встала, пока тебя не было», можно щелкнуть на закладке Perfomance в Grid Control и с помощью ASH – Active Session History посмотреть историю ожиданий, которые были в момент вашего отсутствия. Достаточно просто узнать, в чем причина, если вы видите большую процессорную нагрузку, найти сессию и конкретный SQL-запрос, вызвавший такую нагрузку. ADDM – Automatic Database Diagnostic Monitoring обнаружит все такие запросы и порекомендует изучить их с точки зрения производительности.

Далее вы запускаете Tuning Pack и показываете пользователю, что и как нужно сделать с его запросом, чтобы впредь не было таких остановок системы.

В нашей работающей системе было создано огромное количество индексов. Это происходило исторически, так как система начинала работать сначала в 9-ой версии Oracle, потом в 10-й, потом тестировалась уже в 11-ой. И при работе в каждой версии администраторы и разработчики создавали индексы так, как они это видели, а не изучали проблему детально, пытаясь ответить на вопрос - насколько нужны эти индексы. С помощью Oracle SQL Tuning Advisor & SQL Access Advisor задача по созданию нужного индекса или изменения профиля выполнения SQL становится простой и понятной задачей для администратора. Ему нужно только найти с помощью Oracle Diagnostic Pack проблемные SQL запросы и попросить «советчиков» подсказать, что нужно сделать, чтобы этот запрос работал быстрее. Затем просмотреть результат и исполнить предлагаемые рекомендации.

В Oracle Database 11g теперь уже существует автоматическая настройка SQL, без вмешательства администратора. Еще одна ежедневная задача администратора - управление процессом резервного копирования. С помощью Oracle EM Grid Control очень легко контролировать и управлять процессом резервного копирования всех баз данных организации. В ГИАЦ кроме продуктивных баз есть еще несколько копий для тестирования вновь разрабатываемых модулей и новой функциональности системы, так называемые БД для разработчиков. Всего их наберется уже с десяток. Достаточно один раз выбрать политику резервного копирования и восстановления для каждой из баз, создать соответствующий job и включить его в расписание. Каждое утро, открыв соответствующую страницу Grid Control с отчетами о выполнении job-ов, вы сможете найти полную информацию о выполнении всех backup-ов.

Хочется рассказать еще об одной важной задаче, которую нам приходилось решать с помощью опций Grid Control. За последние 3 года мы уже дважды переходили на новую техническую платформу. Первый опыт миграции осуществлялся с помощью утилиты exp & imp, затем Data Pump. При этом несколько недель ушло на подготовку к такому переходу. По часам замеряли, сколько времени делается дамп и сколько времени уходит на его вливание в БД, какие проблемы при этом могут возникнуть. И при самом переходе на новую машину некоторые подсистемы были недоступны в течение 4 суток (время на заливку информации из дампа, корректировка того, что забыли перенести: права на объекты базы данных, link-и и кое-что другое (человеческий фактор никуда не денешь).

При использовании же опции Cloning Grid Control этот процесс проходил более спокойно и практически незаметно для пользователей. На осуществление следующей миграции брали с запасом 2 дня, но сам перенос данных и последующая настройка заняли гораздо меньше времени, во многом благодаря огромной помощи специалиста ЗАО «Инфосеть» Николая Дронина. Кроме того, процесс подготовки к переходу на новый комплекс был более коротким. И в этом случае ничего не потерялось, так как при клонировании баз данных создавался их полный аналог.

Замечательными свойствами опции Cloning Database Grid Control мы уже неоднократно воспользовались при создании тестовых стендов для разработчиков и сдачи различных ОКРов. Во всех этих случаях требуется продемонстрировать работоспособность вновь созданной системы на реальных объемах существующей базы данных. Но специфика наших баз данных такова, что в ней хранятся персональные данные людей, которые по закону являются конфиденциальной информацией. Для таких целей мы пользуемся опцией Data Masking для того, чтобы перемешать, изменить реальные данные в тестовые. В результате работы этой опции мы получаем тестовую систему реального объема, но с записями, не являющиеся достоверными, однако сохраняющими структуру своих логических связей. При этом функциональность системы не теряется.

После проверки работоспособности вновь разработанных модулей на тестовом стенде наступает важный момент – перенос их на продуктивные базы данных. С помощью Oracle EM Grid Control администратор перед началом работ создает именованную «точку восстановления» (Restore Point), и в случае неудачного применения нового прикладного программного обеспечения, администратор кнопкой «Restore» восстанавливает систему до внесения изменений, что позволяет избежать множества проблем.

Частой задачей администратора БД в ГИАЦ является установка продуктов Oracle на разные сервера (установка новых версий), а также при выходе нового патча – его применение к существующим базам данных.

При инсталляции и применении патча вручную необходимо предварительное детальное изучение документации по инсталляции. Если пользоваться опцией Provisioning Pack Oracle Grid Control эта задача превращается в выбор машины, выбор продукта или патча и нажатие кнопки «Выполнить». Далее весь процесс проходит автоматически, и в этом случае намного меньше риск возникновения ошибки, как если бы мы действовали по старинке. Кроме того, если не забыть перед накатыванием патча создать Restore Point, то в случае неудачи можно опять вернуться на исходную позицию.

Очень тяжело проходила миграция баз данных в среду RAC. Миграция проходила в 2 этапа: вначале базы данных перенесли на работу с ASM, а потом сделали ее кластерной БД. Сначала перенос в ASM предлагалось сделать с помощью скриптов RMAN, но из системных соображений и требований было решено и в этом случае воспользоваться Grid Control. И процесс миграции существующей БД в среду RAC прошел гладко, безболезненно и довольно быстро по времени.

Сейчас уже трудно себе представить работу администратора без Grid Control, настолько прочно и уверенно он вошел в нашу жизнь. Отличный инструмент для поддержания работоспособности системы и ее обслуживания – наглядный, оперативный, довольно простой в эксплуатации.