Я ищу способ предотвратить вход в систему, чтобы сделать полную резервную копию базы данных для миграции с текущего экземпляра SQL Server 2000 на новый экземпляр SQL 2005. Мой друг предложил запустить сценарий, который переводит БД в состояние отката. Не будучи администратором баз данных, мой DDL очень плох, и запуск сценария, который я не понимаю, может быть не лучшей идеей.
Один из вариантов, который может быть проще, - просто отсоединить и скопировать на новый сервер.
Любые предложения будут ценны.
Есть несколько способов сделать это, некоторые из них более элегантны, чем другие:
Отсоединить, скопировать на новый сервер, присоединить к новому серверу, повторно присоединить к текущему серверу
Переведите БД в однопользовательский режим и сделайте резервную копию
Отключите сетевой кабель от сервера.
Блокировать входящие подключения к порту 1433
отсоединить / скопировать / прикрепить будет работать. (Не оставляйте файлы LDF. Они важны, хотя некоторые люди так не думают, особенно если вы быстро закрываете базу данных. Вы можете потерять данные, если журнал неправильно прикреплен к новый сервер.).
У меня есть другая альтернатива, в которой используется часто упускаемая из виду функция «Пауза» SQL Server.
Я считаю, что установка базы данных для одного пользователя может быть проблемой, когда у вас много пользователей, которые переходят в эту базу данных. Они становятся «одиночными пользователями» до того, как это сделает мое соединение.
Мой метод работает лучше всего, если у вас есть окно запроса, а не графический интерфейс SSMS. Этот метод может не сработать, если вы используете кластер (прошло много лет с тех пор, как я пробовал его, и я не помню результат. Вы не хотите, чтобы случайно запускалось переключение при отказе).
Кроме того, этот метод может не работать, если есть другие базы данных для других приложений, работающих на том же SQL Server.
Войдите в окно запроса как администратор. Вы будете использовать это соединение, чтобы убить spids (через мгновение), а затем сделать резервную копию базы данных в последний раз.
Приостановите службу SQL Server. (В SSMS щелкните правой кнопкой мыши значок сервера или используйте апплет панели управления или любую аналогичную программу управления службами.)
Это предотвратит любой новые имена входа в этот экземпляр, включая подключения администратора, подключения db_owner и подключения агента SQL, но существующие подключения не будут сброшены. Пока сервер приостановлен, попытки подключения не удастся и вы получите сообщение об ошибке. Возможно, вы захотите предупредить своих пользователей или службу поддержки.
Затем скопируйте результат в окно запроса и запустите его. Он уничтожит все соединения в текущей базе данных, кроме вашего.
Вы можете использовать «Возобновить» в том же меню, что и «Пауза», чтобы разрешить вход, когда вы закончите, если хотите. Установите старую базу данных в режим «только для чтения» или «в автономном режиме» (желательно), прежде чем впускать людей обратно. («Офлайн» лучше, чем «только для чтения», потому что вы хотите, чтобы люди получали сообщения об ошибках в том случае, если вы что-то пропустили при указании строк подключения на новую. Сервер. Удаление базы данных также приведет к появлению сообщений об ошибках, но автономный режим не так постоянен. Если вам нужно вернуться на старый сервер, легко просто изменить базу данных в Интернете, но вам придется выполнить восстановление, если вы удалили базу данных. Вы всегда можете отказаться от автономной базы данных завтра, когда убедитесь, что миграция прошла успешно.)
Конечно, вам необходимо восстановить резервную копию на сервере, на который вы мигрируете, исправить любые входы SQL, затем исправить строки подключения для приложений или изменить запись DNS для сервера, в зависимости от того, как вы это обрабатываете, включите функция контрольной суммы базы данных, выполнить полное переиндексирование всех таблиц, обновить уровень совместимости базы данных, если это необходимо, и т. д. и т. д.
Если вы новичок в этом, или если это особенно важно или у вас есть требовательные пользователи, я бы посоветовал сначала попробовать хотя бы один пробный прогон. Вам не нужно будет всех выгнать для пробного запуска, просто сделайте резервную копию и восстановите ее на новом сервере. Выполнение восстановления заставляет вас определить, где находятся файлы (буквы дисков и пути могут быть разными на разных серверах), и дает вам представление о том, сколько времени потребуется на восстановление. (На самом деле, если у вас уже есть копия базы данных на новом сервере, это обычно немного быстрее, если вы восстанавливаете «с заменой», чем если вы собираетесь с нуля. Это дает вам некоторое пространство для маневра при предоставлении оценить для пользователей, как долго система будет отключена для миграции.)
Если вы не используете только логины Windows, вы хотите проверить, что логины SQL работают, прежде чем делать это «по-настоящему». Лучше всего, если у вас есть тестовая система, имитирующая продакшн, где вы можете отработать свой "WTF?" первые моменты, но не у всех есть такая роскошь.
перевод базы данных в однопользовательский режим подойдет. Вам нужно будет сделать резервную копию прямо сейчас в текущем подключении, чтобы предотвратить восстановление других подключений, если вы отключите соединение и попытаетесь использовать Enterprise Manager для выполнения резервного копирования. Вы также захотите отключить базу данных, когда закончите. Вот пример использования северного ветра.
use northwind
alter database northwind set single_user with rollback immediate
backup database northwind to disk='c:\northwind.bak' with init
use master
alter database northwind set offline