Oracle OCP: Oracle Database 12c Administrator Certified Professional Study Guide

Oracle OCP Краткое пособие по подготовке к экзамену 1Z0-060

И. Гавриков

И.С. Гавриков, к.ф.-м.н., Oracle OCP 10g, 11g, 12c, HP HP-UX CSA, CSE e-mail: [email protected] Условия и ограничения использования Copyright 2015. И. Гавриков. Никакая часть данной публикации не может быть распространена, занесена в публичные или частные базы, или системы хранения/восстановления текстов/изображений, или сохранена в любой форме любыми средствами без письменного разрешения автора. Oracle, Solaris, Oracle Solaris являются зарегистрированными марками Oracle Corporation и/или филиалов компании Oracle. HP, HP-UX являются зарегистрированной маркой Hewlett-Packard Development Company, L.P. и/или филиалов компании Hewlett-Packard Development Company, L.P. Информация, содержащаяся в данной публикации, взята автором из источников, которые считаются надежными. Однако, в силу человеческих и/или механических ошибок источников, автора и/или других сторон, автор не гарантирует точности, адекватности или полноты любой информации, включенной в данную публикацию, и не несет какой-либо ответственности за любые ошибки или упущения или результаты, полученные в результате использования данной информации.

2

О чем хотел сказать автор............................................................................................................................... 10 Дополнительные источники знаний .......................................................................................................... 10 Новые возможности СУБД Oracle 12c ............................................................................................................ 11 Утилита Enterprise Manager Express ........................................................................................................... 11 Использование Enterprise Manager Express .......................................................................................... 11 Настойка порта для EM Express .............................................................................................................. 14 Использование ассистентов OUI, DBCA для установки и настройки базы данных ................................ 15 Ассистент создания базы данных (Database Create Assistant (DBCA)) ................................................ 30 Введение в модель арендованной контейнерной базы данных (Multitenant Container Database (CBD)) ............................................................................................................................................................ 36 Преимущества контейнерной базы данных ......................................................................................... 36 Описание арендной архитектуры .......................................................................................................... 37 Создание и настройка контейнерной базы данных и перемещаемых баз данных .......................... 37 Создание и настройка контейнерной БД (CDB) ................................................................................ 37 Создание и настройка перемещаемой БД (PDB) .............................................................................. 39 Создание перемещаемой БД из seed ............................................................................................ 40 Клонирование перемещаемой БД ................................................................................................. 40 Включение извлеченной перемещаемой БД в контейнерную БД ............................................. 41 Создание перемещаемой БД на основе монолитной ................................................................. 41 Удаление перемещаемой базы данных ........................................................................................ 42 Преобразование монолитной базы Oracle данных в перемещаемую базу данных ................. 42 Управление контейнерными и перемещаемыми базами данных ..................................................... 43 Запуск и остановка контейнерной (CDB)/перемещаемой (PDB) базы данных .................................. 45 Изменение параметров экземпляра для контейнерной (CDB) или перемещаемой (PDB) БД......... 47 Управление табличными пространствами, общими и локальными пользователями, привилегиями и ролями ......................................................................................................................... 48 Управление табличными пространствами контейнерной (CDB) или перемещаемой (PDB) БД .. 48 Управление пользователями и привилегиями в контейнерной (CDB) или перемещаемой (PDB) БД .......................................................................................................................................................... 49 Создание общего пользователя ................................................................................................. 49 Создание локального пользователя .......................................................................................... 50 3

Привилегии общих и локальных пользователей ...................................................................... 50 Резервное копирование, восстановление и ретроспективный откат для контейнерной и перемещаемой БД ...................................................................................................................................... 52 Выполнение резервного копирования контейнерной или перемещаемой БД ................................ 52 Восстановление контейнерной или перемещаемой БД...................................................................... 53 Выполнение ретроспективного отката на контейнерной базе данных ............................................. 55 Управление жизненным циклом информации и оптимизация работы с дисковой памятью ............. 57 Использование управления жизненным циклом информации (Information Lifecycle Management, ILM) ........................................................................................................................................................... 57 Горячая карта (Heat Map) .................................................................................................................... 57 Автоматическая оптимизация данных (Automatic Data Optimization, ADO) .................................. 57 Выполнение отслеживания изменений и автоматизированное размещение данных ................ 57 Перенос файлов данных online .................................................................................................................. 60 Внутреннее архивирование (In-Database Archiving) и временная актуальность данных (Valid-Time Temporal) ...................................................................................................................................................... 61 Различие между управлением жизненным циклом информации (Information Lifecycle Management, ILM) и временной актуальностью................................................................................... 61 Установка и использование временной актуальности ........................................................................ 62 Работа с внутренним архивированием строк (In-Database archiving) ................................................. 65 Аудит............................................................................................................................................................. 66 Включение и настройка унифицированного аудита ............................................................................ 66 Запрет унифицированного аудита ......................................................................................................... 67 Создание и включение политик аудита ................................................................................................ 70 Привилегии .................................................................................................................................................. 73 Использование административных привилегий .................................................................................. 73 Создание, разрешение и анализ использования привилегий ............................................................ 75 Редактирование (redaction) данных Oracle ............................................................................................... 77 Применение и управления политиками редактирования данных Oracle.......................................... 77 RMAN и ретроспективный архив данных .................................................................................................. 81 Применение расширений RMAN ........................................................................................................... 81 Восстановление отдельных таблиц из резервных копий ................................................................ 81 Интерфейс командной строки RMAN ................................................................................................ 81 Дупликация активной базы данных................................................................................................... 81 Опция NOOPEN для дупликации ........................................................................................................ 81 4

Многосекционные копии образа (Multisection Image Copies)......................................................... 82 Многосекционные инкрементальные резервные наборы ............................................................. 82 Оптимизация моментального снимка дисковой памяти (Storage Snapshot Optimization) ........... 82 Новые возможности ретроспективных архивов (Flashback Data Archive) .............................................. 83 Отслеживание операций базы данных в реальном времени ................................................................. 84 Реализация отслеживания операций базы данных в реальном времени ......................................... 84 Настройка SQL .............................................................................................................................................. 87 Использование адаптивных планов выполнения ................................................................................ 87 Адаптивные планы .............................................................................................................................. 87 Адаптивные статистики ....................................................................................................................... 88 Использование расширенных возможностей сбора статистики......................................................... 89 Конкурентные статистики ................................................................................................................... 90 Автоматическое определение групп столбцов (Automatic column group detection) .................... 90 Использование управления адаптивными SQL планами.................................................................... 91 Аварийный контроль (Emergency Monitoring), контроль реального времени (Real-Time ADDM), сравнительный контроль (Compare Period ADDM) и анализ истории активных сессий (ASH Analytics) ....................................................................................................................................................................... 93 Выполнение аварийного контроля и контроля реального времени .................................................. 93 ADDM реального времени .................................................................................................................. 94 Создание сравнительного отчета ADDM по периоду............................................................................... 96 Диагностика проблем производительности с использованием новых возможностей ASH ................ 97 Менеджер ресурсов и другие расширения контроля производительности ......................................... 98 Использование менеджера ресурсов для контейнерной и подключаемых баз данных ................. 98 Различие между мультипроцессной и многопотоковой архитектурой в Oracle ................................... 99 Использование флэш кэша (flash cache) .................................................................................................. 100 Расширенные возможности при работе с индексами и таблицами .................................................... 101 Применение расширенных возможностей работы с индексами ..................................................... 101 Применение расширенных возможностей работы с таблицами ..................................................... 102 Применение расширенных возможностей online операций ............................................................ 103 Улучшения программы диагностики ADR (Automatic Diagnostic Repository) ....................................... 105 Описание улучшений ADR .................................................................................................................... 105 Журнал отладки (Debug Log) ................................................................................................................ 105 Улучшения Oracle Data Pump, SQL*Loader, External Tables Online операций ....................................... 106 Обзор улучшений Oracle Data Pump .................................................................................................... 106 5

Применение расширенных возможностей загрузчика SQL*Loader и внешних таблиц.................. 109 Возможности "прямого" NFS (Direct NFS) ............................................................................................ 110 Расширенные возможности секционирования ...................................................................................... 111 Обзор расширенных возможностей секционирования ..................................................................... 111 Секционирование по ссылочному интервалу (interval-reference) ................................................ 111 Операции множественного обслуживания секций таблиц ........................................................... 111 Каскадная функциональность (Cascade Functionality) .................................................................... 113 Перемещение секций "на ходу"....................................................................................................... 113 Расширенные возможности индексирования для секционированных таблиц .................................. 114 Асинхронное обслуживание индексов................................................................................................ 114 Частичные индексы (partial indexes) .................................................................................................... 114 ONLINE перемещение секций .............................................................................................................. 115 Улучшения в SQL ........................................................................................................................................ 116 Настройка расширенных типов данных .............................................................................................. 116 Применение ограничений количества строк в выборке (Top-N SQL запросы) ................................ 116 Безопасные файлы (Secure Files) .......................................................................................................... 117 Применение Oracle Database Migration Assistant для преобразования в Unicode .......................... 118 Ключевые навыки администратора базы данных ...................................................................................... 120 Основы администрирования .................................................................................................................... 120 Общие замечания об администрировании ........................................................................................ 120 Основы архитектуры базы данных ...................................................................................................... 121 Понятия "база данных" и "экземпляр" ............................................................................................ 121 Системная глобальная область System Global Area (SGA) .......................................................... 123 Установка и начальная настройка базы данных ..................................................................................... 125 Настройка сетевой поддержки для сервера и клиента базы данных .................................................. 130 Метод локальных имен (Local Naming Method) ................................................................................. 132 Метод простого соединения (Easy Connect Naming Method) ............................................................ 132 Метод службы каталога (Directory Naming Method) .......................................................................... 133 Метод внешних имен (External Naming Methods) .............................................................................. 133 Отслеживание оповещений базы данных .............................................................................................. 134 Адаптивные пороги (Adaptive Thresholds)........................................................................................... 134 Выполнение ежедневного сопровождения базы данных ..................................................................... 135 Установка и анализ исправлений............................................................................................................. 137 6

Online исправления ............................................................................................................................... 137 Центр управления EM Cloud Control и обновления............................................................................ 138 Запросы к каталогу исправлений ......................................................................................................... 139 Резервное копирование и восстановление базы данных ..................................................................... 141 Создание резервных копий .................................................................................................................. 144 Инкрементальные резервные копии................................................................................................... 145 Отслеживание изменения блоков (Block Change Tracking)................................................................ 145 Восстановление файлов базы данных ................................................................................................. 146 Диагностирование сетевых проблем и проблем базы данных. ........................................................... 148 Обнаружение и восстановление сбоев данных с помощью Data Recovery Advisor ............................ 150 Сбои ........................................................................................................................................................ 150 Восстановление с помощью Data Recovery Advisor ............................................................................ 151 LIST FAILURE ........................................................................................................................................ 151 ADVISE FAILURE................................................................................................................................... 151 CHANGE FAILURE ................................................................................................................................ 152 REPAIR FAILURE ................................................................................................................................... 152 Реализация технологии ретроспективного отката ................................................................................. 153 Ретроспективный откат таблиц ............................................................................................................ 153 Ретроспективные версионные запросы .............................................................................................. 153 Запросы ретроспективных транзакций ............................................................................................... 155 Ретроспективный откат базы данных .................................................................................................. 156 Загрузка и выгрузка данных ..................................................................................................................... 159 Обслуживание заданий Data Pump...................................................................................................... 159 Параметры expdp .............................................................................................................................. 161 Параметры impdp .............................................................................................................................. 162 Сетевые операции Data Pump .......................................................................................................... 163 SQL-Loader .............................................................................................................................................. 163 Перемещение объектов из пространства SYSAUX .................................................................................. 166 Создание постоянного табличного пространства "по умолчанию" ...................................................... 167 Использование консультанта для определения размеров журналов повторов (redo) ...................... 168 Применение безопасных файлов для хранения данных LOB ............................................................... 169 Применение прямого NFS клиента .......................................................................................................... 171 Управление производительностью ......................................................................................................... 172 7

Проектирование размещения базы данных ........................................................................................... 172 Контроль производительности ................................................................................................................ 173 Управление памятью................................................................................................................................. 176 Автоматическое управление разделяемой памятью (Automatic Shared Memory Management) ... 177 Буферный кэш ........................................................................................................................................ 177 Выявление и анализ проблем производительности.............................................................................. 179 Проведение реального тестирования приложений. .............................................................................. 182 SQL Performance Analyzer ...................................................................................................................... 182 Используемые представления словаря данных ................................................................................. 182 Последовательность действия при анализе изменения производительности ............................... 183 Повтор выполнения базы данных ........................................................................................................ 184 Применение ресурсного менеджера для управления распределением ресурсов ............................ 186 Директивы ресурсного плана ............................................................................................................... 186 Ограничения сессий по вводу/выводу или потреблению циклов процессора ............................... 187 Замечания по настройке производительности ...................................................................................... 188 Дисковая память ........................................................................................................................................ 189 Управление объектами базы данных .................................................................................................. 189 Табличные пространства (Tablespaces) ........................................................................................... 190 Управление табличным пространством отката (Undo) .................................................................. 190 Группы журналов повторов (Redo Log Groups) ............................................................................... 191 Архивные журналы (Archive Logs) .................................................................................................... 191 Управляющие файлы (Control Files) ................................................................................................. 192 Управляемые Oracle файлы .............................................................................................................. 192 Администрирование ASM ..................................................................................................................... 194 Полностью квалифицированная форма имен файлов................................................................... 195 Алиасы имен файлов......................................................................................................................... 196 Управление дисками ASM и дисковыми группами ........................................................................ 197 Атрибуты дисковых групп ............................................................................................................. 197 Создание дисковой группы .......................................................................................................... 198 Модификация дисковой группы .................................................................................................. 199 Управление экземпляром ASM ........................................................................................................ 200 Остановка экземпляра ASM .......................................................................................................... 201 Управление очень большими данными (VLDB) .................................................................................. 203 8

Общие замечания .............................................................................................................................. 203 Методы секционирования................................................................................................................ 203 Одноуровневое секционирование .............................................................................................. 203 Композитное секционирование................................................................................................... 204 Управление табличным пространством .............................................................................................. 205 Базовая компрессия таблиц (Basic Table Compression) .................................................................. 206 Расширенная строковая компрессия (Advanced Row Compression) ............................................. 206 Гибридное колоночное сжатие (Hybrid Columnar Compression) ................................................... 206 Сжатие сегментов (Segment Shrink) ................................................................................................. 207 Запуск сжатия динамического сжатия сегментов ...................................................................... 207 Примеры......................................................................................................................................... 208 Безопасность .............................................................................................................................................. 209 Разработка и внедрение политики безопасности .............................................................................. 209 Пользователи ..................................................................................................................................... 209 Привилегии и роли ............................................................................................................................ 209 Аудит ................................................................................................................................................... 210 Настройка и управление аудитом........................................................................................................ 211 Создание файла паролей ...................................................................................................................... 213 Шифрование столбцов и табличных пространств .............................................................................. 215 Шифрование столбцов ...................................................................................................................... 217 Шифрование табличных пространств .............................................................................................. 217 Словарь........................................................................................................................................................... 219

9

О чем хотел сказать автор Вначале несколько "не". Эта книга не заменяет курс "Oracle Database 12c: New Features for Administrators", читаемый в Oracle University. Эта книга не содержит списка вопросов, которые могут быть заданы на реальном экзамене 1Z0-060, но содержит ответы на них. В этом пособии содержится описание а) основных изменений, сделанных в СУБД Oracle версии 12с по сравнению с 11g; и б) основных навыков администратора СУБД, которые могут пригодиться как для сдачи экзамена 1Z0-060, так и в повседневной работе. В упомянутом курсе Oracle University раскрываются специфические возможности релиза 12с. В данном руководстве несколько глав посвящено существенно более широким темам, например, повседневным обязанностям администратора СУБД (DBA). Потенциальный круг вопросов по данной тематике может быть очень широким. В Oracle считают, и в этом автор полностью согласен с ними, что люди, сдающие экзамен 1Z0-060, работали или работают в качестве DBA и знают большую часть этих тем на практике. Если это не так, то нужно запланировать достаточное время для работы с реальной базой данных.

Дополнительные источники знаний Основными источниками информации по подготовке к экзамену являются: документация Oracle http://docs.oracle.com/ книги независимых авторов т.н. White papers и статьи на Oracle Learning Library Материалы Oracle Learning Library являются наиболее полными и точными, т.к. созданы специалистами Oracle и проверены значительным количеством сторонних лиц. При подготовке к экзамену желательно использовать несколько источников учебных материалов. Разные точки зрения помогут составить более полное представление о рассматриваемой теме, что, несомненно, поможет пониманию работы СУБД Oracle.

10

Новые возможности СУБД Oracle 12c Утилита Enterprise Manager Express Использование Enterprise Manager Express Enterprise Manager Express это утилита, предназначенная для управления базой данных (БД) Oracle с использованием интернет-браузера. Она встроена в БД и позволяет отслеживать, управлять производительностью БД и также выполнять некоторые общие административные функции. С помощью веб-интерфейса можно просматривать, создавать и изменять различные объекты базы данных. Утилита EM Express спроектирована, как легковесное приложение, оказывающее незначительное воздействие на производительность. С EM Express не связаны какие-либо фоновые процессы и задачи. При работе она использует только внутренние компоненты БД, такие как XDB и SQL*Net и данные, собранные существующими процессами Oracle. EM Express запрашивает данные с сервера базы данных только при работе пользователя с веб-интерфейсом. Запрошенная информация обрабатывается внутри интернет-браузера, что минимизирует нагрузку на сервер базы данных. Утилита EM Express не может функционировать без базы данных, поэтому EM Express не может выполнять любые действия вне ее, в частности осуществить запуск или остановку экземпляра. Следует сказать, что, поскольку EM Express использует Shockwave Flash (SWF) файлы, то используемый браузер должен поддерживать Flash plug-in. EM Express доступен через ссылку, выдаваемую ассистентом DBCA при создании базы данных:

Рис. 1 Сообщение об успешном создании БД. Ссылка на EM Express

Если неизвестно, какой порт был назначен для EM Express ("по умолчанию" используется 5500/tcp), то порт можно определить с помощью следующего SQL-запроса: 11

SQL> SELECT DBMS_XDB_CONFIG.GETHTTPSPORT() FROM dual; DBMS_XDB_CONFIG.GETHTTPSPORT() -----------------------------5500

Ссылка на EM Express будет выглядеть так: https://database-hostname:portnumber/em/ Например: https://ora-1123:5500/em/ или https://192.168.150.196:5500/em/ Если экземпляр БД и прослушиватель запущены, то по указанному адресу в браузере откроется начальная страница EM Express. Если база данных неактивна, то нужно запустить ее до попытки зайти в EM Express. Зарегистрироваться в EM Express можно с использованием учетной записи, имеющей достаточный уровень полномочий, а именно, обладающей одной из ролей EM_EXPRESS_BASIC или EM_EXPRESS_ALL. Первоначально такими пользователями являются SYS и SYSTEM. В реальной работе использование учетной записи SYS нежелательно. В место этого для администрирования БД рекомендуется создать отдельную учетную запись, заменяющую SYS или SYSTEM, и присвоить этой учетной записи роль EM_EXPRESS_BASIC или EM_EXPRESS_ALL. При входе в EM Express будет отображена страница приглашения:

Рис. 2 Регистрация в EM Database Express 12c

12

После регистрации открывается домашняя страница EM Express. На этой странице отображается общее состояние БД и текущая активность. Административные задачи, доступные в Enterprise Manager Express, сгруппированы в четыре меню в верхней части страницы: Настройка (Configuration) - EM Express позволяет менять инициализационные параметры базы данных. На странице показано текущее распределение памяти и список 10 процессов с максимальным потреблением памяти. Администратор может также посмотреть список используемых опций и свойства БД. Дисковая Память (Storage) - Функции администрирования дисковой памятью позволяют DBA управлять redo-журналами (журналы повторов), архивными журналами и табличными пространствами. Имеется возможность запустить консультант (advisor) по UNDO пространству (пространство отката) и статистике. EM Express также отображает информацию от содержании управляющего файла. Безопасность (Secirity) - Меню безопасности EM Express позволяет DBA создавать и изменять пользователей, роли, профили, выдавать и отзывать привилегии. Производительность (Performance) - Центр производительности EM Express отображает информацию о производительности БД за определенный период. Отображаемая информация включает SQL Monitor, ASH Analytics (анализ истории активных сессий) и ADDM (Automatic Database Diagnostic Monitor). Центр производительности также включает в себя набор метрик, описывающих характеристики нагрузки и использование ресурсов базы данных.

Рис. 3 Домашняя страница базы данных EM Express

13

Настойка порта для EM Express При необходимости порт EM Express может быть изменен. Каждый экземпляр БД на данном сервере должен иметь уникальный порт. Если порт не был настроен, то доступ к EM Express невозможен. Для настройки порта нужно выполнить несколько шагов: 1. Нужно проверить, что Oracle Net Listener уже настроен и запущен. Для запуска, остановки и проверки состояния прослушивателя нужно использовать утилиту lsnrctl. 2. Если прослушиватель запущен на порту, отличном от порта "по умолчанию", 1521, то файл init.ora базы данных, которая будет управляться EM Express, должен содержать параметр local_listener. Параметр local_listener должен ссылаться на параметр в TNSNAMES, указывающий на корректный прослушиватель. Например, запись local_listener=orcl будет необходима для экземпляра, определенного в файле TNSNAMES.ORA с нестандартным портом 1527: orcl= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp)(HOST=ora-1123)(PORT=1527) ) (CONNECT_DATA= (SERVICE_NAME=orcl)(SERVER=DEDICATED) ) )

Диспетчер TCP должен быть включен. Для этого нужно добавить запись в файл init.ora для управляемой EM Express базы данных dispatchers="(PROTOCOL=TCP)(SERVICE=XDB)"

3. Базу данных необходимо перезапустить, чтобы изменения в init.ora стали активными 4. С помощью PL/SQL процедуры DBMS_XDB_CONFIG.SETHTTPSPORT следует назначить порт HTTPS для EM Express. Эта процедура изменит значение порта HTTPS в файле xdbconfig.xml из Oracle XML DB Repository. Для выполнения этих действия необходимо подключиться к БД с привилегией SYSDBA. В следующем примере устанавливается порт 5600 для EM Express: SQL> exec DBMS_XDB_CONFIG.SETHTTPSPORT(5600);

Следует отметить что, если вызов SETHTTPSPOST производился при запущенном процессе прослушивателя, то некоторое время EM Express будет доступен как на старом, так на новом порту. Если такое поведение является неприемлемым, то нужно перед вызовом функции остановить процесс прослушивания, произвести замену порта и запустить процесс прослушивания. Для получения большей информации о EM Express необходимо обратиться к документу Oracle "Database 2 Day DBA" и крайне полезно установить СУБД Oracle 12c, чтобы более подробно ознакомиться с EM Express. Проверить успешность смены порта можно с помощью команды lsnrctl status (на рисунке выделен фрагмент с описанием сервиса EM Express, зарегистрированного на нужном порту):

14

Рис. 4 Информация о порте EM Database Express 12c

Использование ассистентов OUI, DBCA для установки и настройки базы данных Установка СУБД Oracle обоснованно считается действием, требующим понимания специфики операционной системы (ОС). Даже при наличии опыта успешных установок для используемой ОС рекомендуется ознакомиться с соответствующим руководством. В данной главе описан опыт установки Oracle 12c на Oracle Solaris 10 (SPARC). Для установки файлов программного обеспечения СУБД для Solaris 10 (SPARC) нужно выделить следующий объем дискового пространства: Издание СУБД Oracle 12c Enterprise Edition Standard Edition Standard Edition One

Требуемый размер дискового пространства, GB 6.1 5.9 5.9

Дополнительно требуется также 1GB свободной памяти в директории /tmp. Сервер, на котором будет функционировать база данных, должен иметь не менее 2 GB оперативной памяти и соответствующее количество памяти swap'а: Оперативная память сервера(RAM), GB 1-2 2 - 16 > 16

Пространство swap 1.5 размера оперативной памяти (RAM) равно размеру оперативной памяти 16GB 15

Если выполнены эти базовые требования, то можно перейти к анализу дополнительных требований к ресурсам. Проводить установку можно только после выполнения всех требований к параметрам ОС, описанных в руководстве по установке (Oracle® Database Installation Guide 12c Release 1 (12.1) for Oracle Solaris документ № E17752-12). Подготовка ОС Solaris 10 для установки ПО Oracle включает следующие основные действия: В файл /etc/system необходимо добавить следующие параметры ядра (см. также http://docs.oracle.com/cd/E19076-01/t2k.srvr/819-2544-21/prod-note-general.html) и перегрузить сервер. bash-3.2# more /etc/system *ident "@(#)system 1.18 05/06/27 SMI" /* SVR4 1.5 */ * * SYSTEM SPECIFICATION FILE . . set pcie:pcie_aer_ce_mask=0x1 set segkmem_lpsize=0x400000

В файл /etc/inittab необходимо добавить строки для настройки стека tcp/ip: tm::sysinit:/usr/sbin/ndd tm::sysinit:/usr/sbin/ndd tm::sysinit:/usr/sbin/ndd tm::sysinit:/usr/sbin/ndd

-set -set -set -set

/dev/tcp /dev/tcp /dev/udp /dev/udp

tcp_smallest_anon_port 9000 tcp_largest_anon_port 65500 udp_smallest_anon_port 9000 udp_largest_anon_port 65500

> > > >

/dev/console /dev/console /dev/console /dev/console

Нужно модифицировать профиль пользователя root, а именно снять ограничения "по умолчанию": projmod -s \ -K "process.max-file-descriptor=(basic,65536,deny),(priv,65536,deny)" \ -K "process.max-sem-nsems=(priv,2048,deny)" \ -K "project.max-sem-ids=(priv,1024,deny)" \ -K "project.max-shm-ids=(priv,256,deny)" \ -K "project.max-shm-memory=(priv,18446744073709551615,deny)" \ user.root

Требуется создать группы операционной системы: # groupadd oinstall # groupadd dba

Требуется создать пользователя-владельца инсталляции СУБД: # /usr/sbin/useradd -g oinstall -G dba –s /bin/bash -d /home/oracle \ -m -k /etc/skel oracle

16

Рекомендуется установить bash в качестве рабочей среды для владельца инсталляции Oracle, поскольку часть скриптов, содержащихся в инсталляционных пакетах не работает корректно под оболочкой Bourne. Требуется создать профиль пользователя oracle: projadd -p 200 -c "Oracle user" -U oracle \ -G dba,oinstall \ -K "process.max-file-descriptor=(basic,65536,deny),(priv,65536,deny)" \ -K "process.max-sem-nsems=(priv,2048,deny)" \ -K "project.max-sem-ids=(priv,1024,deny)" \ -K "project.max-shm-ids=(priv,256,deny)" \ -K "project.max-shm-memory=(priv,18446744073709551615,deny)" \ oracle.user

Нужно добавить следующую строку в файл /etc/user_attr oracle::::project=oracle.user

чтобы привести файл в следующий вид: bash-3.2# cat /etc/user_attr # # Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # /etc/user_attr # # execution attributes for profiles. see user_attr(4) # #ident "@(#)user_attr 1.1 07/01/31 SMI" # # adm::::profiles=Log Management lp::::profiles=Printer Management postgres::::type=role;profiles=Postgres Administration,All root::::auths=solaris.*,solaris.grant;profiles=Web Console Management,All;lock_after_retries=no;min_label=admin_low;clearance=admin_high oracle::::project=oracle.user bash-3.2#

Нужно убедиться, что у пользователя oracle установлен активный профиль oracle.user bash-3.2# su - oracle Oracle Corporation SunOS 5.10 Generic Patch January 2005 bash-3.2$ id -pa uid=100(oracle) gid=100(oinstall) groups=100(oinstall),101(dba) projid=200(oracle.user) bash-3.2$ logout

Необходимо создать начальную базовую структуру директорий # mkdir -p /u01/app/oracle

17

# chown oracle:oinstall /u01/app/oracle # chmod -R 775 /u01/

Дистрибутивы СУБД доступны на сайте Oracle после регистрации. Для 64-bit версии Oracle требуется выгрузить solaris.sparc64_12cR1_database_1of2.zip и solaris.sparc64_12cR1_database_2of2.zip в подходящую директорию, извлечь содержимое архивов с помощью программы unzip и запустить инсталлятор Oracle runInstaller. Для работы инсталлятора обязательно наличие графической среды. Если все требования по предварительной настройке ОС выполнены, то инсталлятор выведет экран "Configure Security Updates" установки. Шаг 1. "Configure Security Updates" - На этом экране необходимо ввести адрес почты, на который Oracle сможет присылать информацию о проблемах с безопасностью ПО базы данных. Дополнительно можно получать исправления и дополнения по безопасности с My Oracle Support.

Рис. 5 Установка ПО Oracle 12c. Экран 1

18

Шаг 2. Загрузить обновления программного обеспечения - При необходимости можно выгрузить обновления ПО с My Oracle Support. Для доступа нужна учетная запись и соответствующий уровень оплаченной поддержки. Дополнительно можно выбрать использование ранее полученных обновлений или вообще отказаться от них.

Рис. 6 Установка ПО Oracle 12c. Экран 2

19

Шаг 3. Опции установки - На этом шаге можно выбрать один из возможных типов установки СУБД: установку ПО и создание БД, просто установку ПО или модернизацию существующей базы данных

Рис. 7 Установка ПО Oracle 12c. Экран 3

20

Шаг 4. Grid опции установки - На этом шаге осуществляется выбор типа установки: установка обычной инстанции, узла кластера Oracle Real Application Cluster или одноузлового кластера Oracle RAC One Node.

Рис. 8 Установка ПО Oracle 12c. Экран 4

21

Шаг 5. Выбор языка - На экране осуществляется выбор дополнительных языков для БД. Рекомендуется выбирать все доступные.

Рис. 9 Установка ПО Oracle 12c. Экран 5

22

Шаг 6. Тип СУБД - На этом шаге вы обязаны выбрать один из типов редакции СУБД: Enterprise (база данных большого предприятия), Standard Edition (средние предприятия и большие отделы) и Standard Edition One

Рис. 10 Установка ПО Oracle 12c. Экран 6

23

Шаг 7. Определение пути установки. - На этом шаге выбирается местоположение ПО СУБД в файловой системе.

Рис. 11 Установка ПО Oracle 12c. Экран 7

24

Шаг 8. Создание inventory - На экране предлагается указать место хранения метаданных инсталляции, если ПО Oracle устанавливается первый раз, и группу операционной системы, владеющей данной директорией. Все последующие инсталляции ПО Oracle независимо от версий и типов будут использовать указанное место хранения.

Рис. 12 Установка ПО Oracle 12c. Экран 8

25

Шаг 9. Задание групп операционной системы - На шаге присваиваются привилегии БД существующим группам операционной системы.

Рис. 13 Установка ПО Oracle 12c. Экран 9

26

Шаг 10. Проверка соответствия. - Инсталлятор проверяет, что все параметры системы удовлетворяют требованиям ПО СУБД. Если проверка завершается неудачно, то список ошибок выводится на экран. Рекомендуется перед продолжением установки привести все параметры ОС в соответствие с требованиями Oracle. При нажатии клавиши ignore инсталлятор продолжит работу, несмотря на встретившиеся ошибки. Шаг 11. Сводка - Инсталлятор выводит итоговое сообщение обо всех опциях, выбранных ранее. На этом шаге можно изменить часть опций.

Рис. 14 Установка ПО Oracle 12c. Экран 11

27

Шаг 12. Установка продукта. - На этом шаге инсталлятор производит копирование файлов и другие инсталляционные задачи (линковку, задание полномочий, флагов выполнения и т.д.). Ход установки отображается в процентах выполнения и стадиях.

Рис. 15 Установка ПО Oracle 12c. Экран 12

28

Шаг 12а. root скрипты. - Завершающий шаг установки требует, чтобы два скрипта были запущены под суперпользователем root. Этот шаг специфичен для Unix-подобных систем.

Рис. 16 Установка ПО Oracle 12c. Выполнение root скриптов

29

Шаг 13. Завершение - Это то, к чему стремились!

Рис. 17 Установка ПО Oracle 12c. Завершение установки

Ассистент создания базы данных (Database Create Assistant (DBCA)) В ранних версиях Oracle действие "создание базы данных" означало выполнение команды CREATE DATABASE , которая делала все необходимые действия. Команда требовала введения массы параметров. Вряд ли кто-то сожалеет, что теперь можно обойтись без этого. Database Create Assistant (DBCA)) является существенно более простым средством создания базы данных. По завершении работы DBCA база данных готова к работе, тогда как база, созданная при помощи CREATE DATABASE, требует запуска нескольких скриптов прежде, чем работа с ней будет возможна! Утилита DBCA может быть запущена прямо из инсталлятора, или же она может быть запущена как отдельное приложение в любой момент после завершения установки ПО Oracle. DBCA работает в двух режимах: интерактивном и пакетном. Интерактивный режим использует графический интерфейс и проводит пользователя через несколько шагов создания и настройки БД. Пакетный режим позволяет создать БД с помощью скрипта. Утилита DBCA запускается в пакетном режиме при задании аргументов командной строки и файла ответов, либо аргументов и файла ответов. В главе описан только интерактивный режим.

30

Для запуска DBCA нужно зарегистрироваться на сервере БД под пользователем, имеющим права для создания и запуска БД. Для запуска DBCA на UNIX/Linux или в командной строке Microsoft Windows нужно ввести команду dbca. Исполняемый модуль dbca расположен в директории ORACLE_HOME/bin. После запуска DBCA нужно ответить на ряд вопросов о типе, размещении и планируемым параметрам базы данных и создать БД. Рассмотрим процедуру создания базы данных "по шагам". Шаг 1. Операции с БД. На этом шаге нужно выбрать одну из операций: создание базы данных, настройку или удаление базы данных (опции недоступны при отсутствии настроенных БД), настройку шаблонов создания БД или управление перемещаемыми (pluggable) БД (опция недоступна при отсутствии настроенных перемещаемых БД).

Рис. 18 Создание базы данных при помощи DBCA. Экран 1

31

Шаг 2. Режим создания БД. На этом шаге необходимо выбрать имя базы данных, тип дисковой памяти, расположение файлов и области быстрого восстановления (fast recovery area), используемый набор символов и пароль администратора БД. Если используется Enterprise версия также можно создать базу контейнерного типа. В расширенном (Advanced) режиме возможно задание много других параметров БД.

Рис. 19 Создание базы данных при помощи DBCA. Экран 2

32

Шаг 3. Проверка соответствия требованиям. - DBCA проверяет, что выполняются все необходимые условия для создания БД

Рис. 20 Создание базы данных при помощи DBCA. Экран 3

33

Шаг 4. Сводка - На этом экране показано, с какими параметрами будет создана БД в данный момент.

Рис. 21 Создание базы данных при помощи DBCA. Экран 4

34

Шаг 5. Процесс создания БД - На экране отображается процесс создания базы данных.

Рис. 22 Создание базы данных при помощи DBCA. Экран 5

Когда DBCA завершит свою работу, база данных будет полностью готова к использованию, т.е. можно подключаться к БД и создавать пользователей и объекты. После создания, смены версии БД или установки исправлений следует запустить скрипт utlrp.sql. Этот скрипт перекомпилирует все PL/SQL модули, включая пакеты, процедуры и триггеры, которые могут быть в недействительном состоянии. "По умолчанию" скрипт производит параллельную перекомпиляцию, основываясь на значении параметра CPU_COUNT. Этот шаг необязателен, но Oracle рекомендует сделать его сразу после создания базы данных, а не позднее.

35

Введение в модель арендованной контейнерной базы данных (Multitenant Container Database (CBD)) Преимущества контейнерной базы данных В версии Oracle 12c вводится принципиально новая архитектура - арендованная база данных (опция Multitenant Enterprise Edition). Новая архитектура позволяет рассматривать базу данных Oracle как контейнерную БД (Container database, CDB), которая предоставляет ресурсы для нескольких перемещаемых баз данных (pluggable databases, PDBs), каждая из которых может быть добавлена или удалена из CDB. Существующие БД Oracle могут быть адаптированы для помещения в контейнерную базу. Обратное неверно. Новые перемещаемые БД (PDB) в свою очередь могут быть доступны всем клиентам без необходимости изменения существующих приложений. К преимуществам модели арендованной контейнерной базы данных относятся: Консолидация баз данных - Множество перемещаемых баз данных могут находиться внутри единственной контейнерной БД. В рамках CDB они разделяют единый набор фоновых процессов, серверной и системной памяти при полном разделении данных в рамках индивидуальных PDB. В рамках этой архитектуры отсутствует необходимость в дополнительном обслуживании или смешивании данных как в случае виртуальной БД (Virtual Private Database). Это позволяет размещать много больше перемещаемых баз (PDBs) на используемом оборудовании, нежели в случае использования привычной архитектуры Oracle. Снижение стоимости - Консолидация нескольких баз может значительно снизить стоимость требуемого серверного оборудования. Также контейнерная БД, содержащая десяток перемещаемых баз PDBs требует значительно меньше обслуживания, чем десять отдельных БД. В итоге нужно меньше персонала, правда, более квалифицированного. Быстрое развертывание - Перемещаемые БД делают очень быстрым процесс миграции или развертывания данных и кода. Вставка перемещаемой БД в контейнерную, извлечение и вставка в другую контейнерную базу занимают незначительное время. Упрощенное управление - Управление и мониторинг одной контейнерной БД значительно проще, чем работа с несколькими отдельными базами, так как есть единый набор файлов и единственная инстанция для обслуживания. При этом упрощаются процедуры резервного копирования и восстановления после сбоев. Разделение административных обязанностей - Учетные записи арендованных баз являются либо общими, т.е. при их использовании возможно подключение к любому контейнеру, в котором у них есть привилегии, либо локальными, т.е. возможно подключение только к одной перемещаемой базе. Обязанности DBA в свою очередь могут быть разделены между контейнером CDB и арендной базой PDB. Администраторы CBD используют общие учетные записи для администрирования CDB. Администраторы PDB пользуются локальными учетными записями для администрирования отдельных перемещаемых баз PDB. Привилегии определены только в рамках контейнера, где они выданы. Локальный пользователь одной перемещаемой базы не имеет привилегий на другую базу внутри общей контейнерной базы CDB.

36

Упрощение настройки - Контроль и настройка одной базы данных проще, чем настройка десятка БД. Упрощение установки обновлений - Установка обновлений или замена версии одной базы данных значительно проще и менее продолжительны, нежели те же операции с несколькими БД. Описание арендной архитектуры Арендная архитектура это технология, которая позволяет базе данных Oracle работать как контейнерная база с несколькими, от 0 до 253, перемещаемыми базами (PDB). Контейнер представляет собой набор схем, объектов и связанных с ними конструкций, хранимый в арендованной базе данных. Контейнер это либо перемещаемая БД (PDB), либо корневая база (root или CDB$ROOT). Каждая PDB с точки зрения приложения является отдельной базой данных. В рамках CDB каждая PDB должна иметь уникальный идентификатор ID и имя. Перемещаемая БД (PDB) изолирует данные и операции, поэтому с точки зрения пользователя или приложения, получающего доступ по сети Oracle Net, каждая PDB выглядит так, как будто она являются традиционной базой. Каждая контейнерная база включает в себя следующие контейнеры: Единственный контейнер root - Корневой контейнер содержит метаданные ПО Oracle (например, поставленные Oracle исходные коды PL/SQL пакетов) и общих пользователей. Общий пользователь (common user) это пользователь, известный для всех контейнеров. Корневой контейнер называется CDB$ROOT. Все PDB принадлежат корневому контейнеру. Данные пользователей не следует хранить в корневом контейнере, и системноопределенные схемы корневого контейнера никогда не должны меняться. Исключение составляет создание общих пользователей и роли для административных целей. Единственный контейнер seed PDB - Seed (англ. "семя", "посевной материал") PDB системно-поставляемый шаблон базы данных, который может быть использован при создании новых перемещаемых баз данных. seed PDB называется PDB$SEED. Не следует добавлять или изменять объекты в PDB$SEED. Пользовательские перемещаемые базы PDB, от 0 до 253. - PDB, созданные пользователями (под термином пользователь имеется в виду администратор БД), это сущности, содержащие данные и код, предназначенные для реализации определенного набора функций или бизнес-задач. Сразу после создания CDB не содержит PDB. Перемещаемые базы данных (PDB) добавляются к контейнерной базе данных по мере необходимости. Каждая из PBD должна иметь уникальное в пределах CDB имя. Более того, поскольку каждая PDB имеет сервис с собственным именем, имя PDB должно быть уникальным в пределах всех CBD, обслуживаемых общим прослушивателем. Создание и настройка контейнерной базы данных и перемещаемых баз данных Создание и настройка контейнерной БД (CDB) Для создания CDB нужно выполнить такие же действия, как и для создания обычной БД Oracle. До начала процедуры нужно знать, для каких целей будет использоваться БД и планировать создание в соответствии с этим. Некоторые предварительные рекомендации включают:

37

Спланировать таблицы и индексы перемещаемых БД, которые будут включены с CDB, и оценить размеры требуемого дискового пространства. Спланировать размещение файлов CDB в операционной системе. Спланировать количество фоновых процессов в CDB. Определить глобальное имя CDB, которое будет задано в параметрах DB_NAME и DB_DOMAIN. Разработать стратегию резервного копирования и восстановления для защиты CDB от аварий. Выбрать подходящий набор символов для интернациональных приложений. Оценить начальный размер табличного пространства SYSAUX. Перед тем, как будет создана новая контейнерная БД (CDB), нужно убедиться в следующем: Должно быть установлено ПО Oracle 12c с уровнем совместимости не менее 12.0.0. Сервер должен обладать достаточным количеством оперативной памяти. Сервер должен обладать достаточным количеством дисковой памяти, чтобы разместить файлы планируемых перемещаемых баз. Контейнерная база CDB может быть создана как во время, так и после установки ПО Oracle. База CDB может быть создана либо с помощью Database Configuration Assistant (DBCA), либо SQLкомандой CREATE DATABASE. Oracle рекомендует использование DBCA. DBCA является наиболее простым методом, и CDB готова к использованию сразу после завершения работы DBCA. Ассистент DBCA может быть запущен из Oracle Universal Installer или как отдельное приложение в любое время после установки ПО Oracle. Возможно создание CDB в интерактивном или пакетном режиме. В интерактивном режиме используется графический интерфейс, и настройка БД выполняется пошагово. Пакетный режим использует скрипт создания CDB. Как только CDB создана, в нее с помощью утилиты DBCA можно включить новую перемещаемую БД (PDB). Использование SQL-оператора CREATE DATABASE по созданию CDB сходно с созданием монолитной БД. По сравнению с созданием CDB при помощи DBCA это более трудозатратный процесс. Однако вручную можно создавать CDB при помощи скриптов и выполнять точную настройку опций, что не получится с DBCA. При использовании SQL-оператора CREATE DATABASE нужно указать имена и расположение root файлов и seed файлов. После завершения создания CDB ее файлы могут использоваться для создание новых PDB. Контейнер seed не может быть модифицирован после создания. Имена и расположение файлов seed должны быть указаны одним из следующих способов: SEED_FILE_NAME_CONVERT - Этот параметр определяет каким образом формировать имена файлов seed из имен root файлов. Он может быть использован для задания одного или нескольких шаблонов имен файлов и шаблонов замены имен файлов в форме ('string1','string2',' string3',' string4'). Шаблон string2 замещает string1, string4 - string3. Можно задать столько пар, сколько потребуется. Нечетное количество параметров вызовет ошибку. Может быть задано значение NON, что означает отсутствие преобразования. Если параметр не задан, преобразование не производится. SEED_FILE_NAME_CONVERT задает имена файлов для seed файлов в директории 38

/oracle/pdbseed. Шаблоны имен файлов, указанные в этом инициализационном параметре, не могут совпадать с именами файлов или директорий, управляемых Oracle Managed Files. Oracle Managed Files - Когда разрешено использование Oracle Managed Files, OMF определяет имена и расположение файлов seed. PDB_FILE_NAME_CONVERT - Инициализационный параметр PDB_FILE_NAME_CONVERT может использоваться для указания имен и расположения файлов seed. Если PDB_FILE_NAME_CONVERT включен при создании CDB в инициализационный файл и ни один из двух других методов не задействован, то он определит имена файлов seed. Если задан более чем один из описанных методов, то приоритет определяется в приведенном выше порядке. Если в конструкции CREATE DATABASE заданы все три метода, то будет использоваться только параметр SEED_FILE_NAME_CONVERT. Создание и настройка перемещаемой БД (PDB) Для создания перемещаемой БД (PDB) необходимо выполнение следующих условий: Должна существовать контейнерная БД (CDB). CDB должна быть открыта в режиме read/write. Текущий пользователь должен быть общим пользователем, с текущим контейнером root. Текущий пользователь должен иметь системную привилегию CREATE PLUGGABLE DATABASE. Имя PDB должно быть уникально для "своей" CDB и для всех CDB, обслуживаемых общим прослушивателем. Перемещаемые PDB, создаваемые в конфигурации Oracle Data Guard с физической standby базой, должны удовлетворять дополнительным специфическим ограничениям, см. руководство Oracle Data Guard Concepts and Administration для детальной информации. Существует четыре (4) метода создания перемещаемой базы данных (PDB) в арендуемой контейнерной БД (CDB): Использование seed - Файлы seed копируются в новое место и ассоциируются с новой перемещаемой БД Клонирование существующей PDB - Существующая перемещаемая база данных (PDB) может быть клонирована и включена в контейнерную БД. Используемая в качестве источника PDB может быть частью локальной CDB или другой CDB. Все файлы, принадлежащие PDB-источнику копируются в новое место и ассоциируются с новой PDB. Включение извлеченной перемещаемой БД - XML-файл с описанием извлеченной совместно с файлами БД включается в CDB. Преобразование монолитной БД в контейнерную - Пакет DBMS_PDB может быть использован для создания извлеченной БД из монолитной БД 12c. Созданная таким образом PDB может быть включена в CDB. Все описанные техники включают использование оператора CREATE PLUGGABLE DATABASE в тот или иной момент времени. Этот оператор используется для копирования базы данных и 39

включения перемещаемой БД в контейнерную БД согласно требованиям. Этот оператор имеет дополнительные параметры для установки некоторых характеристик PDB: Дисковая память - Параметр STORAGE указывает количество памяти, которое может быть использовано всеми табличными пространствами, принадлежащими PDB, и объем памяти во временном табличном пространстве "по умолчанию", разделяемом всеми PDB, который может быть использован сессиями PDB. Если установлен STORAGE UNLIMITED или параметр STORAGE не задан, то PDB не имеет ограничений по количеству дисковой памяти. Расположение файлов - Всего имеется три параметра, влияющих на имена файлов в PDB. Параметр PATH_PREFIX используется для задания директории и вложенных поддиректорий для расположения файлов PDB, когда заданы относительные пути для объектов и определенных параметров инициализации. Параметр FILE_NAME_CONVERT задает имена файлов PDB после включения ее в CDB. Параметр SOURCE_FILE_NAME_CONVERT задает имена PDB файлов до включения ее в CDB. Шаблон использования временного файла - Параметр TEMPFILE REUSE указывает, что существующий временный файл временного табличного пространства в целевой директории может быть использован повторно. Если задан этот параметр, и в директории нет файла, то Oracle создаст новый временный файл. Если параметр не задан, Oracle попытается создать временный файл. Если файл с таким же именем, как и создаваемый, существует, то возникнет ошибка, и CDB не будет создана. Создание перемещаемой БД из seed Для создания перемещаемой БД (PDB) в рамках контейнерной БД (CDB) можно использовать оператор CREATE PLUGGABLE DATABASE с использованием файлов seed.При создании новой PDB из seed должен быть явно указан администратор базы данных DBA для новой PDB. Новая БД будет создана с тремя табличными пространствами: SYSTEM, SYSAUX, TEMP. Администратор создается как локальный пользователь новой PDB и ему назначается роль PDB_DBA. Для создания PDB из seed нужно: Зарегистрироваться в корневом контейнере базы CDB с помощью SQL*Plus. Выполнить CREATE PLUGGABLE DATABASE команду, указав локального администратора для PDB. При необходимости нужно указать другие параметры. Открыть новую перемещаемую базу в режиме read/write, чтобы Oracle смог завершить интеграцию новой PDB в CDB. Выполнить резервное копирование PDB. Например: SQL> CREATE PLUGGABLE DATABASE ocp_pdb ADMIN USER ocp_adm IDENTIFIED BY password; Клонирование перемещаемой БД С помощью оператора CREATE PLUGGABLE DATABASE можно клонировать существующую PDB. При клонировании существующей БД должен быть задан параметр FROM. PDB-источник может находиться как внутри локальной, так в удаленной CDB. Для клонирования БД пользователь должен 40

обладать привилегией CREATE PLUGGABLE DATABASE в контейнере CBD$ROOT и исходной PDB, а исходная PDB должна быть открыта в режиме read-only. Для клонирования PDB нужно: Зарегистрироваться в корневом контейнере базы CDB с помощью SQL*Plus. Выполнить CREATE PLUGGABLE DATABASE команду, указав исходную PDB в параметре FROM. При необходимости нужно указать другие параметры. Открыть новую перемещаемую базу в режиме read/write, чтобы Oracle смог завершить интеграцию новой PDB в CDB. Выполнить резервное копирование PDB. Следующая команда создает новую перемещаемую базу данных pdb2 на основе существующей pdb1: SQL> CREATE PLUGGABLE DATABASE pdb2 FROM pdb1 PATH_PREFIX = '/u01/oracle/pdb2' FILE_NAME_CONVERT = ('/u01/oracle/pdb1/', '/u01/oracle/pdb2/');

Включение извлеченной перемещаемой БД в контейнерную БД Эта технология использует XML-файл, содержащий описание метаданных существующей перемещаемой БД (PDB), совместно со связанными файлами БД для включения в CDB. XML-файл описывает расположение файлов PDB. Для включения извлеченной PDB в CDB нужно: Зарегистрироваться в корневом контейнере базы CDB с помощью SQL*Plus. Запустить процедуру DBMS_PDB.CHECK_PLUG_COMPATIBILITY, чтобы определить совместимость PDB c CBD. Шаг не является обязательным. Выполнить команду CREATE PLUGGABLE DATABASE, указав XMP-файл, содержащий описание БД в параметре USING. При необходимости нужно указать другие параметры. Открыть новую перемещаемую базу в режиме read/write, чтобы Oracle смог завершить интеграцию новой PDB в CDB. Выполнить резервное копирование PDB. Например: SQL> CREATE PLUGGABLE DATABASE ocp_pdb USING '/u01/aux/ocp_pdb.xml' NOCOPY TEMPFILE REUSE; Создание перемещаемой БД на основе монолитной Существует три способа преобразовать монолитную БД в перемещаемую и включить ее в контейнерную БД: DBMS_PDB - С помощью пакета DBMS_PDB создать XML-файл, описывающий метаданные БД. Этот файл описывает файлы монолитной (классической) БД. Затем возможно включить эти файлы в CDB, используя этот XML-файл, как это описано ранее. Чтобы использовать эту технологию, монолитная БД должна быть версии 12с. Более старые версии должны быть модернизированы до 12с.

41

Oracle Data Pump - В данном методе используется утилиты Oracle Data Pump для экспорта данных из монолитной БД, которые затем импортируются в перемещаемую БД (PDB). GoldenGate Replication - В данном методе используется репликация данных из монолитной БД в перемещаемую с помощью продукта GoldenGate. Когда перемещаемая БД получит все данные из монолитной, пользователи могут переключиться на перемещаемую. Удаление перемещаемой базы данных Для удаления перемещаемой БД применяется команда DROP PLUGGABLE DATABASE. Перемещаемая БД (PDB) может быть удалена в случае переноса в другую контейнерную БД (CDB) или при отсутствии необходимости в ней. После удаления PDB, управляющий файл CDB модифицируется таким образом, чтобы удалить все ссылки на удаляемую PDB. Команда DROP не производит удаление каких-либо архивированных redo-журналов и архивных наборов для удаленной БД. Для их удаления нужно использовать Oracle Recovery Manager (RMAN). Когда перемещаемая БД удалена можно либо сохранить, либо удалить файлы данных, связанные с этой БД, используя один из следующих параметров: KEEP DATAFILES - "по умолчанию". Файлы данных сохраняются. Временный файл перемещаемой БД будет удален, даже если включен этот параметр, т.к. этот файл больше не нужен. INCLUDING DATAFILES - Эта опция удаляет файлы данных с диска. Для перемещаемой БД, созданной с параметром SNAPSHOT COPY, параметр INCLUDING DATAFILES обязательно должен быть указан при удалении перемещаемой БД. Для удаления перемещаемой БД должны выполняться следующие условия: PDB должны быть смонтирована или она должна быть закрыта. Пользователь должен иметь SYSDBA или SYSOPER привилегии, выданные глобально или локально в PDB. Сессия должна быть установлена с параметром AS SYSDBA или AS SYSOPER. Для удаления перемещаемой БД нужно: Зарегистрироваться в корневом контейнере CDB с помощью SQL*Plus. Выполнить команду DROP PLUGGABLE DATABASE, указав удаляемую БД. Например, SQL> DROP PLUGGABLE DATABASE ocp_pdb INCLUDING DATAFILES; Преобразование монолитной базы Oracle данных в перемещаемую базу данных Как говорилось ранее, существует три способа преобразовать монолитную базу данных (БД) в перемещаемую: при помощи пакета DBMS_PDB, утилитами Oracle Data Pump и с помощью Goldengate репликации. В этом разделе рассматривается процедура DBMS_PDB.DESCRIBE. Утилиты Oracle Data Pump рассматриваются далее, а продукт Golden Gate не включен в изложение, т.к. не является частью экзамена. 42

Чтобы преобразовать монолитную БД в перемещаемую с использованием пакета DBMS_PDB, требуется, чтобы монолитная была в транзакционно-целостном состоянии. Кроме того, она должна быть запущена в режиме read-only. Как только монолитная БД запущена в режиме read-only, следует подключиться к ней и выполнить процедуру DBMS_PDB.DESCRIBE. Эта процедура создаст XML-файл с описанием монолитной БД. В примере создается файл ocp_db.xml в директории /u01/oracle SQL> BEGIN DBMS_PDB.DESCRIBE( pdb_descr_file => '/u01/oracle/ocp_db.xml'); END; / По завершению процедуры создается XML-файл и файлы монолитной базы могут быть включены в контейнерную БД (CDB). В этом момент можно остановить монолитную базу и выдать команду CREATE PLUGGABLE DATABASE с подходящими параметрами, например SQL> CREATE PLUGGABLE DATABASE ocp_db USING '/u01/oracle/ocp_db.xml' COPY FILE_NAME_CONVERT = ('/u01/oracle/db01/', '/u01/oracle/ocp_db/'); Перед первым открытием новой перемещаемой БД нужно обязательно выполнить скрипт ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql, для чего следует переключиться в созданную перемещаемую базу данных с помощью команды SQL> ALTER SESSION SET CONTAINER=ocp_db; и выполнить этот скрипт: SQL> @?/rdbms/admin/noncdb_to_pdb.sql После завершения скрипта новая перемещаемая БД должна быть открыта в режиме readwrite для завершения интеграции ее в контейнерную базу CDB. SQL> ALTER SESSION SET CONTAINER=ocp_db; SQL> ALTER PLUGGABLE DATABASE OPEN; При попытке открыть новую перемещаемую БД в первый раз в режиме read-only будет выдана ошибка. Как только перемещаемая БД была открыта в режиме read-write, необходимо выполнить резервное копирование новой перемещаемой БД. Управление контейнерными и перемещаемыми базами данных Приложения могут получать доступ к корневой БД или перемещаемым БД через сервисы. Сервисы БД являются дополнительными свойствами перемещаемых БД. При создании новой перемещаемой БД автоматически создается новый сервис с таким же именем. Если служба Oracle Net Services настроена корректно, то возможен доступ к перемещаемой БД через имя сервиса с использованием либо простого синтаксиса соединения (easy connect syntax) или c использованием имени сервиса из файла tnsnames.ora. При установлении соединения с использованием имени 43

сервиса с непустым именем PDB имя пользователя в сессии определяется в контексте PDB. Если имя сервиса не указано или использовано имя сервиса с пустым значением PDB, то будет считаться, что пользователь относится к контексту root. Если две и более контейнерных БД используют общий прослушиватель, и эти БД содержат две и более перемещаемых БД с одинаковым именем сервиса, то подключение будет носить случайный характер. Все сервисы для перемещаемых БД должны быть либо уникальны для данной системы, либо каждая контейнерная БД должны иметь свой собственный прослушиватель. К каждой перемещаемой БД можно подключиться с использованием команды CONNECT SQL*Plus. Альтернативным способом является команда SQL ALTER SESSION SET CONTAINER. Команда CONNECT может быть использована для подсоединения к корню или перемещаемой БД в контейнерной базе. Любой из перечисленных ниже способов может быть использован для доступа к корневому контейнеру через CONNECT из SQL*Plus: локальное соединение локальное соединение с системной аутентификацией соединение с БД с использованием простого синтаксиса соединение с БД с использованием имени сервиса удаленное соединение с БД с использованием внешней аутентификацией Чтобы установить сессию с корневым контейнером, необходимо быть общим пользователем и иметь привилегию CREATE SESSION в корневом контейнере. Для подсоединения к корневому контейнеру с использованием команды CONNECT SQL*Plus следует запустить SQL*Plus с параметром /NOLOG $ sqlplus /nolog Находясь в SQL*Plus можно установить сессию с корневым контейнером используя: локальное соединение SQL> connect username/password локальное соединение с системной аутентификацией SQL> connect / as sysdba соединение с использование имени сервиса SQL> connect username/pasword@ocp_db Любой из следующих способов может быть использован для установления соединения с перемещаемой БД с использованием команды CONNECT из SQL*Plus: соединение с БД с использованием синтаксиса easy connect SQL> connect username/password@host[:port][/service_name] 44

соединение с БД с использованием имени сервиса SQL> connect username/password@service_name Чтобы пользователь мог установить соединение с перемещаемой БД, пользователь должен быть общим, и ему должна быть присвоена привилегия CREATE SESSION глобально или в данной перемещаемой БД, или он должен быть локальным пользователем с привилегией CREATE SESSION. Только пользователь с одной из ролей SYSDBA, SYSOPER, SYSBACKUP, SYSDG может подключаться с перемещаемой БД в смонтированном состоянии. Для соединение с перемещаемой БД с использованием команды CONNECT SQL*Plus нужно запустить SQL*Plus с параметром /nolog $ sqlplus /nolog следующая команда устанавливает перемещаемой БД (PDB) ocp_db:

соединение

локального

пользователя

user

с

SQL> connect user@ocp_db Если сессия установлена для общего пользователя контейнерной БД, то следующая команда может быть использована для перехода в другой контейнер SQL> ALTER SESSION SET CONTAINER=container_name; ,где container_name может быть одним из следующих: CDB$ROOT для переключения в корневой контейнер PDB$SEED для перехода в seed контейнер имя перемещаемой БД (PDB) Запуск и остановка контейнерной (CDB)/перемещаемой (PDB) базы данных За исключением среды Real Application Cluster контейнерная БД выполняется в виде одиночного экземпляра. Процесс запуска контейнерной БД ничем не отличается от запуска монолитной. Команды STARTUP NOMOUNT, STARTUP MOUNT и STARTUP OPEN работают в контейнерной БД и имеют такое же назначение. Однако статус перемещаемой БД внутри контейнерной БД изменился. Для запуска экземпляра контейнера следует подключиться к корневому контейнеру с привилегией SYSDBA. Как только экземпляр запущен, можно воспользоваться представлением V$PDBS для определения статуса перемещаемых БД. Контейнерная БД может быть запущена в режиме: NOMOUNT - Если контейнерная БД находится в состоянии NOMOUNT, то инстанция запущена, но перемещаемые БД не имеют статуса, и запрос к V$PDBS не вернет какихлибо данных. MOUNT - Если контейнерная БД смонтирована, то управляющий файл экземпляра открыт. Корневой контейнер и все контейнеры будут в статусе MOUNTED. OPEN - Если контейнерная БД открыта, то корневой контейнер будет открыт. SEED контейнер будет открыт в режиме read-only. Все остальные контейнеры будут в состоянии MOUNT. 45

Когда контейнерная БД открыта, можно открыть перемещаемые БД по отдельности или одновременно: SQL> ALTER PLUGGABLE DATABASE ocp_db OPEN; SQL> ALTER PLUGGABLE DATABASE ALL OPEN; SQL> ALTER PLUGGABLE DATABASE ALL EXCEPT ocp_db OPEN; Остановка экземпляра контейнерной БД не отличается от остановки монолитной базы данных. Для остановки экземпляра необходимо выполнение следующих условий: БД должна быть открыта или смонтирована Текущий пользователь должен быть общим пользователем с одной из привилегий SYSDBA, SYSOPER, SYSBACPUP, SYSDG Текущим контейнером должен быть CDB$ROOT Режим перемещаемой БД может быть изменен SQL командой ALTER PLUGGABLE DATABASE или SQL*Plus командой STARTUP. Для перемещаемой БД возможно одно из следующих состояний: OPEN READ WRITE - в этом режиме разрешены запросы и пользовательские транзакции с генерацией журналов изменений. OPEN READ ONLY - в этом режиме разрешены запросы, но запрещены изменения. OPEN MIGRATE - в этом режиме разрешен запуск скриптов для модификации словаря перемещаемой БД. Перемещаемая БД находится в этом режиме после команды ALTER DATABASE OPEN UPGRADE. MOUNTED - в смонтированном состоянии перемещаемая БД ведет себя аналогично смонтированной монолитной БД. Никакие изменения объектов не разрешены, и объекты доступны только для администраторов. Если текущим контейнером является корневой, то команда ALTER PLUGGABLE DATABASE изменяет состояние указанных перемещаемых БД (PDB). Если PDB открыта командой ALTER PLUGGABLE DATABASE OPEN, то режим READ WRITE является значением "по умолчанию". Исключением является случай, когда PDB принадлежит контейнерной БД, используемой в качестве физической standby базы данных, для которой значением "по умолчанию" является READ ONLY. Перемещаемые БД, состояние которых должно быть изменено, могут быть указаны: в виде списка из одной или нескольких БД, разделенных запятыми; параметра ALL, что указывает на все доступные БД в рамках контейнерной БД; ALL EXCEPT, что указывает на необходимость изменения всех БД, за исключением явно указанных. Примеры: SQL> ALTER PLUGGABLE DATABASE ocp_db, test OPEN READ WRITE; SQL> ALTER PLUGGABLE DATABASE ALL OPEN READ WRITE; SQL> ALTER PLUGGABLE DATABASE ocp_db OPEN READ ONLY RESTRICTED; SQL> ALTER PLUGGABLE DATABASE ALL EXCEPT ocp_db OPEN; 46

Если текущим контейнером является корневой, то можно использовать команду STARTUP PLUGGABLE DATABASE для открытия отдельной перемещаемой БД. Команда STARTUP PLUGGABLE DATABASE имеет следующие опции: FORCE - закрывает открытую перемещаемую БД перед последующим открытием в readwrite. RESTRICT - открывает PDB в режиме, позволяющим устанавливать сессии с БД только пользователям с привилегией RESTRICTED SESSION. OPEN - открывает перемещаемую БД либо режиме read-write или read-only. Вы можете указать OPEN READ WRITE или OPEN READ ONLY. "по умолчанию" используется READ WRITE. Примеры: SQL> STARTUP PLUGGABLE DATABASE ocp_db OPEN; SQL> STARTUP PLUGGABLE DATABASE ocp_db RESTRICT; SQL> STARTUP PLUGGABLE DATABASE ocp_db OPEN READ ONLY; SQL> STARTUP PLUGGABLE DATABASE ocp_db FORCE; Команда ALTER PLUGGABLE DATABASE также используется для закрытия одной или нескольких перемещаемых БД. Чтобы закрыть PDB, нужно подключиться к корневому контейнеру с привилегией SYSOPER или SYSDBA и выполнить команду ALTER PLUGGABLE DATABASE CLOSE, указав имена закрываемых перемещаемых БД. Если команда содержит ключевой слово IMMEDIATE, то транзакции в выбранной БД откатываются назад и все сессии принудительно закрываются. Если ключевое слово IMMEDIATE отсутствует, то команда "подвисает", ожидая завершения всех сессий с данной перемещаемой БД. Все файлы данных перемещаемой БД будут закрыты и недоступны для пользователей. Команды SHUTDOWN IMMEDIATE и ALTER PLUGGABLE DATABASE CLOSE эквиваленты с точки зрения перемещаемых баз данных. Примеры: SQL> ALTER PLUGGABLE DATABASE ocp_db, test CLOSE; SQL> ALTER PLUGGABLE DATABASE ALL CLOSE; SQL> ALTER PLUGGABLE DATABASE ALL EXCEPT testdb CLOSE IMMEDIATE; Изменение параметров экземпляра для контейнерной (CDB) или перемещаемой (PDB) БД Контейнерная БД имеет единственный бинарный файл параметров SPFILE независимо от количества перемещаемых БД. Любой параметр инициализации, установленный на корневом уровне, устанавливается во всех PDB, которые содержатся в CDB. Многие, но не все, инициализационные параметры могут быть установлены на уровне отдельных перемещаемых БД. Список таких параметров может быть получен следующим запросом: SQL> SELECT name FROM v$system_parameter WHERE ispdb_modifiable = 'TRUE' ORDER BY name; 47

Любой из этих параметров, неустановленный индивидуально для PDB, наследуется из параметра, установленного в корневом контейнере. Значения параметров задаются на уровне PDB с помощью команды ALTER SYSTEM. Если опция видимости изменений SCOPE установлена в SPFILE или BOTH, то значения параметра будет сохранены после закрытия/повторного открытия перемещаемой БД или после перезапуска контейнерной БД в целом. Параметры, установленные таким образом, также переносятся при клонировании БД и извлечении/включении перемещаемых БД. Любой параметр, не включенный в результат приведенного выше запроса, может быть установлено только для корневого контейнера и, следовательно, является общим для всех PDB. Управление табличными пространствами, общими и локальными пользователями, привилегиями и ролями Управление табличными пространствами контейнерной (CDB) или перемещаемой (PDB) БД Табличные пространства в контейнерной арендуемой БД служат тем же целям и в большинстве случаев используются таким же образом, как и монолитной БД. Синтаксис создания и модификации табличных пространств в целом не изменился. Есть несколько моментов, специфичных для табличных пространств в контейнерной БД: Постоянное табличное пространство может принадлежать только одному контейнеру. При создании табличного пространства в контейнере, табличное пространство связывается с контейнером. Контейнерная БД может иметь только одно табличное пространство отката UNDO или одно активное пространство UNDO для каждого экземпляра RAC CDB. Существует одно временное табличное пространство "по умолчанию" для всей контейнерной БД. Корневой контейнер и перемещаемые БД также могут иметь свое собственное временное табличное пространство "по умолчанию". Поскольку постоянное табличное пространство может быть связано только с одним контейнером, каждый контейнер должен иметь собственное постоянное табличное пространство "по умолчанию". Пользователи, подключенные к данному контейнеру и не имеющие явного пространства "по умолчанию", будут использовать пространство "по умолчанию" контейнера. При подключении к CDB команда установки постоянного табличного пространства "по умолчанию" выглядит так SQL> ALTER DATABASE DEFAULT TABLESPACE tbs_users_cdb; При подключении к перемещаемой БД команда ALTER DATABASE сохранена для совместимости, но предпочтимым синтаксисом является: SQL> ALTER PLUGGABLE DATABASE DEFAULT TABLESPACE tbs_users_pdb; Контейнерная БД будет иметь только одно временное табличное пространство "по умолчанию" (или группу табличных пространств). Чтобы создать или изменить это табличное пространство нужно, чтобы текущим контейнером был CDB$ROOT. Можно создать дополнительные временные табличные пространства в корне и назначить их пользователям. Аналогично, каждая 48

контейнерная БД может содержать одно временное табличное пространство "по умолчанию" и временные табличные пространства, которые могут быть назначены пользователям. Когда перемещаемая БД извлекается из контейнерной БД, ее временные табличные пространства тоже извлекаются. Управление пользователями и привилегиями в контейнерной (CDB) или перемещаемой (PDB) БД Общий пользователь это пользователь БД, имеющий одинаковую идентичность в корневой и любой существующей и будущей перемещаемой БД. Общие пользователи могут подсоединяться и выполнять действия в корневом контейнере и внутри любого контейнера, в котором они имеют привилегии. Пользователь, подключенный к корневому контейнеру, может выполнять определенные операции (ALTER PLUGGABLE DATABASE, CREATE USER, CREATE ROLE), которые влияют на перемещаемые БД. Однако большинство операций может быть выполнено внутри текущего контейнера. Пользователи вначале должны явно переключиться на контейнер, где нужно произвести действия, а потом произвести требуемые операции. Например, общий пользователь не может выполнять запросы к таблицам/представлениям в перемещаемой БД, если она не является текущим контейнером. Создание общего пользователя Для создания общего пользователя нужно выполнить ряд условий: Нужно подключиться к корневому контейнеру и обладать общей системной привилегией CREATE USER. Текущим контейнером сессии должен быть CDB$ROOT. Имя общего пользователя должно начинаться с C## или c## и содержать только ASCII или EBCDIC символы. Чтобы явно указать, что пользовательская учетная запись является общей, нужно в команде CREATE USER указать опцию CONTAINER=ALL. Если текущим контейнером является корневой, то при отсутствии опции CONTAINER в указанной команде, неявно предполагается CONTAINER=ALL. Не следует создавать какие-либо объекты в схемах общих пользователей. Такие объекты не могут быть пересекать границы перемещаемых БД и могут вызвать проблемы при их переносе. В следующем примере создается общий пользователь и ему присваиваются привилегии SET CONTAINER и CREATE SESSION, необходимые для перемещения между контейнерами: SQL> CREATE USER c##ocp_admin IDENTIFIED BY password DEFAULT TABLESPACE ts_cdb_users QUOTA 100M ON ts_cdb_users TEMPORARY TABLESPACE temp_ts CONTAINER = ALL; SQL> GRANT SET CONTAINER, CREATE SESSION TO c##ocp_admin CONTAINER = ALL;

49

Создание локального пользователя Локальные пользователи определены только в той перемещаемой БД, где созданы. Они не могут установить соединение и им не могут быть выданы привилегии в других контейнерах. Возможно, конечно, создать пользователей с одинаковыми именами в разных перемещаемых БД, но эти учетные записи не имеют ничего общего, кроме имени. Чтобы создать локального пользователя нужно: Нужно подключиться к перемещаемой БД, в которой нужно создать пользователя, и иметь привилегию CREATE USER. Имя локального пользователя не может начинаться на C## или c##. Опция CONTAINER=CURRENT может быть явно включена в команду CREATE USER, чтобы указать пользователя, как локального. При подключении к перемещаемой БД при неуказанном параметре CONTAINER подразумевается CONTAINER=CURRENT. Например: SQL> CREATE USER ocp_user IDENTIFIED BY password DEFAULT TABLESPACE ts_pdb_users QUOTA 100M ON ts_pdb_users TEMPORARY TABLESPACE temp_ts PROFILE ocp_profile CONTAINER = CURRENT; Привилегии общих и локальных пользователей Общие и локальные пользователи могут выдать привилегии друг другу. Определенная привилегия, например CREATE ANY TABLE, не является общей или локальной сама по себе. Если CREATE ANY TABLE выдана общим образом, то она становится общей привилегией, если локально, то локальной. Общие выданные привилегии: Привилегия, выданная "в общем", может быть использована в любом существующем и будущем контейнере. Только общие пользователи могут выдавать привилегии "в общем" и только общим пользователям или ролям. Выдающий привилегии должен быть подключен к корневому контейнеру и должен явно указывать параметр CONTAINER=ALL в команде GRANT. Могут включать в себя системные и объектные привилегии. Не следует выдавать общие привилегии роли PUBLIC. Локальные привилегии: Локально выданные привилегии могут быть использованы только контейнере, где были выданы, даже, если этим контейнером был корневой. И общие, и локальные пользователи могут давать привилегии локально. 50

И общие, и локальные пользователи могут давать привилегии другим общим или локальным ролям. Выдающий привилегии должен быть подключен к контейнеру и должен указать параметр CONTAINER=CURRENT в команде GRANT. Любой пользователь может выдавать привилегии локально любому другому пользователю или роли (общей или локальной) или роли PUBLIC. Параметр CONTAINER в команде GRANT или REVOKE определяет, где выдаются или отзываются привилегии. Если параметр CONTAINER явно установлен в ALL, то команда выдает привилегии во всех существующих и будущих контейнерах. При использовании CURRENT привилегии определяются в локальном контейнере. Значение CURRENT ставится "по умолчанию", если опция опущена за исключением, когда вы подключены к корневому контейнеру, тогда "по умолчанию" будет ALL. В примере общему пользователю c##ocp выдается общая привилегия CREATE TABLE. В результате пользователь сможет пользоваться привилегией во всех имеющихся и будущих контейнерах. SQL> GRANT CREATE TABLE TO c##ocp CONTAINER=ALL; Общие роли создаются в корневом контейнере и известны во всех существующих и будущих контейнерах. Все предопределенные и поставляемые Oracle роли являются общими. Локальные роли существуют только в перемещаемых БД, где созданы, и могут быть использованы только там. Локальные роли не могут иметь каких-либо общих привилегий. Общие и локальные пользователи взаимодействуют с общими и локальными ролями следующим образом: Общие пользователи могут создавать общие роли и выдавать их другим общим и локальным пользователям. Общая роль может быть выдана общему пользователю в общем или локально. Если общая роль выдана локальному пользователю, то привилегии роли применимы только в рамках локального контейнера. Локальные пользователи не могут создавать глобальные роли. Локальные пользователи могут выдавать общие роли общим локальным пользователям. Если выполняются следующие условия, то привилегии выданные "в общем" для общей роли применяются в корневом контейнере и во всех существующих и будущих контейнерах: И выдающий, и получающий роль являются общими пользователями. Выдающий роль имеет выданную "в общем" SET CONTAINER привилегию и опцию ADMIN OPTION для общей роли. Команда GRANT содержит опцию CONTAINER_ALL. Имя общей роли должно начинаться с C## или c## и содержать только ASCII или EBCDIC символы. Это правило не распространяется на поставляемые Oracle роли, такие как DBA. При создании роли параметр CONTAINER должен быть установлен в ALL. За исключением случая, когда вы подключены к корневому контейнеру, отсутствие параметра в команде CREATE ROLE приведет к тому, что роль будет создана в текущей PDB. Если параметр CONTAINER опущен, когда вы подключены к

51

корневому контейнеру, "по умолчанию" роль будет создана как общая. В примере создается общая роль c##ocp SQL> CREATE ROLE c##ocp container=ALL;

Резервное копирование, восстановление и ретроспективный откат для контейнерной и перемещаемой БД Выполнение резервного копирования контейнерной или перемещаемой БД Резервное копирование базы данных Oracle в арендной архитектуре можно выполнять с помощью утилиты RMAN или EM Cloud Control. Существует возможность выполнять резервное копирование или восстановление контейнерной БД полностью, т.е. со всеми контейнерами, отдельно корневого контейнера, или любой из перемещаемых БД. Также существует возможность резервировать и восстанавливать отдельные табличные пространства и файлы данных в отдельных перемещаемых БД. Резервирование каждого элемента контейнерной БД отдельно (корневой контейнер и перемещаемые БД) функционально эквивалентно в терминах восстановимости контейнерной БД полностью. Действия, требуемые для резервного копирования контейнерной БД, эквивалентны операциям полного резервного копирования монолитной БД. При резервировании контейнерной БД целиком, RMAN выполняет резервирование корневого контейнера, всех перемещаемых БД, всех архивированных журнальных файлов. Из полученного резервного набора можно восстановить контейнерную БД в целом, только корневой контейнер или комбинацию перемещаемых баз, включенных в резервный набор. Чтобы выполнить резервное копирование следует запустить RMAN, подключиться к корневому контейнеру, как общий пользователь с полномочиями SYSBACKUP или SYSDBA и к каталогу восстановления, если он используется. База данных должна быть либо открыта, либо смонтирована. После этого можно выдать подходящие команды резервирования в командном интерпретаторе RMAN: Резервирование контейнерной БД целиком: RMAN> BACKUP DATABASE; Выполнить резервное копирование БД, переключить активные redo-журналы, включив архивированные журналы в резервный набор: RMAN> BACKUP DATABASE PLUS ARCHIVELOG; Выполнить резервное копирование корневого контейнера RMAN> BACKUP DATABASE ROOT; Выполнить резервное копирование перемещаемой БД Есть два способа выполнить резервное копирование перемещаемой БД с помощью RMAN:

52

Установить соединение с корневым контейнером, выдать команду BACKUP PLUGGABLE DATABASE из командной строки интерпретатора RMAN. Этот метод может быть полезен при резервировании одной или более PDB. RMAN> BACKUP PLUGGABLE DATABASE db_ocp, test; Установить соединение с перемещаемой БД, выдать команду BACKUP DATABASE из командной строки интерпретатора RMAN. RMAN> BACKUP DATABASE; Восстановление контейнерной или перемещаемой БД Контейнерную базу данных можно восстановить полностью, только ее корневой контейнер, одну перемещаемую базу, или только часть перемещаемой базы, как то табличное пространство или файл данных. Если контейнерная база восстанавливается полностью, то корневой контейнер и все перемещаемые базы восстанавливаются в рамках одной операции. Для восстановления контейнерной БД следует воспользоваться командами RESTORE и RECOVER RMAN. При восстановлении RMAN автоматически извлечет из резервных наборов все нужные архивированные журналы redo. Если резервный набор хранится на внешней системе, то необходимо настроить требуемые каналы доступа. Для восстановления контейнерной БД полностью нужно запустить RMAN, установить соединение с корневым контейнером в качестве общего пользователя с привилегиями SYSBACKUP или SYSDBA, при необходимости установить соединение с каталогом восстановления. Следующая команда извлечет данные и восстановит контейнерную БД полностью: RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; При необходимости можно удалить любые архивные журналы, что были извлечены на диск для операции восстановления, поскольку они больше не нужны для работы, с помощью следующей команды: RMAN> RECOVER DATABASE DELETE ARCHIVELOG; Если имели место ошибки пользователя или повреждение данных, специфичные для корневого контейнера, то можно восстановить только корневой контейнер. Однако Oracle настоятельно рекомендует восстановить все перемещаемые БД после восстановления корневого контейнера. Это позволит избежать несоответствия метаданных между корневым контейнером и перемещаемыми БД. Как общее правило предпочтительно восстанавливать контейнерную БД в целиком. Чтобы восстановить корневой контейнер нужно подключиться к нему RMAN как общий пользователь с SYSDBA или SYSBACKUP привилегиями. Контейнерная БД должны быть смонтирована, но не открыта. Восстановление состоит из следующих этапов: При необходимости следует настроить типовое устройство "по умолчанию" и каналы. Следует извлечь и восстановить корневой контейнер:

53

RMAN> RESTORE DATABASE ROOT; RMAN> RECOVER DATABASE ROOT; Следует убедиться в отсутствии ошибок в процессе восстановления. Oracle настоятельно рекомендует восстановить все перемещаемые БД и seed сразу после восстановления корневого контейнера. Для этого нужно выдать команды RESTORE PLUGGABLE DATABASE и RECOVER PLUGGABLE DATABASE RMAN> RESTORE PLUGGABLE DATABASE 'PDB$SEED',db_ocp; RMAN> RECOVER PLUGGABLE DATABASE 'PDB$SEED',db_ocp; Следует проверить отсутствие ошибок восстановления и открыть контейнерную базы данных и все перемещаемые БД: RMAN> ALTER DATABASE OPEN; RMAN> ALTER PLUGGABLE DATABASE ALL OPEN; Можно выполнить полное восстановление отдельной перемещаемой БД или нескольких БД без влияния на работу других баз данных в той же контейнерной базе данных. Эту операцию можно выполнить, подключившись как к корневому контейнеру, так и к PDB. Если подключение выполнено к корневому контейнеру, то следует использовать команды RESTORE PLUGGABLE DATABASE и RECOVER PLUGGABLE DATABASE (см. пример выше.). Таким образом, возможно восстановление нескольких перемещаемых БД за один раз. Если вы подключены к перемещаемой БД, то нужно использовать команды RESTORE DATABASE и RECOVER DATABASE. В этом случае возможно восстановление только одной БД за операцию. В примере приведена последовательность восстановления перемещаемой БД ocp_db при подключении к корневому контейнеру из RMAN под общим пользователем с правами SYSDBA или SYSBACKUP: Вначале следует закрыть базу данных, требующую восстановления: RMAN> ALTER PLUGGABLE DATABASE ocp_db CLOSE; Если какие-то файлы данных отсутствуют, то возникнет ошибка, и база не сможет закрыться. В этом случае нужно подключиться к PDB с отсутствующими файлами данных и перевести их в состояние offline, чтобы БД смогла закрыться: RMAN> ALTER PLUGGABLE DATABASE ocp_db DATAFILE 8 OFFLINE; При необходимости следует настроить типовое устройство "по умолчанию" и каналы. восстановить перемещаемую БД командами: RMAN> RESTORE PLUGGABLE DATABASE ocp_db; RMAN> RECOVER PLUGGABLE DATABASE ocp_db; Если какие-либо файлы были переведены в состояние offline, нужно перевести в состояние online: RMAN> ALTER PLUGGABLE DATABASE ocp_db DATAFILE 8 ONLINE; 54

Следует проверить отсутствие ошибок при восстановлении в журнале RMAN. Если восстановление было успешным, нужно открыть базу: RMAN> ALTER PLUGGABLE DATABASE ocp_db OPEN; Чтобы восстановить одну перемещаемую БД, будучи подключенным к ней RMAN'ом от имени локального пользователя с привилегиями SYSDBA, нужно: Закрыть перемещаемую БД; RMAN> ALTER PLUGGABLE DATABASE CLOSE; Если какие-то файлы данных отсутствуют, то возникнет ошибка, и база не сможет закрыться. В этом случае нужно подключиться к PDB с отсутствующими файлами данных и перевести их в состояние offline, чтобы БД смогла закрыться: RMAN> ALTER DATABASE DATAFILE 19 OFFLINE; При необходимости следует настроить типовое устройство "по умолчанию" и каналы Следует восстановить перемещаемую БД командами: RMAN> RESTORE DATABASE; RMAN> RECOVER DATABASE; Если какие-либо файлы были переведены в состояние offline, нужно перевести в состояние online: RMAN> ALTER DATABASE DATAFILE 19 ONLINE; Следует проверить отсутствие ошибок при восстановлении в журнале RMAN. Если восстановление было успешным, нужно открыть базу: RMAN> ALTER PLUGGABLE DATABASE OPEN; Выполнение ретроспективного отката на контейнерной базе данных Ретроспективный откат (flashback) для контейнерной базы данных выполняется точно так же, как и для монолитной. Единственным исключением является ситуация, когда одна и более перемещаемых БД была восстановлена на определенный момент времени (Point-In-Time-Recovery). Если какая-либо из перемещаемых баз восстановлена на момент времени в прошлом, то ретроспективный откат контейнерной БД может быть запрещен, чтобы обеспечивать обратную совместимость. Если это так, то невозможно напрямую перемотать контейнерную БД к моменту времени, более раннему, чем момент восстановления перемещаемой БД (PITR). Попытка ретроспективного отката к более раннему моменту времени вызовет сообщение: ORA-39866: Data files for pluggable database must be offline to flashback across a PDB point-in-time recovery

Если же есть необходимость откатить контейнерную БД на момент времени ранее, чем PITR, нужно сделать следующие действия: 55

Запустить RMAN, установить соединение с корневым контейнером с пользователем, имеющим SYSDBA или SYSBACKUP привилегии. Определить время, на которое нужно восстановить контейнерную БД (CDB). Перевести все файлы, относящиеся к восстановленной перемещаемой базе (PDB) в offline. Перемотать контейнерную БД на желаемое время. Файлы PDB, находящиеся в режиме offline, не будут при этом затронуты. Восстановить перемещаемую БД, для которой было выполнено восстановление на момент времени, командами RESTORE PLUGGABLE DATABASE и RECOVER PLUGGABLE DATABASE. Перевести файлы PDB в режим online.

56

Управление жизненным циклом информации и оптимизация работы с дисковой памятью Использование управления жизненным циклом информации (Information Lifecycle Management, ILM) Управление жизненным циклом информации это действия по управлению жизненным циклом данных от создания или получения до архивирования или удаления. Oracle 12c предлагает две новых возможности ILM, которые позволяют базе данных интеллектуально управлять использованием табличного пространства: горячая карта (Heat Map) и автоматическая оптимизация данных (Automatic Data Optimization, ADO). Горячая карта (Heat Map) В любой базе данных к разным частям информации обращаются с разной интенсивностью и различным образом. Данные, к которым обращаются часто, должны располагаться на дисковом пространстве, имеющем наибольшую производительность, точнее, минимальное время отклика. Напротив, редко требуемые данные могут храниться на устройствах памяти с низкой производительностью, не оказывая при этом влияния на общую производительность базы данных. Наиболее быстрая дисковая память неизбежно является наиболее дорогой, поэтому с точки зрения цены нерационально хранить редко используемые данные на быстрой дисковой памяти. Разделение дисковой памяти (storage tiering) это действия по размещению данных на нескольких типах дисковой памяти. При разделении дисковой памяти по типам, идеальной является ситуация, когда наиболее часто используемые данные хранятся на быстрых дисках, а менее часто используемые на более медленных. Новая функция базы данных Oracle, горячая карта (Heat Map), создана именно для таких целей. Механизм "горячей карты" автоматически отслеживает изменение данных на уровне строк и сегментов. Как только данные изменены, отслеживаются временные характеристики на уровне строк и агрегируются на уровне блока. Время изменения, время полного сканирования таблиц и время поиска индекса, - все они отслеживаются на уровне сегмента. Конечным результатом является то, что при использовании горячей карты можно увидеть, каким образом происходит доступ к данным и как меняется характер доступа во времени. Автоматическая оптимизация данных (Automatic Data Optimization, ADO) Автоматическая оптимизация данных (Automatic Data Optimization, ADO) позволяет администраторам базы данных создавать политики сжатия и перемещения данных. Одной из характеристик ADO является умная компрессия (Smart Compression), использующая в работе данные горячей карты для связывания политик и степени компрессии в зависимости от степени использования данных. Периодически база данных оценивает политики ADO и на основе данных горячей карты принимает решение о переносе и/или сжатии данных. Будучи включенной, ADO работает в фоновом режиме во время окна обслуживания без вмешательства DBA, но при необходимости может быть выполнена им вручную. Политики ADO могут быть определены на уровне сегмента или строки для таблиц и их секций. Выполнение отслеживания изменений и автоматизированное размещение данных Для реализации ILM политик можно использовать горячую карту базы данных Oracle, чтобы отследить доступ к данным и их изменение. Включение горячей карты является единственным 57

способом реализации политики ILM. Горячая карта может быть включена или выключена на уровне системы или сессии с помощью команд ALTER SYSTEM или ALTER SESSION с параметром HEAT_MAP. После включения все факты доступа к объектам во всех табличных пространствах за исключением SYSTEM и SYSAUX отслеживаются фоновым процессом. Следующие SQL команды включают и выключают горячую карту для экземпляра базы данных соответственно: SQL> ALTER SYSTEM SET HEAT_MAP=ON; SQL> ALTER SYSTEM SET HEAT_MAP=OFF; Для анализа данных отслеживания горячей карты можно использовать следующие представления: V$HEAT_MAP_SEGMENT - отображает информацию о доступе к сегментам в реальном времени. DBA_HEAT_MAP_SEGMENT - отображает последнее время доступа к каждому из сегментов. DBA_HEAT_MAP_SEG_HISTOGRAM - отображает информацию о доступе ко всех сегментам. DBA_HEATMAP_TOP_OBJECTS - отображает горячую карту для 1000 самых активных объектов. DBA_HEATMAP_TOP_TABLESPACES - отображает горячую карту для 100 наиболее активных табличных пространств. Чтобы автоматически перемещать данных между различными типами дисковой памяти, нужно определить одну или более политик автоматической оптимизации данных (ADO). Политики ADO могут быть определены для уровня строки, сегмента или табличного пространства как во время создания, так и с помощью оператора ALTER для уже существующего объекта. Политики ADO могут быть определены с параметром видимости SEGMENT, ROW или GROUP. Следующий запрос дает список политик для текущего пользователя: SQL> SELECT policy_name, policy_type, enabled FROM user_ilmpolicies; Команды SQL CREATE TABLE и ALTER TABLE имеют дополнительный необязательный параметр, позволяющий создать, удалить, включить или выключить политику ILM. Параметр policy определяет политику, используемую при сжатии или изменении типа дисковой памяти для объекта. Политики ILM ADO получают системно-определяемые имена, такие как P1, P2, ... Pn. Политики уровня сегмента выполняются однократно. Как только политика была успешно применена, она будет выключена и никогда более не будет применена, за исключением явного включения. Политики уровня строк остаются включенными после успешно применения и выполняются многократно. Приняты следующие соглашения "по умолчанию" для сжатия, которые применяются в групповых политиках: COMPRESS ADVANCED - На обычных таблицах реализуются как стандартное сжатие для индексов и низкое LOW для LOB сегментов. 58

COMPRESS FOR QUERY LOW/QUERY HIGH - На обычных таблица реализуются как стандартное сжатие для индексов и среднее (MEDIUM) для LOB сегментов. COMPRESS FOR ARCHIVE LOW/ARCHIVE HIGH - На стандартных таблицах реализуются как стандартное сжатие для индексов и высокое (HIGH) для LOB сегментов. В примере приведен код добавления политики ILM для секции таблицы HR.SALES: SQL> ALTER TABLE hr.sales MODIFY PARTITION sales_q01_2012 ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW AFTER 60 DAYS OF NO MODIFICATION; SQL> ALTER TABLE hr.sales MODIFY PARTITION sales_q01_2009 ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 12 MONTHS OF NO MODIFICATION; SQL> ALTER TABLE hr.sales MODIFY PARTITION sales_q01_2007 ILM ADD POLICY COMPRESS FOR ARCHIVE HIGH SEGMENT AFTER 12 MONTHS OF NO ACCESS; Если существующая политика ILM противоречит новой создаваемой политике, то нужно удалить или выключить старую политику. Это можно сделать следующим образом: SQL> ALTER TABLE hr.sales MODIFY PARTITION sales_q01_2012 ILM DISABLE POLICY P2; SQL> ALTER TABLE hr.sales MODIFY PARTITION sales_q01_2012 ILM DELETE POLICY P2;

59

Перенос файлов данных online Теперь в Oracle 12c можно выполнять SQL команду ALTER DATABASE MOVE DATAFILE для переноса или переименования файла данных, не прерывая доступа пользователей к данным. При переименовании или перемещении файла указатели на него модифицируются в управляющем файле. Одновременно файл физически перемещается или переименуется в файловой системе. Если файл с таким же именем и в том же месте, что задано в команде ALTER DATABASE, уже существует, то команда завершится ошибкой. При использовании ключевого слова REUSE, Oracle перезапишет его новым файлом, переименованным или перемещенным. В момент переименования или перемещения файла по SQL команде ALTER DATABASE MOVE DATAFILE создается копия файла данных. Поэтому перед началом операции нужно убедиться в наличии дискового пространства, достаточного для размещения и файла, и его копии одновременно. По завершении операции исходный файл "по умолчанию" удаляется. Если указана опция KEEP, то исходный файл сохраняется. Однако после завершения операции база данных будет использовать только новый файл данных. В примерах показано переименование, перемещение файла данных, перемещение с ключом REUSE, перемещение с ключом KEEP: SQL> ALTER DATABASE MOVE DATAFILE '/u01/oracle/X/user1.dbf' TO '/u01/oracle/X/user_ts1.dbf'; SQL> ALTER DATABASE MOVE DATAFILE '/u01/oracle/X/user_ts1.dbf' TO '/u02/oracle/X/user_ts1.dbf'; SQL> ALTER DATABASE MOVE DATAFILE '/u01/oracle/X/user_ts1.dbf' TO '/u02/oracle/X/user_ts1.dbf' REUSE; SQL> ALTER DATABASE MOVE DATAFILE '/u01/oracle/X/user_ts1.dbf' TO '/u02/oracle/X/user_ts1.dbf' KEEP;

60

Внутреннее архивирование (In-Database актуальность данных (Valid-Time Temporal)

Archiving)

и

временная

Различие между управлением жизненным циклом информации (Information Lifecycle Management, ILM) и временной актуальностью Разработанная Oracle технология управления жизненным циклом информации (Information Lifecycle Management, ILM) создана для оптимизации использования базой данных ресурсов дисковой памяти. Как правило, чем быстрее дисковая память, тем она дороже. Количество данных, хранимое в базах данных предприятий, слишком велико, чтобы оправдать покупку достаточного количества быстрых дисков для хранения полного содержания базы. Технология ILM создана, чтобы улучшить эффективной использования дисковой памяти и повысить производительность базы данных, делая базу более приспособленной к наличию разных уровней (скоростей) дисковой памяти. Используя возможности ILM, БД Oracle может переносить данные между типами дисковой памяти на основании частоты доступа к ним. С другой стороны, ILM может улучшить использование дисковой памяти за счет сжатия данных, к которым обращения редки. Сжимает или переносит данные ILM - целью является оптимизация ресурсов дисковой памяти при минимальном влиянии на производительность БД. Новая возможность Oracle, временная актуальность (Valid-Time Temporal Validity), позволяет создавать измерение временной актуальности. Данные для этого измерения хранятся в двух скрытых столбцах таблицы. Если в запросе к таблице не установлен фильтр по этим столбцам, то при выборке из таблицы строки будут выдаваться независимо от того, являются ли они временно актуальными. Временная актуальность не влияет на размер занимаемого таблицей пространства или производительность базы данных, она всего лишь вводит новые средства фильтрации.

61

Установка и использование временной актуальности Новая возможность Oracle 12c, временная актуальность, дает способ задать диапазон времени для каждой строки в таблицы, когда данные в ней актуальны для приложения. Диапазон времени, указывающий, что строка актуальна, может быть установлен пользователями или приложениями. В терминах ILM атрибуты актуальности определяют, когда данные актуальны и когда нет. При использовании этих атрибутов запрос может вернуть только строки, содержащие актуальные данные. Концепции, являющиеся основой модели временной актуальности, включают следующие понятия: Актуальное время (valid time) - Определенное пользователем временное представление. Примером актуального времени является время начала и завершения проекта, найма и увольнения работника. Таблицы с семантикой актуального времени - Таблицы, имеющие одно или более измерений, каждое из которых имеет начало и конец. Ретроспективные запросы актуального времени (Valid-time flashback queries) Возможность выполнять версионные и AS OF запросы. Использование актуального времени требует задания пары столбцов типа время-дата в таблице. Эти столбцы могут быть добавлены явно, или созданы неявно. Период временной актуальности может быть добавлен к таблице при ее создании или путем модификации существующей таблицы. В примере создается таблица со столбцами временной актуальности, отражающими период испытательного срока нового сотрудника. Никаких столбцов типа DATE явно не создается, но параметр PERIOD FOR создает эти столбцы неявно: SQL> CREATE TABLE probationary_emps ( emp_id NUMBER PRIMARY KEY, first_name VARCHAR2(20), last_name VARCHAR2(25), PERIOD FOR emp_probation); При отображении определения таблицы выводятся только столбцы EMP_ID, FIRST_NAME и LAST_NAME: SQL> DESCRIBE probationary_emps; Name Null? Type -------------- --------- -------------EMP_ID NOT NULL NUMBER FIRST_NAME VARCHAR2(20) LAST_NAME VARCHAR2(25)

Скрытые столбцы этой таблицы могут быть выведены в результате запроса к таблице USER_TAB_COLS: SQL> SELECT column_name, data_type, column_id AS CID, internal_column_id AS ICID, hidden_column AS HID 62

FROM user_tab_cols WHERE table_name = 'PROBATIONARY_EMPS'; COLUMN_NAME DATA_TYPE CID ICID HID -------------------- ---------------------------- --- ---- --EMP_PROBATION_START TIMESTAMP(6) WITH TIME ZONE 1 YES EMP_PROBATION_END TIMESTAMP(6) WITH TIME ZONE 2 YES EMP_PROBATION NUMBER 3 YES EMP_ID NUMBER 1 4 NO FIRST_NAME VARCHAR2 2 5 NO LAST_NAME VARCHAR2 3 6 NO

В результате выполнения следующего оператора вставки данных INSERT в таблицу будут добавлены две строки с началом и окончанием 90-дневного испытательного срока: SQL> INSERT INTO probationary_emps(emp_probation_start, emp_probation_end, emp_id, first_name, last_name) VALUES ('01-10-2013 12.00.01', '30-12-2013 12.00.01',1234, 'John', 'Doe'); SQL> INSERT INTO probationary_emps(emp_probation_start, emp_probation_end, emp_id, first_name, last_name) VALUES ('14-09-2013 12.00.01', '13-12-2013 12.00.01',5678, 'Fred', 'Rogers'); SQL> SELECT emp_id FROM probationary_emps; EMP_ID ---------1234 5678

При запросе таблицы с учетом скрытых столбцов выводятся только актуальные данные: SQL> SELECT emp_id FROM probationary_emps WHERE emp_probation_start < '20-SEP-2013 12.00.01' AND emp_probation_end > '20-SEP-13 2012.00.01'; EMP_ID ---------5678

Строго говоря, эта функциональность не делает ничего такого, что нельзя было бы сделать, добавляя обычные столбцы типа DATE к таблице. Но, в приложениях с большим количеством неактуальных данных, которые следует хранить по требованию регуляторов, использование этой функциональности может упростить программирование. Несколько более интересную функциональность обеспечивает PL/SQL пакет DBMS_FLASHBACK_ARCHIVE, содержащий процедуру ENABLE_AT_VALID_TIME. Это процедура может быть использована для установки видимости периода актуальности для запрашиваемого времени: SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time ('ASOF', '20-DEC-2013 12.00.01'); SQL> SELECT emp_id FROM probationary_emps; 63

EMP_ID ---------5678

Эта процедура может быть использована для установки видимости временных данных, чтобы указать актуальность данных для времени текущей сессии: SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('CURRENT'); SQL> SELECT emp_id FROM probationary_emps; no rows selected

Эта же процедура может быть использована для установки видимости временных данных, чтобы указать актуальность данных для всей таблицы ("по умолчанию"): SQL> EXECUTE DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time('ALL'); SQL> SELECT emp_id FROM probationary_emps; EMP_ID ---------1234 5678

64

Работа с внутренним архивированием строк (In-Database archiving) Встроенная возможность внутреннего архивирования строк позволяет сохранять строки данных в промышленной БД, но сделать их невидимыми для приложений. Эта функциональность может быть нужна для реализации требований регулятора при сохранении минимального влияния на производительность приложений. Архивированные строки могут быть сжаты для ускорения резервного копирования. Чтобы использовать внутреннее архивирование строк таблицы необходимо разрешить режим ROW ARCHIVAL для таблицы (команда SQL ALTER TABLE ROW ARCHIVAL;) и установить значение скрытого столбца ORA_ARCHIVE_STATE в ненулевое. Если параметр сессии ROW ARCHIVAL VISIBILITY установлен в ACTIVE, то отображаться будут только строки с нулевым значением ORA_ARCHIVE_STATE столбца. Если этот параметр установлен в ALL, то запросы будут возвращать как архивные, так не архивные строки таблицы. В примере приведен возможный сценарий использования: SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE; SQL> CREATE TABLE archival_example (col_1 NUMBERL, col_2 VARCHAR2(20)) ROW ARCHIVAL; SQL> INSERT INTO archival_ example (col1, col2) VALUES (1, 'Record One'); SQL> INSERT INTO archival_ example (col1, col2) VALUES (2, 'Record Two'); SQL> INSERT INTO archival_ example (col1, col2) VALUES (3, 'Record Three'); SQL> INSERT INTO archival_ example (col1, col2) VALUES (4, 'Record Four'); SQL> SELECT col1, col2, ora_archive_state FROM archival_example; COL_1 ----1 2 3 4

COL_2 -----------Record One Record Two Record Three Record Four

ORA_ARCHIVE_STATE -----------------0 0 0 0

SQL> UPDATE archival_ example SET ora_archive_state = '6' WHERE col_1 = 3; SQL> SELECT col_1, col_2, ora_archive_state FROM archival_example; COL_1 ----1 2 4

COL_2 -----------Record One Record Two Record Four

ORA_ARCHIVE_STATE -----------------0 0 0

SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL; SQL> SELECT SELECT col_1, col_2, ora_archive_state FROM archival_example; COL_1 ----1 2 3 4

COL_2 -----------Record One Record Two Record Three Record Four

ORA_ARCHIVE_STATE -----------------0 0 6 0

65

Аудит Включение и настройка унифицированного аудита В Oracle 11g и более ранних версиях записи аудита располагались в разных местах, что усложняло работу аудиторов. Новый объединенный (унифицированный) аудит объединяет информацию из нескольких источников и делает ее доступной в стандартном формате через представление UNIFIED_AUDIT_TRAIL словаря данных. Унифицированный аудит ведется в виде таблицы базы данных в схеме AUDSYS в табличном пространстве SYSAUX. Таблица аудита доступна только для чтения. Данные доступны пользователю SYS или пользователю с присвоенными ролями AUDIT_ADMIN или AUDIT_VIEWER. Роль AUDIT_ADMIN позволяет просматривать данные и создавать политики аудита. Роль AUDIT_VIEWER может только просматривать данные, но не может создавать или менять политики. В журнале унифицированного аудита содержатся данные из следующих источников: Унифицированные политики аудита и установки команды AUDIT. Записи тонкой настройки аудита (fine-grained audit record) DBMS_FGA. Oracle Real Application Security. Oracle Recovery Manager (аудит RMAN включается в журнал унифицированного аудита "по умолчанию"). Oracle Database Vault. Oracle Label Security. Oracle Data Mining. Oracle Data Pump. Oracle SQL*Loader Direct Load. Будучи настроенным, унифицированный аудит всегда остается включенным и не зависит от параметров инициализации, использовавшихся в предшествующих релизах. Если база данных запущена в режиме READ-ONLY, то записи аудита записываются в новые файлы операционной системы в директории $ORACLE_BASE/audit/$ORACLE_SID. С помощью представления V$OPTION можно определить, была ли произведена миграция на унифицированный аудит: SQL> SELECT value FROM v$option WHERE parameter = 'Unified Auditing'; PARAMETER VALUE ---------------- ---------Unified Auditing TRUE

Приведенный пример показывает, что унифицированный аудит был настроен. В противном случае будет выдано FALSE. Для вновь созданных 12c баз данных "по умолчанию" включен смешанный режим аудита посредством настроенной политики ORA_SECURECONFIG. Смешанный режим разрешает и традиционный (до 12c), и унифицированный аудит. Традиционный аудит задается параметром инициализации AUDIT_TRAIL. При установке его в значение отличное от NONE в 12c, традиционный и унифицированный журналы аудита начнут заполняться записями. Установки аудита могут быть применены к различным перемещаемым базам данных (PDB) или к контейнерной базе в целом в зависимости от типа политики. В среде арендованной базы данных каждая БД, включая корневую, имеет собственный журнал аудита. 66

Когда база данных предыдущего релиза модернизируется до 12c, необходимо вручную мигрировать на унифицированный аудит, если нужно пользоваться его преимуществами. Если унифицированный аудит разрешен, то это приведет к запрету традиционного аудита. Чтобы начать использование унифицированного аудита, нужно разрешить по крайней мере одну политику аудита. Для прекращения использования нужно запретить все политики унифицированного аудита. Предварительно настроенная политика ORA_SECURECONFIG изначально разрешена во вновь созданных базах 12c. В этой политике установлен аудит следующих действий: ADMINISTER KEY MANAGEMENT, ALTER ANY PROCEDURE, ALTER ANY SQL TRANSLATION PROFILE, ALTER ANY TABLE, ALTER DATABASE LINK, ALTER DATABASE, ALTER PLUGGABLE DATABASE, ALTER PROFILE, ALTER ROLE, ALTER SYSTEM, ALTER USER, AUDIT SYSTEM, CREATE ANY JOB, CREATE ANY LIBRARY, CREATE ANY PROCEDURE, CREATE ANY SQL TRANSLATION PROFILE, CREATE ANY TABLE, CREATE DATABASE LINK, CREATE DIRECTORY, CREATE EXTERNAL JOB, CREATE PLUGGABLE DATABASE, CREATE PROFILE, CREATE PUBLIC SYNONYM, CREATE ROLE, CREATE SQL TRANSLATION PROFILE, CREATE USER, DROP ANY PROCEDURE, DROP ANY SQL TRANSLATION PROFILE, DROP ANY TABLE, DROP DATABASE LINK, DROP DIRECTORY, DROP PLUGGABLE DATABASE, DROP PROFILE, DROP PUBLIC SYNONYM, DROP ROLE, DROP USER, EXEMPT ACCESS POLICY, EXEMPT REDACTION POLICY, GRANT ANY OBJECT PRIVILEGE, GRANT ANY PRIVILEGE, GRANT ANY ROLE, LOGMINING, LOGOFF, LOGON, PURGE DBA_RECYCLEBIN, SET ROLE, TRANSLATE ANY SQL В документации прямо указано, что системная привилегия TRANSLATE ANY SQL не может быть объектом аудита, но в состав предопределенной политики ORA_SECURECONFIG она включена. Запрет унифицированного аудита Перед запрещением унифицированного аудита нужно запретить все разрешенные политики. Это предотвратит переход базы данных в смешанный режим аудита. Для запрета унифицированного аудита нужно: Зарегистрироваться в базе данных как пользователь с ролью AUDIT_ADMIN, запросить представление AUDIT_UNIFIED_ENABLE_POLICIES (столбцы POLICY_NAME и ENABLE_OPT) и выполнить команду NOAUDIT POLICY для всех включенных политик. Подключиться к базе данных как пользователь с привилегией SYSDBA или SYSOPER. 67

Остановить базу командой SHUTDOWN IMMEDIATE Из командной строки запустить следующую команду $ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk uniaud_off ioracle Запустить из SQL*Plus базу данных командой STARTUP. "По умолчанию" записи аудита записываются в очереди SGA и периодически переписываются в таблицы схемы AUDSYS табличного пространства SYSAUX. Запись в очередь, т.н. отложенная запись, по сравнению с прямой записью на диск, значительно улучшает производительность процесса журналирования. Однако, если экземпляр завершился аварийно или по команде SHUTDOWN ABORT, то отложенная запись приведет к возможной потере части записей аудита. Если такое поведение неприемлемо, то нужно настроить прямую запись данных в таблицы аудита. Следует знать, что на активных БД это может повлиять на производительность. В контейнерной БД эта опция может быть установлена для каждой перемещаемой БД отдельно. Установить режим записи журнала аудит можно следующим образом: Нужно зарегистрироваться в базе данных посредством SQL*Plus пользователем с ролью AUDIT_ADMIN. Нужно установить параметр AUDIT_TRAIL_MODE с помощью пакета DBMS_AUDIT_MGMT в режим прямой записи в таблицу: SQL> BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE, DBMS_AUDIT_MGMT.AUDIT_TRAIL_IMMEDIATE_WRITE); END; / Для отложенной записи (записи в очередь): SQL> BEGIN DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY( DBMS_AUDIT_MGMT.AUDIT_TRAIL_UNIFIED, DBMS_AUDIT_MGMT.AUDIT_TRAIL_WRITE_MODE, DBMS_AUDIT_MGMT.AUDIT_TRAIL_QUEUED_WRITE); END; / В моменты, когда базы данных недоступна на запись, включая момент, когда экземпляр запущен, но БД закрыта или БД открыта в режиме "только чтение", записи аудита пишутся во внешние файлы в директории $ORACLE_BASE/audit/$ORACLE_SID. Содержимое этих файлов может быть загружено в базу данных с помощью процедуры DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES. Делается это так: 68

Нужно зарегистрироваться в базе данных посредством SQL*Plus пользователем с ролью AUDIT_ADMIN. Следует проверить, что база данных открыта на чтение/запись. Нужно запустить процедуру DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES. SQL> EXEC DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES; Записи аудита будут немедленно загружены в таблицы схемы AUDSYS и затем удалены из директории $ORACLE_BASE/audit/$ORACLE_SID.

69

Создание и включение политик аудита Унифицированная политика аудита представляет собой набор правил, которые отслеживают определенные аспекты поведения пользователей в базе данных. Политика создается командой CREATE AUDIT POLICY. В базе данных могут быть активными несколько политик унифицированного аудита. Они могут включать в себя и системные, и объектные опции одновременно. Команды SQL AUDIT и NOAUDIT соответственно включают и выключают политики аудита. Команды SQL AUDIT и NOAUDIT также позволяют включить аудит прикладного контекста. Можно вести аудит следующих типов активности: Активность учетных записей пользователей, включая административные записи пользователей, зарегистрировавшихся с привилегией SYSDBA, ролей и привилегий. Действия над объектами, т.е. удаление таблиц, запуск процедур и т.д. Создание, удаление изменение значений контекста. Действия Oracle Database Real Application Security, Oracle Recovery Manager, Oracle Data Mining, Oracle Data Pump, события "прямой загрузки" Oracle SQL*Loader, Oracle Database Vault и Oracle Label Security. Возможно наличие множества активных политик, но следует ограничивать количество активных политик. Синтаксис команды создания политики достаточно гибок, чтобы задать нужное количество параметров. Лучше группировать связанные опции в единую политику, нежели создавать несколько политик. Меньшее количество политик снижает накладные расходы при регистрации в базе данных, когда происходит загрузка политик в память UGA сессии. При этом также понижается потребление памяти UGA, и внутренняя проверка функциональности аудита становится более эффективной. При создании унифицированной политики аудита командой CREATE AUDIT POLICY база данных заносит ее в объекты класса, которыми владеет пользователь SYS, а не пользователь, создававший политику. Базисный синтаксис команды выглядит так: CREATE AUDIT POLICY policy_name { {privilege_audit_clause [action_audit_clause ] [role_audit_clause ]} | { action_audit_clause [role_audit_clause ] } | { role_audit_clause } }[ WHEN audit_condition EVALUATE PER {STATEMENT|SESSION|INSTANCE}] [CONTAINER = {CURRENT | ALL}]; Следующая команда создает политику, которая создает записи в журнале аудита в любой момент, когда исполняются команды, требующие привилегий ALTER ANY TABLE и DROP ANY TABLE, выданные через роль ocp_admin: SQL> CREATE AUDIT POLICY change_table_pol PRIVILEGES ALTER ANY TABLE, DROP ANY TABLE ROLES ocp_admin; После создания политики ее нужно включить командой AUDIT с параметром POLICY. Политика может быть приложена к одному и более пользователей, или ко всем пользователям за 70

исключением. Также возможно указать, будут ли писаться записи аудита при успешных действиях, неудачных действиях или независимо от успешности действий. Вновь созданная политика станет действовать только после установления пользователем новой сессии с базой данных. Если пользователи зарегистрированы в БД в тот момент, когда политика включена, то сбор данных невозможен до того момента, как пользователи зарегистрируются заново. Команда AUDIT поддерживает следующие дополнительные параметры: BY - используется для приложения политики к одному и более пользователям. AUDIT POLICY change_table_pol BY ocpuser. EXCEPT - используется для исключения пользователя из политики. AUDIT POLICY change_table_pol EXCEPT card1; WHENEVER SUCCESFUL - записывает только успешные выполнения политики. AUDIT POLICY change_table_pol WHENEVER SUCCESSFULL. WHENEVER NOT SUCCESFUL - записывает только неудачные выполнения политики. AUDIT POLICY change_table_pol WHENEVER NOT SUCCESSFULL. Следует отметить, что: WHENEVER - -Если параметр WHENEVER опущен, то и неуспешные, и успешные действия пользователя заносятся в журнал аудита. BY/EXCEPT - Политика может включена либо с опцией BY, либо с EXCEPT, но не с обеими одновременно. AUDIT ... BY - Если несколько команд AUDIT выполняются в одной и той же самой унифицированной политике для разных пользователей, то применяются все политики. AUDIT ... EXCEPT - Если несколько команд AUDIT выполняются в той же самой унифицированной политике для разных пользователей, то применяется только последнее исключение. COMMON policies - Общие политики могут быть включены только из корневого контейнера и только для общих пользователей. LOCAL policies - Локальные политики аудита могут быть включены только из перемещаемых баз данных, к которым они применяются. SQL> AUDIT POLICY ORA_DATABASE_PARAMETER except AAA; SQL> AUDIT POLICY ORA_DATABASE_PARAMETER except SYS, SYSTEM; В результате двух последовательных команд включения аудита не будут отслуживаться только действия пользователей SYS и SYSTEM. "По умолчанию" все события RMAN записываются в журнал унифицированного аудита. Представление UNIFIED_AUDIT_TRAIL содержит несколько полей, начинающихся на RMAN_ и используемых для записей событий RMAN автоматически. Специфичные для RMAN столбцы в UNIFIED_AUDIT_TRAIL включают: RMAN_SESSION_RECID - Идентификатор сессии RMAN. Совместно со столбцом RMAN_SESSION_STAMP. Это значение однозначно идентифицирует задание RMAN. 71

RMAN_SESSION_STAMP - Время сессии. RMAN_OPERATION - Операция RMAN, выполненная во время задания. RMAN_OBJECT_TYPE - Тип объектов, обрабатываемых во время сессии RMAN. RMAN_DEVICE_TYPE - Устройство, задействованное в данной сессии RMAN.

72

Привилегии Использование административных привилегий В версии Oracle 12c произошли некоторые изменения в составе системных привилегий. Большинство из них направлено на повышение безопасности базы данных за счет лучшего разделения функций. Считается, что принцип минимума привилегий, а именно, пользователь должен получать минимум привилегий для выполнения своих обязанностей, должен соблюдаться всегда. Появились три новых административных роли SYSBACKUP, SYSDG, SYSKM, отвечающих за резервное копирование и восстановление, функции высокой доступности и работу с ключами. Новые роли позволяют не выдавать роль SYSDBA для повседневных операций. SYSBACKUP - Эта роль позволяет пользователям Recovery Manager (RMAN) подключаться к целевой БД и выполнять операции резервирования/восстановления либо с помощью RMAN или SQL*Plus. SYSDG - Административная привилегия SYSDG используется для выполнения операций Data Guard. Эта привилегия может быть использована как с Data Guard Broker, так и с утилитой dgmgrl. Для того чтобы подключиться к БД, как SYSDG с использованием пароля, обязательно следует включить имя нужного пользователя в файл паролей. SYSKM - Административная привилегия SYSKM дает возможность пользователю выполнять операции Transparent Data Encryption. Для того чтобы подключиться к БД, как SYSKM с использованием пароля, обязательно следует включить имя нужного пользователя в файл паролей. Появилась новая системная привилегия, связанная с мусорной корзиной (recycle bin) DBA. В предыдущих версиях для очистки системной корзины требовалась привилегия SYSDBA. Новая привилегия PURGE DBA_RECYCLEBIN позволяет пользователям выполнить операцию PURGE DBA_RECYCLEBIN, не имея привилегию SYSDBA: SQL> sho user USER is "SYSTEM"

SQL> PURGE dba_recyclebin; purge dba_recyclebin * ERROR at line 1: ORA-01031: insufficient privileges

SQL> GRANT PURGE DBA_RECYCLEBIN TO system; Grant succeeded.

SQL> PURGE dba_recyclebin; DBA Recyclebin purged.

73

Привилегия SELECT ANY DICTIONARY теперь не дает возможности просматривать критичные таблицы словаря базы данных DEFAULT_PWD$, ENC$, LINK$, USER$, USER_HISTORY$ и XS$VERIFIERS. Это изменение повышает безопасность БД "по умолчанию", запрещая доступ к подмножеству таблиц словаря через привилегию SELECT ANY DICTIONARY. Начиная с Oracle 12c, привилегия UNLIMITED TABLESPACE не включена в роль RESOURCE. Это изменение повышает безопасность базы данных "по умолчанию", так как удаляет потенциальную возможность для пользователей и приложений, имеющих роль RESOURCE, превысить предполагаемые квоты ресурсов в табличных пространствах.

74

Создание, разрешение и анализ использования привилегий С помощью продукта Oracle Database Vault (платная опция) можно провести анализ привилегий. При анализе создается профиль пользователей базы данных, в котором будет сохранен список всех использованных системных и объектных привилегий. Результат может быть использован при аудите используемых и выданных привилегий. На основе этой информации количество выданных привилегий может быть уменьшено до только необходимых для выполнения обязанностей. Анализ привилегий помогает повысить безопасность БД путем определения неиспользуемых или избыточных привилегий. Возможно выполнение анализа привилегий как с включенным и настроенным Oracle Database Vault, так и без его включения и настройки. Администрировать анализ привилегий можно либо из Enterprise Manager Cloud Control, либо используя пакет PL/SQL DBMS_PRIVILEGE_CAPTURE. Чтобы воспользоваться этой возможностью, пользователю должна быть присвоена привилегия CAPTURE_ADMIN, позволяющая выполнить пакет DBMS_PRIVILEGE_CAPTURE, и привилегия SELECT на представления, содержащие результат анализа. Пакет DBMS_PRIVILEGE_CAPTURE позволяет создавать, включать, выключать и удалять политики анализа привилегий. Он также создает отчеты, показывающие использование привилегий, доступные через представления словаря данных. Общий алгоритм действий при анализе привилегий состоит из нескольких шагов. Следует: Определить политику анализа привилегий. SQL> BEGIN DBMS_PRIVILEGE_CAPTURE.CREATE_CAPTURE( name => 'ocprep_dev_role_pol', description => 'Captures ocprep_dev role use', type => DBMS_PRIVILEGE_CAPTURE.G_ROLE, roles => role_name_list('DBA', 'RESOURCE'); END; / Включить политику анализа привилегий и запись используемых привилегий. SQL> EXEC DBMS_PRIVILEGE_CAPTURE.ENABLE_CAPTURE ('ocprep_dev_role_pol'); Выключить запись используемых привилегий. SQL> EXEC DBMS_PRIVILEGE_CAPTURE.DISABLE_CAPTURE ('ocprep_dev_role_pol'); Выполнить анализ результатов. SQL> EXEC DBMS_PRIVILEGE_CAPTURE.GENERATE_RESULT ('ocprep_dev_role_pol'); SQL> SELECT username, sys_priv, object_owner, object_name FROM dba_used_privs WHERE capture = 'ocprep_dev_role_pol'; Удалить политику анализа привилегий (необязательно) SQL> EXEC DBMS_PRIVILEGE_CAPTURE.DROP_CAPTURE ('ocprep_dev_role_pol'); 75

В базе данных может быть активна только одна единственная политика анализа привилегий. Единственным исключением из этого правила является политика типа DBMS_PRIVILEGE_CAPTURE.G_DATABASE, которая может быть включена одновременно с анализом привилегий другого типа. Если анализ привилегий был включен до остановки экземпляра, то он будет включен после нового запуска. Чтобы создать отчет о привилегиях необходимо, чтобы анализ привилегий должен быть выключен. Как только анализ привилегий завершен, можно удалить политику анализа. Удалить можно только неактивную политику. Удаление политики анализа привилегий также удаляет все записи об используемых и неиспользуемых привилегиях, связанных с этой политикой. Невозможно анализировать использование привилегий пользователем SYS. Ниже приведена часть представлений, связанных с анализом привилегий, для полной информации следует обратиться к руководству Oracle по Oracle Database Vault: DBA_PRIV_CAPTURES - Содержит информацию о существующих политиках анализа привилегий. DBA_USED_PRIVS - Содержит список привилегий, которые были использованы в отчетах политик анализа привилегий. DBA_UNUSED_PRIVS - Содержит список привилегий, которые не были использованы в отчетах политик анализа привилегий. DBA_USED_OBJPRIVS - Содержит список объектных привилегий, которые были в отчетах политик анализа привилегий. Не включает путей к объектам (если применимо). DBA_UNUSED_OBJPRIVS - -- Содержит список объектных привилегий, которые не были в отчетах политик анализа привилегий. Не включает путей к объектам (если применимо). DBA_USED_SYSPRIVS - Содержит список системных привилегий, которые были в отчетах политик анализа привилегий. Не включает путей к системным объектам (если применимо). DBA_UNUSED_SYSPRIVS - Содержит список системных привилегий, которые не были отчетах политик анализа привилегий. Не включает путей к системным объектам (если применимо).

76

Редактирование (redaction) данных Oracle Применение и управления политиками редактирования данных Oracle Редактирование данных Oracle дает возможность заменять "на лету" данные, возвращаемые в результате запроса до отображения внутри приложения. Сами данные, содержащиеся в БД, не изменяются. Это гарантирует, что неуполномоченные пользователи не увидят важную информацию. Редактирование данных Oracle обеспечивает целостное редактирование значений столбцов для модулей приложений, получающих доступ к одной и той же информации БД. Редактирование данных позволяет редактировать значение столбцов любым из следующих методов: Полное редактирование (Full redaction) - Все содержимое столбца подвергается редактированию. Отредактированное значение, возвращаемое в результате запроса, зависит от типа данных. Для столбцов типа NUMBER возвращается ноль (0), для символьных - одиночный пробел. Частичное редактирование (Partial redaction) - Только часть данных подвергается редактированию. Например, можно редактировать большую часть номера банковского счета с знаком №, за исключением последних 4 символов. Регулярные выражения (Regular expressions) - Регулярное выражение может использоваться для поиска шаблона и замены части данных. Разработано исключительно для работы с текстовыми данными. Применимо для данных переменной длины. Случайное редактирование (Random redaction) - Отредактированные данные представлены случайно сгенерированными последовательностями, зависящими от типа столбца. Без редактирования (No redaction) - Тип редактирования ‘None’ используется для тестирования операций политики. В этом случае никакого редактирования данных не происходит. Политика редактирования данных определяется способ, как данные будут замаскированы, включая: Тип редактирования (Full, Partial, Random и т.д). Как происходит редактирование (для частичного редактирования определяется, какая часть данных редактируется). Когда происходит редактирование (для каких пользователей будут видны редактированные, для каких актуальные данные). Для создания и управления политиками редактирования данных нужно иметь привилегию EXECUTE на PL/SQL пакет DBMS_REDACT. В пакет включены следующие процедуры: DBMS_REDACT.ADD_POLICY - Добавляет политику редактирования к таблице или представлению. DBMS_REDACT.ALTER_POLICY - Изменяет политику редактирования DBMS_REDACT.UPDATE_FULL_REDACTION_VALUES - Изменяет значение редактирования для полного редактирования данного типа данных. Для начала использования нового значения нужно перезапустить экземпляр. 77

DBMS_REDACT.ENABLE_POLICY - Включает политику редактирования. DBMS_REDACT.DISABLE_POLICY - Выключает политику редактирования. DBMS_REDACT.DROP_POLICY - Удаляет политику редактирования. Политика полного редактирования (full data redaction) редактирует содержание столбца целиком. "По умолчанию", столбцы типа NUMBER замещаются нулем (0), а столбцы типа VARCHAR2 одиночным пробелом. Процедура UPDATE_FULL_REDACTION_VALUES используется для замены этих значений. В примере показано использование полного редактирования значений столбца EDI_NUM в таблице EDIGAS.EDI_DATA. Параметр "expression" применяет политику к любому пользователю, обращающемуся к таблице, за исключением тех, кто обладает системной привилегией EXEMPT REDACTION POLICY. Пользователи SYS и SYSTEM автоматически имеют привилегию EXEMPT REDACTION POLICY. Это означает, что оба этих пользователя всегда могут обойти любую существующую политику редактирования данных и всегда имеют возможность видеть данные в таблицах или представлениях с наложенными политиками. Политики редактирования, созданные для таблицы или представления, будут применяться к любому представлению, созданному на их основе, включая материальные представления. Политика редактирования будет использоваться на всю длину цепи представлений (представление, созданное на основе другого представления), созданных на основе материнской таблицы или представления. Если для какого-либо зависимого представления создана новая политика редактирования, то для любого из столбцов этого представления и зависимых от него представлений будет использоваться эта новая политика. SQL> BEGIN DBMS_REDACT.ADD_POLICY( object_schema => 'edigas', object_name => 'edi_data', column_name => 'edi_num', policy_name => 'redact_edi_num', function_type => DBMS_REDACT.FULL, expression => '1=1'); END; / При создании политики редактирования параметр "expression" процедуры DBMS_REDACT.ADD_POLICY определяет условия приложения политики. Если этот параметр TRUE, то политика прикладывается. Логическое выражение должно быть основано на одной из следующих функций: SYS_CONTEXT - Эта функция должны быть указана с допустимым пространством имен. Пространством имен "по умолчанию" для SYS_CONTEXT является USERENV. Оно включает такие значения как SESSION_USER и CLIENT_IDENTIFIER. Application Express function - Можно использовать либо V, или NV свертки (для функций APEX_UTIL.GET_SESSION_STATE и APEX_UTIL.GET_NUMERIC_SESSION_STATE соответственно) как части выражения. 78

Выражение должно быть построено с учетом следующего: Допустимо использование только следующих операторов =, !=, >, =, 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''IUS''' Роль - Можно включить/выключить политику с помощью пространства имен SYS_SESSION_ROLES на основании роли. Значение атрибута установлено в TRUE, если указанная роль активна для пользователя/приложения, и FALSE, если роль неактивна. В примере любой пользователь приложения с активной ролью AIS_ADMIN видит актуальные данные, но для остальных данные редактируются: expression => 'SYS_CONTEXT(''SYS_SESSION_ROLES'',''AIS_ADMIN'') = ''FALSE''' Без фильтрации (No Filtering) - Политика может применяться независимо от контекста к любому пользователю, за исключением SYS, SYSTEM или имеющего привилегию EXEMPT REDUCTION POLICY. В примере показано условие применения политики к любому пользователю (с учетом описанных ранее исключений): expression => '1=1' Присвоение доверенным пользователям привилегии EXEMPT REDUCTION POLICY исключает их из всех политик редактирования Oracle. Лицо, создающее политику редактирования, не исключается из нее, за исключением, если пользователь является SYS или обладает привилегией EXEMPT REDUCTION POLICY. Привилегия EXEMPT REDUCTION POLICY включена в роль DBA. Однако эта привилегия должна быть выдана пользователям явно, поскольку она не имеет параметра WITH ADMIN OPTION в роли DBA. При использовании частичного редактирования редактируется только часть данных. Часть цифр, например, номер банковского счета, может быть замещена звездочками за исключением четырех последних, например, ********1234. Можно создать политику для столбцов, использующих текстовой, числовой тип данных или тип дата-время. Для политик, редактирующих текстовой тип данных, существует набор предопределенных макроопределений редактирования. Некоторые из доступных макроопределений, типичных для американского рынка: DBMS_REDACT.REDACT_US_SSN_F5 - Редактирует первые 5 цифр номера социально страхования или чего-то похоже на него, если столбец имеет тип VARCHAR2. Т.е., номер 123-45-6789 отображается как XXX-XX-6789. 79

DBMS_REDACT.REDACT_US_SSN_L4 - Редактирует последние 4 цифры номера социально страхования, если столбец имеет тип VARCHAR2. Т.е., номер 123-45-6789 отображается как 123-45-XXXX. DBMS_REDACT.REDACT_US_SSN_ENTIRE - Редактирует весь номер социально страхования, если столбец имеет тип VARCHAR2. Т.е., номер 123-45-6789 отображается как XXX-XX-ХХХХ. DBMS_REDACT.REDACT_ZIP_CODE - Редактирует первые 5-значный номер почтового индекса, если столбец имеет тип VARCHAR2. Т.е., номер 12345 отображается как XXXXX. DBMS_REDACT.REDACT_DATE_MILLENNIUM - Редактирует даты в формате ДД-МОН-ГГ в вид 01-JAN-00 (January 1, 2000). DBMS_REDACT.REDACT_DATE_EPOCH - Редактирует все даты в 01-JAN-70. В примере показано создание политики редактирования номера в столбце типа VARCHAR2 с применением макроопределения REDACT_US_SSN_L4: SQL> BEGIN DBMS_REDACT.ADD_POLICY( object_schema => 'edigas', object_name => 'edi_data', column_name => 'edi_nn', policy_name => 'redact_cust_edi_nn', function_type => DBMS_REDACT.PARTIAL, function_parameters => DBMS_REDACT.REDACT_US_SSN_L4, expression => '1=1', policy_description => 'Partially redacts last 4 numbers in EDI numbers'); END; /

80

RMAN и ретроспективный архив данных Применение расширений RMAN Функциональность менеджера восстановления (RMAN) Oracle 12c была расширена по сравнению с предыдущими версиями. Наиболее важные расширения описаны ниже. Восстановление отдельных таблиц из резервных копий С точки зрения администратора БД возможность восстановления отдельных таблиц из резервных копий является одним из самых приятных нововведений. Теперь с помощью RMAN можно скопировать и восстановить таблицу или их набор одной командой RECOVER TABLE. До появления этой команды восстановление отдельных таблиц с использованием резервных копий RMAN было весьма трудоемким делом. Нужно было скопировать и восстановить требуемое табличное пространство в отдельное новое место на диске, выполнить экспорт нужных таблиц, а затем импортировать их в исходную БД. В реальных промышленных системах часто приходилось помимо резервного копирования периодически выполнять полный экспорт БД, как обязательную часть стратегии резервирования, чтобы восстановление отдельных таблиц было менее болезненным. Следует, однако, помнить, что для реализации этой опции необходимо весьма значительное свободное дисковое пространство. Интерфейс командной строки RMAN Функциональность командной строки RMAN расширена за счет возможности выполнять SQL команды без указания предшествующего ключевого слова SQL. Для небольшого количества команд, которые существуют и в RMAN, и SQL*Plus и при этом имеют различное назначение, использование ключевого слова SQL по-прежнему возможно и даже необходимо с целью избежать неоднозначности. Стало возможно использовать команду DESCRIBE для получения информации о таблицах и представлениях из командной строки RMAN. Дупликация активной базы данных Активная дупликация это метод восстановления БД по сети, при котором клонируется исходная база данных. Дополнительная (auxiliary) БД подключается к целевой БД и извлекает архивные наборы данных по сети. Этот метод отличается от копирования образов данных целевой БД, который использовался в предыдущих релизах. Новый метод снижает нагрузку на обработку данных целевой БД. Он делает возможным использование сжатия неиспользуемых блоков при дупликации, что уменьшает размер передаваемых архивов. Активная дупликация поддерживает опцию размера секции, что позволяет разделить файлы данных на части. Эти части используются для параллельного восстановления вспомогательной БД. Опция NOOPEN для дупликации Новая опция NOOPEN команды DUPLICATE запрещает автоматическое открытие восстановленной клонированной базы данных. Эта возможность позволяет выполнить изменения любых параметров БД до ее открытия. Это свойство полезно также в случае, когда БД не должна быть открыта с опцией RESETLOGS до запуска скриптов обновления. RMAN> DUPLICATE TARGET DATABASE TO newdb FROM ACTIVE DATABASE NOOPEN;

81

Многосекционные копии образа (Multisection Image Copies) Копирование образа файлов данных может выполняться с опцией SECTION SIZE для разделения файлов данных на несколько секций параллельно по нескольким каналам. Это возможность снижает время создания копии образа больших файлов данных. RMAN> BACKUP AS COPY SECTION SIZE 100M DATABASE; Многосекционные инкрементальные резервные наборы Инкрементальные резервные наборы могут быть выполнены с параметром SECTION SIZE, чтобы разделить файлы данных на секции, которые могут быть архивированы параллельно по нескольким каналам. Этот подход снижает время инкрементального резервирования больших файлов данных. RMAN> BACKUP INCREMENTAL LEVEL 1 SECTION SIZE 100M DATAFILE ’/u01/oracle/X/datafiles/users_01.dbf’; Оптимизация моментального снимка дисковой памяти (Storage Snapshot Optimization) Эта возможность делает возможным использование технологий сторонних фирм для выполнения снимков дисковой памяти базы данных без предварительного перевода ее в режим BACKUP. Режим резервного копирования может привести к дополнительным накладным расходам системных ресурсов и ресурсов ввода/вывода из-за необходимости писать полные образы блоков в журналы-redo. С этой новой возможностью снимки дисковой памяти сторонних производителей, удовлетворяющие следующим требованиям, могут быть выполнены без требования перевода БД в режим резервирования: База данных является аварийно-непротиворечивой (crash consistent) выполнения снимка. Последовательность записи сохранена для каждого файла внутри снимка. Снимок хранит время завершения снимка.

в момент

В команде RECOVER введено ключевое слово SNAPSHOT TIME, позволяющее восстановить снимок к точке непротиворечивости без каких-либо дополнительных ручных процедур для восстановления на требуемый момент времени. Этот снимок затем может быть использован для восстановления всей или части базы.

82

Новые возможности ретроспективных архивов (Flashback Data Archive) В версии 12с расширилась функциональность ретроспективных архивов Oracle - Oracle Flashback Data Archive (FDA). Появились следующие возможности: Отслеживание пользовательского контекста (User-context tracking) - Пользовательский контекст теперь стал частью метаданных, сохраняемых при отслеживании транзакций, поэтому стало намного проще определить, кто внес изменения, и какие изменения были внесены в таблице. Процедура SET_CONTEXT_LEVEL пакета DBMS_FLASHBACK_ARCHIVE используется для установки уровня контекста пользователя, а GET_CONTEXT_LEVEL - для доступа к этой информации. В примере устанавливается типичный TYPICAL контекст, что включает в себя ID пользователя, глобальный ID пользователя и имя хоста: SQL> BEGIN DBMS_FLASHBACK_ARCHIVE.SET_CONTEXT_LEVEL ('TYPICAL'); END; / Усиление базы данных (Database hardening) - Набор таблиц может быть объединен в понятие "приложение". В дальнейшем можно включить ретроспективную архивацию данных для всего этого набора одной командой. Также возможно закрыть, т.е. сделать read-only, полный набор таблиц одной командой, что предотвратит DML операции над набором до того, как он будет открыт. Это возможность упрощает мониторинг и защиту группы логически связанных таблиц с важными данными. Процедура REGISTER_APPLICATION пакета DBMS_FLASHBACK_ARCHIVE используется, чтобы зарегистрировать приложения для усиления БД. Для детального описания следует обратиться к руководству Oracle Database PL/SQL Packages and Types Reference. История экспорта и импорта - Процедуры пакета DBMS_FLASHBACK_ARCHIVE можно использовать для создания временной исторической таблицы. Временная таблица может быть загружена желаемыми историческими данными тем или иным образом, включая Data Pump. Однажды заполненные, данные во временной исторической таблице могут быть импортированы в назначенную историческую таблицу. Также имеется поддержка для пользовательской истории, если для поддержки исторических данных использовался механизм триггеров. Для детального описания следует обратиться к руководству Oracle Database PL/SQL Packages and Types Reference.

83

Отслеживание операций базы данных в реальном времени Реализация отслеживания операций базы данных в реальном времени Операция базы данных это группа связанных задач базы данных, определенных конечным пользователей или приложением. Примером операции является ETL обработка, пакетное задание или транзакция из нескольких SQL-операторов. Операции базы данных могут быть простыми и составными: Простые - Простые операции представляют собой одиночный SQL оператор или PL/SQL процедуру/функцию. Составные (Композитные) - Композитные операции включают в себя все действия между двумя моментами времени в сессии БД с отдельным началом и концом для каждой сессии. Сессия может участвовать только в одной композитной операции. Впервые отслеживание операций было представлено в Oracle 11g, тогда поддерживалась возможность отслеживания только простых операций. Начиная с версии 12c, появилась возможность отслеживать составные операции. БД Oracle автоматически отслеживает параллельные запросы, DML и DDL операторы после начала их выполнения. "По умолчанию" отслеживание операций в реальном времени включается, если а) SQL запрос занимает более 5 секунд процессорного времени или времени системы ввода/вывода при одиночном выполнении (т.н. "дорогая" операция) или б) запрос выполняется параллельно. Данные, полученные при отслеживании SQL операций в реальном времени, могут быть доступны на странице "Monitored SQL Executions" в Enterprise Manager Cloud Control, через представления словарей базы данных, или с помощью пакета DBMS_MONITOR. Страница "Monitored SQL Executions" находится в меню Performance. На этой странице обобщается активность отслеживаемых команд, и она является рекомендуемым средством для работы с мониторингом SQLкоманд в реальном времени. С ее помощью можно также получить детальную информацию об отдельных командах. Для отслеживания SQL-команд в реальном времени используются следующие представления словаря данных: V$SQL_MONITOR - Представление содержит общую информацию о наиболее частых SQL операторах в операциях базы данных. Данные о каждом из отслеживаемых операторов содержатся в отдельной записи. Каждая такая строка представления содержит SQLоператор, статистики которого накоплены по нескольким сессиям и по всем его выполнениям во время операции. В качестве первичного ключа используется сочетание столбцов DBOP_NAME, DBOP_EXEC_ID и SQL_ID. V$SQL_MONITOR_SESSTAT - Представление содержит статистики для всех сессий, включенных в операцию базы данных. Большинство статистик являются накопительными. База данных запоминает статистики в формате XML, а не в виде " статистика - столбец". Это представление предназначено для создания отчетов. V$SQL_PLAN_MONITOR - Это представление содержит отслеживаемую статистику для каждого шага в плане выполнения отслеживаемого SQL-оператора. База данных заносит 84

статистки в V$SQL_PLAN_MONITOR каждую секунду во время выполнения SQL-запроса. Для каждого отслеживаемого запроса в V$SQL_PLAN_MONITOR существуют множественные записи. Каждая запись соответствует шагу в плане выполнения запроса. С помощью пакета DBMS_SQL_MONITOR можно задать начало и конец операции базы данных, а также создать отчет об операции. В пакет входят процедуры: REPORT_SQL_MONITOR - Процедура получает на входе несколько параметров, определяющих выполнение, степень детализации и тип отчета. Без параметров процедура создает текстовый отчет о последней отслеживаемой операции. BEGIN_OPERATION - Функция отмечает начало композитной операции базы данных в текущей сессии. END_OPERATION - Процедура отмечает конец композитной операции базы данных в текущей сессии. DBMS_MONITOR.BEGIN_OPERATION( dbop_name IN VARCHAR2, dbop_eid IN NUMBER := NULL, force_tracking IN VARCHAR2 := NO_FORCE_TRACKING, attribute_list IN VARCHAR2 := NULL) RETURN NUMBER; Функция BEGIN_OPERATION используется для отмечания начала композитной операции. На входе нужно задать следующие параметры: dbop_name - Имя операции. dbpop_eid - Уникальный номер, необходимый, чтобы различать выполнения (параметр необязателен). force_tracking - FORCE_TRACKING заставляет базу данных отслеживать все операторы, независимо от продолжительности или интенсивности ввода/вывода. "По умолчанию" используется опция NO_FORCE_TRACKING, что требует отслеживать только "дорогие" операции (параметр необязателен). attribute_list - Список параметров в форме "имя-значение", разделенных запятыми, например, table_name=emp, operation=load. (параметр необязателен). Отслеживание SQL операторов разрешено, если параметр инициализации STATISTICS_LEVEL установлен в TYPICAL или ALL. В этом случае Oracle начнет отслеживать длинные операции автоматически. Параметр инициализации CONTROL_MANAGEMENT_PACK_ACCESS должен быть установлен в DIAGNOSTIC+TUNING ("по умолчанию"), чтобы использовать отслеживание SQLоператоров. Для разрешения/запрещения отслеживания SQL-операторов можно использовать т.н. хинты. Хинт MONITOR включает отслеживание, а хинт NO_MONITOR выключает. Например, первый оператор включает отслеживание, а второй выключает его: SQL> SELECT /*+ MONITOR */ first_name, last_name, email FROM employees; SQL> SELECT /*+ NO_MONITOR */ first_name, last_name, email FROM employees; 85

Можно явно создать операцию в базе данных, задав ее начало и конец с помощью пакета DBMS_SQL_MONITOR. Операция базы данных начинается функцией BEGIN_OPERATION и завершается процедурой END_OPERATION. Для создания операции базы данных нужно: Запустить SQL*Plus и подключиться к БД с достаточным уровнем привилегий. Определить переменную для хранения идентификатора выполнения (execution ID). SQL> var op_id NUMBER; Начать операцию базы данных. Имя операции my_op. SQL> EXEC :op_id := DBMS_SQL_MONITOR.BEGIN_OPERATION('my_op'); Выполнить нужные запросы, которые войдут в операцию. SQL> SELECT COUNT(*) FROM hr.employees; SQL> SELECT COUNT(*) FROM hr.departments; Завершить операцию базы данных. SQL> EXEC DBMS_SQL_MONITOR.END_OPERATION(' my_op ', :op_id); Убедится, что операция завершена. SQL> SELECT dbop_name, status FROM v$sql_monitor WHERE dbop_name = ' my_op '; DBOP_NAME STATUS ---------- --------my_op DONE

Создать отчет по выполнению операции.

86

Настройка SQL Использование адаптивных планов выполнения Новая возможность Oracle 12c - адаптивная оптимизация запросов (Adaptive Query Optimization), позволяет оптимизатору менять планы выполнения во время выполнения запроса и получать дополнительную информацию, которая помогает улучшить статистики. Существует два аспекта в адаптивной оптимизации запросов: Адаптивные планы (Adaptive Plans) - Эта возможность нацелена на улучшение плана начального/первого выполнения запроса во время выполнения. Адаптивные статистики (Adaptive Statistics) - Эта функция предназначена для обеспечения дополнительных статик, чтобы улучшить последующие выполнения запроса. Адаптивные планы Адаптивные планы позволяют оптимизатору принять окончательное решение о выборе плана выполнения SQL-запроса во время выполнения. План, выбранный оптимизатором до выполнения, создан на основании собранных статистик. Если во время выполнения оптимизатор обнаружит, что оценка кардинальности сильно отличается от действительного количества строк в выборке, то план или его часть может быть автоматически адаптирована (изменена) во время выполнения. Оптимизатор может предварительно определить несколько потенциальных подпланов для частей плана так, что он может выбрать метод выполнения запроса "на лету". Во время выполнения запроса сборщик статистики отслеживает и буферизирует строки, полученные при выполнении части плана. На основании собранных данных оптимизатор принимает окончательное решение, какой подплан будет использоваться. Как только оптимизатор выбрал окончательный план, сборщик статистики останавливает сбор статистик и буферизацию строк, и просто пропускает строки. На последующих выполнениях дочернего курсора оптимизатор запрещает буферизацию строк и выбирает тот же окончательный план. Если план выполнения изменен адаптивным оптимизатором запросов, то результат команды EXPLAIN PLAN будет отличен от результата функции DBMS_XPLAN.DISPLAY_CURSOR. Команда EXPLAIN PLAN покажет только начальный или план "по умолчанию", выбранный оптимизатором. Результат DBMS_XPLAN.DISPLAY_CURSOR будет содержать окончательный план, использованный оптимизатором. Все операции в адаптивном плане, включая точки сбора статистики с использованием DBMS_XPLAN, можно просмотреть. Добавление параметра форматирования "+adaptive" приведет к появлению дополнительного примечания (нотации) "-" в колонке id плана. Это указывает, что эти действия плана не были активны, т.е. не использовались. Средство SQL Monitor в Oracle Enterprise Manager всегда показывает полный адаптивный план, но не указывает, какие операции в плане были неактивны. В представление V$SQL введен новый столбец (IS_RESOLVED_ADAPTIVE_PLAN), указывающий на то, что SQL оператор имеет адаптивный план, и определен ли этот план полностью или нет. Если значение столбца "Y", то план является адаптивным, и окончательный план выбран. Если значение

87

"N", то выбранный план является адаптивным, но окончательный план еще не выбран. Для неадаптивных планов в столбце IS_RESOLVED_ADAPTIVE_PLAN содержится значение NULL. Если параметр инициализации OPTIMIZER_ADAPTIVE_REPORTING_ONLY установлен в TRUE (значение "по умолчанию" FALSE), то информация, необходимая для включения адаптивных методов объединения планов будет собираться, но каких-либо действия по изменению планов делаться не будет. При установке в TRUE будет использоваться план "по умолчанию", но информация, как следует изменить план, собираться будет. Ее можно увидеть с помощью DBMS_XPLAN, задав дополнительный параметр форматирования '+report'. Адаптивные статистики Чтобы построить хорошие планы выполнения, оптимизатор опирается на статистики. Иногда, однако, некоторые предикаты запросов слишком сложны, чтобы опираться только на статистику отдельных таблиц. Во время компиляции SQL-запроса оптимизатор определяет, можно или нет построить хороший план выполнения на имеющихся статистиках. Если нет, то используется динамическая выборка, чтобы скомпенсировать отсутствующую или недостаточную статистику. Если одна и более таблиц не имеет статистик, то динамическая выборка соберет для них базисную статистику. В Oracle 12c динамическая выборка была существенно расширена и стала динамической статистикой. Динамическая статистика может определить более точные оценки количества элементов выборки не только для одиночной таблицы, то и для соединений и групповых предикатов "GROUP BY". Для инициализационного параметра OPTIMIZER_DYNAMIC_SAMPLING введен новый уровень 11. При установке параметра на этот уровень, оптимизатор может решить использовать динамические статистики для любого SQL оператора, даже при наличии всех базисных статистик для таблиц. Решение, использовать ли динамические статистики, основывается на уровне сложности используемого предиката, существующих статистиках базы и полном ожидаемом времени выполнения SQL-запроса. На уровне 11, динамическая выборка будет в большинстве происходить чаще и увеличит время разбора. Чтобы снизить влияние на производительность, результаты запросов динамической выборки будут сохраняться в кэше для совместного использования с другими SQLзапросами. Автоматическая оптимизация создана для улучшения плана выполнения запроса после первого выполнения. В момент завершения первого выполнения SQL запроса оптимизатор определяет, отличается ли информация о выполнении от исходных оценок. Если это так, то оптимизатор ищет новый план для последующего выполнения. Автоматическая оптимизация является итерационным процессом, оптимизатор может проводить оптимизацию несколько раз, с каждым разом узнавая больше и улучшая план выполнения. Oracle 12c поддерживает несколько форм реоптимизации: Отклик по статистике (Statistics feedback) - Оптимизация, формально известная, как отклик по количеству элементов выборке (cardinality feedback), создана для улучшения планов запросов, результаты которых сильно отличны от оценок. Оптимизатор сравнивает исходную оценку количества элементов для SQL-запроса с действительным результатом, полученным по итогам выполнения. Если оценка и результат сильно отличаются, то 88

правильные оценки сохраняются для последующего использования. Оптимизатор также создает директиву SQL плану, поэтому другие SQL-операторы могут получить выгоды от данных, полученных при первом выполнении. Отклик по производительности (Performance Feedback) - Этот тип позволяет улучшить степень параллелизма для повторяющихся SQL-запросов при разрешенной опции Automatic Degree of Parallelism (AutoDOP) в адаптивном режиме. Во время первого выполнения SQL-оператора оптимизатор определяет, нужно ли использовать параллелизм выполнения. По завершении первого выполнения использованная степень параллелизмы сравнивается с вычисленной на основе статистики реальной производительности, собранной во время выполнения. Если они сильно отличаются, то оператор помечается для реоптимизации, и статистики сохраняются для более точного определения степени параллелизма DOP для последующих выполнений. Директивы планов SQL (SQL plan directives) --Директивы планов SQL это дополнительная информация и инструкции, используемые оптимизатором для построения наиболее оптимальных планов выполнения. Они создаются для выражений запросов нежели на уровне операторов или объектов, поэтому они применимы ко многим SQL-операторам. Несколько директив могут использоваться для единственного SQL-оператора. Директивы планов SQL обслуживаются автоматически и хранятся в табличном пространстве SYSAUX. Любая директива плана SQL, которая не использовалась более 53 недель, удаляется автоматически. Состояние директивы отображается в представлениях DBA_SQL_PLAN_DIRECTIVES и DBA_SQL_PLAN_DIR_OBJECTS. Использование расширенных возможностей сбора статистики Процесс сбора инкрементальной статистики получил два существенных улучшения. Инкрементальные статистики остаются верными при сборе на секционированных таблицах. Для секционированных таблиц база данных Oracle должна собрать статистику на уровне таблицы и секции. Существует возможность вычислить статистики глобального уровня путем агрегирования статик уровня секции, убрав, таким образом, необходимость просмотра всей таблицы для построения глобальной статистики. До версии 12c при использовании инкрементальных статистик для таблицы изменение в секции приводило к тому, что статистики для всей таблицы становились устаревшими. Эти статистики не могли быть использованы для создания глобальных статистик до момента пересоздания. Новый параметр INCREMENTAL_STALENESS позволяет администратору определить, когда статистики секции будут считаться устаревшими. "По умолчанию" он установлен в NULL, при этом статистики считаются устаревшими при изменении одной записи в секции. Параметр может принимать следующие значения: USE_STALE_PERCENT - Статистика уровня секции не будет считаться устаревшей пока доля измененных строк меньше, чем значение параметра STALE_PERCENTAGE (10% "по умолчанию"). USE_LOCKED_STATS - Если статистики секции являются постоянными (locked), то они будут использоваться для создания глобальных статистик независимо от того, сколько строк было изменено с момента последнего сбора статистики. 89

Второе улучшение инкрементальных статистик включает в себя возможность обмена секциями. Команда обмена секции обменивает данные между обычной таблицей и указанной секцией секционированной таблицы. Физически данные не переносятся, фактически производится модификация словаря, а именно, указатель секции меняется на указатель таблицы и наоборот. До версии 12c не было возможности собрать статистику с поддержкой инкрементальности на несекционированной таблице. Ранее статистики должны были быть собраны после операции обмена. В 12с статистики могут быть собраны на несекционированной таблице до операции обмена. После обмена, эти данные могут сразу быть использованы для обслуживания глобальных инкрементальных статистик. Новый параметр INCREMENTAL_LEVEL пакета DBMS_STAT используется для указания типа сбора описаний. Если параметр INCREMENTAL_LEVEL установлен в TABLE (значение "по умолчанию" PARTITION), Oracle автоматически создаст описание для таблицы, когда статистика будет собрана. Это описание затем станет описанием уровня секции после операции обмена. Конкурентные статистики Если помощью процедуры DBMS_STATS.SET_GLOBAL_PREF установлено предпочтение сбора глобальной статистики CONCURRENT, то планировщик заданий Oracle Job Scheduler и компонент Advanced Queuing создадут и будут поддерживать одно задание сбора статистики на каждый объект (таблицу или секцию таблицы) конкурентно. В версии 12с процесс сбора статистики был улучшен за счет оптимизации каждого из заданий. Для малых или пустых таблиц, секций или подсекций база данных автоматически соберет все малые объекты в одно задание сбора статистики с целью снижения издержек. Также стало возможно выполнять конкурентный сбор статистики во время ночного задания сбора статистики, установив параметр AUTOSTAT_TARGET в ALL или AUTO. Автоматическое определение групп столбцов (Automatic column group detection) Если несколько столбцов одной таблицы используются в качестве фильтра предиката в операциях соединения или конструкциях GROUP BY, то расширенные статистики на группе этих столбцов могут улучшить точность оценок оптимизатора для объема выборки. Однако часто сложно определить, для каких групп колонок нужно создавать групповые статистики. Автоматическое определение групп столбцов состоит из трех шагов: Заполнение использования столбцов (Seed column usage) - Oracle должен собрать репрезентативную нагрузку, чтобы определить подходящие группы столбцов. Эта нагрузка может быть создана из наборов SQL Tuning Set или при наблюдении за рабочей системой. Процедура DBMS_STATS.SEED_COL_USAGE определяет начало и длительность сбора рабочей нагрузки. Создание групп столбцов (Create the column groups) Вызвав процедуру DBMS_STATS.CREATE_EXTENDED_STATS для соответствующих таблиц, можно создать нужные группы столбцов на основании собранной информации. Как только расширенные статистики были созданы, они начнут обслуживаться автоматически при сборе статистик на таблице. Создать группы столбцов можно и вручную, указав группу в качестве третьего аргумента функции DBMS_STATS.CREATE_EXTENDED_STATS. Повторный сбор статистики (Regather statistics) - Завершающим шагом является повторный сбор статистики на все задействованные таблицы.

90

Использование управления адаптивными SQL планами Новая возможность версии 12с - адаптивное управление планами SQL. С ее появлением администраторы баз данных избавлены от необходимости проверять непринятые планы выполнения вручную. Если автоматическая настройка SQL установлена в COMPREHENSIVE, то новый консультант SPM Evolve Advisor запускает процесс проверки (SYS_AUTO_SPM_EVOLVE_TASK) для всех SQL операторов, имеющих непринятые планы, во время ночного окна обслуживания. Если процесс проверки определяет, что непринятый план значимо лучше, чем принятый план в имеющимся SQL плановом основании (baseline), то план будет автоматически принят. Задание может одобрить более одного плана для SQL-оператора. Создается постоянный отчет, детально описывающий, как новый план работает по сравнению с существующими планами. Задание оценки планов может быть запущено вручную с помощью пакета DBMS_SPM. Задание консультанта Automatic SPM Evolve Advisor не имеет выделенного задание диспетчера заданий. Одно задание управляет и Automatic SQL Tuning Advisor, и Automatic SPM Evolve Advisor. Одно и то же задание включает и выключает оба консультанта. Задание может быть включено в Enterprise manager или с помощью PL/SQL пакета DBMS_AUTO_TASK_ADMIN для чего следует выполнить следующие действия: Следует подключиться к базе данных с административными привилегиями и выполнить следующий PL/SQL код: SQL> BEGIN DBMS_AUTO_TASK_ADMIN.ENABLE ( client_name => 'sql tuning advisor', operation => NULL, window_name => NULL ); END; / Нужно проверить изменения в словаре базы данных. SQL> SELECT client_name, status FROM dba_autotask_client WHERE client_name = 'sql tuning advisor'; CLIENT_NAME STATUS -------------------- -------sql tuning advisor ENABLED

Выполнение процедуры DBMS_AUTO_TASK_ADMIN.DISABLE с теми же параметрами выключит задание. Пакет DBMS_SPM поможет настроить автоматическую оценку планов выполнения. Для получения детальной информации нужно обратиться к руководству Oracle Database SQL Tuning Guide. Рекомендуется, чтобы задание развития планов SQL Plan Management Evolve task было настроено на автоматическое выполнение. Однако можно принять непринятый план вручную с помощью PL/SQL команды или из Cloud Control. Ручное развитие плана позволяет определить 91

является ли новый план лучше, чем любой из одобренных планов в плановом основании. В списке приведены процедуры DBMS_SPM ,наиболее часто используемые для управления развитием планов: ACCEPT_SQL_PLAN_BASELINE - Функция принимает одну рекомендацию по развитию одного плана и включении его в плановое основание SQL. CREATE_EVOLVE_TASK - Функция создает задание консультанта, определяющее план изменений одного или нескольких планов для указанного SQL-оператора. В качестве входного параметра указывается дескриптор SQL -оператора, имя плана или список имен планов, временные пределы, имя задания или описание. EXECUTE_EVOLVE_TASK - Эта функция выполняет задание изменений. В качестве входного параметра задается имя задания, имя выполнения, описание. Если не задано, то консультант создает имя автоматически и возвращает его после вызова функции. IMPLEMENT_EVOLVE_TASK - Эта функция реализует все рекомендации по заданию изменений. REPORT_EVOLVE_TASK - Эта функция отображает результаты задания изменений в виде CLOB. В качестве входных параметров указываются имя задания и нужная часть отчета. SET_EVOLVE_TASK_PARAMETER - Эта функция используется для установки параметров задания изменений. В версии 12с допустимым значением является только TIME_LIMIT. Обычно для ручного изменения заданий развития SQL планов нужно выполнить следующие шаги: Создать задание изменений. Установить параметры задания (при необходимости). Выполнить задание изменений. Воплотить рекомендации, полученные при выполнении задания. Создать отчет по результатам задания.

92

Аварийный контроль (Emergency Monitoring), контроль реального времени (Real-Time ADDM), сравнительный контроль (Compare Period ADDM) и анализ истории активных сессий (ASH Analytics) Выполнение аварийного контроля и контроля реального времени С помощью системы аварийного контроля DBA может подключиться к "зависшему" экземпляру базы данных. Соединение устанавливается с использованием внутреннего механизма и делает возможной диагностику проблемы ядра в то время, когда обычным образом подключиться к базе данных невозможно. При активировании аварийного контроля (Emergency Monitoring) агент Enterprise Manager Cloud Control подключается напрямую к области SGA. Агент минует уровень извлечения/разбора SQL и собирает данные статистик производительности напрямую из SGA. Страница аварийного контроля (Emergency Monitoring) доступна из меню производительность (Performance) домашней странице EM Cloud Control.

Рис. 23 Ссылка на страницу аварийного контроля Oracle EM Cloud Control 12c

На странице отображаются собранные данные ASH и обновляемые в реальном времени данные о блокируемых сессиях в таблице анализа зависаний (Hang Analysis). Администратор может определить блокирующие сессии и "убить" блокирующую сессию нажатием на соответствующую кнопку (выделена цветом).

93

Рис. 24 Страница аварийного контроля Oracle EM Cloud Control 12c при наличии взаимных блокировок

ADDM реального времени Монитор ADDM реального времени впервые появился в Oracle Enterprise Manager Cloud Control 12c, и значительная часть его возможностей также доступна в Enterprise Manager Express. Нужно отметить, что EM Express не имеет технической возможности установки сессии аварийного подключения или какого-либо эквивалентного механизма. Монитор ADDM реального времени создан для упрощения анализа и решения проблем, приводящих к зависанию или блокировке базы данных. Ранее решение их требовало перезапуска базы данных. Монитор ADDM реального времени анализирует текущую производительность БД с помощью набора предопределенных критериев. При обнаружении каких-либо проблем монитор ADDM реального времени предлагает методы для решения любых найденных ошибок без перезапуска БД. В зависимости от состояния базы данных, ADDM реального времени будет использовать один из двух режимов соединения с БД: Нормальное соединение - ADDM реального времени выполняет обычное JDBC соединение с БД. Этот режим предназначен для проведения широкого анализа производительности при условии возможности установки соединения. Диагностическое соединение - сессия с базой данных без блокировок, предназначенная для ситуаций полного зависания, когда обычная JDBC-сессия невозможна. Диагностика, проводимая ADDM реального времени, сходна с диагностикой обычного ADDM, но ADDM реального времени использует другие данные. Обычный монитор ADDM для диагностики использует данные из снимков AWR. Монитор ADDM реального времени использует данные текущей 94

активности ASH из SGA вместо снимков AWR, т.е. ADDM реального времени выполняется автоматически и использует данные в памяти для выделения всплесков активности в базе данных. Если обнаружена проблема производительности, то автоматически включается программа анализа. Просмотр активности ASH происходит каждые три секунды процессом отслеживания управляемости MMON (manageability monitor process) без использования защелок или блокировок. Процесс MMON анализирует статистику работы и включает ADDM реального времени, если обнаружена какая-либо из следующих проблем: High load (высокая нагрузка) - Среднее количество активных сессий в три раза выше, чем число ядер процессора. I/O bound (предел ввода/вывода) - Влияние операций ввода/вывода на активные сессии с учетом производительности чтения одиночного блока слишком велико. CPU bound (предел процессора) - Активные сессии превышают 10% общей нагрузки и утилизация процессора выше 50%. Over-allocated memory (избыточно занятая память) - Выделено более 95% физической памяти. Interconnect bound (предел внутренней передачи) - Предел времени внутренней передачи одиночного блока. Session limit (передел количества сессий) - Количество сессий близко к 100% пределу. Process limit (предел количества процессов) - Количество процессов близко к 100% пределу. Hung sessions (зависшие сессии) - Доля зависших сессий выше, чем 10% от общего количества сессий. Deadlock detected (обнаружены взаимные блокировки) - Обнаружена хотя бы одна взаимная блокировка. Подчиненный процесс MMON занесет полученный отчет ADDM в репозиторий AWR. Метаданные отчета доступны через представление DBA_HIT_REPORTS. ADDM реального времени использует несколько средств, чтобы удостовериться, что автоматическое включение не будет потреблять слишком много системных ресурсов: Интервал между отчетами (Duration between reports) - Если отчет ADDM реального времени был создан за прошедшие 5 минут автоматически, то новый отчет создаваться не будет. Oracle RAC control - Включение ADDM реального времени является локальным для экземпляра. Для Oracle RAC только одиночный экземпляр может создавать отчет ADDM реального времени, поскольку это требует блокировки, и запрос выполняется подчиненным процессом MMON перед действительной генерацией отчета. Повторяющиеся проблемы (Repeated triggers) - Автоматическое включение ADDM реального времени по любой проблеме возможно, если причина включения имеет такой же или больший уровень интенсивности в течение последних 45 минут. Новая проблема (Newly identified issues) - Если обнаружена новая проблема, и она не встречалась за последние 45 минут, то создается новый отчет независимо от активной нагрузки.

95

Создание сравнительного отчета ADDM по периоду Функция сравнения периодов ADDM используется для сравнения производительности сервера базы данных за два разных периода времени. Эта функциональность является частью Enterprise Manager Cloud Control 12c и используется для выяснения причин, почему сервер работает быстрее или медленнее ожидаемого. С ее помощью можно анализировать любую базу данных Oracle версии 10.2.0.4 и старше, обслуживаемую Cloud Control. Для построения отчета нужно выбрать строго два периода: Период сравнения (comparison period) - Обычно, это время, когда обнаружено падение производительности. Однако возможно использование сравнения периодов для выяснения причин роста производительности. Базовый период (base period) - Это определенный период времени, когда база данных функционировала правильно. В качестве базового периода выбирается отрезок времени, когда производительность является приемлемой, а нагрузка близка к периоду сравнения. Для создания сравнительного отчета ADDM нужно выполнить следующее: 1. Из пункта меню Performance EM Cloud Control нужно выбрать AWR и Compare Period ADDM. 2. На странице Run Compare ADDM нужно выбрать базовый и сравниваемый периоды. 3. Запустить генерацию отчета Database Compare Period Report, кликнув на Run. 4. На основании созданного отчета определить причины изменения производительности. Отчет содержит четыре раздела: Обзор (overview) - В разделе приводится значение, насколько данные периоды сопоставимы. Значение основывается на среднем потреблении ресурсов общими для обоих периодов SQL-запросами. Если значение 100%, то "отпечаток" нагрузки в обоих временных отрезках идентичен. Если значение 0%, то временные периоды не имеют общих элементов для специфической размерности нагрузки. Настройки (configuration) - В разделе приводятся параметры настройки экземпляра, хоста, базы данных для обоих периодов. Находки (findings) - Раздел может содержать обнаруженные изменения производительности. В разделе могут приводиться основные различия в производительности, вызванные изменениями в системе. Он содержит значение "влияние изменения" (Change Impact), представляющее масштаб изменения производительности в разные периоды. Если значение положительное, то произошло улучшение, отрицательное - ухудшение. Ресурсы (Resources) - Приводятся сводные данные долей времени БД для обоих периодов времени. Приводится использование ресурсов CPU, оперативной памяти, ввода/вывода и межэкземплярных соединений для RAC.

96

Диагностика проблем возможностей ASH

производительности

с

использованием

новых

Обычный монитор ADDM проводит диагностику базы данных на основании снимков AWR. Если проблема производительности является краткосрочной, то ADDM может не обнаружить ее, так как эта проблема не считается значимой в терминах ее длительности по сравнению с периодом сбора снимков AWR. Данные снимков не является идеальным средством для обнаружения и диагностики периодических или краткосрочных проблем производительности. Для облегчения обнаружения с краткосрочных проблем с производительностью база данных Oracle каждую секунду проверяет активные сессии и заносит собранные данные в циклический буфер в области SGA. Чтобы сохранить приемлемое количество данных, запоминается состояние только тех сессий, которые ждут событий, не относящихся к типу Idle wait. Собранные таким образом данные представляют собой историю активных сессий - Active Session History (ASH). Они могут быть получены через запрос к представлению V$ACTIVE_SESSION_HISTORY. На их основании создается отчет ASH, в который включены следующие параметры сессий: Идентификатор SQL оператора. Номер объекта, номер файла и номер блока. Идентификатор номера события ожидания и серийный номер сессии. Модуль и имя действия. Идентификатор клиента сессии. Хэш идентификатор сервиса. Для создания отчета AWR можно использовать Oracle Enterprise Manager Cloud Control. Для создания отчета ASH из EM Cloud Control нужно: Зайти на домашнюю страницу базы данных Database Home. Из меню Performance выбрать Performance Home. Зарегистрироваться в БД с административными полномочиями. Появится страница Performance. Под Average Active Sessions кликнуть на Run ASH Report. Появится страница Run ASH Report. Ввести дату и время начала и завершения периода, когда имела место кратковременная проблема с производительностью. Нажать Generate Report. По завершении создания отчета ASH он будет доступен в секции Report Results на странице Run ASH Report. Созданный отчет может быть использован для обнаружения причины кратковременной проблемы с производительностью. Отчет ASH разделен на озаглавленные разделы: Основные события (Top Events) - Приводятся детали событий ожидания для отобранных сессий. Выделяются пользовательские, фоновые или приоритетные категории. Профиль нагрузки (Load Profile) - Описывает нагрузку, проанализированную в отобранной сессии. Информация в секции отчета может использоваться для идентификации клиента, сервиса или SQL-команды, которые могут вызывать кратковременные проблемы с производительностью. 97

Основные SQL запросы (Top SQL) - Показывает основные SQL-запросы в отобранной сессии. Определенные здесь вызывающие высокую нагрузку SQL-запросы могут вносить свой вклад в кратковременные проблемы с производительностью. Основные сессии (Top Sessions) - Список сессий, имеющих максимальную долю событий ожидания. Этот список может помочь в идентификации сессий, которые могут источником проблем с производительностью. Часто используемые объекты БД/файлы/защелки (Top DB Objects/Files/Latches) - В секции приводятся дополнительные данные о наиболее часто используемых общих ресурсах базы данных. Три подсекции данной секции отчета приводят список файлов, объектов и защелок, которые наиболее часто использовались в отобранных сессиях. Активность за время (Activity Over Time) - Эта секция полезна для анализа более длинных периодов времени поскольку обеспечивает всесторонние детали об активности и профилях нагрузки во время периода анализа. В среду EM Cloud Control включен новый инструмент ASH Analytics, отображающий данные ASH в графическом виде, что дает возможность интерактивно анализировать данные активности сессий (ASH) и обеспечивает несколько способов манипуляции с анализируемыми данными, включая: Изменение длительности анализируемого периода. Фильтрацию включаемых измерений. Углубленный анализ представления плана нагрузки, показывающий различные события ожидания с учетом их значимости.

Менеджер ресурсов и другие расширения контроля производительности Использование менеджера ресурсов для контейнерной и подключаемых баз данных Менеджер ресурсов используется для настройки квот системных ресурсов БД Oracle, выделяемых нескольким конкурирующим нагрузкам. Даже в монолитной БД конкурирующие нагрузки достаточно сложны с точки зрения выделения ресурсов. Управление ресурсами в контейнерной БД усложняется, так как ресурсы делятся между несколькими подключаемыми БД и контейнерной. Менеджер ресурсов в контейнерной БД работает на двух основных уровнях: Уровень контейнера (CDB) - Управляет нагрузкой нескольких PDB, конкурирующих за ресурсы. Можно настроить каким образом ресурсы выделяются для разных PDB и ограничения, установленные для определенных PDB. Уровень подключаемой БД (PDB) - Нагрузки внутри подключаемой БД. Ресурсы выделяются в двух шаговом процессе: Каждой подключаемой БД выделяется часть совокупных системных ресурсов в контейнерной БД. Внутри каждой подключаемой БД ресурсы, полученные на первом шаге, делятся между установленными сессиями. Менеджер ресурсов позволяет сделать следующее: Указать, что разным подключаемым БД нужно выделять разные доли системных ресурсов на основании их относительной важности. Ограничить использование процессора подключаемой БД. 98

Ограничить степень параллелизма для конкретной контейнерной БД. Ограничить использование ресурсов различными сессиями в рамках одной PDB. Отслеживать использование ресурсов разными PDB.

Различие между мультипроцессной и многопотоковой архитектурой в Oracle В базе данных Oracle существует набор различных процессов, каждый из которых выполняет определенные задачи внутри БД. Такая архитектура является многопроцессной. Если бы СУБД Oracle была однопроцессной, то существовал бы один гигантский процесс, который бы делал всю нужную работу. Многопроцессная архитектура делает Oracle более масштабируемым, т.к. запускаются и используют ресурсы системы только нужные процессы. До версии 12c на платформе Unix/Linux каждый процесс Oracle требовал отдельного системного процесса. В этом релизе стало возможно запускать Oracle для *nix в многопотоковом режиме. При работе в многопотоковом режиме один процесс операционной системы может поддерживать множество процессов Oracle, выполняющихся в виде нитей (thread) внутри процесса ОС. Многопотоковый режим по умолчание выключен. Чтобы включить его, нужно установить параметр экземпляра THREADED_EXECUTION в YES и перезапустить экземпляр. При работе в многопотоковом режиме некоторые фоновые процессы все равно функционируют как процессы ОС (один процесс Oracle - один процесс ОС). Например, PMON и DBW0 выполняются как процессы ОС, тогда как LGWR и SMON могут выполняться как нити одного процесса. Представление P$PROCESS содержит записи для каждого процесса Oracle в экземпляре, в частности ID процесса в ОС и ID нити в ОС. При работе в многопотоковом режиме администрирование БД возможно только с использованием учетной записи, аутентифицируемой с помощью файла паролей. В противном случае возникнет ошибка ORA-1031: SQL> ALTER SYSTEM SET threaded_execution=true SCOPE=SPFILE; System altered.

SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down.

SQL> startup ORA-01017: invalid username/password; logon denied

SQL>

99

Использование флэш кэша (flash cache) Функция Database Smart Flash Cache организует доступ к нескольким устройствам флэшпамяти без помощи менеджера томов ОС. Эта возможность поддерживается только на Solaris и Linux. Включение этой опции может быть полезным, если выполняется следующее: Раздел Buffer Pool Advisory отчета AWR или STATSPACK указывают, что удвоение объема буферного кэша будет полезным. Событие "db file sequential read" входит в список основных событий. Система имеет свободные (spare) циклы процессора. Имеется два параметра настройки Database Smart Flash Cache: DB_FLASH_CACHE_FILE - Указывает список полных путей к файлам Database Smart Flash Cache. Файлы могут как файлами ОС, так и дисковой группой ASM, но они должны находиться на устройствах флэш-памяти. Размещение на обычных дисках может отрицательно повлиять на производительность. Если файла не существует, то база данных создаст его при старте. Всего поддерживается до 16 файлов. DB_FLASH_CACHE_SIZE - Указывает размер каждого файла в Database Smart Flash Cache. Каждый размер соотносится с файлом, указанным в DB_FLASH_CACHE_FILE. Если количество размеров не совпадает с количеством файлов, то возникает ошибка. Размер задается в гигабайтах в виде nG. Представление V$FLASHFILESTAT может быть использовано для определения совокупной задержки (latency), счетчика чтений для каждого файла и вычисления средней задержки. Можно отключить устройство флэш-памяти, указав в команде ALTER SYSTEM нулевой размер соответствующего файла в параметре DB_FLASH_CACHE_SIZE. Включить устройство можно указав исходный размер флэш-памяти. Эти изменения требуют перезапуска экземпляра.

100

Расширенные возможности при работе с индексами и таблицами Применение расширенных возможностей работы с индексами В версии 12c стало возможным создание нескольких индексов на одном и том же наборе столбцов. Когда используется один и тот же набор столбцов, то для создания индекса должна существовать принципиальная разница между индексами (например, B-tree или bitmap). Также, когда более, чем один индекс существует для одного и того же набора столбцов, только один из индексов может быть видимым. Оптимизатор никогда не выберет более одного индекса, так только один из всех возможных является видимым. Несколько индексов может быть создано на одном и том же наборе столбцов, если по крайней мере одна из следующих характеристик создаваемых индексов отличается: Создаются B-tree и битовый индекс. Используются разные типы секционирования. Создаются уникальный и неуникальный индексы.

101

Применение расширенных возможностей работы с таблицами В версии 12c появилась возможность управлять видимостью столбцов. Если один или несколько столбцов сделаны невидимыми, обычный доступ к таблице покажет только видимые столбцы. Например, следующие операции не покажут невидимые столбцы: Оператор SELECT * FROM в SQL. Оператор DESCRIBE в SQL*Plus. Описание атрибута %ROWTYPE в PL/SQL. Оператор Describe в Oracle Call Interface (OCI). Невидимые столбцы будут отображаться только при явном их указании в операторе SELECT. Аналогично, данные в невидимые столбцы можно вставить, только явно указав их список в операторе INSERT. Если INSERT не содержит списка столбцов, то вставка осуществляется только в видимые столбцы. Столбы могут быть сделаны невидимыми при создании таблицы, при добавлении столбца к таблице или при модификации таблицы. Виртуальные столбцы могут быть невидимыми. Невидимые столбцы могут использоваться в качестве ключа секционирования при создании таблиц. Невидимые столбы имеют следующие ограничения: Внешние, кластерные и временные таблицы не могут иметь невидимые столбцы. Атрибуты пользовательских типов не могут быть невидимыми.

102

Применение расширенных возможностей online операций Реорганизация таблицы "на ходу" дает возможность менять структуру таблиц без значимого влияния на их доступность. Если таблица реорганизуется (переопределяется) "на ходу", то она остается доступной для запросов и DML в течении большей части времени модификации и блокируется в монопольном режиме только в течение очень малой части всего процесса. Переопределение таблицы "на ходу" можно выполнить с помощью процедуры " Reorganize Objects" в Oracle EM Cloud Control или при помощи пакета DBMS_REDEFINITION. При проведении реорганизации таблиц следует помнить о необходимости достаточного свободного места, иначе переопределение завершится с ошибкой. Всего в 12 версии сделано несколько улучшений процедуры реорганизации. Улучшения затрагивают:

o

o o

o

Множественные секции (Multiple Partitions) - Стало возможным переопределять несколько секций за одну операцию. Эта возможность снижает время переопределения секционированной таблицы. При одновременной реорганизации нескольких секций используется несколько промежуточных таблиц. Таблицы с политиками частной виртуальной базы (Tables With VPD Policies) - Стало возможным переопределять таблицы с включенными политиками частной виртуальной базы Virtual Private Database (VPD). Параметр copy_vpd_policy процедуры START_REDEF_TABLE определяет режим обработки политик VDP во время переопределения. Этот параметр может принимать следующие значения: DBMS_REDEFINITION.CONS_VPD_NONE - Значение "по умолчанию". Указывает, что в исходной таблице нет политик. Если установлено это значение, но политики присутствуют, то возникает ошибка. DBMS_REDEFINITION.CONS_VPD_AUTO - Существующие политики автоматически скопируются из исходной таблицы в новую в процессе переопределения "на ходу". DBMS_REDEFINITION.CONS_VPD_MANUAL - Это значение используется в том случае, когда нужно скопировать политики из исходной таблицы в новую вручную. Политики VPD должны копироваться вручную, если настроено отображение столбцов между исходной таблицей и промежуточной или нужно изменить/добавить политики VPD во время переопределения. Таймаут блокировки таблицы в монопольном режиме (Lock Timeout for FINISH_REDEF_TABLE) - Можно задать продолжительность времени (в секундах), в течение которого процедура FINISH_REDEF_TABLE пытается установить монопольную блокировку таблицы для обмена исходной и промежуточной таблиц. Если таймаут истекает, то процедура завершается с ошибкой. Ранее пользователь должен был ждать бесконечно или принудительно завершить сессию переопределения. Процедура REDEF_TABLE - Новая процедура в составе пакета DBMS_REDEFINITION. Обычно реорганизация таблицы является многоступенчатым процессом. REDEF_TABLE позволяет выполнить переопределение параметров хранения таблицы за один шаг, если, конечно, меняются следующие свойства: меняется табличное пространство, включая табличное пространство для таблиц, секций, индексов или LOB-сегментов 103

o o

изменение типов компрессии, включая компрессию для таблицы, секции, ключа индекса или столбца LOB для LOB столбцов, изменение к SECUREFILE или BASICFILE типу хранения

104

Улучшения программы диагностики ADR (Automatic Diagnostic Repository) Описание улучшений ADR В версии в Oracle 12c появился новый журнал - журнал команд языка определения данных. Новый журнальный файл команд языка определения данных (DDL) имеет тот же формат и функционирует в основном так же, как и alert.log. Если параметр инициализации ENABLE_DDL_LOGGING установлен в TRUE, то все команды DDL, выполненные базой данных, будут записаны в этот журнал. Если этот параметр установлен в FALSE, команды DDL не включаются в какойлибо журнал. Этот журнал содержит запись для каждой DDL команды. Журнал состоит из двух файлов, содержащих одну и ту же информацию, один в формате XML, другой в текстовом формате. DDL журнал находится в директории log/dll в структуре директорий ADR и включается в пакет инцидента IPS для отсылки в службу поддержки. Если параметр инициализации ENABLE_DDL_LOGGING установлен в TRUE, то следующие команды DDL будут заноситься в журнал: ALTER/CREATE/DROP/TRUNCATE CLUSTER ALTER/CREATE/DROP FUNCTION ALTER/CREATE/DROP INDEX ALTER/CREATE/DROP OUTLINE ALTER/CREATE/DROP PACKAGE ALTER/CREATE/DROP PACKAGE BODY ALTER/CREATE/DROP PROCEDURE ALTER/CREATE/DROP PROFILE ALTER/CREATE/DROP SEQUENCE CREATE/DROP SYNONYM ALTER/CREATE/DROP/RENAME/TRUNCATE TABLE ALTER/CREATE/DROP TRIGGER ALTER/CREATE/DROP TYPE ALTER/CREATE/DROP TYPE BODY DROP USER ALTER/CREATE/DROP VIEW Журнал отладки (Debug Log) Журнал отладки создан для записи ситуаций в базе данных, которые являются необычными, но не приводят к прекращению нормальной работы сигнализирующего компонента БД. Предупреждения, заносимые в журнал отладки, не являются достаточно серьезными, чтобы быть инцидентом или быть занесенными в alert.log. Они заносятся в журнал отладки потому, что они могут стать полезными в диагностике будущих проблем. Журнал отладки имеет тот же формат и поведение, что и alert.log, но он содержит только данные о необычных событиях или условиях, которые могут потребовать исправления. Перенос этой информации в журнал отладки снижает количество событий, которые нужно записывать в alert.log и файлы трассировки, и улучшает читаемость информации отладки. Журнал отладки включается в IPS пакет инцидента и его содержимое предназначено только для поддержки Oracle.

105

Улучшения Oracle Data Pump, SQL*Loader, External Tables Online операций Обзор улучшений Oracle Data Pump При полном экспорте базы данных с помощью Data Pump стало возможным задать опцию полного переносимого экспорта (full transportable export). Для этого нужно установить параметр TRANSPORTABLE=ALWAYS и параметр FULL. Эта функциональная возможность позволяет экспортировать все объекты и данные, необходимые для создания полной копии базы данных. В зависимости от возможности переноса табличных пространств Data Pump использует один из двух методов: Непереносимые табличные пространства - Непереносимые табличные пространства SYSTEM и SYSAUX не могут быть перенесены, они содержат данные и метаданные, выгружаемые в набор файлов экспорта с использованием прямой выгрузки и внешних таблиц. Переносимые табличные пространства - Для переносимых табличных пространств в файлы экспорта выгружаются только метаданные. Содержимое табличных пространств переносится в момент копирования файлов данных на целевую базу данных. Существует несколько ограничений для использования полного переносимого экспорта, включая: Для выполнения экспорта нужна привилегия DATAPUMP_EXP_FULL_DATABASE. Табличное пространство "по умолчанию" для пользователя, выполняющего экспорт, не должно быть в списке транспортируемых. Если экспортируемая БД содержит шифрованные пространства или таблицы с шифрованными столбцами, то обязательно нужно задавать параметр ENCRYPTION_PASSWORD. Если экспортируемая БД содержит шифрованные пространства, то целевая и исходная БД должны быть на платформе с одинаковым порядком байтов (Endianess). Если целевая и исходная БД находятся на платформах с разным порядком байтов, то необходимо выполнить конвертацию данных в формат целевой платформы. Полный переносимый экспорт невозможно перезапустить. Сегменты всех объектов, выбранных для экспорта, должны полностью располагаться внутри административных, непереносимых табличных пространств (SYSTEM/SYSAUX), или же полностью располагаться внутри пользовательских, переносимых пространств. Память для одного объекта не может использовать оба типа пространств одновременно. Новая возможность полного переносимого экспорта утилит Data Pump может использоваться для переноса монолитной БД в подключаемую (PDB) или для переноса одной подключаемой БД в другую контейнерную БД. Операции полного экспорта могут снизить время, необходимое для полного экспорта и импорта. При использовании этой опции не возникает необходимости в выгрузке и загрузке табличных данных, а также в пересоздании индексов в пользовательских пространствах. Функция полного переносимого экспорта идеально подходит для переноса базы данных на новый сервер или для модернизации на новый релиз Oracle.

106

Работа Data Pump со сжатыми данными получила две новых возможности: Сжатие при импорте - Новая опция, позволяющая изменить сжатие для таблиц при импорте, добавлена к impdp и пакету DBMS_DATAPUMP. Параметр TRANSFORM impdp имеет опцию TABLE_COMPRESSION_CLAUSE. Если задано NONE, то таблица получает тот тип сжатия, которые установлен для табличного пространства. Если значение установлено в допустимое значение (например, NOCOMPRESS), то таблицы создаются с указанным типом сжатия. Этот параметр меняет тип сжатия для всех таблиц в исполняемом задании импорта. Сжатие при экспорте - Новая опция, позволяющая управлять степенью сжатия при создании файла экспорта, добавлена к expdp и пакету DBMS_DATAPUMP. Параметр COMPRESSION может использоваться для задания сжатия всей операции экспорта, только данных, только метаданных или не использовать компрессию. "По умолчанию" сжимаются только метаданные. Этот параметр позволит администратору БД лучше управлять выделением ресурсов при экспорте. Другие улучшения Data Pump включают:

o o o o

Export View As a Table - Новый параметр командной строки дает возможность выгрузить представление как таблицу. Вместо экспорта определения представления, Data Pump выгрузит определение таблицы и данные из представления, как будто бы оно было таблицей. При импорте дампа утилита impdp создаст таблицу, используя определение, и вставит данные. LOGTIME - Новый параметр командной строки LOGTIME позволяет включить выдачу временных меток для каждого сообщения, отображаемого при операциях export или import Опция доступна для impdp, expdp и в процедуре DBMS_DATAPUMP.SET_PARAMETER. Допустимы следующие значения: NONE - не выдавать временные метки в статусе или файле журнала (задано "по умолчанию"). STATUS - временные метки только для статуса. LOGTIME - временные метки только для файла журнала. ALL - все временные метки. Audit Commands - Команды Oracle Data Pump теперь аудируются. No Logging Option - К программе impdp и пакету DBMS_DATAPUMP добавлена опция DISABLE_ARCHIVE_LOGGING для параметра TRANSFORM. Если опция задана, то запрещается создание журналов redo при загрузке данных в таблицы и при создании индексов. При использовании опции дисковое пространство, используемое журналами redo при импорте Oracle Data Pump, будет меньше. После выполнения операции импорта необходимо выполнить резервное копирование с помощью RMAN или другим образом. Другие операции, включая CREATE и ALTER (за исключением CREATE INDEX) и операции на мастер-таблице, используемой Oracle Data Pump, создают redo журналы. Security - Параметр командной строки ENCRYPTION_PWD_PROMPT добавлен к expdp / impdp. Он указывает, что клиент Oracle Data Pump должен запросить пароль или извлечь его из командной строки. 107

SecureFiles LOB as Default – Новый параметр impdp пакета DBMS_DATAPUMP заставляет Oracle Data Pump создавать все LOBs как SecureFiles LOBs. "По умолчанию" Data Pump воссоздает таблицы точно такими же, какими они были в исходной базе данных, поэтому, если столбец LOB был BasicFile LOB в экспортируемой БД, то Data Pump попытается воссоздать его как a BasicFile LOB целевой базе данных.

108

Применение расширенных возможностей загрузчика SQL*Loader и внешних таблиц Новый "express mode" режим загрузчика SQL*Loader позволяет загружать данные из плоского файла при указании только имени таблицы. Для успешной реализации этой функциональности файл должен содержать только разграниченные данные, а таблица должна содержать столбцы только символьного, численного и временного типов данных. При работе в экспресс-режиме не используется управляющий файл. Загрузчик SQL*Loader использует тип столбцов таблицы для определения порядка полей ввода и типов данных в файле. Для остальных установок используются значения "по умолчанию", если иное не задано в командной строке. В следующем примере выполняется загрузка в таблицу EMPLOYEES: $ sqlldr username TABLE=employees "По умолчанию" режим "express" SQL*Loader предполагает следующие значения входных параметров, если иные значения не указаны:

o o o o

Файл данных (Data file) - Если не указан, то SQL*Loader ищет файл с именем [table_name].dat в текущей директории. Метод загрузки (Load method) - "по умолчанию" используется внешняя таблица (external tables). Для некоторых типов ошибок в этом режиме SQL*Loader автоматически переключится на прямой путь загрузки (direct path load). Поля (Fields) - Если не указаны, то поля используют имена, типы столбцов и их порядок из целевой таблицы. В записи поля разделены запятыми, записи ограничены символом возврата строки, не имеют вложений и используют обрезку слева и справа. Степень параллелизма (DOP) - Параметр степень параллелизма DEGREE_OF_PARALLELISM установлен в AUTO. Формат даты (Date Format) - используются установки NLS. Набор символов (Character Set) - используются установки NLS. Режим добавления (Append mode) - Новые данные должны быть добавлены в таблицу к уже существующим данным. Имена файлов (File Names) - Если файл данных не указан, то файлам данных, журнала и ошибок будут присвоены имена "по умолчанию" (Параметр %p замещается номером процесса ID Oracle Database.): Data File - table-name.dat SQL*Loader Log File - table-name.log Oracle Database Log Files - table-name_%p.log_xt Bad File - table-name_%p.bad

Для определения, где находятся файлы данных и где создаются выходные файлы, при использовании внешних таблиц для SQL*Loader требуется использование директорий (объектов типа директория). Пользователь, выполняющий операцию загрузки, должен иметь полномочия READ на директорию, содержащую файлы данных, и полномочия WRITE на директорию, где будут создаваться выходные данные. Если директории для файла данных или выходных файлов не существует, то SQL*Loader сгенерирует SQL команду для создания директории. Если это так, то пользователь, выполняющий загрузку, должен иметь привилегию CREATE ANY DIRECTORY. Если директории должны

109

быть удалены после окончания загрузки, то пользователь, выполняющий загрузку, должен иметь привилегию DELETE ANY DIRECTORY. Возможности "прямого" NFS (Direct NFS) Пакет Oracle Direct NFS (dNFS) представляет собой внутренний слой ввода/вывода, обеспечивающий более быстрый, нежели обычные клиенты NFS, доступ к большим файлам. "По умолчанию" в 12c SQL*Loader и внешние таблицы будут использовать этот пакет для доступа к большим файлам. Параметр командной строки DNFS_ENABLE SQL*Loader и параметр access для внешних таблиц может быть использован для явного управления использованием dNFS. Интерфейс Direct NFS используется "по умолчанию" при чтении файлов более 1 GB. Для файлов меньшего размера используется стандартные процедуры ввода/вывода операционной системы. Чтобы использовать Direct NFS на всех входных файлах следует указать DNFS_ENABLE=TRUE. Для запрета использования Direct NFS на всех входных файлах следует указать DNFS_ENABLE=FALSE.

110

Расширенные возможности секционирования Обзор расширенных возможностей секционирования Секционирование по ссылочному интервалу (interval-reference) В версии 12c таблицы, секционируемые по ссылке, могут использовать интервальное секционирование в качестве самого верхнего уровня секционирования. Использование интервальносекционированных таблиц, как основы для ссылочного секционирования, приводит к более удачной модели секционирования. Секции в секционируемой по ссылке таблице соответствующие интервальным секциям в родительской таблице создаются в момент вставки в секционируемую по ссылке таблицу. Любые операции, преобразующие интервальные секции в обычные в родительской таблице, создадут соответствующую нужную информацию в дочерней таблице. Для реализации возможностей интервального ссылочного секционирования требуется установить параметр инициализации COMPATIBLE в 12.0.0.0 или выше. Операции множественного обслуживания секций таблиц Некоторые операции обслуживания секций таблиц теперь могут быть выполнены для нескольких секций в рамках одной команды. Это упрощает в разработку приложений и приводит к более эффективному обслуживанию секций. Изменения касаются следующих операций: ADD - несколько новых секций и подсекций может быть добавлено в ADD PARTITION и ADD SUBPARTITION опциях команды ALTER TABLE. Эта возможность поддерживается только для секционирования по диапазону (range), списку (list) и системных секций и подсекций (subpartition). Множественные интервальные секции могут добавляться секционированной по диапазону или композитно-секционированной по диапазону таблице при условии, что таблица не имеет секции с указанием значения MAXVALUE. Также можно добавить несколько секций к секционированной по списку таблице при условии, что она не имеет секции DEFAULT. В примере показано добавление нескольких секций к таблице, секционированной по диапазону: SQL> ALTER TABLE orders ADD PARTITION orders_2013 VALUES LESS THAN (TO_DATE('01-JAN-2014','DD-MON-YYYY')), PARTITION orders_2014 VALUES LESS THAN (TO_DATE('01-JAN-2015','DD-MON-YYYY')), PARTITION orders_2015 VALUES LESS THAN (TO_DATE('01-JAN-2016','DD-MON-YYYY')); DROP - стало возможным удалить несколько секций или подсекций из секционированных по списку или диапазону в одной SQL команде ALTER TABLE, опции DROP PARTITION или DROP SUBPARTITION. Невозможно удалить все таблицы. В примере показано удаление нескольких секций из таблицы секционированной по диапазону: SQL> ALTER TABLE orders DROP PARTITION orders_1999, orders_2000, 111

таблиц, задавая секции orders,

orders_2001, orders_2002; TRUNCATE - стало возможным проводить усечение нескольких секций таблиц, секционированных по диапазону или списку (опция TRUNCATE PARTITION команды ALTER TABLE). Глобальные индексы должны быть перестроены, только если не задана опция UPDATE INDEXES. В примере показано усечение нескольких секций таблицы, секционированной по диапазону: SQL> ALTER TABLE sales TRUNCATE PARTITIONS orders_1999, orders_2000, orders_2001, orders_2002; MERGE - команда ALTER TABLE MERGE PARTITION может быть использована для слияния содержимого двух и более секций в одну. Исходные секции удаляются, так же, как и любые соответствующие локальные индексы. Эта команда не применима к таблицам, секционированным по хэшу или имеющими подсекции по хэшу. При слиянии нескольких секций по диапазону необходимо, чтобы секции примыкали друг к другу и были указаны в возрастающем порядке граничных значений секций. В примере показано слияние нескольких секций в одну: SQL> ALTER TABLE orders MERGE PARTITIONS orders_2003, orders_2004, orders_2005, orders_2006 INTO PARTITION orders_2003_6; или SQL> ALTER TABLE orders MERGE PARTITIONS orders_2003 TO orders_2006 INTO PARTITION orders_2003_6; SPLIT - содержимое секции или подсекции может быть разделено на несколько секций или подсекций с помощью команды ALTER TABLE в опции SPLIT PARTITION и SPLIT SUBPARTITION. После разделения, исходный сегмент высвобождается. Новые секции получают новые сегменты и наследуют все неявные физические атрибуты исходной секции. В примере показано разделение секции, полученной ранее: SQL> ALTER TABLE orders SPLIT PARTITION orders_2003_6 INTO (PARTITION orders_2003 VALUES LESS THAN (TO_DATE('01-JAN-2004','DD-MON-YYYY')), PARTITION orders_2004 VALUES LESS THAN (TO_DATE('01-JAN-2005','DD-MON-YYYY')), PARTITION orders_2005 VALUES LESS THAN (TO_DATE('01-JAN-2006','DD-MON-YYYY')), PARTITION orders_2006 VALUES LESS THAN 112

(TO_DATE('01-JAN-2007','DD-MON-YYYY')) ); Каскадная функциональность (Cascade Functionality) Операции TRUNCATE PARTITION и EXCHANGE PARTITION для таблиц, секционируемых по ссылке и ссылочному интервалу, будут проводиться каскадно в отношении дочерних таблиц. Эта функциональность дает возможность наследования операций обслуживания секций от родительских к дочерним таблицам. "По умолчанию" для совместимости каскадные операции отключены. Операции обмена секций (EXCHANGE) могут каскадироваться в ссылающихся секциях дочерних таблиц при задании опции CASCADE SQL команд ALTER TABLE EXCHANGE PARTITION и ALTER TABLE EXCHANGE SUBPARTITION. Для успешного выполнения каскадных операций обмена все ограничения ссылочной целостности должны быть определены как ON DELETE CASCADE. При указании опции CASCADE операция EXCHANGE каскадируется на секционированные по ссылке таблицы, которые являются дочерними для целевой таблицы. Опция игнорируется, если указана для таблицы, не имеющих дочерних таблиц, секционированных по ссылке. Команды TRUNCATE TABLE, ALTER TABLE TRUNCATE PARTITION и ALTER TABLE TRUNCATE SUBPARTITION могут каскадироваться на секционированные по ссылке таблицы через включенное ограничение ссылочной целостности с возможностью ON DELETE CASCADE. Каскадируемое действие применяется рекурсивно к дочерним, внучатым и т.д. таблицам. После определения на основании ограничений целостности набора таблиц для операции усечения (truncate) при выполнении усечения возникает ошибка, если хотя бы в одной из таблиц в наборе имеется включенное ограничение из внешней дочерней таблицы, не входящей в набор. Если дочерняя и материнская таблицы связаны несколькими ссылочными ограничениями, операция TRUNCATE TABLE CASCADE на материнской таблице будет успешной при наличии по крайней мере одного разрешенного ограничения целостности с опцией ON DELETE CASCADE. При указании опции CASCADE операции TRUNCATE PARTITION и TRUNCATE SUBPARTITION на целевой таблице распространяются на дочерние таблицы. Перемещение секций "на ходу" Эта функциональность позволяет перемещать или реорганизовывать секцию во время выполнения операций DML над данными в секции. Глобальные индексы таблиц продолжают обслуживаться во время переноса секции, поэтому ручная перестройка индексов не требуется. Опция MOVE PARTITION команды ALTER TABLE может использоваться для выполнения следующих задач: Перегруппировать данные и снизить фрагментацию. Переместить секцию в другое табличное пространство. Изменить атрибуты времени создания. Сохранить данные в сжатом формате с использованием табличного сжатия. Многие из атрибутов физического размещения секции можно поменять командой ALTER TABLE/INDEX MODIFY PARTITION. Для тех атрибутов, которые не могут быть изменены таким способом (например, табличное пространство), нужно использовать опцию MOVE PARTITION. Дополнительно нужно сказать, что хотя и можно использовать MODIFY PARTITION для изменения компрессии, но команда повлияет только на новые, и не затронет существующие данные. При выполнении MOVE 113

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

Расширенные таблиц

возможности

индексирования

для

секционированных

Асинхронное обслуживание индексов Операции обслуживания секций DROP PARTITION и TRUNCATE PARTITION были оптимизированы в версии 12с так, чтобы обслуживание касалось только метаданных. "По умолчанию" обслуживание глобальных индексов для этих операций является асинхронным. Эти операции могут быть выполнены без ограничения доступности к глобальному индексу. Обслуживание глобального индекса после операций DROP и TRUNCATE может быть завершено во время минимальной нагрузки на систему без влияния на доступность индекса. Это делает операции обслуживания секций и подсекций более быстрыми и менее требовательными к ресурсам. Опция UPDATE INDEXES требуется для обеспечения обратной совместимости. Существует ряд ограничений на операции асинхронного обслуживания индексов, а именно асинхронное обслуживание: Применимо только для обычных (heap) таблиц. Не поддерживает таблицы с табличными типами. Не поддерживает таблицы с доменными индексами. Не выполняется для объектов пользователя SYS. Для обработки глобальных индексов, требующих обслуживания, используется автоматическое задание планировщика SYS.PMO_DEFERRED_GIDX_MAINT_JOB. "По умолчанию" это задание запускается в 2:00 ночи каждые сутки. Задание может быть запущено в любое время с помощью DBMS_SCHEDULER.RUN_JOB для упреждающего обслуживания индексов. Частичные индексы (partial indexes) Для секционированных таблиц стало возможным создавать локальные или глобальные индексы на часть секций, что дает большую гибкость в определении индексов для таких таблиц. При создании или изменении таблицы для нее в целом или для отдельной секции может быть задан признак индексирования. Это свойство предполагается для частичных индексов. Частичное индексирование не поддерживается для уникальных индексов или для индексов, используемых для осуществления ограничений уникальности. "По умолчанию" любой индекс создается как полный, который отделяет индекс от свойства индексируемости таблицы. Опция INDEXING может быть указана для секции или подсекции. В примере показано создание секционированной таблицы SALES: SQL> CREATE TABLE sales ( sales_id NUMBER, customer_id NUMBER, sale_date DATE, sale_total NUMBER(9,2)) INDEXING OFF 114

PARTITION BY RANGE (SALE_DATE) (PARTITION sales_p11 VALUES LESS THAN (TO_DATE('01-JAN-2011','DD-MON-YYYY')) INDEXING OFF, PARTITION sales_p12 VALUES LESS THAN (TO_DATE('01-JAN-2012','DD-MON-YYYY')) INDEXING ON, PARTITION sales_p13 VALUES LESS THAN (TO_DATE('01-JAN-2013','DD-MON-YYYY')) INDEXING ON, PARTITION sales_p14 VALUES LESS THAN (TO_DATE('01-JAN-2014','DD-MON-YYYY')) INDEXING ON, PARTITION sales_p15 VALUES LESS THAN (TO_DATE('01-JAN-2015','DD-MON-YYYY')) ); Частичное индексирование для этой таблицы таково Секции SALES_P12, SALES_P13 и SALES_P14 включены во все частичные глобальные индексы Локальные индексы (для индексов, созданных с опцией PARTIAL) соответствуют трем приведенным секциям и создаются доступными к использованию "по умолчанию". Остальные секции исключены из всех частичных глобальных индексов и созданы недоступными в локальных индексах (для индексов, созданных с опцией PARTIAL). ONLINE перемещение секций Операция ALTER TABLE MOVE PARTITION теперь позволяет проводить DML операции во время перемещения секций. При переносе секции глобальные индексы обслуживаются, поэтому ручная перестройка индексов не требуется.

115

Улучшения в SQL Настройка расширенных типов данных В версии Oracle 12c максимальный размер данных для VARCHAR2, NVARCHAR2 и RAW увеличен до 32767 байт. Параметр инициализации MAX_STRING_SIZE определяет, будет ли база данных поддерживать расширенные размеры. Если параметр установлен в STANDARD (по молчанию), то действуют ограничения младших версий: 4000 для VARCHAR2 и NVARCHAR2, и 2000 для RAW. При установке в EXTENDED тип данных может размещать до 32767 байт. Если столбцы типов VARCHAR2 или NVARCHAR2 имеют длину более 4000 байт, или типа RAW более 2000 байт соответственно, то они считаются данными расширенного типа. Расширенные типы данных используют технологию LOB для хранения избыточных, по сравнению с "обычными", данных. В табличных пространствах с автоматическим размещением сегментов (Automatic Segment Space Management (ASSM)) расширенные типы данных хранятся как SecureFiles LOBs. В противном случае, как BasicFiles LOBs. Механизм хранения поддерживается базой данных прозрачно для пользователя. Столбцы "расширенного" типа не появляются как LOB в операциях пользователя и не могут обрабатываться посредством пакета DBMS_LOB. Применение ограничений количества строк в выборке (Top-N SQL запросы) До версии 12c Oracle не давал каких-либо простых средств построения Top-N SQL запросов. Запросы, которые ограничивали количество возвращаемых строк при помощи псевдостолбца ROWNUM, возвращали данные ДО выполнения операций сортировки ORDER BY, и, конечно, не давали ожидаемых Top-N результатов. Два новых параметра, FETCH FIRST и OFFSET, обеспечивают естественную поддержку этой возможности в SQL. Стало возможным с помощью простого SQL запроса ограничить количество возвращаемых строк и указать начальную строку возвращаемого набора. Например, следующий запрос получит список из четырех сотрудников с максимальной зарплатой: SQL> SELECT first_name, last_name, salary FROM hr.employees ORDER BY salary DESC FETCH FIRST 4 ROWS ONLY; FIRST_NAME LAST_NAME SALARY ------------ ----------- -------Vano Dudadze 21000 Dan Kohen 19000 Alex Cooper 14500 Peter Crause 12100

Такая команда, как FETCH LAST, отсутствует. Чтобы получить данные с наибольшими значениями N следует отсортировать их в порядке убывания. Например, следующий запрос пропускает четыре строки с наивысшими значениями и выводит список следующих пяти работников с максимальным окладом: SQL> SELECT first_name, last_name, salary FROM hr.employees 116

ORDER BY salary DESC OFFSET 4 ROWS FETCH NEXT 5 ROWS ONLY; FIRST_NAME LAST_NAME SALARY ------------ ----------- -------Karen Ogayan 11900 Mikhail Vantstein 11800 Nina Greenberg 10900 Rita Hu 10100 Dima Erzuriz 10000

Вместо количества строк в качестве параметра FETCH NEXT также можно задавать долю в процентах. Следующий запрос выводит список из 4% работников с наивысшими окладами: SQL> SELECT first_name, last_name, salary FROM hr.employees ORDER BY salary DESC FETCH NEXT 4 PERCENT ROWS ONLY; FIRST_NAME LAST_NAME SALARY ------------ ----------- -------Vano Dudadze 21000 Dan Kohen 19000 Alex Cooper 14500 Peter Crause 12100 Karen Ogayan 11900

Безопасные файлы (Secure Files) Начиная с версии Oracle 12c при установке параметра COMPATIBLE в 12.1 или выше, для размещения данных LOB "по умолчанию" используются безопасные файлы. Функция SecureFiles обеспечивает более высокую производительность по сравнению с BasicFiles при хранении неструктурированных данных. В этой версии сделаны следующие улучшения SecureFiles:

o o o o o o o o o o

Параллельные операции - SecureFiles обладают улучшенной поддержкой для параллельных DML операций. Несекционированные таблицы, содержащие только столбцы SecureFiles LOB (,не имеющие BasicFiles столбцов), могут поддерживать параллельные операции DML. Следующие операции могут выполняться параллельно: INSERT INSERT AS SELECT CREATE TABLE AS SELECT DELETE UPDATE MERGE (conditional UPDATE and INSERT) Multi-table INSERT SQL Loader Import/Export LogMiner - LogMiner

117

LogMiner - LogMiner полностью поддерживает SecureFiles LOB, включая поддержку дедупликации для столбцов SecureFiles LOB и операций SecureFiles Database File System (DBFS) при установке параметра совместимости в 11.2 и выше. Заполнены могут быть только столбцы SQL_REDO для SecureFiles LOB; столбец SQL_UNDO не заполняются. Применение Oracle Database Migration Assistant для преобразования в Unicode Утилита Database Migration Assistant for Unicode (DMU) поставляется с Oracle 12c Release 1 (12.1) и является официально поддерживаемым методом миграции на набор символов Unicode. Устаревшие утилиты Database Character Set Scanner (CSSCAN) и CSALTER удалены из пакета инсталляции и не поддерживаются. Утилита DMU автоматизирует много миграционных задач. Для существующих баз данных, уже использующих набор символов Юникод, или баз после миграции, DMU поддерживает режим проверки. В этом режиме определяются данные, неверно закодированные в Юникоде, чтобы определить возможные проблемы при реализации Юникода в приложениях базы данных. Для поддержки возможностей DMU база данных должна удовлетворять нескольким критериям: Версия СУБД должна быть 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1 или старше. Набор символом базы данных должен быть на основе ASCII. Должен быть установлен пакет SYS.DBMS_DUMA_INTERNAL. Продукт Oracle Database Vault должен быть отключен до начала процесса миграции. База данных не может быть подключаемой (PDB). База данных должна быть открыта в режиме чтение/запись. Некоторые возможности DMU: Избранное преобразование (Selective Conversion) - утилита DMU имеет возможность обрабатывать только данные, которые должны быть преобразованы, на уровне таблицы, столбца или строки. Отслеживание (Monitoring) - DMU имеет графический интерфейс для отображения процесса преобразования. Встроенное преобразование (Inline Conversion) - База данных Oracle поддерживает встроенное преобразование содержимого с использованием DMU. Работа по расписанию (Scheduling) - Действия по очистке могут быть назначены для позднего выполнения во время операции преобразования. Перед тем, как станет возможным преобразование базы в юникод, утилита DMU должна просмотреть данные в столбцах типов VARCHAR2, CHAR, LONG и CLOB. В этот момент будет определено, существуют ли каких-либо проблемы, которые могут вызвать искажение данных при преобразовании. Утилита DMU преобразует символьные данные в столбцах из объявленного набора символов в целевой набор юникода. Затем она проверяет каждое полученное значение на отсуствие ошибок: Результат преобразования отличен от исходного значения. 118

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

119

Ключевые навыки администратора базы данных Основы администрирования Общие замечания об администрировании В любом бизнесе существует достаточно жесткая иерархия. Подразделение, отвечающее за информационные технологии, в состав которого входят и администраторы баз данных, всегда является частью бизнеса, и поэтому "играет" по его правилам. К большому сожалению, среди людей, называющими себя термином "администратор", необязательно DBA, обычно этим страдают администраторы операционных систем, сложилось странная, и на взгляд автора, неверная практика ставить себя выше остальной части бизнеса. Почему это практика является странной и, в конечном счете, порочной? Деньги зарабатывает бизнес. Да, можно сказать, что без IT-систем поддержки бизнеса, он заработал бы меньше. Но, в любом случае он заработал бы! Бизнес зарабатывал тогда, когда все записи в бухгалтерских книгах велись от руки, и справлялся, причем неплохо. А вот ценность IT-структуры без бизнес-наполнения крайне сомнительна, точнее она практически нулевая и равна стоимости б/у оборудования. Иначе говоря, в адекватной бизнес-иерархии выше всех стоит пользователь, который и зарабатывает деньги не только себе, но и для акционеров, да и на зарплаты IT-отделов тоже. Если представитель бизнеса приходит к IT с требованием установить какое-то приложение для работы, а специалист IT и офицер безопасности в ультимативной форме говорят, "это/здесь мы ставить не будем", то собственнику бизнеса или управляющим имеет смысл озаботиться организацией бизнес-процесса. Тратящие деньги не могут определять работу тех, кто деньги зарабатывает, а местоположение в иерархии зависит только от приближенности пользователю, а не от сложности применяемых решений. Итак, на самом верху стоит пользователь. "Этажом" ниже пользователей стоит администратор бизнес-приложения: SAP-базиса, 1С бухгалтерии, почтовой системы etc, т.е. любого продукта, с которым в силу своих служебных обязанностей работает пользователь. Еще на ступеньку вниз стоит администратор базы данных, которая обслуживает бизнесприложение. Еще на ступеньку вниз стоит администратор системы резервного копирования данных, которая обслуживает бизнес-приложение. Еще на ступеньку вниз стоит администратор операционной системы, используемой для организации функционирования БД и бизнес-приложения и рабочих мест пользователей. Еще ниже находится администратор систем сетевого хранения данных и дисковых массивов. Еще ниже находится администратор сети передачи данных. Офицер безопасности (ОФ) не включается в эту иерархию, поскольку его обязанностью является контроль всех параметрами приложений и сервисов, которые могут повлиять на безопасность данных. Конечно, это не значит, что офицер безопасности может вмешиваться в настройки оборудования и систем, не ставя в известность соответствующие службы. Автор неоднократно наблюдал, как произвольное решение ОФ, принятое без понимания работы 120

приложений, приводило к остановке бизнес-процесса или потере существенной части функциональности. В качестве идеального примера можно привести внутреннюю фильтрацию ICMPпакетов в рамках странной трактовки сетевой безопасности. В результате некоторые ОС, например, HP-UX, удаляли часть сетевых маршрутов, что приводило к полной остановке работы приложений. Другим идеальным примером является установка ограничений длительности сессий во внутренних сетях передачи данных. Вроде бы, благое дело. В результате полностью прекратилось резервное копирование, т.к. сетевые экраны разрывали соединение с агентами до завершения операций. В итоге действия ОФ, несогласованные с администраторами приложений, приводили к остановке бизнеса. Как говорится, с такими друзьми злоумышленники не нужны! Требования бизнеса являются определяющими и для ОФ, и его обязанностью является организация безопасной среды для выполнения требований бизнес-процесса. Из сказанного видно, что в иерархии DBA занимает важное, но отнюдь не самое главное место. Основы архитектуры базы данных Реляционная система управления базами данных Oracle обладает большими возможностями и является достаточно сложной. СУБД создавалась как всесторонняя, открытая и интегрированная система управления информацией. Она может управлять большими объемами данных в многопользовательской среде, обеспечивая одновременный доступ к данным для тысяч пользователей. Она обеспечивает высокий уровень безопасности данных, высокую производительность и обладает очень эффективными средствами восстановления после сбоев. Понятия "база данных" и "экземпляр" На самом высоком уровне сервер базы данных Oracle состоит из двух различных компонентов: базы данных и одного или более экземпляров. В общем случае термин "база данных Oracle" часто используется для обозначения обоих компонент. По определению: База данных (Database) - База данных представляет собой набор файлов на диске, который хранит данные. Эти файлы могут существовать независимо от экземпляра. Экземпляр базы данных (Database instance) - Экземпляр представляет собой набор структур в памяти, предназначенный для управления файлами базы данных. Экземпляр базы данных Oracle состоит из разделяемой области памяти и набора фоновых процессов. Экземпляр может существовать независимо от файлов базы данных. В обычных конфигурациях существую единственный экземпляр и единственная база данных. Однако, при использовании Real Application Clusters (RAC), несколько экземпляров работают с одной базой данных. Кластерная конфигурация обеспечивает повышенную масштабируемость, производительность и устойчивость к сбоям. Oracle Data Guard представляет собой конфигурацию, в которой одна первичная база данных связана с одной или более резервными базами данных. Резервные базы данных могут быть физическими, т.е. представлять собой побайтовые копии первичной базы. В этом случае они поддерживается в синхронном состоянии с первичной базой путем приложения журнальных файлов повторения (redo-журналов). Резервные базы могут быть логическими, т.е. синхронизация баз осуществляется передачей SQL команд с помощью продукта Oracle Streams. 121

В Oracle Learning Library (http://www.oracle.com/webfolder/technetwork/ tutorials/obe/db/12c/r1/poster/OUTPUT_poster/poster.html) содержится документ, детально представляющий структуру экземпляра и базы данных. Нет необходимости запоминать все детали этих диаграмм, но они помогут составить представление, как взаимодействуют разные компоненты экземпляра базы данных. На рисунке приведены основные компоненты экземпляра базы данных: Экземпляр Системная глобальная область System Global Area (SGA)

Фоновые процессы Background Processes PMON

Разделяемый пул Shared Pool Library Cache

Database Buffer Cache User Global Area

Shared SQL Area Data Dictionary Cache

Server Result Cache

Reserved Pool

Private SQL Area

DBWn LGWR

Other

Fixed SGA CKPT Java Pool

Large Pool Response Queue

SMON

Others ... XA Interface Pool

PX Msg Pool

Request Queue

Streams Pool

Backup Recovery Ops Redo Log Buffer

Рис. 25 Структуры памяти и фоновые процессы экземпляра Oracle

При старте экземпляра запускаются фоновые процессы, и выделяются области памяти в ОС. Выделенная область памяти хранит множество разных данных, необходимых для функционирования базы данных. Вот некоторые основные структуры памяти: Системная глобальная область (System Global Area) (SGA) - SGA представляется собой группу структур разделяемой памяти, которая содержит данные и управляющую информацию для одиночного экземпляра Oracle. SGA делится между серверными и фоновыми процессами. Примерами данных, хранимых в SGA, являются кэшируемые блоки данных и разделяемые SQL области Глобальная программная область (Program Global area) (PGA) - Область PGA неразделяемая. Она содержит данные и управляющую информацию исключительно для одного процесса Oracle. Область PGA создается при старте процесса Oracle. Одна область

122

PGA создается для каждого серверного и фонового процесса. Набор всех отдельных областей PGA составляет общую область PGA экземпляра. Пользовательская глобальная область (User Global Area) (UGA) - Область UGA связана с пользовательской сессией. Области программного кода (Software code areas) - Области оперативной памяти, содержащие программный код, который выполняется или может выполняться. Системная глобальная область System Global Area (SGA) Системная глобальная область SGA представляет собой область оперативной памяти, содержащей все данные, необходимые для работы экземпляра базы данных. Она состоит из множества компонентов. Каждый компонент представляет собой участок памяти, используемый для размещения объектов определенного типа. Все компоненты за исключением буферов журнальных файлов повторов (redo log buffer) размещаются и освобождают память в единицах непрерывной памяти, называемых гранулами (granules). Для получения информации о компонентах области SGA нужно запросить представление V$SGASTAT. Наиболее важными компонентами области SGA являются: Буферный кэш базы данных (Database Buffer Cache) - Буферный кэш содержит копии блоков данных, прочитанных из файлов. Буфер это адрес, где менеджер буфера временно хранит (кэширует) текущий или ранее использованный блок данных. Все пользователи базы данных, подключенные к экземпляру, делят доступ к буферному кэшу. Буферный кэш создан для оптимизации операций физического ввода/вывода. Часто используемые блоки хранятся в буферном кэше, редко используемые выгружаются из памяти на диск. Для определения, какой блок будет сохраняться в буферном кэше, используется алгоритм Least Recently Used (LRU). Буфер журнальных файлов повторов (Redo Log Buffer) - Буфер журнальных файлов повтора представляет собой кольцевой буфер, содержащий записи повтора, описывающие изменения, сделанные в базе данных. Эти записи содержат информацию, необходимую для реконструкции изменений, сделанных в базе данных в результате DML или DDL операций. При восстановлении (recovery) база данных прикладывает записи повтора к блокам файлов данных для восстановления потерянных изменений. Записи повтора (redo) занимают непрерывное, последовательное пространство в буфере. Фоновый процесс записи журнальных файлов (log writer (LGWR)) записывает содержимое журнального буфера в активную группу журналов повтора на диск. Разделяемый пул (Shared Pool) - разделяемый пул содержит различные типы программ, требуемых сервером. Частичный список включает разобранные операторы SQL, код PL/SQL, системные параметры, объекты словаря данных. Пул участвует в практически каждой операции базы данных. Помимо всего, каждый оператор SQL, выданный пользователем, требует доступа к разделяемому пулу. Большой пул (Large Pool) - Большой пул - опциональная часть SGA. Он предназначен для размещения областей памяти, которые слишком велики для размещения в разделяемом пуле. Примерами таких областей является область UGA (пользовательская глобальная

123

область User Global Area) для разделяемых серверов, интерфейс XA Oracle и буфера для процессов ввода/вывода менеджера восстановления RMAN. Java пул (Java Pool) - Пул используется для хранения всего специфичного для сессии кода и данных внутри виртуальной машины Java. Он также включает объекты Java, которые мигрировали в пространство Java-сессии по завершении. Потоковый пул (Streams Pool) - Область памяти, используемая только Oracle Streams. Она хранит буферизованные очереди сообщений и обеспечивает память для процессов захвата и применения. Если не настроено иначе, размер области начинается с нуля и растет динамически, по потребностям Oracle Streams. Фиксированная область SGA (Fixed SGA) - Фиксированная область SGA - это внутренняя служебная область. Она содержит общую информацию, нужную фоновым процессам о состоянии базы данных и экземпляра. Размер области устанавливается базой данных Oracle автоматически и не может быть изменен вручную.

124

Установка и начальная настройка базы данных В старые добрые времена создание базы данных Oracle означало использование оператора CREATE DATABASE, который требовал задания множества параметров и делал все, что было нужно. Вряд ли кто-то сожалеет, что теперь можно обойтись без этого. Утилита Database Create Assistant (DBCA) является существенно более простым средством создания базы данных. Более того, по завершении работы DBCA база данных готова к работе, тогда как база, созданная при помощи CREATE DATABASE, требует запуска нескольких скриптов прежде, чем работы с ней будет возможна! Для запуска DBCA нужно зарегистрироваться на сервере БД под пользователем, имеющим права для создания и запуска БД. Обычно это администратор баз данных. Для запуска DBCA на UNIX/Linux или в командной строке Microsoft Windows нужно ввести команду dbca. Исполняемый модуль dbca расположен в директории ORACLE_HOME/bin. После запуска утилита DBCA соберет требуемую информацию и создаст базу данных в соответствии с замыслом администратора. Типовой набор шагов/экранов при создании базы данных с помощью утилиты dbca приведен ниже. Шаг 1. Операции с БД. На этом шаге нужно выбрать одну из операций: создание, настройку или удаление базы данных, настройку шаблонов создания БД или управление перемещаемыми (pluggable) БД (опция недоступна при отсутствии настроенных перемещаемых БД).

Рис. 26 Создание базы данных с помощью утилиты DBCA. Шаг 1

125

Шаг 2. Режим создания БД. На этом шаге необходимо выбрать имя базы данных, тип дисковой памяти, расположение файлов и области быстрого восстановления (fast recovery area), используемый набор символов и пароль администратора БД. Если используется Enterprise версия, то можно создать базу контейнерного типа. В расширенном (Advanced) режиме возможно задание множества других параметров БД.

Рис. 27 Создание базы данных с помощью утилиты DBCA. Шаг 2

126

Шаг 3. Проверка соответствия требованиям. - DBCA проверяет, что выполняются все необходимые условия для создания БД

Рис. 28 Создание базы данных с помощью утилиты DBCA. Шаг 3

127

Шаг 4. Сводка - На этом экране показано, с какими параметрами будет создана БД в данный момент.

Рис. 29 Создание базы данных с помощью утилиты DBCA. Шаг 4

128

Шаг 5. Процесс создания БД - На экране отображается процесс создания базы данных.

Рис. 30 Создание базы данных с помощью утилиты DBCA. Шаг 5

Когда DBCA завершает свою работу, база данных полностью готова к использованию, т.е. можно подключаться с БД и создавать пользователей и объекты. Сразу после создания, смены версии БД или установки исправлений следует запустить скрипт utlrp.sql. Этот скрипт перекомпилирует все PL/SQL модули, включая пакеты, процедуры и триггеры, которые могут быть в недействительном состоянии. "По умолчанию" скрипт производит параллельную перекомпиляцию, основываясь на параметре CPU_COUNT хоста. Этот шаг необязателен, но Oracle рекомендует сделать во время создания базы данных, а не позднее.

129

Настройка сетевой поддержки для сервера и клиента базы данных Для связи между компонентами в распределенном сетевом окружении используется продукт Oracle Net Services. Один из компонентов Oracle Net Services, а именно, Oracle Net, позволяет устанавливать соединение клиентского приложения c базой данных Oracle. Когда установлена сессия между клиентским приложением и базой данных, Oracle Net выполняет передачу данных. Компонент Oracle Net устанавливает и обслуживает соединение между приложением и базой данных и является обязательной частью механизма обмена сообщениями на протяжении всей сессии. Компонент Oracle Net делает возможным установление сессий между традиционными приложениями клиент/сервер и базой данных. Он находится и на клиенте, и на сервере, работает по протоколу TCP/IP, обеспечивая возможность соединения и передачи данных между клиентом и базой данных. На рисунке приводится схема взаимодействия клиента и сервера при помощи Oracle Net. Помимо Oracle Net существуют другие типы соединений Java Application, Web Client при помощи Application Web Server и другие. Полное описание приводится в документе Oracle Database Net Services Administrator's Guide 12c Release 1 (12.1) документ E17610-11.

TCP/IP сеть

клиент

Приложение

RDBMS

Oracle Net

Oracle Net

сервер

Рис. 31 Взаимодействие клиент-сервер с использованием Oracle Net

На клиенте Oracle Net представляет собой фоновый компонент, позволяющий установить соединение с базой данных. На стороне сервера Oracle Net согласует соединения между базой данных и клиентами. Хотя наиболее часто встречается использование Oracle Net для обработки входящих соединений с базой данных Oracle, возможно его использование для доступа к отличным от Oracle источникам данных, типа SQL сервер или DB2, или для доступа к внешним библиотекам через EXTPROC. Сервер базы данных Oracle получает запрос на установление соединения через прослушиватель Oracle Net, далее прослушиватель. Прослушиватель это фоновый процесс, который слушает выделенный порт, ожидая запросы к базе данных. Он обрабатывает запрос клиента и передает его серверу. Прослушиватель настроен на определенный протокол и адрес. Клиенты, имеющие такую же настройку, могут послать запросы на установление соединений с сервером. Когда соединение установлено, клиент и сервер базы данных могут взаимодействовать друг с другом напрямую. Остановка прослушивателя не позволит установить новые соединения, но не повлияет на существующие. Чтобы установить соединение с сервисом базы данных, клиент должен иметь описание соединения (connect descriptor), указывающее расположение и имя сервиса базы данных. В следующем примере приводится описание типа Easy Connect для установления соединения с сервисом ocp.exam.com на сервере ocp-server с использованием порта "по умолчанию" (1251): ocpserver/ocp.exam.com. 130

Чтобы приведенное описание соединения было работоспособным, нужно чтобы требуемая база данных имела соответствующую запись в файле tnsnames.ora клиента. Подходящей для приведенного выше примера соединения и сервера будет: (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=ocp-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=ocp.exam.com)) )

Описание соединения это специально форматированное описание пункта назначения сетевого соединения. Оно содержит имя сервиса назначения и сетевой путь. Сервис назначения указан по имени, а сетевой путь - по расположению, путем указания сетевого адреса. Описание соединения состоит из одного или нескольких протоколов/адресов прослушивателя и информации соединения для сервиса назначения в файле tnsnames.ora. В примере приведено описание соединения с базой данных ocp: ocp= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp) (HOST=ocp-server) (PORT=1521) ) (CONNECT_DATA=(SID=ocp) (SERVICE_NAME=ocp.exam.com) (INSTANCE_NAME=ocp) ) )

Раздел ADDRESS содержит следующие параметры: PROTOCOL – Указывает тип протокола, 'tcp' используется для TCP/IP. HOST – Указывает имя хоста, т.е. ocp-server. Можно использовать IP-адрес, если используется протокол TCP/IP. PORT – Указывает порт, "по умолчанию" используется порт 1521. Раздел CONNECT_DATA содержит следующие параметры: SID – Указывает SID базы данных Oracle database, в данном случае ocp. SERVICE_NAME – Указывает имя сервиса назначения. В примере ocp.exam.com. Значение параметра берется из параметра инициализации SERVICE_NAMES. В общем случае SERVICE_NAMES является глобальным именем базы данных. INSTANCE_NAME – Указывает имя экземпляра. Необязательный параметр, "по умолчанию" совпадает с SID. Если база данных настроена на работу в режиме выделенного сервера, то прослушиватель запускает выделенный серверный процесс для каждого клиентского соединения. Таким образом, каждый серверный процесс обслуживает одного клиента. Когда сессия завершается, выделенный серверный процесс завершается. Процесс установления клиентской сессии включает в себя несколько шагов:

131

Прослушиватель получает запрос клиента на установление соединения. Прослушиватель запускает серверный процесс, и выделенный сервер наследует запрос на соединение от прослушивателя. Клиент устанавливает соединение с выделенным сервером. Сервер проверяет аутентификационные данные клиента. Если клиент аутентифицирован, создается сессия с базой данных. Чтобы установить соединение с базой данных с клиентской машины, нужно чтобы клиентский компьютер имел информацию о расположении сервера базы Oracle, и на каком порту работает прослушиватель. Настройка клиентской сети это действия по определению способов, посредством которых клиенты смогут определить адрес сервера базы данных. Существует ряд методов для получения адресной информации: Метод локальных имен (Local Naming Method) При использовании этого метода адресации вся информация хранится в файле TNSNAMES.ORA. "По умолчанию" он находится в директории $ORACLE_HOME/network/admin/. Имена сетевых сервисов и дескрипторов соединения содержатся в этом файле. В примере дескриптор соединения ocp_1 указывает на сетевой сервис sales.us.example.com: ocp_1= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=ocprep-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.example.com)))

Секция DESCRIPTION описателя соединения определяет целевой сервис базы данных и определяет используемый при соединении протокол. В приведенном примере используется протокол TCP/IP на порту 1251. Метод локальных имен может быть настроен при создании базы данных Oracle или потом. Во время установки программного обеспечения помощник Oracle Net Configuration Assistant предлагает настроить имена сетевого сервиса. После установки можно настроить метод локальных имен с помощью Oracle Net Configuration Assistant, Oracle Enterprise Manager Cloud Control или Oracle Net Manager. Метод простого соединения (Easy Connect Naming Method) При использовании метода простого соединения поиск имени сервиса в файле TNSNAMES.ORA не выполняется. При использовании этого метода не используется каких-либо системы имен или директорий. Метод позволяет установить соединение с сервером базы данных, используя имя хоста базы данных и, при необходимости, порта и сервиса. Основной формат определен следующим образом: CONNECT username@[//]host[:port][/service_name][:server][/instance_name] Дескриптор соединения, используемый при простом соединении, соответствует следующему описателю соединения в файле TNSNAMES.ORA: (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=port)) (CONNECT_DATA=

132

(SERVICE_NAME=service_name) (SERVER=server) (INSTANCE_NAME=instance_name)))

"По умолчанию" имя сервиса при установке Oracle в режиме Typical совпадает с именем базы данных. Синтаксис простого соединения, используемый для подключения к экземпляру: SQLPLUS /nolog SQL> CONNECT username@host/db_name Enter password:

Для подключения к экземпляру из примера выше для метода локальных имен полный синтаксис простого соединения выглядит следующим образом: CONNECT username@ocp_1:1521/sales.us.example.com Метод простого соединения можно использовать, если выполнены все следующие условия: Обеспечение Oracle Net Services установлено на клиентской машине. Протокол TCP/IP поддерживается и клиентом, и сервером базы данных. Не используются какие-либо возможности типа вызова внешних процедур, гетерогенных сервисов и т.п., требующих более детального описания соединения. Параметр EZCONNECT указан в параметре NAMES.DIRECTORY_PATH в файле sqlnet.ora. Метод службы каталога (Directory Naming Method) Метод службы каталога использует LDAP-совместимый сервер, например Oracle Internet Directory. При использовании этого метода описатели соединения отображаются на дескрипторы соединения в сервере каталогов. LDAP-каталог обеспечивает централизованное администрирование сервисов баз данных и имен сетевых сервисов. Запись о сервисе базы данных создается во время создания базы данных Oracle. По завершении установки, можно настроить доступ клиентов к базе данных с использованием LDAPкаталога посредством Oracle Enterprise Manager Cloud Control или Oracle Net Manager. С помощью этих продуктов можно создавать или менять имена сетевых сервисов и алиасов, и модифицировать записи для сервисов баз данных. Будучи настроенными, клиенты могут использовать записи каталога для подключения к базе данных. Метод внешних имен (External Naming Methods) Метод внешних имен использует для определения пути к базе данных внешний сервис, такой как NIS. Этот метод позволяет разрешать имена сетевых сервисов в сетевые адреса. Компании, использующие NIS, могут настроить эту службу для хранения имен сетевых сервисов и адресов, используя внешнее имя NIS. Когда клиентская программа пытается установить соединение с базой данных, используя имя сетевого сервиса, сервер NIS разрешает имя сервиса в адрес Oracle Net и возвращает это адрес клиенту. Клиентская программа использует полученный адрес для соединения с базой данных Oracle.

133

Отслеживание оповещений базы данных Фоновые процессы, составляющие экземпляр Oracle, имеют свои собственные файлы трассировки. Если процесс фиксирует ошибочную ситуацию, то он сбрасывает информацию об ошибке в определенный трассировочный файл. Часть трассировочной информации предназначена для администратора баз данных, а остальная часть для службы Oracle Support. Помимо файлов трассировки имеется файл оповещений всей базы данных (alert.log). В нем содержится хронологический список сообщения и ошибок базы данных. Некоторые из сообщений, заносимых в журнал оповещений: Инициализационные параметры со значениями, отличными от значений "по умолчанию". Все сообщения о внутренних ошибках (ORA-600), о поврежденных блоках (ORA-1578) и взаимных блокировках (ORA-60). Многие административные команды, включая команды DDL CREATE, ALTER и DROP, а также команды STARTUP и SHUTDOWN. Журнал оповещений ведется в двух версиях одновременно: файл в XML-формате и файл в текстовом формате. Любую из версий можно просматривать с помощью текстового редактора. С помощью утилиты adrci можно просмотреть "очищенный" от тэгов журнал в формате XML. Одной из ежедневных, в крайнем случае периодических, обязанностей администратора базы данных является просмотр журнала оповещений и трассировочных файлов с целью обнаружения ошибок сервера или фоновых процессов. Журнал оповещений и трассировочные файлы записываются в директории, являющиеся частью репозитория автоматической диагностики (ADR, Automatic Diagnostic Repository). В общем случае имя трассировочного файла включает имя процесса, создавшего его, например . MMON или LGWR. Параметр MAX_DUMP_FILE_SIZE задает максимальный размер трассировочного файла в блоках файловой системы, если не указана размерность, килобайтах, мегабайтах или гигабайтах. Размер журнала оповещения ограничить невозможно, поэтому нужно периодически удалять его, чтобы размер оставался приемлемым. Удаление файла журнала возможно при работе экземпляра. В общем случае следует хранить архивную копию файла журнала, если это требует техническая политика компании. При возникновении любой критической ошибки серверный процесс создаст один или несколько трассировочных файлов. Если параметр инициализации SQL_TRACE установлен в TRUE, модуль трассировки SQL создаст статистики производительности для операторов SQL, выполняемых экземпляром. Эти трассировочные файлы будут в ADR. Кроме этого, трассировка SQL может быть разрешена на уровне сессии с помощью команды ALTER SESSION SET SQL_TRACE. Пакеты DBMS_SESSION и DBMS_MONITOR служат для управления трассировкой SQL на уровне сессии. Адаптивные пороги (Adaptive Thresholds) В версии 12с появилась возможность отслеживать производительность базы данных непрерывно с помощью адаптивных порогов. Администратор БД может установить уровень предупреждения и критический уровень для множества системных метрик. Эти пороги создаются с использованием статистик, полученных из метрик, собранных в перемещающемся базовом окне. Статистики для метрик перемещающегося окна пересчитываются еженедельно и могут изменять величину порогов, если изменилась производительность системы. Адаптивные пороги могут

134

обнаруживать разные типы нагрузки на базу данных, такие как OLTP-запросы в течение дня, пакетные задания ночью, резервное копирование в выходные дни. Существует два типа адаптивных порогов:

o o o o

Процент от максимальной величины (Percentage of maximum) - Порог вычисляется как процент от максимального значения, наблюдаемого для данных в перемещающемся базовом окне (например, 95% от максимального значения). Уровень значимости (Significance level) - Порог представляет собой значение в процентилях, представляющее насколько необычно наблюдать значения выше порога. Порог задается одним из следующих значений: Высокое, High (.95) – ожидается, что только 5 из 100 наблюдений превысят это значение. Очень высокое, Very High (.99) – ожидается, что только 1 из 100 наблюдений превысит это значение. Серьезное, Severe (.999) –ожидается, только 1 из 1000 наблюдений превысит это значение. Экстремальное, Extreme (.9999) – ожидается, что только 1 из 10000 наблюдений превысит это значение.

Выполнение ежедневного сопровождения базы данных Список "ежедневных" процедур по обслуживанию базы данных, выполняемых администратором, может сильно варьироваться в зависимости от компании, базы данных (размера, типа нагрузки и т.п.) и личности администратора. Два разных человека, выполняющих один и тот список процедур, будет выполнять их разным образом. Некоторые администраторы любят автоматизировать максимально возможное количество повторяющихся работ. Другие, к ним относится и автор, предпочитает автоматизировать только регулярно повторяющиеся операции, или те операции, где требуется набирать много команд, и, соответственно, велика вероятность ошибки. Oracle в руководстве Oracle Database Administrator's Guide предлагает следующий список задач администратора: Установка и модернизация программного обеспечения Oracle и приложений. Размещение системной дисковой памяти и планирование будущих потребностей в ней для размещения баз данных. Создание первичных структур для размещения объектов баз дынных (табличных пространств). Создание объектов баз данных (таблиц, представлений, индексов). Планирование процедур резервирования и восстановления информации базы данных. Обеспечение взаимодействия с поддержкой Oracle. Проверка соответствия лицензионных соглашений. Изменение структуры базы данных, при необходимости. Заведение пользователей и обеспечение безопасности системы. Управление и отслеживание активности пользователей в базе данных. Отслеживание и настройка производительности базы данных. Ведение архивных данных на лентах/дисках. 135

Выполнение резервного копирования/восстановления базы данных. Список задач упорядочен по частоте выполнения: часто операции расположены в конце списка. К числу именно "ежедневных" можно отнести последние пять задач. Резервное копирование и восстановление, особенно для продуктивных систем, является наиболее важной задачей сопровождения базы данных. Продуктивная система нуждается не только в адекватной стратегии резервирования, администратор должен постоянно проверять успешность ее реализации и доступность копий данных, а также возможность восстановления базы данных из резервных наборов. Фраза "не потеряй данные" для администратора БД значит то же самое, что для врача "не навреди". Конечно, важно, чтобы база работала на пике производительности. Важно, чтобы пользователи были удовлетворены временем отклика. Но самое главное - данные должны быть целы, а в случае аварии должны быть восстановлены настолько полно, насколько возможно, в идеале полностью. Это первая и основная абсолютная цель.

136

Установка и анализ исправлений Единственным верным источником исправлений для программного обеспечения базы данных Oracle является сайт поддержки Oracle. Для получения исправлений нужно: Зарегистрироваться на My Oracle Support, ранее известный, как Metalink, и заранее оплатить поддержку. Нажать на вкладку Patches & Updates. На странице Patches & Updates в разделе Patch Search, ввести номер патча и нажать Search. На странице результатов поиска нажать на номер патча. My Oracle Support выведет детали описания патча в отдельном окне. Нажать Download. В диалоге File Download выбрать на имя patch.zip для загрузки файла на локальный диск. Нажать на Download Patch Metadata. В диалоге Download Patch Metadata выбрать Download для выгрузки файла метаданных. По рекомендациям Oracle после начальной инсталляции программного обеспечения и на регулярной основе администратор должен выгружать и устанавливать патчи. В реальной эксплуатации обычно следует проводить установку исправлений, если пользователи или БД встретилась с ошибками функционирования. Установка исправлений всегда согласуется с требованиями бизнес-подразделений и не может быть выполнена без их согласия. Oracle производит несколько типов исправлений: Промежуточные исправления (Interim Patches) - Содержат исправления одиночной ошибки или группы ошибок, предоставляемых по требованию. Могут содержать специфические для потребителя исправления безопасности. Диагностические исправления (Diagnostic Patches) - Предназначены для облегчения диагностики или проверки исправления/набора исправлений. Наборы исправлений (Patch Set Updates (PSU)) - Содержат набор значимых, малоответственных и проверенных исправлений для какого-либо продукта/компонента. Критические наборы исправлений (Critical Patch Updates (CPU)) - Набор исправлений для множества уязвимостей, включая проблемы безопасности. Некоторые патчи могут быть установлены при работающем экземпляре с использованием утилиты OPatch или Enterprise Manager Patch Wizard , который в свою очередь использует OPatch в фоновом режиме. Администратор может определить, какие исправления применимы к его системе, с помощью советника Patch Advisor из Enterprise Manager Cloud Control. Online исправления До версии 11g все патчи содержали либо объектные (расширение .о), либо архивные (.а) файлы. Их установка требовала перелинковки исполняемых файлов базы данных, иначе говоря, остановки экземпляра для применения исправлений. В настоящее время значительное количество исправлений может быть установлено "на ходу". Эти патчи содержат т.н. .so файлы, которые представляют собой динамические или разделяемые библиотеки, не требующие перелинковки исполняемых файлов. Поскольку перелинковка не нужна, эти исправления могут быть применены или отменены при активном экземпляре. Это упрощает администрирование, поскольку исчезает 137

необходимость в остановке базы данных. Это также означает, что установка/удаление online-патчей проводятся более оперативно, потенциально процедура занимает несколько секунд. Online-патчи устанавливаются с помощью утилиты OPatch. Применение online-патчей несет следующие преимущества: Отсутствие периода простоя. Независимость от остановок базы данных. Возможность вносить исправления на узлы RAC по очереди. Быстрая установка. Естественно, есть и недостатки: Требуется больше оперативной памяти. Исправления "на ходу" доступны не для всех платформ. Не все исправления могут быть применены "на ходу". Центр управления EM Cloud Control и обновления Центр управления Oracle Enterprise Manager Cloud Control 12c обладает новыми возможностями по управлению исправлениями. Целью нововведений является снижение сложности операций и минимизация времени простоя, связанные с установкой исправлений. Новое решение по управлению исправлениями предлагает следующие преимущества: Интегрированный с My Oracle Support процесс установки обновлений. Общий интерфейс позволяет видеть рекомендации, проводить поиск исправлений и выгружать патчи. Планы исправлений позволяют от начала и до конца управлять потоком патчей. Планы включают автоматический выбор процедур применения и анализа конфликта исправлений. Ранний обзор исправлений для определения применимости в данном окружении, проверки планов патчей и автоматическое получение подтверждения патчей для разрешения проблем проверки. Развертываемые планы исправлений могут быть сохранены как шаблоны установки, содержащие предопределенный набор патчей и параметров развертывания. Получение отдельных патчей для одиночных баз данных, объектов RAC и объектов Oracle Grid. План исправлений из Cloud Control помогает создать список патчей, которые нужно применить к группе из одного или нескольких целевых объектов, далее целей. Исправление может быть добавлено к плану цели только, если исправление имеет тот же уровень версии и тип платформы, что и цель. План также проверяет исправления для Oracle Database, Fusion Middleware и Cloud Control на соответствие окружению для выявления конфликта с установленными ранее патчами. На основании добавленных исправлений Enterprise Manager автоматически определяет подходящую процедуру развертывания, которая будет использоваться для применения патчей. EM Cloud Control может устанавливать исправления в двух различных режимах:

138

Online режим - Этот режим можно использовать, если политикой безопасности EM Cloud Control разрешено установить соединение с My Oracle Support, иначе говоря, нужен доступ в интернет. Этот режим позволяет администратору просмотреть рекомендации Oracle относительно устанавливаемых исправлений, вручную искать исправления на сайте My Oracle Support и добавлять их к плану установки исправлений. В этом режиме также возможно автоматическое разрешение конфликтов исправлений путем слияния патчей напрямую с My Oracle Support. Offline режим - Нужно использовать, если EM Cloud Control не имеет доступа к My Oracle Support напрямую. В этом режиме можно только искать исправления, которые ранее были загружены вручную в библиотеку обеспечения (Software Library), и добавлять найденные в план установки исправлений. Запросы к каталогу исправлений Начиная с версии 12с, представлена новая возможность - запросы к каталогу исправлений или интерактивный каталог исправлений (Queryable Patch Inventory). Этот функционал реализован с помощью пакета DBMS_QOPATCH. С помощью этого пакета можно просмотреть список установленных исправлений через PL/SQL или SQL интерфейс. Результатом запроса будет вся информация об исправлениях, доступная с помощью параметра lsinventory-xml утититы opatch. Пакет DBMS_QOPATCH получает доступ к репозиторию исправлений Oracle Universal Installer (OUI) в реальном времени для получения информации о патчах и их метафайлах Запросы к каталогу исправлений позволяют: Получать список установленных исправлений из командной строки SQL. Создавать отчеты и проводить проверки соответствия в нескольких средах окружения. Проверять список установленных исправлений для Oracle RAC с одного места. В пакет DBMS_QOPATCH включены следующие программы: GET_OPATCH_BUGS - Выдает список ошибок, исправленных патчем в формате XML, если задан номер патча. При отсутствии номера выдается список в формате XML всех исправлений для всех патчей. GET_OPATCH_COUNT - Выдает количество всех установленных исправлений в формате XML. GET_OPATCH_DATA - Выдает краткое описание исправления в формате XML (Patch ID, время создания). GET_OPATCH_FILES - Выдает список файлов, модифицированных при установке исправления формате XML. GET_OPATCH_INSTALL_INFO - Выдает XML элемент, содержащий описание ORACLE_HOME директорию с исправлениями и расположение каталога исправлений. GET_OPATCH_LIST - Выдает список исправлений в формате формате XML из каталога. GET_OPATCH_LSINVENTORY - Выдает полный список каталога исправлений в формате XML. GET_OPATCH_OLAYS - Выдает список патчей, накладывающихся на данный патч, в формате формате XML.

139

GET_OPATCH_PREQS - Выдает список требований, необходимых для установки патча в виде XML элемента. GET_OPATCH_XSLT - Выдает таблицу стилей (style-sheet) для представления каталога исправлений opatch. GET_PENDING_ACTIVITY - Выдает информацию, связанную с примененными на одиночном экземпляре SQL патчами путем запроса бинарного каталога. GET_SQLPATCH_STATUS - Выводит информацию о статусе SQL патча путем запроса SQL регистра патчей с получением полной информации. IS_PATCH_INSTALLED - Выдает информацию, такую как patchID, дату применения и данные SQL патча, в установленном исправлении в виде узла XML, запрашивая XML каталог. PATCH_CONFLICT_DETECTION - Выдает имя конфликтного исправления для данного файла патча, если имеется конфликт с существующим установленным патчем. SET_CURRENT_OPINST - Устанавливает имя узла и экземпляра для получения деталей расположения каталога исправлений, специфичных для среды Oracle Real Application Clusters (RAC). Детальное описание возможностей пакета содержится в документе My Oracle Support Doc ID 1530108.1 "Oracle Database 12.1 : FAQ on Queryable Patch Inventory".

140

Резервное копирование и восстановление базы данных Тема резервного копирования и восстановления базы данных весьма велика и не может быть раскрыта в рамках одной главы. Далее содержится более чем краткий обзор настройки Oracle’s Recovery Manager (RMAN), создания резервных копий и восстановления базы данных. Детальное описание следует искать в документе Oracle Backup and Recovery User's Guide 12c Release 1 (12.1) E50658-06s. Утилита RMAN имеет набор параметров, позволяющий управлять специфическими действиями во время резервирования. Стандартные значения большинства этих параметров важны для выполнения стандартных операций резервирования/восстановления. Понимание, за что отвечают те или иные параметры, позволит настроить поведение утилиты оптимально для данной базы данных. Постоянные установки, такие как расположение резервной копии, тип устройства, тип удержания,- могут быть заданы для каждой целевой базы. Интерес представляют две команды: SHOW - Команда выводит текущие установки RMAN для целевой базы данных. В выводе будут указано, являются ли параметры измененными, или же их значение "по умолчанию". Эта информация также доступна через представление V$RMAN_CONFIGURATION. CONFIGURE - Эта команда позволяет изменить текущее поведение RMAN в данном окружении резервирования/восстановления. При использовании ее с ключом CLEAR настраиваемый параметр сбрасывается в значение "по умолчанию". Некоторые примеры использования: Следующая команда устанавливает политику удержания, чтобы поддерживать три полных или уровня 0 резервных копии каждого файла данных и управляющего файла. Любая резервная копия, "старше", чем третий файл, считается устаревшей. Значение "по умолчанию" 1. RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3; Напротив, политика удержания может задавать окно восстановления, которое гарантирует наличие достаточного количества резервных копий для восстановления базы данных на любое прошедшее время внутри окна: RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; Когда тип целевого устройства резервного копирования не задан явно, RMAN создает резервную копию на устройстве, указанном "по умолчанию", т.е. на жестких дисках. Следующая команда задает магнитную ленту устройством "по умолчанию": RMAN> CONFIGURE DEFAULT DEVICE TYPE TO sbt; Независимо от установок типа устройства "по умолчанию" можно указать тип устройства напрямую, используя параметр DEVICE TYPE команды BACKUP, как показано ниже: RMAN> BACKUP DEVICE TYPE SBT DATABASE; RMAN> BACKUP DEVICE TYPE DISK DATABASE; 141

При резервировании на диск RMAN может быть настроен на создание "по умолчанию" либо наборов резервирования (backup set), либо копий образа данных (image copies). Для устройств типа лента тип резервного набора может быть только резервный набор. Дополнительно следует сказать, что менеджер RMAN способен создавать наборы резервирования с бинарным сжатием. Указание опции COMPRESSED в конструкции BACKUP TYPE TO BACKUPSET задает RMAN создание сжатых наборов резервирования для данного типа устройств. При опускании опции COMPRESSED сжатие выключается. Преднастроенный тип резервирования для диска - несжатый набор резервирования. В примере показана настройка RMAN для создания копий и резервных наборов: RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; Для включения сжатия резервных наборов следует добавить ключевое слово COMPRESSED: RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; RMAN> CONFIGURE DEVICE TYPE SBT BACKUP TYPE TO COMPRESSED BACKUPSET; Канал в RMAN определяется как соединение с сессией базы данных. Команда CONFIGURE CHANNEL используется для настройки опций для дисковых или каналов стримера. Если команда CONFIGURE CHANNEL используется для указания настроек канала для устройства "по умолчанию", любые предыдущие установки теряются. Любые установки, не указанные явно в CONFIGURE CHANNEL, будут установлены в значения "по умолчанию". RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 1G; RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/tmp/%U'; "По умолчанию" RMAN выделяет один дисковый канал для всех операций. При необходимости можно изменить размещение и формат имени файла "по умолчанию" для данного канала. Следует помнить, что если задан явный формат резервных копий для дискового канала, то RMAN не будет делать резервные копии "по умолчанию" в области быстрого восстановления (fast recovery area). RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u01/ora_df%t_s%s_s%p'; RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1'; Если задать несколько каналов, настроенных на разные дисковые пути, то RMAN распределит резервные копии между ними. Для этого нужно задать канал типа DEVICE TYPE DISK для каждого дискового пути и указать формат. Например: RMAN> RUN { ALLOCATE CHANNEL U01 DEVICE TYPE DISK FORMAT '/u01/%U'; ALLOCATE CHANNEL U02 DEVICE TYPE DISK FORMAT '/u02/%U'; BACKUP DATABASE PLUS ARCHIVELOG; };

142

Можно настроить автоматическое резервирование управляющего файла и файла параметров при каждом резервировании базы данных с помощью RMAN. Дополнительно, если описание структуры базы данных в управляющем файле меняется, и база данных находится в режиме архивирования журналов, то будет выполняться автоматическое резервирование управляющего файла. Автосохранение управляющего файла добавляет дополнительную избыточность в политику резервирования, позволяя восстановить базу данных даже после потери текущего управляющего файла, каталога восстановления и файла параметров. Возможность автосохранения включается и выключается следующим образом: RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP OFF; Настройки RMAN можно вернуть к значениям "по умолчанию" используя ключевое слово CLEAR: RMAN> CONFIGURE DEFAULT DEVICE TYPE CLEAR; RMAN> CONFIGURE RETENTION POLICY CLEAR; RMAN> CONFIGURE CONTROLFILE AUTOBACKUP CLEAR; Если включена оптимизация резервного копирования RMAN, то при выполнении резервирования RMAN будет пропускать файлы, если идентичный файл уже был сохранен на устройстве того же типа. Чтобы проверить, что файл является идентичным, RMAN использует следующий критерий: Файл данных (Datafile) --Файл данных должен иметь те же идентификатор базы данных DBID, номер системного изменения в контрольной точке SCN, номер системного изменения при создании SCN, номер системного изменения при сбросе журнала RESETLOGS SCN и время файла, как и файл в резервной копии. Файл данных должен быть в состоянии offline-normal, read-only или нормально закрыт. Архивный журнал (Archived log) - Журнал должен иметь тот же идентификатор базы данных DBID, номер последовательности, номер системного изменения при сбросе журнала RESETLOGS SCN и время. Резервный набор (Backup set) - Резервный набор должен иметь те же идентификатор базы данных DBID, идентификатор записи резервного набора ID и отметку. Даже если RMAN определит, что резервируемый файл идентичен файлу, обработанному ранее, политика удержания и возможность дуплексирования могут потребовать выполнения резервирования файла. Если параметр TO DESTINATION используется совместно с BACKUP RECOVERY AREA или BACKUP RECOVERY FILES, то RMAN будет анализировать наличие идентичных резервных копий только в указанных местах. Включение оптимизации делается следующей командой: RMAN> CONFIGURE BACKUP OPTIMIZATION ON; Как только для целевой базы данных включена оптимизация резервирования, то, если ни один из сохраняемых файлов не был изменен со времени последнего резервирования, RMAN не выполнит резервирование повторно. Если каждый файл базы в данной операции резервирования 143

пропускается из-за совпадения с ранее сохраненным, ошибок не возникает. Оптимизация резервирования будет игнорироваться при задании ключевого слова FORCE в команде BACKUP: RMAN> BACKUP DATABASE FORCE; RMAN> BACKUP ARCHIVELOG ALL FORCE; Создание резервных копий При создании копий образов результатом являются побитные копии каждого файла данных, архивных журналов повторов или контрольного файла. При восстановлении базы данных копии образов могут использоваться в исходном состоянии. Копии создаются командой RMAN BACKUP AS COPY, командой ОС cp/copy или процессом архивирования Oracle. Тип резервирования "по умолчанию" может быть задан в виде "копии образа" (image copies) с помощью команды CONFIGURE DEVICE TYPE: RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; Также можно принудительно изменить тип "по умолчанию", указав оператор AS COPY в команде BACKUP: RMAN> BACKUP AS COPY DEVICE TYPE DISK DATABASE; Другим типом резервных данных является резервный набор. Резервный набор состоит из одного или нескольких файлов данных, управляющего файла, файла параметров сервера и архивированных журнальных файлов. Каждый резервный набор состоит из одного или нескольких бинарных файлов. Каждый бинарный файл называют частью набора. Части набора записываются во внутреннем формате, который понятен только RMAN. Оглавление резервного набора разделено между разными частями набора, если размер части набора ограничен параметром MAXPIECESIZE. Это ключевое слово задается в команде ALLOCATE CHANNEL или CONFIGURE CHANNEL. Как и в случае копий образа, для задания "по умолчанию" типа резервный набор нужно использовать команду CONFIGURE DEVICE TYPE: RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; Поведение "по умолчанию" может быть изменено при использовании ключевого слова AS BACKUPSET. Можно указать как настроенное устройство "по умолчанию", так и указать его явно: RMAN> BACKUP AS BACKUPSET DATABASE; RMAN> BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; Полная резервная копий базы данных содержит управляющий файл и все файлы данных. Эта копия может быть сделана, если база данных смонтирована или открыта. Команда RMAN BACKUP DATABASE служит для создания полной резервной копии: RMAN> BACKUP DATABASE; Добавление конструкции PLUS ARCHIVELOGS приведет к резервированию базы данных, переключению журналов повторов и включению архивированных журналов в резервную копию. При

144

этом гарантируется наличие полного набора архивных журналов на время резервирования, что позволит выполнить восстановление данных после восстановления файлов резервной копии. RMAN> BACKUP DATABASE PLUS ARCHIVELOG; Инкрементальные резервные копии Команда BACKUP INCREMENTAL позволяет RMAN создать инкрементальный резервный набор для базы данных. Инкрементальные резервные наборы захватывают изменения, сделанные после последнего резервирования БД, на уровне блоков данных. Восстановление с инкрементальными наборами проходит быстрее, чем при использовании только архивированных журналов. Существует три типа инкрементального резервирования: Уровень 0 - Это начальная точка для инкрементального резервирования. При этом резервируются все блоку базы данных и содержание резервной копии идентично полной резервной копии. Уровень 1 дифференциальный - Это резервное копирование сохраняет блоки, измененные со времени предшествующего инкрементального резервирования. Это тип уровня 1 "по умолчанию". Уровень 1 кумулятивный - Это резервное копирование сохраняет блоки, измененные со времени последнего резервирования уровня 0. При восстановлении с инкрементальных резервных копий, RMAN использует копию уровня 0 в качестве начальной точки. Потом используются копии уровня 1 для модификации измененных блоков где возможно, чтобы избежать повторного приложения изменений из архивированных журналов. При наличии инкрементальных копий RMAN использует их при восстановлении. В примере показано создание инкрементальной копии 0 уровня, которая будет служить основой для инкрементальной политики резервирования: RMAN> BACKUP INCREMENTAL LEVEL 0 DATABASE; В следующем примере показано создание кумулятивной инкрементальной копии уровня 1: RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; В следующем примере показано создание дифференциальной инкрементальной копии уровня 1: RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE; Отслеживание изменения блоков (Block Change Tracking) Возможность отслеживания изменения блоков улучшает производительность создания инкрементальных копий путем записи информации об измененных блоках для каждого файла данных. Если отслеживание изменения блоков включено, то RMAN использует специальный файл отслеживания изменений с целью пометить измененные блоки во время резервирования. Этот файл позволяет не проводить просмотр всех блоков резервируемом файле. "По умолчанию" отслеживание выключено. Для всей базы данных существует единый единственный файл отслеживания изменений. 145

Если не указано иное, файл отслеживания изменений создается в пути, определяемом параметром инициализации DB_CREATE_FILE_DEST. Он используется только при выполнении инкрементального резервирования с уровнем больше 0, поскольку уровень 0 включает все блоки. Как только файл отслеживания был создан, и инкрементальное резервирование уровня 0 выполнено, то следующее инкрементальное резервирование может использовать данные отслеживания изменений. Для включения отслеживания нужно выполнить следующую команду: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; При необходимости можно указать расположение файла отслеживания: SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/rman_change_track.f' REUSE; Выключить отслеживание изменений можно с помощью команды: SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; Восстановление файлов базы данных В документации Oracle используются два разных термина "restore" и "recover". И тот, и другой переводят русским словом "восстановление". С точки зрения семантики процесса слово "restore" лучше перевести как "восстановлений файла", а слово "recover" как "восстановление данных в файле". Восстановление файлов базы данных является весьма объемной темой, а сценарий восстановления зависит от многих факторов. Однако на экзамене не будет рассматриваться скольнибудь сложные случаи восстановления. В реальной жизни лучше придерживаться простого правила "Чем проще, тем лучше", не превращая, в общем-то тривиальную операцию, в разновидность искусства. В данном разделе сделаны следующие допущения: Несколько файлов данных были потеряны, но база данных сохранила все текущие управляющие файлы или весь набор групп текущих журналов повторов. База данных использует текущий бинарный файл параметров. Доступен полный набор архивированных журналов повторов и инкрементальных резервных копий, необходимый для восстановления данных в файлах. Каждый файл данных имеет либо резервную копию, либо полный набор текущих и архивных журналов повторов от момента времени создания файлов без резервной копии. В резервной копии нет шифрованных файлов. База данных не является кластерной. База данных использует в работе область быстрого восстановления. Для восстановления файлов и восстановления данных в файлах все базы данных нужно: Запустить RMAN и установить сессию с базой данных: $ rman RMAN> CONNECT TARGET / 146

Если база не смонтирована, то смонтировать ее: RMAN> STARTUP MOUNT; Проверить настроенные каналы с помощью команды SHOW: RMAN> SHOW ALL; Если нужные каналы не настроены, то нужно будет настроить каналы с помощью команды CONFIGURE или включить команды ALLOCATE CHANNEL внутри RUN-блока Восстановить файлы базы данных и данные в файлах: RMAN> RESTORE DATABASE; Starting restore at 20-DEC-14 ... Finished restore at 20-DEC-14

RMAN> RECOVER DATABASE; ... media recovery complete, elapsed time: 00:00:21 Finished recover at 20-DEC-14

Проверить успешность выполнения операций восстановления. Если все прошло нормально, нужно открыть базы данных: RMAN> ALTER DATABASE OPEN;

147

Диагностирование сетевых проблем и проблем базы данных. Первым шагом любой диагностики является сбор информации, что, собственно говоря, работает не так. Каждый серверный и фоновый процесс экземпляра может писать в собственный файл трассировки. При обнаружении внутренней ошибки процесс записывает информацию о ней в свой трассировочный файл. Часть этой информации предназначена для администратора, часть для службы поддержки Oracle. Все базы данных Oracle ведут файл оповещений (alert.log). Имя файла определено как alert_.log, и "по умолчанию" он расположен в директории $ORACLE_BASE/diag/rdbms///trace. Журнал оповещений представляет собой хронологическую последовательность сообщений и ошибок, создаваемую базой данных. Этот файл включает следующие записи Все внутренние ошибки (ORA-00600), все ошибки, вызванные повреждением блоков данных (ORA-01578), все ошибки взаимных блокировок (deadlock errors) (ORA-00060). Административные операции, такие как CREATE, ALTER, DROP операторы и команды STARTUP, SHUTDOWN, ARCHIVELOG. Сообщения и ошибки, связанные с работой разделяемого сервера и диспетчерского процесса. Ошибки, возникающие при автоматическом обновлении материализованных представлений. Значения параметров инициализации, отличные от значений "по умолчанию". Эта информация заносится в журнал оповещений вместо вывода на консоль, хотя некоторые из сообщений могут быть выведены и туда. Как только любая из отслеживаемых операций завершилась успешно, сообщение и временная отметка записываются в журнал оповещений. Обслуживаются две версии журнала оповещений: форматированный в виде XML и простой текстовый файлы. Любой из них можно просмотреть текстовым редактором. Для просмотра XMLформатированного файла можно использовать утилиту adrci. Администратор должен периодически проверять содержимое журнала оповещения и трассировочных файлов на предмет поиска ошибок, требующих вмешательства. Фоновые процессы всегда пишут в соответствующие трассировочные файлы. Для фонового процесса ARCn (процесс архивирования журналов) можно управлять количеством и типами трассировочной информации, которая будет записываться, с помощью параметра инициализации log_archive_trace. Другие фоновые процессы такой возможности не имеют. Серверный процесс записывает трассировочный файл при возникновении ошибки. Начиная с версии 11g все диагностические сообщения, трассировочные файлы, дампы, журнал оповещений, отчеты монитора состояний и т.д., хранятся в структуре директорий, известной как репозиторий автоматической диагностики (Automatic Diagnostic Repository, ADR). Структура ADR поддерживает несколько экземпляров и несколько продуктов Oracle одновременно. Каждый экземпляр каждого продукта хранит диагностические данные в своей собственной домашней директорией внутри ADR. Репозиторий ADR обеспечивает единую структуру каталогов с едиными форматами диагностических данных для всех продуктов и экземпляров. Это, плюс единый набор инструментов, позволяет диагностическим данным быть скоррелированными и дает возможность анализа для нескольких продуктов. 148

Параметр инициализации DIAGNOSTIC_DEST задает директорию, служащую корневой для структуры ADR. Для выяснения директории, содержащей трассировочный файл можно запросить представление V$DIAG_INFO: SQL> SELECT name, value FROM v$diag_info WHERE name LIKE 'Diag%'; NAME VALUE ------- ---------------------------------------------------------------Diag Enabled TRUE Diag Trace /u01/app/oracle/diag/rdbms/x/X/trace Diag Alert /u01/app/oracle/diag/rdbms/x/X/alert Diag Incident /u01/app/oracle/diag/rdbms/x/X/incident Diag Cdump /u01/app/oracle/diag/rdbms/x/X/cdump

В V$DIAG_INFO содержится информация о ADR Base – путь к корню ADR. ADR Home – путь к дому ADR для текущего экземпляра. Diag Trace – место положение трассировочных файлов фоновых процессов, трассировочных файлов серверных процессов, файлов трассировки SQL и текстовой версии журнала оповещений alert log. Diag Alert – местоположение XML-версии файла оповещений alert log. Default Trace – путь к файлу трассировки текущей сессии. Diag Incident – путь к файлу пакета для инцидента. Diag Cdump – Аналогично cdump. Местоположение для дампов ядра. Health Monitor – Местоположение отчетов монитора состояния. Инфраструктура управления сбоями основана на проблемах и инцидентах. Проблема определена как критическая ошибка базы данных. Критические ошибки заявлены как внутренние ошибки экземпляра, такие как ORA-00600, ORA-07445 или ORA-04031. Проблемы отслеживаются в ADR по ключу проблемы, который является текстовой строкой с ее описанием. Инцидент определен как единичный случай проблемы. Если проблема встречается несколько раз, для каждого случая создается отдельный инцидент. БД Oracle отмечает инцидент по временной отметке и отслеживает их в ADR. Инциденты идентифицируются по числовым номерам, уникальным в рамках ADR. При каждом инциденте производятся следующие действия: Заносится запись в журнал оповещений. Оповещение об инциденте посылается в Oracle Enterprise Manager. Диагностические данные об инциденте сохраняются в виде дампов памяти. При необходимости, в ADR создается новая поддиректория, куда записывается один или несколько дампов памяти, созданных при инциденте.

149

Обнаружение и восстановление сбоев данных с помощью Data Recovery Advisor Инструментарий Data Recovery Advisor является средством восстановления поврежденных данных. Этот инструмент тесно взаимодействует с Support Workbench, системой контроля функционирования базы данных и утилитой RMAN. Он может отобразить проблемы повреждения данных, оценить их размер и влияние, предложить опции восстановления и автоматизировать процесс восстановления. В контексте Data Recovery Advisor проверка функционирования является диагностической процедурой, запускаемой монитором функционирования с целью оценки состояния базы данных и/или ее компонентов. Процедура проверки работоспособности вызывается при возникновении ошибок, либо может быть инициирована вручную. Data Recovery Advisor может диагностировать следующие сбои: Наличие компонентов, таких как файлы данных и управляющие файлы, недоступных базе данных. Физическое повреждение блоков, как то сбои контрольных сумм блоков и неверные значения в полях заголовков блоков. Нарушения целостности, такие как возраст файла данных больше, чем базы данных. Ошибки ввода/вывода, такие как ошибки оборудования, драйверов операционной системы и превышение ограничений операционной системы. В некоторых случаях Data Recovery Advisor может обнаружить и обработать логические повреждения данных. В общем, однако, обнаружение и устранение логических повреждений данных потребует помощи со стороны Oracle Support Services. Сбои Сбой это постоянное повреждение данных, обнаруженное при контроле работоспособности. Сбои обычно обнаруживаются, когда база данных встречает поврежденные данные (блоки), и возникает ошибка. При этом автоматически вызывается процедура проверки работоспособности. Эта процедура произведет поиск сбоев, связанных с возникшей ошибкой и занесет все найденное в ADR. Data Recovery Advisor может создать рекомендации по устранению сбоев только после того, как обнаруженные сбои будут занесены в ADR. Data Recovery Advisor может сообщить о сбоях и исправить сбои, вызванные недоступностью файлов, физическим или логическим повреждением блоков и ошибками ввода/вывода. Всем сбоям присваивается приоритет: критический CRITICAL, высокий HIGH или низкий LOW, а также статус открытый OPEN или закрытый CLOSED. CRITICAL - сбои критического уровня. Требуют немедленного внимания, так как они могут привести к недоступности база данных. Обычно, критические сбои приводят к остановке экземпляра и диагностируются при последующем старте. HIGH - сбои высокого уровня. Делают базу данных частично недоступной или невосстановимой, и обычно должны быть устранены в максимально короткое время. LOW - сбои низкого уровня. Могут быть проигнорированы до устранения всех проблем с более высоким приоритетом.

150

Восстановление с помощью Data Recovery Advisor Советник Data Recovery Advisor позволяет выбрать опции восстановления работоспособности. Восстановление может включать в себя восстановление блоков, восстановление файлов данных и данных в файле, или использование технологии ретроспективного отката Oracle Flashback Database. Data Recovery Advisor предлагает автоматический или ручной режим восстановления. Администратор может выбрать автоматический режим для восстановления работоспособности базы данных, если его устраивает предлагаемая схема восстановления. В автоматическом режиме Data Recovery Advisor выполняет восстановление, проверяет успешность проведенной процедуры и закрывает соответствующие записи о сбоях. Для устранения сбоев при помощи RMAN рекомендуется следующая последовательность действий в сессии: LIST FAILURE для отображения списка сбоев, ADVISE FAILURE для отображения опций восстановления и REPAIR FAILURE для исправления сбоев. LIST FAILURE Команда LIST FAILURE выводит список сбоев, для которых можно выполнить команды ADVISE FAILURE и REPAIR FAILURE. RMAN> LIST FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary ––––– –––– –––- ––––––- –––- ––––– –––– –––- ––––––- –––674 HIGH OPEN 23-DEC-14 One or more non-system datafiles are missing 721 HIGH OPEN 23-DEC-14 Datafile 1: '/u01/oradata/X/system01.dbf' contains one or more corrupt blocks

ADVISE FAILURE Команда ADVISE FAILURE отображает возможные методы восстановления после указанного сбоя. Команда выдает краткую сводку сбоев, идентифицированных Data Recovery Advisor, и закрывает все открытые сбои после их исправления. Команда ADVISE FAILURE также указывает, какую стратегию восстановления Data Recovery Advisor считает оптимальной для данного набора сбоев. Советник Data Recovery Advisor проверяет применимость процедуры восстановления перед тем, как предложить ее. Например, он проверит все ли резервные копии и архивные журналы повторов, нужные для восстановления, доступны. Data Recovery Advisor может создать как автоматический, так и ручной сценарий восстановления. Команда ADVISE FAILURE сопоставляет набор сбоев и набор шагов восстановления, оптимальный с точки зрения Data Recovery Advisor. При возможности Data Recovery Advisor объединяет несколько шагов восстановления в один. Например, при повреждении файла данных, отсутствующем управляющем файле и потерянном текущем файле журнальной группы, Data Recovery Advisor порекомендует единый консолидированный план восстановления работоспособности базы данных и выполнения проведения восстановления данных на момент времени (PITR - point-in-time recovery) RMAN> ADVISE FAILURE; 151

List of Database Failures ========================= Failure ID Priority Status Time Detected Summary ––––– –––– –––- ––––––- –––- ––––– –––– –––- ––––––- –––274 HIGH OPEN 23-DEC-14 One or more non-system datafiles are missing 329 HIGH OPEN 21-DEC-14 Datafile 1: '/u01/oradata/X/system01.dbf' contains one or more corrupt blocks analyzing automatic repair options; this may take some time using channel ORA_DISK_1 analyzing automatic repair options complete Mandatory Manual Actions ======================== no manual actions available Optional Manual Actions ======================= 1. If file /u01/oradata/X/data01.dbf was unintentionally renamed or moved, restore it Automated Repair Options ======================== Option Repair Description ––– ––––––––– Restore and recover datafile 41; Perform block media recovery of block 73781 in file 1 Strategy: The repair includes complete media recovery with no data loss Repair script: /u01/oracle/log/diag/rdbms/x/X/hm/reco_740113234.hm

CHANGE FAILURE Команда CHANGE FAILURE изменяет приоритет сбоя с высокого на низкий или наоборот, а также позволяет закрыть сбой. Изменить критический приоритет невозможно. RMAN> CHANGE FAILURE 6 PRIORITY LOW; REPAIR FAILURE Команда REPAIR FAILURE используется для восстановления после сбоев, идентифицированных Data Recovery Advisor. Целевой экземпляр базы данных должен быть запущен, он должен быть монолитным и не может быть экземпляром standby. Важно отметить, что в большинстве случаев должна быть активной только одна сессия RMAN, выполняющая команду REPAIR FAILURE. Единственным исключением из правила является команда REPAIR FAILURE PREVIEW, выполнение которой допускается из конкурирующих сессий. Для выполнения автоматического восстановления Data Recovery Advisor'у могут потребоваться определенные резервные копии и архивные журналы повторов. Если эти файлы недоступны, то восстановление невозможно. Если возможно, то Data Recovery Advisor соединит несколько операций восстановления в одну. Если в данной сессии не выдавалась команда ADVISE FAILURE, то команда REPAIR FAILURE приводит к неявной выдаче команды ADVISE FAILURE. Менеджер RMAN всегда проверяет, что сбои еще являются актуальными, и автоматически закрывает исправленные. После выполнения восстановления после сбоя RMAN заново проверяет все открытые сбои с целью проверки на возможное их исправление после проведенных действий.

152

Реализация технологии ретроспективного отката Ретроспективный откат таблиц "По умолчанию" при удалении таблицы база данных не освобождает занимаемое ею место. Вместо этого, база данных переименовывает таблицу и помещает ее и все связанные с ней объекты в корзину удаленных. Если выяснится, что удаление таблицы было ошибкой, то ее можно восстановить. Для восстановления используется оператор FALSHBACK TABLE. Корзина удаленных это таблица словаря данных, содержащая информацию, которая требуется для восстановления удаленных объектов. Сами по себе удаленные объекты остаются там, где они были перед удалением, занимая то же самое пространство. Удаленные объекты по-прежнему учитываются в квотах пользователя до явного их удаления из корзины, или они явно удалены базой данных из-за пространственных ограничений. Если корзина выключена, то удаляемые таблицы и связанные с ними объекты не помещаются в нее, они просто удаляются. Восстановление их в этом случае возможно с помощью других средств, например, из резервных копий. "По умолчанию" корзина включена. При удалении пользователя все связанные с ним объекты, помещенные в корзину, удаляются. При удалении табличного пространства вместе с содержимым в корзину ничего не помещается. Дисковая память доступная базе данных, где размещались объекты, больше не существует. База данных удаляет все записи в корзине, ссылающиеся на объекты из удаляемого табличного пространства. Оператор FLASHBACK TABLE TO BEFORE DROP используется при восстановлении объектов из корзины. При восстановлении нужно использовать либо имя таблицы, назначенное системой при помещении в корзину, либо исходное имя. Дополнительный параметр RENAME TO позволяет переименовать таблицы во время восстановления. Представление USER_RECYCLEBIN позволит определить назначенное системой имя. Для выполнения оператора FLASHBACK TABLE TO BEFORE DROP необходимы такие же привилегии, как и для удаления таблицы. В примере приводится команда для восстановления таблицы ocp_new и присвоения ей нового имени: SQL> FLASHBACK TABLE ocp_new TO BEFORE DROP RENAME TO ocp_2; Ретроспективные версионные запросы Ретроспективные версионные запросы используются для извлечения метаданных и исторических данных для определенного момента в прошлом. Временной интервал может быть задан двумя временными отметками или двумя номерами системных изменений SCN. Полученные метаданные включают начальное и конечное время существующих версий, тип операции DML, использованный при создании, и идентификатор транзакции, которая создавала версии записей. Для выполнения ретроспективного версионного запроса нужно использовать параметр VERSIONS BETWEEN оператора SELECT. Синтаксис параметра VERSIONS BETWEEN определен следующим образом: VERSIONS {BETWEEN {SCN | TIMESTAMP} начало AND конец}. В результате ретроспективного запроса возвращаются следующие псевдостолбцы:

153

VERSIONS_START[SCN/TIME] - начальное значение номера системного изменения (SCN) или время в формате TIMESTAMP, когда активна версия строки. NULL , если версия более ранняя, чем стартовое значение. VERSIONS_END[SCN/TIME] - SCN или время в формате TIMESTAMP, когда версия строки устарела. Если NULL, то либо версия строки является текущей во время запроса, или строка отмечена для операции DELETE. VERSIONS_XID - Идентификатор транзакции, создавший версию строки. VERSIONS_OPERATION - Операция, проводимая транзакцией: I (вставка), D (удаление), U (изменение). Версия соответствует транзакции, которая производила вставку, удаление или изменение. Данная версия строки является достоверной с момента, включая VERSIONS_START*, но не включая VERSIONS_END*. Иначе говоря, она достоверна для любого времени "t", которое удовлетворяет условию VERSIONS_START* UPDATE employees SET salary = 97000 WHERE emp_last='Dow'; SQL> UPDATE employees SET salary = 102000 WHERE emp_last='Dow'; SQL> UPDATE employees SET salary = 105000 WHERE emp_last='Dow'; SQL> COMMIT; При выполнении ретроспективного версионного запроса можно получить следующие записи: SQL> SELECT versions_starttime, versions_endtime,versions_xid, versions_operation AS OP,salary FROM employees VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('23-DEC-2014 11:46','DD-MON-YY 24HH:MI') AND TO_TIMESTAMP('23-DEC-2014 11:56','DD-MON-YY 24HH:MI') WHERE emp_last = 'Dow'; VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID OP SALARY -------------------- --------------------- ---------------23-DEC-2014 11.51 09000900A9010000 23-DEC-2014 11.49 22-DEC-2014 11.51 04001A003F010000 23-DEC-2014 11.49 22-DEC-2014 11.49 03002100A2010000 23-DEC-2014 11.49

- -----U 105000 U 102000 U 97000 93500

Как видно, в таблице были произведены три изменения, каждое из которых увеличивало значение поля salary. Видно, когда действовало каждое значение поля. Значение поля VERSIONS_XID при использовании технологии запросов ретроспективных транзакций Oracle для нахождения метаданных для любой из этих трех транзакций. Эта информация будет включать в себя SQL оператор для отката изменения строки и имя пользователя, выполнившего изменения.

154

Запросы ретроспективных транзакций Запросы ретроспективных транзакций используются для получения метаданных и исторических данных для одной или всех транзакций в данном интервале. Эти данные извлекаются из статического представления словаря данных FLASHBACK_TRANSACTION_QUERY. Запрос ретроспективных транзакций заполняет столбец UNDO_SQL. Код SQL, содержащийся в этом столбце, является противоположным той операции DML, которую выполняла соответствующая транзакция. Этот код обычно может обратить исходную транзакцию с известными ограничениями, т.е. оператор INSERT из SQL_UNDO вряд ли сможет вставить обратно строку с тем же ROWID, с которым она была удалена. В общем, как правило, технологии ретроспективного версионного запроса и запроса ретроспективных транзакций используются совместно для получения идентификатора транзакций ID. SQL> SELECT operation, start_scn, commit_scn, logon_user FROM flashback_transaction_query WHERE xid = HEXTORAW('09000900C9140000'); OPERATION -----------UNKNOWN BEGIN

START_SCN COMMIT_SCN LOGON_USER --------- ---------- ------------ -----------593374 594863 OCP 593374 594863 OCP

В следующем запросе используется ретроспективный версионный запрос в качестве подзапроса, что дает возможность соотнести каждую версию строки с именем пользователя, ответственного за изменения: SQL> SELECT xid, logon_user FROM flashback_transaction_query WHERE xid IN ( SELECT versions_xid FROM employees VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('22-FEB-2014 11:40:00', 'DD-MON-YYYY HH:MI:SS') AND TO_TIMESTAMP('22-FEB-2014 11:56:00', 'DD-MON-YYYY HH:MI:SS') ); При необходимости можно с помощью процедуры DBMS_FLASHBACK.TRANSACTION_BACKOUT откатить транзакцию и все зависимые транзакции в то время, когда база данных открыта. Откат транзакций использует данные пространства отката UNDO для создания и выполнения компенсирующих операций, чтобы вернуть измененные данные в исходное состояние. DBMS_FLASHBACK.TRANSACTION_BACKOUT не выдает COMMIT на DML операции, выполняемые в при откате транзакций. При этом процедура устанавливает блокировки на строки и таблицы, чтобы избежать других зависимых изменений в системе. Для полного отката нежелательных изменений и постоянного возврата к исходным данным необходимо явно зафиксировать транзакции.

155

Для того, чтобы использовать технологию запросов к ретроспективным транзакциям необходимо функционирование базы данных в режиме архивирования журналов. Также необходимо включить дополнительное журналирование. SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Для выполнения ретроспективных запросов необходимо наличие необходимых привилегий. Достаточно привилегий следующих типов: полномочия FLASHBACK и SELECT на требуемые объекты полномочия SELECT на все таблицы и привилегию FLASHBACK ANY TABLE. Для выполнения запросов ретроспективных транзакций администратор должен выдать привилегию SELECT ANY TRANSACTION. Для выполнения SQL-кода отката изменений, полученного при помощи Oracle Flashback Transaction, администратор должен выдать привилегии SELECT, UPDATE, DELETE и INSERT на вовлеченные таблицы. Также нужно выдать привилегию EXECUTE на пакет DBMS_FLASHBACK. Ретроспективный откат базы данных Возможность ретроспективного отката базы данных позволяет вернуть базу данных к более раннему моменту времени с целью исправления проблем, вызванных логическим повреждением данных или ошибками пользователей внутри ранее определенного временного окна. Ретроспективный откат является существенно более эффективным нежели восстановление базы данных на момент времени, т.к. не требует проведений операций резервирования и восстановления. Ретроспективный откат базы данных возможен с помощью команды RMAN FLASHBACK DATABASE или SQL оператора FLASHBACK DATABASE. База данных должна быть заранее настроена для использования этой полезной функциональности. Для того, чтобы воспользоваться возможностями ретроспективного отката базы данных, необходимо установить требуемое время удержания (flashback retention target) и настроить область быстрого восстановления (Fast Recovery Area). Время удержания указывает, как далеко в прошлое можно "отмотать" базу данных. Ретроспективный механизм базы данных ведет собственные ретроспективные журналы и хранит их в области быстрого восстановления. После настройки база данных регулярно копирует образы измененных блоков данных каждого файла данных в ретроспективные журналы. Эти блоки в дальнейшем могут быть использованы для реконструкции содержимого файлов данных для любого момента времени, для которого существует журнал. В дополнение к ретроспективным журналам журналы повторов redo на диске или ленте должны быть доступны для всего периода времени, охватываемому ретроспективными журналами. Диапазон SCN, для которого достаточно ретроспективных журналов для выполнения команды FLASHBACK DATABASE, называется окном ретроспективного отката. Если область Fast Recovery Area не имеет достаточного пространства для файлов восстановления, таких как архивированные журналы повторов и другие резервные копии, нужные в рамках политики удержания, база данных может удалить ретроспективные журналы с наиболее ранними SCN. Требуемое время удержания не гарантирует, что возможность ретроспективного

156

отката базы данных будет доступна для всего периода. В этом случае может потребоваться большая область быстрого восстановления. Ретроспективный откат базы данных имеет ряд ограничений: С помощью технологии Flashback Database можно откатить изменения, внесенные самой базой данных. Технология не может исправить ошибки, связанные со сбоем оборудования или удалением файлов. С помощью Flashback Database невозможно отменить операции сжатия файлов данных. Если управляющий файл восстановлен из резервной копии или пересоздан, то все накопленные ретроспективные журналы становятся неактуальными. Если при выполнении целевое время операции Flashback Database приходится на действия с опцией NOLOGGING, то велика вероятность повреждения блоков объектов и файлов данных, вовлеченных в операции NOLOGGING. Нормальная точка восстановления это просто именованный явно SCN или момент времени. Она фактически является алиасом для данного SCN. Если используется ретроспективный откат или восстановление на момент времени, то можно использовать имя точки восстановления вместо времени или SCN. Нормальные точки восстановления в итоге перестают быть актуальными для контрольного файла, если их не удалили вручную, поэтому они не требуют текущего обслуживания. Следующие команды поддерживаю работу с точками восстановления: RECOVER DATABASE и FLASHBACK DATABASE из RMAN. FLASHBACK TABLE оператор в SQL Гарантированная точка восстановления также является алиасом для SCN в операциях восстановления. Однако гарантированные точки восстановления никогда не состариваются в контрольном файле и должны быть явно удалены. Это гарантирует, что можно "перемотать" базу данных к точке восстановления, даже если создание ретроспективных журналов не включено. Если же оно включено, то гарантированная точка восстановления заставляет удерживать все ретроспективные журналы, нужные для перемотки базы данных к гарантированному системному изменению SCN. Чтобы включить возможность выполнения ретроспективного отката базы данных Flashback Database, нужно, во-первых, проверить, что экземпляр открыт или смонтирован. Если экземпляр смонтирован, то база данных должна быть в консистентном состоянии (остановлена командой shutdown или shutdown immediate), если экземпляр не является физической standby базой. Последовательность включения состоит из следующих шагов: 1. Нужно установить параметр DB_FLASHBACK_RETENTION_TARGET равным желаемой величине окна ретроспективного отката в минутах. "По умолчанию" это 1 день (1440 минут). Необязательное действие. 2. Следует включить возможность ретроспективного отката для всего экземпляра SQL> ALTER DATABASE FLASHBACK ON;

157

3. При необходимости нужно отключить создание ретроспективных журналов для некоторых табличных пространств. Для отключения журналов ретроспективного отката нужно выполнить следующую команду, экземпляр должен быть либо смонтирован, либо открыт: SQL> ALTER DATABASE FLASHBACK OFF; Обслуживание журналов ретроспективного отката не предполагает значительной дополнительной нагрузки на экземпляр. Измененные блоки записываются в эти журналы относительно редко, через регулярные интервалы, чтобы ограничить дополнительную нагрузку на обработку и ввод/вывод. Оптимизация производительности состоит в основном получении максимально быстрой записи блоков. Для желаемого результата желательно следовать следующим правилам: Для области быстрого восстановления (fast recovery area) нужно использовать быструю файловую систему, предпочтительно без кэширования средствами ОС Лучше настроить максимально возможное количество дисков для обслуживания области быстрого восстановления. Если дисковая подсистема, используемая для размещения области быстрого восстановления, не имеет энергонезависимой памяти, то следует создать файловую систему поверх "полосатого" тома с размером полосы 128KB. Для больших баз данных следует установить параметр LOG_BUFFER по крайней мере в 8MB. Для выполнения ретроспективного отката базы данных нужно выполнить следующие базовые шаги: 1. Запустить RMAN и установить сессию с базой данных, которую нужно перемотать назад. 2. Поместить базу данных в режим MOUNT. SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; 3. Выполнить команду FLASHBACK DATABASE. SQL> FLASHBACK DATABASE TO SCN 12345678; 4. Открыть экземпляр в режиме "только чтение" в SQL-Plus и выполнить тестовые запросы, с целью проверки содержания базы данных. SQL> ALTER DATABASE OPEN READ ONLY; 5. Если данные удовлетворяют требованиям, то нужно остановить базу данных и открыть ее с опцией RESETLOGS: SQL> SHUTDOWN IMMEDIATE; SQL> STARTUP MOUNT; SQL> ALTER DATABASE OPEN RESETLOGS; 158

Загрузка и выгрузка данных Утилита Data Pump разработана для быстрого переноса данных и метаданных из одной базы данных в другую. Она заменяет функциональность утилит export/import, существовавших ранних версиях Oracle. Data Pump состоит из трех различных частей: expdp и impdp - Это клиенты командной строки, использующие процедуры из пакета DBMS_DATAPUMP для выполнения экспорта или импорта. Эти утилиты получают параметры командной строки для экспорта/импорта данных и метаданных для всей базы данных или ее части. DBMS_DATAPUMP - Пакет, также известный как Data Pump API, обеспечивает высокоскоростной механизм для перемещения всех или части данных и метаданных от одной база данных к другой. DBMS_DATAPUMP может использоваться независимо от клиентов impdp и expdp. DBMS_METADATA - Пакет, также известный как Metadata API, обеспечивает централизованную возможность для извлечения, манипуляции и пересоздания метаданных словаря. DBMS_METADATA DATAPUMP может использоваться независимо от клиентов impdp и expdp. Задания Data Pump используют мастер-таблицу, мастер-процесс и рабочие процессы для выполнения работы и отслеживания хода работы: Мастер-таблица - Мастер-таблицы используется для отслеживания хода работы при передаче данных и метаданных. Она реализована в виде пользовательской таблицы в базе данных. Пользователь, выполняющий impdp или expdp, должен иметь привилегию CREATE TABLE для создания мастер-таблицы и достаточную квоту в своем табличном пространстве. Имя мастер-таблицы совпадает с именем задания, ее создавшего. Задание Data Pump не может иметь имя, совпадающее с именами существующих таблиц или представлений в схеме. Информация из мастер-таблицы используется для перезапуска задания. Мастер-процесс - мастер-процесс создается для каждого задания экспорта или импорта. Он управляет всей операцией экспорта/импорта, включая взаимодействие с клиентами, создание и управление пулом рабочих процессов, ведением журнала операций. Рабочий процесс - Мастер-процесс размещает работы, которые нужно выполнить между рабочими процессами, выполняющими обработку данных и метаданных в ходе операций. Data Pump может обеспечить работой несколько рабочих процессов, выполняющихся параллельно для увеличения производительности. Обслуживание заданий Data Pump С помощью утилит Data Pump Export или Import можно подключиться к выполняющему заданию. При подключении в журнальном режиме состояние задания автоматически отображается в ходе выполнения в реальном времени. При подключении в интерактивно-командном режиме можно запросить состояние задания. Дополнительно нужно упомянуть, что журнальный файл может быть записан во время выполнения задания. В нем суммируются процесс выполнения задания, перечисляются все ошибки и 159

записывается итоговый результат задания. Состояние задания или информацию о заданиях можно получить из представлений словаря данных: DBA_DATAPUMP_JOBS - Содержит список всех активных заданий Data Pump в базе данных, независимо от их состояния во всех экземплярах. В представлении также имеется информация от всех мастер-таблицах, не связанных с активными заданиями. DBA_DATAPUMP_SESSIONS - Содержит список сессий, которое подключены к заданиям Data Pump. Информация в этом представлении полезна для выяснения, почему остановившееся задание не завершилось. V$SESSION_LONGOPS - Операции Data Pump, которые переносят табличные данные, обслуживают запись, указывающую степень завершенности операции. Эта запись содержит оценку размера перемещенных данных и периодически модифицируется для отображения действительного объема обработанных данных. К параметрам заданий Data Pump относятся следующие столбцы V$SESSION_LONGOPS: USERNAME - владелец задания. OPNAME - имя заданий. TARGET_DESC - выполняемая операция. SOFAR - обработанный объем данных. TOTALWORK - оценочный объем данных. UNITS - мегабайт (MB). MESSAGE - форматированное сообщение о состоянии задания в виде 'job_name: operation_name : nnn out of mmm MB done'. Утилита экспорта Data Pump вызывается командой expdp. Действия, выполняемые утилитой, определяются заданными параметрами. Эти параметры могут быть заданы либо в командной строке, либо в файле параметров. Экспорт Data Pump может управляться с помощью командной строки, файла параметров или интерактивно-командного режима. Командная строка - Позволяет указать большинство параметров экспорта в командной строке. Файл параметров - Позволяет указать большинство параметров экспорта в виде файла. Параметр PARFILE не может быть использован в самом файле параметров, т.е. файл параметров не может быть вложенным. Интерактивно-командный режим - Отображает приглашение командной строки экспорт, позволяющее вводить разные команды. Некоторые команды являются специфичными для интерактивно-командного режима. Задания Data Pump работают со следующими типами файлов: Файлы дампов (Dump Files) - содержат перемещаемые данные и метаданные. Файлы журналов (Log Files) - Содержат сообщения о совершаемых действиях. SQL файлы (SQL Files) - Содержат записи операции SQLFILE.

160

Файлы данных (Data Files) -файлы, указанные в параметре DATA_FILES, при выполнении переносимого импорта. Существует несколько режимов экспорта для выгрузки разных частей базы данных. Режим указывается при помощи параметра. Доступны следующие режимы: Полный (Full) - При полном экспорте выгружается вся база данных. Для выполнения такого экспорта требуется роль DATAPUMP_EXP_FULL_DATABASE. Включается при указании параметра FULL. Схема (Schema) -Режим экспорта "по умолчанию". Если выполняющему экспорт пользователю выдана роль DATAPUMP_EXP_FULL_DATABASE, то возможно задать список схем для экспорта. В противном случае можно экспортировать только собственную схему. Включается при указании параметра SCHEMAS. Таблица (Table) - В этом режиме экспортируется только указанный набор таблиц, секций и зависимых от них объектов. Для экспорта таблиц из чужих схем обязательно наличие роли DATAPUMP_EXP_FULL_DATABASE. Включается при задании параметра TABLES. Табличное пространство (Tablespace) - В этом режиме экспортируются только таблицы и зависимые от них объекты, содержащиеся в указанном наборе табличных пространств. Привилегированные пользователи могут выгрузить все таблицы. Непривилегированные пользователи выгружают только таблицы из собственных схем. Включается при задании параметра TABLESPACES. Переносимое табличное пространство (Transportable Tablespace) - В этом режиме экспортируются только метаданные для таблиц и зависимых объектов, находящихся в указанном наборе табличных пространств. Файлы данных копируются в рамках отдельной операции. Включается при задании параметра TRANSPORT_TABLESPACES. Параметры expdp Для управления экспортом используются следующие параметры: ATTACH – Выполняет подключение клиентской сессии к существующему заданию экспорта и автоматически запускает интерактивно-командный интерфейс. CONTENT – Позволяет управлять типом экспортных данных: выгружать данные, метаданные или и то, и другое. DIRECTORY – Задает место в файловой системе, куда будут записываться файлы дампов и журналы. DUMPFILE – Задает имя и, при необходимости, объекты директорий для файлов дампа. ESTIMATE – Задает метод, которые будет использоваться при экспорте для оценки размеров дискового пространства, которое понадобится заданию экспорта (в байтах). ESTIMATE_ONLY – Указывает, что необходимо произвести только оценку потребности в дисковом пространстве без выполнения реального экспорта. EXCLUDE – Позволяет отфильтровать метаданные, которые будут исключены из экспорта, включая объекты или типы объектов. FILESIZE – Задает максимальный размер каждого файла дампа. FULL – Задает режим полного экспорта. 161

INCLUDE – Позволяет отфильтровать метаданные, которые будут включены в экспорт, включая объекты или типы объектов для выбранного типа экспорта. JOB_NAME – Имя задания экспорта, используется для последующей идентификации. LOGFILE – Задает имя и, при необходимости, директорию журнала задания экспорта. PARFILE – задает имя файла параметров экспорта. QUERY – Позволяет указать SQL-запрос, используемый для фильтрации данных для экспорта. SCHEMAS – Указывает список схем для экспорта в режиме "схема". TABLES – Указывает список таблиц для экспорта в режиме "таблицы". TABLESPACES – Указывает список табличных пространств для экспорта в режиме "табличное пространство". TRANSPORT_TABLESPACES - Указывает, что предполагается провести экспорт в режиме "переносимые табличные пространства". В параметре приводится список имен табличных пространств, для которые будет произведен экспорт метаданных из исходной базы данных в целевую. Параметры impdp Многие из приведенных выше параметров утилиты expdp применимы и для impdp. Дополнительно, для impdp существуют следующие параметры: REUSE_DATAFILES – Указывает, будет ли задание импорта повторно использовать уже существующие файлы при создании табличных пространств. SQLFILE – Указывает имя файла, в который будут записаны все SQL DDL команды, которые должны быть выполнены при импорте. STATUS –Указывает, как часто будет обновляться информация о состоянии выполнения задания импорта. TABLE_EXISTS_ACTION – Задает действия, которые нужно выполнить при совпадении имен импортируемой и уже существующей таблиц. REMAP_DATAFILE – Изменяет имя исходного файла данных на целевое имя во всех SQLоператорах, где есть ссылка на исходные данные. REMAP_SCHEMA – Загружает все объекты из одной исходной схемы в другую целевую. REMAP_TABLE – Позволяет переименовать таблицы при импорте. REMAP_TABLESPACE – Отображает все объекты с постоянными данными, отобранные для импорта в исходном табличном пространстве в новое целевое табличное пространство. Следующие команды доступны интерактивном режиме: ADD_FILE – Добавляет дополнительный файл дампа. CONTINUE_CLIENT – Завершает диалоговую сессию и переходит в режим записи журнала. EXIT_CLIENT – Останавливает сессию клиента импорта/экспорта, не затрагивая работу задания. KILL_JOB – Отключает все активные сессии клиента и останавливает задание. PARALLEL – Изменяет количество рабочих процессов для текущего задания. START_JOB – Перезапускает задание, к которому произведено подключение. 162

STATUS – Выводит подробный отчет, о состоянии текущего задания и/или меняет время опроса состояния задания. STOP_JOB – Останавливает текущее задания для последующего перезапуска. Сетевые операции Data Pump При задании параметра NETWORK_LINK утилиты impdp при импорте данные перемещаются между базами напрямую с использованием SQL. Оператор SELECT выбирает данные из удаленной базы данных с помощью соединения с базой данных, указанного в параметре NETWORK_LINK. Соответствующий оператор INSERT производит вставку данных в целевую базу. В операции не участвуют файлы дампов. Если параметр NETWORK_LINK используется утилитой expdp при экспорте данных, то данные из удаленной базы записываются в файлы дампов на целевой базе данных. Поддерживаются только следующие типы соединения баз данных: Публичные (Public , public and shared). Определенный пользователь (Fixed user). Подключенный пользователь (Connected user). Соединение баз данных типа "Current User" в Data Pump не поддерживается Существует ряд ограничений для применения параметра NETWORK_LINK: При использовании полного переносимого экспорта, таблицы со столбцами LONG или LONG RAW, находящиеся в административных табличных пространствах не поддерживаются. При переносе базы данных по сети с использованием полного переносимого экспорта, аудит не может быть включен для таблиц, расположенных в административных табличных пространствах (SYSTEM и SYSAUX), если сама информация аудита расположена в пользовательском пространстве. Исходная и целевая базы данных не могут отличаться друг от друга более, чем на две версии. Например, если одна база данных это версия 12с, то другая может быть только 12c, 11g, 10g. SQL-Loader Утилита SQL-Loader используется для загрузки данных из сторонних источников. Утилита имеет развитый механизм разбора входных данных, позволяющий обрабатывать широкий набор плоских данных из внешних файлов. По существу любая база данных может экспортировать данные в виде файла плоского формата. SQL-Loader может загрузить эти данные в таблицы базы данных Oracle. SQL-Loader может выполнить следующие действия: Загрузить данные по сети, если данные находятся на другом сервере, нежели база целевая данных. Загрузить данные из нескольких файлов в рамках одной и той же сессии. Загрузить данные в несколько таблиц в рамках одной и той же сессии. Указать набор символов, используемый в данных. Выборочно загрузить данные на основании значений в записях. Изменять данные перед загрузкой их, используя функции SQL. 163

Создавать уникальные последовательные значения ключей в указанных столбцах. Использовать файловую систему ОС для доступа к файлам данных. Загружать данные с диска, ленты или именованного канала pipe. Создавать подробные отчеты об ошибках. Загружать произвольные объектно-ориентированные данные. использовать вторичные файлы данных для загрузки LOB'ов и коллекций. Использовать обычную, прямую загрузку данных или загрузку с помощью внешних таблиц. Утилита SQL-Loader может использоваться как с управляющим файлом, так и без него. Использование управляющего файла позволяет наиболее полно управлять операцией загрузки. Простые операции загрузки могут быть выполнены без указания управляющего файла. Этот режим называется оперативной загрузкой (SQL-Loader express mode). Сессия SQL-Loader использует следующие файлы: Control – Задает формат файла данных и управляет поведением SQL*Loader. Data – Один или более файлов, содержащих загружаемую информацию. Log – Журнал действий, выполненных SQL*Loader, и список возникших ошибок. Bad – Содержит все записи, которые не могут быть загружены из-за ошибок. Discard – Содержит все записи, которые должны быть пропущены по указаниям управляющего файла. Вызов SQL-Loader осуществляется командой sqlldr. Дополнительно могут указываться параметры, устанавливающие параметры сессии. Помимо командной строки, эти параметры могут быть указаны следующим образом: Параметры могут быть добавлены к файлу параметров. Чтобы использовать файл параметров, его имя нужно задать в командной строке с помощью PARFILE. Некоторые параметры могут быть указаны с управляющем файле SQL-Loader в конструкции OPTIONS. Если параметр задан и в командной строке, и в файле параметров, и в конструкции OPTIONS управляющего файла, то выбирается значение из командной строки. Управляющий файл SQL-Loader представляет собой текстовый файл, указывающий SQLLoader'у, где расположены файлы данных, какой формат использовать при разборе данных, в какие таблицы производить вставку данных и т.д. Управляющий файл имеет три свободно определяемых раздела: Первый раздел содержит информацию для всей сессии, глобальные опции, расположение входных файлов и данные, которые будут загружаться. Второй раздел состоит из одного или более блоков INTO TABLE. В блоке содержится информация о целевых таблицах. Третий раздел является дополнительным и, при наличии, содержит входные данные.

164

SQL-Loader поддерживает два метода вставки данных в таблицы Oracle: обычный (Conventional Path) и прямой (Direct Load). При обычном SQL-Loader фактически создает операторы INSERT для каждой записи в файле, которую нужно загрузить, и передает их разборщику SQL Oracle. При прямой загрузке SQL-Loader минует разборщик SQL и загружает данные в таблицы напрямую. Прямой метод значительно быстрее, но обычный значительно гибче. Прямой метод имеет некоторые ограничения: Он не может использоваться параллельно с другими транзакциями в целевой таблице. Триггеры не срабатывают при вставке. Данные записываются выше указателя максимально занятых блоков даже при наличии свободного места в начале таблицы. Не поддерживаются кластеризованные таблицы. Указатели внешней ссылочной целостности при загрузке отключаются.

165

Перемещение объектов из пространства SYSAUX Табличное пространство SYSAUX является дополнительным системным пространством для пространства SYSTEM. Некоторые их компонентов Oracle, которые ранее создавались в отдельных табличных пространствах, теперь "по умолчанию" располагаются в SYSAUX. Если пространство SYSAUX становится недоступным, то основная функциональность база данных сохраняется. Функциональность, использующая объекты в SYSAUX, может стать недоступной к использованию или частично неработоспособной. Представление V$SYSAUX_OCCUPANTS используется для определения компонентов, располагающихся в SYSAUX. Представление содержит информацию: Имя компонента. Описание компонента. Имя схемы. Процедуру переноса компонента. Текущее использование табличного пространства. Имя процедуры в столбце MOVE_PROCEDURE представления V$SYSAUX_OCCUPANTS описывает процедуру, которую нужно использовать для переноса компонента из пространства SYSAUX. При необходимости для компонента, ранее перенесенного из пространства SYSAUX, та же самая процедура может быть использована для возврата его в SYSAUX. В следующем запросе приведен частичный вывод компонентов базы данных, их описание и имя процедуры, которая позволит перенести их в другое пространство: SQL> SELECT occupant_name, occupant_desc, move_procedure FROM v$sysaux_occupants WHERE move_procedure IS NOT NULL; OCCUPANT_NAME OCCUPANT_DESC MOVE_PROCEDURE ---------------------------------------------------------------LOGMNR LogMiner SYS.DBMS_LOGMNR_D.SET_TABLESPACE LOGSTDBY Logical Standby SYS.DBMS_LOGSTDBY.SET_TABLESPACE AUDIT_TABLES DB audit tables DBMS_AUDIT_MGMT.move_dbaudit_tables XDB XDB XDB.DBMS_XDB.MOVEXDB_TABLESPACE AO Analytical DBMS_AW.MOVE_AWMETA Workspace Object Table

166

Создание постоянного табличного пространства "по умолчанию" В версии 12с появилась возможность задавать постоянное табличное пространство "по умолчанию", которое будет использоваться для всех учетных записей пользователей, не имеющих явно присвоенного табличного пространства. Эта возможность была добавлена, чтобы избежать неприятной альтернативы, состоявшей в том, что вновь созданные пользователи без явно назначенного пространства "по умолчанию", получали в его качестве системное пространство SYSTEM. Теперь операторы CREATE DATABASE и ALTER DATABASE получили опцию DEFAULT TABLESPACE. В примере показано, как задать USERS в качестве табличного пространства "по умолчанию": SQL> ALTER DATABASE DEFAULT TABLESPACE users; Текущие установки табличных пространств "по умолчанию" могут быть получены из представления DATABASE_PROPERTIES: SQL> SELECT property_name, property_value FROM database_properties WHERE property_name like '%TABLESPACE'; PROPERTY_NAME PROPERTY_VALUE ------------------------------ -------------DEFAULT_TEMP_TABLESPACE TEMP DEFAULT_PERMANENT_TABLESPACE USERS

Если задано или изменено постоянное табличное пространство "по умолчанию", то все объекты, созданные пользователями, не имеющими явно назначенного табличного пространства, будут созданы в этом пространстве за исключением случая, когда оператор создания объекта явно укажет, где следует располагать объект. Табличное пространство "по умолчанию" не может быть удалено.

167

Использование консультанта повторов (redo)

для

определения

размеров

журналов

Размер журналов повторов может влиять на производительность базы данных в целом. Поведение процессов DBW и ARCH частично зависит от размеров журналов повторов. В общем случае больший размер файла дает большую производительность. Если размеры файлов слишком малы, то это приводит к частому выполнению процедуры контрольной точки. Частота выполнения контрольной точки зависит от нескольких факторов, включая влияние журнальных файлов и значение параметра FAST_START_MTTR_TARGET. Если этот параметр установлен так, чтобы снизить время восстановления экземпляра, то база данных автоматически старается выполнять контрольную точку достаточно часто, чтобы удовлетворить значению FAST_START_MTTR_TARGET. В столбце OPTIMAL_LOGFILE_SIZE представления V$INSTANCE_RECOVERY содержит оптимальный размер файлов повторов. Эта информация также доступна на странице Redo Log Groups в Oracle Enterprise Manager. По правилу большого пальца размер журнала повторов варьируется от 100МБ до нескольких гигабайт. Этот размер зависит от количества информации повторов, создаваемого системой. Считается, что следует устанавливать размер журналов таким, чтобы переключение их происходило не чаще, чем раз в двадцать минут.

168

Применение безопасных файлов для хранения данных LOB В версии Oracle 11g был введен новый тип памяти для хранения больших объектов безопасные файлы (SecureFile LOBs). Предыдущий тип переименован в базисные файлы (BasicFile LOBs). SecureFile LOBs добавили несколько новых возможностей для хранения больших объектов: Интеллектуальное сжатие позволяет пользователям явно сжимать данные для экономии дискового пространства. Интеллектуальное шифрование позволяет хранить шифрованные данные "на месте" и делать их доступными для произвольного чтения и записи. Возможность дедупликации позволяет Oracle автоматически определять повторяющие LOB данные и сохранять пространство, храня только одну копию данных. Оптимизация пути доступа к данным LOB включает логическое кэширование выше уровня дисковой памяти, упреждающее чтение, новые режимы кэширования, векторизованный ввод/вывод и т.д. Параметр инициализации db_securefile определяет, будет ли база данных Oracle использовать SecureFile или BasicFile для размещения LOB. Возможны следующие значения этого параметра: ALWAYS, FORCE, PERMITTED, NEVER и IGNORE. Смысл этих значений: ALWAYS - База данных будет пытаться создавать SecureFile для размещения LOB, но создаст BasicFile, если используемое табличное пространство не использует механизм автоматического управления сегментами. PERMITTED - Разрешено создание SecureFile для размещения LOB. PREFERRED - Все LOB создаются как SecureFiles, если явно не указан тип размещения BASICFILE в описании размещения LOB или используемое табличное пространство использует ручной тип управления сегментами. При задании параметра PREFERRED случаи, когда тип размещения BASICFILE был бы унаследован из описания секции или столбца, игнорируются, и LOB будут создаваться с типом хранения SecureFiles. NEVER - запрещает создание типа памяти SecureFile для размещения LOB. Если оператор DML пытается явно создать столбец как SecureFile LOB, будет создан BasicFile LOB. Если какая-либо опция или возможность специфичная для типа хранения SecureFile задана в DML, то возникнет ситуация исключения. IGNORE - Ключевое слово SECUREFILE все параметры SecureFiles игнорируются. Реорганизация "на лету" может выполняться на уровне таблиц или секций. Реорганизация "на лету" означает, что таблицы или их секции не переводятся в состояние offline. Реорганизация также может проводиться параллельно. Однако эта операция требует дополнительного пространства, равного полному размеру таблицы или ее секции(й) и всех LOB сегментов. Кроме того, после миграции требуется перестроить глобальные индексы. Тип хранения SecureFiles наследует установки столбца LOB для дедупликации, шифрования и сжатия, указанные при создании LOB'а. Пакет DBMS_LOB содержит несколько процедур, позволяющих определить или изменить унаследованные значения:

169

DBMS_LOB.GETOPTIONS - С помощью этой процедуры может быть получены текущие параметры. Возвращается целое число, соответствующее предопределенной константе для данного типа. Например, для DEDUPLICATE_OFF возвращается 0. Нет необходимости знать все значения для теста, нужно только знать имя процедуры. DBMS_LOB.SETOPTIONS - Процедура устанавливает параметры для SecureFile LOB (сжатие, дедупликацию и шифрование). Параметры устанавливаются для каждого LOB, переназначая исходные параметры. DBMS_LOB.ISSECUREFILE - Эта функция возвращает значения TRUE или FALSE в зависимости от того, указывает ли переданный LOB локатор (BLOB или CLOB) на SecureFile. Существующая в пакете DBMS_SPACE процедура SPACE_USAGE позволяет получить информацию об использовании пространства объектами LOB. Процедура возвращает объем диска в блоках, занимаемый всеми LOB'ами в сегменте. Процедура может использоваться только в пространстве с автоматическим управлением сегментами.

170

Применение прямого NFS клиента Начиная с версии Oracle 11g, в ядро базы данных встроен собственный NFS клиент. Эта возможность повышает производительность файловых операций и улучшает управляемость при использовании сетевых файловых систем NFS. Прямой клиент NFS (Direct NFS Client) улучшает производительность ввода/вывода путем встраивания специфичных для Oracle оптимизаций и удаления накладных расходов для поддержки NFS в ядре операционной системы. Кроме того, прямой NFS упрощает настройку путем удаления необходимости ручной настройки большинства параметров NFS. Для применения прямого NFS соответствующие файловые системы должны быть смонтированы и доступны через ядро операционной системы. Прямой NFS не монтирует файловую систему. Специфические опции монтажа, используемые ОС, не являются значимыми, так как прямой NFS управляет доступом БД Oracle к дискам. Клиент прямого NFS использует либо новый файл настроек oranfstab, либо файл монтажа файловых систем (/etc/mtab для Linux), чтобы определить установки для точек монтажа устройств NFS. Параметры монтажа определяются в следующем порядке. Первоначально, Oracle ищет параметры монтажа в файле $ORACLE_HOME/dbs/oranfstab, который устанавливает параметры прямого клиента NFS для одной базы данных. Во-вторых, Oracle ищет требуемые параметры в /etc/oranfstab, где указаны точки монтажа NFS, доступные для всех баз данных сервера. В завершение Oracle читает файл монтажа файловых систем (/etc/mtab для Linux, /etc/vfstab - Solaris), чтобы определить доступные точки монтажа NFS. При наличии одинаковых записей клиент прямого NFS будет использовать первую найденную. Помимо заполнения одного из этих файлов необходимо заменить стандартную библиотеку Oracle Disk Manager (ODM) на библиотеку с поддержкой прямого клиента NFS. Пример содержания файла oranfstab: server: FirstNFSServer path: 192.168.1.1 path: 192.168.1.2 path: 192.168.1.3 path: 192.168.1.4 export: /u01/oradata1 mount: /u01/oradata1

Как только этот файл создан, то следующие команды разрешат использование библиотеки прямого клиента NFS ODM: $ cd $ORACLE_HOME/lib $ cp libodm11.so libodm11.so_stub $ ln –s libnfsodm11.so libodm11.so

171

Управление производительностью Проектирование размещения базы данных Если у двух юристов существует три мнения, то даже один администратор баз данных может иметь несколько мнений по поводу файловой раскладки одной и той базы данных. Иначе говоря, термин "правильный" зависит от личности его использующего и обстоятельств. Одной из стандартных рекомендаций Oracle при разработке плана размещения БД и планирования ввода/вывода является использование Oracle Automatic Storage Management (Oracle ASM). Из-за способа, используемого в Oracle ASM при чередовании (striping) данных по всему набору доступных дисковых групп, большинство общепринятых правил раскладки файлов просто неприменимо при использовании ASM. Oracle ASM дает следующие возможности: Чередование данных(Striping). Зеркалирование данных (Mirroring). Перестройка дисковой памяти на ходу и динамическая балансировка. Управление созданием и удалением файлов. Для систем, не использующих Oracle ASM, существует несколько возможных конфигураций для оптимизации производительности дисковой памяти: Чередовать все по всем дискам - Наиболее простой способ распределить ввод/вывод для минимизации конкуренции состоит в создании единственного тома, данные в котором равномерно чередуются по всем дискам. Из соображений резервирования данных, созданный том должен быть зеркалирован (RAID 1). Разместить архивные журналы на отдельные диски - Если архивированные журналы повторов хранятся на том же наборе дисков, что и остальные файлы базы данных, то запросы ввода/вывода к этим дискам будут замедляться, когда база данных архивирует журналы повторов. Перенос архивных файлов на отдельные диски улучшит производительность операции архивирования и поможет избежать ее конкуренции с записями в файлы данных. Перенести журналы повторов на отдельные диски - Базы данных с высокой интенсивностью операций модификаций (OLTP системы, например) ведут интенсивную запись в журналы повторов. Перенос этих файлов на отдельные диски, как от файлов данных, так и архивированных журналов, означает, что запись в журналы повторов будет осуществляться с максимальной скоростью. Производительность в обработке транзакций будет максимальной, и запись журналов повторов не будет подвержена влиянию какихлибо других операций ввода/вывода.

172

Контроль производительности Для определения проблем с производительностью существует много инструментов и методик. В последних выпусках Oracle наиболее простым способом обнаружения проблем с производительностью было использование Enterprise Manager, что требовало лицензирование некоторых опций. Для версии 12c рекомендуемым решением является Oracle Enterprise Manager Cloud Control - продукт управления уровня предприятия. EM Cloud Control создан для управления всей IT средой, включая базы данных, сервера, интеграционные продукты и т.д. Строго говоря, для эксплуатации одной базы данных этот продукт избыточен. Для управления одной базой данных Oracle предлагает облегченную версию Enterprise Manager - EM Express. EM Express представляет собой утилиту, встроенную в БД и позволяющую управлять БД Oracle через веб-интерфейс, отслеживать производительность БД, а также выполнять некоторые общие административные функции. Это легковесное приложение, спроектированное для минимизации накладных расходов на базу данных. В базе данных нет каких-либо фоновых задач или процессов, связанных с EM Express. Утилита пользуется данными, которые уже были собраны БД. Страница производительности EM Express является отправной точкой для анализа проблем производительности. На рисунке приведен вид страницы производительности EM Express:

Рис. 32 Страница производительности базы данных EM express

На этой странице приведено объединенное представление всех данных по производительности для данного момента времени. Данные по производительности включают 173

аналитику ASH, монитор SQL, ADDM и метрики, которые описывают характеристики нагрузки и использование ресурсов базы данных. Страница производительности может отображать исторические и текущие данные. Временной интервал может быть выбран из диалога "Select Time Period" или с помощью полосы прокрутки "Time Picker" в верхней части страницы. После выбора временного интервала имеющиеся данные будут отображены на соответствующей вкладке. На полосе прокрутки отображается среднее количество активных сессий за период времени. При наличии пиков на полосе прокрутки указатель интервала времени может быть перемещен на интересующее время для получения более детальной информации (на рис. 30 указатель установлен на 03:55 PM). При работе в режиме реального времени данные производительности извлекаются из представлений памяти базы данных. Полоса прокрутки времени отображает данные за прошедший час, и DBA может указать любой временной интервал внутри этого времени. "По умолчанию" отображаются последние пять минут. При работе с историческими данными происходит извлечение их из репозитория AWR. Администратор может выбрать любой временной интервал, если данные имеются в AWR. Содержимое страницы производительности может быть сохранено как составной отчет текущей активности. Страница производительности систематизирует данные производительности путем разделения их на несколько вкладок, каждая из которых относится к разным аспектам производительности базы данных. На странице производительности доступны следующие вкладки: Сводка (Summary) - В режиме реального времени на этой вкладке выдается обобщенное представление производительности системы в терминах потребление ресурсов сервера (CPU, ввод/вывод и потребление памяти), а также среднее количество активных сессий. В историческом режиме на вкладке отображаются данные производительности системы в терминах потребления ресурсов, среднего количества активных сессий и данные по профилю нагрузки. Активность (Activity) --На вкладке отображаются данные аналитики ASH Analytics для данных реального времени или исторических данных. Нагрузка (Workload) - На вкладке отображаются данные о профиле нагрузки, а именно интенсивность вызовов, интенсивность регистрации пользователей и количество сессий. Дополнительно на вкладке приводятся список наиболее интенсивных SQL-запросов для выбранного временного интервала. В режиме реального времени для SQL запросов отображаются только времена базы (DB time) данных. В режиме исторических данных пользователь также может увидеть и другие метрики, например, время CPU или количества выполнений. RAC - Отображаются специфические для RAC метрики, например, количество полученных глобальных блоков кэша, или средняя задержка передачи блока. Отслеживаемые SQL запросы (Monitored SQL) - На вкладке отображается выполнение отслеживаемых SQL запросов, кода PL/SQL и операций базы данных (Database Operations) для режима реального времени и исторического режима. ADDM - Отображаются данные ADDM и отчеты ADDM реального времени для обоих режимов работы. 174

Текущие находки ADDM (Current ADDM Findings) - На вкладке выводятся данные анализа производительности системы в реальном времени за последние пять минут. Вкладка доступна только в режиме реального времени, а ее содержимое обновляется только, если селектор выбора времени указывает на текущее время.

175

Управление памятью В ранних релизах Oracle управление памятью экземпляра было весьма сложным ручным процессом, в котором немалую роль играла интуиция администратора. С течением времени, читай с развитием ядра, Oracle добавлял все больше и больше возможностей автоматизации этого процесса. В версии 12c существует единственный параметр, позволяющий экземпляру базы данных автоматически настраивать все пулы памяти. Если параметру инициализации MEMORY_TARGET задано требуемое целевое значение, экземпляр при запуске затребует у операционной системы это количество памяти и автоматически разместит разные пулы памяти. Дополнительно можно указать величину максимального размера памяти MEMORY_MAX_TARGET. Параметр MEMORY_TARGET является динамическим и может быть изменен без перезапуска экземпляра. MEMORY_MAX_TARGET является статическим, и его изменения потребует остановки экземпляра. Он служит верхним пределом для MEMORY_TARGET, поэтому случайно не получится установить MEMORY_TARGET слишком большим. При использовании автоматического управления памятью экземпляр перераспределяет память между SGA и PGA автоматически по мере изменения нагрузки. Базы данных, созданные с помощью DBCA с использованием базовых инсталляционных опций, будут использовать автоматическое управление памятью "по умолчанию". Если экземпляр не использует автоматическое управление памятью, то включить этот режим можно с использованием следующих команд: SQL> ALTER SYSTEM SET MEMORY_TARGET = nM; SQL> ALTER SYSTEM SET SGA_TARGET = 0; SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 0; Дополнительно можно выдать следующую команду SQL> ALTER SYSTEM SET MEMORY_MAX_TARGET = nM SCOPE = SPFILE; Соотношения между четырьмя параметрами, используемыми автоматическим управлением памятью (Automatic Memory Management, AMM), описываются следующим образом: memory_target – Если задан параметр MEMORY_TARGET, то экземпляр при запуске разместит заданное параметром количество памяти, "по умолчанию" выделив 60% размещенного для SGA, а 40% - PGA. С течением времени работы экземпляр будет перераспределять память между системной глобальной областью (SGA) и программной глобальной областью (PGA). Если параметр MEMORY_TARGET не задан, то автоматическое управление памятью не используется, даже если задано значение параметра MEMORY_MAX_TARGET. memory_max_target – Если параметр установлен, то его значение определяет максимальный объем памяти, который Oracle запросит у операционной системы для размещения SGA и PGA. Если параметр не задан, то считается, что он равен значению MEMORY_TARGET. sga_target – Параметр необязателен при использовании автоматического управления памятью. Если значение задано, и значение MEMORY_TARGET также задано, то величина

176

SGA_TARGET становится минимально возможной величиной памяти, которая может быть выделена SGA автоматически. pga_aggregate_target – Параметр необязателен при использовании автоматического управления памятью. Если значение задано, и MEMORY_TARGET также задано, то значение PGA_AGGREGATE_TARGET становится минимально возможной величиной памяти, которая может быть выделена PGA автоматически. Автоматическое управление разделяемой памятью (Automatic Shared Memory Management) Механизм Automatic Shared Memory Management (ASMM) является предшественником автоматического управления памятью (Automatic Memory Management, AMM). Если есть необходимость использовать ASMM вместо AMM, общий объем памяти экземпляра SGA задается с помощью параметра инициализации SGA_TARGET. Экземпляр Oracle автоматически распределит эту память между различными частями SGA. При использовании ASMM некоторые компоненты SGA нужно задавать вручную, включая LOG_BUFFER - Размер буфера журнала. DB_KEEP_CACHE_SIZE - Размер буфера удержания. DB_RECYCLE_CACHE_SIZE - Размер буфера повторного использования. DB_nK_CACHE_SIZE - Размер буфера(ов) для нестандартных размеров блоков. Вся память, выделенная управляемым вручную компонентам, вычитается из величины SGA_TARGET, а остаток распределяется между компонентами, размер которых управляется автоматически: SHARED_POOL_SIZE - Разделяемый пул. LARGE_POOL_SIZE - Большой пул. JAVA_POOL_SIZE - Пул Java. DB_CACHE_SIZE - Буферный кэш. STREAMS_POOL_SIZE - Потоковый пул. Механизм перераспределения памяти, как AMM, так и ASMM, использует статистики, собранные для базы данных, поэтому ни одна из этих опций не может быть использована, если параметр инициализации STATISTICS_LEVEL установлен в BASIC. Буферный кэш Буферный кэш базы данных разделен на несколько пулов. Отдельные пулы могут быть настроены вручную либо для удержания данных в кэше, либо для возможного освобождения после завершения использования. Определенным объектам схемы может быть назначен подходящий буферный кэш для обеспечения лучшего контроля над старением блоков. В системе существуют следующие буферные пулы: Пул "по умолчанию" (Default pool) - Пул, где обычно располагаются, кэшируются, блоки. Если дополнительные пулы вручную не настроены, то этот пул является единственным пулов в системе.

177

Пул удержания (Keep pool) - Пул предназначен для блоков, к которым предполагается частое обращение, но они все равно покидают пул "по умолчанию" из-за старения и требования пространства для размещения новых блоков. Целью буфера удержания является сохранение объектов в памяти как можно дольше, чтобы снизить количество операций ввода/вывода. Пул повторного использования (Recycle pool) - Этот пул предназначен для блоков, которые будут использоваться нечасто. Пул повторного использования предотвращает избыточное использование пространства кэша объектами. В этой области следует располагать большие сегменты, доступ к которым происходит случайным, хаотичным образом. В пуле "по умолчанию" эти сегменты вызовут избыточный сброс буфера на диск без каких-либо выгод, так как в момент, когда блок будет нужен повторно, он уже будет сброшен на диск.

178

Выявление и анализ проблем производительности Автоматический монитор диагностики базы данных (Automatic Database Diagnostic Monitor или ADDM) представляет собой утилиту, встроенную в функциональность базы данных Oracle, которая автоматически определяет и сообщает о проблемах с производительностью. Функциональность ADDM основана на снимках репозитория автоматической нагрузки (Automatic Workload Repository, AWR). Данные из снимков анализируются, а результаты отображаются как "находки" ADDM на домашней странице базы данных в Oracle Enterprise Manager Cloud Control. Cloud Control является начальным инструментом для диагностического мониторинга и, когда возможно, следует запускать ADDM с его помощью. Если Cloud Control недоступен, то можно запускать ADDM с помощью пакета DBMS_ADDM. Для использования API и пакета DBMS_ADDM необходимо наличие привилегии ADVISOR. Находки ADDM позволяют администраторам БД быстро обнаруживать проблемы с производительностью, в идеале быстрее, чем об этом заявят пользователи. Первым или одним из первых шагов в поиске и устранении проблем производительности должен быть просмотр результатов анализа ADDM. Каждая находка ADDM будет включать в себя рекомендации для устранения или уменьшения проблем с производительностью. Регулярный просмотр и реализация рекомендаций ADDM должны быть частью регулярных обязанностей администратора по обслуживанию БД. После каждого снимка AWR ("по умолчанию" раз в час) выполняется анализ ADDM, а его результаты сохраняются в базе данных. При обнаружении потенциальной проблемы, ADDM выполняет следующие шаги: Находит причину проблемы с производительностью. Выдает рекомендации по устранения причины. Оценивает ожидаемые результаты. Указывает области, где нет необходимости настройки. Монитор ADDM проводит анализ сверху вниз. Вначале определяются симптомы проблем производительности, и уточняется анализ с целью обнаружить корневую причину. Монитор ADDM использует временные статистики БД для определения наличия проблем с производительностью. Время базы данных (DB time) это накопленное время, потраченное базой данных на выполнение запросов пользователей. Время DB time включает в себя время ожидания и процессорное время всех активных пользовательских сессий. Максимальной целью является минимизация DB time для данной нагрузки. При этом база данных сможет обслужить максимально возможное количество запросов пользователей на имеющихся ресурсах. Настройка производительности это итерационный процесс. Когда одна проблема решена, другая часть системы может стать новым узким местом. Решение проблем производительности может потребовать нескольких циклов даже с использованием возможностей ADDM. Если проблема производительности определена, то монитор ADDM рекомендует потенциальные решения. Если возможно, то может быть выдан набор решений для одной проблемы. Рекомендации ADDM могут включать себя следующие предложения:

179

Аппаратные изменения - Добавление процессоров или изменение в системе ввода/вывода. Изменения параметров базы данных - Изменение параметров инициализации экземпляра. Изменения в схеме - Создание хэш-секционирования в таблице или индексе, или применение автоматического управления сегментами (ASSM). Изменение приложений - Примеры, которые могут быть использованы для опций кэширования для последовательностей и использования связанных переменных. Использование других ассистентов - Монитор ADDM может быть предложить использовать SQL Tuning Advisor для вызывающих большую нагрузку SQL-запросов или примененить Segment Advisor для активно используемых объектов (горячие объекты). "По умолчанию" монитор ADDM включен. Его поведением управляют параметры инициализации CONTROL_MANAGEMENT_PACK_ACCESS и STATISTICS_LEVEL. Чтобы включить монитор, нужно установить параметр CONTROL_MANAGEMENT_PACK_ACCESS в DIAGNOSTIC+TUNING ("по умолчанию") или DIAGNOSTIC. При установке этого параметра в NONE запрещает многие возможности Oracle, включая ADDM. Для включения ADDM параметр STATISTICS_LEVEL следует установить в TYPICAL ("по умолчанию") или же ALL. Установка этого параметра в BASIC запрещает многие возможности Oracle, включая ADDM. Анализ производительности ввода/вывода частично зависит от значения параметра DBIO_EXPECTED, описывающего ожидаемую производительность подсистемы I/O. Это значение является средним временем в миллисекундах, нужное для чтения одного блока. "По умолчанию", Oracle использует 10 миллисекунд, что приемлемо для большинства жестких дисков. Основываясь на имеющемся оборудовании, можно выбрать другое время. Если подходящее значение определено, то можно изменить DBIO_EXPECTED. В примере показано, как установить значение 600 миллисекунд. Приведенный код должен выполнять пользователь SYS: SQL> EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM','DBIO_EXPECTED',600); "По умолчанию" AWR создает снимки производительности каждый час и хранит статистики в репозитории нагрузки в течение восьми дней. При необходимости можно изменить оба этих временных интервала. Рекомендуется установить период хранения по крайней мере один месяц. Более длинные периоды могут быть рекомендованы, если они включают полный бизнес-цикл, что зависит от потребностей бизнеса. Результаты анализа ADDM представлены в виде набора находок. Находки ADDM принадлежат к одному из трех классов: Проблема (Problem) - Находки, описывающие причину проблем с производительностью. Признак (Symptom) - Находки, описывающие данные, часто ведущие к проблемам/проблеме. Информация (Information) - Находки, используемые для отчета о местах системы, не влияющих на производительность.

180

Любая найденная проблема будет квалифицирована с оценкой доли времени базы данных, которую эта проблема вызывает. Если проблема имеет несколько причин, монитор ADDM может сообщить о нескольких находках для нее. Рекомендации составляются из действий и объяснений. Все действия в рекомендациях должны быть реализованы в требуемой последовательности, чтобы достичь предполагаемой выгоды. Действие ADDM может представлять несколько решений. В этом случае, логичнее всего реализовывать самое простое решение. В любом случае за все отвечает администратор.

181

Проведение реального тестирования приложений. Для тестирования реальной нагрузки приложений используются две утилиты Oracle - повтор базы данных Database Replay и анализатор производительности SQL - SQL Performance Analyzer (SPA). Эти две утилиты обеспечивают всеобъемлющее решение для тестирования влияния планируемых изменений на производительность приложений. С их помощью можно удостовериться, что планируемые изменения в базе данных не приведут к снижению производительности. Утилита SPA позволяет оценить результаты изменений окружения базы данных на планы выполнения SQLзапросов и наборы статистик, запуская запросы по отдельности и последовательно в текущем и планируемом окружении. Утилита SQL Performance Analyzer использует наборы настройки SQL (SQL Tuning Sets), советник настройки SQL (SQL Tuning Advisor) и систему управления планами SQL (SQL Plan Management). Анализатор производительности автоматизирует и упрощает процесс выявления потенциального влияния изменений даже при очень высоких SQL нагрузках. SQL Performance Analyzer Прежде, чем запустить анализатор производительности SQL (SQL Performance Analyzer), нужно выполнить захват SQL операторов из промышленной системы. Захват рабочей нагрузки оказывает незначительное влияние на БД. Захват рабочей нагрузки, содержащей большое количество SQL операторов, лучше опишет базу данных промышленной системы, что поможет анализатору производительности SQL точнее предсказать потенциальное влияние планируемых изменений на производительность. В идеале, следует захватить все SQL-операторы, вызываемые приложениями или выполняемые заданиями промышленной базы данных. Захваченные SQL-операторы могут быть сохранены в виде набора настройки SQL и использованы в качестве входных данных анализатора производительности. Набор настройки SQL представляет собой объект базы данных, включающие в себя один и более оператор SQL, вместе с их статистиками и контекстом выполнения. Операторы SQL могут быть загружены в набор настройки SQL из нескольких источников. Можно использовать кэш курсоров, репозиторий нагрузки AWR или уже имеющийся набор настройки SQL. Использование наборов настройки SQL позволяет администратору: Хранить SQL код и любую необходимую дополнительную информацию в едином постоянном объекте базы данных. Заполнять, изменять, удалять и выбирать захваченные SQL операторы в наборы настройки SQL. Загружать и объединять содержимое различных источников, такие как репозиторий AWR и кэш курсоров. Экспортировать наборы настройки SQL из системы, где был произведен захват нагрузки, и импортировать в другую систему Использовать SQL нагрузку в качестве входных данных для других консультантов, таких как SQL Tuning Advisor или the SQL Access Advisor Используемые представления словаря данных Для наблюдения работы анализатора производительности SQL и просмотра результатов анализа используются следующие представления:

182

o o o o

Представление DBA_ADVISOR_TASKS содержит описания созданных задач анализатора производительности SQL. Представление DBA_ADVISOR_EXECUTIONS содержит данные о выполнении задач. Представление DBA_ADVISOR_FINDINGS содержит результаты поиска анализатора производительности SQL. SQL Performance Analyzer обнаруживает следующие типы находок: Проблемы, такие как снижение производительности. Симптомы, такие как изменения планов выполнения. Ошибки, такие как отсутствие объектов или представлений. Информационные сообщения. Представление DBA_ADVISOR_SQLPLANS содержит список всех планов выполнения. Представление DBA_ADVISOR_SQLSTATS содержит список всех разборов SQL и статистик их выполнения. Представление V$ADVISOR_PROGRESS содержит ход анализа производительности SQL.

Последовательность действия при анализе изменения производительности Захватить рабочую нагрузку SQL, которую предполагается анализировать, и сохранить ее в виде набора настройки SQL. Если для тестирования планируется использовать отдельную от продуктивной систему, то окружение тестовой системы должно быть максимально близким к продуктивной. Набор настройки SQL нужно перенести на тестовую систему. На тестовой систем создается задача анализатора производительности SQL. Выполняется предварительный перед внесением изменений в настройки прогон SQLоператоров из набора настройки. Выполняются планируемые изменения в системе. На измененной системе выполняется прогон SQL-операторов из набора настройки. Проводится сравнение данных производительности двух прогонов и создается отчет, указывающий на SQL-операторы, выполнение которых улучшилось, не изменилось или ухудшилось после изменений. Проводится настройка SQL-операторов, выполнение которых ухудшилось. Пакет DBMS_SQLPA содержит процедуры и функции для работы SQL Performance Analyzer. Следующие процедуры применяются для создания и проведения задач анализа, а также создания отчетов о находках: CREATE_ANALYSIS_TASK - Эта функция применяется для создания задач анализа как для одиночного SQL оператора из различных источников (SQL текста, AWR или кэша курсоров), так и для набора настройки SQL. EXECUTE_ANALYSIS_TASK - Эта функция/процедура выполняет ранее созданную задачу анализа, функция возвращает новое имя задачи. REPORT_ANALYSIS_TASK - Процедура выводит результаты выполнения задачи анализа.

183

Повтор выполнения базы данных Утилита Oracle Database Replay проигрывает ранее захваченные внешние вызовы базы данных, сделанные за время захвата рабочей нагрузки. Захват включает в себя всю значимую информацию о клиентских запросах, такую как SQL-запрос, значение переменных связывания и информацию о транзакции. Фоновая активность базы данных и задания планировщика не включаются в захват. Кроме того, следующие типы клиентских запросов не включаются в данные захвата: Данные прямой загрузки из внешних источников, загруженные при помощи утилиты SQLLoader. Разделяемые серверные запросы (Oracle MTS). Данные потоков Oracle (Oracle Streams). Данные расширенной репликации (Advanced replication). Отличные от PL/SQL Advanced Queuing (AQ). Ретроспективные запросы. Перемещения объектов на основе Oracle Call Interface (OCI). Доступ к объектам без использования SQL. Распределенные транзакции. Хорошей практикой считается перезапуск экземпляра перед началом процесса захвата. При этом можно быть уверенным, что текущие и зависимые транзакции завершились или были откачены до начала процесса захвата. Если экземпляр не перезапущен, то транзакции не завершены и будут лишь частично включены в данные захвата. "По умолчанию" при захвате рабочей нагрузки записываются все действия всех пользователей. Фильтры рабочей нагрузки могут исключить или наоборот включить сессии определенных пользователей в данные захвата. Можно использовать либо фильтры включения или исключения, но не оба типа одновременно. Фильтры включения описывают сессии, которые должны быть захвачены в рабочую нагрузку. Фильтры исключения указывают пользовательские сессии, которые не будут включены в данные захвата. Чтобы добавить фильтр к процедуре захвата нагрузки нужно использовать процедуру DBMS_WORKLOAD_CAPTURE.ADD_FILTER. Для удаления существующего фильтра нужно использовать процедуру DBMS_WORKLOAD_CAPTURE.DELETE_FILTER. Следует назначить однозначно определенную точку начала снятия рабочей нагрузки, так чтобы база данных, используемая для снятия нагрузки, могла быть восстановлена к той же самой точке перед началом снятия нагрузки. Желательно, чтобы в базе данных перед началом снятия нагрузки не было активных пользовательских сессий. Активные сессии могут иметь активные транзакции, которые не смогут быть воспроизведены полностью. Следует рассмотреть возможность перезапуска экземпляра в режиме RESTRICTED перед запуском процесса захвата. Когда начинается процесс захвата, база данных автоматически переключается UNRESTRICTED, и нормальные операции могут быть продолжены в момент начала захвата нагрузки. Процесс захвата начинается с помощью процедуры DBMS_WORKLOAD_CAPTURE.START_CAPTURE, остановить процесс захвата следует с помощью процедуры DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE.

184

При необходимости можно экспортировать данные AWR из продуктивной системы, чтобы было можно провести подробный анализ нагрузки на обеих системах. Эти данные нужны, если планируется выполнить сравнение периодов AWR для пары захватов загрузки или повторов выполнения. Для экспорта данных AWR используется процедура BMS_WORKLOAD_CAPTURE.EXPORT_AWR. Для контроля хода процесса захвата нагрузки можно использовать Oracle Enterprise Manager Cloud Control или следующие представления: DBA_WORKLOAD_CAPTURES - Содержит список всех захватов, созданных в базе данных. DBA_WORKLOAD_FILTERS - Содержит список всех фильтров, используемых для фильтрации нагрузки для данный базы данных. После завершения захвата нагрузки необходимо обработать файлы захвата для того, чтобы использовать их для воспроизведения нагрузки. Предварительная обработка преобразовывает захваченные данные в файлы повторного проигрывания и создает требуемые для проигрывания нагрузки метаданные. Захваченная рабочая нагрузка после обработки может быть многократно воспроизведена на любой системе с той же версией Oracle. В общем случае для обработки рекомендуется перенести захваченные файлы на другую систему. Хотя захват нагрузки имеет минимальную избыточную нагрузку на систему, но обработка его результатов может быть продолжительным по времени и ресурсоемким процессом. Лучше, если процесс обработки будет выполняться на системе, которую будут использовать для воспроизведения нагрузки, нежели на продуктивной. Файлы захвата обрабатываются при помощи процедуры DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE. После завершения обработки захваченной нагрузки полученные данные могут быть воспроизведены на тестовой системе. При воспроизведении Oracle выполнит все записанные во время захвата действия. Он воссоздаст все захваченные внешние запросы клиентов с теми же временными параметрами, степенью конкурентности и последовательностью транзакций, которые имели место на продуктивной системе. Утилита Database Replay использует программу клиентского повтора для воссоздания внешних запросов. В зависимости от объема захваченной нагрузки может возникнуть необходимость применения нескольких клиентов повтора. Клиент повтора имеет встроенное средство калибровки для определения требуемого количества клиентов для получения данной нагрузки. Проигрывается полная нагрузка, полученная в продуктивной базе, включая операции DML и запросы SQL, поэтому данные в системе, предназначенной для проигрывания, должны быть максимально логически близкими к системе, где проводился захват.

185

Применение ресурсного менеджера для управления распределением ресурсов Менеджер ресурсов Oracle Database Resource Manager (DRM) создан для оптимизации выделения ресурсов конкурирующим сессиям базы данных. Менеджер DRM попытается предотвратить проблемы, которые могут возникнуть, если операционная система принимает решение о выделении ресурсов, требующих больших издержек, не зная о потребностях базы данных. Менеджер DRM позволяет преодолеть эти проблемы путем предоставления базе данных большего контроля над выделением аппаратных ресурсов. Менеджер DRM дает возможность выделить группы сессий на основании их атрибутов и затем выделять ресурсы для групп так, чтобы оптимизировать использование оборудования для имеющегося программного окружения. Информация, реализующая функции разделения сессий и присвоения ресурсов, называется ресурсным планом. Oracle 12c содержит несколько настроенных ресурсных планов, обеспечивающих директивы управления ресурсами, которые смогут дать немедленную выгоду для основных типов установок баз данных: DEFAULT_MAINTENANCE_PLAN - План "по умолчанию" для окон обслуживания. DEFAULT_PLAN - Базисный план "по умолчанию", план отдает приоритет операциям SYS_GROUP и выделяет минимальные ресурсы для автоматизированного обслуживания и диагностики. DSS_PLAN - Пример плана для хранилища данных, план отдает приоритет критичным DSS запросам перед некритичными и операциями ETL. ETL_CRITICAL_PLAN - Пример плана для хранилища данных, план отдает приоритет операциям ETL перед запросами DSS. INTERNAL_QUIESCE - План для "заморозки" базы данных. План не может быть активирован напрямую. Для активации нужно использовать команду QUIESCE. MIXED_WORKLOAD_PLAN - Пример плана для смешанной нагрузки, план отдает приоритет интерактивным операциям перед пакетными операциями. Директивы ресурсного плана Директивы ресурсного плана для потребительских групп могут указывать предельные значения потребления для CPU или ввода/вывода для сессий в этой группе. Это ограничение реализуется путем задания действий, которые следует сделать, если какая-либо операция в сессии потребует больших ресурсов, нежели указано. Эти действия, называемые "переключателями", возникают только для выполняющихся и потребляющих ресурсы сессий, не ожидающих пользовательского ввода или циклов процессора. Возможны следующие действия: Сессия будет переключена в потребительскую группу с меньшими доступными ресурсами. Сессия будет прервана. Текущий SQL-оператор сессии будет прерван. Атрибут директивы ресурсного плана, определяющий тип выполняемого действия, называется SWITCH_GROUP. Этот атрибут определяет потребительскую группу, в которую будет переключена сессия при достижении требуемого значения. Если значением этого атрибута является потребительская группа, то сессия будет переключена в указанную группу. Если имя 186

группы"CANCEL_SQL", то выполнение текущего оператора SQL будет прервано. Наконец, если имя группы "KILL_SESSION", то сессия будет прервана. Ограничения сессий по вводу/выводу или потреблению циклов процессора Атрибуты директив ресурсного плана, используемые для задания условий переключения между потребительскими группами, приводятся ниже. "По умолчанию" все они установлены в значение UNLIMITED. SWITCH_TIME: Задает время (в секундах процессора), которое может выполняться вызов перед тем, как будет выполнено действие. SWITCH_IO_MEGABYTES: Задает объем ввода/вывода в мегабайтах, которое может быть записано/прочитано в сессии перед переключением. SWITCH_IO_REQS: Задает количество операций ввода/вывода, которое сессия может выполнить перед переключением. Имеется два атрибута ресурсного плана, которые можно использовать для изменения поведения переключения ресурсных планов: SWITCH_ESTIMATE: Если атрибут установлен в TRUE, то база данных оценивает время выполнения каждого вызова. Если оценка превысит SWITCH_TIME, то сессия будет переведена в заданную в SWITCH_GROUP группу до начала выполнения вызова. "По умолчанию" значение FALSE. SWITCH_FOR_CALL: Если атрибут установлен в TRUE, то сессия, переключенная автоматически в другую потребительскую групп, возвращается в исходную потребительскую группу после завершения вызова верхнего уровня. "По умолчанию" значение NULL.

187

Замечания по настройке производительности Эта тема вполне заслуживает отдельной монографии, а отнюдь не главы. Таких монографий существует невероятное количество, но всегда следует помнить, что в конечном итоге они не содержат окончательных рекомендаций по настройке именно определенной базы данных именно с конкретными приложениями для используемой операционной системы и оборудования. Самое главное, что можно извлечь из многочисленных книг независимых авторов и документации Oracle это общую методологию, как добиться приемлемого уровня производительности. Существует ряд простых советов, что нужно делать: Настраивайте БД только при наличии причин - До тех пор, пока не возникла проблема с производительностью, не стоит проводить настройку. До тех пор, пока проблема не возникла, не стоит пытаться ее решить. Это не значит, что администратор не должен проводить проактивный поиск проблем. Если был обнаружен SQL-запрос, потребляющий много ресурсов, то возможно(!) найдено узкое место. Работа по настройке такого запроса является прямой задачей администратора. Собирайте данные - Перед внесением любых изменений администратору следует применять средства, предлагаемые Oracle для сбора информации о проблемах производительности. Внесение изменений в отсутствие данных практически всегда является пустой тратой времени. Последние релизы базы данных получили значительный набор средств для сбора и анализа информации о наиболее общих причинах снижения производительности. Воспользуйтесь ими перед внесением изменений. Делайте последовательные изменения - Изменения нужно делать последовательно. Внесено изменение - сделан тест. При внесении нескольких изменений сложно, или вообще невозможно, сказать, какое из них стало причиной улучшения или ухудшения ситуации. Это особенно важно, если вносимые изменения имеют глобальное влияние на систему. Изменение, улучшающее производительность в коротком цикле тестирования, может вызвать общую деградацию производительности или другую проблему в более длительном периоде, что будет обнаружено после завершения тестирования. Например, обычной ловушкой является разительное улучшение скорости работы подсистем ввода данных и одновременная деградация подсистем, связанных с созданием отчетов. Остановитесь - Как только было установлено исправление для найденной проблемы производительности, нужно остановиться и не продолжать настройку. Хотя вы уже и начали настройку, не забывайте о первом правиле и не продолжайте ее в отсутствие проблемы. Наблюдайте - Администратор, очевидно, отслеживает производительность базы данных ежедневно. В дополнение к этим обязанностям необходимо следующие несколько дней после внесения изменений обратить дополнительное внимание на любые элементы базы данных, которые могут зависеть от внесенных изменений. Чем большие и широкие изменения были сделаны, тем дольше следует отслеживать поведение базы данных на предмет нежелательных последствий.

188

Дисковая память Управление объектами базы данных Часть базисных административных функций администратор БД может выполнить с помощью Oracle Enterprise Manager Express (EM Express). Используя web-интерфейс можно просматривать, создавать и изменять различные объекты размещения данных. После первичной регистрации в EM Express будет выведена следующая страница:

Рис. 33 Домашняя страница базы данных в EM Database Express

Вторая ссылка "Storage" открывает выпадающее меню для управления различными типами структур хранения базы данных Oracle. При выборе одного из элементов меню откроется один из следующих экранов.

189

Рис. 34 Управление объектами дисковой памяти

Табличные пространства (Tablespaces) С помощью функций этого экрана можно выполнять стандартные административные задачи по управлению табличными пространствами, включая создание, удаление, добавление файлов данных, изменение статуса (на "только чтение") и т.д.

Рис. 35 Управление табличными пространствами

Управление табличным пространством отката (Undo) Эта вкладка предназначена для отображения статистики использования пространства отката. Необходимость во втором пространстве undo встречается довольно редко, а единственное пространство не требует больших административных затрат. Этот экран полезен для проверки, что пространство отката имеет достаточный размер для текущей активности базы данных.

190

Рис. 36 Управление табличным пространством UNDO

Группы журналов повторов (Redo Log Groups) Как и экран табличных пространств, экран управления журналами повторов позволяет выполнить ряд административных действий с журналами повторов: создать, удалить, добавить новых членов и т.д. На экране отображается информация об активной группе журналов, завершении архивирования и т.д.

Рис. 37 Управление журнальными файлами повторов

Архивные журналы (Archive Logs) На экране приведена информация об архивированных журналах повторов.

191

Рис. 38 Управление архивными журналами

Управляющие файлы (Control Files) На экране выводятся данные об управляющих файлах базы данных. Единственной административной операцией является возможность создания резервной копии файла в формате трассировки.

Рис. 39 Управление управляющими файлами базы данных

Управляемые Oracle файлы Система Oracle Managed Files (OMF) предназначена для упрощения администрирования файлов базы данных. При использовании OMF администратор указывает директории файловой системы для файлов разных типов, после чего база данных автоматически создаст, назовет и будет управлять файлами на уровне объектов базы данных в указанных местах файловой системы. 192

Например, при создании табличного пространства в параметрах DATAFILE не нужно указывать путь и имя файла. Система OMF работает с менеджером логических томов (LVM), но не работает с "сырыми" устройствами. OMF можно использовать для создания и удаления при необходимости следующих объектов базы данных: Табличных пространств (Tablespaces). Журналов повторов (Redo log files). Управляющих файлов (Control files). Архивированных журналов (Archived logs). Файлов отслеживания изменений блоков (Block change tracking files). Ретроспективных журналов (Flashback logs). Резервных копий RMAN (RMAN backups). OMF не используется при создании или именовании административных файлов, как то, файлы трассировки, аудита, журналы оповещений (alert logs) и дампы памяти. Имеется три параметра инициализации, задающие директории для файлов разных типов. Указанные директории должны существовать, и на эти директории должны быть установлены разрешения, позволяющие базе данных создавать файлы. При использовании OMF Oracle проверяет уникальность создаваемого файла и удаляет файл при отсутствии необходимости в нем. При использовании OMF используются следующие параметры инициализации: DB_CREATE_FILE_DEST - Определяет путь "по умолчанию", где база данных будет создавать файлы данных или файлы временного табличного пространства. Этот же путь используется как место "по умолчанию" для создания журналов повторов и управляющих файлов, если не задан параметр DB_CREATE_ONLINE_LOG_DEST_n. DB_CREATE_ONLINE_LOG_DEST_n - Определяет расположение "по умолчанию" журналов повторов и управляющего файла. Меняя значение "n" можно мультиплексировать журналы повторов или управляющие файлы. Всего можно задать до пяти копий. DB_RECOVERY_FILE_DEST - Задает расположение области быстрого восстановления (Fast Recovery Area). Указанные путь будет использоваться как место "по умолчанию" для журналов повторов и управляющего файла или мультиплексированных копий файлов повторов и управляющих файлов, если не задан параметр DB_CREATE_ONLINE_LOG_DEST_n.

193

Администрирование ASM Система автоматического управления дисковой памятью Oracle (Automatic Storage Management, ASM) это решение Oracle, предназначенное для управления размещением файлов базы данных. Она работает как менеджер томов, создающий файловую систему, предназначенную исключительно для базы данных. При создании тома указывается режим зеркалирования (mirroring) или чередования (striping). При использовании технологии ASM, помимо обычной базы данных, существует специальный выделенный экземпляр ASM. Экземпляр Oracle ASM также использует возможности системы управляемых Oracle файлов (OMF). Файлы OMF создаются автоматически, имена им присваиваются без участия администратора. Система OMF также автоматически удаляет файлы, если табличные пространства или файлы были удалены в базе данных. Экземпляр ASM управляет дисковым пространством и распределением нагрузки ввода/вывода между дисками для оптимизации производительности. Система ASM дает следующие преимущества по сравнению с обычными файловыми системами: Упрощает операции по созданию баз данных и управлению дисковым пространством. Распределяет данные между несколькими дисками для обеспечения равномерной нагрузки. Автоматически проводит балансировку данных после внесения изменений конфигурации дисковой памяти. Экземпляр Oracle ASM использует ту же базисную технологию, как и БД Oracle. Область глобальной памяти SGA и фоновые процессы ASM экземпляра близки к аналогичным процессам самой базы данных. Область SGA экземпляра ASM значительно меньше, чем область SGA базы данных, и имеет меньшее количество внутренних компонент, так как ASM имеет меньшую функциональность. Единственной функцией экземпляра ASM является монтаж дисковых групп и обеспечение доступа к связанным с ними файлам базы данных со стороны экземпляров БД. Экземпляр ASM не выполняет монтаж/запуск экземпляров БД. Экземпляр Oracle ASM состоит из следующих логических элементов: Диски ASM (ASM Disks) - Устройство дисковой памяти, выделенное для создания дисковой группы ASM. Диск ASM это физический диск или его секция, логический диск (Logical Unit Number, LUN) дискового массива, логический том или устройство сетевой памяти. Дисковые группы ASM (ASM Disk Groups) - Набор дисков ASM, управляемый как одно логическое целое. Файлы ASM (ASM Files) - Файлы, хранимые в группе Oracle ASM группе. База данных может хранить файлы данных, управляющие файлы, текущие файлы повторов и некоторые другие типы файлов на файловой системе Oracle ASM. Экстенты ASM (ASM Extents) - Область, предназначенная для размещения содержимого файлов Oracle ASM, используются сырые устройства. Файл ASM состоит из одного или более экстента, экстент состоит из одного или более единиц размещения ASM. Единицы размещения ASM (ASM Allocation Units) - Базисная единица размещения или выделения памяти в дисковой группе.

194

Экземпляр ASM (ASM Instance) - Специализированный экземпляр Oracle, управляющий дисками Oracle ASM. Он управляют метаданными дисковой группы и сообщает расположение файлов данных экземпляру базы данных. Система Oracle ASM не поддерживает напрямую размещение некоторых типов административных файлов в дисковых группах, а именно файлов трассировки, файлов журналов оповещений, файлов экспорта и дампов ядра. Система Oracle ASM поддерживает основные типы файлов, нужные базе данных. В списке приводятся наиболее часто используемые типы файлов и шаблоны, описывающие атрибуты для их создания, которые могут быть размещены в ASM: Управляющие файлы / Control files - CONTROLFILE Файлы данных / Data files - DATAFILE Журналы повторов / Redo log files - ONLINELOG Архивные журналы / Archive log files - ARCHIVELOG Временные файлы / Temporary files - TEMPFILE Фрагменты резервных копий файлов данных / Data file backup pieces - BACKUPSET Фрагменты резервных копий файлов журналов / Archive log backup piece - BACKUPSET Файл параметров экземпляра / Server initialization parameter file (SPFILE) PARAMETERFILE Журналы ретроспективных повторов / Flashback logs - FLASHBACK Наборы утилиты DataPump / Data Pump dumpset - DUMPSET Полностью квалифицированная форма имен файлов Когда бы ни создавался файл в Oracle ASM, система Oracle Managed Files автоматически создает для него полностью квалифицированное имя. Полностью квалифицированное имя представляет собой полный путь в файловой системе Oracle ASM. Это имя можно использовать в операциях Oracle ASM, за исключением операции создания дисковой группы. Полностью квалифицированное имя имеет следующий вид: +diskgroup/dbname/filetype/filetypetag.file.incarnation , где: +diskgroup - Имя дисковой группы с предшествующим знаком "+". Знак "+" эквивалентен корневой директории файловой системы ASM. dbname - Значение параметра DB_UNIQUE_NAME базы данных, которой принадлежит файл. filetype - Тип файла Oracle. filetypetag - Специфичная для данного типа информация о файле. file.incarnation - Пара файл/инкарнация. Используется для гарантий уникальности. Пример полностью квалифицированного файла: +dg1/v11/controlfile/current.271.839783087 При запросе создания файла полностью квалифицированное имя не указывается. Имя задается в виде алиаса или имени дисковой группы, после чего система Oracle ASM создает файл в желаемом месте на основании типа файла. Затем система Oracle ASM присваивает подходящее 195

полностью квалифицированное имя. Если в запросе на создание файла указан алиас, то система Oracle ASM создает алиас и связывает его с полностью квалифицированным именем. За один запрос можно создавать один или несколько файлов. Алиасы имен файлов Алиасы имен файлов могут быть использованы для ссылки на существующие файлы и для создания новых файлов ASM. Алиас состоит из имени дисковой группы с лидирующим знаком "+" и имени файла. Алисы имен файлов используют иерархическую структуру директорий со знаками "\" или "/", разделяющими компоненты имени. Алиасы должны включать имя дисковой группы. Алиасы не могут существовать на уровне корня (+). Если файл создан с алиасом, то для доступа к нему можно использовать либо алиас, либо полное имя файла. Имена алиасов не могут оканчиваться на пару чисел, разделенных точкой. Примеры алиасов: +dg1/v11/control_file.bkp В примере приводится создание табличного пространства отката с файлом данных, расположенным в дисковой группе dg1 и имеющим алиас zz_2: SQL> CREATE UNDO TABLESPACE z_undo_2 DATAFILE '+dg1/z/zz_2' size 200m; В итоге будет создано табличное пространство с одним файлом, и этому файлу будет назначен алиас: ASMCMD> ls -l /dg1/z Type Redund Striped Time DATAFILE UNPROT COARSE FEB 03 14:00:00 +DG1/Z/DATAFILE/Z_UNDO_2.264.870704891 ASMCMD>

Sys N

Name zz_2 =>

Если при создании файла данных использовался алиас, то он не является файлом Oracle Managed Files (OMF), иначе говоря, при удалении табличного пространства, система OMF не удалит его, и это придется делать вручную. Для удаления вручную нужно использовать следующую команду SQL: SQL> ALTER DISKGROUP dg1 DROP FILE '+dg1/z/zz_2';

196

Управление дисками ASM и дисковыми группами Дисковая группа ASM состоит из нескольких дисков и является базовым объектом, которым управляет Oracle ASM. Дисковые группы содержат информацию, необходимую для управления дисковым пространством. Дисковая группа состоит из дисков, файлов и единиц размещения. Файл располагается внутри одной группы. Одна группа может содержать файлы разных баз данных. Одна база данных может использовать файлы из разных дисковых групп. Атрибуты дисковых групп Атрибуты дисковой группы представляют собой параметры, привязанные к дисковой группе, но не к экземпляру ASM. Некоторые из наиболее общих атрибутов приводятся ниже. Для получения полной информации следует обратиться к документу Oracle ASM Administrator's Guide. ACCESS_CONTROL.ENABLED - Атрибут определяет, включен ли контроль доступа (File Access Control) Oracle ASM для группы. Возможные значения true или false. "По умолчанию" FALSE. Атрибут может быть установлено только при изменении дисковой группы. ACCESS_CONTROL.UMASK - Атрибут определяет маскирование разрешений при создании файлов Oracle ASM для пользователей-владельцев файла, пользователей, входящих в группу владельца файла и остальных, не включенных в группу. Атрибут применяется ко всем файлам дисковой группы. AU_SIZE - Экстент файла состоит из одной или более единиц размещения. Файл Oracle ASM состоит из одного или более экстента. При создании дисковой группы можно задать размер единицы размещения с помощью параметра AU_SIZE. Допустимые значения 1, 2, 4, 8, 16, 32 или 64 MB, в зависимости от уровня совместимости группы. COMPATIBLE.ASM - Этот атрибут задает формат структур данных для метаданных ASM в дисковой группе. Версия ASM должна быть равна или выше, чем это значение, чтобы получить доступ к данной дисковой группе. Параметр COMPATIBLE.ASM всегда должен быть выше или равен COMPATIBLE.RDBMS для той же дисковой группы. Например, можно установить COMPATIBLE.ASM дисковой группы в 11.0, а COMPATIBLE.RDBMS - в 10.1. В этом случае дисковая группа может управляться только версией ASM 11.0 и выше. При этом любая база данных версии 10.1 или старше может использовать данную дисковую группу. При увеличении значений обоих этих параметров значение COMPATIBLE.ASM следует увеличивать первым. COMPATIBLE.RDBMS - Параметр задает формат сообщений, которыми обмениваются экземпляр ASM и экземпляр базы данных. Параметр задает минимальную версию клиентской базы данных, которая может использовать дисковую группу. Для разных дисковых групп в рамках одного экземпляра ASM можно задавать разные значения параметра в зависимости от версий клиентских БД. CONTENT.TYPE - Задает тип дисковой группы: data, recovery или system.Значение определяет "расстояние" до ближайшего соседнего диска в сбойной (failure) группе, куда Oracle ASM копирует данные при зеркалировании. Значением "по умолчанию" является "data", что определяет дистанцию 1 до ближайшего диска. Значение "recovery" задает дистанцию 3, а значение "system" задает значение 5.

197

DISK_REPAIR_TIME - Определяет продолжительность времени, которое диск может быть недоступен из-за временной неработоспособности перед тем, диск будет удален из дисковой группы. Чтобы функциональность можно было использовать, оба параметра COMPATIBLE.RDBMS и COMPATIBLE.ASM должны быть установлены 11.1 или выше. Параметр нельзя установить при создании дисковой группы, но можно модифицировать атрибут DISK_REPAIR_TIME при помощи команды ALTER DISKGROUP SET ATTRIBUTE. Если оба атрибута, COMPATIBLE.RDBMS и COMPATIBLE.ASM, установлены по крайней мере в 11.1, то значение "по умолчанию" равно 3.6 часа. Если любой из атрибутов меньше 11.1, то диск удаляется из группы немедленно после того, как он стал недоступным. Время может быть задано в минутах (M) или часах(H). Если задано неименованное значение, то считается, что заданы часы. Значение времени нахождения диска в состоянии offline "по умолчанию" может быть изменено с помощью конструкции DROP AFTER команды ALTER DISKGROUP DISK OFFLINE. Если диск переведен в состояние offline с использованием текущего значения DISK_REPAIR_TIME, а значение атрибута дисковой группы потом изменено с помощью оператора ALTER DISKGROUP SET ATTRIBUTE, то измененное значение будет использовано для определения момента удаления диска из группы. Создание дисковой группы Для создания дисковых групп используется оператор SQL CREATE DISKGROUP. При создании дисковой группы указывается следующая информация: Уникальное имя группы. Уровень избыточности дисковой группы. Для зеркалирования файлов средствами Oracle ASM нужно указывать уровень избыточности NORMAL REDUNDANCY (2-копии для большинства типов файлов) или HIGH REDUNDANCY (3-копии для всех типов файлов). Если нет необходимости зеркалирования средствами Oracle ASM, следует задать EXTERNAL REDUNDANCY. Список дисков, отформатированных как Oracle ASM диски, принадлежащих группе. Список дисков, принадлежащих специальной группе сбоев (необязательно). Тип группы сбоев (необязательно). Атрибуты дисковой группы, такие как уровень совместимости или размер единиц размещения (параметр является необязательным). В примере создается дисковая группа с именем DG1 с нормальной избыточностью. Она состоит из двух групп сбоя FG1 и FG2 с тремя дисками в каждой. Такой тип дисковой группы применим для размещения файлов базы данных: SQL> CREATE DISKGROUP DG1 NORMAL REDUNDANCY FAILGROUP FG1 DISK '/dev/rdsk/c6t6001438009B02AE90000400001910000d0s6' NAME diska1, '/dev/rdsk/c6t6001438009B02AE90000400001950000d0s6' NAME diska2, '/dev/rdsk/c6t6001438009B02AE90000400001970000d0s6' NAME diska3 FAILGROUP fg2 DISK '/dev/rdsk/c6t6001438009B02AE900003000015D0000d0s6' NAME diskb1, '/dev/rdsk/c6t6001438009B02AE90000300001610000d0s6' NAME diskb2, 198

'/dev/rdsk/c6t6001438009B02AE90000300001650000d0s6' NAME diskb3 ATTRIBUTE 'au_size'='2M', 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2'; Модификация дисковой группы Для изменения свойств дисковой группы применяется команда SQL ALTER DISKGROUP. С ее помощью можно добавить, удалить, изменить размер дисков при открытой базе данных. Совмещение нескольких операций в одной команде ALTER DISKGROUP возможно и рекомендуется. Группирование операций в одной команде ALTER DISKGROUP может снизить затраты на балансировку. Система Oracle ASM автоматически проводит балансировку дисковой группы после проведения изменений. Представление V$ASM_OPERATION позволяет отслеживать статут операции балансировки. В примере в существующую группу DG1 добавляются два новых диска: SQL> ALTER DISKGROUP data ADD DISK '/dev/rdsk/c6t6001438009B02AE90000400001990000d0s6' NAME diska4, '/dev/rdsk/c6t6001438009B02AE900004000019B0000d0s6' NAME diska5; Если в команде ALTER DISKGROUP для дисковой группы не задан параметр POWER, или балансировка проходит неявно из-за добавления/удаления диска, то параметр инициализации ASM_POWER_LIMIT определяет максимальную используемую вычислительную мощность. Значение параметра может быть изменено динамически. Более высокие значения приведет к снижению времени балансировки, но потребуют больше ресурсов ввода/вывода и процессорной мощности. Значение "по умолчанию", 1, минимизирует влияние балансировки на другие процессы и приложения.

199

Управление экземпляром ASM Запуск экземпляра ASM незначительно отличается от запуска обычного экземпляра базы данных Oracle. При запуске экземпляра ASM следует иметь в виду следующее: Нужно установить переменную окружения ORACLE_SID в соответствии с имеющимся Oracle ASM system identifier (SID). Значение "по умолчанию" это +ASM для одиночной инсталляции и +ASMnode_number для инсталляции RAC. Переменная окружения ORACLE_HOME должна быть установлена в дом Grid Infrastructure, т.е. туда, где установлено программное обеспечение Oracle ASM. Файл параметров должен содержать запись INSTANCE_TYPE=ASM, указывающую, что запускается экземпляр ASM. Команда STARTUP приводит к монтажу дисковых групп, а не к монтажу и открытию баз данных. Экземпляр ASM интерпретирует параметры команды STARTUP в SQL*Plus следующим образом: FORCE - Выдает команду SHUTDOWN ABORT экземпляру Oracle ASM перед тем, как запустить его. MOUNT или OPEN - Монтирует дисковые группы, указанные в параметре ASM_DISKGROUPS. Это параметр "по умолчанию". Режим "OPEN" для экземпляра ASM в реальности не существует. Если задан, то трактуется как MOUNT. NOMOUNT - Запускает экземпляр Oracle ASM, не монтируя какие-либо дисковые группы. RESTRICT - Запускает экземпляр в режиме ограниченной функциональности. Только пользователи, имеющие обе системные привилегии CREATE SESSION и RESTRICTED SESSION, могут установить соединение. Привилегии SYSASM операционной системы и OSASM группы операционной системы позволяют передать ответственность по управлению дисковой памятью системным администраторам без назначения высокоуровневого доступа к базе данных Oracle. Пользователи могут быть созданы для экземпляра ASM, и им могут быть выданы привилегии SYSASM. Это позволит им подключаться к экземпляру ASM и выполнять административные задачи. Аналогично, присвоение пользователю операционной системы группы OSASM даст ему возможность подключиться к экземпляру в качестве SYSASM с использованием аутентификации ОС. $ . oraenv ORACLE_SID = [] ? +ASM The Oracle base remains unchanged with value /u01/app/grid

$ sqlplus / as sysasm SQL> CREATE USER asm_admin IDENTIFIED by password1; User created.

SQL> GRANT SYSASM TO asm_admin; SQL> SQLPLUS /NOLOG SQL> CONNECT asm_admin AS SYSASM 200

Enter password: password1 Connected to an idle instance.

SQL> STARTUP ASM instance started Total System Global Area 71303168 bytes Fixed Size 1069292 bytes Variable Size 45068052 bytes ASM Cache 25165824 bytes ASM disk groups mounted

Остановка экземпляра ASM Остановка экземпляра ASM командой SHUTDOWN из SQL*Plus выполняется точно также, как и остановка обычной базы данных Oracle. Перед подключением к экземпляру ASM с помощью SQL*Plus следует убедиться, что переменная окружения ORACLE_SID указывает на ASM SID. Перед остановкой экземпляра ASM нужно остановить все экземпляры баз данных, использующих его. Перед выполнением остановки ASM также необходимо размонтировать все файловые системы, смонтированные на томах Oracle ASM Dynamic Volume Manager. Для остановки экземпляра ASM нужно выполнить следующие шаги: $ . oraenv ORACLE_SID = [] ? +ASM The Oracle base remains unchanged with value /u01/app/grid

$ sqlplus /nolog SQL> CONNECT asm_admin AS SYSASM Enter password: password1 Connected.

SQL>SHUTDOWN NORMAL; Допустимы следующие режимы команды SHUTDOWN экземпляра Oracle ASM: NORMAL - Экземпляр будет ждать завершения всех выполняющихся SQL операторов до размонтирования дисковых групп и остановки. Экземпляр также ждет завершения всех пользовательских сессий. Если какая-либо база данных подключена к экземпляру ASM, то команда SHUTDOWN завершается с ошибкой и не выполняется. NORMAL это режим "по умолчанию". IMMEDIATE или TRANSACTIONAL - Экземпляр будет ждать завершения всех выполняющихся SQL операторов до размонтирования дисковых групп и остановки. Экземпляр не ждет завершения сессий пользователей, подключенных нему. Если какаялибо база данных подключена к экземпляру, команда завершается в ошибкой и не выполняется. Параметры TRANSACTIONAL и IMMEDIATE эквиваленты, так как экземпляр ASM не имеет транзакций. ABORT - Экземпляр ASM останавливается без размонтирования дисковых групп. При последующем старте необходима процедура восстановления. Любые экземпляры баз 201

данных, использующие это ASM, также будут остановлены аварийно, поскольку их файлы данных станут недоступны.

202

Управление очень большими данными (VLDB) Общие замечания Понятия "большой" и "очень большой" крайне размыты и неопределенны. 100ГБ данных это много или мало? Это может быть всего лишь одно изображение с высокой степенью детализации, а может быть массивом из миллионов записей. В первом случае доступ к данным достаточно тривиален, хотя непросто просмотреть результат. Во втором случае отбор нужных данных может быть весьма непростой задачей, хотя отображение явно сложностей не вызовет. В случае БД обычно предполагают, что большая база данных это постоянно растущая база данных, таблицы которой содержат миллионы и более записей. Определение нестрогое, но понятное на интуитивном уровне. В эпоху молодости автора вместо слова "миллионы", говорили "сотни тысяч", но мощность процессоров и доступность памяти слегка сдвинули планку вверх. Управление размещением данных в Очень Больших Базах Данных чаще всего реализуется с помощью секционирования. Секционирование улучшает способность Oracle поддерживать очень большие таблицы, разделяя их на более мелкие и управляемые куски, называемые секциями или партициями. Секционированные таблицы упрощают настройку SQL запросов, позволяя SQL операторам избежать просмотра секций, не содержащих данных, при использовании "обрезания секций" (partition pruning). Секционирование также может упростить настройку SQL путем разбиения больших объединений сходно объединенных секционированных объектов при использовании секционных объединений. Секционирование таблиц и индексов идет рука об руку с параллелизмом запросов для увеличения производительности в хранилищах данных. Если объект базы данных секционирован, то возможно параллельное выполнения просмотра разных секций таблицы или индекса. Методы секционирования Существует три базовых метода, определяющих каким образом данные будут распределяться по секциям: диапазон (Range), хэш (Hash) и список (List). При секционировании с использованием этих методов можно разделить таблицы на секции на одном уровне или разделить ее на двух уровнях для композитного секционирования. Каждый из двух методов имеет преимущества и предпосылки для использования. Специфика данных в таблице определяет стратегию ее секционирования. Иначе говоря, прежде чем заниматься деление таблицы следует посмотреть, что там хранится! Одноуровневое секционирование При одноуровневом секционировании при определении таблицы применяется один из трех методов, при этом один или несколько столбцов таблицы используются в качестве ключей секционирования: Секционирование по диапазону (Range Partitioning) - В этом методе распределение данных по секциям основано на интервале значений ключа секционирования. Для каждой секции определен диапазон значений ключа, определяющий, какие записи попадут в секцию. Это наиболее частый тип секционирования, а в качестве ключа секционирования часто используются время. Секции создаются при помощи лексической конструкции VALUES LESS THAN, которая указывает не включаемую верхнюю границу секции. Строки, имеющие значение ключа секционирования равного или большего этой границы 203

помешаются в следующую, более "высокую", секцию. Нижняя граница секции фактически задается значением VALUES LESS THAN предыдущей секции. Первая секция не имеет нижней границы. Самая старшая секция может использовать параметр MAXVALUE. Это параметр представляет виртуальное бесконечное значение, используемое для сортировки записей со значением ключа, большим, чем любые возможные значения, включая NULL. Секционированию по хэш-коду (Hash Partitioning) - В этом методе для распределения данных по секциям используется алгоритм хэширования на основе указанного ключа. Хэширующий алгоритм спроектирован так, чтобы равномерно распределять записи между секциями. Этот метод является идеальным, если нужно распределить данные равномерно между разными устройствами. Он проще в реализации, нежели секционирование по диапазону. Хэш-секционирование особенно полезно, если данные не являются историческими или не имеют очевидного ключа секционирования. Секционирование по списку (List Partitioning) - Этот метод позволяет провести секционирование на основе списка дискретных значений ключа секционирования для каждой секции. Таким способом администратор может точно управлять помещением записей в секции. Секционирование по списку дает возможность сгруппировать неупорядоченный и несвязанный набор данных. При секционировании по списку секция DEFAULT обеспечивает хранение всех значений ключа, которые не отображены явно на другие секции. Композитное секционирование Эта стратегия совмещает базовые методы секционирования, описанные ранее. При композитном секционировании таблица делится на части, а затем каждая полученная секция делится на подсекции. Методы, использованные для секционирования на обоих уровнях, могут быть как одинаковыми, так и разными. Композитное секционирование может повысить уровень потенциального обрезания секций и обеспечить более точное размещение данных по секциям. Возможны следующие методы композитного секционирования: Секционирование диапазон-диапазон (Range-Range Partitioning). Секционирование диапазон-хэш (Range-Hash Partitioning). Секционирование диапазон-список (Range-List Partitioning). Секционирование список-диапазон (List-Range Partitioning). Секционирование список-хэш (List-Hash Partitioning). Секционирование список-список (List-List Partitioning).

204

Управление табличным пространством Самым первым и самым простым из шагов по эффективному управлению размещением объектов в табличном пространстве является использование локального управления. Локально управляемое табличное пространство использует битовые карты для отслеживания всей информации об экстентах. Локальное управление имеет несколько преимуществ по сравнению с традиционными табличными пространствами, которые хранят эту информацию в словаре данных: Операции размещения и удаления модифицируют только локально управляемые ресурсы, поэтому эти операции выполняются быстрее и параллельно, в результате чего улучшается производительность системы в целом. Локально управляемые временные табличные пространства не создают ни данных отката, ни данных повторов. При указании лексемы AUTOALLOCATE база данных автоматически выбирает подходящий размер экстента. Снижается частота обращений к словарю данных, снижая конкуренцию во времена высокой интенсивности обращений к таблицам. Нет необходимости в операциях слияния свободных экстентов. Любое табличное пространство, включая SYSTEM и SYSAUX, может быть локально управляемыми. Программный пакет DBMS_SPACE_ADMIN содержит набор специальных процедур для обслуживания локально управляемых табличных пространств. В синтаксисе команды создания локально управляемого табличного пространства CREATE TABLESPACE в конструкции EXTENT MANAGEMENT содержится ключевое слово LOCAL. Значением "по умолчанию" при создании постоянного табличного пространства является "EXTENT MANAGEMENT LOCAL AUTOALLOCATE". Указание этой конструкции является опционным, за исключением случая, когда не нужно использовать локальное управление или же требуется указать размещение типа UNIFORM. "По умолчанию" база данных управляет экстентами локально. Если нужно, чтобы в табличном пространстве использовались одинаковые экстенты определенного размера, то при его создании необходимо задать ключевое слово UNIFORM. Ниже приведены две идентичные по результатам команды создания табличного пространства: SQL> CREATE TABLESPACE ocp_1 DATAFILE '/u01/app/oracle/oradata/X/ocp_01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE; SQL> CREATE TABLESPACE ocpts DATAFILE '/u01/app/oracle/oradata/X/ocpts_01.dbf' SIZE 50M; Существует два метода, используемых базой данных Oracle, для управления сегментами в локально управляемом табличном пространстве. Ручное управление использует свободные списки для управления свободным пространством внутри сегмента, автоматическое - использует битовые карты. Автоматическое управление более эффективно и является выбором "по умолчанию" для всех новых постоянных локально управляемых табличных пространств. Можно явно включить автоматическое управление с помощью конструкции SEGMENT SPACE MANAGEMENT AUTO: 205

SQL> CREATE TABLESPACE ocp_1 DATAFILE '/u01/app/oracle/oradata/X/ocp_01.dbf' SIZE 50M EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO; Базовая компрессия таблиц (Basic Table Compression) Базовая компрессия таблиц (Basic Table Compression) является наиболее ограниченным из доступных методов сжатия данных. Базовая компрессия не применяет сжатие данных к операциям DML (INSERT / UPDATE), выполняемым в таблице. Данные сжимаются только при массовой загрузке в таблицу. Опция базовой компрессии включена в версию Database Enterprise Edition (EE) базы данных. Форматы сжатия на диске для базисной компрессии и для расширенной строковой компрессии (Advanced Row Compression) идентичны, поэтому технически возможна конвертация из базисной в расширенную строковую компрессию путем замены опции размещения для таблицы или секции. Расширенная строковая компрессия (Advanced Row Compression) Расширенная строковая компрессия (Advanced Row Compression) была представлена в версии 11g под названием табличное сжатие для OLTP (OLTP Table compression). Этот вид компрессии сжимает данные для всех типов операций с данными, включая обычные DML операции INSERT и UPDATE. Расширенная строковая компрессия снижает накладные расходы, вызванные операциями записи сжатых данных. Расширенная строковая компрессия является частью опции Advanced Compression. Алгоритм работы расширенного строкового сжатия основан на удалении дублирующихся значений внутри блока данных, в том числе в охватывающих несколько столбцов. Гибридное колоночное сжатие (Hybrid Columnar Compression) Технология гибридного колоночного сжатия (Hybrid Columnar Compression, HCC) представляет собой метод организации сжатия данных внутри набора блоков базы данных. Для использования HCC необходима поддержка со стороны файловой системы, на которой располагаются данные. В настоящий момент для технологии HCC требует наличие дисковой памяти Oracle - Exadata, Pillar Axiom или Sun ZFS Storage Appliance. В этом случае данные хранятся с использованием комбинации методов построкового и поколоночного сжатия. Данные, сжатые HCC, хранятся в логических конструкциях, называемых единицами сжатия (compression unit). При загрузке данных в таблицу с использованием HCC, значения столбцов для группы строк группируются вместе и сжимаются. После сжатия данных столбцов для набора строк полученный набор помещается в единицу сжатия. Поскольку данные столбца имеют один тип и сходные характеристики, то алгоритм сжатия становится более эффективным. По утверждениям разработчиков ожидаемая степень сжатия составляет от 6 до 15 раз в зависимости от типа данных. Таблицы, созданные в табличном пространстве со сжатием по методу HCC, будут использовать данный метод "по умолчанию". При необходимости можно создать несжатую таблицу и таблицу, использующую иной метод компрессии, указав опцию типа сжатия в команде создания таблицы CREATE TABLE. При изменении типа сжатия табличного пространства все вновь создаваемые таблицы будут использовать новый тип компрессии, но уже существующие сохранят старый тип.

206

Сжатие сегментов (Segment Shrink) Возможность сжатия сегментов дает возможность вернуть фрагментированное свободное пространство ниже высшей отметки использования (high watermark) в сегменте. Сжатие сегментов дает следующие возможности: Сжатие данных ведет к лучшему использованию кэша. При полном сканировании таблиц читается меньше блоков сжатых данные. Сжатие сегментов является операцией, проводимой оперативно и почти без прерываний текущей активности пользователей, иначе говоря, не взаимодействующей с операциями DML или запросами. Конкурирующие операции DML блокируются на короткое время в момент завершения операции сжатия, во время освобождения пространства. Индексы обслуживаются во время операции сжатия и остаются доступными после ее завершения. Для операции не требуется выделения дополнительного пространства. Сжатие сегментов возвращает неиспользуемое пространство и выше, и ниже высшей отметки использования. "По умолчанию" операция сжатия уменьшает сегмент, подстраивает отметку использования и освобождает неиспользуемое пространство. При сжатии сегментов требуется перемещать строки на новое место, поэтому перед началом операции требуется разрешить перемещение строк и запретить срабатывание любых триггеров, работающих на основе изменения rowid. Операции сжатия могут быть выполнены только для объектов в локально управляемых табличных пространствах с включенным механизмом автоматического управления размещения сегментов (ASSM). Внутри табличного пространства с ASSM могут быть динамически сжаты все типы сегментов за исключением следующих: IOT mapping tables Таблицы материализованных представлений на основе rowid Таблицы с функциональными индексами SECUREFILE LOB'ы Сжатые таблицы (Compressed tables) Запуск сжатия динамического сжатия сегментов Можно сжать сегменты таблиц, индексно-организованных таблиц, индексов, секций, подсекций или материализованных представлений. Эту операцию можно сделать с помощью команд ALTER TABLE, ALTER INDEX, ALTER MATERIALIZED VIEW и ALTER MATERIALIZED VIEW LOG с заданием операнда SHRINK SPACE. Существует два дополнительных операнда для управления поведением операции сжатия: COMPACT – В этом случае операция сжатия проводится в два этапа. Если указан это параметр, то база данных дефрагментирует пространство сегмента и сжимает строки таблицы, но не меняет значение отметки использования и не освобождает пространство. Можно выполнить операцию с операндом SHRINK SPACE без COMPACT во время нерабочего времени для завершения операции сжатия. CASCADE – Этот операнд расширяет действие команды сжатия сегментов на все зависимые сегменты объекта.

207

Примеры Выполняется сжатие таблицы и всех зависящих от нее сегментов: SQL> ALTER TABLE table_001 SHRINK SPACE CASCADE; Выполняется сжатие секции таблицы: SQL> ALTER TABLE partitioned_table_002 MODIFY PARTITION part_01 SHRINK SPACE;

208

Безопасность Тема огромная и очень важная. Тема, достойная отдельной и немалой книги, а отнюдь не главы. Автор это осознает, но целью данной книги является краткое описание обязанностей DBA, достаточное для прохождения соответствующего экзамена. Разработка и внедрение политики безопасности Политика безопасности для базы данных устанавливает методы защиты ее от случайного или намеренного повреждения. База данных Oracle имеет отличные средства для защиты от потери данных из-за аппаратных или других сбоев. Защита данных от внутренних сбоев и ошибок, вызванных уполномоченными пользователями или лицами, получившими доступ нелегально (например, путем получения полномочий легальных пользователей), является задачей администратора базы данных. Правильно построенные политики безопасности могут: Снизить возможности атакующего в получении доступа к базе данных. Минимизировать ущерб, который может быть нанесен на уровне пользователей. Обнаруживать попытки незаконного доступа к базе данной или данным ограниченного доступа. Существуют три области, требующие определения политики безопасности: пользователи, привилегии, аудит. Пользователи Перед тем, как пользователь мог подключиться к базе данных нужно, чтобы он был аутентифицирован с использованием допустимого, ранее определенного в базе данных, имени. В базе данных Oracle существует несколько способов проведения аутентификации пользователей. Наиболее общим является задание пароля. Начиная с версии 11g, пароли учетных записей пользователей являются регистрозависимыми "по умолчанию". Это поведение можно изменить, хотя Oracle рекомендует использовать регистрозависимые пароли. В версии 12c вместо одной введены две функции проверки сложности паролей: ORA12C_VERIFY_FUNCTION и ORA12C_STRONG_VERIFY_FUNCTION. Любая из них может быть использована, как в состоянии поставки, так и модифицирована в соответствии с требованиями безопасности. Производитель рекомендует произвести собственные настройки. "По умолчанию" функции проверки сложности выключены. Включение любой из этих функций значительно снизит возможности подбора паролей к базе данных. Привилегии и роли Сразу после аутентификации пользователя, т.е. после проверки, определен ли он в базе данных, пользователь получает все привилегии, выданные ему ранее. Хорошей практикой является назначение минимального количества привилегий, необходимого для выполнения служебных функций пользователя. Выдача избыточных привилегий не имеет положительного влияния и может скомпрометировать безопасность базы данных. К сожалению, для большинства администраторов привычно выдавать избыточные привилегии пользователям, чтобы последние могли выполнить желаемые действия и отстали от DBA, вместо того, чтобы потратить время и выдать только нужные привилегии. В идеале следует давать привилегии, без которых нельзя обойтись, нежели те, которые нужно или хочется получить! Пользователи базы данных могут получить права двумя способами: 209

Явно - привилегии выдаются напрямую пользователю. На основании ролей - привилегии присваиваются ролям. Роль в свою очередь присваивается пользователю. Роли упрощают и улучшают управление привилегиями. В идеале нужно создать в базе данных типовые роли для всех бизнес-процессов. Минимальный набор или требуемые привилегии затем должны быть присвоены ролям, а роли в свою очередь должны быть присвоены пользователям. При таком подходе минимизируется работа DBA по выдаче полномочий пользователям, и снижается риск выдачи им избыточных привилегий. Аудит Аудит позволяет администраторам базы данных отслеживать и записывать действия пользователей, включая действия самих DBA. Аудит позволяет отслеживать как действия для всей системы, так и действия с отдельным объектом базы данных. "По умолчанию" Oracle задает набор объединенных политик аудита, содержащий стандартные настройки аудита. При необходимости можно создать собственные объединенные политики. Пакет PL/SQL DBMS_FGA нужно применять для создания точных политик аудита, срабатывающих на уровне строк и значений данных, нежели объединенные политики аудита. Аудит может помочь выявить попытки уполномоченных пользователей превысить уровень своих привилегий как для получения доступа к данным, находящимся вне их полномочий, так и попыток повреждения базы данных. Аудит также полезен при обнаружении попыток нелегального доступа к базе данных.

210

Настройка и управление аудитом Встроенные в Oracle возможности позволяют отслеживать и сохранять выбранные действия пользователей базы данных. Аудит может быть основан как на действиях пользователей базы данных, так и внешних. Стандартный аудит может быть основан на индивидуальных действиях, например, операторах SQL, или при использовании специфических системных или объектных привилегий. Можно выполнять аудит успешных и неуспешных действий. Аудит должен быть включен и настроен для нужд данной базы. Записи аудита будут занесены либо в словарь данных или в файлы операционной системы. Аудит является эффективным средством для усиления внутреннего контроля. Обычно аудит используется для выполнения следующих задач: Отслеживать действия. Удерживать пользователей или злоумышленников от неподобающих действий. Расследовать подозрительные действия. Предупреждать аудитора о запрещенных действиях. Отслеживать и собирать данные об определенных действиях в базе данных. Выявлять проблемы с авторизацией или контролем доступа. Выполнять требования соответствия требованиям регулирующих органов. Стандартный аудит включается с помощью параметра инициализации AUDIT_TRAIL. Возможны следующие значения этого параметра: DB – Направляет записи аудита в журнал аудита базы данных, за исключением обязательных записей аудита и записей аудита пользователя SYS, которые всегда записываются в журнал аудита операционной системы. DB является значением "по умолчанию". DB, EXTENDED – Имеет такой же смысл, что и DB, но при этом также заполняется переменные SQL и текст SQL в формате CLOB-type в столбцы таблицы SYS.AUD$ вместе с оператором SQL, использованным при аудируемом действии (при наличии). OS – Направляет все записи аудита в файлы ОС. Параметр AUDIT_FILE_DEST задает местоположение файла. XML – Заносит записи аудита в формате XML. Значение XML AUDIT_TRAIL не влияет на системный журнал аудита. Эти записи всегда будут в простом текстовом формате. XML, EXTENDED – Поведение такое же, как и при AUDIT_TRAIL=XML, но вызывает включение текста SQL и значения переменных SQLв файлы аудита в формате XML операционной системы. NONE – Выключает стандартный аудит. Записи стандартного аудита заносятся в таблицу SYS.AUD$, а записи т.н. тонкого аудита заносятся в таблицу SYS.FGA_LOG$. Записи аудита могут быть удалены только пользователем с административными привилегиями. Действия администратора также должны аудироваться. Если значение параметра инициализации O7_DICTIONARY_ACCESSIBILITY установлен в FALSE ("по умолчанию"), то только пользователи с правами SYSDBA могут выполнять операции DML над SYS.AUD$ и SYS.FGA_LOG$. При наличии лицензий, конечно, для дальнейшего улучшения защиты данных быть применены такие продукты Oracle, как Database Vault иOracle Label Security. 211

Определенные операции с базой данных всегда записываются в файлы аудита, находящиеся в операционной системе. Прежде всего, это действия любого пользователя, зарегистрированного в базе с правами SYSDBA или SYSOPER. Это т.н. обязательный аудит, выполняющийся независимо от установок параметра AUDIT_TRAIL. "По умолчанию" файлы аудита в операционной системе находятся в директории $ORACLE_BASE/admin/$ORACLE_SID/adump и имеют расширение aud. Обязательный аудит отслеживает следующие операции Запуск базы данных. Регистрацию SYSDBA и SYSOPER. Останов базы данных. Каждая новая сессия пользователей с правами SYSDBA или SYSOPER записывается в отдельный файл. Следует периодически проверять содержимое этих файлов и удалять их, так как даже для слабонагруженной базы данных их количество может быть очень велико, до нескольких миллионов, что может сильно замедлять работу сервера. Тонкий аудит (Fine-grained auditing, FGA) расширяет возможности стандартного аудита. Тонкий аудит позволяет задать специфические условия, выполнение которых вызовет срабатывание событий аудита и запись в журнал. Это позволяет точно аудировать запросы и операции DML. Тогда как стандартный аудит может обнаружить выполнение SELECT на заданной таблице, тонкий аудит может выявить выполнение операции SELECT в определенное время, к определенному столбцу или определенному набору строк. Иначе говоря, тонкий аудит (Fine Grained Auditing) позволяет точнее задавать объект аудита с меньшим уровнем информационного "шума" из-за фальшивых срабатываний.

212

Создание файла паролей Файл паролей Oracle необходим для поддержки административных прав SYSDBA, SYSOPER, SYSBACKUP, SYSDG и SYSKM. Если файл потерян и поврежден, то он должен быть создан повторно с помощью утилиты командной строки orapwd. Когда создается новый файл паролей, утилита запрашивает пароль для SYS и заносит введенные данные в файл. Синтаксис команды: $ orapwd FILE=filename [ENTRIES=numusers] [FORCE={Y|N}] [IGNORECASE={Y|N}] Для всех аргументов команды запрещено использование пробелов вокруг знака "=". Описание аргументов команды: FILE --Имя создаваемого файла. Нужно задавать полный путь. Если задано только имя, то файл будет создан в текущей директории. ENTRIES - Максимальное количество записей (учетных записей), которое можно разместить в файле. Необязательный параметр. FORCE - Если Y, то существующий файл будет перезаписан. Необязательный параметр. IGNORECASE - Если Y, то пароли считаются регистронезависимыми. Необязательный параметр. FORMAT - Если это параметр равен 12 ("по умолчанию"), то утилита ORAPWD создает файл паролей в формате Oracle Database 12c. Формат 12c нужен для поддержки SYSBACKUP, SYSDG и SYSKM административных прав. При установке параметра в legacy утилита ORAPWD создает файл паролей с поддержкой только SYSDBA и SYSOPER привилегий. SYSBACKUP - При задании параметра в Y ORAPWD создает запись SYSBACKUPфайле паролей за запрашивает ввод пароля. SYSDG - При задании параметра в Y ORAPWD создает запись SYSDG файле паролей за запрашивает ввод пароля. SYSKM - При задании параметра в Y ORAPWD создает запись SYSKM файле паролей за запрашивает ввод пароля. При выполнении следующей команды будет создан файл паролей, позволяющий задать 40 привилегированных пользователей с разными паролями: $ orapwd FILE=/u01/app/oracle/product/12.1.0/dbhome_1/dbs/orapwX ENTRIES=40 Параметр инициализации REMOTE_LOGIN_PASSWORDFILE связан с файлом паролей. Этот параметр нужно установить в SHARED, EXCLUSIVE или NONE. При значении SHARED файл паролей может быть использован несколькими базами данных, но в таком режиме опознается только пользователь SYS, даже если другие пользователи определены. При значении EXCLUSIVE файл паролей может быть использован только одной базой данной, при этом поддерживаются несколько пользователей. Параметр инициализации REMOTE_LOGIN_PASSWORDFILE задает ражим работы с файлом паролей. Параметр может иметь следующие значения: none - База данных Oracle ведет себя так, как будто файла паролей не существует. Пользователь с правами SYS должен быть аутентифицирован операционной системой. 213

exclusive - Файл паролей может быть использован только одной базой данных. При использовании выделенного файла паролей можно добавлять, удалять и модифицировать пользователей, задавать пароли для SYS, SYSBACKUP, SYSDG и SYSKM с помощью команды ALTER USER. Значение "по умолчанию". shared - Файл паролей используется несколькими базами, запускаемыми на одном сервере одновременно, или несколькими экземплярами Oracle RAC. Разделяемый файл паролей является "read-only" и не может быть модифицирован. Таким образом, невозможно добавлять пользователей. Все пользователи, которые должны быть в файле паролей, нужно добавить в файл паролей, когда REMOTE_LOGIN_PASSWORDFILE установлен в "exclusive", а затем значение может быть заменено на "shared".

214

Шифрование столбцов и табличных пространств Для шифрования столбцов и табличных пространств используется опция Oracle Transparent Data Encryption (TDE). Перед началом использования TDE нужно создать программное хранилище ключей, т.е. контейнер, хранящий мастер-ключ для шифрования TDE. На каждую базу данных должно быть одно хранилище ключей, и база данных находит это хранилище, проверяя местоположение ее в файле sqlnet.ora или в пути $ORACLE_BASE/admin/$ORACLE_SID/wallet. В примере приведена последовательность создания шифрованного табличного пространства для базы данных X. $ mkdir $ORACLE_BASE/admin/$ORACLE_SID/wallet $ sqlplus / as sysdba (Возможно выполнение операций, как пользователь SYSKM или SYSTEM). SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "oracle"; System altered.

Цветом выделен мастер-ключ. Он является регистрозависимым, использование двойных кавычек является обязательным. После выполнения команды хранилище ключа создано, открыто и расположено в директории: SQL> ! ls $ORACLE_BASE/admin/$ORACLE_SID/wallet/ewallet.p12 /u01/app/oracle/admin/X/wallet/ewallet.p12

SQL> CREATE TABLESPACE s2 DATAFILE '/u01/app/oracle/oradata/X/s2.dbf' SIZE 150M ENCRYPTION USING '3DES168' DEFAULT STORAGE (ENCRYPT); Tablespace created.

SQL> SELECT TABLESPACE_NAME, ENCRYPTED, STATUS FROM dba_tablespaces; TABLESPACE_NAME -----------------------------SYSTEM SYSAUX UNDOTBS1 TEMP USERS S2

ENC --NO NO NO NO NO YES

STATUS --------ONLINE ONLINE ONLINE ONLINE ONLINE ONLINE

SQL> ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTOFIED BY "oracle"; System altered.

Расположение хранилища мастер-ключа также может быть задано параметром ENCRYPTION_WALLET_LOCATION в файле $ORACLE_HOME/network/admin/sqlnet.ora. В этом случае хранилище может быть доступно для нескольких экземпляров одновременно. ENCRYPTION_WALLET_LOCATION = (SOURCE=(METHOD=FILE)

215

(METHOD_DATA= (DIRECTORY=/u01/app/oracle/product/12.1.0/dbhome_1/network/admin/$ORACLE_SID) ) )

После создания хранилище следует установить правильные полномочия доступа к нему. Рекомендуется установить следующие полномочия: $ chown -R oracle:oinstall $ORACLE_BASE/admin/$ORACLE_SID/wallet $ chmod -R 700 $ORACLE_BASE/admin/$ORACLE_SID/wallet $ chmod 600 $ORACLE_BASE/admin/$ORACLE_SID/wallet/ewallet.p12 и при наличии возможностей задать бит, блокирующий случайное удаление хранилища мастерключа любым пользователем, включая администратора. Для файловой системы ZFS в Solaris 11 бит устанавливается командой $ chmod S+ci ewallet.p12 и снимается командой $ chmod S-ci ewallet.p12. Для получения детальной информации о настройке хранилища следует обратиться к документу Oracle 12c Advanced Security Guide. В ранних релизах программное хранилище называлось Oracle Wallet. Программное хранилище должно быть открыто перед тем, как будет предпринята попытка создать шифрованный столбец или табличное пространство, а также перед занесением или извлечением шифрованных данных. Если хранилище открыто, то оно доступно всем сессиям, и остается открытым до того, как будет явно закрыто или до остановки базы данных. Технология Oracle Transparent Data Encryption (TDE) поддерживает индустриальные стандартные алгоритмы шифрования, включая 3DES168, AES128, AES192, AES256. Длина используемого ключа соответствует имени алгоритма, т.е. алгоритм AES128 использует 128-битный ключ. Используемый алгоритм указывается при создании шифрованного столбца или табличного пространства. При необходимости для каждого столбца или табличного пространства можно выбрать свой алгоритм, не существует требования использовать общий алгоритм для экземпляра. Хотя более длинные ключи теоретически предполагают более высокую стойкость и безопасность, но их использование ведет к повышению нагрузки на процессор. По умолчания TDE использует алгоритм шифрования AES с длиной ключа 192 (AES192). TDE добавляет произвольную текстовую константу (salt) к простым текстовым данным перед шифрованием, чтобы усложнить расшифровку данных путем перебора паролей. Для проверки целостности TDE также добавляет код аутентификации сообщений (Message Authentication Code, MAC) к данным. "По умолчанию" для проверки целостности используется алгоритм SHA-1.

216

Шифрование столбцов Шифрование столбцов реализует функциональность шифрования и расшифровки данных на уровне SQL. Любая утилита или опция Oracle, обходящая уровень SQL, не может использовать сервисы, обеспечиваемые TDE. Шифрование столбцов с использованием TDE не следует использовать со следующими объектами/функциями базы данных: Индексы, отличные от B-tree. Интервальный поиск с использованием индекса. Синхронный захват изменений данных. Переносимые табличные пространства. Также невозможно применение TDE для шифрования столбцов, используемых в качестве внешних ограничений ссылочной целостности. При необходимости шифрования столбцов, использующих неподдерживаемые возможности, следует воспользоваться пакетом DBMS_CRYPTO. Столбцы типов BINARY_DOUBLE, BINARY_FLOAT, CHAR, DATE, INTERVAL DAY TO SECOND, INTERVAL YEAR TO MONTH, NCHAR, NUMBER, NVARCHAR2, RAW, TIMESTAMP, VARCHAR2 можно шифровать. Символьные типы данных имеют ограничения по размеру, для получения деталей следует обратиться к документу Advanced Security Guide. В примере приводится команда создания новой таблицы, содержащие шифрованный столбец SALARY с применением алгоритма шифрования "по умолчанию" (AES192). SQL> CREATE TABLE employee (emp_id NUMBER, first_name VARCHAR2(128), last_name VARCHAR2(128),salary NUMBER ENCRYPT); Если нужно проиндексировать зашифрованный столбец, то он должен быть зашифрован без применения текстовой константы (salt). В примере приводится команда создания аналогичной выше таблицы, содержащие шифрованные столбцы EMP_ID без константы и SALARY с применением алгоритма шифрования AES256. SQL> CREATE TABLE employee (emp_id NUMBER ENCRYPT NO SALT, first_name VARCHAR2(128), last_name VARCHAR2(128),salary NUMBER ENCRYPT USING 'AES256'); С помощью команды ALTER TABLE ADD можно добавить шифрованный столбец к существующей таблице: SQL> ALTER TABLE employee ADD (ssn VARCHAR2(11) ENCRYPT); С помощью команды ALTER TABLE MODIFY можно зашифровать существующий столбец: SQL> ALTER TABLE employee MODIFY (last_name ENCRYPT); Шифрование табличных пространств Для защиты важных данных любое постоянное табличное пространство может быть зашифровано. Шифрование табличного пространства прозрачно для базы данных, пользователей и приложений. Если табличное пространство зашифровано, то все его блоки зашифрованы. Все типы сегментов поддерживают шифрацию, включая таблицы, индексы, кластеры, LOB'ы, секции таблиц и 217

индексов и т.п. Чтобы усилить безопасность данные из шифрованных табличных пространств автоматически шифруются при записи в пространство отката, журналы повторов и любое временное табличное пространство. Шифрование не требует дополнительного места на дисках. При использовании шифрованных пространств существует ряд ограничений: Нельзя зашифровать существующее пространство с помощью команды ALTER TABLESPACE. Существует ограничения при переносе шифрованных пространств с помощью технологии переносимых табличных пространств (Transportable Tablespace). При восстановлении базы данных с шифрованными пространствами нужно открыть хранилище ключей после монтажа базы данных и до ее открытия, чтобы процесс восстановления мог расшифровать блоки данных и журналов повторов. Следующая команда создает шифрованное табличное пространство с использованием алгоритма шифрования "по умолчанию": SQL> CREATE TABLESPACE secure_ts_01 DATAFILE '/u01/app/oracle/oradata/X/ocp_secure01.dbf' SIZE 100M ENCRYPTION DEFAULT STORAGE(ENCRYPT);

218

Словарь Хотя на русском языке издано достаточно документации по СУБД Oracle, часть терминологии не имеет признаваемого всем информационным сообществом перевода на русский язык. Автор считает необходимым привести используемые англоязычные термины и используемый перевод. В тексте книги там, где это было необходимо, наряду с русскими терминами использовались их английские эквиваленты. Краткий термин (англ.)

Полный термин (англ.)

Русский перевод термина

archivelog flashback Fast recovery area redo log

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

patch

partition Queryable Patch Inventory Software Library undo undo tablespace ADO ADR ASH CBD DBCA DBA

Automatic Data Optimization Automatic Diagnostic Repository Active Session History Container DataBase Database Create Assistant Database administrator

FDA FGA ILM PITR PDB OUI VLDB

Flashback Data Archive Fine-grained auditing Information Lifecycle Management Point-in-time recovery Pluggable DataBase Oracle Universal Installer Very Large Database

219