DeepEdit!

Многие операции с данными в Oracle выполняются в области кэша бу­феров базы данных, расположенного в наборе сегментов разделяемой памяти ядра Oracle, который называется системной глобальной обла­стью. Поэтому все аналитики производительности уделяют внимание тому, что происходит в кэше буферов базы данных. Сообщается о том, что доступ к буферам кэша осуществляется из сотен различных фраг­ментов кода ядра Oracle [Lewis (2003)]. Из всех таких обращений к бу­ферам наибольшие затраты связаны с операциями логического ввода/ вывода Oracle (LIO). Количество LIO для вызова базы данных равно сумме значений его статистик cr и cu из данных трассировки SQL.

Практически в каждой из Oracle-систем, которые я встречал, более 50% общего процессорного времени, отданного приложениям Oracle, занимали ненужные вызовы LIO. Во многих случаях можно избавить­ся от более чем 90% нагрузки на систему без потери какой бы то ни бы­ло функциональности для бизнеса.

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

Обращение к слишком большому количеству буферов вызывает допол­нительную нагрузку на процессор и приводит к росту времени, прове­денному вне исполнения, проявляющемуся в больших неучтенных длительностях. Избыточные операции LIO приводят к возникновению ожиданий освобождения защелок в цепочках буферов кэша (cache buffer chains) и служат причиной избыточных системных вызовов чте­ния, проявляющихся в виде событий db file sequential read или db file scattered read.

Многие события ожидания Oracle могут служить иллюстрацией вред­ных побочных эффектов ненужных обращений к буферам. Например, любая производительность ухудшается по мере увеличения очереди к процессору. Событие ожидания Oracle log file sync - один из первых признаков возрастания задержек, возникающих в очереди к процессо­ру. Негативные последствия избыточных обращений к буферам могут проявиться в абсолютно неожиданных местах. Например, если избы­точные обращения к буферам приводят к усилению конкуренции за дисковый ввод/вывод, процессы записи DBWR могут стоять в очереди по­зади вызовов чтения. Если процесс DBWR не успевает за изменениями буферов, то в приложениях появляются события ожидания free buffer waits, write complete waits и даже log file switch (checkpoint incomplete). Зачастую оказывается, что причина проблем с ожиданием освобожде­ния буфера buffer busy waits кроется в избыточном количестве операций LIO. Ошибки, приводящие к ненужным операциям LIO, могут вызвать даже лишние выполнения событий SQL*Net message from client.

Существует ряд причин, по которым столь многие системы страдают от избыточных вызовов LIO. Одна из них заключается в том, что всех нас учили, что обращение к памяти выполняется гораздо быстрее, чем к диску, из чего следовало, что в бесконечных обращениях к памяти нет ничего страшного [Millsap (2001c)]. Более глубокая причина того, что огромное количество приложений Oracle страдает от избыточности операций LIO, состоит в том, что пользователи могут создать проблему множеством способов. Рассмотрим небольшой пример:

Пользователи приложений могут заставить их выполнять ненуж­ные обращения к буферам разными способами. Можно выполнять запросы, не пользуясь фильтрами, например, поиск продавца с на­званием «Xerox» можно осуществлять посредством запроса «всле­пую» вместо того, чтобы наложить на имя ограничение вида X%. Можно запрашивать отчеты, не указывая аргументов, например можно запустить формирование отчета по продажам всей компа­нии начиная с ее основания вместо того, чтобы сформировать нуж­ный отчет по своему отделу за определенный месяц. Кроме того, в те моменты, когда система начинает работать медленнее из-за из­бытка вызовов LIO, пользователи могут отправлять на исполнение одну и ту же операцию несколько раз, в результате чего одни и те же вызовы LIO выполняются по несколько раз.

Ошибки, приводящие к ненужным обращениям к буферам, могут со­вершать и администраторы приложений. В конфигурируемых при­ложениях, например в Oracle e-Business Suite, способы организации плана бухгалтерских счетов и настройки приложения могут серьез­но повлиять на количество вызовов LIO, совершаемых типовыми бизнес-функциями. Некоторые приложения, подобные продукту Oracle General Ledger, имеют собственные встроенные средства опти­мизации запросов. Применяя подобные средства и пренебрегая при этом внимательным изучением их влияния на производительность, можно породить много ненужных вызовов LIO. Ошибки админист­раторов приложений в деле архивирования и очистки данных могут привнести в приложение миллионы ненужных вызовов LIO.

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

Администраторы данных могут инициировать избыточные вызовы LIO огромным количеством способов. Вероятно, самый распростра­ненный из них - предоставление некорректной информации о таб­лицах и индексах оптимизатору Oracle по стоимости (Cost-Based Query Optimizer - CBO) из-за того, что статистика собрана непра­вильно. Таблицы, страдающие миграцией или сцеплением строк в тяжелой форме, порождают больше вызовов LIO. То же самое происходит, если неудачно выбраны значения PCTFREE и PCTUSED. От­сутствие в соответствующих ситуациях индексированных таблиц, кластеров и разделов может привести к обработке излишних LIO. Отсутствие ограничений (например, не назначены столбцы, высту­пающие в качестве первичных или внешних ключей, не определе­но, какие столбцы допускают использование NULL, а какие - нет) мо­жет помешать оптимизатору запросов Oracle использовать планы выполнения, ограничивающие количество вызовов LIO. Конечно же, недостаточное количество индексов (или просто неправильные индексы) может вызвать ненужные вызовы LIO для запросов, а из­быточное количество индексов может привести к выполнению лишних вызовов LIO в командах INSERT, UPDATE и DELETE.

Естественно, что решения разработчиков приложений оказывают огромное влияние на количество LIO. Некоторые виды конструкций

SQL делают невозможным применение эффективного плана выпол­нения запроса ядром Oracle. Например, наличие в инструкции WHERE предиката TRUNC(STARTDATE) = TO_DATE(:b1, 'mm/dd/rr') может поме­шать серверному процессу Oracle использовать индекс для START_DATE, который мог бы значительно уменьшить количество LIO. Бывает и так, что в коде приложения качество SQL очень высоко, но вызовов LIO все равно слишком много. Так, приложение с построчной вы­боркой из курсора Oracle может выполнять в сто раз больше вызо­вов LIO, чем такое же приложение, в котором реализован механизм выборки массивом (array fetch) для извлечения 100 строк в одном вызове LIO. Игнорирование возможности выборки массивом приво­дит к дополнительной нагрузке не только на базу данных, но и на сеть. Дополнительные вызовы базы данных, необходимые для обра­ботки многочисленных маленьких наборов строк приводят к тому, что возрастает количество выполнений события SQL*Net message from client, а это сразу же отражается на времени отклика пользователь­ской операции.

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

Учитывая, что масса разных специалистов одновременно должна вы­полнить свою работу безошибочно, чтобы исключить проблемы с LIO, не приходится удивляться наличию избыточных вызовов LIO в боль­шинстве систем.