6. Необходимые действия после выполнения миграции
После выполнения миграции на тестовой системе необходимо убедится, что производительность и стабильность новой версии остались не ухудшились. Для этого рекомендуется провести ряд мероприятий направленных на определение и устранение проблем, угрожающих стабильности и производительности систем.
-
Тестирование критичных операций
Проведите тестирование основных операций и сравните результаты по их выполнению на предыдущей версии. Производительность операций или представлений должна быть не хуже чем на предыдущей версии. В случае низкой скорости работы операции следует выяснить и устранить причины замедления.
Обязательное внимание следует уделять планам запросов на новой системе по сравнению с планами запросов на предыдущей системе. При сравнении планов в первую очередь следует уделять внимание скорости выполнения запросов и количеству потребляемых ресурсов как-то : логических блоков и операций чтения данных.
В случае наличия опции Tuning Pack, процесс сравнения запросов можно автоматизировать, использую возможности SQL Performance Analyzer.
Если нет возможности использовать Tuning Pack рекомендуется использовать данные собранные STATSPACK или результаты анализа файлов трассировки сессий(событие 10046).
-
Нагрузочное тестирование системы
Наиболее эффективным средством тестирования системы является проведение нагрузочного тестирования новой системы. Под нагрузочным тестированием понимается создание нагрузки эквивалентной или большей той, с которой работает информационная система на старой версии. Для создания нагрузки могут использоваться специализированные нагрузочные инструменты или привлечение большого количества пользователей воспроизводящую реальную работу за какой-то фиксированный интервал времени.
При нагрузочном тестировании могут быть выявлены проблемы связанные с масштабируемостью новой платформой и стабильностью системы.
При проведении нагрузочного тестирования следует проводить мониторинг потребления ресурсов сервера и в случае значительного различия метрик следует проводить анализ работы экземпляра базы данных.
-
Мониторинг стабильности новой версии
Во время проведения тестирования проводите мониторинг логов базы данных, на предмет появления каких-либо ошибок или файлов трассировок. Особое внимание следует уделять ошибкам с кодами ORA-7445, ORA-600, так как их появление сигнализирует о критичных проблемах в работе базы данных. В случае возникновения таких ошибок рекомендуется обращаться в службу поддержки компании Oracle.
Как правило, появление таких ошибок связано с использованием окружения не сертифицированного для Oracle 11g Release 2 или ошибками в программном обеспечении Oracle. Во втором случае следует инициировать запросы в службу поддержки Oracle и процесс миграции не рекомендуется проводить до устранения ошибок данного типа
-
Краткий перечень изменений в Oracle 11g Release 2
Далее приведён краткий перечень изменений в Oracle 11g Release 2 по сравнению с Oracle 10g Release 2, на которые следует обратить внимание при планировании, тестировании и выполнении миграции продуктов на основе «ЦФТ-Платформа Развития».
-
Служебные процессы базы данных
В Oracle 11g Release 2 увеличено количество служебных процессов на сервере. Количество служебных процессов может зависет от используемых подсистем базы данных. Далее приведено описание части таких процессов.
Наименование процесса
|
Описание
|
DBRM (database resource manager)
|
Управление ресурсными планами и прочими задачами, связанными с выделением ресурсов
|
DIA0(diagnosablity process 0)
|
Определение подвисших процессов и удаление взаимоблокировок
|
EMNC(event monitor coordinator)
|
Рассылка и координирование сообщений
|
FBDA(flashback data archiver process)
|
Сохраняет исторические строки с наблюдаемых таблиц,
|
GTX0-j(global transaction)
|
Поддержка транзакция XA в среде Oracle Real Application Cluster;
|
GMON
|
Мониторинг дисков в ASM;
|
MARK
|
Используется ASM
|
SMCO(space manager coordinator)
|
Управления задачами выделения или реорганизации пространства
|
VKTM(virtual keeper of time)
|
Используется для определения времени процессами
|
VKRM(virtual scheduler for resource manager process)
|
Управление процессами в зависимости активного плана ресурсов
|
Общее количество типов служебных процессов в Oracle Database 11g Release 2, включая расширения ASM, Data Guard, Oracle Streams составляет чуть менее ста.
-
Параметры, влияющие на работу оптимизатора запросов
В Oracle 11g Release 2 добавились новые параметры, влияющие на работу оптимизатора запросов.
Параметр
|
Описание
|
OPTIMIZER_USE_INVISIBLE_INDEXES
|
Разрешает или запрещает использование индексов в состоянии INVISIBLE. По умолчанию имеет значение FALSE
|
OPTIMIZER_USE_PENDING_STATISTICS
|
Разрешает или запрещает использование статистики в состоянии PENDING. По умолчанию имеет значение FALSE
|
OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES
|
Разрешает или запрещает захват планов запросов для размещения в SQL Management Base. По умолчанию имеет значение FALSE
|
OPTIMIZER_USE_SQL_PLAN_BASELINES
|
Разрешает или запрещает использование SQL Management Base. По умолчанию имеет значение TRUE.
|
Не рекомендуется изменять значение данных параметров на рабочей базе данных, без предварительного тестирования.
-
Задание по сбору статистики
Начиная с версии Oracle 10g Release 2, в базе данных запускаются задания по автоматическому сбору статистики. В Oracle 11g Release 2 данное задание запускается, как часть автоматизированных заданий по управлению базой данных (AutoTask). Для отключения автоматического сбора статистики можно использовать пакет DBMS_AUTO_TASK_ADMIN.
Пример :
$ sqlplus / as sysdba
SQL> exec DBMS_AUTO_TASK_ADMIN.DISABLE(client_name=>’auto optimizer stats collection’,operation=>NULL,window_name=>NULL);
Для проверки состояния задания можно использовать представление DBA_AUTOTASK_CLIENT.
Пример :
$ sqlplus / as sysdba
SQL> select client_name,status,TOTAL_CPU_LAST_7_DAYS from dba_autotask_client where client_name like 'auto optimizer stats collection';
CLIENT_NAME STATUS TOTAL_CPU_LAST_7_DAYS
------------------------------------------ -------- -------------------------
auto optimizer stats collection DISABLED
-
Изменения параметров сбора статистики
Начиная с Oracle 9i, для сбора статистики рекомендуется использовать пакет DBMS_STATS. Для сокращения длительности процедуры сбора статистики, рекомендуется задавать параметр ESTIMATE_PERCENT, определяющий процент данных используемых для получения статистики.
В Oracle 11g Release 2 алгоритм расчета статистики был модифицирован. При указании значения ESTIMATE_PERCENT равным AUTO_SAMPLE_SIZE, будет использоваться новый алгоритм расчёта статистики, который работает значительно быстрее.
-
Оценочное изменение при построении запросов
Оптимизатор запросов в версии Oracle 11g Release 2 при построении планов выполнения запросов может использовать следующие оптимизационные решения :
Null aware anti join
Join predicate pushdown
Group by placement
Данные возможности можно отключить использую параметр OPTIMIZER_FUTURES_ENABLED. В случае массовой деградации планов запросов рекомендуется установить параметр OPTIMIZER_FEATURES_ENABLED=10.2.0.4.
После этого рекомендуется выяснить причину деградации планов, провести работы по ее нормализации и вернуться к OPTIMIZER_FEATURES_ENABLED=11.2.0.2
При необходимости получения уникальных данных, если оптимизатор Oracle 11g Release 2 определяет, что данные уже являются уникальными, то оптимизатор исключает действия по сортировке уникальных значений.
Зачастую в колонках таблиц содержаться данные, которые зависят друг от друга. По таким колонкам можно собрать расширенную статистику и при построении запросов, оптимизатор будет учитывать корреляцию таких данных.
Возможно так же собрать статистику по группе или набору колонок, которая позволит оптимизатору более точно учитывать распределение или выборку данных. Такая статистика включает в себя подсчёт количества уникальных значений, количество null значений, частотные гистограммы и плотность.
-
Адаптивное построение планов запросов
В Oracle 11g Release 2 оптимизатор сохраняет значения переменных, совместно со статистикой ресурсоемкости запросов. Если оптимизатор определяет, что ресурсоёмкость запроса зависит от значения переменных, то может быть произведено построение нового плана.
То есть в зависимости от значения переменных, могут использоваться разные планы выполнения запросов. Данный механизм является значительно более интеллектуальным и менее ресурсоёмким, в отличии от механизма bind peeking, появившегося в Oracle 9i.
В Oracle 11g Release 2 появилась подсистема мониторинга зависаний (hang manager). Данная подсистема автоматически определяет зависшие процессы, анализирует причины и фиксирует в логах зависание (hang) процессов базы данных. За работу данного процесса отвечает выделенный служебный процесс DIA0.
Для просмотра информации о таких случаях можно использовать утилиту adrci .
-
Автоматическая оптимизация запросов
В версии Oracle 10g Release 2 администратор базы данных для настройки SQL мог использовать SQL Tuning Advisor. В Oracle 11g Release 2 SQL Tuning Advisor запускается автоматически. В качестве запросов кандидатов для оптимизации используются наиболее ресурсоемкие запросы, сохраненные в Automated Workload Repository (AWR). Данное задание называется Automatic SQL Tuning и запускается каждую ночь.
Для отключения данного задания можно использовать пакет DBMS_AUTO_TASK_ADMIN.
Пример:
$ sqlplus / as sysdba
SQL> exec DBMS_AUTO_TASK_ADMIN.DISABLE(client_name=>’sql tuning advisor’,operation=>NULL,window_name=>NULL);
Для проверки состояния задания можно использовать представление DBA_AUTOTASK_CLIENT.
Пример :
$ sqlplus / as sysdba
SQL> select client_name,status,TOTAL_CPU_LAST_7_DAYS from dba_autotask_client where client_name like 'sql tuning advisor';
CLIENT_NAME STATUS TOTAL_CPU_LAST_7_DAYS
------------------------------------------ -------- -------------------------
auto optimizer stats collection DISABLED
-
Кэширование результатов запросов
Начиная с Oracle 11g Release 1, появилась возможность кэширования и повторного использования результатов выполнения запросов, без повторной обработки данных. В базе данных можно определить размер памяти, выделяемой в SGA для хранения результатов запросов (RESULT_CACHE_MAX_SIZE) и режим использования (RESULT_CACHE_MODE).
Использование данной возможности можно явно указать через задание подсказки (HINT) в запросе.
Несмотря на преимущества, в общем случае, не рекомендуется использовать данную возможность для продуктов на основе «ЦФТ-Платформа Развития».
Для продуктов на основе «ЦФТ-Платформа развития» значение параметра PLSQL_OPTIMIZE_LEVEL должно быть равным 0. Оптимизацию PLSQL с уровнем равным 1 и выше категорически не рекомендуется использовать.
-
Изменения в политиках безопасности
Начиная с Oracle 11g Release 2 измены значения параметров профиля, определяющих срок жизни паролей:
Параметр профиля
|
Значение по умолчанию в Oracle 11g Release 2
|
PASSWORD_GRACE_TIME
|
7
|
PASSWORD_LIFE_TIME
|
180
|
PASSWORD_LOCK_TIME
|
1
|
Параметр SEC_CASE_SENSITIVE_LOGON разрешает или запрещает различать регистры букв в паролях. Значение данного параметра по умолчанию TRUE. Для продуктов на основе «ЦФТ-Платформа Развития», мигрирующих с Oracle 10g Release 2 рекомендуется устанавливать данный параметр в значение FALSE.
Нижеследующие параметры служат для защиты базы данных от попыток перебора паролей.
SEC_PROTOCOL_ERROR_FURTHER_ACTION
SEC_PROTOCOL_ERROR_TRACE_ACTION
SEC_MAX_FAILED_LOGIN_ATTEMPTS
Начиная с Oracle 11g Release 2, параметр AUDIT_TRAIL по умолчанию имеет значение DB. В предыдущих версиях, значение данного параметра было NONE.
По умолчанию ведется аудит следующих действий :
ALTER ANY PROCEDURE
CREATE ANY LIBRARY
DROP ANY TABLE
ALTER ANY TABLE
CREATE ANY PROCEDURE
DROP PROFILE
ALTER DATABASE
CREATE ANY TABLE
DROP USER
ALTER PROFILE
CREATE EXTERNAL JOB
EXEMPT ACCESS POLICY
ALTER SYSTEM
CREATE PUBLIC DB LINK
GRANT ANY OBJECT PRIVILEGE
ALTER USER
CREATE SESSION
GRANT ANY PRIVILEGE
AUDIT SYSTEM
CREATE USER
GRANT ANY ROLE
CREATE ANY JOB
DROP ANY PROCEDURE
Помимо этого ведется аудит всех операций имеющих признак BY ACCESS.
Для управления информацией в журнале аудита (таблица AUD$), в Oracle 11g Release 2 создан новый пакет DBMS_AUDIT_MGMT.
|
