Огромная транзакция в Sql Server, есть ли проблемы?

Question

У меня есть программа, которая выполняет много массовых операций с базой данных SQL Server 2005 или 2008 (удаляет и создает индексы, создает столбцы, полные обновления таблиц и т. Д.), Все в одной транзакции.

Есть ли проблемы?быть ожидаемым?

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

Существуют ли другие причины для разделения транзакции на более мелкие этапы?

Answer 1

Короче говоря,

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

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

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

Answer 2

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

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

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

Если что-то пойдет не так, я надеюсь, что у вас есть сценарии отката и / или резервная копия.

Есть ли действительно необходимость делать все атомарно?

Answer 3

В зависимости от сложности ваших операторов обновления, я бы рекомендовал делать это только для небольших таблиц, скажем, из нескольких 100 строк.Особенно, если у вас есть только небольшой объем доступной основной памяти.В противном случае, например, обновление больших таблиц может занять очень много времени и даже зависнуть.Тогда трудно понять, что делает процесс (spid) и сколько времени это может занять.

Я не уверен, является ли "Drop index" операцией, регистрируемой транзакцией в любом случае.См. этот вопрос здесь на stackoverflow.com.

Answer 4

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

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