Профессионалу администратору

Мугес А. Миньяс,
Server Technologies,
Oracle Corporation.

Лучшие практические методы администрирования СУБД Oracle9i
(Oracle9i Database Administration Best Practices,
by Mughees A. Minhas, Server Technologies, Oracle Corporation.)
(часть II)

Источник: OracleWorld, Copenhagen, Denmark, 24-27 June 2002, http://www.oracle.com/pls/oow/oow_user.show_public?p_event=12&p_type=session&p_session_id=15509

Оптимизация производительности

Плохо настроенная система – это только небольшой шаг, чтобы система стала недоступной. Настройка системы баз данных должна обеспечивать приемлемую производительность, поэтому настройка имеет у АБД высший приоритет. В СУБД Oracle9i появилось несколько новых функциональных возможностей, облегчающих настройку. Марк Шейман (Mark Shaiman), старший научный аналитик компании META Group, подтверждает: “Хотя СУБД Oracle всегда обладала существенными функциональными возможностями, в общем, для достижения оптимальной производительности требовались различные "настройки". В СУБД Oracle9i автоматизированы многие вспомогательные процессы, позволяющие АБД облегчить сопровождение и обеспечить "дружественность по отношению к пользователям" ”. В этом разделе мы обсудим ряд хороших практических методов в свете новых возможностей СУБД Oracle9i.

Общая методология

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

1. Регулярный сбор полного набора статистических показателей операционной системы, экземпляров СУБД и приложений.

2. Определение проблемных областей.

Рис. 2. На первой странице типового отчета утилиты StatsPack на первом плане размещаются ключевые данные о системе.

3. Определение потенциальных решений.

4. Реализация решений.

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

5. Повторение процесса.

Настройка кеша буферов.

Некоторые структуры оперативной памяти СУБД, такие, как кеш буферов, существенно влияют на производительность СУБД. Несмотря на то, что утилита StatsPack раскрывает тайны процесса настройки, важность хорошо настроенного кеша буферов заслуживает более строгого метода. С этой целью в СУБД Oracle9i введен механизм консультативной справки по кешу буферов (Buffer Cache Advisory). Эта справка выдается по результатам внутреннего моделирования, основанного на текущей рабочей нагрузке. Справка предсказывает частоту неудачных обращений к кешу для различных размеров кеша буферов в диапазоне от 10% до 200% текущего размера кеша. Эти предсказания публикуются через новое представление V$DB_CACHE_ADVICE, которое можно использовать для определения оптимального размера кеша буферов при существующей рабочей нагрузке. В Oracle Enterprise Manager имеется удобное средство, которое интерпретирует данные представления V$DB_CACHE_ADVICE (см. рис. 3). Обеспечивая детерминированный способ определения размера кеша буферов, СУБД Oracle9i берет на себя работу по предсказанию конфигурации кеша буферов.

Рис 3. Консультативная справка по кешу буферов.

АБД должны использовать эту консультативную справку для настройки кеша буферов. Все консультативные справки, включая консультативную справку по кешу буферов, и сбор статистических данных в СУБД Oracle9i Release 2 управляются с помощью одного параметра STATISTICS_LEVEL (уровень сбора статистических данных). У него может быть три возможных значения: BASIC (базовый), TYPICAL (типовой) и ALL (все). Значение по умолчанию – TYPICAL. Значения TYPICAL и ALL позволяют включать в сервере механизмы создания консультативных справок: Buffer Cache Advisory (кеш буферов), Shared Pool Advisory (разделяемый пул), PGA Advisory (программная глобальная область) и MTTR Advisory (ожидаемое среднее время восстановления). При этом оказывается незначительное влияние на производительность, связанное со сбором данных и моделированием кеша. Однако выгоды от надлежащим образом настроенной памяти намного перевешивают эти накладные расходы.

Настройка разделяемого пула.

Разделяемый пул, так же как и кеш буферов, представляет собой важную структуру оперативной памяти, которую необходимо тщательно настраивать для обеспечения высокой производительности сервера базы данных. Влияние настройки разделяемого пула на время реакции СУБД Oracle идентично настройке кеша буферов – облегчайте настройку, используя консультативные справки, которые основаны на внутреннем моделировании рабочей нагрузки. Статистические данные консультативной справки по разделяемому пулу (Shared Pool Advisory) позволяют отслеживать использование библиотечного кеша в памяти разделяемого пула и предсказывать изменение общего времени разбора на уровне экземпляра для различных размеров разделяемого пула. Два новых представления, V$SHARED_POOL_ADVICE и V$LIBRARY_CACHE_MEMORY содержат информацию для определения, сколько памяти используется для библиотечного кеша, сколько памяти закреплено в настоящее время, сколько объектов в LRU-списке разделяемого пула, а также сколько времени может быть потеряно или сэкономлено при изменении размера разделяемого пула. Представление V$SHARED_POOL_ADVICE содержит информацию о расчетной экономии времени разбора для различных размеров разделяемого пула. Эти размеры варьируются в пределах от 50% до 200% текущего размера разделяемого пула с равными интервалами изменения. В Oracle Enterprise Manager имеется средство графической визуализации этого моделирования, с которым проще работать, чем с представлением V$SHARED_POOL_ADVICE через интерфейс командной строки (см. рис. 4).

Рис. 4. Консультативная справка по разделяемому пулу.

Консультативная справка по разделяемому пулу также управляется с помощью параметра STATISTICS_LEVEL. Когда в параметре установлены значения TYPICAL или ALL, механизм создания этой справки включается, для его отключения следует установить значение BASIC. Как отмечено ранее, с помощью параметра STATISTICS_LEVEL выполняется управление сбором статистических данных для всех консультативных справок. Установка в нем значения BASIC отключит все справки.

Настройка памяти для выполнения операторов SQL.

Производительность выполнения сложных долго работающих запросов, типичных в DSS-среде, существенно зависит от размера памяти, доступной в программной глобальной области (PGA, Program Global Area). В СУБД Oracle8i администраторы устанавливают размер PGA, тщательно настраивая ряд параметров инициализации, таких, как SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE, CREATE_BITMAP_AREA_SIZE и т.д. В СУБД Oracle9i появилась опция полностью автоматического управления памятью PGA. Администраторам нужно просто указать максимальный объем памяти PGA, доступной экземпляру СУБД. Для этого используется новый параметр инициализации PGA_AGGREGATE_TARGET (суммарная память PGA). Сервер базы данных автоматически некоторым интеллектуальным способом распределяет эту память между различными активными запросами так, чтобы обеспечить максимальную производительность и наиболее эффективно использовать память. Кроме того, СУБД Oracle9i может сама адаптироваться к изменению рабочей нагрузки, таким образом ресурсы используются эффективно независимо от нагрузки на систему. Объем памяти PGA, доступной экземпляру, можно изменять динамически, изменяя значение параметра PGA_AGGREGATE_TARGET. Это позволяет оперативно добавлять или отнимать память PGA у активного экземпляра. АБД должны использовать данную опцию и не пытаться настраивать PGA вручную, поскольку машина базы данных лучше оснащена средствами определения потребностей в памяти для выполнения операторов SQL. Это относится как к повышению пропускной способности систем с большим количеством пользователей, так и к уменьшению времени ответа при выполнении запросов.

С этой самонастраивающейся PGA единственная остающаяся задача для АБД состоит в том, чтобы установить надлежащим образом значение параметра PGA_AGGREGATE_TARGET. Это очень просто делать с помощью новой консультативной справки по размеру PGA (PGA Advisory), введенной в СУБД Oracle9i Release 2. Как и консультативная справка по кешу буферов эта справка использует внутреннее моделирование для предсказания оптимального размера PGA при текущей рабочей нагрузке. В представлении V$PGA_TARGET_ADVICE содержатся результаты этого моделирования, показывающие надлежащее значение параметра PGA_AGGREGATE_TARGET. В Oracle Enterprise Manager имеется очень простое средство графической визуализации этого моделирования (см. рис. 5).

Рис. 5. Консультативная справка по PGA.

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

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

Общие причины проблем производительности

Итак, мы обсудили лучшие практические методы оптимизации производительности, давайте сейчас рассмотрим методы, использование которых приводит к возникновению проблем производительности. Наша рекомендация здесь очень простая: "избегайте их".

1. Плохое управление соединениями.

   Приложение соединяется и отсоединяется от базы данных при каждом взаимодействии с ней. Это – обычная проблема программного обеспечения промежуточного слоя в серверах приложений. Эта ошибка снижает производительность более чем на два порядка, а также полностью отсутствует масштабируемость. Возможное решение – трехзвенная архитектура, когда пользователи или клиенты соединяются со средним звеном, который имеет постоянные соединения с базой данных. Таким образом, одно постоянное соединение с базой данных может быть использовано разными пользователями.

2. Плохое совместное использование курсоров.

   Отсутствие разделения курсоров приводит к многократным разборам. Если не используются переменные связывания, то выполняется полный разбор (hard parsing) всех операторов SQL. Это имеет существенное отрицательное влияние на производительность. В курсорах, которые открываются и повторно используются много раз, следует использовать переменные связывания. Для больших приложений, в которых не используются переменные связывания, разделение курсоров можно включить принудительно, установив параметр инициализации CURSOR_SHARING=FORCE.

3. Неправильное конфигурирование ввода-вывода.

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

4. Проблемы конфигурирования журнала базы данных.

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

5. Нехватка списков свободных блоков, групп списков свободных блоков и сегментов отката.

   В кеше буферов может возникать сериализация блоков данных из-за нехватки списков свободных блоков (free lists), групп списков свободных блоков (free list groups), участков транзакций (INITRANS) или сегментов отката (rollback segments). Особенно часто это возникает в приложениях, часто выполняющих операции вставки данных в базу данных с большим размером блоков (от 8Kб до 16Kб). Этой проблемы легко избежать, используя опцию автоматического управления пространством сегментов (Automatic Segment Space Management) вместе с опцией автоматического управления откатом (Automatic Undo Management).

6. Длительные полные просмотры таблиц.

   Длительные полные просмотры таблиц в операциях большого объема или в интерактивных операциях, выполняемых в оперативном режиме, могут указывать на неудовлетворительное проектирование транзакций, отсутствие индексов или плохую оптимизацию операторов SQL. Длительные полные просмотры таблиц по своей природе являются операциями, интенсивными по вводу-выводу и немасштабируемыми при увеличении количества пользователей. В пакете настройки (tuning pack) Enterprise Manager предлагается мощный инструмент, SQL-анализатор (SQL Analyze), для обнаружения и оптимизации операторов SQL, интенсивно потребляющих ресурсы. Это – хороший способ решения проблем оптимизации операторов SQL.

7. Дисковые сортировки.

   Дисковые сортировки, в противоположность сортировкам в оперативной памяти, могут в операциях, выполняемых в оперативном режиме, указывать на неудовлетворительное проектирование транзакций, отсутствие индексов, неоптимальное конфигурирование PGA или плохую оптимизацию операторов SQL. Дисковые сортировки по своей природе являются операциями, интенсивными по вводу-выводу и немасштабируемыми. Эту проблему можно устранить, выделяя память PGA достаточного размера и используя опцию автоматической настройки PGA (Automatic PGA Tuning), рассмотренную выше.

8. Большие объемы рекурсивных операций SQL.

   Большие объемы рекурсивных операций SQL, выполняемых в схеме SYS, могут указывать, что имеют место действия по управлению пространством, такие, как выделение экстентов. Эти действия немасштабируемы и влияют на время реакции системы. Обычно это возникает при использовании табличных пространств, управляемых с помощью словаря данных, (dictionary managed tablespaces). В таких случаях повышению производительности может помочь использование локально управляемых табличных пространств (locally managed tablespaces), существенно уменьшающих объемы рекурсивных операций SQL.

9. Ошибки схем и оптимизатор.

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

10. Использование нестандартных параметров инициализации.

Резервирование и восстановление

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

У бизнеса должна быть стратегия восстановления после катастроф, которые приводят к потере данных. В настоящее время только 45% компаний из списка крупнейших компаний мира (Fortune 500) имеют формальные стратегии для своей защиты от бедственной потери данных. Только 12% из этих стратегий рассматриваются на корпоративном уровне ("Calculating the Cost of Downtime" (вычисление стоимости времени простоя), Анжела Карр (Angela Karr), Advanstar Communications). При разработке формальной стратегии АБД должны планировать потерю данных из-за неожиданных отказов, причинами которых могут быть аппаратные или программные сбои, человеческие ошибки, природные явления и т.д. Для каждого из таких возможных событий АБД должны иметь план действий. В некоторых случаях может потребоваться восстановление носителя, в других будет достаточно восстановления экземпляра. Для обеих этих ситуаций АБД должны иметь планы действий. Мы рассмотрим их в этом разделе ниже. В конце концов, администратор базы данных и системный администратор должны документировать среду базы данных и стратегии восстановления, чтобы при возникновении сбоя АБД мог диагностировать проблему и немедленно заняться ее решением.

Планирование восстановления экземпляра

Работа систем может аварийно завершаться по разным причинам, например, из-за прекращения подачи электроэнергии. В этом случае после перезапуска экземпляра СУБД и до открытия базы данных для пользователей будет выполняться восстановление экземпляра. Цель восстановления экземпляра – восстановление физического содержимого базы данных в транзакционно согласованное состояние. Поэтому во время восстановления должны применяться все сделанные зафиксированными транзакциями изменения, которые находились в кеше буферов и не были записаны на диск до сбоя, а затем выполняется откат всех записанных на диск изменений, сделанных незафиксированными транзакциями. Восстановление экземпляра выполняется внутренними механизмами СУБД Oracle и не требует вмешательства администратора. Единственный аспект, о котором должен заботиться АБД – продолжительность выполнения восстановления; это легко контролируется настройкой в файле инициализации параметра FAST_START_MTTR_TARGET (MTTR – mean time to recover, среднее время восстановления). В системах, в которых размер кеша буферов составляет много гигабайтов, восстановление экземпляра может быть очень длительным с совершенно не предсказуемым временем восстановления. Для АБД оба эти свойства мало допустимы. Новая опция быстрого восстановления с предсказуемым временем (Fast-Start Time-Based Recovery) в СУБД Oracle9i позволяет АБД задавать среднее время восстановления экземпляра (в секундах) с помощью установки значения в параметре FAST_START_MTTR_TARGET. Эта опция реализуется ограничением количества "грязных" буферов и количества журнальных записей, сгенерированных после последней контрольной точки. Для обеспечения заданного времени восстановления сервер базы данных по существу регулирует скорость выполнения контрольных точек.

Если в параметре FAST_START_MTTR_TARGET установлено слишком низкое значение, сервер базы данных будет писать на диск очень часто, и это может привести к снижению скорости работы системы. Поэтому этот параметр необходимо настраивать так, чтобы сервер не выполнял чрезмерное количество контрольных точек, но при этом время восстановления оставалось бы в приемлемых пределах. С этой целью в СУБД Oracle9i Release 2 введена новая консультативная справка по MTTR (MTTR Advisory). Эта справка позволяет экземпляру оценивать (в процентах) изменение количества записей на диск, которое могло бы произойти при других значениях в параметре FAST_START_MTTR_TARGET. Используя оценку, полученную при типичной рабочей нагрузке на экземпляр, вы можете определить влияние повышения или понижения значения в данном параметре. Значения консультативной справки по MTTR содержатся в представлении V$MTTR_TARGET_ADVICE. Это представление имеет пять строк, которые показывают предполагаемую дисковую активность при различных значениях в параметре FAST_START_MTTR_TARGET: текущее значение; приблизительно десятая часть текущего значения; приблизительно половина текущего значения; приблизительно полтора текущего значения и приблизительно двойное текущее значение. В Enterprise Manager можно получить графическое представление консультативной справки по MTTR (см. рис. 6).

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

Рис. 6. Консультативная справка по MTTR.

Планирование восстановления носителя

Стратегия резервирования

Восстановление носителя требуется всегда, когда теряются данные. Наиболее общие причины потери данных: сбои носителя и человеческие ошибки. Для того чтобы можно было восстанавливать носитель, сервер базы данных должен функционировать в режиме ARCHIVELOG (архивирование журнала). Его легко включить с помощью оператора ALTER DATABASE. Затем АБД должны выбрать метод резервирования. В прошлом АБД писали свои собственные скрипты для резервирования базы данных. Сейчас делать это уже нецелесообразно, так как утилита Recovery Manager (диспетчер восстановления) лучше оснащена для управления резервированием. Утилита Recovery Manager имеет вариант с интерфейсом командной стоки, а также вариант с графическим интерфейсом, встроенным в Enterprise Manager. Утилита Recovery Manager позволяет пользователям специфицировать все их требования резервирования, например, полное оперативное резервирование базы данных на ленту, автономное резервирование всей базы данных на диск и т.п. Более того, использование средств планирования в Enterprise Manager позволяет запускать задания создания резервных копий в заданное время, как регулярно, так и по потребности. Хорошая практическая рекомендация: вместе с резервными копиями файлов данных базы данных создавать резервную копию управляющего файла. Резервную копию управляющего файла, как минимум, необходимо создавать при изменении структуры базы данных.

Для тех администраторов, которым требуются также файлы систем резервирования, корпорация Oracle инициировала, совместно с поставщиками систем управления носителями, программу решения проблем резервирования (Backup Solution Program, http://otn.oracle.com/deploy/availability). Участники этой программы – сторонние поставщики, инструментальные средства которых обеспечивают комплексное решение вопросов резервирования как системных файлов, так и файлов базы данных Oracle. Это лучше использования для управления резервированием двух отдельных инструментов, Recovery Manager или Enterprise Manager для файлов базы данных Oracle и отдельного инструмента для системных файлов.

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

Стратегия восстановления

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

1. Сбой носителя.
   Обычный пример сбоя носителя – разрушение дисковых головок, которое приводит к потере всех файлов базы данных, размещенных на диске. Для полного отказа диска уязвимы все файлы, связанные с базой данных, включая файлы данных, управляющие файлы, оперативные и архивные журнальные файлы. Восстановление после сбоя носителя включает в себя копирование всех неисправных файлов из резервной копии, а затем их восстановление. В наихудшем случае может потребоваться копирование и восстановление всей базы данных. Сбой носителя – первостепенная задача стратегии резервирования и восстановления, поскольку во время восстановления обычно требуется копировать некоторые или все файлы базы данных, а затем применять для их восстановления журнальные файлы.
2. Человеческая ошибка.
   Пользователи могут непредумышленно удалять данные или уничтожать таблицы. Хороший способ минимизации последствий таких ситуаций – предоставлять пользователям только такие привилегии базы данных, которые им безусловно необходимы. Но человеческие ошибки будут по-прежнему возникать и АБД должны быть готовы к работе над ними. Создание логических резервных копий или экспорт таблиц – хороший способ справляться со случайными уничтожениями таблиц. Ретроспективный запрос (Flashback Query), новое средство, введенное в СУБД Oracle9i, очень хорошо подходит для восстановления после случайных удалений или вставок. Последним средством, к которому можно прибегнуть, является копирование из резервной копии и восстановление всего табличного пространства, содержащее объекты, на которые подействовала человеческая ошибка. Существуют различные методы восстановления после человеческих ошибок, и все они должны быть протестированы.
3. Повреждение блоков данных.
   Неисправная аппаратура или ошибка операционной системы могут быть причиной повреждения блоков данных, в результате которого их формат не будет распознаваться СУБД Oracle или их содержимое будет внутренне несогласованным. В СУБД Oracle имеется средство восстановления носителя на уровне блоков (Block Media Recovery), которое копирует и восстанавливает только поврежденные блоки, и не требует восстановления всего файла данных. Это уменьшает среднее время восстановления (MTTR, Mean Time to Recovery), так как копируются и восстанавливаются только те блоки, которые требуется восстановить, а испорченные файлы данных остаются в оперативном режиме.
4. Стихийные бедствия.
   Землетрясения и наводнения могут привести к полному разрушению оборудования информационного центра. В таких случаях требуется копирование из резервных копий и восстановление на альтернативных установках. Это неизбежно влечет за собой необходимость поддержки резервных копий не только на основной установке, но и на альтернативной. "Внешнее" копирование и восстановление следует тщательно тестировать и планировать по времени, чтобы бизнес мог выдержать такие стихийные бедствия без компрометирования своих соглашений об уровнях сервиса.

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

Заключение

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

Благодарности

Идеи этой работы разрабатывались с помощью многих экспертов корпорации Oracle. Их вклад очень ценен. Особые благодарности Грэму Вуду (Graham Wood), Бенуа Дажвилю (Benoit Dageville), Алексу Цукерману (Alex Tsukerman), Рону Вайссу (Ron Weiss) и Сушиле Кумар (Sushil Kumar) за их вклад и обратную связь.

Ссылки

1. J. Loaiza. Optimal Storage Configuration Made Easy, http://otn.oracle.com/deploy/performance/index.htm
2. S. Kumar. Server Manageability: DBA’s Mantra for a Good Night’s Sleep.
3. G. Wood, C. Dialeris. Diagnosing Performance Using StatsPack, http://otn.oracle.com/deploy/performance/index.htm
4. Oracle White Paper: Oracle Performance Improvement Method, http://otn.oracle.com/deploy/performance/index.htm
5. T. Lahiri, et al. Fast-Start: Quick Fault Recovery in Oracle, http://web06-02.us.oracle.com/deploy/availability/techlisting.html
6. T. Bednar. Database Backup and Recovery: Strategies and Best Practices.
7. Oracle9i DBAs Guide, Release 1 (9.0.1) (Прим. пер. Имеется также русский перевод: Сервер Oracle9i. Руководство администратора. Выпуск 2 (9.2). Его можно заказать в http://www.rdtex.ru/.)
8. Oracle9i Database Performance Guide and Reference, Release 1 (9.0.1)
6. Oracle9i Database Concepts, Release 1 (9.0.1) (Прим. пер. Имеется также русский перевод: Сервер Oracle9i. Основные концепции. Выпуск 2 (9.2). Его можно заказать в http://www.rdtex.ru/.)
7. Oracle9i Performance Methods, Release 1 (9.0.1)
8. Oracle Technology Network, http://otn.oracle.com