DeepEdit!

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

для хранения этих        так что, в конечном счете, некоторые блоки приходится перекрывать блоками, затребованными позже.

Управление буферным кэшем базы данных до появления Oracle8i

Легко заметить, что в версиях Oracle, появившихся до Oracle8i, буферный

кэш базы данных в своей основной форме является системой управления запа­сами. В него входит пространство (кэш) для размещения запасов (блоков базы данных). Кроме того, в нем имеется средство для управления блоками, чтобы выбрасывать их или освобождать место для новых, следуя модифицированному правилууправления "первым пришел, первым обслужен" (FIFO, first-in-first-out). Такой метод управления называется алгоритмом наиболее давно использовав­шихся элементов (LRU, Least Recently Used).

Представим пример, который объяснит механизм управления LRU в буфер-
ном кэше базы данных. Рассмотрим работу супермаркета по соседству с вами.
Когда вы ожидаете очереди в кассу, вы обычно стоите в узком пространстве
между полками, заваленными всякой мелочью - последняя попытка продать вам
что-то такое, что вам совершенно не нужно. Многое из выложенного на этих
полках можно найти только здесь, и часто на них есть что-то совершенно новое.
Некоторые предметы имеют тенденцию появляться на короткое время, а затем
исчезать. Какие-то пользующиеся большим спросом товары типа журнала
"ТВ-Парк" или жвачки лежат там постоянно. Пространство, занятое не столь
нужными вещами, в конечном счете заполняется другими симпатичными мале-
нькими штучками. Но кажется, что предметы повышенного спроса не покидают
этого "царства        Вещи же, не пользующиеся спросом или редко

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

Oracle использует такой модифицированный метод управления FIFO на базе алгоритма LRU и управляет им посредством связанного списка адресов блоков.

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

операций с памятью).

Когда блок считывается в память, процесс сервера, читающий его с диска,

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

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

давно использовавшиеся блоки. С некоторого момента такие блоки становятся разрешенными для повторного использования.

Помимо LRU, имеется еще один список, ассоциируемый с буферным кэшем базы данных. Это так называемый грязный список буферов, содержимое кото­рых было изменено. После того как содержимое блока изменяется, Oracle не по­зволяет перекрыть (переписать) этот блок, пока его содержимое не будет записано на диск. Программа записи базы данных (DBWR, database writer) несет ответственность за то, чтобы список измененных блоков сохранял управляе­мые размеры. К сожалению, так как эта операция связана с физическим вво­дом/выводом, она подвержена ограничениям по производительности системы ввода/вывода. Если эта система служит препятствием в выполнении в требуе­мое время программой вывода базы данных своих обязанностей, возникает множество событий ожидания. После того как DBWR запишет эти блоки на диск, они (логически) перемещаются обратно в список LRU (поскольку больше не являются грязными). Каждый блок может быть либо грязным, либо доступ­ным для повторного использования (свободным).

Поясним управление списком LRU для версий Oracle вплоть до 7.3, исполь­зуя простой пример. Представьте, что кэш буфера базы данных состоит всего из пяти блоков, имеющих номера от 1 до 5. Допустим, процесс начинает считы­вать блоки в память. Пять блоков данных (А-Е) считываются в буферы (1-5) бу­ферного кэша базы данных. Блок А попадает в 1-й буфер, В - во 2-й, С - в 3-й, D -в 4-й, а Е - в 5-й. Если необходимо прочесть блок F (новый блок), куда можно его

записать? Давайте посмотрим на список LRU в направлении от наиболее давно

использованного к наименее давно использованному (MRU. most recently used) блокам, прежде чем F займет свое место. Они расположены в порядке 1,2, .'5, 4, 5

как указано в таблице:

1 = блок А    2= блок В     3 = блок С      4 = блок D      5 = блок Е

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

Прим. пер.). 

Следовательно, данные в буфере 1 должны быть переписаны (если

запрос блоков позволяет это). Если данные в блоке 1 изменены и до сих пор не

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

1 = блок F    2 = блок В     3 = блок С      4 = блок D      5 = блок Е

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

в память блоки сегмента отката (и их заголовки). Это может привести к тому, что кэш буфера окажется переполненным, а некоторые блоки - устаревшими.

Если впоследствии некоторым другим процессам будут нужны содержащие-
ся в устаревших блоках данные, им придется выполнить физическую операцию
ввода/вывода и занести эти блоки обратно в память. А теперь, чтобы жизнь ме-
дом не казалась; мы сообщим, что различные атрибуты таблиц и операций влия-
ют на то, как процесс сервера справляется с обновлением списка        в то
время, как он читает блоки. Например, при выполнении полного сканирования
таблицы Oracle помещает блоки сканируемой таблицы в конец списка LRU, так что эти блоки могут устареть быстрее других. Но если включен атрибут таблицы cache, процесс сервера поместит данные блоки в другой конец (со стороны MRU) списка. Неправильное использование этого аргумента может вызвать конкуренцию и необоснованный физический ввод/вывод. Число блоков, взя­тых с MRU-конца списка в случаях, когда включен атрибут cache, определяется

внутренней установкой ядра Oracle.