The Search For Intelligent Life in the Cost-Based Optimizer
by Tim Gorman

Ввод/вывод в Oracle7 версии 7.1 и выше

Пришел черед Oracle7 версии 7.1...

Вновь архитекторы Oracle7 показали свою проницательность. Во-первых, они сделали проблемный параметр SMALL_TABLE_THRESHOLD "недокументированным", переименовав его в "_SMALL_TABLE_THRESHOLD". Это дало эффект наложения знака "опасность" на данный параметр, предупреждая: "Изменяй меня на свой страх и риск". Хорошая мысль!

Тем не менее, они осознавали, что разработчикам нужно закреплять некоторые таблицы в Буферном Кэше. Поэтому они создали атрибуты CACHE и NOCACHE для команд CREATE TABLE и ALTER TABLE. По умолчанию использовался атрибут NOCACHE, но разработчик мог изменить его значение на CACHE. Это означало, что таблицы с атрибутом CACHE также могли быть размещены в MRU-конце связного LRU-списка (подобно случаю очень маленьких таблиц) даже при выполнении операции FTS. Блоки таблиц с атрибутом NOCACHE по-прежнему размещались в LRU-конце списка.

Однако, учитывая человеческую природу и помня популярное, но ложное представление о том, что закрепление таблиц в памяти заставит каждое приложение "летать", как Вы думаете, что могло бы произойти? Конечно! Каждый стал бы помечать все свои таблицы атрибутом CACHE!

Набив шишки c параметром SMALL_TABLE_THRESHOLD, архитекторы Oracle7 добавили ограничитель, чтобы предотвратить эту ситуацию. Они создали еще один параметр CACHE_SIZE_THRESHOLD, который определил максимальный размер для таблиц с установленным атрибутом CACHE. Если таблица была бы помечена как CACHE, но ее размер был бы больше числа блоков, заданных параметром CACHE_SIZE_THRESHOLD, Oracle трактовал бы такую таблицу как NOCACHE, игнорируя атрибут CACHE. Значение параметра по умолчанию было определено в 10% от размера Буферного Кэша, но оно могло быть при необходимости увеличено или уменьшено администраторами баз данных (или разработчиками, которые взломали пароли DBA).

Итак, вот все правила, которые остаются в силе на протяжении последних десяти лет, начиная с Oracle7 версии 7.1. Операции индексного сканирования (использующие одноблочные операции ввода/вывода) всегда помещают блоки в MRU-конец связного LRU списка Буферного Кэша. Такие блоки имеют тенденцию сохраняться в Буферном Кэше на значительное время. Природа доступа к древообразной структуре B*-Tree индексов склонна повышать вероятность повторного использования буферов, которые будут постоянно перемещаться обратно в MRU-конец списка. Таким образом, индексы имеют тенденцию к очень хорошему кэшированию.

С другой стороны, операции FTS будут читать данные с диска в буферы кэша, которые будут сразу размещены в LRU-конце связного LRU-списка. Если же таблицы принадлежат к классу маленьких таблиц, то их данные будут считаны в буферы, размещенные в MRU-конце списка. Еще одним исключением является случай, когда таблицы помечены как CACHE и их размер меньше ограничения, накладываемого параметром CACHE_SIZE_THRESHOLD. В этом случае, считываемые блоки будут также размещены в MRU-конце списка.

В целом, для операции FTS характерно, что почти каждая операция логического чтения приводит к операции физического чтения. Это совершенно нормально. Операции FTS обычно имеют 20% или меньший (часто до 1% или 5%) коэффициент попадания в Буферный Кэш, который означает, что практически все (за исключением небольшого числа) операции логического чтения приводят к соответствующим операциям физического чтения. Напротив, для индексного доступа обычно характерны высокие (95% или выше) значения коэффициента попадания в Буферный Кэш.