Есть ли разница между фиксацией и откатом в транзакции, имеющей только выборки?

Поскольку вы не использовали DML, я подозреваю, что в Oracle не будет разницы между COMMIT и ROLLBACK. В любом случае делать нечего.

В целом COMMIT выполняется намного быстрее, чем ROLLBACK, но в случае, когда вы ничего не сделали, они фактически одинаковы.

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

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

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

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

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

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

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

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

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

В документации указано, что:

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

http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_4010.htm#SQLRF01110

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

Что ж, мы должны учитывать, что возвращает SELECT в Oracle. Есть два режима. По умолчанию SELECT возвращает данные в том виде, в каком они просматривались в тот самый момент, когда оператор SELECT начал выполняться (это поведение по умолчанию в режиме изоляции READ COMMITTED, транзакционном режиме по умолчанию). Итак, если UPDATE / INSERT был выполнен после того, как был выдан SELECT, он не будет виден в наборе результатов.

Это может быть проблемой, если вам нужно сравнить два набора результатов (например, дебетовую и кредитную стороны приложения главной книги). Для этого у нас есть второй режим. В этом режиме SELECT возвращает данные в том виде, в котором они выглядели в момент начала текущей транзакции (поведение по умолчанию на уровнях изоляции READ ONLY и SERIALIZABLE).

Итак, по крайней мере, иногда необходимо выполнять SELECT в транзакции.

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