Законное использование DUMP TRAN

Question

Мне недавно пришлось устранить причину периодических ошибок ODBC в 12-летнем приложении на основе SQL.Виновником оказалось следующее утверждение в конце одной из хранимых процедур:

DUMP TRAN NotTheRealDBName WITH NO_LOG

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

Я пытаюсь представить, почему в середине бизнеса нужно создавать резервные копии и восстанавливать журнал транзакцийлогика, но я не могу обдумать это.Кто-нибудь может привести пример эффективного использования DUMP TRAN?

Answer 1

Их ключевой частью является то, что программа также добавляет предложение WITH NO_LOG. Так что в основном это усекает журнал. Вероятно, 12 лет назад автор столкнулся с проблемами роста журнала, «тщательно» исследовал проблему и пришел к выводу, что лучший способ - обрезать журнал, когда он делал какие-то длинные обновления. Не берите в голову, что в процессе он разрывает цепочку резервного копирования любого плана обслуживания ...

Answer 2

DUMP теперь BACKUP, и я почти уверен, что опция NO_LOG была прекращена в SQL Server 2008 (и по уважительной причине).

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

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

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

Answer 3

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