Обеспечение целостности данных
Транзакции
Транзакция— это одна или более SQL-команд, завершаемых фиксацией (commiting) или откатом (rollbacking).
Под фиксацией (commiting) понимается принятие и сохранение всех изменений.
Откат (rollbacking) — это процедура отмены последних изменений, т. е. возврат к предыдущему состоянию БД.
Чтобы понять как работает система Oracle, рассмотрим по шагам пример работы простой транзакции.
Итак, транзакция выполняется следующим образом.
1. Приложение обрабатывает пользовательский ввод и создает соединение с сервером посредством SQL*Net.
2. Сервер принимает запрос на соединение и создает серверный процесс.
3. Пользователь выполняет SQL-команду или совокупность команд. (В нашем примере будем считать, что пользователь изменяет данные в строке таблицы.)
4. Серверный процесс просматривает, есть ли в разделяемом пуле SQL-область с идентичными SQL-командами. Если он находит аналогичную разделяемую SQL-область, то серверный процесс проверяет права пользователя на доступ к данным. Предположим, что права имеются, тогда серверный процесс выполняет команды, используя разделяемую SQL-область. Однако если разделяемая SQL-область не найдена, выделяется память под новую область, а затем происходит разбор и выполнение SQL-команд.
5. Серверный процесс ищет данные в SGA (если они там есть) или считывает их из файла данных в SGA.
6. Серверный процесс изменяет данные в SGA. (Запомните, что серверный процесс может только считывать данные из файла данных.) Позже процесс DBWR запишет измененные блоки данных в постоянное хранилище (на жесткий диск, магнитную ленту и т.д.).
7. Пользователь выполняет команду COMMIT (Фиксация) или ROLLBACK (Откат). Первая завершает транзакцию, а вторая отменяет изменения. Если транзакция зафиксирована, процесс LGWR немедленно записывает ее в файл журнала изменений.
8. Если транзакция успешно завершена, клиентскому процессу передается код завершения. Если произошел какой-либо сбой, возвращается сообщение об ошибке.
Примечание. Транзакция не считается зафиксированной до тех пор, пока не завершена запись в файл журнала изменений (redo log file). Этот механизм способствует тому, что в случае сбоя зафиксированная транзакция может быть восстановлена.
При работе с СУРБД Oracle необходимо решать задачу обеспечения целостности данных (восстановления базы данных после сбоев, перехвата ошибок и т.д.), для чего используются следующие функции: создание контрольных точек, журнализация и архивирование.
Создание контрольных точек (checkpointing). Как уже говорилось, сигнал к созданию контрольной точки поступает либо от процесса DBWR, либо от процесса LGWR. Но что же такое контрольная точка и для чего она необходима?
Так как все изменения блоков данных происходят в блоковых буферах, то изменения данных в памяти не обязательно отражаются в этих блоках на диске. Процесс кэширования происходит по алгоритму последнего использованного блока, поэтому буфер, подверженный постоянным изменениям, помечается как последний использованный и процесс DBWR не записывает его на диск. Контрольная точка служит для обеспечения записи этих буферов на диск. Все грязные буферы должны сохраняться на диске в обязательном порядке.
Контрольная точка может работать в двух режимах: нормальной контрольной точки и быстрой контрольной точки.
В режиме нормальной контрольной точки грязные буферы записываются последовательно процессом DBWR. Эта контрольная точка выполняется гораздо дольше, чем быстрая, но затрагивает меньше системных ресурсов.
В режиме быстрой контрольной точки процесс DBWR записывает одновременно несколько буферов. Эта контрольная точка выполняется очень быстро и более эффективна при вводе-выводе, однако она значительно снижает производительность системы.
Частое выполнение контрольных точек способствует увеличению времени, необходимого на восстановление системы в случае сбоя.
Контрольная точка автоматически выполняется при смене журнала изменений.
Журнализация и архивирование. Журнал изменений (redo log) записывает все изменения БД Oracle. Целью его создания является возможность экстренного восстановления БД в случаях сбоев системы и потери файлов данных. Восстановив файлы данных из ранее сделанных резервных копий, файлы журнала изменений (включая архивные файлы журнала) могут повторить все последние транзакции и таким образом файлы данных будут полностью восстановлены.
Когда файл журнала изменений оказывается полностью заполненным, происходит смена журнала и процесс LGWR заводит новый файл. Во время смены журнала процесс ARCH записывает заполненный файл в архив файлов журнализации. В тот момент, когда архивирование только закончилось, файл журнала изменений помечается как доступный. Очень важно, чтобы архивные файлы журнала изменений надежно хранились, так как они могут понадобиться для восстановления системы.