Февраль 2005
Профессионалу администратору
Аруп Нанда
Oracle Database 10g:
20 наиболее привлекательных для АБД возможностей
(Oracle Database 10g: The Top 20 Features for DBAs
by Arup Nanda)
Часть V
Источник: журнал Oracle Magazine,
OTN Technical Articles ( http://www.oracle.com/oramag/webcolumns/windex.html),
http://otn.oracle.com/pub/articles/10gdba/index.html
В течение 20 недель Arup Nanda, “Лучший АБД 2003 года” по версии журнала Oracle Magazine, рассказывал о наиболее, по его мнению, привлекательных для администраторов баз данных возможностях Oracle Database 10g.
[От редакции OM/RE: мы продолжаем публикацию переводов этих заметно окрашенных индивидуальной авторской
интонацией небольших по объему заметок, но удивительно емких по содержаниею и точных по существу рассматриваемых вопроcов.
В каждом выпуске журнала предполагается по две-четыре “недели” от Arup Nanda. В этот раз мы предлагаем
вниманию читателей
"Неделю 13" и "Неделю 14".]
План публикаций
Неделя 13
Утилита Enterprise Manager 10g
(Enterprise Manager 10g)
Наконец-то я представляю универсальный (one-stop-shop – един во всех лицах) для новичков ли или для экспертов инструмент администрирования и управления Oracle.
На недавней встрече с группой пользователей я спросил: “Какой инструмент Вы используете в своей повседневной АБД-деятельности?” Ответы разнились в зависимости от опыта работы в качестве администраторов баз данных. Большинство искушенных администраторов выразили предпочтение простому интерфейсу командной строки SQL*Plus (это и мое личное предпочтение), разделяя с остальными доверие к горстке изделий третьих фирм. Однако, среди АБД начального уровня (entry-level) ответ на тот же самый вопрос был совершенно другой. Их очевидным инструментальным выбором был Enterprise Manager (EM).
Не трудно понять это предпочтение. Со времени ее введения несколько лет назад, утилита Oracle Enterprise Manager последовательно совершенствовалась, начав с символьного режима, соответствующего утилите SQL*DBA, развившись в клиентский инструмент, зависящий от OS и, наконец, превратлась в Java-продукт. Информация, представляемая EM, была достаточно детализирована для решения большинства задач администрирования для тех пользователей, которые были или не слишком охочи, или слишком заняты, чтобы изучать новый синтаксис, но желали иметь графический (GUI) интерфейс для того, чтобы выполнять обычные рутинные операции (chores) базы данных, как-то: добавление пользователей, изменение файлов данных,проверка сегментов отката. Пакет диагностики (diagnostic pack) предоставлял всю необходимую GUI-поддержку для настройки производительности.
Однако, одной из главных проблем, препятствующих широко распространению EM, была ее неспособность сохранить темп с развитием сервера базы данных непосредственно. Например, версия EM для базы данных Oracle9i не поддерживает разделение на подсекции (subpartitioning) - возможность, введенную еще в Oracle8i.
В Oracle Database 10g новая версия EM изменила эту ситуацию. Она имеет новую архитектуру, новый интерфейс и, что наиболее важно, очень мощный и совершенный инструментарий, пригодный всему сообществу АБД - от новичков до продвинутых пользователей. И лучшее из всего то, что без каких-либо дополнительных издержек ЕМ стала непосредственным шагом инсталляции. Конечно, если Вы испытываете инструментальные средства третьих фирм, то можно отменить соединение с EM, чтобы не препятствовать соревнованию. Даже если Ваше (подобно мне) АБД-кредо: "in-command-line-we-trust" (“в командной строке наша правда” - [прим.ред.- вспомним знаменитое “In God we trust!”]), Вы весьма оцените, как EM сможет помочь Вам во многих ситуациях.
В этой статье я представлю Вам новый EM. Но поскольку этот инструмент настолько широк по своим возможностям, то невозможно охватить их полный спектр; вместо этого, я объясню несколько основных свойств и предложу указатели на дополнительный материал. Следуя духу всех статей всей серии, я приведу практические примеры, которые продемонстрируют использование инструмента для решения проблем, взятых из реальной жизни.
Архитектура
EM 10g устанавливается по умолчанию, когда инсталлируется программное обеспечение 10g. Это от предыдущих версий концептуально отличается в том, что вместо инсталлируемого клиентского инструмента, EM 10g фактически представляет собой HTTP-сервер (называемый DB Console – “Консоль Базы Данных”), находящийся непосредственно на сервере базы данных. (См. Рисунок 1.) Можно использовать любой браузер, чтобы увидеть EM-интерфейс.
Рисунок 1: Архитектура EM
Номер порта для DB Console находится в файле $ORACLE_HOME/install/portlist.ini. Приведем пример этого файла; номер порта в Вашем случае, конечно, может быть иным.
Ultra Search HTTP port number = 5620
iSQL*Plus HTTP port number = 5560
Enterprise Manager Agent Port =
Enterprise Manager Console HTTP Port (starz10) = 5500
Enterprise Manager Agent Port (starz10) = 1830
Из этого текста мы узнаем, что Agent (Агент) базы данных starz10 слушает порт 1830, а EM-консоль слушает 5500. Мы можем активизировать EM-экран доступа (logon screen), введя следующий URL:
http://starz/em/console/logon/logon
Этот URL открывает экран входа в систему, и Вы можете войти, как пользователь DBA. В нашем примере мы войдем как SYS.
Главная домашняя страница базы данных
После входа в систему открывается главная домашняя страница базы данных (Main Database Home Page). В заглавной части домашней страницы приведены важные подробности, чтобы их сразу увидеть. (См. Рисунок 2.)
Рисунок 2: Главная домашняя страница базы данных (Верхняя часть)
Пройдемся по некоторым самым важным точкам, показанным на этом рисунке,
и соотнесем их с пронумерованными ссылками в этой статье.
Сначала обратим внимание на раздел, обозначенный "General" (1); этот раздел показывает некоторые самые рудиментарные (rudimentary) сведения о базе данных, как-то: база данных с именем, совпадающим с именем экземпляра, была поднята 20 марта. [Директория] Oracle Home показана в виде гиперссылки (hyperlink), если кликнуть по которой, то показываются все программы и все другие базы данных Oracle, которые совместно используют этот Oracle Home. Гиперссылка процессов прослушивания (Listeners) показывает все базы данных и экземпляры, обслуживаемые тем процессом прослушивания сети, имя которого приведено непосредственно ниже. Наконец, она показывает имя хоста (starz).
В разделе с названием "Host CPU" (“Хост CPU”) (2) сразу приводятся характеристики CPU. Раздел "Active Sessions" ("Активные Сессии") (3) показывает активные сессии и что они делают в настоящее время (4). Мы видим, что 99 % времени сессии находятся в состоянии ожидания. (Мы позже найдем причину их ождания.) Раздел "High Availability" ("Высокая Готовность") (5) приводит данные, связанные с готовностью. Например, параметр "Instance Recovery Time" ("Время Восстановления Экземпляра") приводит значение MTTR (mean time to repair - средняя наработка до ремонта – словарь Lingvo) указанного экземпляра, что определяет, сколько времени может потребоваться восстановления экземпляра после аварийного отказа.
Интересен раздел "Space Usage" ("Использование Пространства") (6): он показывает предупреждения по 23 сегментам. (Опять же об этих предупреждениях я расскажу позже.) Раздел "Diagnostic Summary" ("Суммарная Диагностика") (7) предоставляет краткий обзор работающей базы данных. Число обнаруженных операций показывает, сколько спорных вопросов было на самом деле идентифицировано Automatic Database Diagnostic Monitor (ADDM - Автоматический Монитор Диагностики Базы данных), новым механизмом самодиагностики в 10g. Также EM автоматически анализирует вычислительную среду, чтобы определить, не нарушаются ли какие-либо рекомендации по оптимальному функционированию; результат этого анализа представлен в разделе "Policy Violation" (“Нарушения Поведения”). Наконец, EM просматривает сигнальный (alert) журнал и показывает любые недавно случившиеся ошибки ORA-. Эта информация неоценима – автоматическое сканирование ошибок Oracle в сигнальном журнале избавляет Вас от скущественных неудобств, связанных с их ручным поиском.
В нижней части домашней страницы базы данных (database home page), показанной на рисунке 3, мы видим некоторые из этих сообщений более подробно. Раздел "Alerts" ("Сигналы") (1) показывает все соответствуюшие предупреждения, которые требуют вашего внимания, каждое из которых может быть легко отконфигурировано. Возьмем, например, первое [предупреждение] (2), которое показывает, что процесс Archiver (Архиватор) по каким-то причинам зависает. Конечно, следующим действием нужно определить почему. Чтобы узнать это, надо только кликнуть по нему. Вам будет показано много подробностей из файла alert.log, содержащего [сообщение] об ошибке. В этом случае виновником (culprit) стала переполненная область ретроспективного восстановления (flashback recovery area); нам нужно только почистить ее, и процесс Archiver сможет начать работать снова.
Рисунок 3: Главная Домашняя страница Базы данных (Нижняя часть)
Другой сигнал (3) – это ожидание: база данных теряет 69% времени в связи с ожиданием, связанного с классом ожидания "Application" ("Приложение"). Помните, что верхняя часть домашней страницы показывало, что сессия ждет? Этот сигнал показывает нам, что она ждет. Кликнем по гиперссылке и немедленно увидим, что Вы фактически ждете.
Следующий сигнал (4) показывает аудит-сообщение о том, что пользователь SYS связался с базой данных с некоей клиентской машины. Снова нажимая по гиперсссылке можно получить все подробности об этом подключении. Последнее предупреждение (5) показывает, что некоторые объекты инвалидны. Кликнув по гиперссылке, Вы получите экран, где инвалидные (invalid) объекты стали правильными (validated).
Как Вы видите, домашняя страница базы данных служит приборной панелью для всего, что заслуживает внимания. Исключая загромождение экрана детальной информацией, интерфейс был сделан весьма кратким с тем, чтобы детали появлялись только по щелчку. Вы можете получить всю эту информацию вручную, но для этого потребоваться много времени и усилий. EM 10g обеспечивает решение out-of-the-box ("как из ящика").
Общее Применение
Давайте посмотрим, как в новом EМ решаются некоторые более общие задачи.
Одна из таких задач состоит в том, чтобы изменить таблицу и ей принадлежащие индексы. На домашней странице базы данных, как показано в рисунке 3, выберите закладку "Administration" (“Администрирование”) и сошлитесь на пункт 6. С этой страницы Вы можете управлять базой данных, конфигурировать сегменты отката, создать табличные пространства и схемные объекты, поднимать менеджеры ресурсов, использовать новый Scheduler (Планировщик) – о чем будет рассказано в следующей статье, и так далее. Выберите там [пункт] "Tables" (“Таблицы”), что предъявит Вам экран, показанный на рисунке 4.
Рисунок 4: Управление Таблицами
Обратите внимание на символ прожектора, подсвеченный в красном круге; это – кнопка, чтобы получить список значений. На показанном на рисунке экране можно кликнуть по символу LOV, чтобы получить список пользователей в базе данных и выбрать одного из них. Кликом по кнопке "Go" (“Идти”) поднимается список таблиц для этого пользователя. Можно определить знак подстановки (wildcard), например "%", чтобы поднять все таблицы со словом TRANS в имени, используя шаблон %TRANS %.
Давайте рассмотрим пример. Выберем таблицу TRANS, чтобы изменить в ней некий столбец. Щелчок по гиперссылке поднимает "экран "Edit Table" "Редактирование Таблицы", как показано на рисунке 5.
Рисунок 5: Администрирование Таблиц
Если надо изменить формат столбца ACTUAL_RATE с NUMBER(10) на NUMBER(11), достаточно изменить число (Ref 1) и кликнуть "Apply" (“Применить”). Чтобы увидеть используемое SQL-предложение, надо кликнуть по кнопке "Show SQL" ("Показ SQL").
Другая важная часть информации, которая доступна на том же экране, это тенденция роста. Поскольку в следующей статье этой серии речь пойдет об управлении сегментами, стоит понаблюдать рост объекта с течением времени. Этот экран дает ту же самую информацию, но в графическим виде. Чтобы увидеть этот экран, щелкните по закладке “Segments” (“Сегменты”) (Рисунок 5 Ref 2). Вы увидите экран сегментов, как показано на рисунке 6.
Рисунок 6: Экран Сегментов
Обратите внимание на элементы, отмеченные в красных кругах. Экран показывает, как сколько пространства [дисковой памяти] распределено сегменту (2), сколько используется фактически (1) и сколько потрачено впустую (3). Внизу экрана (4) Вы можете видеть диаграмму (graph – граф) используемого и распределенного для объекта пространства. В этом примере используемость таблицы была постоянной, следовательно, на графике - прямая строка.
На таблице можно выполнить и другие административные операции, используя для той цели закладки, например, "Constraints" ("Ограничения") для управления ограничениями целостности.
Настройка производительности с использованием EM
Сколь много бы Вы ни узнали до этого момента и даже, если Ваше впечатление от EM изменились, это не предлагает таких уж больших функциональных возможностей, по сравнению с предыдущей Java-версией. Однако, в отличие от нее EM теперь поддерживает и новые функциональные возможности Oracle Database. Например, EM может теперь обрабатывать подсекции (subpartitions).
Однако опытные администраторы базы данных захотят получить больше от такого инструмента, особенно в проблемах поиска и локализации неисправностей или по части действенной настройки производительности. Продолжим рассматривать пример. Вернемся к предыдущему разделу, где мы узнали, что наша база данных стоит на классе ожиданий "Application" ("Приложение"), как показано на домашней странице базы данных (рисунок 3 Ref 3). И мы должны диагностировать причину. Одной из ключевых задач в понимании любого процесса настройки является то, как взаимодействуют различные компоненты: CPU, диск, хост-подсистемы, чтобы это помогло рассмотреть все эти переменные вместе, в контексте. Чтобы сделать это, выберите закладку "Performance" (“Производительность”) на домашней страницы базы данных. Это поднимает экран, который показан на рисунке 7.
Рисунок 7: Закладка "Performance" (“Производительность”)
Обратите внимание, как выравнены все метрики на одном и том же самом графике по времени, что упрощает рассмотрение их взаимозависимостей. Обратите внимание на всплеск (spike) (3), который соответствует задаче Scheduler (Планировщика). Это показывает, что в это время примерно семь сессий находились в состоянии ожидания, связанного с ожиданием Планировщика. Так, что же случилось? Обратите внимание на метрики CPU, расположенные в том же самом месте (зеленая область), - они показывают максимальное когда-либо использование центрального процессора, как показано на диаграмме прерывистой линией (4). До и после этой точки мы не видим, чтобы встречались всплески использования CPU, что дает нам путеводную нить. Обратите внимание, что всплеск использования CPU связан с длиной очереди (1), что является прямым результатом деятельности Scheduler (Планировщика), который, возможно, сгенерировал чрезмерные требования к объему оперативной памяти (memory), вызвав повышенную активность пейджинга (paging activity) (2). Как Вы можете видеть, все симптомы линейно падают, что позволдяет лучше понять "profile" ("профиль") загрузки базы данных.
Обратите внимание на всплески в конце графика времени для Run Queue Length (Длина Очереди Выполнения) (5) и Paging Rate (Интенсивность Пейджинга) (6), которые коррелируют с другим всплеском на оси Physical Reads (Физические Чтения) (7). В чем причина?
Анализируя график "Sessions: Waiting and Working" ("Сессии: Ожидание и Работа"), по времени когда встречались всплески, мы можем видеть, что большинство сессий ожидало класс ожиданий "Application". Но нам нржно точно узнать, что оно ожидало в течение этого периода времени. Кликнув по области этого периода, нам открывается экран Active Sessions (Активные Сессии), как показано на рисунке 8.
Рисунок 8: Ожидания Активных Сессий
Экран показывает, что сессии находились в состоянии ожидания события enq: TX – row lock contention. Тогда какое же SQL-предложение вызвало это? Очень просто: непосредственно на экране (в красном круге) показан ID (идентификатор) 8rkquk6u9fmd0 SQL-предложения. Кликнув по SQL ID, мы увидим SQL-экран, показанный на рисунке 9.
Рисунок 9: Детализация SQL
На этом экране можно увидеть SQL-предложение и соответствующие подробности, включая план выполнения. Оказывается, что это SQL-предложение вызывало заблокированную строку, так что источником проблемы может быть дизайн прикложения.
Конфликт защелок
Предположим, что щелчок по закладке "Performance" вызовет экран, подобно показанному на рисунке 10.
Рисунок 10: Закладка "Performance", пример 2
На рисунке обратите внимание на метрику, подсвеченную в красном прямоугольнике. Вы можете видеть, что многие из связанных с CPU ожиданий приходятся на 12:20AM, что привело к большой очереди выполнения для CPU. Мы должны диагностировать, это ожидание.
Сначала, кликнем по графику в области, показанной конфликтной ситуации (contention) CPU, которая помечена на рисунке надписью "Click Here" (“Щелкни сюда”), чтобы подробно увидеть это конкретное ожидание, показанное на рисунке 11.
Рисунок 11: Ожидания Активных Сессий
Обратите внимание на затененный контур на графике (1) "Active Sessions Working: CPU Used" (“Работа Активных Сессий: Использование CPU”). Вы можете, используя мышь, перетащить его в центр. Эта операция заставит расположенные ниже круговые диаграммы (2 и 3) отобразить данные только в границах периода, соответствующего этому блоку. Мы видим, что определенное SQL-предложение с идентификатором 8ggw94h7mvxd7 работает очень тяжело (extra hard) (2). Мы также видим, что пользовательская сессия пользователя по имени ARUP и SID 265 находится на вершине исполнения (3). Кликнем по сессии, чтобы увидеть подробности. В результате появится экран "Session Details" (“Детализация Сессии”). Щелкнув по закладке "Wait Events" (“События ожидания”), получим детализацию событий ожидания, присущих сессии, как то, что можно увидеть на рисунке 12.
Рисунок 12: Детализация событий ожидания
Обратите внимание, что на этом экране самое длительное ожидание - 118 сотых долей секунды, подсвеченное в красном круге, - это ожидание библиотечного кэша. Если Вы кликните по гиперссылке "Latch: Library Cache" ("Защелка: Библиотечный Кэш"), то увидите экран, подобный представленному на рисунке 13.
Рисунок 13: Гистограмма Ожиданий
Этот экран предоставляет уникальную информацию, недоступную в базах данных до 10g. Коль скоро нашей диагностируемой проблемой является конфликт защелок (latch contention), как Вы узнаете, что ожидание в 118 сотых долей секунды объединяет много маленьких ожиданий в нескольких сессиях или только одно большое ожидание только одной сессии, тем самым искажая данные?
Нашим спасением являются гистограммы. Из рисунка Вы знаете, что приблизительно 250 раз сессии были в состоянии ожидания по 1 миллисекунде (подсвечено в круге). 180 раз сессии ожидали где-то от 4 до 8 миллисекунд. Этот экран показывает, что типичны ожидания небольшой продолжительности, делая незначащими симптомы конкуренции за защелки.
С домашней страницы базы данных можное обратиться к ADDM, SQL Access Advisor и другим Советчикам (Advisors), кликая по закладке "Advisor Central" ("Центральный Советчик"). ADDM запускается автоматически, поскольку метрики собраны, и результаты немедленно отправляются на страницу Advisor Central, которая (когда на нее кликают) показывает рекомендации, предлагаемые ADDM. SQL Tuning Advisor (Советчик настройки SQL) также исследует эти метрики и сообщает свои рекомендации на этой странице. (Мы намного более подробно рассмотрим ADDM и SQL Tuning Advisor в следующих выпусках этой серии статей.)
Обслуживание Сделано Простым
Закладка "Maintenance" ("Обслуживание") на домашней странице базы данных – это клавиатура запуска обычных действий обслуживания, как-то: резервирование и восстановление, экспорт или импорт данных (См. “Неделя 4. Накачка Данных”), клонирование базы данных и многое другое. На этом экране можно также редактировать логическое обоснование лучших приемов (best practices), на которых основаны сигналы Policy Violations.
Заключение
Как было сказано ранее, это обсуждение - только вершина очень большого айсберга. В этой статье в мои намерения не входил всесторонний обзор; скорее, я хотел только быстро взглянуть на некоторые возможности, которые охватывают квалификационный спектр.
АБД-новичку Oracle 10g EM предоставляет достаточно много средств для сравнительно быстрого изучения нюансов администрирования Oracle Database. Хорошим кратким руководством по задачам и методам администрирования Oracle с использованием EM является справочное описание
"2-Day DBA" reference manual
("DBA за 2 дня")
. Я усиленно рекомендую (особенно начинающим АБД) прочитать это руководство.
Неделя 14
Виртуальная частная база данных
(Virtual Private Database)
Пять типов политик (policies), образов действий, зависящих от [значений] столбцов и маскировка столбцов делают VPD (Virtual Private Database - виртуальная частная база данных) достаточно сильным инструментом АБД для организации защиты базы данных.
VPD, также известная также, как Fine Grained Access Control (глубоко детализированный контроль доступа), обеспечивает мощные возможности защиты на уровне строки. Этот механизм, введенный еще в Oracle8i, стал широко популярным и может быть применен в самых разнообразных приложениях от программного обеспечения образования до финансовых сервисов.
VPD работает прозрачно и так изменяет запросы к данным, что пользователю предоставляется только частичное отображение таблицы, основанное на наборе заданных критериев. Во время выполнения в конец ко всем запросам добавляются предикаты, отфильтровывающие только те строки, которые полагается видеть данному пользователю. Например, если пользователю положено видеть только данные, отнесенные учетной записи SCOTT, то настроенная VPD автоматически перезаписывает запрос:
select * from accounts;
на:
select * from accounts
where am_name = 'SCOTT';
АБД устанавливает политику безопасности таблицы ACCOUNTS. С каждой политикой ассоциируется связанная с ней функцией, называемая функцией политики (policy function), которая возвращает строку: where am_name = 'SCOTT', которая и применяется как предикат. Если Вы не совсем хорошо знакомы с функциональными возможностями этого механизма, я рекомендую прочитать статью в журнале Oracle Magazine "Keeping Information Private with VPD" http://otn.oracle.com/oramag/oracle/04-mar/o24tech_security.html
Типы Политик
В некоторых ситуациях можно избавиться от избыточного повторного синтаксического анализа (parsing), который необходим, чтобы сгенерировать предикат. Например, в наиболее реальных жизненных ситуациях этот предикат не является столь уж статическим, как “where am_name = 'SCOTT';”. [Функция] может быть значительно более динамической, основываясь на том, кем является пользователь, каков уровень его авторизации, какие учетные записи она просматривает и так далее. Следовательно, и строка, создаваемая и возвращаемая функцией политики, должна быть очень динамической, и Oracle, чтобы гарантировать результат, должен раз за разом выполнять функцию политики, тратя впустую ресурсы и снижая производительность. Этот тип политики, известной под названием "динамическая" ("dynamic") политика, в которой потенциально предикат при выполнении может каждый раз существенно различаться, был доступен в базе данных Oracle9i и предшествующих выпусках.
В дополнение к имеющейся динамической политике Oracle Database 10g вводит еще несколько новых типов политик, задающих для повышения производительности лучшие способы управления тем, как создается предикат:
- context_sensitive (контекстно-зависимый),
- shared_context_sensitive (разделяемый контекстно-зависимый),
- shared_static (статически разделяемый) и
- static (статический).
Давайте рассмотрим, что подразумевает каждый тип политики и как его использовать в соответствующих ситуациях.
Dynamic Policy (Динамическая Политика). В 10g "динамическая" политика задается по умолчанию для того, чтобы сохранить совместимость вниз, то есть так же, как это было в Oracle9i. В этом случае функция политики пересчитывается каждый раз, когда есть обращение к таблице: для каждой строки и для каждого пользователя. Давайте посмотрим на предикат политики поближе:
where am_name = 'SCOTT'
Если пропустить фразу “where”, видно, что предикат имеет две различных части: часть перед оператором равенства (am_name) и после него ('SCOTT'). В большинстве случаев тот, что после, больше походит на переменную, в которую помещаются данные пользователя (если пользователь - SCOTT, то значение переменной -'SCOTT'). Часть до оператора равенства статична. Итак, даже при том, что действительно нужно для каждой строки вычислить значение функции политики, чтобы генерировать соответствующий предикат, знание о статичности первой части и динамичности второй может использоваться для улучшения производительностью. Этот подход применен в 10g, когда используется политика типа "context_sensitive" как параметр при вызове dbms_rls.add_policy:
policy_type => dbms_rls.context_sensitive
В другом демонстрационном сценарии мы имеем таблицу ACCOUNTS с несколькими столбцами, один из которых - BALANCE показывает остаток (баланс) на счете. Давайте предположим, что пользователю разрешено работать со счетами (accounts), баланс которых ниже некоторого значения, которое определено контекстом приложения. Эта величина остатка фигурирует в функции политики, и вместо жесткого кодирования мы можем использовать контекст приложения, как например:
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'balance < sys_context(''vpdctx'', ''maxbal'')';
end;
Атрибут MAXBAL контекста приложения VPDCTX может быть установлен ранее в сессии, и функция просто может получить это значение во время выполнения.
Обратите пристальное внимание на этот пример. Предикат имеет две части: первая до знака (<), а вторая после него. В первой части слово "balance" – это литерал. Часть после знака (<) является более или менее статичной, поскольку переменная контекста приложения является константой, пока ее не изменят. Если атрибут контекста приложения не изменяется, то и весь предикат является константой, и, следовательно, нет необходимости пересчитывать функцию. Если тип политики определен как контекстно-зависимый (context sensitive), Oracle Database 10g распознает этот факт для оптимизации. Если в течение сессии не было изменений контекста сессии, то функция не пересчитывается, что значительно повышает производительность.
Static Policy. (Статическая Политика). Иногда бизнес-операция предписывает предикат, который является более статичным. Например, при демонстрации контекстно-зависимой политики мы определили максимальный баланс, задаваемый пользователем как переменная. Этот подход полезен в случае web-приложений, в которых Oracle-ский userid (идентификатор пользователя) разделяется многими web-пользователями и базируется в их авторизации этой переменной (application context -контекст приложения), установленной приложением. Поэтому web-пользователи TAO и KARTHIK, которые соединяются с базой данных как пользователь APPUSER, могут иметь два различных значения контекста приложения в их сессиях. Здесь значение MAXBAL не привязано к Oracle-скому userid, но скорее к индивидуальным сессиям TAO и KARTHIK.
В случае статичной (static) политики предикат более предсказуем, как показано ниже.
LORA и MICHELLE – это менеджеры бюджетов (account managers) в Acme Bearings и Goldtone Bearings, соответственно. При соединении с базой данных они используют их собственные идентификаторы и должны только видеть те строки, которые имеют к ним отношение. Для LORA предикат становится “where CUST_NAME = 'ACME'”; для Michelle, “where CUST_NAME = 'GOLDTONE'”. В этом случае предикат привязан к userid пользователя, и, следовательно, любая сессия, которая создается при соединении, будет всегда иметь одно и то же самое значение в контексте приложения.
Если предикат кэшируется в SGA, то этот факт может использоваться 10g для многократного использовании в сессии без нужды пересчета функции политики. [Текст] функции политики примерно таков:
create or replace vpd_pol_func
(
p_schema in varchar2,
p_table in varchar2
)
return varchar2
is
begin
return 'cust_name = sys_context(''vpdctx'', ''cust_name'')';
end;
И политика определяется как:
policy_type => dbms_rls.static
Это решение гарантирует, что функция политики вычисляется только единожды. Даже если контексты приложений изменяются в течение сессии, функция никогда не пересчитывается, что делает этот процесс [приписывания предиката] чрезвычайно быстрым.
Статическая политика рекомендуется в случае хостинга (hosting – обслуживание на главной машине) ваших приложений в интересах нескольких подписчиков. В этом случае единственная база данных содержит данные для нескольких пользователей или подписчиков. Когда очередной подписчик соединяется [с базой], входной (after-logon) триггер может установить контекст приложения в значение, которое используется в функции политики, чтобы очень быстро генерировать предикат.
Однако, задать статичную политику - что взять обоюдоострый меч (double-edged sword). В приведенном выше примере мы предполагали, что значение атрибута VPDCTX.CUST_NAME в контексте приложения не изменяется в течение сессии. Но что будет, если это неправильное предположение? Если даже значение изменится, функция политики не пересчитается, и новое значение применяться в предикате не будет, что приведет к неправильному результату! Итак, надо быть очень осторожным в применении статичной политики; Вы должны быть абсолютно уверены, что значение не будет изменяться. Если это допущение сделать нельзя, лучше вместо этого определить политику как контекстно-зависимую.
Shared Policy Types. (Разделяемые типы политик). Можно сделать выбор в пользу некоей общей функции политики для нескольких таблиц, чтобы повторно применять программу и максимизировать использование скомпилированного (parsed) кода. Например, в вышеупомянутом примере мы можем иметь различные таблицы для различных типов бюджетов (accounts) - SAVINGS и CHECKING, но правило - то же самое: пользователи ограничены в доступе к бюджетам с большими, чем они уполномочены, балансными остатками. По этому сценарию запрашивается одна функция, используемая для политик доступа к таблицам CHECKING и SAVINGS. Политика создается как контекстно-зависимая (context_sensitive).
Предположим, что имеет место следующая последовательность событий:
- Соединение сессии;
- Установка контекста приложения;
- select * from savings;
- select * from checking;
Даже при том, что контекст приложения не изменяется между шагами 3 и 4, функция политики будет пересчитана, просто потому что выбранные таблицы теперь разные. Это не желательно, поскольку функция политики та же самая, и нет никакой нужды пересчитывать функцию.
Новой в 10g является возможность совместно использовать политику для нескольких объектов. В вышеупомянутом примере можно было бы определить тип этой политики как:
policy_type => dbms_rls.shared_context_sensitive
Объявление политик как "shared" ("разделяемая") повышает производительность за счет отказа от повторного пересчета функции, как было показано выше.
Выборка Столбцов
Теперь вообразим ситуацию, когда VPD-политика должна быть применена, только если выбраны некоторые столбцы. В приведенном выше примере в таблице ACCOUNTS находятся следующие строки:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY 2000
3 ISRAEL D 1500
Предполагается, что Michelle доступны бюджеты с балансными остатками не более 1 600. Когда она задает, скажем, следующий запрос:
select * from accounts;
она получает:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
3 ISRAEL D 1500
Бюджет no 2 с балансом большим 1 600 был отвергнут при выводе. Michelle может быть обеспокоена, поскольку получила из таблицы только две строки, а не три. Но если она выдаст запрос:
select count(*) from accounts;
который просто считает число строк в таблице, то на выводе [снова] два, а не три.
Однако, здесь мы можем разрешить немного ослабить политику защиты. В этом запросе Michelle не может увидеть конфиденциальные данные типа остатка на счете; она просто считает все записи в таблице. Согласно с политикой защиты мы можем позволить этому запросу сосчитать все записи, вне зависимости разрешено ли Michelle видеть их. Если такое требование имеет место, то в 10g другой параметр запроса к dbms_rls.add_policy разрешает эту возможность:
sec_relevant_cols => 'BALANCE'
Теперь VPD-политика применяет ограничения в зависимости от того, явно или неявно (например, “select *”) пользователь задает в запросе столбец BALANCE. Строки из таблицы будут выбраться иным образом, нежели в запросе, где пользователь запросил только общее число строк, а не столбец BALANCE. Если вышеупомянутый параметр установлен, как было показано, то запрос
select count(*) from accounts;
покажет число три, а не два. Но запрос:
select * from accounts;
вернет только две строки, а не три.
Маскировка столбцов
Теперь давайте добавим еще одно требование к рассматриваемому примеру. Вместо подавления при выводе строк с балансным остатком выше порогового значения, мы можем захотеть показывать все строки, но замаскировать те значения балансового столбца, когда они превышают порог. Защищенный столбец – все тот же BALANCE.
Предполагается, что Michelle не должны быть доступны бюджеты с балансом более 1,600. Когда она задает все тот же запрос:
select * from accounts;
она видит только две строки: бюджеты acctno 1 и acctno 3. Мы же хотим, чтобы она видела:
ACCTNO ACCT_NAME BALANCE
------ ------------ -------
1 BILL CAMP 1000
2 TOM CONNOPHY <null>
3 ISRAEL D 1500
Обратите внимание, что отображены все строки, но значение столбца BALANCE отсутствует (отображено как <null>) для бюджета acctno 2, у которого балансный остаток на самом деле равен 2 000, что превышает установленный порог 1 600. Это решение называется "column masking" ("маскировка столбца") и определяется специфическим я параметром запроса к dbms_rls.add_policy:
sec_relevant_cols_opt => dbms_rls.all_rows
Такая тактика может быть очень полезна в случаях, когда важно знать только некоторые значения столбцов и не нужна сложная настройка кода. Эта возможность представляет собой серьезную альтернативу требованию шифрования хранимых данных.
Заключение
В Oracle Database 10g VPD превратился в очень мощный механизм, способный обеспечить разнообразие требований, таких как: маскировка столбцов, выборочно основанных на политике, и применение политики только при обращении к некоторым столбцам. Производительность политики может быть повышена путем применения разнообразных типов политик, отвечающих характеру приложения, реализуя возможность применения во множестве ситуаций.
Для получения подробной информации о VPD и пакете dbms_rls обратитесь
к Главе 79 Руководства
“PL/SQL Packages and Types Reference”, а также к книге документации
“Oracle Database Security Guide”.
На эту тему Вы можете также прочитать мою в соавторстве с Don Burleson (Дон Бурлесон) книгу “Oracle Privacy Security Auditing” (изд. Rampant TechPress).
| 