DeepEdit!

Значение 60% для коэффициента попадания в буферный кэш базы данных озна­чает, что база данных имеет плохую производительность.

Неверно! По мере того как меняется природа операций, выполняемых базой данных, должно меняться и это значение. В дневные часы можно наблюдать вы­сокие значения коэффициента попадания в кэш (CHR, cache-hit ratio) для опе­раций OLTP, если они обращаются к тому же самому набору блоков. Но ночью, когда запускаются большие пакетные задания, манипулирующие с широким диапазоном блоков, нужно ожидать снижения CHR. Следует иметь в виду, что блоки, к которым обращались днем, остаются на том же месте, но к ним добав­ляется много новых. Это и приводит к снижению CHR. Если процессы пользо­вателей не ожидают блоков, которые необходимо прочесть с диска, 

ожидание 

свободных буферов или сожаления о плохой производительности делает при­емлемым значение CHR в районе 60%. Настройка - это те действия, которые должен предпринять пользователь, чтобы его задания выполнялись, а вовсе не достижение непонятно откуда взявшихся значений коэффициентов.

Значения коэффициента попадания в кэш буфера базы данных, равные 99% и выше, означают, что база данных работает на своем пиковом уровне.

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

что Oracle работает с пиковой эффективностью, когда на самом деле назревает

осложнение. С точки зрения пользователя, если ему приходится ожидать чте­ния блоков с диска, появления свободных буферов или цепочки LRU в буфер­ном кэше базы данных, ему следует отнестись безразлично, что CHR составляет 99%. АБД должен понять, что у него возникла проблема с производительно­стью. Более того, наличие у большинства так называемых реальных систем вы­соких CHR (в районе 99%) обычно означает крайнюю неэффективность SQL в приложениях. Необходимо "найти и обезвредить" эти "обиженные" операторы

SQL, чтобы добиться приемлемого времени реакции системы.

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

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

6 процессорами. Понятно, почему возникли узкие места с ЦП для этой системы. Заметим также, что должен использоваться такой метод планирования, чтобы, скажем, одновременно выполнялось не более четырех заданий.

До настоящего виновника возникновения конкуренции за ЦП удалось доко­паться, только когда все процессы Oracle были подвергнуты трассировке и уста­новлены наиболее дорогостоящие операторы SQL. Перед осуществлением этой процедуры CHR базы данных составлял 98%, и администратор базы дан­ных Oracle был полностью уверен, что Oracle работает оптимально, хотя в реа­льности все обстояло абсолютно противоположным образом. Оказалось, что

виновниками происходящего были операторы SQL, в каждом из которых содер­жались коррелированные подзапросы, причем любой из них выполнялся около 45 мин, полностью занимая все "лошадиные силы" одного из ЦП. Стоило запус­тить шесть таких запросов, и система буквально приходила в негодность.

После того как коррелированные подзапросы были переписаны в запросы
со "встроенными представлениями" (в разделе "Как не надо писать SQL" главы
"Настройка приложения - вопросы, относящиеся к ведению        мы уже при-

водили примеры того, как это можно        операторы SQL стали выполнять-

ся за 45 с, занимая только 65% мощности одного ЦП. Совершенно очевидно,
что после подобного переписывания мы добились намного лучшей масштабиру-
емости приложения, чем раньше. Далее, после того, как эти переписанные за-
просы были введены в        CHR системы составил        но при этом

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

коэффициентов попадания в кэш с оптимальной производительностью. Теперь становится видно, насколько опасно настраивать Oracle, используя вместо со­бытий ожидания коэффициенты попадания в кэш.

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

Что такое пятиминутное правило кэширования или теперь уже, наверное, десятиминутное?

Кэшем в контексте систем управления базами данных называется сегмент

коллективно используемой памяти, который распределен для выборки данных

и манипулирования ими. Кэш данных Oracle называется 

буферным кэшем базы данных. 

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

'чшркэши. 

Концепция супер­кэширования (релевантная для определенных аппаратных платформ) базируется на факте, что блок управления памятью (MMU, memory management unit) на сервере отвечает за обработку трансляции адресов памяти. Некоторые серверы поддерживают очень изощренные манипуляции MMU, в результате че­го могут весьма эффективно управлять большими блоками памяти.

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

Transaction Processing: Techniques and Concepts. 

Gray, Reuter
и может быть выведено из следующего уравнения:

Частота = ((Стоимость 1 байта памяти - Стоимость 1 

байта 

дисковой памяти) * Размер объекта)/Стоимость 1 с доступа к объекту

Используя цены на дисковую память, оперативную память и подсистемы вво­да/вывода в 1997 г., можно определить, что точка уменьшения отдачи для кэша находится в районе пяти минут. Если воспользоваться современными ценами на упомянутые выше компоненты, можно (в зависимости от конкретной плат­формы операционной системы) получить значения около 8-10 мин, так как по

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

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

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