Oracle что быстрее commit или rollback

Обновлено: 07.07.2024

Верно ли, что системы РСУБД оптимизированы для операций COMMIT ? Насколько медленнее /быстрее выполняются операции ROLLBACK и почему?

Для SQL Server вы можете утверждать, что операция фиксации - это не что иное, как запись LOP_COMMIT_XACT в файл журнала и освобождение блокировок, что, конечно же, будет быстрее, чем ROLLBACK каждого действия, которое ваша транзакция выполняла с BEGIN TRAN.

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

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

Изменить: бит бит .

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

Итак, пересмотренная версия моего более раннего ответа. Насколько медленнее откат? При прочих равных условиях для обычной OLTP-транзакции это не так. Вне границ типичного, это может занять больше времени, чтобы «отменить», чем «сделать», но (это потенциальный твистер языка?), Почему это будет зависеть от того, как было сделано «делать».

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

Создайте две таблицы и упакуйте их неэффективно (потерянное пространство на странице):

Запустите «плохой» запрос на обновление, измеряя время, затрачиваемое на выполнение работы, и время, затраченное на выпуск фиксации.

Сделайте то же самое, но выполните выпуск и отметьте откат.

С @ Rows = 1 я получаю разумную последовательность:

5500ms для поиска /обновления
3ms commit
Откат за 1 мс

8500msнайти /обновить
15ms commit
Откат за 15 мс

15000ms find /update
10ms commit
Откат 500 мс

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

Для Oracle откат может занять много времени дольше, чем время, затрачиваемое на изменение отката. Это часто не имеет значения, потому что

Никакие блокировки не удерживаются во время откат транзакции.
Он обрабатывается фоновым процессом с низким приоритетом

Для SQL Server я не уверен, что ситуация такая же, но кто-то скажет, если это не .

Что касается «почему», я бы сказал, что rollback должен быть редким , как правило, только если что-то пошло не так, и, конечно, commit , скорее всего, будет гораздо более распространенным - поэтому имеет смысл оптимизировать для commit

Откат не просто «о, неважно» - во многих случаях он действительно должен отменить то, что он уже сделал. Нет правила, что операция отката всегда будет медленнее или всегда будет быстрее, чем исходная операция. Если вы ждете, я предлагаю, чтобы было безопаснее просто ждать.

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

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

Не все. PostgreSQL не требует больше времени для отката, чем для фиксации, поскольку две операции фактически идентичны с точки зрения ввода /вывода на диске. На самом деле я не думаю, что это вопрос оптимизации для фиксации, поскольку речь идет о том, какие другие запросы оптимизируются для.

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

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

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

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

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

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

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

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

Oracle имеет как журнал, так и пространство отката. Журнал транзакций накапливает блоки, которые позже записываются авторами БД. Поскольку эти asychronous, почти ничего связанного с DB writer не влияет на вашу транзакцию (если очередь заполняется, вам, возможно, придется подождать.)

даже для транзакции только для запросов я готов поспорить, что в областях отката Oracle есть немного транзакционного учета. Я подозреваю, что откат требует некоторой работы со стороны Oracle, прежде чем он определит, что на самом деле нечего откатывать. И я думаю, что это синхронно с вашей транзакцией. Вы можете не отпустите все блокировки до завершения отката. [Да, я знаю, что вы не используете их в своей транзакции, но проблема блокировки заключается в том, почему я думаю, что откат должен быть полностью освобожден, тогда все замки могут быть освобождены, тогда ваш откат завершен.]

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

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

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

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

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

Что такое TCL-операторы в PL / SQL?

Операторы TCL означает используются для контроля транзакций в базе данных Oracle. Такой оператор либо сохранит ожидающие транзакции ( Commit ), либо откатит ожидающую транзакцию ( Rollback ). Эти операторы играют жизненно важную роль, потому что, если транзакция не сохранена, изменения через операторы DML не будут сохранены в базе данных. Ниже приведены различные операторы TCL.

Сохраняет все ожидающие (pending) транзакции

Отменяет все ожидающие транзакции

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

Отменить все ожидающие транзакции до указанной <точки сохранения> ( <save point> )

Транзакция будет завершена в следующих сценариях.

Когда выдается какое-либо из вышеуказанных утверждений (кроме SAVEPOINT )
Когда выдаются заявления DDL. (DDL - операторы автоматической фиксации)
Когда выдаются заявления DCL. (DCL - операторы автоматической фиксации)

Что такое автономная транзакция

В PL / SQL все изменения, сделанные в данных, будут называться транзакцией. Транзакция считается завершенной, когда к ней применено сохранение ( Commit ) / сброс ( Rollback ). Если сохранение / удаление не задано, транзакция не будет считаться завершенной, и изменения, внесенные в данные, не будут выполнены на сервере на постоянной основе (не будут зафиксированными в базе).

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

Свойства автономных транзакций

Автономная транзакция может быть указана на уровне подпрограммы.
Чтобы любая подпрограмма работала в другой транзакции, в декларативном разделе этого блока должно быть указано ключевое слово « PRAGMA AUTONOMOUS_TRANSATION ».
Оно даст указание компилятору обрабатывать это как отдельную транзакцию, и сохранение / отмена внутри этого блока не будет отражаться в основной транзакции.
Перед выходом из этой автономной транзакции в основную транзакцию необходимо выполнить COMMIT или ROLLBACK , поскольку в любой момент может быть активна только одна транзакция.
Поэтому, как только мы сделали автономную транзакцию, нам нужно сохранить ее и завершить транзакцию, тогда только мы можем вернуться к основной транзакции сеанса.

Синтаксис автономной транзакции

В приведенном выше синтаксисе блок был выполнен как автономная транзакция.

Примеры кода PL/SQL с автономной транзакцией

В этом примере мы собираемся понять, как работает автономная транзакция. Блоки основной и автономной транзакции приведены на рисунке ниже:

Результат выполнения кода:

Объяснение кода:

Строка 2: объявление l_salary как NUMBER .

Строка 3: объявление процедуры nested_block

Строка 4: Создание процедуры nested_block как « AUTONOMOUS_TRANSACTION »

Строки 7-9: повышение зарплаты сотруднику с номером 1002 на 15000.

Строка 10: фиксация транзакции

Строки 13-16: печать сведений о зарплате сотрудника 1001 и 1002 до внесения изменений

Строки 17-19: повышение зарплаты сотруднику № 1001 на 5000

Строки 20: вызов процедуры nested_block

Строки 21: отмена основной транзакции

Строки 22-25: печать сведений о зарплате сотрудника 1001 и 1002 после изменений.

Увеличение зарплаты сотруднику с номером 1001 не отразится в результате, поскольку основная транзакция была отклонена. Увеличение заработной платы сотрудника с номером 1002 отражено, поскольку этот блок был выполнен как отдельная (автономная) транзакция и сохранен в конце.

Таким образом, независимо от сохранения / отмены в основной транзакции, изменения в автономной транзакции были сохранены без изменения основных транзакций.

хотя я использую Git довольно часто, я все еще новичок.

иногда я делаю ошибку, но замечаю ее только после Я совершил это. В этот момент мне обычно приходится долго искать в Интернете команду, которую я должен использовать, чтобы избавиться от нее (перед тем, как нажать).

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

вернуться
изменить
откат
отменить.

У меня есть, что наконец-то пришло время узнать эти различия раз и навсегда. Каковы они?

условия вернуться и изменить имеют хорошо определенное значение в Git. В отличие от этого, откат и отменить не имеют такого четко определенного значения и открыты для интерпретации.

возвращаясь фиксации.

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

чтобы отменить фиксацию выявленных <commit> , просто запустите

изменение фиксации.

. означает замену" текущей " фиксации на новую, которая имеет тот же родитель(ы); подробнее в как именно git commit --amend работает?

имейте в виду, что

О внесении изменений фиксация, которую вы уже нажали на общий пульт, - плохая практика, потому что это форма перезаписи истории (она "удаляет" самую последнюю фиксацию, на которой ваши сотрудники, возможно, уже основывали свою работу);

вы можете изменить только последний коммит в данной ветви; чтобы переписать старые коммиты, вам нужно вывести big guns (например, interactive rebase).

чтобы изменить фиксацию, внесите все необходимые изменения и выполните их, затем запустить

откат.

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

отменить коммит.

. может означать в зависимости от контекста, либо вернуться или изменить фиксации.

git --amend Вы должны использовать команду git --amend только для коммитов, которые не были переданы в общедоступную ветвь другого репозитория Git. Команда git --amend создает новый идентификатор фиксации, и люди могут основывать свою работу уже на существующей фиксации. В этом случае им нужно будет перенести свою работу на основе нового commit

git revert Вы можете отменить коммиты с помощью команды git revert. Эта команда отменяет изменения совершать. Такие фиксации полезны для документирования того, что изменение было отозвано.

здесь [Введите описание ссылки здесь][1]

Отмена Изменений: git checkout , git revert , git reset , git clean

git revert : эта команда отменяет изменения фиксации. он ведет учет в журналах.

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

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