Лучший способ создать сценарий отката SQL Server?

Question

Я работаю над некоторыми изменениями схемы в существующей базе данных.

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

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

• Удалите новые ограничения и индексы
• Измените таблицы, чтобы удалить новые столбцы
• Удалить добавленные таблицы
• Зафиксировать транзакцию

Есть ли лучший подход?

Answer 1

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

Answer 2

Вы упускаете пятый шаг

• Удалите новые ограничения и индексы
• Измените таблицы, чтобы удалить новые столбцы
• Удалить добавленные таблицы
• Зафиксировать транзакцию
• Протестируйте сценарий до конца, прежде чем запускать его в производство

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

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

Answer 3

Если это относительно небольшая база данных, просто сделайте резервную копию перед применением обновления.Если все пойдет наперекосяк, вы выполняете восстановление.

Как только он заработает и будут введены новые данные, вы все равно не сможете откатить его назад.Вы просто должны устранить проблемы.

Answer 4

Если вы используете такой инструмент, как Redgate SQL Compare, вы можете запустить сравнение между двумя базами данных обоими способами и использовать оба для создания необходимых вам сценариев.сценарий dev to prod будет содержать вносимые вами изменения, а сценарий prd to dev вернется в исходное состояние рабочей базы данных.Это гарантирует, что вы также ничего не забудете ни в одном из сценариев.

Answer 5

С SQL Server 2005 или новее вы также можете создать моментальный снимок базы данных, который позволяет вам вернуться к этому состоянию в любое время.Смотрите эту страницу для получения дополнительной информации:

http://msdn.microsoft.com/en-us/library/ms175158.aspx