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

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

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

Этот последний вариант требует, конечно, поддержки приложений и имеет смысл (есть приложения, в которых режим только для чтения не имеет смысла.)

Если вы используете SQL Server, вы всегда можете удалить фрагментацию индекса онлайн, начиная с SQL Server 2000 и далее. Команда DBCC INDEXDEFRAG всегда выполняет оперативную реорганизацию. Я написал это специально как альтернативу DBCC DBREINDEX.

В SQL Server 2005 и более поздних версиях команда ALTER INDEX ... REORGANIZE заменяет DBCC INDEXDEFRAG и всегда находится в сети. Также в 2005 году с помощью Enterprise Edition вы можете перестраивать индексы в режиме онлайн, используя ALTER INDEX ... REBUILD ... WITH (ONLINE=ON). В начале и в конце операции требуется несколько очень краткосрочных блокировок таблиц, поэтому он не такой онлайновый, как REORGANIZE (а перестройка индекса в основном онлайн - не очень хороший маркетинговый термин:-). Вы даже можете переместить индексы в новые файловые группы, используя CREATE INDEX ... WITH DROP_EXISTING и указав ONLINE=ON.

Спасибо

Общие задачи обслуживания

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

Изменение схемы базы данных

Когда вам нужно обновить схему базы данных, вы будете вынуждены выключить свое решение на несколько минут (или в состояние только для чтения), ЕСЛИ изменение нарушает старую версию. Если ваша новая схема просто создает таблицы или поля, это не повлияет на старую версию¹, поэтому такой вид изменения схемы можно выполнить онлайн² и с помощью развертывания Blue-Green для вашего приложения для достижения высокой доступности.

Если ваша новая схема переименовывает существующее поле или удаляет его, чтобы достичь 100% времени безотказной работы, вам необходимо выполнить следующие шаги:

Переименование поля

1. Если вам нужно переименовать из A в B, примените изменение схемы, которое добавляет новое поле B и дублирует содержимое A. Кроме того, держите нетронутым.
2. Разверните новое приложение, которое использует поле B и не использует поле A.
3. Примените изменение схемы, которое удаляет A.

Удаление поля

1. Не применяйте никаких изменений схемы.
2. Разверните новое приложение, которое не использует поле, которое будет удалено.
3. Примените изменение схемы, удаляющее поле.

Примечание 1: некоторые инструменты ORM, такие как.NET Entity Framework, связывают каждое изменение схемы с идентификатором миграции. Таким образом, при развертывании новой версии схемы старые приложения мгновенно ломаются. Этого также можно избежать, если отключить эту проверку.

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

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

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

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