ТЕМА:

Процесс записи данных в базу Oracle работает не в вакууме и учитывая, что его целью является сохранение данных, спустя некоторое время после того, как процесс записи в журнал скопирует буфер журнала на диск, едва ли кого-то удивит, если я скажу, что dbwr должен взаимодействовать с другими процессами в системе. В этом статье моего блога мы сначала изучим поведение dbwr во взаимодействиях с lgwr, затем посмотрим, как он использует списки LRU совместно с другими процессами, и детально исследуем механизм контрольных точек, задачей которого является обеспечить постоянное копирование «грязных» (измененных) буферов на диск.

Взаимодействие dbwr и lgwr

Процесс lgwr всегда сохраняет изменения раньше, чем dbwr сохранит блоки данных. Это означает, что после аварии блок данных, находящийся на диске, всегда можно переместить «в будущее», применив записи из журнала, и никогда – «в прошлое». В результате получается очень надежный механизм восстановления. Однако, dbwr обычно сохраняет блоки после проверки значения LRBA: в них – самого раннего момента, когда они изменились – поэтому возникает вопрос: что произойдет, если подошло время сохранить буфер и он оказался изменен за несколько микросекунд до того, как dbwr добрался до него? Вполне возможно, что процесс dbwr будет иногда находить блоки, изменившиеся настолько недавно, что соответствующие записи повторения еще не были записаны в буфер журнала.