Oracle ALTER SESSION ADVISE COMMIT?

Мое приложение автоматически восстанавливается после сбоев. Я тестирую это следующим образом:

  1. Запустить приложение
  2. В середине обработки убить хост сервера приложений (shutdown -r -f)
  3. При перезагрузке хоста перезапускается сервер приложений (как служба Windows)
  4. Приложение перезагружается
  5. Приложение пытается выполнить обработку, но оно блокировано незавершенной двухфазной транзакцией фиксации в базе данных Oracle из предыдущего сеанса.
  6. Где-то между 10 и 30 минутами позже БД разрешает предыдущий txn, и обработка продолжается нормально.

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

ALTER SESSION ADVISE COMMIT;

Но он не может дать мне гарантий или подробностей о возможности потери данных при этом.

К счастью, рассматриваемый оператор просто обновляет значение datetime до SYSDATE каждую секунду или около того, поэтому, если было какое-то повреждение данных, оно длилось бы ‹ 1 секунды, прежде чем оно было бы перезаписано.

Но, на мой вопрос. Что именно делает приведенное выше утверждение? Как Oracle решает проблемы синхронизации данных при его использовании?


person Synesso    schedule 03.06.2011    source источник


Ответы (1)


Можете ли вы уточнить роль «локальной» и «удаленной» баз данных в вашем сценарии.

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

  1. Начинает транзакцию
  2. Вносит изменения в базу данных
  3. Вносит изменения в другую базу данных
  4. Заставляет другую базу данных «обещать зафиксировать»
  5. Локально фиксирует
  6. Получает удаленную базу данных для фиксации

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

Ваше описание, похоже, относится к сбою сервера приложений, который представляет собой другой чайник рыбы. В вашем случае, я думаю, сценарий следующий:

  1. Сервер приложений принимает соединение и запускает транзакцию
  2. Сервер приложений умирает без фиксации
  3. Сервер приложений перезагружается и устанавливает новое соединение с базой данных.
  4. Сервер приложений запускает новую транзакцию в новом соединении
  5. Новая транзакция «зависает» в ожидании блокировки, удерживаемой старым соединением/транзакцией.
  6. Через 20 минут мертвое соединение разрывается, а транзакция откатывается.
  7. Затем продолжается новая транзакция.

В этом случае решение состоит в том, чтобы быстрее отключить старое соединение с более коротким временем ожидания (например, SQLNET_EXPIRE_TIME в sqlnet.ora сервера) или вручную ALTER SYSTEM KILL SESSION.

person Gary Myers    schedule 03.06.2011