Скажем, вы обновляете запись в таблице. На очень высоком абстрактном уровне следующие шаги выполняются, как только блок, содержащий целевую запись, идентифицирован (или скопирован в) буферный кеш базы данных.
- Вектор изменений REDO, описывающий, как вставитьUNDO запись в блок UNDO создана. Эта UNDO необходима для отката изменений в случае необходимости в будущем. UNDO также может потребоваться для удовлетворения SQL-запросов, которые были запущены до того, как обновление было инициировано и все еще выполняется.
- Создан вектор изменений REDO, описывающий изменение блока данных для выполнения запрошенного обновления.
- Объединяя два вектора изменений REDO, запись REDO создается и записывается в круговой буфер журналов повторов (RLB).
- Запись UNDO вставляется в блок UNDO в буферном кеше.
- Фактическое изменение вносится в блок данных в буферном кеше.
В этот момент RLB может содержать записи REDO из нескольких серверных процессов. Часть RLB последовательно записывается одним процессом записи в журнал (LGWR) в онлайн-файлы журналов повторов. Только если происходит одно из следующих событий, все записи повторного выполнения из RLB записываются в онлайн-файлы журнала повторного выполнения.
a. Один из процессов сервера выдает сообщение COMMIT. (событие ожидания синхронизации файла журнала).
b. Произошло переключение журнала (файл журнала повторного выполнения онлайн заполнен, и LGWR переключается на новый файл журнала повторного подключения онлайн из ограниченного числа файлов журнала повторного подключения онлайн, в которые LGWR пишет циклически).
c. Каждые 3 секунды.
d. RLB заполнен на одну треть.
e. Когда процессу Database Writer (DBWn) необходимо записать грязные буферы на диск. (Когда возникнет такая необходимость, поясняется позже).
- Обратите внимание, что даже сейчас грязные буферы (которые включают в себя блок, который мы изменили в буферном кеше) не были записаны на диск (данныефайл). Теперь давайте поговорим о DBWn.
В отличие от процесса LGWR, может быть несколько процессов DBWn (обозначаемых суффиксом n), которые могут асинхронно (без учета фактического изменения записи в блок данных в буфере). кеш, конечно, после внесения изменений в буфер) записывает грязные буферы из кеша буферов базы данных на диск параллельными записями. Но эти записи происходят только при следующих обстоятельствах.
a. Когда чистых буферов больше нет в буферном кеше базы данных
b. Когда контрольная точка происходит. (Контрольная точка - это точка в файле журнала повторов (номер изменения системы (SCN)), до которой грязные буферы уже записаны на диск (т. Е.) До этой точки в файле журнала повторов файл данных синхронизируется с буферным кешем.)
Следовательно, утверждается, что DBWn выполняет отложенную запись только тогда, когда это необходимо, в отличие от быстрой записи, близкой к реальной, выполняемой LGWR.
Еще одинДело в том, что модулем логической записи Oracle является блок. На диске в файле данных этот блок идентифицируется и затем копируется в буферный кеш. Oracle никогда не блокирует блоки. Он получает защелку на заголовке блока буфера перед чтением буфера. Вот почему мы видим «цепочки буферов кэша защелки», ожидающие события, когда какое-то сканирование с большим диапазоном не позволяет другим процессам получить эту защелку. Что касается блокировки, когда мы обновляем строку в блоке Oracle, Oracle блокирует на уровне детализации, строку, которую мы обновляем.
Архитектура памяти и процессов в рамках архитектуры экземпляра Oracle в Документация Oracle - хорошее место для понимания этих понятий.