22 авг. 2024 г.

Миграция СУБД Oracle Database с RISC-платформ на Linux x86 с помощью кроссплатформенных переносимых табличных пространств - Часть N3

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД Oracle с RISC-платформ на Linux x86 - различие в форматах хранения (Endian) и необходимость конвертации блоков в файлах данных при миграции. Также кратко была описана технология миграции с помощью транспортируемых табличных пространств, включая вариант с инкрементальными резервными копиями, который позволяет снизить время простоя (downtime) при миграции.

В второй части статьи был описан алгорим миграции с помощью технология Full Transportable Export/Import (FTEX) с использованием скриптов M5, поставляемых компанией Oracle.

Несмотря на значительное упрощение миграции с помощью технологии Full Transportable Export/Import и скриптов M5, опыт автора показывает, что при миграции реальных производственных баз Oracle, возникает ряд проблем.

В заключительной, третьей части статьи, будут описаны эти проблемы и приведены возможные варианты их решения.

Подготовка исходной БД для миграции
Перед тем как начинать финальный этап миграции (перевод на исходной БД табличных пространств в read only и снятие финального инкрементального бэкапа) рекомендуется выполнить следующие действия:
  1. Собрать статистику по словарю и по фиксированным объектам (dictionary и fixed objects statistics), она важны для производительности Data Pump:
       begin
         dbms_stats.gather_fixed_objects_stats;
         dbms_stats.gather_dictionary_stats;
       end;
    
  2. проверить, что на исходной БД включена технология Block Change Tracking (BCT) - для ускорения получения инкрементальных бакапов;
  3. отключить менеджер ресурсов (resource manager):
       alter system set resource_manager_plan='';
       
  4. отключить все maintenance windows в maintenance window-группе:
    select window_name from dba_autotask_window_clients;
    exec dbms_scheduler.disable(name => 'SYS.MONDAY_WINDOW');
    exec dbms_scheduler.disable(name => 'SYS.TUESDAY_WINDOW');
    ...
    exec dbms_scheduler.disable(name => 'SYS.SUNDAY_WINDOW
       
  5. остановить все автоматические задания (Jobs);
  6. для того чтобы избежать ожиданий (waits) вызваных resize-операциями в SGA, следует проверить что размер STREAM_POOL не меньше чем 512M.
Длительный простой для БД, содержащих большое количество объектов в словаре

Проблема связана с тем, что в случае если БД содержит большое количество объектов (десятки тысяч и более), то есть имеет большой объем словаря (Oracle Diсtionary), экспорт/импорт метаданных при заключительном шаге миграции занимает длительное время.

Для решения этой проблемы, следует метаданные на целевую БД копировать заранее с помощью скриптов развертывания приложения, если их нет - с помощью Oracle Datapump Export Utility (параметр content=metadata_only утилиты expdp). При переносе метаданных следует также исключить определения сегментов с помощью параметра EXCLUDE утилиты Oracle Datapump Export (expdp), поскольку они будут переносится на финальном этапе с помощью подключения перемещаемых табличных пространств к целевой БД на Linux x86.

При использовании FTEX, перенос метаданных, кроме определений сегментов, также можно запретить с помощью параметра EXCLUDE утилиты expdp.

После подключения табличных пространств к целевой БД, следует перекомпилировать все PL/SQL-оъбъекты (пакеты, функции, процедуры, триггеры и т.д.) с помощью системного скрипта utlrp.sql, поскольку эти объекты находятся в невалидном состоянии (INVALID) - были созданы когда сегментов (таблиц и индексов) в целевой БД еще не было.

Разумеется, после того как метаданные скопированы на целевую БД, на исходной БД следует запретить изменение определений объектов. Это можно сделать административным способом (запретить "выкатывать" изменения на продуктивную БД), либо с помощью DDL-триггера, который будет выбрасывать исключение (exception) на любую пользовательскую DDL-операцию.

В вышеприведенном способе уменьшения времени простоя есть тонкий нюанс, связанный с последовательностями (sequences).
Дело в том, что если создавать последовательности на целевой БД заранее, то к моменту переключения на БД на Linux x86, на продуктивной БД на RISC-сервере, их значения будут уже другими - будут иметь бОльшие значения. Ведь, ведь после создания последовательностей на сервере Linux x86, текущая продуктивная БД на RISC-сервере продолжала свою работу !

Рис 1. Расхождение значений последовательностей при опережающем копировании метаданных

Для выравнивания текущий значений последовательности на целевой БД с значениями на исходной БД на RISC-сервере, был разработан скрипт reset_seq.sql
Этот скрипт выполняется на целевой БД, сразу после того как приложение на исходной БД остановлено и началась выгрузка метаданных сегментов.
Начиная с Oracle Database 18c сдвинуть текущее значение последовательности можно простой командой ALTER SEQUENCE <имя последовательности> RESTART START WITH <новое <значение последовательности>

Длительный простой для БД, содержащих большое количество сегментов

Если в перемещаемых табличных пространствах содержится большое количество сегментов (сотни тысяч и более), возникает длительный простой при экспорте/импорте метаданных сегментов (операции unplug/plug табличных пространств).
Дело в том, что появления до Oracle Database 21c, экспорт/импорт метаданных для перемещаемых табличных пространств работает только в один поток.

Особенно это критично для больших ERP-систем SAP R/3 и Oracle E-Business Suite, базы данных которых содержат миллионы сегментов.
Для таких БД, операции выгрузки и загрузки метаданных сегментов, могут занимать многие часы.

Для решения этой проблемы можно посоветовать несколько способов, которые могут применяться совместно.

Разделить БД на несколько замкнутых множеств табличных пространств и мигрировать их параллельно
Идея заключается в том, чтобы все пользовательские табличные пространства разделить на несколько замкнутых множеств (self-contained), и затем мигрировать их одновременно.

Если выделить такие множества c ходу не удается, например, сегменты находятся в одном большом табличном пространстве, то можно создать новые табличное пространство и перенести туда сегменты не имеющие связей с другими табличными пространствами.
Для онлайнового перемещения сегментов используются команды alter table ... move online, alter index ... rebuild online, alter table ... move lob, либо пакет DBMS_REDEFINITION если версия СУБД Oracle не поддерживает перемещение сегментов в online.

Для одного из проектов автору пришлось разработать набор скриптов для онлайнового перемещения сегментов из одного табличного пространства в другое.

После миграции, сегменты в новых табличных пространствах можно вернуть обратно, если, конечно, такое требование присутствует.

Следует отметить, что для вышеописанного способа применить технологию Full Transportable Export/Import не получится, поскольку она мигрирует целиком все пользовательские табличные пространства. В этом случае следует применять обычную технологию транспортируемых табличных пространств c инкрементальными резервными копиями и perl-скрипты V4 от компании Oracle.

Удалить небольшие индексы на исходной БД перед финальным шагом и пересоздать на целевой БД Этот способ прост в реализации и позволяет значительно снизить количество сегментов для миграции, а значит и время простоя на экспорт/импорт метаданных сегментов на финальном шаге миграции.

Перед снятием заключительного инкрементального бэкапа на исходной БД на RISC-сервере, удаляются небольшие индексы, размер которых не превышает нескольких гигабайт (размер подбирается исходя из допустимого времени простоя и производительности оборудования на целевой БД). После подключения сконвертированных табличных пространств на Linux-сервере, эти индексы заново пересоздаются с помощью оператора СREATE INDEX ... ONLINE.

Для автоматизации процесса автор использует разработанный скрипт del_small_ind.sql, который выгружает DDL-операторы создания индексов в отдельный файл и удаляет их из исходной БД, выключая ограничения целостности UNIQUE и PK, если удаляемый индекс нужен для поддержки их работоспособности. Одновременно скрипт del_small_ind.sql генерирует скрипт create_small_ind.sql создания этих индексов и включения соответствующих ограничений целостности на целевой БД.

Скрипт del_small_ind.sql запускается после остановки приложения на исходной БД, перед операцией перевода табличных пространств в режим Read Only. Скрипт create_small_ind.sql запускается на целевой БД после подключения сконвертированных табличных пространств.

Удалить вспомогательные (промежуточные) таблицы на исходной БД перед финальным шагом и пересоздать на целевой БД
В большом приложения часто присутствует большой набор таблиц, которые хранят только промежуточные данные. Например, staging-таблицы в информационно-аналитических хранилищах данных. В процессе работы приложения, содержимое таких таблиц удаляется и "перезаливается" заново.

Такие таблицы тоже можно удалить из исходной БД, перед переводом табличных пространств в режим read-only. Следует заранее создать эти таблицы на целевой БД с помощью соответствующих команд CREATE TABLE.
Для автоматизации этой операции удобно использовать утилиту expdp с параметрами TABLES и CONTENT=METADATA_ONLY, и далее импортировать полученный дамп в исходную БД с помощью утилиты impdp.

Заранее перенести статические справочные таблицы
Идея заключается в том, чтобы заранее перенести статические таблицы на БД на Linux x86 сервере. Статические таблицы - имеются в виду таблицы, которые не меняются, по крайней мере на период миграции можно запретить в них изменения. В качестве примера можно привести справочник валют в финансовом приложении, или справочник тарифов услуг в биллинговой системе.

Такие таблицы удаляются из исходной БД, перед переводом табличных пространств в режим read-only. Следует заранее создать эти таблицы на целевой БД с помощью соответствующих команд CREATE TABLE и перенести в них данные из исходной БД.
Для автоматизации этой операции удобно использовать утилиту expdp с параметрами TABLES, и далее импортировать полученный дамп в исходную БД с помощью утилиты impdp.

Следует обратить внимание, что эти статические таблицы придется загрузить в целевой БД в новые табличные пространства (ведь табличных пространств из исходной БД в целевой БД еще нет!) - их нужно заранее создать на целевой БД, и импортировать в них эти таблицы с помощью параметра REMAP_TABLESPACES утилиты impdp.

Для того, чтобы гарантировать неизменность этих таблиц, рекомендуется на целевой БД перевести их в режим read only.
После переключения на целевую БД, нужно не забыть вернуть эти таблицы в режим read write

Удалить неиспользуемые таблицы
Очень часто в больших приложениях, которые постоянно развиваются, в схеме данных скапливаются неиспользуемые таблицы, например: резервные копии таблиц, таблицы для функционала, который уже удален из приложения. Поэтому перед проектом миграции рекомендуется провести очистку схем приложения от неиспользуемх таблиц.

У автора был опыт проекта, когда проблема длительного простоя на экспорт-импорт метаданных сегментов при миграции СУБД Oracle с HP-UX IA64 на Oracle Linux была решена именно этим способом - удалением неиспользуемых таблиц скопившихся за долгие годы изменения схемы данных приложения.

Временный перенос системного табличного пространства и онлайн редологов на RAM-диск
Снизить время импорта метаданных сегментов в целевую БД можно еще одним оригинальным способом: уменьшить объем SGA для экземпляра на целевом сервере Linux x86, на освободившийся объем памяти создать RAM-диск, затем перенести на него файлы табличного пространства SYSTEM и онлайновые редологи.

Дело в том, что в процессе подключения новых табличных пространств и перекомпиляции PL/SQL-кода в целевой БД, основной объем изменений происходит именно в системном табличном пространстве и, очевидно, в online redolog. Скорость доступа к нем резко возрастет, если эти файлы будут размещаться в памяти.

На завершающем этапе миграции, файлы табличного пространства SYSTEM и онлайновых редологов переносятся на обычный диск, экземпляр останавливается, RAM-диск удаляется и освободившееся память возвращается в объем SGA, c последующим стартом экземпляра.

Очистка мусорной корзины (Recycle Bin) и дематериализация пустых сегментов на целевой БД
Конечно, нужно не забыть очистить мусорную корзину, если она включена:

  SQL> purge dba recyclebin;
 
Также можно рекомендовать удалить пустые сегменты на исходной БД, то есть перевести их в режим отложенного создания (deffered segment creation):
  exec dbms_space_admin.drop_empty_segments;
 

В этом случае сам сегмент будет удален из табличного пространства, однако его описание в словаре БД останется.

Экономия времени происходит за счет того, что происходит уменьшение объема метаданных сегментов, поскольку не нужно сохранять в дамп-файле описание сегментов и не нужно затем создавать сегмент на целевой БД при подключении табличного пространства

Миграция директорий (Directory) и BFILE

Очевидно, что содержимое каталогов файловой системы на исходном сервере, автоматически не переносится на целевой сервер.

Поэтому, если приложение или инструменты ДБА, используют ссылки на каталоги в БД Oracle - объекты DIRECTORY и, тем более, внешние LOB-объекты (BFILE), то необходимо вручную скопировать их на целевой сервер, предварительно создав на нем каталоги на файловой системе и аналогичные ссылки на них в БД (directory). Содержимое используемых каталогов с исходного сервера следует переносить на целевой сервер только после того как приложение остановлено.

Для автоматизации проверки использования директорий в исходной БД и генерации DDL-скрипта для их создания на целевой БД, автором был разработан и применяется скрипт check_dirs.sql

Миграция очередей Oracle Advanced Queuing

При использовании миграции с помощью переносимых табличных пространств и скриптов V4, переносятся только таблицы с сообщениями очередей, сами объявления очередей не переносятся в ходе expdp/impdp операции. Для решения этой проблемы, очереди на приемнике нужно пересоздавать заново, определив затем соответствующие таблицы с сообщениями, которые были смигрированы с БД-источника, подробнее об этом в документе "How Advanced Queueing (AQ) Objects Are Exported And Imported. (Doc ID 2291530.1)"

Также при использовании скриптов M5 и FTEX, очень часто происходят проблемы с экспортом/импортом очередей Advanced Queuing - они практически всегда не переносятся корректно.

Рекомендуется в любом случае, определения очередей AQ переносить отдельно, затем определяя для каждой очереди соответствующую таблицу, после подключения табличных пространств на целевой БД.

Для автоматизации процесса выгрузки скрипта создания очередей и скрипта подключения таблиц к вновь созданной очереди на целевой БД автором был разработан скрипт recreate_queues.sql.

Ошибка при миграции большого количества файлов данных

Автор в одном из проектов столкнулся с этой неприятной проблемой.
Если БД имеет большой размер и состоит из большого количество файлов данных, а такое происходит при использовании табличных пространств созданных в режиме smallfile, то при импорте метаданных сегментов с БД-источника возникает ошибка: ORA-01240: too many data files to add in one command.

Проблема связана с тем, что при импорте метаданных сегментов, строка с полными именами файлов данных должна умещаться в одну redo-запись в лог-файле. Описание этой проблемы приведено в документе на сайте службы технической поддержки Oracle Support: "ORA-39123 ORA-1240 Error On Import Of Transportable Tablespace (Doc ID 740983.1)".

Решение, предлагаемое в этом документе, простое: переименовать файлы данных сократив их имена, путь на файловой системе можно сократить сделав короткий символический линк на имя файла и переименовать имя файла данных в СУБД на новое имя с этим символическим линком.

Если файлов данных слишком много, и строка с полным списком файлов все равно не помещается в одну redo-запись, то можно порекомендовать создать табличные пространства в режиме bigfile и перенести туда все сегменты.
Для решения этой проблемы автору пришлось разработать скрипт move_segments.sql для онлайного перемещения сегментов в новые bigfile табличные пространства.

Перенос статистики до миграции табличных пространств

При использовании для миграции скриптов M5, есть небольшая особенность связанная с переносом статистики для SQL-оптимизатора Oracle: статистика не переносится в целевую БД (по умолчанию передается параметр exclude=statistics в утилиту expdp).
В этом есть смысл, поскольку статистику следует переносить заранее - это значительно скэномит время простоя при миграции.

На исходной БД следует выгрузить текущую актуальную статистику в stage-таблицу.

Рис 2. Выгрузка статистики и ее копирование на целевой сервер

Перенос stage-таблицы с статистикой с исходной БД на целевую производится через обычный Datapump Export, либо stage-таблица будет перенесена в ходе миграции соответствующего пространства автоматически.

Проверка метаданных после миграции
Критически важно, после того как табличные пространства успешно подключены к целевой БД на Linux x86 и PL/SQL-код скомпилирован, тщательно проверить что ничего не "сломалось" и не "потерялось" по дороге:
  • проверить блоки данных на отсутствие повреждений (corrupted blocks) с помощью утилиты RMAN (validate database check logical);
  • проверить отсутствие логических повреждений в Oracle Dictionary с помощь системного скрипта hcheck.sql - "Script to Check Data Dictionary for Known Problems (Doc ID 136697.1)";
  • проверить состояние всех объектов в system tablespace, что не появились ли объекты в невалидном состоянии (INVALID) и все ли объекты были перенесы, с этой целью автором был разработан скрипт check_objects.sql для сверки состояний всех объектов,кроме сегментов, на исходной и целевой БД, с контролем их соответствия c исходной БД;
  • проверить, что все сегменты, которые были в исходной БД, также присутствуют и в целевой БД, для этого используется разработанный автором скрипт check_segments.sql ;
  • собрать статистику по словарю и по фиксированным объектам.
Заключение

Проект по миграции СУБД Oracle с платформы RISC на Linux x86 только на первый взгляд кажется простой задачей.

Конечно, для небольших БД, для которых допустимо большое время простоя (downtime), проще всего для этой цели применять технологию экспорт-импорта данных Oracle Datapump.

Однако для больших БД, содержащих большое количество объектов, и для которых бизнес регламентирует небольшое время простоя, необходимо применять другие технологии.

Рассмотренные в статье технологии Oracle Transportable Table с инкрементальными резервными копиями и Oracle Full Transportable Export/Import позволяют решить эту задачу.

Это сложные технологии, но при тщательной подготовке, тестировании и наличии готовых инcтрументов, задача миграции вполне решаема.

За рамками статьи остались вопросы сайзинга целевого сервера на Linux x86 и тестировании производительности при миграции.
Это большие темы и, видимо, они потребуют написания отдельной статьи.

Автор выражает благодарность компании ЭЛЬКАРО за предоставленный для тестирования сервер на платформе Sun Solaris 11.4 for SPARC.

5 авг. 2024 г.

Миграция СУБД Oracle Database с RISC-платформ на Linux x86 с помощью кроссплатформенных переносимых табличных пространств - Часть N2

Введение

В первой части статьи была рассмотрена основная проблема при миграции СУБД Oracle с RISC-платформ на Linux x86 - различие в форматах хранения (Endian) и необходимость конвертации блоков в файлах данных при миграции. Также кратко была описана технология миграции с помощью транспортируемых табличных пространств, включая вариант с инкрементальными резервными копиями, который позволяет снизить время простоя (downtime) при миграции.

Было отмечено, что для упрощения межплатформенной миграции с помощью транспортируемых табличных пространств с инкрементальными резервными копиями, компания Oracle предоставляет набор готовых perl-скриптов - в документе "V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)”.

В заключении, была описана технология миграции с помощью Full Transportable Export/Import (FTEX), которая, начиная с Oracle Database 19c, поддерживает автоматическую конвертацию блоков при смене Endian.

Переход с RISC-платформ на Linux x86 c помощью скрипта миграции M5

Для упрощения миграции БД с сменой Endian, компания Oracle предоставляет новый набор скриптов M5:M5 Cross Endian Platform Migration using Full Transportable Data Pump Export/Import and RMAN Incremental Backups (Doc ID 2999157.1)

Данные скрипты включают в себя все последние улучшения в технологии Oracle FTEX.

Стоит отметить, что скрипты M5 реализованы на языке программирования bash schell, без использования скриптов на perl. Объем M5-скриптов (в строках кода) в несколько раз меньше, чем вариант perl-скриптов для V4.

M5-скрипты поддерживают:
  • encrypted табличные пространства;
  • мультисекционные бакапы;
  • миграцию множества БД в одну CDB одновременно;
  • компрессию в backup sets;
  • улучшенный паралеллизм;
  • БД-источник может быть как Non-CDB так и PDB;
  • БД-приемник также может быть как Non-CDB, так и PDB.

Дополнительно, для миграции с помощью скриптов M5, целевая БД должна иметь включенный режим Oracle Managed Files (OMF) - должен быть выставлен параметр DB_CREATE_FILE_DEST.

Шаги миграции с использованием скриптов-M5

Набор скриптов M5 состоит из следующих файлов:

  • dbmig_driver_m5.sh – основной скрипт;
  • impdp.sh – скрипт, выполняющий подключение табличных пространств к целевой БД;
  • dbmig_ts_list.txt – файл конфигурации с списком переносимых табличных пространств, так как используется FTEX, то здесь должны быть включены все табличные пространства, кроме системных;
  • dbmig_driver.properties - файл конфигурации, в котором прописываются все необходимые для работы скриптов настройки
  • .

Использование скрипта M5 состоит из следующих этапов:

  1. Подготовка к миграции;
  2. Получение полной резервной копии пользовательских табличных пространства, их копирование и конвертация на целевой БД;
  3. Получение инкрементальной резервной копии пользовательских табличных пространства, его копирование, конвертация и применение на целевой БД (выполняется несколько раз для снижения времени простоя);
  4. Подключение новых табличных пространств к целевой БД;
  5. Финальные пост-миграционные операции на целевой БД.

Подготовка

  1. Подключение NFS-диска к хосту с БД-источником и к хосту с БД- приемником, можно обойтись без NFS-диска, но в этом случае придеться вручную копировать резервные копии и конфигурационные файлы между серверами;
  2. oтредактировать файл конфигурации dbmig_driver.properties;
  3. на сервере Linux x86 создать и подготовить пустую БД;

Получение и восстановление “горячей” полной резервной копии

Основные действия начинаются с запуска скрипта dbmig_driver_m5.sh на исходном RISC-сервере

$> dbmig_driver_m5.sh L0  

Данный скрипт, согласно настройкам в файле dbmig_driver.properties, создает полную резервную копию БД, а также создает скрипт restore_L0_<source_sid>_<timestamp>.cmd для утилиты RMAN, для последующего восстановления и конвертации файлов данных на сервере с Linux x86.

При выполнения скрипта dbmig_driver_m5.sh, выдает детальная информация о создании резервной копии, в том числе, показывается итоговая статистика создания резервной копии: время выполнения, объем обработанных данных.

Рис. 1 Создание полной резервной копии на RISC-сервере

SCN, на который была создана полноя резервная копия (RMAN Level 0 backup), записывается в специальный файл .next_scn. Данный SCN будет использоваться для последующих итерационных созданий инкрементальных резервных копий (RMAN Level 1 backup).

Если NFS-диск не используется, то потребуется перенести на целевой сервер файлы резервной копии и сформированный скрипт для RMAN restore_L0__.cmd Далее, используя данный скрипт, следует выполнить воcстановление БД на целевом сервере Linux x86.

  $> rman target / @restore_L0_orcl_2040415224825.cmd

После выполнения скрипта RMAN, требуется проконтролировать восстановление по логам команды RMAN.

Следует обратить внимание, что в управляющем скрипте утилиты RMAN явно отсутствует команда CONVERT, а всего лишь присутствует команда восстановления полной резервной копии:

# target database
RUN
{
ALLOCATE CHANNEL DISK1 DEVICE TYPE DISK FORMAT '...';
ALLOCATE CHANNEL DISK2 DEVICE TYPE DISK FORMAT '...';
RESTORE ALL FOREIGN DATAFILES TO NEW FROM BACKUPSET
'<backup-set-1>',
'<backup-set-2>',
...
'<backup-set-n>'
};

Поскольку конвертация файлов данных c Big Endian на Little Endian производится автоматически.

Получение инкрементальный резервной копии на исходной БД

Запуск создания инкрементальной резервной копии на RISC-сервере также производится через выполнение скрипта dbmig_driver_m5.sh:

  $> dbmig_driver_m5.sh L1

Аналогично, как и при создании полной резервной копии, при создании инкрементальной резервной копии создается управляющий скрипт с именем вида restore_L1_<source_sid>_<timestamp>.cmd для утилиты RMAN.

Рис. 2 Создание инкрементальной резервной копии на RISC-сервере

Вновь созданную инкрементальную резервную копию требуется скопировать и применить на целевой БД:

  $> rman target / @restore_L1_orcl_240416003010.cmd

По окончании восстановления, требуется убедиться в отсутствии ошибок, анализируя журналы выполнения утилиты RMAN.

Точно также, как и в ходе восстановления полной резервной копии, производится автоматическая конвертация блоков инкрементальной резервной копии в Little Endian, перед тем как применять ее к новым табличным пространствам на целевой платформе Linux x86.

Итераций с созданием инкрементальной резервной копии можно выполнить несколько раз, в зависимости от объема изменений в БД-источнике и допустимого времени простоя (downtime). В последний день перед переключением на новую БД, создание инкрементальных резервных копий выполняется несколько раз, чтобы последняя резервная копия получилась минимального размера и, соответственно, ее конвертация и применение выполнятся за минимальное время.

Переключение и время простоя (downtime)

В час “Х” назначается время простоя БД (downtime). В этот период табличные пространства в исходной БД будут переведены в режим Read-Only. Сессии приложения могут использовать исходуню БД на RISC-сервере, но только в режиме Read-Only.

Для выполнения переключения на целевую БД на сервере Linux x86, производится финальный запуск скрипта dbmig_driver_m5.sh на RISC-cервере:

  $> dbmig_driver_m5.sh L1F

При этом запуске, на исходной БД, выполняются следующие действия:

  • Перевод всех табличных пространств, указанных в конфигурационном файле dbmig_ts_list.txt, в режим Read-Only;
  • Получение финальной инкрементальной резервной копии - cоздается управляющий файл RMAN для восстановления restore_L1F_<source_sid>_<timestamp>.cmd
  • Выгрузка всех метаданных с целевой БД, в том числе и для перемещаемых табличных пространств.
Рис. 3 Создание финальной инкрементальной резервной копии на RISC-сервере и выгрузка всех метаданных

Далее, на целевой БД восстанавливаем последний инкрементальный бакап, используя управляющий файл RMAN.

  $> rman target \ @restore_L1F_orcl_240418005511.cmd

Начинаем подключение новых табличных пространств на целевой БД, для этого используем скрипт impdp.sh, в который предварительно нужно внести изменения в переменные окружения

  • ORACLE_HOME – каталог ORACLE_HOME целевой БД на сервере Linux x86;
  • ORACLE_SID – SID целевой БД;
  • ORACLE_CONNECT_STRING – строка подсоединения;
  • DATA_PUMP_DIR=DATA_PUMP_DIR - Data Pump directory

При запуске скрипта impdp.sh указываются 3 параметра:

  1. Дамп файл, полученный в ходе выполнения expdp на исходном сервере
  2. Лог последнего востановления на целевой БД (используется для получения списка файлов данных, которые будут подключаться)
  3. Константа test или run. Если указать test, то просто будет создан файл параметр для утилиты Datapump Import (impdp). При указании run , файл параметров для утилиты Datapump Import также будет сгенерирован, и затем произойдет вызов утилиты impdp с этим параметром.
Рис. 4 Подключение файлов данных и загрузка всех метаданных на сервере Linux x86

Следует обязательно проверить результат в лог-файле.

По окончанию, метаданные в целевую БД перенесены, новые табличные пространства подключены и доступны. Целевая БД готова к использованию!

>Финальные пост-миграционные операции на целевой БД

  1. Вручную удалить точку восстановления (restore point) в целевой БД после миграции (эта точка автоматически создается в самом начале работы скрипта impdp.sh);
  2. Собрать статистику (Table, Index,Column Usage), так как она исключается в M5-скрипте по умолчанию, либо загрузить статистику из stage-таблицы, если статистика была скопирована в stage-таблицу на БД источнике;
  3. Создать полную резервную копию БД на сервере с Linux x86, и удалить резервные копии, которые использовались в ходе миграции, лучше это выполнять через утилиту RMAN, чтобы этой информации не осталось в каталоге RMAN.

Для удаления резервных копий на сервере Linux x86 используются следующие команды RMAN:

  • DELETE
  • CHANGE ... UNCATALOG


Cкрипты M5 в сочетании с технологией Full Transportable Export/Import позволяют значительно упростить миграцию БД Oracle с RISC на Linux x86. Несмотря на это, особенно при миграции крупных БД, содержащих сотни тысяч объектов, возникает ряд проблем.

В заключительной, третьей части статьи, будут описаны проблемы, которые возникли на многочисленных реальных проектах, и приведены способы их решения.

3 авг. 2024 г.

Миграция СУБД Oracle Database с RISC-платформ на Linux x86 с помощью кроссплатформенных переносимых табличных пространств - часть N1

Введение

В последнее время наблюдается рост интереса заказчиков к миграции СУБД Oracle Database с RISC-платформ (прежде всего это платформы Oracle SPARC и IBM Power) на Linux x86.

Этому способствует много причин. Oracle прекратил развитие SPARC-архитектуры, RISC-сервера в несколько раз дороже x86-серверов, комплектующие к ним стоят в несколько раз дороже, чем для x86-серверов. В то же время, платформа x86, благодаря стараниям компании AMD, за последние годы получила бурное развитие: на рынке стали доступны относительно недорогие 2-х сокетные системы с 128 процессорными ядрами, что суммарно дает 256 ядер на сервер (512 потоков с включенной технологией AMD SMT).

Также унификация аппаратного обеспечения инфраструктуры ПО (баз данных и серверов приложений) с помощью широко распространенной платформы Linux x86, значительно упрощает ее сопровождение и стоимость. Также устраняется зависимость от одного вендора, то есть от производителя RISC-серверов.

В данной статье будет подробна описана миграция СУБД Oracle Database с RISC-платформ на Linux x86 с минимальным временем простоя с помощью кроссплатформенных переносимых табличных пространств (Crossplatform Transportable Tablespaces).

Различие в форматах хранения на x86 и на RISC-платформах

Проблема миграции баз данных с RISC-платформ на Linux x86 состоит в том, что эти платформы имеют разный формат хранения данных в памяти и на диске. На RISC-платформах байты упорядочены от старшего к младшему (Big Endian), а в Linux x86 — наоборот, от младшего к старшему (Little Endian).

Рис. 1 Различие хранения данных на платформах RISC и x86

Аналогичным образом данные хранятся на диске и в памяти - в блоках данных СУБД Oracle Database.

Таким образом, для миграции БД Oracle с RISC-платформы на Linux x86, просто скопировать файлы данных недостаточно – необходима конвертация блоков в файлах данных, то есть нужно “переставить” байты в обратном порядке.

Узнать порядок байтов в БД Oracle Database, можно с помощью следующего SQL-запроса:

SQL> SELECT 
   p.endian_format
 FROM 
   v$transportable_platform p,
   v$database                       d
 WHERE
   p.platform_id = d.platform_id;

Миграция с помощью транспортируемых табличных пространств

Технология транспортируемых табличных пространств хорошо и давно известна администраторам баз данных Oracle и разработчикам. Ее суть заключается в возможности просто скопировать файлы данных табличных пространств с одного сервера на другой, с дальнейшим подключением этих файлов к другой БД.

В ходе перемещения табличных пространств в рамках одного и того же Endian, например, с Windows x86 на Linux x86 или c Solaris x86 на Linux x86 производятся следующие операции:

  1. Предварительно создается пустая БД (не содержит пользовательских табличных пространств) на целевой платформе;
  2. Табличные пространства для переноса на исходной БД переводятся в режим “только для чтения” (read only), поскольку файлы данных должны быть согласованы;
  3. Экспортируются метаданные сегментов в этих табличных пространствах с помощью утилиты Datapump Export;
  4. Файлы данных и дамп-файл с метаданными, сформированный на предыдущем шаге, копируются на целевой сервер;
  5. Производится импорт метаданных в целевую БД с помощью утилиты Datapump Import – табличные пространства подключаются к целевой БД;
  6. Табличные пространства переводятся в режим “read write”.
Рис. 2 Копирование табличных пространств с одинаковым Endian

На вышеприведенном Рис. 2, транспортируемые табличные пространства используются для миграции БД с платформы Windows x86 на Linux x86 c одновременным апгрейдом версии СУБД Oracle Database с 11.2.0.4 до 19.23.

При копировании файлов данных, все они должны быть согласованными с помощью перевода табличных пространств в режим Read-only. Копирование файлов данных можно сделать несколькими способами: RMAN backup (Image Copy), утилитами копирования операционной системы или с помощью встроенного системного PL/SQL-пакета DBMS_FILE_TRANSFER.

При миграции БД c RISC-платформы на Linux x86 добавляется шаг конвертация файлов данных, поскольку эти платформы имеют разный Endian.

Необходимо отметить следующие особенности использования технологии транспортируемых табличных пространств для миграции БД между платформами:

  1. До Oracle Database 19c существовало несколько ограничений по типам данных в таблицах для переноса, например не поддерживался перенос таблиц с столбом типа XMLType;
  2. Если перенос осуществляется между БД с разными Endian, например: с IBM AIX на Linux x86, то необходима конвертация файлов данных с помощью команды CONVERT утилиты Oracle RMAN, либо с помощью встроенного системного пакета DBMS_FILE_TRANSFER, который производит конвертирование блоков на “лету” в момент копирования файла на целевую БД;
  3. Переносятся только сегменты (таблицы, индексы, мат. представления, и их секции), все остальные метаданные, которые находятся в системном табличном пространстве SYSTEM, НЕ переносятся (например: пакеты PL/SQL, последовательности, представления, определения пользователей и ролей и т.д.); эти метаданные нужно переносить на целевую БД другим способом, например с помощью утилиты Datapump Export с параметром content=metadata_only.

Из всего вышеизложенного, следует, что для миграции с RISC-платформ на Linux x86 с помощью транспортируемых табличных пространств, требуется очень большое время простоя (downtime).

Рис. 3 Полный цикл миграции БД с IBM AIX for Power на Oracle Linux for x86 с конвертацией Endian

На Рис. 3 приведен полный цикл миграции, включая перенос метаданных и конвертацию файлов БД с помощью RMAN, базы данных с IBM AIX for Power на Oracle Linux x86. Дополнительно производится обновлении версии Oracle Database Release Update с 19.9 на 19.23.

Миграция с помощью транспортируемых табличных пространств и кроссплатформенных резервных копий

C целью уменьшения времени простоя при миграции БД c одной платформы на другую, корпорация Oracle, в версии СУБД Oracle Database 11.2.0.4 добавила новую технологию: Cross Platform Incremental Backup. Речь идет о том, что стало возможно конвертировать не только полные копии файлов БД, а также инкрементальные резервные копии.

Это позволяет получить "горячую" полную резервную копию табличных пространств (backup as image copy) на RISC-платформе, сконвертировать и восстановить его на Linux x86. Затем получить "дельту" изменений на RISC-платформе (инкрементальную резервную копию), и сконвертировав ее, применить к табличным пространствам на Linux x86. Данная технология позволяет очень сильно сократить время простоя БД на миграцию.

Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока конвертация инкрементальной резервной копии не начнет умещаться в заданное бизнесом технологическое окно простоя.

Подробно весь процесс миграции с RISC-платформ на Linux x86 с помощью кроссплатформенных инкрементальных резервных копий подробно описан в документе “V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)” службы Oracle Support.

Для упрощения процесса такой миграции, корпорация Oracle поставляет набор скриптов на языке программирования Perl. Скачать их можно в ссылке в вышеприведенном документе.

Миграция с помощью Full Transportable Export/Import (FTEX)

При миграции с помощью транспортируемых табличных пространств и кроссплатформенных резервных копий было серьезное ограничение: метаданные из табличного пространства SYSTEM нужно было переносить вручную. Еще в Oracle Database 12.1.0.2 была представлена технология Full Transportable Export/Import (FTEX), которая позволяет мигрировать пользовательские табличные пространства и метаданные за один шаг. Практически за один шаг мигрирует целиком вся БД. Но было существенное ограничение: целевая БД должна была иметь тот же Endian, что и исходная БД.

И вот, наконец, в Oracle Database 19c это ограничение было снято – миграцию с помощью Full Transportable Export/Import можно теперь делать между базами с разными Endian.

Миграция с помощью технологии Full Transportable Export/Import (FTEX), имеет следующие преимущества по сравнению с традиционным перемещением табличных пространств с инкрементальными резервными копиями:

  • Переносятся все метаданные БД целиком:
    • профили
    • публичные dblink и синонимы
    • directories
    • triggers, кроме принадлежащих SYS
    • SQL Management Base (SQL plan baselines, plan directives)
  • Полностью автоматическое создание метаданных;
  • Легко в использовании, например: не нужно явно выполнять команду конвертации файлов в RMAN (CONVERT), при восстановлении полной резервной копии или применении инкрементального бэкапа, конвертация блоков на целевой платформе будет выполнена автоматически.
Рис. 4 Упрощение миграции с помощью FTEX

Помимо миграции с RISC-платформ на Linux x86, FTEX может использоваться и для решения других задач:

  • апгрейд на новый релиз или Release Update СУБД Oracle Database;
  • миграцию между non-CDB и PDB;
  • миграцию между платформами с одинаковыми Endian (Например Windows -> Linux).

Для использовании технологии FTEX, для миграции с RISC на x86, необходимо, чтобы исходная и целевая базы данных удовлетворяли следующим требованиям по установленным версиям ПО:

  • установлен Oracle Database Release Update 19.18 и выше;
  • также установлен соответствующий Datapump Bundle Patch.

Помимо требований к версии БД, для использования FTEX, также должны выполняться следующие условия:

  • Целевая БД должна иметь значение COMPATIBLE тот же или выше, что и исходная БД;
  • Целевая БД должна иметь тот же Character Set что и исходная;
  • В целевой БД рекомендуется иметь TimeZone-файл той же версии, что и в исходной БД;
  • При наличии типов TIMESTAMP WITH LOCAL TIME ZONE, параметр DBTIMEZONE должен быть одинаковым.

В второй части статьи будет подробно рассмотрена миграция БД Oracle Database с RISC на x86 с помощью скриптов нового поколения от Oracle (M5).

27 дек. 2020 г.

RACChecker 21.1 Released!

Спешу сообщить, что выпущена новая версия утилиты RACChecker, которая предназначена для проверки готовности приложения к миграции в среду Oracle Real Application Cluster.
Появилось ряд новых возможностей, которые я добавил по просьбе трех крупных заказчиков:
  • для работы утилиты теперь необходим ODP.Net 19c, который входит в состав Oracle Client 19c for Windows;

  • новый параметр CHECK_JOB_NO_CLASS, включает проверку на наличие заданий DBMS_SCHEDULER, которые не привязаны к сервису, то есть не привязаны ни к какому JOB CLASS;

  • при включенном параметре CHECK_V$VIEWS (проверка на использование V$-представлений в PL/SQL-коде приложения), теперь выводится не просто имя PL/SQL-процедуры и номер строки, но и имя используемого V$-представления, например:
      Checking v$-views issue
        found in procedure TEST_RACCHECKER_VDOLLAR - line 9 ("V$SESSION")
        found in procedure TEST_RACCHECKER_VDOLLAR_WRAP - (wrapped!) - ("V$INSTANCE")
      Finish check this issue
      
    
    обратите, кстати, внимание, что в втором случае - номера строки нет, потому-что исходная процедура зашифрована (wrapped) - утилита обнаружила факт использования представления V$INSTANCE через зависимости! ;

  • новый недокументированный параметр _SKIP_INVALID_OBJECTS позволяет пропустить проверку объектов, которые находятся в состоянии INVALID;
    Да,да - RACChecker имеет недокументированные параметры! Посмотреть их можно, указав ключ "_HELP=Y" при запуске утилиты;

  • новый параметр CREATE_SAMPLE_CONFIG позволяет сгененировать простой файл конфигурации sample_config.cfg, - для дальнейшей его модификации;

  • теперь утилита поддерживает более 1000-пакетов (packages)- в предыдущих версиях происходило "падение" утилиты по ошибке переполнения, если в БД в одной смехе присутствовало более 1000 пакетов;

  • проверка на использование директорий (Oracle directory) включена по умолчанию (CHECK_DIRS=Y).
Подробно требования к приложению описаны в свежем документе "Application Development Best Practices for Oracle Real Application Clusters (RAC) - Developer’s Checklist".

Ссылка для скачивания: RACChecker.


17 февр. 2017 г.

Oracle Database 12.2 New Features content

Материалы нашего семинара по новым возможностям Oracle Database 12c Release 2 можно скачать по следующей ссылке: Oracle Database 12c Release 2

29 июл. 2016 г.

RACChecker - check application for RAC compatible

Тема разработки и адаптации приложений под RAC очень обширна и многогранна и затрагивает практически все аспекты создания прикладного ПО для СУБД Oracle Database. Но, тем не менее, для того чтобы гарантировать что ваше приложение корректно будет работать в RAC, необходимо убедиться, что оно не использует технологии и механизмы которые в RAC в не работают, либо работают с особенностями. Подробно требования к приложению описаны в документе "Oracle RAC Database aware Applications - Developer’s Checklist". Вот перечень этих технологий:
  • каналы (пакет DBMS_PIPE) - не синхронизируются между узлами кластера;

  • объекты БД типа DIRECTORY (каталоги в файловой системе) должны располагаться на разделяемом сторадже и должны быть видны всем узам кластера;

  • вместо V$-представлений нужно использовать соответствующие GV$-представления;

  • задания управляемые через пакет DBMS_JOB - крайне не рекомендуется использовать в RAC, поскольку задания этого пакета не поддерживают сервисы.


    Методы борьбы с вышеперечисленными технологиями мы подробно рассматривали на культовом семинаре "RAC Deep Dive for Developers"

    Довольно часто приложение имеет большие объемы PL/SQL-кода (сотни тысяч и даже миллионы строк кода), и вспомнить о том, в каком месте используется тот же DBMS_PIPE крайне сложно: код давно отлажен и работает, а его автор уже давно не работает в компании.
    Для того, что облегчить анализ серверной части кода (хранимых процедур PL/SQL) мною была разработана утилита RACChecker. Эта утилита поможет быстро ответить на вопрос: готово ли, в минимальной степени, ваше приложение при переходе в RAC.
    RACChecker анализирует ваш исходный код и находит объекты и строки кода, где вы используете технологии, которые в RAC не работают.

C:\RAC\Utils\RACChecker>RACChecker.exe help=y

RAC Checker: Release 12.2.0.1.0 - Production on 15.04.2015 11:07:13

Utility for check support Oracle DB for RAC and Exadata

Copyright (c) 2016 Igor Melnikov.  All rights reserved.

You can control how RACChecker runs by entering the RACChecker command followed
by various arguments. To specify parameters, you use keywords:

     Format:  RACChecker parameter=value TYPE=value

     Example: RACChecker USERID=scott/tiger@orcl TYPE=PIPE
              RACChecker USERID=demo/demo@demo   TYPE=ALL

Keyword          Description (Default)
--------------------------------------------------
SCHEMAS          schemas in which check ALL-for all schemas (ALL)
HELP             print this message: Y/N (N)
TYPE             object type: PIPE,JOB,ALL (ALL)
REPORT_FILE      file name for output report
PARFILE          parameter file name
SEQUENCES        Show NON-cached sequences (Y)
MIN_SEQ_CACHE    Check for sequences on minimum cache size (20)
SEQ_ORDERED      Check for sequences which are ordered (N)
SAVE_SOURCE      Save sources for "bad" objects (N)
DIR_SOURCE       Directory where sources will be save
SEQ_DDL_OPT      Generate sequence ddl-optimization for RAC: CACHE,ORDER,BOTH,NONE (NONE)
CHECK_DIRS       Check directory objects (for shared dir issue) (N)
CHECK_V$VIEWS    Check v$-views usage (Y)
USERID           Oracle connection string


Я думаю, что из списка параметров очевидно их назначение.
Следует обратить внимание лишь на следующие моменты:

  • пользователь в строке подключения (параметр USERID) должен иметь права на чтение словаря (dictionary);

  • утилита опционально может находить некэшируемые последовательности (с ними тоже возможны проблемы в RAC);

  • возможна выгрузка DDL-скриптов для плохих объектов с помощью параметра SAVE_SOURCE=Y;

  • для своей работы утилита требует установленной среды выполнения .NET Framework 4.5, а также ODP.NET Provider 12.1.0.2.4 - рекомендуется установить версию поставляемую с Instant Client - она небольшая по размеру.

Конечно, никакого волшебства в работе этой утилиты нет: она всего лишь анализирует соответствующие представления словаря.

Утилита может находить факт использования неработающих в RAC технологий (например: пакет DBMS_PIPE), даже если PL/SQL-код зашифрован (wrapped). Утилита на "лету" определяет что код зашифрован, и в этом случае анализирует не исходный код, а зависимости от пакетов dbms_pipe,dbms_job.
Утилита НЕ может обнаружить факт использования этих пакетов только в одном случае: если они используются через динамический PL/SQL (EXECUTE IMMEDIATE или DBMS_SQL) и код зашифрован.

Утилита определяет факт использования пакетов внутри однострочных коментариев. Это не приводит к ложному срабатыванию. Многострочные комментарии, к сожалению, не поддерживаются. При анализе последовательнойстей можно задать минимальный размер их кеша (параметр MIN_SEQ_CACHE). В этом случае будут выведены все последовательности, размер кэша которых меньше этого минимума.

За время своего существования утилита RACChecker постоянно развивалась, и помогла очень многим заказчикам перенести свои существующие приложения в среду Oracle Real Application Cluster.

C помощью RACChecker вы быстро определите проблемные места при переходе в RAC!

Ссылка для скачивания: RACChecker.

12 апр. 2016 г.

Real-Time Database Operation Monitoring в Oracle Database 12c

Технология мониторинга SQL-запросов в режиме реального времени (Real-Time SQL Monitoring ), которая появилась в Oracle Database 11g, позволяет администраторам и разработчикам взглянуть внутрь каждого долго выполняющего запроса.
Для каждого долго выполняющегося запроса можно увидеть его реальный план выполнения, количество обработанных строк, расхождение ожидаемой и фактической кардинальности (количество ожидаемых и количество фактических строк) на каждом шаге плана запроса. Также можно увидеть различные метрики SQL-запроса: CPU, I/O requests, throughput, PGA, temp space.
В том числе можно производить мониторинг статистики ввода-вывода для каждого шшага запроса.

В свое время технология Real-Time SQL Monitoring была большим шагом вперед для ответа на вопрос "Что реально происходит в базе данных?".

Рис 1. Мониторинг выполнения запроса с помощью Real-Time SQL Monitoring

Вместе с тем, вышеописанная технология позволяет производить мониторинг только на уровне отдельного запроса. Очень часто необходимо отслеживать выполнение на уровне отдельных бизнес-операций в приложении. Поскольку бизнес-операция, в приложении состоит из нескольких запросов, приходиться вручную сопоставлять выполняющиеся запросы к конкретной бизнес-операции, например: "Расчет зарплаты". Особенно актуальной эта задача становится при возникновении проблем с производительностью кричичных для бизнеса операций.

Рассмотрим такой типичный случай.
При возникновении проблемы с производительностью расчета зарплаты, конечный пользователь обращается к администратору СУБД. DBA должен среды сотен (возможно и тысяч!) выполняющихся запросов, выделить запросы относящиеся к расчету зарплаты, выяснить какие из них сейчас выполняются и, затем, наконец, разобраться в причинах медленной работы этой бизнес-операции.
Для идентификации запросов часто приходится обращаться к разработчикам приложения и анализировать его исходный код. Все это часто приводит к взаимным обвинениям администраторов и разработчиков.
Не правда-ли: знакомая картина?

СУБД Oracle Database 12c предлагает решение и этой проблемы, позволяя производить мониторинг на уровне составных бизнес-операций.
Эта технология получила название Real-Time Database Operation Monitoring, и позволяет осуществлять мониторинг в режиме реального времени в терминах бизнес-процессов (бизнес-операций) выполняющихся в данный момент в СУБД.
Очевидно, что СУБД ничего "не знает" про бизнес-процессы, и для этого приложению необходимо каким-либо образом сообщить об этом базе данных: сгруппировать обращения к СУБД в бизнес-операции.

Для того, чтобы выделить в потоке обращений к СУБД бизнес-операцию, предлагается специальный API (Application Program Interface), реализованный в виде PL/SQL-пакета DBMS_SQL_MONITOR.
Пакет DBMS_SQL_MONITOR стандартно поставляется в составе СУБД и устанавливается по умолчанию - то есть входит в состав стандартных системных пакетов Oracle Database 12с.
Для выделения начала бизнес-операции предназначена процедура BEGIN_OPERATION данного пакета, для окончания бизнес-операции - END_OPERATION.

Возвращаясь к вышеописанному примеру с расчетом заработной платы, ее мониторинг в исходном коде хранимой PL/SQL-процедуры может быть оформлен следующим образом:
 CREATE PROCEDURE calc_salary(v_pDep IN NUMBER) IS
   v_xDBOpId          NUMBER;
 BEGIN
   v_xDBOpId := dbms_sql_monitor.begin_operation('Расчет зарплаты',
                                                 forced_tracking => 'Y');
   prepare_calc();
   main_calc();
   finish_calc();

   dbms_sql_monitor.end_operation('Расчет зарплаты', v_xDBOpId); 
 END;
Параметр forced_tracking процедуры BEGIN_OPERATION аналогичен хинту MONITOR в запросе: при его установке (forced_tracking => 'Y'), мониторинг бизнес-операции производится в любом случае. В противном случае - мониторинг производится только в случае, если бизнес-операции по продолжительности выполнения занимает 5 и более секунд ЦПУ или ввода-вывода. Запустим наш модифицированный бизнес-процесс расчета зарплаты и посмотрим, как он теперь отображается на экране SQL Monitoring консоли администрирования Enterprise Manager 12c. В списке выполняющихся запросов появился запрос c "говорящим" именем "Расчет зарплаты":

Рис 2. "Расчет зарплаты" в списке запросов на экране SQL Monitoring

Перейдя внутрь выполняющейся бизнес-операции - для этого нужно кликнуть мышью на SQL_ID операции (в нашем случае: "Расчет зарплаты"), можно увидеть страницу детальной информации: какие запросы из состава бизнес-операции уже выполнились, и какой запрос является текущим - выполняется в данный момент:

Рис 3. Детальная информация о выполнении бизнес-операции

"Провалившись" внутрь любого запроса в бизнес-операции, можно увидеть знакомый по предыдущим версиям экран SQL-мониторинга запросов.

После завершения бизнес-операции входящие в него запросы точно также доступы для анализа, как это и было раньше (в СУБД Oracle Database 11g) для уже завершившихся SQL-запросов.
Рис 4. Бизнес-операция "Расчет зарплаты" завершена

Для того, чтобы сгруппировать запросы в бизнес-операции из приложений Java и С++/C-приложений, соответствующий клиентский API доступа к БД (JDBC и OCI, соответственно) также был расширен.
Вот так, например, выглядит выделение бизнес-операции в Java-приложении:

Connection conn = DriverManager.getConnection(myUrl, myUsername, myPassword);
conn.setClientInfo("E2E_CONTEXT.DBOP", “Расчет зарплаты");
Statement stmt = conn.createStatement();
stmt.execute(v_xSQLQuery1);
... ... ... ...
... ... ... ...

conn.setClientInfo("E2E_CONTEXT.DBOP", null);
Если Вы разрабатываете приложение сразу для разных версий СУБД Oracle Database, то можете воспользоваться условной компиляцией PL/SQL, чтобы иметь один и тотже код в независимости от версии БД:
 create procedure calc_salary(v_pDepartmentId in number) is
    v_xDBOpId          NUMBER;
  begin
    $if dbms_db_version.ver_le_11_2 $then

    $else
      v_xDBOpId := dbms_sql_monitor.begin_operation('Расчет зарплаты',
                                                    forced_tracking => 'Y');
    $end
  
    v_gCurrentDepartmentId := v_pDepartmentId;
  
    prepare_calc();
    main_calc();
    finish_calc();
    
    $if dbms_db_version.ver_le_11_2 $then
    $else 
      dbms_sql_monitor.end_operation('Расчет зарплаты', v_xDBOpId);  
    $end
  end;
Объявление переменной v_xDBOpId нет смысла обрамлять в символ условной компиляции,поскольку при компиляции в СУБД Oracle Database 11g, PL/SQL-оптимизатор удалит её из исходного кода, поскольку она является "мертвой" - нигде не используется.

Продолжение следует ...