Обеспечение целостности данных

Транзакции

Транзакция — это одна или более 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 записывает заполненный файл в архив файлов журнализации. В тот момент, когда архивирование только закончилось, файл журнала измене­ний помечается как доступный. Очень важно, чтобы архивные файлы журнала изменений надежно хранились, так как они мо­гут понадобиться для восстановления системы.

Дата добавления: 2014-01-07