Лучшие практики для изменения схемы SQL Server 2008 - PullRequest
5 голосов
/ 13 декабря 2010

Я ищу информацию, относящуюся к следующему:

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

Производственная база данных является серверной для двух отдельных веб-сайтов ASP.NET.

Наш процесс изменения схемы достаточно устойчив, и каждая "миграция" фактически представляет собой файл .cs, содержащий изменения схемы.Затем мы будем использовать ADO.NET, чтобы применить изменения схемы к базе данных.

Мой вопрос больше связан с подключением базы данных.

Должен ли я остановить два сайта, которые обращаются к БД.Я предполагаю, что должен.Стоит ли переводить БД в однопользовательский режим.Похоже, я должен, но я не совсем уверен в этом.

Чего мне не хватать?Какие вещи укусили вас за руку перед изменениями схемы БД.

Ответы [ 3 ]

5 голосов
/ 13 декабря 2010

Если обновления меняют такие вещи, как имена столбцов, сохраненные параметры процедуры и т. Д., То всегда переводите приложения в автономный режим перед обновлением схемы.

Если обновления предназначены только для вещей, которые не влияют на нормальную обработку данных, тогда вы можете сделать это "горячим". Эта категория - когда вы добавляете такие вещи, как индексы, таблицы и т. Д.

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

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

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

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

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

3 голосов
/ 13 декабря 2010

Я не учел маршрут .cs / ado.net для внесения изменений в схему.Что мы делаем, это создаем «дельта» .SQL файлы - SQL для внесения изменений.Они выполняются по схеме известной ревизии для внесения изменений, и запуск .SQL является частью развертывания.

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

Когда мы внедряем, у нас есть определенное время дня / недели, предупреждайте пользователей / клиентовзакрытие веб-сайтов и т. д. Благодаря практическим развертываниям, проводимым почти каждый день на dev и промежуточных серверах в последние дни перед выпуском, окончательное доверие к развертыванию остается высоким.

Сохраняя изменения схемы в SQL, они больше похожи на «основную» схему SQL, которую они модифицируют, и поэтому их легче отслеживать.Меньше отлаживать тоже!

Они также управляются в TFS вместе с остальным кодом.

0 голосов
/ 13 декабря 2010

Идеальная ситуация, но не всегда достижимая: Вы вносите изменения схемы, совместимые с версией V вашего веб-сайта. Затем вы выпускаете V на свои веб-серверы. После того, как все ваши веб-серверы до V , вы можете выполнить любые очистки (заполнить пропущенные значения и т. Д.), А затем внести соответствующие изменения обнуляемости.

...