Основные нововведения Oracle 12 R2: Рывок вперед или эволюция?
Докучаев Дмитрий
Руководитель Центра Компетенции по базам данных УКЦ ФОРС
OCP
Основные нововведения Oracle 12 R2: Рывок вперед или эволюция?
Уважаемые коллеги и друзья!Уже несколько месяцев прошло с тех пор, как мы смогли впервые скачать такой долгожданный релиз 12.2. Это достаточный срок, чтобы ознакомиться с новым продуктом, протестировать его работу как в тестовом, так и (смельчаки всегда найдутся) в боевом окружении. Возможно, протестировать свое приложение или написать новое, увидеть разницу в планах запросов, обжечься на багах и применить новые патчи, наконец!
Да мало ли что бывает в нашей работе!
И это – достаточный срок, чтобы составить свое определенное мнение, основанное не на отзывах в форумах и статьях в известных (и не очень) журналах с разной степенью аффилированности, но на собственном опыте и опыте коллег, мнению которых я за годы работе в Форсе привык доверять.
И, кстати, меня, как специалиста, такая привычка еще никогда не подводила!
Oracle Database 12.2 представляет существенный апгрейд мультиарендной архитектуры БД, а также новый подход к процессингу информации ресурсами оперативной памяти. Нововведения предназначены для оптимизации ключевых рабочих нагрузок и их главных характеристик: производительности, безопасности и т.д. Общее число нововведений во втором релизе 12-й версии Oracle составляет около 300 различных усовершенствований буквально по всем важным направлениям работы.
Теперь, когда лирическое отcтупление завершено, перейдем к более подробному рассмотрению основной темы данной статьи – обзору основных нововведений Oracle database 12 R2.
Нововведения в Multitenant Container Database Architecture
1. Application Container
В Oracle Database 12.2 введено концептуально новое понятие - Application Container. Oracle семимильными шагами, причём довольно успешными, движется дальше по пути консолидации и претворения в жизнь облачных решений.Представлена концепция контейнеров приложений, которая предлагает возможность иметь одно логическое определение для одного или нескольких приложений.
Каждый Application Container, по аналогии с CDB, имеет свой Application Root и Application Seed PDB, которые разделяют свои ресурсы среди PDB, содержащихся в этом контейнере. Подробнее про нововведения в контейнерных базах можно прочитать в нашей статье (ссылка)
2. Локальное UNDO в контейнерных БД
Интересное нововведение – возможность использования каждой подключенной базой своего локального UNDO. При этом, редологи, конечно, остаются общими для всех PDB в контейнере.
Параметр инициализации, отвечающий за SHARED или LOCAL UNDO - LOCAL_UNDO_ENABLED, его значение по-умолчанию – FALSE.
В случае перевода параметра в TRUE, каждый контейнер в БД должен использовать локальный UNDO
Для чего это нужно? Эта опция существенно облегчает горячее клонирование CDB и обеспечивает нулевое время простоя при переносе контейнеров.
Процесс перевода на использование локальных UNDO выглядит так:
SQL> STARTUP UPGRADE
SQL> ALTER DATABASE LOCAL UNDO ON;
3. Recovery и flashback контейнерных БД
Полезные нововведения появились и по части восстанавливаемости и 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, а только изменяет связанную с ней запись в общем контрольном файле!
Новое в управлении производительностью (Performance ) CDB и PDB
1. AWR и ADDM
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;
1. Появилась возможность использовать 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
1. Индивидуальное управление памятью для подключенных баз
Пожалуй, самое важное нововведение в аспекте управления ресурсами – локальное управление памятью для каждой подключенной PDB.
До 12.2 мы никаким явным образом не могли заставить подключенные базы ограничивать использование областей памяти.
Единственный метод как-то ограничить ресурсы каждой PDB был Resource Manager, при использовании которого можно было изменить максимумы и доли используемых ресурсов внутри контейнера путем ограничения использования процессора.
Также была возможность регулировать I/O на уровне CDB, но этот функционал был доступен только для Exadata (до 12.2)
( В новой версии БД появились параметры:
· MAX_IOPS: Number of IOs issued per second
· MAX_MBPS: MB of IO issued per second)
Теперь чем нас действительно сильно порадовала 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
Новые привилегии и опции профилей.
1. SYSRAC
Наряду с появившимися в Oracle Database 12.1 новыми системными привилегиями SYSBACKUP, SYSDG и SYSKM, призванными разграничить, в целях безопасности, административные полномочия, в 12.2 введена новая системная привилегия SYSRAC для управления кластером
Привилегия SYSRAC
• Не поддерживается файлом паролей
• Используется только CRS oraagent
Например:
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 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 LISTENER_NETWORKS SELECT X$ tables, V$ / GV$ views EXECUTE dbms_service dbms_service_prvt dbms_session
dbms_ha_alerts_prvt
|
2. Файл паролей
Наконец-то претерпел изменения файл паролей! Теперь он имеет другой формат и несет больше информации.
– Статус аккаунта OPEN, LOCKED EXPIRED
– Время последнего успешного логина
– Используемый метод аутентификации ( LDAP,OS,password file)
Соответственно, изменился синтаксис утилиты 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 также проверяет файл паролей на целостность
Нововведения в Data Redaction
Задача разделения доступа к данным в ИТ системах возникает всегда. Если доступ к базе данных возможен только из сервера приложений, то можно возложить эту обязанность на него. Но почти всегда есть потребность прямого доступа к данным, например для аналитиков и других привилегированных пользователей.
В 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 появилась возможность шифровать существующие табличные пространства.
.
· Пользовательские табличные пространства могут быть офлайн во время зашифровки.
· SYSTEM, SYSAUX, and UNDO – шифрование этих табличных пространств производится только на монтированной базе данных.
*Тут стоит заметить, что шифровать UNDO, если у нас зашифрованные данные в файлах бессмысленно, ибо попавшие в UNDO before-change данные уже будут зашифрованными!
**Можно создать зашифрованное Temporary табличное пространство, но зашифровать существующее – не получится!
Расширения RMAN, резервное копирование и восстановление.
1. Новые команды и расширения RMAN
Появилась возможность для обновления и удаления каталога восстановления одной командой:
RMAN> UPGRADE CATALOG NOPROMPT;
RMAN> DROP CATALOG NOPROMPT;
2. RESTORE and RECOVER
Команды RESTORE and RECOVER обычно идут последовательно, одна за другой, что, собственно говоря, логично.
Oracle Database 12.2 расширяет функционал команды RMAN REPAIR опциями DATAFILE, TABLESPACE, PLUGGABLE DATABASE and DATABASE и выполнением
RESTORE и RECOVER одной единой командой.
При этом, (если это возможно) REPAIR автоматически переводит файл данных в offline, извлекает из его бекапа (RESTORE), восстанавливает его (RECOVER) и потом переводит снова в состояние online!
Посмотрим на примере:
RMAN> REPAIR DATABASE;
RMAN> REPAIR PLUGGABLE DATABASE pdb1;
RMAN> REPAIR TABLESPACE example;
RMAN> REPAIR DATAFILE 12;
3. Неполное восстановление БД
Далее, появились интересные нововведения в операции неполного восстановления базы данных.
До 12.1 включительно, восстанавливая базу до последнего доступного архивного или редолога, мы могли пользоваться командой
RMAN> RECOVER DATABASE UNTIL CANCEL; (из SQL Plus или RMAN 12C)
После применения последнего доступного лога мы давали команду
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 лог файла (группы).
В случае же, если статус лог файла INACTIV, то у нас вообще практически нет проблем. Данных, необходимых для восстановления инстанса в нем нет, файл заархивирован.
В этой ситуации мы просто пересоздаем его с помощью команды:
SQL> alter database clear logfile '/FILE_PATH’;
и открываем базу без RESETLOGS.
SQL> alter database open;
Возвратимся к нашему утерянному ACTIVE лог файлу.
Так как у нас есть архивная копия, то мы можем, применив ее, «перескочить» в процессе восстановления через утерянный лог файл и закончить восстановления применением текущего (CURRENT) редолога.
Если не идти по этому пути, то процесс восстановления будет таким же, как и при потере CURRENT редо лога, то есть, восстановление из прошлого бэкапа и накат архивов и редо логов.
Кошмар любого администратора и его руководителя…
На большой базе, или при применении большого количества архивных логов время простоя может быть просто неприемлемым!
Поэтому поступаем таким образом:
1. Переходим в SQL Plus (На 12 RMAN возможно использование командной строки RMAN, так как команды SQL Plus больше не надо выделять соответствующей нотацией)
2. SQL> alter database recover until cancel;
3. SQL> alter database recover continue default;
Применяем архивные логи, причем последним применяется архивная копия нашего трагически потерянного ACTIVE редо!
4. SQL> alter database recover continue default;
5. Тут мы предсказуемо получаем ошибку ORA-00308: cannot open archived log. RMAN ищет следующий архивный журнал, но не находит, так как редолог CURRENT не заархивирован!
6. И тут мы немного «обманываем» Oracle, подсовывая вместо архива, которого в принципе нет и быть не может, текущий CURRENT редо лог:
SQL> alter database recover logfile '/CURRUNT REDO LOG FILE’;
7. SQL> alter database open resetlogs;
8. Все! (фанфары, туш)
Мы, проведя НЕПОЛНОЕ восстановление, ПОЛНОСТЬЮ восстановили базу (по последнюю закоммиченную транзакцию)
Уф….
4. Восстановления отдельных таблиц
Теперь вернемся, друзья, к нашей теме, к 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 автоматически проверяет наличие места на диске.
Читатели, кто попадал в подобные ситуации с нехваткой (как всегда, неожиданной) места, те поймут.
Если дискового пространства недостаточно, то сервер сразу сгенерит ошибку на уровне ОС и процесс восстановления просто не начнется.
5. DBMS_REDEFINITION
Значительные изменения, заслуживающие отдельной статьи, которая, безусловно будет опубликована в ближайшем номере ФОРС magazin, произошли с возможностью переопределения таблиц, в частности, с пакетом DBMS_REDEFINITION.
В частности, в процедуре START_REDEF_TABLE параметр enable_rollback, который позволяет откатить все изменения до запуска FINISH_REDEF_TABLE.
Процесс выглядит следующим образом:
1. Проверяем, может ли таблица быть переопределена онлайн.
2. Создается промежуточная таблица.
3. Стартуем процесс переопределения (redefinition)
4. Завершаем процесс:
Откатываем изменения или применяем их:
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, SQL*Loader и внешних таблицах.
1. Expdp и impdp
Oracle Data Pump в версии 12.1 базы данных Oracle поддерживает параллельный экспорт и импорт табличных данных, но обработка метаданных при этом производится одним процессов.
Data Pump в 12.2 сокращает время выгрузки и загрузки метаданных путем параллельного запуска нескольких фоновых процессов. Это новое усовершенствование позволяет ускорить процесс миграции больших баз данных. Параллельный экспорт и импорт метаданных активируется заданием параметра PARALLEL:
$ expdp … PARALLEL = n
При миграции таблицы, DBA иногда предварительно создает таблицу перед переносом ее данных, т. к. новая таблица может иметь новые атрибуты (например, сжатие) или другой вид партиционирования.
Импорт данные таблицы из секционированной таблицы в новую идет последовательно, по одной партиции за раз, потому что измененная структура новой таблицы может вызвать появление строк из одной экспортируемой партиции исходной таблички в нескольких партициях целевой.
Если же партиций много (не такой уж редкий случай на практике), то процесс импорта может быть неприемлемо долгим. Data Pump в 12.2 позволяет частично обойти это ограничение и загружать данные из нескольких разделов одновременно в следующих случаях:
· Если экспортируемые и импортируемые таблицы имеют тот же метод партиционирования и партиции поименованы одинаково.
· Если экспортируемые таблицы данных во всех секциях рассматривается как единое целое, т. е., импортируются параллельно с помощью конструкции INSERT AS SELECT.
2. Переименование файлов данных при использовании перемещаемых табличных
В 12.2 появился новый механизм импорта файлов TTS.
Новый параметр утилиты импорта - REMAP_DIRECTORY изменяет расположение исходного местонахождение файлов в новое во всех конструкциях SQL типа:
· CREATE TABLESPACE
· CREATE LIBRARY
· CREATE DIRECTORY
12.1 $ impdp…TRANSPORT_DATAFILES= '/dir1/f1.dbf','/dir1/f2.dbf','/dir1/f3.dbf'
12.2 $ impdp … REMAP_DIRECTORY='''/dir1/':'/dir2/'''
3. Импорт по сети
Безусловно полезная опция импорта по сети получила новый функционал – выбор и определения метода доступа к данных.
Данная возможность определяется параметром ACCESS_METHOD, который может принимать следующие значения:
· DIRECT_PATH: (теперь можно импортировать таблицы со столбцами с типом данных LONG)
· INSERT_AS_SELECT
· AUTOMATIC
Пример использования:
$ impdp … TABLES=hr.employees
NETWORK_LINK=dblink1 ACCESS_METHOD=DIRECT_PATH
DATA_OPTIONS=ENABLE_NETWORK_COMPRESSION
Докучаев Дмитрий 2017г.
-------------------------------- - - -----------------------------------
Продолжение рассказа о нововведениях Oracle Database 12 r2 – в следующем номере журнала FORS MAGAZIN
