12 вариант 2 (954078), страница 19

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 19)

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

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

Параллельная обработка

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

Опция параллельного сервера

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

Предположим, что имеется кластер из двух серверов, на каждом сервере находится база данных и каж­дая база данных разделяет общие файлы данных. Если по каким-то причинам происходит отказ базы дан­ных 1 (например, аппаратный отказ), пользователей базы данных 1 можно перенаправить в базу данных 2. База данных 2 может использоваться как резервная копия базы данных 1 и наоборот.

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

Опция параллельного запроса

Опция параллельного запроса представляет собой возможность воспользоваться наличием нескольких процессоров на сервере. При использовании этой опции на нескольких процессорах можно разделить запросы базы данных в Oracle на несколько меньших запросов и назначить их ряду процессов. Каждый процесс разрешит свой запрос, а затем объединит результаты в единый набор результатов. Этот процесc называется распараллеливанием или параллельной обработкой. Опция параллельного запроса особенно полезна в среде хранилищ данных или поддержки принятия решений, где выполняются сложные и сумми­рующие запросы, а для загрузки базы данных применяются пакетные транзакции.

В Огас1е8 в дополнение к поддержке оператора SELECT в предыдущих версиях обеспечивается возможность параллельного выполнения транзакций INSERT, UPDATE и DELETE. Параллельные манипуляции с данными обеспечивают возможность более быстрой загрузки данных в пакетном режиме по сравнению с загрузкой без параллельной опции.

Число процессов, используемых для выполнения запроса, зависит от указанной степени распаралле­ливания. Опция параллельного запроса может быть вызвана для каждой таблицы после ее создания с ис­пользованием фразы PARALLEL, как показано в следующем примере:

create table table_name (columni, column2, ...)

storage (storage options)

parallel degree (default);

create table table_name columni, coluinn2, . . .)

storage (.storage options)

parallel degree (n);

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

Лучше не вызывать опцию запроса parallel на сервере с одним процессором, поскольку это приведет к снижению производительности, а не к ее повышению.

Сбор статистики. Инструментальные средства настройки производительности.

Первым и наиболее важным шагом в настройке базы данных является сбор статистики о текущей про­изводительности базы данных. Такие инструментальные средства дают представление о том, какова теку­щая производительность базы данных, и позволяют DBA оценивать достигнутые успехи, измеряя результаты выполненной работы.

Просмотр SGA и установок параметров

Для просмотра текущих установок параметров экземпляра RDBMS Oracle применяется Oracle Server*Manager. Команда show sga показывает текущий размер и структуру SGA. Команда show parameter позволяет также отображать параметры INIT.ORA. Для просмотра только определенного параметра укажите его в команде. Например:

% svrmgri

SVRMGR> Connect internal

Connected.

SVRMGR> show parameter block

Отображаются все параметры базы данных, даже те, которые не были явно установлены в файле па­раметров INIT.ORA. Параметры, не установленные DBA, отображаются со своими значениями по умол­чанию. Выведя этот список в файл данных, DBA может получить точный снимок установок базы данных

Утилиты utibstat и utiestat

Чтобы определить, что нужно исправить в экземпляре RDBMS Oracle, необходимо вначале узнать, что неисправно. Иногда проблемы производительности возникают случайным образом; однако обычно они имеют определенную картину. Происходят ли они в обеденное время? Вечером? Рано утром? Одной из предпосылок успешной настройки производительности является способность определить время возникнове­ния проблемы.

В Oracle предусмотрены инструментальные средства, позволяющие подробно изучить, что происходит в RDBMS Oracle в определенный период времени. Это утилиты "открыть статистику" (utibstat) и "закстатистику" (utiestat). Эти сценарии позволяют получить снимок работы экземпляра за определенный ин­тервал времени. Они для сбора информации используют динамические таблицы производительности Oracle (V$).

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

Для использования utibstat и utiestat необходимо запустить базу данных, установив значение TIMED_STATISTICS в файле параметров INIT.ORA в TRUE. В противном случае Oracle не соберет неко­торую информацию, необходимую для отчета. Однако при установке TIMEDJSTATISTICS в TRUE в эк­земпляре базы данных возникают непроизводительные издержки. Они невелики — составляют всего около 4-8% в количественном выражении — и необходимы для получения точных характеристик производитель­ности базы данных. Многие DBA устанавливают этот параметр в TRUE только во время сбора статистики.

Установив требуемые параметры (база данных должна поработать достаточно долго) и определив нужное окно, можно выполнить снимок с использованием utibstat. Для выполнения любого из этих сценариев вы доджны иметь возможность подключиться к базе данных по connect internal. Запустив utibstat, вы укажете экземпляру RDBMS, чтобы он начал собирать статистику, пока не получит другого распоряжения. Это производится следующим образом:

% svrmgri SVRMGR> @$ORACLE_HOME/rdbms/admin/utlbstat

С момента выполнения этого сценария экземпляр RDBMS Oracle будет собирать статистику произво­дительности. Он будет это делать до тех пор, пока не будет выполнен сценарий utiestat, который остано­вит сбор статистики производительности. Необходимо учитывать, что во время выполнения utibstat база данных должна оставаться активной и ее нельзя останавливать.

% svrmgri SVBMGR> @$ORACLE_HOME/rdbms/admin/utlestat

После выполнения utiestat база данных создаст отчет под названием REPORT.TXT в текущем катало­ге, который будет содержать собранную статистическую информацию. Каждый отчет содержит следующую

информацию:

• Статистику библиотечного кэша

• Итоговую статистику системы

• Статистику событий ожидания в рамках всей системы

• Среднюю длину очереди записи незафиксированных буферов

• Статистику файлового ввода/вывода

• Статистику SGA и кэша

• Статистику защелок

• Статистику сегментов отката

• Текущие установки параметров инициализации

• Статистику кэша словаря

• Статистику времени запуска и останова

Нужно поддерживать высокие значения коэффициента попадания и низкие значения времени ожидания.

EXPLAIN PLAN

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

Ниже приведены некоторые общие рекомендации по настройке приложений:

• необходимо создавать EXPLAIN PLAN (пояснительный план) для всех запросов в приложении. Это поможет вам определить, был ли запрос правильно оптимизирован.

• необходимо проверять EXPLAIN PLAN для представлений базы данных. Это важно, поскольку представления при использовании в запросах ведут себя не так, как таблицы. Операторы SQL представления не выполняются, пока к ним не поступит запрос, поэтому неэффективное представление может рез­ко снизить производительность в целом эффективного приложения. Особенно следите за соедине­нием одних представлений с другими.

• Если хорошо работающее приложение начинает работать медленно, остановите его и определите, что изменилось. Во многих случаях запрос прекрасно работает в экспериментальной среде и в те­чение первых нескольких месяцев на производстве, пока не накопятся данные; может потребоваться индекс для ускорения поиска в базе данных. В других случаях может оказаться, что в результате добавления индекса существующие результаты EXPLAIN PLAN стали недействительными. Это ре­альная опасность, когда слишком многим разрешено создавать индексы на производственных таб­лицах. Чем больше индексов имеет таблица, тем больше времени требуется на загрузку или модификацию данных в таблице базы данных; это также влияет на скорость выдачи результатов запроса из базы данных.

• Старайтесь поддерживать единообразие кода SQL. Везде, где это возможно, в приложениях долж­ны применяться одинаковые операторы SQL, что позволяет воспользоваться преимуществами со­вместно используемой области SQL базы данных Oracle. Этим можно будет воспользоваться только при полном совпадении кода SQL.

• Старайтесь формулировать запросы более конкретно. Чем более конкретным является запрос базы данных, тем быстрее он выполняется. Например, запрос таблицы по ROWID намного конкретнее, чем запрос с фразой LIKE. Если только нет необходимости использовать в приложении менее кон­кретные запросы, всегда пишите запросы с использованием PRIMARY KEY или другой индекси­рованной информации.

• Следите за тем, как часто выполняются запросы к базе данных и являются ли они необходимы­ми. Избегайте слишком частых или ненужных вызовов, например вызова цикла, который вначале запрашивает в таблице DUAL имя пользователя. При каждом выполнении такого цикла выдается запрос. Запросы других типов могут стать еще более дорогостоящими. По возможности обрабаты­вайте данные в памяти и воздерживайтесь от запросов к базе данных.

Характеристики

Список файлов домашнего задания