Можно ли временно отключить изменения базы данных в Microsoft SQL Server?

В грядущем обновлении мне нужно будет преобразовать несколько таблиц на нашем сервере из UTF-16 в UTF-8. Я ожидаю, что это займет несколько часов.

Есть ли хороший способ отключить INSERTS и UPDATES, но разрешить SELECTS в базе данных?

Или мне нужно заблокировать изменения на бизнес-уровне/отключить базу данных, пока происходит обновление?

У вас может быть XY-проблема. Существуют способы сделать то, что вы пытаетесь сделать, не требуя, чтобы обрабатываемые таблицы были недоступны для изменения на время операции. Вот как бы я его качал (высокий уровень):

1. Добавьте новый столбец с нужным определением (тип данных, сопоставление и т. д.).
2. Используйте триггеры «после вставки», чтобы убедиться, что изменения данных, поступающие из вашего приложения, также изменяют новый столбец.
3. Заполните существующие данные в таблице.
4. Удалите старый столбец, переименуйте новый столбец, чтобы он имел имя старого столбца.

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

На самом базовом уровне "Да" вы можете это сделать... DENY INSERT, UPDATE, DELETE ON <table> TO <user> однако невозможно сказать, как отреагирует ваше приложение. По моему опыту, большинство приложений будут разбрызгивать ошибки повсюду и кричать о кровавом убийстве, если вы сделаете это, возможно, даже повредив данные (непроверенные ошибки, плохое использование транзакций и т. д.). Редко (возможно, никогда) я не видел приложения, которое изящно переключалось в режим только для чтения, когда доступ к базе данных был не таким, как планировалось/ожидалось.

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

Если ваши требования не допускают длительного простоя (или вообще не допускают отключения), существуют более сложные способы справиться с этим. Одной из мыслей было бы добавить триггер после вставки/после обновления для автоматического преобразования новых/обновленных записей в новое поле во время обслуживания небольших пакетов. Как только все данные будут преобразованы, переключите приложение на новое поле и удалите старое.

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

1. Создайте копию своей базы данных.
2. Запустите обновления схемы на копии.
3. Используйте такой продукт, как Redgate SQL Compare, или напишите свои собственные скрипты для синхронизации данных. Собери их как можно ближе
4. Закройте приложение, повторная синхронизация.
5. Измените подключение к базе данных на новую базу данных (или переименуйте базы данных).
6. Перезапустите приложение.

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

Я хотел бы сделать это по нескольким причинам. Минимальные простои и влияние на пользователей. Возможность безопасного отката. Возможность проверить влияние изменений схемы/данных.

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