Обеспечение целостности данных. Управление транзакциями в СУБД Oracle и SQL Server, страница 5

o  Завершилась транзакция. Подтверждение о завершении транзакции не посылается до тех пор, пока изменения транзакции не будут сохранены в журнальном файле

o  Буфер журнала заполнен на треть

o  Процесс DBWR закончил запись на диск измененных буферов при выполнении контрольной точки

o  Истекло время ожидания LGWR

·  Необязательный фоновый процесс контрольной точки CKPT может взять на себя часть работы LGWR, обновляя заголовки файлов данных и управляющих файлов при выполнении контрольной точки

·  Необязательный фоновый архивный процесс ARCH копирует оперативные журнальные файлы на указанное внешнее устройство после переключения журнала для последующего восстановления при сбоях носителя

Рисунок 1 Фиксация изменений в базе данных

Переключение журналов

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

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

Переключение, также, может быть инициировано администратором базы данных с помощью команды ALTER SYSTEM SWITCH LOGFILE.

Архивирование журналов

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

Архивация журнальных файлов возможна только в том случае, если база данных запущена в режиме ARCHIVELOG, который не разрешает переписывать файлы журнала до тех пор, пока они не будут заархивированы. Если архивация файлов журнала невозможно по той или иной причине (не запущен архивный процесс или переполнено устройство, на которое производится архивация), система зависнет, когда будут заполнены все журнальные файлы. Копирование журнальных файлов на диск или ленту может быть автоматическим или ручным:

·  Автоматическим копированием журнальных файлов на внешнее устройство занимается необязательный фоновый процесс ARCH. Количество архивных процессов для экземпляра, запущенных одновременно, задается в файле параметров

·  Администратор может архивировать журнальные файлы вручную, независимо от того, запущен или нет архивный процесс. Если архивный процесс не запущен, своевременное копирование файлов журнала на внешнее устройство является ответственностью администратора базы данных. Ручное архивирование журналов применяется, если автоматическое копирование невозможно (переполнен внешний носитель) или для выполнения более тонкого копирования (на разные внешние носители)

Контрольная точка

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

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

Контрольная точка выполняется:

·  при каждом переключении журнала;

·  через заданное число секунд после предыдущей контрольной точки (задается в файле параметров);

·  после записи заданного числа блоков журнала на диск с момента предыдущей контрольной точки (задается в файле параметров);

·  во время нормальной остановки экземпляра;

·  может инициироваться администратором базы данных с помощью команды ALTER SYSTEM CHECKPOINT.

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

Последовательные шаги фиксации изменений в базе данных

1.  Пользователь выполняет команду COMMIT

2.  Фоновый процесс LGWR записывает содержимое буфера журнала в текущую группу журнальных файлов

3.  Фоновый процесс LGWR регистрирует контрольную точку в управляющем файле

4.  Освобождаются блокировки ресурсов в блоках данных и сегментах отката

5.  Пользователю сообщается, что изменения транзакции зафиксированы