Home  |  Administration  |  SQL  |  Tuning  |  Miscellaneous  |

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

Предыдущая Оглавление Следующая

Обзор правил ввода/вывода в Oracle

Операции ввода/вывода в Oracle осуществляют доступ не к отдельным строкам, а к блокам базы данных, которые содержат строки. Кроме того, Oracle не пытается сразу искать блоки данных на диске, вместо этого он ожидает найти их кэшированные копии в области разделяемой памяти, точнее в Буферном Кэше, расположенном в SGA. Операции чтения буферов в Буферном Кэше известны как операции логического чтения. Говоря точнее, существует два основных типа операций логического чтения: consistent gets и db block gets (другое название current gets). Consistent gets - это операции извлечения конкретной (point-in-time11) версии блока данных, обычно запрашиваемой операторами SELECT. С другой стороны, db block gets или current gets - это операции извлечения наиболее "свежей" (most up-to-date), текущей на данный момент копии блока данных, обычно запрашиваемой с целью модификации операторами INSERT, UPDATE, DELETE. Различие между этими двумя типами логических операций чтения не столь существенно для дальнейшего обсуждения. Оно было упомянуто только к месту, однако если взглянуть на статистику в представлениях V$SYSSTAT или V$SESSTAT, Вы не найдете там статистики "logical reads", вместо этого Вы обнаружите "consistent gets" и "db block gets". Просто сложите их вместе.

Очевидно, что если реальная база данных находится на жестком диске, а не в разделяемой памяти, то буферы в Буферном Кэше пришлось каким-то образом заполнить! Обычно это происходит, когда серверный процесс проверяет наличие конкретного блока базы данных в Буферном Кэше (операция логического чтения). Если искомый блок находится в кэше, тогда все хорошо - процесс продолжает свою работу. Но если блок не найден ни в одном буфере Буферного Кэша, то серверный процесс, выполнивший операцию логического чтения, сделает запрос к подсистеме ввода/вывода (операция физического чтения), чтобы считать блок в буфер. Затем серверный процесс продолжает свою обычную работу.

Что произойдет, если серверный процесс выполнил логическое чтение блока, который отсутствует в Буферном Кэше, определил, что его там нет, и производит физическое чтение, а другой серверный процесс в то же время пытается выполнить операцию логического чтения до того, как первый завершит свою операцию физического чтения? Выполнят ли оба процесса операцию физического чтения? Ответ отрицательный. После того, как первый процесс определит, что требуемый блок данных отсутствует в Буферном Кэше, он резервирует буфер под этот блок до фактического выполнения операции физического чтения. Затем процесс блокирует этот буфер и запрашивает операцию физического ввода/вывода. Если второй процесс пытается выполнить операцию логического чтения в то время, когда буфер заблокирован, он отправит сигнал события-ожидания (wait-event) buffer busy wait и просто ожидает снятия блокировки. В итоге избыточные операции ввода/вывода не нужны...

Скованные одной цепью...

Буферный Кэш представляет собой кэш, состоящий из буферов, и управляемый по LRU12-алгоритму. Согласно этому алгоритму, буферы, к которым обращаются наиболее часто, перемещаются в MRU13-конец связного списка. Вновь читаемые блоки считываются в кэш и размещаются MRU-конце списка. Когда Oracle производит операции логического чтения буферов, последние перемещаются в MRU-конец списка. Если к блоку нет обращений, он постепенно вытесняется все дальше и дальше по направлению к LRU-концу списка. В конце концов, он достигает конца списка и вновь считанный блок займет его буфер. Другими словами, блок будет вытеснен из LRU-списка.

ПРИМЕЧАНИЕ: В Oracle8i реализация LRU-алгоритма подверглась значительным изменениям, добавлен новый "mid-point insertion" алгоритм для минимизации действий над защелкой (latch) при операциях закрепления и отделения блоков от списка, особенно в случае перемещения "hot" блоков в MRU-конец списка. У меня нет более подробной информации на этот счет; оставлю детали для последующего обновления этой статьи...


Предыдущая Оглавление Следующая
Last Update: October 11, 2007 18:33:32