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

Распределенные транзакции

Распределенные (distributed) транзакции используются в средах распределенных БД, когда данные могут изменяться одновременно в нескольких БД, расположенных удаленно, но связанных между собой с помощью связей БД (database links). При фиксации изменений в подобных транзакциях они либо фиксируются во всех экземплярах, либо ни в одном. В этом случае используется специальный механизм двухфазной фиксации.

Транзакции и данные повтора

Практически любое изменение данных в БД генерирует данные повторного выполнения (redo data, redo entries), которые при фиксации транзакций записываются в активные журналы повтора (redo logs) и используются для возможности повторного выполнения транзакции, например, в случае сбоя.

Данные повтора не создаются для сегментов во временных ТП.

Транзакции и данные отката

Помимо этого, выполнение транзакций, изменяющих существующие данные, влечет за собой сохранение согласованных данных на начало транзакции. Эти данные называются данными отмены (undo data) и используются для возможности отмены изменений, сделанных транзакцией, как будто бы она вообще не выполнялась.

Данные отмены совместно с журналами повтора используются при восстановлении системы после сбоя.

Еще одно важно назначение данных отката – обеспечение в системе т.н. согласованности по чтению (read consistency), позволяющую всегда читать согласованные данные, что бы с ними не происходило.

Например, пользователь А пытается читать некоторые данные после того, как пользователь Б начал их модифицировать. В этом случае пользователь А получит доступ только к зафиксированным данным, которые в данном случае он считает из сегментов отката. Пользователь Б продолжит работу.

Что происходит при фиксации.

Операция фиксации данных транзакций (COMMIT) выполняется быстро, не вызывая увеличения нагрузки на ресурсы системы. Изменение данных в транзакции влечет за собой генерацию данных повтора. Эти данные помещаются сначала в буфер повторного выполнения, затем сбрасываются в текущие журналы повтора. Если транзакция выполняется продолжительное время, то большая часть данных повтора уже будет сброшена в журналы повтора. Т.е. процесс LGWR не ждет, пока поступит команда фиксации, механизм его работы основан на допущении, что измененяемые в системе данные будут, в-основном, фиксироваться, а не откатываться. Поэтому фиксация транзакции не зависит от длины транзакции и объема изменяемых данных, ибо сервер Oracle заранее выполнил большую часть работы по фиксации. Сама команда COMMIT дает сигнал «доделать» оставшуюся работу:

- сгенерировать SCN (System Change Number), по сути, номер транзакции в системе;

- сбросить SCN и оставшиеся данные повтора из буфера повтора в активные журналы повтора;

- снять блокировки, установленные транзакцией.

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

Что происходит при откате.

Операция отката изменений (ROLLBACK) считывает данные из сегмента отката и «накатывает» их, возвращаяся данные к состоянию на начало транзакции. По сравнению с операцией фиксации, операция отката может быть достаточно ресурсоемкой – здесь имеет значение объем измененных данных в течение транзакции.

Управление откатами

Данные отката в СУБД Oracle 10gсохраняются в сегментах отката, которые, в свою очередь, традиционно хранятся в специально создаваемых табличных пространствах (например, в версии СУБД Oracle8 i подобное ТП называлось по умолчанию RBS, от RollBack Segments). До версии Oracle9 i сегменты отката должны были создаваться и поддерживаться вручную. На АБД накладывались дополнительные обязанности по слежению за их работой и разрешением проблемных ситуаций, с ними связанных. Такой способ создания и использования сегментов отката называется ручным управлением откатами (manual undo management mode).

В версии СУБД Oracle9 i появилась возможность облегчить АБД управление откатами. Теперь можно (и нужно!) использовать новую возможность системы – автоматическое управление откатами (automatic undo management mode).

Новый метод также подразумевает использование специальных табличных пространств, называетмых табличными пространствами отмены (undo tablespaces). Как минимум одно такое ТП должно быть создано перед тем, как использовать этот режим работы. Обычно такое ТП создается вместе с созданием БД и по умолчанию называется UNDOTBS или UNDOTBS1.

Режим управления откатами устанавливается при старте экземпляра с помощью параметра инициализации UNDO_MANAGEMENT. Для включения режима автоматического управления откатами необходимо установить значение этого параметра в AUTO.

Как уже упоминалось выше, к моменту включения автоматического режима в БД должно существовать как минимум одно табличное пространство отмены (создается с помощью команды CREATE UNDO TABLESPACE …, либо при создании БД в команде CREATE DATABASE). Параметр инициализации UNDO_TABLESPACE указывает, какое ТП отмены будет выбрано при старте экземпляра. Если его не указать, будет выбрано первое из доступных ТП отмены. В ручном режиме управления откатами установка этого параметра вызовет ошибку при запуске экземпляра.

В БД может существовать несколько ТП отмены. Переключаться между ними можно с помощью команды ALTER SYSTEM SET UNDO_TABLESPACE ….

Если же в БД нет ни одного ТП отмены, то для пользовательских транзакций будет использован системный сегмент отката в ТП SYSTEM. Этот сегмент создается автоматически и в общем случае не предназначет для обслуживания пользовательских транзакций.

В ТП отмены нельзя создавать другие объекты БД. Его наполнение – системно управляемые сегменты отката. ТП отмены должны создаваться как локально управляемые с опцией autoallocate (используется по умолчанию).

Пример создания ТП отмены:

CREATE UNDO TABLESPACE undotbs2

DATAFILE 'undotbs_2.dbf' SIZE 100M AUTOEXTEND OFF;

Помимо указания табличного пространства отмены, для управления данными отмены используется также параметр UNDO_RETENTION. Он указывает (в секундах) продолжительность времени, в течение которого в ТП отмены будут сохраняться данные отмены для уже зафиксированных транзакций. Основное назначение этого параметра – обеспечение согласованности по чтению, позволяющее длительным запросам выполняться беспрепятственно. По умолчанию может иметь значение 900 (15 минут) или 10800 (3 часа).

Длительные операции чтения иногда заканчиваются неудачно, потому что требуемая согласованная информация, сохраненная в сегментах отката, может быть переписана данными отмены более поздних транзакций (ошибка ORA-01555 snapshot too old).

Как раз с помощью параметра UNDO_RETENTION и можно добиться того, чтобы эта ошибка перестала появляться (при достаточном объеме пространства в ТП отмены). Например, можно выставить этот параметр равным 30 минутам, и в течение этого времени данные отмены всех транзакций, работавших в этом промежутке, будут доступны для длительных запросов.

Для различных нагрузок можно устанавливать значение этого параметра с помощью команды ALTER SYSTEM, например:

ALTER SYSTEM SET UNDO_RETENTION = 1200;

Мониторинг эффективности работы сегментов отката

Используйте представление словаря V$UNDOSTAT для мониторинга эффективности использования сегментов отмены и, при необходимости, принятия решений об внесении изменений в конфигурацию системы.

Это представление предоставляет подробный набор статистических данных, которые «снимаются» каждые 10 минут в течение последних 24 часов, т.е. можно посмотреть не только текущую ситуацию, но и историю нагрузки на сегменты отмены в течение суток. На основе этой информации можно делать объективные оценки для уточнения необходимого для данных отмены пространства.

Это представление одинаково хорошо собирает статистику и в ручном и в автоматическом режиме управления откатами.

Представление DBA_UNDO_EXTENTS – показывает время фиксации для каждого из экстентов в табличном пространстве отмены.

select segment_name, sum(bytes), sum(blocks) from dba_undo_extents

group by segment_name;