руководитель Центра компетенции
по базам данных УКЦ ФОРС,
Oracle Certified Professional
Уважаемые коллеги и друзья!
Уже несколько месяцев прошло с тех пор, как мы смогли впервые скачать такой долгожданный релиз 12.2. Это достаточный срок, чтобы ознакомиться с новым продуктом, протестировать его работу как в тестовом, так и (смельчаки всегда найдутся) в боевом окружении. Возможно, протестировать свое приложение или написать новое, увидеть разницу в планах запросов, обжечься на багах и применить новые патчи, наконец!
Да мало ли что бывает в нашей работе!
И это — достаточный срок, чтобы составить свое определенное мнение, основанное не на отзывах в форумах и статьях в известных (и не очень) журналах с разной степенью аффилированности, но на собственном опыте и опыте коллег, мнению которых я за годы работе в ФОРСе привык доверять.
И, кстати, меня, как специалиста, такая привычка еще никогда не подводила!
Oracle Database 12.2 представляет существенный апгрейд мультиарендной архитектуры БД, а также новый подход к процессингу информации ресурсами оперативной памяти. Нововведения предназначены для оптимизации ключевых рабочих нагрузок и их главных характеристик: производительности, безопасности и т.д. Общее число нововведений во втором релизе 12-й версии Oracle составляет около 300 различных усовершенствований буквально по всем важным направлениям работы.
Теперь, когда лирическое отcтупление завершено, перейдем к более подробному рассмотрению основной темы данной статьи — обзору основных нововведений Oracle Database 12 R2.
В Oracle Database 12.2 введено концептуально новое понятие — Application Container. Oracle семимильными шагами, причём довольно успешными, движется дальше, по пути консолидации и претворения в жизнь облачных решений.
Представлена концепция контейнеров приложений, которая предлагает возможность иметь одно логическое определение для одного или нескольких приложений.
Каждый Application Container, по аналогии с CDB, имеет свой Application Root и Application Seed PDB, которые разделяют свои ресурсы среди PDB, содержащиеся в этом контейнере. Подробнее про нововведения в контейнерных базах можно прочитать в нашей статье.
Интересное нововведение — возможность использования каждой подключенной базой своего локального UNDO. При этом, редологи, конечно, остаются общими для всех PDB в контейнере.
Параметр инициализации, отвечающий за SHARED или LOCAL UNDO — LOCAL_UNDO_ENABLED, его значение, по умолчанию, — FALSE.
В случае перевода параметра в TRUE, каждый контейнер в БД должен использовать локальный UNDO.
Для чего это нужно? Эта опция существенно облегчает горячее клонирование CDB и обеспечивает нулевое время простоя при переносе контейнеров.
Процесс перевода на использование локальных UNDO выглядит так:
SQL> STARTUP UPGRADE SQL> ALTER DATABASE LOCAL UNDO ON;
Полезные нововведения появились и по части восстанавливаемости и flashback контейнерных баз.
Во-первых, появилась возможность остановки контейнера с параметром abort:
SQL> ALTER PLUGGABLE DATABASE CLOSE ABORT;
В случае утери или порчи табличного пространства system PDB нам больше нет необходимости переводить весь контейнер в режим mount, что достаточно серьезно поднимает уровень доступности систем, где любое время простоя является неприемлемым.
Во-вторых, появилась возможность делать flashback database для отдельно взятой PDB, что ранее, в версии 12 R1, было недоступно ( только для всего контейнера).
Пример показывает конфигурацию и использование опции flashback database для отдельной PDB.
Конфигурируем:
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=2880 SCOPE=BOTH; SQL> ALTER DATABASE FLASHBACK
Делаем flashback database для PDB:
RMAN> CONN sys@pdb1 RMAN> ALTER PLUGGABLE DATABASE CLOSE; RMAN> FLASHBACK PLUGGABLE DATABASE pdb1 TO SCN 411010; RMAN> ALTER PLUGGABLE DATABASE pdb1 OPEN RESETLOGS;
Концептуально, PDB открывается с помощью RESETLOGS также как и OPEN RESETLOGS для обычной БД. Информацию о реинкарнациях PDB можно посмотреть в новом динамическом представлении V$PDB_INCARNATION.
Стоит обратить внимание, что PDB RESETLOGS не делает RESETLOGS в CDB, а только изменяет связанную с ней запись в общем контрольном файле!
Oracle Database 12.2 вводит новый параметр для контроля уровня параллелизма в запросах, с помощью конструкции containers().
SQL> ALTER SESSION SET containers_parallel_degree = 12;
Или
SQL> SELECT /*+ CONTAINERS (DEFAULT_PDB_HINT=PARALLEL 8*/ sum(revenue), year FROM CONTAINERS(sales_data) WHERE year = 2014 GROUP BY year;
Появилась возможность использовать PDB-Level Snapshot Views, что было недоступно на 12.1:
SQL> SELECT view_name FROM dba_views WHERE view_name LIKE '%AWR%_PDB%';
На рисунке показана архитектура и состав этих уровней для представлений в AWR:
ADDM, тем не менее, срабатывает только на уровне всего контейнера, как и отчеты AWR. Впрочем, в отчете AWR мы можем увидеть детализированную статистику для всех контейнеров: для CDB root и каждой открытой PDB.
Пожалуй, самое важное нововведение в аспекте управления ресурсами — локальное управление памятью для каждой подключенной PDB.
До 12.2 мы никаким явным образом не могли заставить подключенные базы ограничивать использование областей памяти.
Единственный метод как-то ограничить ресурсы каждой PDB был Resource Manager, при использовании которого можно было изменить максимумы и доли используемых ресурсов внутри контейнера путем ограничения использования процессора.
Также была возможность регулировать I/O на уровне CDB, но этот функционал был доступен только для Exadata (до 12.2).
В новой версии БД появились параметры:
Теперь, чем нас действительно сильно порадовала Oracle. Да, друзья, это свершилось! Теперь, с 12 R2, для каждого подключенного контейнера можно использовать свой SGA_TARGET, а также свои параметры для ручного управления памятью — DB_CACHE_SIZE и SHARED_POOL_SIZE.
Появился новый параметр SGA_MIN_SIZE — «минимальная гарантированная доля SGA» для PDB, причем сумма всех минимумов SGA для всех PDB не может превышать 50% от всей памяти контейнера.
Про PGA — тоже хорошие новости. Параметры PGA_AGGREGATE_LIMIT и PGA _AGGREGATE_TARGET устанавливаются на уровне контейнеров точно так же, как и для обычных баз данных.
Ну не прекрасно ли!
Соответственно, появились и новые динамические представления для контроля за использованием памяти на уровне PDB. Вот некоторые из них:
V$RSRCPDBMETRIC V$RSRCPDBMETRIC_HISTORY V$RSRC_PDB V$RSRC_PDB_HISTORY
Ну и, наконец, 12.2 полностью стала поддерживать появившийся в 12.1 функционал Heat Map (т.н. «горячих карт») и расширений управления хранения данных согласно жизненного цикла (ADO Enhancements).
Включить данный функционал очень просто. Достаточно прописать в параметрах строчку:
HEAT_MAP = ON
Наряду с появившимися в Oracle Database 12.1 новыми системными привилегиями SYSBACKUP, SYSDG и SYSKM, призванными разграничить, в целях безопасности, административные полномочия, в 12.2 введена новая системная привилегия SYSRAC для управления кластером.
Привилегия SYSRAC:
Например:
SQL> grant sysrac to c##test; * ERROR at line 1: ORA-28190: SYSRAC administrative privilege cannot be granted to other users
Также появилась новая группа OSRACDBA с возможностью аутентификации посредством OS*.
*В Windows группа называется ORA_%HOMENAME%_SYSRAC.
SYSRAC обладает следующими привилегиями:
|
ALTER DATABASE MOUNT ALTER DATABASE OPEN ALTER DATABASE OPEN READ ONLY ALTER DATABASE CLOSE ALTER SESSION SET EVENTS ALTER SESSION SET _NOTIFY_CRS ALTER SESSION SET CONTAINER ALTER SYSTEM REGISTER ALTER SYSTEM SET LOCAL_LISTENER |
ALTER SYSTEM SET REMOTE_LISTENER ALTER SYSTEM SET LISTENER_NETWORKS SELECT X$ tables, V$ / GV$ views EXECUTE dbms_service dbms_service_prvt dbms_session dbms_ha_alerts_prvt DEQUEUE sys.sys$service_metrics |
Наконец-то, претерпел изменения файл паролей! Теперь он имеет другой формат и несет больше информации.
Соответственно, изменился синтаксис утилиты orapwd:
$ orapwd Usage: file=<fname> … format=<12/12.2> sys=<pass/external(<sys-ext-name>)> $ orapwd describe file=orapwcdb3 Password file Description : format=12.2
Тем не менее, утилита orapwd позволяет очень просто мигрировать с 12.1 и более ранних версий на файла паролей версии 12.2. Пример использования можем посмотреть:
$ mv orapwcdb1 orapwcdb1.12 $ orapwd file=orapwcdb1 input_file=orapwcdb1.12 format=12.2 $ orapwd describe file=orapwcdb1 Password file Description : format=12.2
*Команда DESCRIBE утилиты orapwd также проверяет файл паролей на целостность.
Задача разделения доступа к данным в ИТ-системах возникает всегда. Если доступ к базе данных возможен только из сервера приложений, то можно возложить эту обязанность на него. Но почти всегда есть потребность прямого доступа к данным, например для аналитиков и других привилегированных пользователей.
В Oracle 12c добавлена возможность изменять на выдаче значения полей (полностью или частично), в зависимости от неких, определяемых нами, условий. Эта возможность получила название Oracle Data Redaction и состоит в применении специальных политик.
В 12.2 Oracle опция Data Redaction получила значительные улучшения. Если в 12.1, при создании политик, мы могли только определить «how to redact», то есть, каким образом изменить данные в выдаче, то в 12.2 каждый столбец может иметь свою «policy expression».
То есть, Oracle Database 12.2 позволяет создать разные расширения для разных столбцов одной таблички или представления, или просто для отдельного столбца (например, номера кредитных карт).
Oracle Database 12.2 и опция Oracle Advanced Security предоставляют новую «библиотеку форматов данных Data Redaction». Библиотека форматов хранится в репозитарии Enterprise Manager Cloud Control и содержит:
В Oracle Database 12.2 появилась возможность шифровать существующие табличные пространства.
*Тут стоит заметить, что шифровать UNDO, если у нас зашифрованные данные в файлах бессмысленно, ибо попавшие в UNDO before-change данные уже будут зашифрованными!
**Можно создать зашифрованное Temporary табличное пространство, но зашифровать существующее — не получится!
Появилась возможность для обновления и удаления каталога восстановления одной командой:
RMAN> UPGRADE CATALOG NOPROMPT; RMAN> DROP CATALOG NOPROMPT;
Команды RESTORE и RECOVER обычно идут последовательно, одна за другой, что, собственно говоря, логично. Oracle Database 12.2 расширяет функционал команды RMAN REPAIR опциями DATAFILE, TABLESPACE, PLUGGABLE DATABASE и DATABASE и выполнением RESTORE и RECOVER одной единой командой.
При этом (если это возможно), REPAIR автоматически переводит файл данных в offline, извлекает из его бекапа (RESTORE), восстанавливает его (RECOVER) и потом переводит снова в состояние online!
Посмотрим на примере:
RMAN> REPAIR DATABASE; RMAN> REPAIR PLUGGABLE DATABASE pdb1; RMAN> REPAIR TABLESPACE example; RMAN> REPAIR DATAFILE 12;
Далее, появились интересные нововведения в операции неполного восстановления базы данных.
До 12.1 включительно, восстанавливая базу до последнего доступного архивного или редолога, мы могли пользоваться командой (из SQL Plus или RMAN 12C)
RMAN> RECOVER DATABASE UNTIL CANCEL;
После применения последнего доступного лога мы давали команду
RMAN> CANCEL
и
RMAN> ALTER DATABASE OPEN RESETLOGS;
В 12.2 этот процесс автоматизирован, достаточно дать одну команду
RMAN> RECOVER DATABASE UNTIL AVAILABLE REDO;
И, в случае применения сотен или, не приведи Бог, большего количества архивных логов, процесс восстановления пройдет гораздо быстрее. При этом, конечно же, открытие БД с опцией RESETLOGS никто не отменял:
RMAN> ALTER DATABASE OPEN RESETLOGS;
Отрадно, что старый синтаксис не стал неиспользуемым, ибо как нам тогда малой кровью восстанавливать БД при утерянном redo log со статусом ACTIVE, который на наше счастье, успел заархивироваться?
Позволю себе небольшое лирическое отступление по этому поводу, или как «обмануть» Oracle!
Предположим, у нас неведомым образом утеряна группа лог файлов. Все!
Инстанс падает, мы монтируем базу и смотрим v$log. Видим статус утерянных файлов журналов STATUS=ACTIVE и ARC=YES. То есть, лог файл не требует архивации, но нужен для recovery.
Если бы его статус был CURRENT (то есть, лог файл текущий), то БД можно восстановить только с помощью более раннего полного бекапа на момент времени до утери CURRENT лог файла (группы). В случае же, если статус лог файла INACTIVE, то у нас вообще практически нет проблем. Данных, необходимых для восстановления инстанса, в нем нет, файл заархивирован. В этой ситуации мы просто пересоздаем его с помощью команды:
SQL> alter database clear logfile '/FILE_PATH’;
и открываем базу без RESETLOGS.
SQL> alter database open;
Возвратимся к нашему утерянному ACTIVE лог файлу. Так как у нас есть архивная копия, то мы можем, применив ее, «перескочить» в процессе восстановления через утерянный лог файл и закончить восстановление применением текущего (CURRENT) редо лога.
Если не идти по этому пути, то процесс восстановления будет таким же, как и при потере CURRENT редо лога, то есть, восстановление из прошлого бэкапа и накат архивов и редо логов. Кошмар любого администратора и его руководителя... На большой базе, или при применении большого количества архивных логов время простоя может быть просто неприемлемым!
Поэтому поступаем таким образом:
SQL> alter database recover until cancel;
SQL> alter database recover continue default;Применяем архивные логи, причем последним применяется архивная копия нашего трагически потерянного ACTIVE редо!
SQL> alter database recover continue default;
SQL> alter database recover logfile '/CURRUNT REDO LOG FILE’;
SQL> alter database open resetlogs;
Теперь вернемся, друзья, к нашей теме, к 12.2.
Изменению подверглась возможность восстановления отдельных таблиц. До 12.2 таблицы (партиции) восстановимы были только в пределах одной схемы. Remap мог изменить имя таблички, но не ее собственника. В Oracle Database 12.2 это ограничение исчезло, причем касательно не только таблиц, но и всех зависимых объектов (индексов, ограничений, триггеров и т.д.).
RMAN> RECOVER TABLE hr.employees UNTIL SCN 2146235 AUXILIARY DESTINATION '/u01/app/oracle/backup_test' REMAP TABLE hr.employees:hr_new.employees;
Полезным можно считать нововведение, когда при создании вспомогательного (auxiliary) инстанса для восстановления таблицы, Oracle автоматически проверяет наличие места на диске. Те читатели, кто попадал в подобные ситуации с нехваткой места (как всегда, неожиданной), поймут. Если дискового пространства недостаточно, то сервер сразу сгенерит ошибку на уровне ОС и процесс восстановления просто не начнется.
Значительные изменения, заслуживающие отдельной статьи, которая, безусловно, будет опубликована в ближайшем номере FORS Magazine, произошли с возможностью переопределения таблиц, в частности, с пакетом DBMS_REDEFINITION.
В частности, в процедуре START_REDEF_TABLE параметр enable_rollback, которая позволяет откатить все изменения до запуска FINISH_REDEF_TABLE.
Процесс выглядит следующим образом:
SQL> EXEC DBMS_REDEFINITION.START_REDEF_TABLE (... ENABLE_ROLLBACK => TRUE) SQL> EXEC DBMS_REDEFINITION.FINISH_REDEF_TABLE (... DISABLE_ROLLBACK => TRUE) SQL> EXEC DBMS_REDEFINITION.ROLLBACK(...); SQL> EXEC DBMS_REDEFINITION.ABORT_ROLLBACK(...);
И, главным изменением в процессе оnline redefinition, безусловно, нужно считать возможность переопределения с «No Exclusive DML Locks»!
То есть, на заключительном этапе redefinition (EXEC dbms_redefinition), больше не накладывается эксклюзивная блокировка на таблицу, заставляющая (возможно) других пользователей ожидать ее высвобождения.
Конечно, это не та длительная блокировка, накладываемая на объект командой ALTER TABLE MOVE на все время выполнения этого пресловутого MOVE, но, тем не менее, для систем высочайшего уровня доступности даже небольшие задержки могут быть неприемлемыми.
Oracle Data Pump в версии 12.1 базы данных Oracle поддерживает параллельный экспорт и импорт табличных данных, но обработка метаданных при этом производится одним процессом. Data Pump в 12.2 сокращает время выгрузки и загрузки метаданных путем параллельного запуска нескольких фоновых процессов. Это новое усовершенствование позволяет ускорить процесс миграции больших баз данных. Параллельный экспорт и импорт метаданных активируется заданием параметра PARALLEL:
$ expdp ... PARALLEL = n
При миграции таблицы, DBA иногда предварительно создает таблицу перед переносом ее данных, т.к. новая таблица может иметь новые атрибуты (например, сжатие) или другой вид партиционирования. Импорт данных таблицы из секционированной таблицы в новую идет последовательно, по одной партиции за раз, потому что измененная структура новой таблицы может вызвать появление строк из одной экспортируемой партиции исходной таблички в нескольких партициях целевой.
Если же партиций много (не такой уж редкий случай на практике), то процесс импорта может быть неприемлемо долгим. Data Pump в 12.2 позволяет частично обойти это ограничение и загружать данные из нескольких разделов одновременно в следующих случаях:
В 12.2 появился новый механизм импорта файлов TTS. Новый параметр утилиты импорта — REMAP_DIRECTORY изменяет расположение исходного местонахождение файлов в новое во всех конструкциях SQL типа:
12.1:
$ impdp ... TRANSPORT_DATAFILES= '/dir1/f1.dbf','/dir1/f2.dbf','/dir1/f3.dbf'
12.2:
$ impdp ... REMAP_DIRECTORY='''/dir1/':'/dir2/'''
Безусловно полезная опция импорта по сети получила новый функционал — выбор и определения метода доступа к данных. Данная возможность определяется параметром ACCESS_METHOD, который может принимать следующие значения:
Пример использования:
$ impdp … TABLES=hr.employees NETWORK_LINK=dblink1 ACCESS_METHOD=DIRECT_PATH DATA_OPTIONS=ENABLE_NETWORK_COMPRESSION
Продолжение рассказа о нововведениях Oracle Database 12 r2 — в следующем номере журнала FORS Magazine.