Может ли команда COMMIT (в SQL) когда-либо терпеть неудачу? Как?

При работе с транзакциями базы данных каковы возможные условия (если они есть), которые приведут к завершению окончательного оператора COMMIT в транзакции, предполагая, что все операторы в транзакции уже выполнены без проблем?

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

-- <initial handshaking stuff>
START TRANSACTION;
-- <Execute a bunch of SQL statements>
-- <Inform master of readiness to commit>
-- <Time passes... background transactions happening while we wait>
-- <Receive approval to commit from master (finally!)>
COMMIT;

Если ваш код попадает в этот окончательный оператор COMMIT и отправляет его в вашу СУБД, можете ли вы когда-нибудь получить сообщение об ошибке (проблема уникальности, полная база данных и т.д.) в этом заявлении? Какие ошибки? Зачем? Как они появляются? Разве это зависит от того, какую СУБД вы запускаете?

Ответы

Ответ 1

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

И что не учитывая другие причины, которые он может потерпеть неудачу:

  • Само изменение может не соответствовать ограничениям базы данных.

  • Потеря мощности не позволяет завершить работу.

  • Уровень запрошенного выбора concurrency может запретить обновление (например, курсоры, обновляющие измененную таблицу).

  • Фиксирование может быть тайм-аутом или быть соединением, которое истекает из-за проблем с голоданием.

  • Сетевое соединение между клиентом и базой данных может быть потеряно.

И все остальные "простые" причины, которые не на моей голове.

Ответ 2

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

Ответ 3

Конечно.

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

Томас

Ответ 4

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

Как утверждает Ignacio, может быть отложен контроль ограничений (это может быть любая форма ограничения, а не только уникальное ограничение, в зависимости от механизма СУБД).

Спецификация SQL Server: сброс данных FILESTREAM можно отложить до момента фиксации. Это может потерпеть неудачу.

Ответ 5

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

Транзакция может выйти из строя, если она никогда не получает одобрения от ведущего (по каким-либо причинам).

Ответ 6

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

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

Будем надеяться.

Ответ 7

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