Oracle что происходит при commit

Обновлено: 02.07.2024

Для работы с транзакциями Oracle поддерживает следующие операторы SQL:

Слово WORK в COMMIT и ROLLBACK носит косметический характер и употребляется по желанию.

Команды COMMIT и ROLLBACK

В Oracle отсутствует команда для создания новой транзакции (в отличие от стандарта SQL), но есть две команды завершения: фиксацией результатов выполнявшихся в последней транзакции команд DML ( COMMIT ) и отказом от них ( ROLLBACK ). Соединение с СУБД автоматически приводит к началу новой транзакции, и то же случается по завершению отработки любой команды COMMIT или ROLLBACK . Таким образом, все операции с данными (таблиц, индексов, внутренних объектов LOB ) волей-неволей всегда выполняются в Oracle в рамках какой-нибудь транзакции, а сеанс связи программы с СУБД выглядит последовательностью сменяющих друг друга транзакций. Команды завершения транзакции затрагивают только операции DML, но в некоторых случаях СУБД порождает такие команды самостоятельно. Так, всякая команда DDL завершается неявной (скрытой) выдачей COMMIT ; аварийный разрыв сеанса или возникновение исключительной ситуации на уровне программы сопровождается неявной выдачей ROLLBACK .

Иногда приводят два методических правила по употреблению COMMIT :

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

Операция COMMIT затратна для СУБД и при особо частой выдаче может заметно тормозить работу СУБД. В версии 10 введена возможность ускоренного выполнения COMMIT . Для этого в команде можно указать ключевые слова BATCH ("групповая фиксация": запись о выдаче COMMIT заносится в буфер журнала в СУБД, но не провоцирует перенос журнальных записей в файл) или NOWAIT (СУБД начинает обрабатывать следующую команду сеанса, не дожидаясь фактического завершения отработки COMMIT ):

Пример такого поведения можно наблюдать, прогнав в SQL*Plus с помощью сценарного файла следующий текст:

Здесь разрыв транзакции достигается форсированной перезагрузкой СУБД: STARTUP FORCE .

Любое из указаний BATCH или NOWAIT в команде COMMIT WRITE отменяет гарантию со стороны СУБД попадания последних изменений в БД в случае сбоя, невзирая на выдачу программой пользователя COMMIT .

Умолчательный способ отработки COMMIT при наличии указанных вариантов можно установить для всей СУБД ( ALTER SYSTEM … ) и для отдельных сеансов ( ALTER SESSION … ) параметрами СУБД:

Сервер Oracle использует быстрый механизм фиксации, который гарантирует, что зафиксированные изменения могут быть восстановлены в случае отказа экземпляра.

Системный Номер Изменения

Всякий раз, когда транзакция фиксируется, сервер Oracle присваивает транзакции SCN фиксации.

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

Шаги в Обработке Фиксаций

Когда выполяется обработка COMMIT, происходят следующие шаги:

Серверный процесс помещает запись фиксации, наряду с SCN, в буфер журнала транзакций.

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

Пользователю сообщается, что COMMIT выполнен.

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

Сбрасывание грязных буферов в файл данных выполняется независимо DBW0 и может произойти или до, или после фиксации.

Преимущества Быстрой Фиксации

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

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

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

Если несколько транзакций фиксируются одновременно, экземпляр осуществляет комбинирование нескольких записей журнала транзакций и пишет их за один раз.

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

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

Отметьте : Откат транзакции не инициирует запись LGWR на диск. Сервер Oracle всегда откатывает незафиксированные изменения при восстановлении после отказов. Если происходит отказ после отката, прежде, чем записи отката будут записаны на диск, отсутствие записи фиксации достаточно, чтобы гарантировать, что изменения, произведенные транзакцией, откатываются.

Есть потребность в деталях разобраться в базовых вещах СУБД Oracle.
Читаю родную документацию, и не только родную..понимаю . и не понимаю. делюсь своими мыслями по-поводу и хочу услышать Ваше понимание тех или иных вещей.
Кому-то это будет полезно с точки зрения познания нового, кому-то с точки зрения "вспомнить все", а для кого-то это может стать первоисточником в будущем.

Итак, первое что вызвало некие неоднозначные мысли в моей голове это : "что же происходит при COMMIT и ROLLABACK в деталях" . на уровне роботы процессов СУБД , последовательности действий с блоками данных.

Я выскажу свое понимание того что происходит , хочу услышать поправки(если будут). Понимать то что происходит буду по первоисточнику - родной документации от фирмы производителя.

Разбираем COMMIT и ROLLABACK в деталях:
Смотрим Oracle® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 раздел - 4 Transaction Management :
1.
A transaction is a logical unit of work that contains one or more SQL statements. A transaction is an atomic unit. The effects of all the SQL statements in a transaction can be either all committed (applied to the database) or all rolled back (undone from the database).

с этим все предельно понятно. думаю ни у кого не возникает вопросов.

2.
читаем , читаем, читаем. не интересует пока, The Two-Phase Commit Mechanism. не интересуют Savepoints In Transactions. и коммиты с роллбеками в транзакциях с сейвпоинтами. пока не думаем по именовании транзакций ..не вдумываемся в тонкости автономных транзакций. находим самое интерестное . что же происходит при COMMIT и ROLLABACK.

3.
Commit Transactions:
Before a transaction that modifies data is committed, the following has occurred:
3.1. Oracle has generated undo information. The undo information contains the old data values changed by the SQL statements of the transaction.
3.2. Oracle has generated redo log entries in the redo log buffer of the SGA. The redo log record contains the change to the data block and the change to the rollback block. These changes may go to disk before a transaction is committed.
3.3. The changes have been made to the database buffers of the SGA. These changes may go to disk before a transaction is committed.

Понимаем:
В буферном кэше области SGA "висят" блоки с даннымикоторые будут менятся.
Итак:
3.1. Генерируется анду информация..анду тейблспейс и роллбэк сегмент..это из этой же "темы" (или нет. )
- undo information = "дельта"(только изменения) между первоначальным состоянием блока данных и тем что произошло..или .
3.2. Генерятся реду блоки информации..которые пока висят в памяти в "log buffer of the SGA". эти блоки могут начать писаться на диск в реду -лог фалы. ну при опред. условиях. Том Кайт писал про 3. например в буфере 1 Мб накопилось. или .
3.3. Изменяются "первоначальные" блоки в буферном кэше области SGA. или. . и могут начать писаться на диск ДО коммита . пока не совсем четко . в каких случаях будут писаться на диск эти блоки .

с этим воот так . теперь дальше смотрим :
3.4.
When a transaction is committed, the following occurs:
3.4.1. The internal transaction table for the associated undo tablespace that the transaction has committed, and the corresponding unique system change number (SCN) of the transaction is assigned and recorded in the table.

3.4.2. The log writer process (LGWR) writes redo log entries in the SGA's redo log buffers to the redo log file. It also writes the transaction's SCN to the redo log file. This atomic event constitutes the commit of the transaction.

3.4.3. Oracle releases locks held on rows and tables.

3.4.4. Oracle marks the transaction complete

и понимаем:
3.4.1. получается за анду тейблсейсом закреплена некая "внутрення таблица транзакций". в нее запишется SCN закомиченой транзакции. или.

3.4.2. процесс LGWR пишет на диск в реду-лог файлы буферы из буфера журналов повторного выполнения содержащии только изменения. + пишет SCN транзакции. или .

3.4.3. "разруливает" блокировки. кстати могут возникнуть нюансы). по времени)

3.4.4. "помечает" транзакцию. комплит. где помечает.

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

4.
Rollback of Transactions
Rolling back means undoing any changes to data that have been performed by SQL statements within an uncommitted transaction. Oracle uses undo tablespaces (or rollback segments) to store old values. The redo log contains a record of changes.

In rolling back an entire transaction, without referencing any savepoints, the following occurs:

4.1. Oracle undoes all changes made by all the SQL statements in the transaction by using the corresponding undo tablespace.
4.2. Oracle releases all the transaction's locks of data.
4.3. The transaction ends.

и понимаем.
4.1. возвращает обратно все что было выполнено используя "corresponding undo tablespace". как . . вычитывает обратно с диска старые значения. и применяет к буферам буферного кеша области SGA . или . . я так понимаю в редулогах всеравно есть записи о изменениях которые в итоге не применились. просто без отметки SCN
4.2. снимает блокировки. понятно.
4.3. где-то что об этом указывается ?

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

Ждем резензий . правок . и просто мыслей расширяющих мировозрение в данной теме. :)

До сих пор вы знакомились с компонентами системы базы данных Oracle: необходимыми файлами и распределением памяти, а также способами их настройки. Теперь пришло время посмотреть, как Oracle обрабатывает пользовательские запросы и как проводит изменение в данных. Важно понимать механизм обработки транзакций SQL, потому что все взаимодействие с базой данных Oracle происходит либо в форме запросов SQL, которые читают данные, либо операций SQL (или PL/SQL), которые модифицируют, вставляют или удаляют данные.

Транзакция – это логическая единица работы в базе данных Oracle, состоящая из одного или более операторов SQL. Транзакция начинается с первого исполняемого опертартора SQL и завершается, когда вы фиксируетет или отказываете транзакцию. Фиксация (commiting) транзакции закрепляет проведенные вами изменения, а откат (roll back) – конечно же, отменяет их. Как только вы зафиксировали транзакцию, все прочие транзакции других пользователей, которые начались после нее, смогут видеть изменения, проведенные вашими транзакциями.

Когда транзакция вообще не может выполниться (скажем, из-за отключения электропитания), то она вся целиком должна быть отменена. Oracle откатывает все изменения, проведенные предшествующими операторами SQL, возвращая данные в исходное состояние (которое они имели перед началом транзакции). Весь процесс построен так, чтобы поддерживать целостность данных – т.е. концепцию «все или ничего».

Следующий простой пример вставки строки описывает то, как Oracle обрабатывает транзакцию.

Фиксация и откат

Вы должны четно понимать два фундаментальных термина, касающихся транзакций: фиксаций (commiting) и откат (rolling back) транзакций. Ниже кратко объясняются оба термина.

Фиксация транзакции

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

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

База данных может писать изменения транзакции, которые были выполнены первыми, из буферов базы данных в SGA в файлы данных немедленно или же спустя какое-то время после фиксации транзакции, либо даже перед ее фиксацией. Когда баз данных фиксирует транзакцию, она выполняет следующее.

База данных назначает и записывает SCN для фиксируемой транзакции.
Писатель журналов пишет элементы журнала повторного выполнения в файл журнала повторного выполнеяия на диске из буфера журнала повторного выполнения в SGA: он также записывает SCN транзакции в файл журнала повторного выполнения, помечая тем официальную фиксацию транзакции.
База данных освобождает все блокировки таблиц и строк.
База данных помечает транзакцию как завершенную.

Откат транзакции

Отменить изменения, выполненные транзакцией, которые еще не были зафиксированы можно с помощью команды ROLLBACK. В то время как журнал повторного выполнения содержит все изменения, проведенные в транзакции, сегмент отмены (undo) содержит все старые значения, которые существовали до момента проведения изменений. Вы можете либо откатить изменения, проведенные всей транзакцией, либо просто вернуться к маркеру, который поместили ранее внутри транзакции, называемому точкой сохранения (savepoint). Существует несколько типов отката, среди которых перечислены ниже:

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

Независимо от причины отката, процедура всегда одна и та же.

База данных использует данные в виде, который они имели до изменения в табличном пространстве undo, чтобы отменить все изменения, проведенные во время транзакции.
База данных освобождает все блокировки транзакции и таблицы.
База данных завершает транзакцию

Целостность данных и параллелизм данных

База данных была бы не слишком полезной, если бы множество пользователей не могли обращаться к данным и модифицировать их одновременно. Под параллелизмом данных (a concurrency) понимают способность базы данных обеспечивать параллельный доступ для множества пользователей. Чтобы обеспечить согласованные результаты, база данных нуждается в механизме, который гарантирует, что пользователи не будут натыкаться на изменения, проводимые друг другом. Целостность данных (data consistence) - это возможность для пользователя получать согласованное представление данных, включая все изменения, проведенные в них другими пользователями.

Для обеспечения целостности данных, Oracle использует специальные структуры, именуемые сегментами отмены (undo segments). Например, когда вы читаете набор данных для транзакции, Oracle обеспечивает, чтобы прочитанные данные были согласованы по набору транзакций т.е. гарантирует, что данные, которые вы видите, отражают один набор зафиксированных транзакций. Oracle также обеспечивает согласованность данных по чтению, что означает, что все данные, выбранные вашими запросами, относятся к одному моменту времени. Сегменты отмены Oracle – это часть табличного пространства undo, упомянутого ранее в этой главе.

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

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

Блокировки Oracle сложны, и вы детально познакомитесь с ними в главе 8, вместе с тем, как Oracle обеспечивает согласованность и параллелизм данных.

Писатель базы данных и протокол опережающей записи

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

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

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

Системный номер изменения

Системный номер изменения, или SCN (system change number) – важный оценочный фактор, используемый базой данных Oracle для отслеживания состояния в каждый данный момент времени. Когда вы читаете (SELECT) данные в таблицах, то не затрагиваете состояния базы данных, но когда модифицируете, вставляете или удаляете строку, то состояние базы данных по отношению к тому, каким оно было до операции. Oracle использует SCN для слежения за всеми изменениями, проведенными в базе данных со временем. SCN – это логическая временная метка, используемая Oracle для упорядочивания событий, происходящих с базой данных. SCN очень важен по нескольким причинам, не последняя из которых – восстановление базы данных после сбоя.

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

SCN помогает Oracle определять необходимость восстановления после сбоя, после внезапного прерывания работы экземпляра базы данных или после издания команды SHUTDONW ABORT. Всякий раз, когда база данных выполняет операцию контрольной точки, Oracle пишет команду START SCN в заголовки файлов данных. Управляющий файл поддерживает значение SCN для каждого файла данных, называемый STOP SCN, который обычно устанавливается в бесконечность, и всякий раз, когда экземпляр останавливается нормально (командой SHUTDOWN NORMAL или SHUTDOWN IMMEDIATE). Oracle копирует номер START SCN в заголовках файлов данных в номера STOP SCN ля файлов данных в управляющем файле. Когда вы перезапускаете базу данных после успешного останова, нет необходимости ни в каком восстановлении, потому что номера SCN в файлах данных и управляющих файлах соответствуют. С другой стороны, внезапное прерывание работы экземпляра не оставляет времени на приведение в соответствие номеров SCN, и Oracle обнаруживает необходимость восстановления экземпляра, потому что отличаются номера SCN в файлах данных с одной стороны, и управляющем файле - с другой. Они играют ключевую роль в восстановлении базы данных. Oracle определяет, на сколько нужно вернуться, применяя архивные журналы повторного выполнения во время восстановления на основе SCN.

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

Когда вы проводите изменения в базе данных, вы должны иметь возможность отменить или откатить это изменение при необходимости. Информация, необходимая для отмены или отката изменений транзакции, которая в основном состоит из информации таблицы, предшествующей изменению, называется данными отмены (векторами изменений) и хранится в записях отмены (undo records). При выдаче команды ROLLBACK Oracle использует эти записи отмены для замены измененных данных их исходными версиями. Записи отмены жизненно важны для восстановления базы данных, когда незавершенные или незафиксированные транзакции должны быть отменены, чтобы оставить базу в согласованном состоянии.

Oracle настоятельно рекомендует использовать средство автоматического управления изменениями (Automatic Undo Management - AUM), при котором сам сервер oracle будет поддерживать и управлять сегментами отмены (отката). Все, что вам нужно сделать – это предоставить выделенное табличное пространство undo и установить параметр инициализации UNDO_MANAGEMENT в auto. Oracle создаст необходимое количество сегментов отмены, которые структурно подобны традиционным сегментам отката, и будет расширять их по мере необходимости. Нет ничего необычного в том, что будут создаваться новые сегменты отмен, а старые – деативизироваться в зависимости от количества транзакций, проводимых в базе данных.

Поскольку Oracle самостоятельно управляет размерами индивидуальных сегментов отмены, два решения, которые вы должны принять, касаются размера табличного пространства undo и установки инициализационного параметра UNDO_RETINTION (который определяет, насколько долго Oracle будет стараться хранить для вас записи об отмене в табличном пространстве undo). Помните, что ваше табличное пространство undo должно не только вместить все долговременные транзакции, но так же быть достаточно большим, чтобы позволить работать всем средства ретроспективы (flashback), которые вы можете реализовать в вашей базе данных; средства ретроспективы Oracle позволяют отменять изменение данных на различных уровнях. Некоторые из них, такие как Flashback Query, Flashback Versions Query и Flashback Table используют данные отмены.

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

Читайте также: