Oracle Enterprise manager и его пакеты

Oracle Enterprise manager и его пакеты

(средства управления СУБД и приложениями)

М. Ривкин

I. Проблемы управления.

Общеизвестно, что для того, чтобы находящиеся в промышленной эксплуатации информационно - управляющие приложения работали хорошо (быстро, надежно, качественно), его должны сопровождать специальные люди - администраторы базы данных, администраторы сети, администраторы всей системы и т. д. Требования к квалификации этих людей очень высокие и стоимость их на рынке тоже довольно высока. Кроме того, и в России и на западе постоянно ощущается недостаток таких специалистов. Например, в обязанности администратора базы данных (АБД), работающего с одной базой данных (БД), входит:

- управление пользователями и привелегиями;

- управление ресурсами БД;

- копирование и восстановление БД;

- экспорт/импорт данных;

- мониторинг состояния БД и приложений;

- обеспечение непрерывной работы приложений;

- обеспечение высокой производительности приложения;

- старт и остановка системы;

- инсталляция новых версий;

и т д.

Этот список далеко не полный, его можно продолжать и продолжать. И ошибка в любой из этих работ может привести к простою в работе организации и многомиллионным потерям.

Хотелось бы отметить, что последнее время часто приходится слышать о СУБД, которые якобы не требуют администрирования. Они противопоставляются СУБД Oracle, администрирование которой якобы чрезвычайно сложно и доступно немногим супер АБД. Особенно часто слова о СУБД, не требующей администрирования, слышны от представителей фирмы Microsoft. Однако даже беглого взгляда на приведенный выше и далеко не полный список обязанностей АБД достаточно для того, чтобы понять - эти работы надо выполнять для любой СУБД, если мы хотим, чтобы приложения работали в промышленном режиме. Поэтому коммерческая СУБД без администрирования сегодня - это иллюзия или обман. Другое дело, насколько трудоемки операции администрирования и какие инструментальные средства есть в арсенале АБД. Об этом и идет речь в данной статье.

Теперь давайте посмотрим, что происходит сегодня в области информационных систем и СУБД.

Во-первых, число пользователей этих систем постоянно растет и мы уже говорим о тысячах и десятках тысяч пользователей, а переход к интернет - приложениям увеличивает число пользователей еще на порядок. Соответственно возрастает и нагрузка на АБД.

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

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

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

Что бы нам хотелось иметь в идеале?

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

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

Идеальный инструмент должен создать ситуацию, когда администратор БД будет проактивным. Будет предупреждать события до их возникновения, а не реагировать в пожарном порядке на постоянно возникающие проблемы. В этом случае количество проблем уменьшится, а вероятность ошибок станет минимальной. Выгоды от использования такого инструмента понятны. Снизится стоимость обучения АБД, уменьшится время простоя системы и повысится ее производительность. Уменьшится трудоемкость выполнения рутинных задач. Т. е. мы получим в эксплуатации ту самую “хорошую” прикладную систему.

На самом деле такой идеальный инструмент для управления СУБД Oracle существует, более того, его имеют все администраторы Oracle (он поставляется бесплатно вместе с сервером Oracle). Инструмент называется ORACLE ENTERPRISE MANAGER.

II. Oracle Enterprise manager

1. Общее описание

Одной из основных компонент Oracle Enterprise Manager (OEM) является центральная консоль оператора. Сидя за этой консолью АБД как в центре управления полетами видит все СУБД, которые он администрирует, несмотря на то, что они размещаются на разных компьютерах, разбросанных по разным зданиям, городам и странам. Он может отслеживать состояние этих СУБД и выполнять с каждой СУБД или с группой СУБД различные административные действия, не сходя со своего рабочего места. А при желании он может все это делать через интернет.

Центральная консоль написана на языке Java и имеет красивый и удобный графический интерфейс, который может работать на Windows платформах и на Sun Solaris. Кроме СУБД администратор может контролировать с этой консоли узлы сети (компьютеры), листенеры, сервера приложений (Oracle application servers), Oracle Developer Server, ERP приложения (SAP/R3, Oracle Applications), а для новой конфигурации Oracle - Oracle Appliance (поставка Oracle Server вместе с куском операционной системы, необходимым для его работы) OEM позволяет управлять и операционной системой.

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

Рис. 1. Центральная консоль OEM

В левом верхнем окне можно видеть навигатор объектов, с которыми мы собираемся работать (это БД, узлы, пользователи, объекты БД и т д). Под этим окном размещается окно для работы с пакетными заданиями (JOB), правее него видно окно для управления и контроля событий, происходящих на узлах и в БД. В правом верхнем углу можно разместить карту региона, на которой будут иконками отмечены администрируемые БД или узлы. В случае возникновения проблем в этих БД (узлах) у иконки появляется красный флажок и АБД видит, что требуется его вмешательство.

Но самое главное достоинство OEM это то, что он является не просто фиксированным инструментом АБД. OEM - это некая рама, каркас (frame) в которую легко могут добавляться новые модули - инструменты, расширяя функции OEM. Рассмотрим архитектуру OEM более подробно.

2. Архитектура OEM

OEM состоит из 3 компонент: центральные консоли, за которыми работают АБД, управляющие сервера (Management servers), реализующие всю логику OEM и интеллектуальные агенты (Intelligent Agents), работающие на узлах, где размещены БД, и выполняющие там задания по поручению управляющих серверов. Управляющий сервер имеет свой репозиторий, где он хранит необходимую для работы информацию о пользователях БД, узлах, привилегиях и т д. Репозиторий хранится в БД Oracle. Консоль выполняет функции интерфейса. Несколько консолей может работать с одним управляющим сервером, а при большой нагрузке можно запустить дополнительный управляющий сервер, который будет использовать тот же репозиторий. Таким образом достигается балансировка нагрузки.

OEM позволяет выполнять не только те команды, которые выполняются экземпляром (instance) Oracle, но и команды операционной системы, старт и остановку БД. Поэтому на каждом управляемом узле должен работать сервис, который не привязан к состоянию БД. Эту роль и выполняет интеллектуальный агент. Он может выполнять скрипты, стартовать БД, выполнять команды операционной системы, контролировать возникновение заказанных OEM событий. Причем выполнение этих работ может происходить в заранее указанные моменты времени или с определенной периодичностью, а результат будет передан управляющему серверу тогда, когда тот будет иметь связь с агентом.

Рис. 2. Архитектура OEM

Понятно, что консоль, управляющий сервер, его репозиторий, агент с управляемыми БД все могут размещаться на отдельных компьютерах. Но можно все это установить и на один компьютер. Иногда для сбора статистики в помощь интеллектуальному агенту требуется запустить еще один сервис - Data Gatherer.

Вместе с OEM Вы можете проинсталлировать его Web вариант. Он не требует дополнительного конфигурирования. Вы просто запускаете на компьютере с OEM установленную упрощенную версию сервера приложений и можете работать с консолью через интернет/интранет с любого компьютера, где есть Web броузер. (правда, при первом обращении Вас попросят выгрузить и установить пакет Jinitiator). Через этот Web интерфейс доступны все функции OEM и пакета DBA Management Pack, который будет описан ниже.

Как уже было сказано, OEM состоит из консоли, управляющего сервера и агентов. Но в него могут легко встраиваться дополнительные модули - компоненты, выполняющие те или иные работы по администрированию. Таких модулей существует много и их можно разбить на несколько групп.

1. Пользовательские модули и модули других фирм. OEM имеет документированный API и все желающие могут разрабатывать и включать в OEM свои собственные модули, расширяющие функциональность OEM.

2. DBA Management Pack. Это стандартный набор модулей, разработанных Oracle и поставляемых вместе с OEM. Они позволяют выполнять основные работы по администрированию БД (работы с экземпляром Oracle, пользователями, объектами БД).

3. Oracle Diagnostic, Tuning, Change Management Packs. Эти три пакета модулей, разработанных Oracle, не входят в стандартную поставку. Их надо покупать отдельно. Они сильно помогают АБД в диагностировании, настройке и модификации БД.

4. Прочие специфические модули. Эти модули также разработаны Oracle и нужны для работы с отдельными специфическими опциями (компонентами) сервера. Если Вы купили и используете эти опции, то Вам следует установить и использовать и модули для конфигурирования и управления этими опциями. Например, есть модуль для работы с Oracle Parallel Server, есть Replication Manager для конфигурирования репликации, есть Video Server manager и т. д.

В этой статье мы коротко расскажем про эти специфические модули, а основное внимание сосредоточим на описании DBA Management Pack, Diagnostic, Tuning, Change Management Packs. Но прежде остановимся на общих характеристиках OEM.

3. Характеристики и функции OEM

OEM и все его модули имеют графический интерфейс. Большинство работ выполняется с помощью мыши. Выполнить сложные операции помогают помощники (Wizards). Они разбивают сложную операцию на части и ведут с АБД диалог, объясняя, что и как надо делать. Таким образом, даже не очень опытный администратор может выполнить сложные задачи. Кроме того, OEM еще и обучает АБД в процессе работы. Вы всегда можете посмотреть текст скриптов и SQL операторов, которые он формирует и понять, что и почему будет делаться. OEM позволяет Вам узнать какие режимы выполнения той или иной операции возможны и т д.

В состав OEM входит 4 подсистемы:

n система управления пакетными заданиями (JOB SYSTEM)

n система управления событиями (EVENT SYSTEM)

n система анализ узлов сети (DISCOVERY SERVICE)

n система управления безопасностью (SECURITY SERVICE)

Система управления пакетными заданиями позволяет АБД и модулям OEM формировать задания, запускать их на выполнение, контролировать результаты выполнения. Задание может содержать как SQL - PL/SQL операторы для работы с БД, так т TCL скрипты, команды операционной системы, задания на старт/остановку базы и т д. Один раз созданное задание можно поместить в библиотеку заданий и выполнять многократно. Задание может быть запущено немедленно, в заранее указанное время, может выполняться многократно через указанные интервалы времени, в определенные дни недели или месяца. Кроме того, одно задание можно назначить на выполнение группе БД или узлов и тогда оно будет выполняться на каждой из этих БД или в каждом узле. Таким образом достигается упрощение выполнения стандартных и повторяющихся работ.

В состав OEM входит набор заранее подготовленных заданий, таких как анализ данных, экспорт/импорт, загрузка данных, копирование/восстановление, старт/остановка БД, выполнение команд SQLPLUS и Server Manager. Меняя параметры этих заданий можно выполнять широкий набор функций. Кроме того, этапы одного задания могут быть взаимосвязаны. Например, выполняться только при успешном или неуспешном выполнении предыдущего этапа задания.

Задания могут запускаться не только по времени, но и автоматически при возникновении фиксируемых OEM событий в БД или на узле. Это так называемые Fixit job. Например, при возникновении события “В табличном пространстве xxxxx осталось менее 1 М свободного пространства”, автоматически запустится Fixit job, увеличивающая это табличное пространство. Вмешательство АБД здесь не требуется. Он будет лишь извещен о выполнении работы.

Система управления событиями позволяет АБД указать системе, какие события в БД или на узле его интересуют. После этого он может не думать об этих событиях. Система сама известит его, когда это событие возникнет. Можно включить контроль события (группы событий) сразу на нескольких узлах (БД). Сигнал о возникновении события может появляться не только в окне событий консоли. Он графически отображается на карте консоли (красный или зеленый флажок), а, кроме того, сообщение о событии может быть послано АБД по электронной почте или на пэйджер. При контроле некоторых событий АБД может сам задать пороговые значения, о которых его следует извещать (например, когда свободного места останется меньше xx Мб).

В состав OEM входит набор стандартных событий, контроль которых можно заказать. При установке Diagnostic Pack этот набор значительно расширяется. Кроме того, АБД может описать собственные события с помощью оператора SELECT. Стандартные события делятся на группы, связанные с аудитом, ошибками, производительностью, использованием ресурсов, использованием пространства БД и компьютера. Ну а Fixit Job поможет реагировать на эти события автоматически.

Система анализа узлов сети позволяет OEM автоматически определить, какие БД, листенеры, сервера приложений установлены на указанном узле сети. Вам надо знать только имя узла. OEM дает команду агенту узла провести исследование и затем включает обнаруженные объекты в дерево навигатора объектов. Если же агент на этом узле не работает, то у Вас остается возможность определить эти объекты вручную.

Ну и, наконец, система управления безопасностью. Для связи с OEM АБД должен указать свое имя и пароль. На основе этого определяются его привилегии. Поскольку АБД приходится работать со многими БД и узлами, то очень сложно запомнить имена и пароли для работы с каждой БД (узлом). АБД может сохранить эти имена и пароли в репозитории OEM и больше не указывать их, открывая БД или запуская тот или иной модуль. OEM возьмет их из репозитория автоматически. Таким образом, мы имеем единый вход для управления многими системами (single sign on). Естественно, что все имена и пароли кодируются при пересылке по сети.

В окне навигатора объектов OEM АБД видит дерево управляемых объектов (узлов, БД, листенеров и т д.). Он может раскрывать это дерево и запускать модули для работы с этими объектами. Стандартные функции администрирования выполняются модулями, входящими в пакет DBA Management Pack.

III. DBA Management Pack

DBA Management Pack - это набор модулей, облегчающих выполнение задач по администрированию БД. Все компоненты пакета могут запускаться как из-под OEM консоли, так из операционной системы. Основное достоинство DBA Management Pack заключается в том, что он позволяет заменить ввод команд SQL на работу с простыми графическими интерфейсами. Т. е. не надо знать синтаксис SQL для выполнения сложных работ по администрированию. С помощью этого пакета АБД может централизованно администрировать одну или несколько БД, расположенных локально или удаленно и на любых платформах (тип компьютера + операционная система).

DBA Management Pack состоит из группы модулей, называемой DBA Studio и компоненты SQL Plus Worksheet. SQL Plus Worksheet - это обыкновенный интерпретатор языка SQL. Он позволяет писать и выполнять SQL и PL/SQL запросы, выполнять команды DBA и запускать выполнение скриптов.

DBA Studio включает 4 модуля:

n Instance manager

n Security manager

n Schema manager

n Storage manager

Кроме того, в состав DBA Studio входят помощники (wizards) для выполнения копирования/восстановления, экспорта/импорта и загрузки данных.

Большим достоинством DBA Studio является то, что она может работать автономно, не используя управляющий сервер. Часть функций, связанная с выполнением заданий (JOB) (копирование/восстановление, экспорт/импорт, загрузка) при этом правда не доступна, но на не очень мощных компьютерах возможность не запускать управляющий сервер и напрямую работать с БД очень ускоряет работу. С DBA Studio могут работать не только АБД. Очень много функций, связанных с просмотром объектов (системных и пользовательских) в БД может выполнять любой пользователь с привилегиями роли SELECT_CATALOG_ROLE. При этом он может только смотреть информацию, но не менять ее. DBA Studio дает возможность легко строить, просматривать, выводить на печать и в HTML формат так называемые суммарные справки. Например, отчет обо всех пользователях БД или обо всех сегментах отката БД.

Все 4 модуля DBA Studio имеют похожий интерфейс и позволяют выполнять стандартные операции со своими объектами: создать, удалить, посмотреть и изменить характеристики. Для некоторых объектов можно выполнить специфические операции (например, добавить файл к табличному пространству, вывести пространство в offline /online или сделать его доступным только на чтение, запустить копирование (backup), реорганизацию и т. д.)

Но дело в том, что сами то объекты в этих четырех модулях совершенно разные: это системные объекты в storage manager, пользователи и привилегии в security manager, пользовательские объекты в schema manager.

Instance manager позволяет работать с информацией об экземпляре (instance) Oracle. Вы можете просмотреть общую информацию об экземпляре и БД (имя, режим работы, состояние БД и т д.), распределение областей в памяти (видна круговая диаграмма размеров областей SGA). АБД может просмотреть значения всех параметров экземпляра (взятых из файла init.ora) и изменить значения некоторых из них, не останавливая Oracle. Очень удобно, что для каждого параметра видно подробное описание его смысла и возможных значений. АБД может остановить и перезапустить экземпляр Oracle в любом режиме.

Instance manager позволяет работать с системой управления ресурсами экземпляра (resource management). Вы можете создавать планы использования ресурсов компьютера (resource plan), создавать группы потребителей ресурсов (resource consumer group), назначать этим группам процент использования процессоров и степень параллелизма. Естественно, что все это можно просматривать и менять с помощью удобного графического интерфейса.

Instance manager позволяет увидеть, какие сеансы сейчас работают с БД и получить некоторую статистическую информацию об этих сеансах (кто его открыл, какой SQL оператор он выполняет, план выполнения этого SQL, статус сеанса и т д.). Более полную и оперативную информацию о сеансе можно получить с помощью Diagnostic Pack. АБД может также легко прервать сеанс пользователя (kill session).

Schema manager позволяет работать с пользовательскими объектами БД. Их более двух десятков. Это и таблицы, индексы, представления и процедурные компоненты, и такие новые объекты, как измерения (dimension), материализованные представления, очереди, массивы и объектные типы. АБД может создать, удалить, просмотреть и отредактировать эти объекты. Для объектов, содержащих данные (например, таблиц) можно редактировать не только описание объекта, но и сами данные. Среди специфических функций для конкретных объектов следует отметить возможность простого выполнения команды DROP COLUMN, очень простое создание задания на сбор статистики (команда ANALYZE) для объекта, группы объектов, объектов схемы и т.д.

Для создания некоторых сложных объектов используются помощники. Они могут пошагово создать сложную таблицу, состоящую из частей (partitions), порекомендуют, где следует создать материализованное представление, сколько оно займет места и какой даст выигрыш в производительности. Если в системе установлены Diagnostic, Tuning, Change Management Packs, то из Schema manager можно для конкретного объекта схемы запустить нужный модуль из этих пакетов. Но все же главным достоинством Schema manager является возможность оперативного получения наглядной информации об объектах схем БД.

Storage manager позволяет работать с системными объектами БД: табличными пространствами, сегментами отката, файлами данных, журнальными файлами. АБД может оперативно смотреть информацию об этих объектах, модифицировать ее. Для табличных пространств и файлов данных можно видеть диаграмму процентного использования файла. Storage manager позволяет также просматривать и модифицировать информацию о журнальных и Control файлах, запускать операции копирования control файлов и файлов данных. Объекты Storage manager можно выводить в offline / online, для журнальных файлов можно выполнять checkpoint (контрольная точка) и переключение файлов.

Security manager позволяет управлять пользователями, ролями, привилегиями и профайлами. Используя графический интерфейс АБД может создавать пользователей, назначать им роли, привилегии, профайлы. Security manager поддерживает режимы задания паролей, позволяет отследить зависимости (например, кому грантирована данная роль).

IV. Прочие специфические модули

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

· Replication manager - конфигурирование и контроль репликации;

· Video Server manger - управление видео серверами, потоками и клиентами. Упрощает конфигурирование и обслуживание видео сервера;

· Parallel Server manager - управление несколькими экземплярами Oracle на кластере. Он позволяет отслеживать и настраивать специфические для Parallel Server характеристики Oracle;

· Intermedia Text manager - конфигурирование и управление работой с неструктуриро-ванными текстами;

· Application Server manager - конфигурирование и управление работой с серверами приложений Oracle;

· Developer Server Forms manager - конфигурирование и управление работой с Forms Server

· Spatial Index Advisor - конфигурирование и управление работой с пространственной информацией;

· Oracle Failsafe manager - конфигурирование и управление работой с Failsafe;

· Oracle Express manager - конфигурирование и управление работой с Express продуктами;

· Directory manager - работа с Oracle LDAP Internet Directory;

· Enterprise Security manager - работа с Advanced Networking option;

· Applications manager - работа с SAP/R3 или Oracle Applications.

Этот список не полон и постоянно пополняется.

V. Diagnostic, Tuning, Change management Packs

или

как лечить 5 основных головных болей администратора БД

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

Чем же так занят АБД? Если проанализировать всю его деятельность, то можно выделить 5 основных проблем, решение которых занимает большую часть его времени. Такими проблемами являются:

· выполнение рутинных работ;

· оперативная реакция на возникающие проблемы;

· обеспечение высокой производительности системы;

· решение проблемы исчерпания ресурсов;

· модификация структуры БД прикладных систем.

К рутинным работам, которые АБД обязан выполнять регулярно, относится, например, создание резервных копий файлов БД, экспорт важных таблиц, сбор статистики об объектах БД (команда Аnalyze), печать различных справок и отчетов и т д. Обычно эти работы не сложны, но могут занимать много времени и, главное, надо не забыть их выполнять и даже, иногда, принять организационные меры для контроля выполнения этих работ. Например, не сделанная вовремя копия табличного пространства может привести к потере данных или длительному простою системы. Рутинные работы известны заранее и АБД должен снова и снова выполнять их.

Оперативная реакция на возникающие проблемы занимает большую часть времени АБД. В реально работающей системе постоянно что-то случается. Непрерывно прибегают пользователи со своими проблемами, которые, естественно, важнее всех других, и их надо решить немедленно, бросив все другие работы. Приходят заявки и информация о проблемах по почте и телефону. Часто эта текучка не позволяет выполнить даже ранее запланированные важные административные работы. А уж в конце квартала/года приоритет этого типа работ максимален. Проблем такого рода может быть очень много. Например: задание не выполняется и висит, задание не запускается и выдает ошибку, у пользователя нет необходимых привилегий, заданию не хватает ресурсов (диска, памяти и т. д.), пользовательская программа вдруг стала работать нештатно или вообще перестала отвечать. Этот список бесконечен и любой администратор может продолжить его.

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

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

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

Решение проблемы исчерпания ресурсов - это не очень частая, но очень болезненная задача. Когда внезапно обнаруживается, что на диске больше нет места или производительности компьютера не хватает, чтобы выполнить важную задачу в срок, АБД испытывает много неприятных минут. Часто он просто не в силах решить возникшую проблему, т. к. для этого требуется закупка оборудования, выделение денег и т д. Иногда решение возникшей проблемы наспех (например, создание дополнительного файла, увеличивающего табличное пространство, на с трудом найденном свободном участке чужого диска) приводит к разрушению БД в дальнейшем (владелец диска удалил чужой файл или его забыли скопировать во время backup).

Пятая проблема, связанная с модификацией структуры БД приложения, на первый взгляд не является прямой обязанностью АБД. Этим должен заниматься разработчик приложения. Но следует вспомнить, что часто для оптимизации работы приложения АБД приходится переносить объекты БД в другие табличные пространства, схемы, на другие диски. АБД обычно более опытен, чем разработчик, и ему приходится участвовать в процессе установки новых версий прикладной системы, тиражировать изменения в структуре БД на множество эксплуатационных узлов, в различные филиалы и т. д. Часто разработчик плохо доступен и АБД приходится разбираться в причинах, препятствующих работе приложения, а это может вести также к корректировке объектов БД.

К сожалению, любая ошибка при выполнении изменений в структуре БД может привести к выходу из строя приложения. А если изменения тиражируются во многие узлы, то и к остановке группы приложений. Изменения, связанные с одним приложением, могут затронуть другие приложения. И очень часто результаты непродуманной корректировки структуры БД могут сказаться не сразу. Какие-то функции приложения станут работать неверно, но выяснится это нескоро. Поэтому работа по внесению изменений в структуры данных приложений требует много времени, тщательности и предварительного анализа последствий.

Из всего выше описанного видно, насколько тяжела доля АБД. Хотелось бы ее облегчить. Что бы хотелось иметь в идеальном случае?

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

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

По поводу исчерпания ресурсов. Единственным действенным средством здесь может быть планирование, т. е. возможность предсказать возникновение недостатка ресурсов заранее и неспеша закупить дополнительные ресурсы (диски, память, компьютеры и т. д.)

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

Проблема Решение

Рутинные работы ===========è АВТОМАТИЗИРОВАТЬ

Оперативная реакция на все ===è МОНИТОРЫ

Высокая производительность ===è НАСТРОЙКА

Исчерпание ресурсов =========è ПЛАН

Модификация структуры БД ===è Отслеживать зависимости и

автоматизировать

Рис. 3. Пять головных болей АБД

Oracle предложил лекарство от этих головных болей в виде трех дополнительных пакетов - Diagnostic Pack, Tuning Pack, Change Management Pack, которые помогают реализовать выше описанные подходы к решению указанных проблем. Рассмотрим, как эти пакеты помогают в решении каждой из этих проблем.

1. Ежедневное администрирование и рутинные работы

Средства для автоматического выполнения рутинных и ежедневных задач были уже описаны выше, поскольку они входят в состав OEM. Это система управления пакетными заданиями (job system) и система управления событиями (event system). Фиксирующие задания (Fixit job), привязанные к событиям, срабатывают автоматически при возникновении события. Обычные задания выполняются регулярно по времени и таким образом автоматически, без вмешательства АБД, выполняют один раз описанные рутинные работы. При установке Oracle Diagnostic Pack набор стандартных событий сильно расширяется и соответственно возможность автоматизации рутинных работ увеличивается.

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

Такой же подход можно применить для того, чтобы решать задачи заранее, до того, как они

превратятся в проблемы. Например, вместо того, чтобы в авральном порядке увеличивать переполненное табличное пространство, АБД может, создав событие “В табличном пространстве хх осталось менее 1 Мб свободного пространства”, привязать к нему Fixit job, автоматически добавляющий файл к этому табличному пространству. Интеллектуальный агент узла, обнаружив возникновение такого события, пошлет сообщение управляющему серверу и тот автоматически выдаст команду на выполнение работы по расширению табличного пространства. Агент выполнит работу и пришлет извещение об этом в дневное время на пэйджер АБД, а ночью - по электронной почте.

2. Мониторинг и диагностика возникающих проблем

Главная задача, которую обеспечивают модули пакета Oracle Diagnostic Pack - это получение точной, наглядной, оперативной информации о том, что происходит в БД и на узле. Причем следует помнить, что в работающей системе ситуация меняется ежесекундно. Знание состояния БД и узлов часто также помогает решать проблемы еще до их возникновения, т е. вести проактивное администрирование.

В состав Diagnostic Pack входит модуль Performance manager. Он позволяет АБД просмотреть состояние БД и узлов в виде таблиц и цветных диаграмм (круговых, столбчатых, линейных). Графическое представление информации очень удобно и наглядно. АБД сразу же видит, где есть проблемы.

Например, для определения качества настройки экземпляра Oracle и области памяти SGA администратор должен знать, как часто обращения Oracle за данными в области буфера данных (buffer cache), библиотечный буфер (library cache), буфер словаря (dictionary cache) не находят данных в оперативной памяти и вызывают считывание данных с диска. АБД должен выявить число таких “непопаданий/ненахождений”, определить какой процент это составляет от общего числа обращений. Если этот процент превышает некоторое пороговое значение (различное для каждого буфера), например, более 10% непопаданий, то это сигнал о том, что следует увеличивать данную область памяти.

Однако для того, чтобы получить все эти цифры, АБД должен выполнить множество запросов к внутренним труднопроизносимым динамическим таблицам Oracle (V$ таблицы). Следует помнить их имена, писать эти запросы или готовить скрипты, производить вычисления и т. д. С помощью диаграммы использования кэша Performance manager АБД может увидеть информацию о состоянии всех буферов сразу, не выполняя никаких запросов (рис 4).

Рис. 4. Диаграммы Performance manager

В синих круговых диаграммах использования кэшей красный сектор обозначает процент непопаданий. Если он есть и велик (можно посмотреть его величину, т. е. процент непопаданий), то проблема существует и ее надо решать. Если же все красные сектора узки - проблем с кэшами нет.

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

В состав Performance manager входит большое количество заранее созданных диаграмм. Они собраны в группы. Для БД:

- контроль блокировок

- контроль ввода/вывода

- контроль спора за ресурсы

- информация об экземпляре

- контроль загрузки БД

- контроль использования областей памяти

- контроль пользователей ресурсов

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

Для узла: контроль системы, процессора, памяти, кэша, физических и логических дисков, процессов, нитей, объектов, редиректор, сервера и его очередей, пэйджинга, броузера, RAS, телефонии, NBT connection.

Кроме того, АБД может создавать свои собственные диаграммы, запоминать их и далее постоянно использовать. Т. е. если у АБД есть своя технология и заранее подготовленные запросы, то их легко встроить в Performance manager. Если диаграмма показывает укрупненные данные, то Вы всегда можете, щелкнув мышью, перейти (провалиться) на следующий уровень детализации. Например, если АБД обнаружил проблемы с использованием библиотечного кэша, он может перейти к просмотру подробной диаграммы использования библиотечного кэша и увидеть массу информации уже об отдельных областях, объектах и операциях библиотечного кэша.

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

Особенно полезны 2 составные диаграммы Performance manager - обзор использования кэша и обзор загрузки БД. Каждая из них состоит из нескольких более мелких диаграмм и на одном экране такая диаграмма дает всю информацию, которая нужна для быстрой диагностики проблем. Эти 2 диаграммы настолько полезны и часто используемы, что Oracle дополнительно включил их прямой вызов в меню Diagnostic Pack. Диаграммы Performance Pack драматически упрощают и ускоряют работу АБД и чрезвычайно полезны.

Другой модуль Diagnostic Pack - Top Sessions. Он позволяет АБД видеть все сеансы, открытые сейчас с БД, их состояние, и массу статистики о сеансах. Сеансы можно упорядочить на экране в соответствии со значениями статистики, например, по количеству операций ввода/вывода, использованию процессора или времени выполнения. Можно смотреть не все сеансы, а только N первых в этом отсортированном списке. Поскольку диаграмма обновляется с заданной Вами частотой, Вы всегда знаете, какие сеансы сейчас работают, какие завершились, активны они или нет и что делают. Для выбранного сеанса можно перейти на уровень просмотра всей статистики данного сеанса (ее много). Она делится на общую статистику и статистику, связанную с производительностью. Можно посмотреть какой SQL оператор выполняет сейчас сеанс и план выполнения этого оператора.

Top Sessions позволяет получить информацию о текущих блокировках в БД. Посмотрев дерево блокировок, АБД видит, какой сеанс какие ресурсы заблокировал и в каком режиме. И какие сеансы ждут этот заблокированный ресурс. Если, например, неопытный пользователь явно заблокировал некоторую таблицу командой Lock и остановил работу других пользователей, то АБД может легко это увидеть и завершить (убить) из Top Sessions сеанс этого пользователя, разблокировав таблицу. Для получения более подробной информации о блокировках в БД можно использовать еще один модуль Diagnostic Pack, называемый Lock monitor. Он динамически отображает дерево блокировок (пользовательских и блокирующих/ожидающих) и позволяет завершать/убивать сеансы.

Следующая компонента Diagnostic Pack - Trace manager. В состав сервера Oracle входит компонента Oracle Trace (не путать с SQL Trace). Она позволяет приложениям, работающим с БД Oracle, писать в файлы операционной системы всевозможную статистику о работе приложения. Есть специальный API, который могут использовать эти приложения. Сам экземпляр Oracle, тоже в некотором роде является приложением, работающим с БД. И создатели программы Oracle Server встроили в нее вызовы этого API. Включив соответствующий параметр в файле параметров, АБД может включить сбор этой статистики. Статистика пишется в файл в некотором внутреннем представлении. Ее много, она трудночитаема.

Oracle Trace manager позволяет облегчить работу с этим огромным множеством статистики. Во-первых, его графический интерфейс позволяет ограничить круг собираемой статистики и задать частоту ее сбора. АБД создает так называемую “коллекцию’ для которой определяет: статистку какого приложения надо собирать, какое подмножество статистики собирать, для всех или для заданных пользователей собирать статистику, когда начать и когда прекратить сбор и т. д. Кроме того, собранная статистика будет форматироваться и загружаться в реляционные таблицы БД. Так что в дальнейшем ее сможет использовать не только Trace manager Viewer, но и любые приложения, использующие SQL, например, генератор отчетов может строить свои отчеты на базе этих таблиц. Собранная статистика может далее использоваться для настройки БД модулем Oracle Expert, входящим в Tuning Pack.

Но мало статистику собрать. Надо дать возможность в ней не утонуть. Входящая в состав Trace manager программа просмотра Trace Data Viewer, содержит большое количество заранее подготовленных отчетов, которые обеспечивают упорядоченный взгляд на всю собранную статистику. Можно создать и свои пользовательские отчеты.

В состав Diagnostic Pack входит и еще один модуль, Capacity Planer, но он предназначен для планирования использования ресурсов и мы поговорим о нем позже. Таким образом, пакет Diagnostic Pack состоит из модулей:

· Capacity planer

· Lock monitor

· Performance manager/Performance overview

· Top sessions

· Trace manager/Trace Data Viewer

Он позволяет в реальном времени собирать статистику о БД, узлах и приложениях и определять текущее состояние этих объектов и тенденции изменения состояния. Модулям Capacity planer и Performance manager в сборе статистики об операционной системе, БД, приложениях и серверах приложений помогают компоненты Intelligent Agent и Data Gatherer.

3. Настройка БД и приложений

Пакет Tuning Pack позволяет автоматизировать процесс настройки БД и приложений. В процессе настройки можно выделить три проблемы:

n настройка БД для оптимальной работы всей совокупности приложений

n настройка SQL операторов и создание необходимых индексов

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

Настраивать всю систему в целом обычно очень сложно. Поэтому, как правило, задачей администратора является выявление “узких мест”, наиболее сильно снижающих производительность. Далее АБД должен проанализировать проблемы, создающие эти узкие места, выработать рекомендации по решению этих проблем и затем выполнить эти рекомендации, расшивая тем самым узкие места и повышая производительность всей системы. Такой подход реализуют и модули Tuning Pack. Для настройки использования пространства БД и устранения проблем хранения используются два модуля Tuning Pack - Tablespace Map и Reorg Wizard.

Модуль Tablespace Map позволяет получить детальное графическое изображение того, как размещаются данные (сегменты) и их части (экстенты) в выбранном табличном пространстве. АБД видит список объектов, хранящихся в табличном пространстве, их тип, размер, наличие свободного пространства. Кроме того, он может запустить программу анализа сегментов, которая пометит красным или желтым флажком сегменты, для которых обнаружены проблемы или есть тенденция возникновения проблем. Далее с помощью Reorg Wizard эти проблемы можно разрешить. Какие же проблемы определяет программа анализа? Это, например, наличие сильно фрагментированных таблиц и индексов, наличие сегментов с слишком быстрым ростом числа экстентов, сегменты с чейнингом и миграцией строк, сегменты, для роста которых уже нет места в табличном пространстве, стагнацию индекса. Tablespace Map не только идентифицирует эти проблемы, но и создает отчеты для каждого сегмента, где предлагает пути решения проблем (например, перестроить индекс, увеличить табличное пространство и т д.).

Если Tablespace Map - это все-таки больше диагностическое средство, то Reorg Wizard позволяет реально разрешить проблемы и настроить области хранения базы данных. Reorg Wizard можно запускать как из OEM, так и из Tablespace Map. Соответствуя своему названию, он ведет с Вами диалог и формирует задания OEM для реорганизации либо всего табличного пространства, либо отдельных его сегментов. С помощью Reorg Wizard Вы можете: переместить объекты в другое табличное пространство, изменить их параметры хранения, перестроить фрагментированные таблицы и индексы, избавиться от миграции строк в таблицах. Он может также удалить фрагментацию табличного пространства. Все операции производятся с учетом взаимозависимости объектов.

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

Oracle Expert. Процесс настройки БД состоит из нескольких этапов. Настраивающий БД администратор должен реализовать некоторую методологию настройки, описывающую эти этапы. Суть этой методологии довольно проста. Вначале, естественно, надо определить, что мы будем настраивать (экземпляр, методы доступа, SQL и т. д.), выделить уже упоминавшиеся узкие места. Затем следует определить источники, из которых мы будем черпать статистическую информацию, на основе которой и выполняется анализ состояния системы. Эта информация может быть уже подготовлена другими модулями, может собираться специально для данного анализа, может вводиться вручную и т. д.

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

Как видно из описанной выше методологии, процесс настройки достаточно сложен, трудоемок, требует высокой квалификации. Ручной сбор статистики о состоянии БД и приложений превращает работу АБД в кошмар. Модуль Oracle Expert реализует описанную выше методологию в автоматическом режиме. Т. е. он, руководствуясь заложенными в Oracle Expert правилами, автоматически готовит скрипты, необходимые для настройки системы, и АБД остается их только выполнить. Конечно никакая, даже экспертная система, не заменит хорошего администратора. Но она может облегчить и ускорить его работу, указав направление правильного движения. Что касается начинающих АБД, то Oracle Expert может не только выполнять их работу по настройке БД, но и объяснить свои действия и, тем самым, постепенно повышать их квалификацию. Заложенные в Oracle Expert правила настройки разработаны опытными администраторами Oracle и учитывают все механизмы последних версий Oracle, о которых АБД может и не знать. Кроме того, АБД может добавить свои правила в систему и расширить ее возможности.

Основная идея работы Oracle Expert состоит в том, что он собирает статистические данные о БД и экземпляре Oracle, схеме БД, компьютере, на котором работает БД и о работе приложений (workload). Статистика может собираться втечение некоторого заданного интервала времени, чтобы отследить динамику изменений в системе. После анализа собранных данных Oracle Expert строит отчеты о собранной статистике, выдает рекомендации о путях решения обнаруженных проблем и генерирует скрипты, выполнение которых поможет разрешить эти проблемы. АБД вовсе не обязан принимать на веру все рекомендации Oracle Expert. Он может ознакомиться с описанием причин, по которым Oracle Expert выдал эту рекомендацию, и принять или отвергнуть ее. Вся собранная статистика и выработанные рекомендации хранятся в репозитории Oracle Expert.

Процесс настройки с помощью Oracle Expert начинается с того, что АБД определяет сферу настраиваемых компонент и характеристики настройки. Для этого помощник (wizard) Oracle Expert создает новый сеанс настройки. АБД может настраивать: экземпляр Oracle, SQL операторы, схему и параметры хранения БД и методы доступа к БД. При настройке методов доступа выдаются рекомендации по созданию или перестройке индексов, причем Oracle Expert может ориентироваться как на все имеющиеся в кэше операторы SQL, так и только на операторы SQL с наихудшей производительностью.

При создании сеанса следует указать тип приложения (OLTP, DSS, смешанное). Это повлияет на то, какие правила будут применяться при работе Oracle Expert. АБД может также указать: допустимое время простоя системы, ожидаемый уровень нагрузки по записи (малый, средний, большой), используются ли приложения Oracle Forms. После определения сеанса настройки Oracle Expert начинает сбор статистики. Он может сам выполнить команду Analyze или использовать данные из словаря БД. Может Oracle Expert и воспользоваться статистикой, собранной модулем Trace manager.

Что же анализирует Oracle Expert? Для экземпляра Oracle собираются данные о параметрах экземпляра, размерах областей памяти, вводе/выводе, сортировке, использовании распараллеливания операций. Много информации и текущей статистики берется из динамических таблиц V$. Для анализа информации о БД Oracle Expert определяет размер блока, использование Parallel server, имя БД, информацию о пользователях, табличных пространствах, сегментах отката. Для анализа доступа собираются данные о схемах и пользовательских объектах, кардинальности и объеме таблиц, физической и логической структуре БД. Данные берутся как из динамических таблиц, так и из управляющего (control) файла. И, наконец, для анализа загрузки системы Oracle Expert собирает данные о частоте выполнения и важности SQL операторов, настройках оптимизатора, статистике SQL операторов.

Вся эта информация собирается автоматически. Единственное, что надо указать вручную, - это информацию о компьютере (память, число процессоров и т. д.). После сбора статистики Oracle Expert применяет к ней свои правила и оптимизирует: SQL операторы, параметры экземпляра, методы доступа, структуры данных, параметры хранения данных. Пример выдаваемых рекомендаций можно видеть на рисунке 5.

Рис. 5. Рекомендации Oracle Expert

Рекомендации могут быть самыми разными, от удаления пользовательских данных из табличного пространства SYSTEM и создания дополнительных индексов, до изменения настроечных значений файла параметров экземпляра. Oracle Expert при этом выполняет за АБД сложные вычисления и тесты. Например, если Ваш буферный кэш мал и его надо увеличить, то АБД должен знать, какова будет оптимальная величина этого буфера. Для того, чтобы определить эту оптимальную величину, следует работать с внутренними таблицами словаря, определяя какой эффект даст тот или иной квант приращения/уменьшения буфера. Это довольно сложная и нудная работа. А Oracle Expert сразу выдаст АБД оптимальный требуемый размер буфера.

Максимальную выгоду при настройке приложения может дать настройка плохо написанных SQL операторов. Это итеративная работа, практически метод проб и ошибок. Автоматическая настройка SQL с помощью стоимостного оптимизатора (cost based) не всегда дает наилучший эффект. Для выполнения работы по настройке SQL в состав Tuning Pack входит модуль SQL Analyze. Он позволяет АБД выбрать критичный по использованию ресурсов оператор SQL либо прямо из кэша, либо из файла, либо ввести (вклеить) текст руками. Далее мы можем экспериментировать с этим оператором, менять планы его выполнения и каждый раз оценивать статистику выполнения, добиваясь минимального времени выполнения этого оператора.

SQL Analyze создает планы выполнения для различных режимов оптимизации (Rule, Cost first rows, Cost all rows, Choose). Планы графически отображаются в виде дерева шагов выполнения и мы можем “оживить” этот план, заставив SQL Analyze пошагово показывать какой шаг за каким выполняется, что делает, сколько строк данных возвращает, какие типы соединения таблиц (join) использует и т. д. Уже здесь видно отсутствие или неиспользование индексов, нежелательная последовательность шагов и т. д. Для каждого варианта плана выполнения считается статистика, исследование которой может помочь в оптимизации. Экран всегда можно “расщепить” на две части, чтобы сравнить планы и статистики разных версий одного и того же оператора.

АБД может модифицировать SQL оператор вручную, меняя синтаксис для Rule based оптимизатора или вставить подсказки (Hint) для Cost based оптимизатора. Однако можно “напустить” на SQL оператор SQL Tuning Wizard, который, в соответствии с заложенными в него правилами, проанализирует этот оператор и модифицирует его для оптимального выполнения. SQL Tuning Wizard работает достаточно эффективно, учитывает не только время выполнения, но и другую статистику SQL оператора.

Если же Вы решили сами вставлять подсказки (hint) в SQL оператор, то Вам не надо помнить их синтаксис и смысл. Компонента Hint Wizard поведет с Вами диалог и вставит выбранные подсказки в указанное место оператора. Таким образом, после применения SQL Analyze Вы можете получить оптимальный вариант Вашего сложного SQL оператора.

В состав Tuning Pack входит также модуль Index Tuning Wizard. Он анализирует указанную схему данных и дает рекомендации о том, какие дополнительные индексы следует построить.

Пакет Oracle Tuning Pack включает следующие модули:

· Index Tuning Wizard

· Oracle Expert

· Reorg Wizard

· SQL Analyze

· Tablespace Map

Он позволяет решать все проблемы, связанные с настройкой БД и приложений.

4. Планирование использования ресурсов

Часто перед АБД встают вопросы типа:

· “Почему я расходую дисковое пространство так быстро?”

· “Каковы будут мои потребности в оборудовании в следующем году?”

· “Когда мне потребуется увеличить память моего сервера и на сколько?”

и т. д.

Модуль Capacity Planer, входящий в состав Diagnostic Pack, позволяет ответить на эти вопросы заранее, согласовать с начальством и заложить в бюджет покупку нового оборудования задолго до возникновения проблемы. Идея работы Capacity Planer достаточно проста. Он собирает статистику, заказанную Вами, о работе БД и узлов, агрегирует ее и строит на основе этой статистики график изменения анализируемых параметров (например, как меняется во времени количество свободного места в табличном пространстве). Далее на основе этой статистики система может применить простой алгоритм прогнозирования и продлить этот график на интервал времени в будущем (рис 6). На основе такого прогнозирования с учетом тенденции изменения графика Capacity Planer позволяет ответить на два простых, но очень важных вопроса:

1. Когда кривая (график) достигнет указанной величины (например, какого числа свободного места в табличном пространстве останется меньше хх Мб и его надо будет увеличивать?)

2. Каково будет значение параметра (кривой) в заданное время в будущем (например, сколько при такой скорости использования места в табличном пространстве его останется 1 января 2001 года?)

Для того, чтобы проводить анализ, надо вначале включить сбор статистики для выбранных параметров анализа. Параметры сгруппированы в классы. Так для БД можно собирать статистику и делать прогноз для параметров, связанных с вводом/выводом, конкуренцией за ресурсы, экземпляром Oracle, загрузкой БД, использованием оперативной памяти, пользователями. Можно создать и свой класс. Всего для БД можно анализировать более 50 параметров. Существует множество параметров и классов и для узлов сети.

Набор параметров, по которым включен сбор статистики, называется коллекцией. Для коллекции мы указываем частоту сбора статистики (каждый час или несколько раз в месяц/год), продолжительность ее хранения в репозитории, где она накапливается (например, 1 год).

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

Графики Capacity Planer позволяют АБД:

n оценить корреляцию тенденций использования ресурсов;

n понять историю изменения производительности системы и использования ресурсов;

n предвидеть момент исчерпания ресурсов;

n планировать будущие потребности в ресурсах.

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

Рис. 6. Графики Capacity Planer

5. Модификация структуры БД прикладных систем

Пакет Oracle Change Management Pack сильно облегчает работы, связанные с изменением структуры БД и хранящихся в ней объектов, а также тиражирование изменений из базы разработчика в эксплуатационные базы. Change Management Pack реализует следующую методологию модификации БД: определяется текущее состояние БД и ее структур, это состояние сравнивается с предыдущим состоянием, выявляются различия и на основе их формируется план внесения изменений в другие БД. Далее проводится анализ влияния и допустимости таких изменений, строится отчет и скрипты для выполнения изменений. После чего можно запустить эти скрипты на выполнение.

Практически все работы сопровождаются помощниками и подсказками, а для реализации сложных изменений Change Management Pack сам формирует набор SQL операторов. Поскольку все операции выполняются под контролем пакета и через простой графический интерфейс, то вероятность ошибок и потерь данных снижается. Кроме того, пакет позволяет откатить (отменить) неверно сделанные изменения.

В состав пакета входят следующие модули, вызывающиеся как пункты меню:

DB Search - позволяет искать объекты любого типа в БД по имени или части имени и смотреть их характеристики.

DB Capture - позволяет провести реинженеринг всей базы, ее частей, отдельных схем. При этом результаты таких реинженерингов (называемые baseline) можно сохранить и затем использовать при сравнении различных состояний БД.

DB Diff - позволяет сравнить две БД или два baseline или БД и baseline (или их части, например, таблицы). В результате сравнения строится отчет о найденных различиях. Можно сравнивать не только пользовательские объекты БД, но и системные объекты (профили, роли, сегменты отката и т д.). Прямо из DB Diff можно запустить компоненту Synchronization Wizard, которая поможет исправить одну из сравниваемых БД так, чтобы она пришла в соответствие со вторым объектом сравнения. Какой объект будет синхронизироваться, АБД выбирает сам.

Два модуля DB Quick Change и DB Alter позволяют быстро модифицировать любые характеристики объектов БД. Вы можете менять не только структуру объектов, но и их параметры хранения, при этом Change Manager выполнит все работы по перемещению и пересозданию объектов. Отличие DB Alter от DB Quick Change заключается только в том, что DB Quick Change позволяет модифицировать только один объект в одной БД, а DB Alter формирует планы внесения изменений во многие объекты и эти планы могут быть применены к нескольким БД.

DB Propagate позволяет выбрать в мастер базе группу объектов и скопировать/воссоздать эти объекты в других БД. При этом учитывается взаимосвязь объектов. Копироваться могут не только описания объектов, но и данные.

Таким образом, Change Management Pack позволяет Вам делать изменения в экспериментальной БД и после того, как они будут признаны успешными, распространить их на эксплуатационные БД. Главным достоинством пакета является то, что прежде чем делать изменения, он проводит сложный анализ зависимостей, и АБД всегда может знать последствия своих действий по изменению БД и может быть уверен в качестве и согласованности выполнения этих изменений.

VI. Заключение

Oracle Enterprise Manager и его пакеты позволяют упростить, ускорить, а иногда и автоматизировать выполнение сложных операций. Это позволяет АБД сосредоточить свое внимание на выполнении сложных творческих задач поддержания системы. Использование этих средств помогло многим компаниям. Например, мы имеем следующие отзывы:

· Компания Deluxe Checks: “Производительность системы возросла на 20%”

· Компания John Deere: “Время выполнения запроса уменьшилось с 45 минут до нескольких секунд”

· Компания Cargill: “Стоимость поддержания системы снизилась на 1/3”