Лучший способ скопировать базу данных (SQL Server 2008)
Тупой вопрос - какой лучший способ скопировать экземпляры в среду, где я хочу обновить сервер разработки экземплярами с производственного сервера?
Я сделал резервное восстановление, но я слышал, что detach-copy-attach и один парень даже сказали мне, что он просто скопирует файлы данных между файловыми системами....
Являются ли эти три (или два, последние звучат вроде подозреваемого) принятыми методами?
Я понимаю, что второй метод работает быстрее, но требует времени простоя источника из-за аспекта отсоединения.
Кроме того, в этой ситуации (желая получить точную копию продукции на dev-сервере), какая принятая практика для переноса логинов и т.д.? Должен ли я просто создавать резервные копии и восстанавливать пользовательские базы данных + master + msdb?
Ответы
Ответ 1
Самый быстрый способ скопировать базу данных - это метод detach-copy-attach, но у производственных пользователей не будет доступа к базе данных при отсоединении prod db. Вы можете сделать что-то подобное, если ваша производственная БД - это, например, система Точки продажи, которую никто не использует ночью.
Если вы не можете отсоединить производственный db, вы должны использовать резервное копирование и восстановление.
Вам нужно будет создать логины, если они не находятся в новом экземпляре. Я не рекомендую вам копировать системные базы данных.
Вы можете использовать SQL Server Management Studio для создания сценариев, которые создают необходимые вам логины. Щелкните правой кнопкой мыши логин, который вам нужно создать, и выберите Script Вход в систему/Создать.
В этом списке указаны потерянные пользователи:
EXEC sp_change_users_login 'Report'
Если у вас уже есть идентификатор входа и пароль для этого пользователя, исправьте его, выполнив:
EXEC sp_change_users_login 'Auto_Fix', 'user'
Если вы хотите создать новый идентификатор входа и пароль для этого пользователя, исправьте его, выполнив следующие действия:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
Ответ 2
Самый простой способ - это script.
Запустите это при создании:
USE MASTER;
BACKUP DATABASE [MyDatabase]
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder.
WITH COPY_ONLY
Эта одна команда делает полную резервную копию базы данных в одном файле, не мешая доступности продукции или расписанию резервного копирования и т.д.
Чтобы восстановить, просто запустите это на своем dev или протестируйте SQL Server:
USE MASTER;
RESTORE DATABASE [MyDatabase]
FROM DISK = 'C:\temp\MyDatabase1.bak'
WITH
MOVE 'MyDatabase' TO 'C:\Sql\MyDatabase.mdf', -- or wherever these live on target
MOVE 'MyDatabase_log' TO 'C:\Sql\MyDatabase_log.ldf',
REPLACE, RECOVERY
Затем сохраните эти сценарии на каждом сервере. Удобство с одним щелчком.
Edit:
если вы получаете ошибку при восстановлении того, что логические имена не совпадают, вы можете получить их следующим образом:
RESTORE FILELISTONLY
FROM disk = 'C:\temp\MyDatabaseName1.bak'
Если вы используете учетные записи SQL Server (а не проверку подлинности Windows), вы можете запустить это после восстановления каждый раз (на dev/test machine):
use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';
Ответ 3
UPDATE:
Ниже приведен мой совет ниже, как script БД с использованием SQL Server Management Studio, но по умолчанию в SSMS по умолчанию не хватает всех важных частей базы данных (например, индексов и триггеров!). Таким образом, я создал свою собственную программу для корректной script базы данных, содержащей почти каждый тип объекта DB, который вы, возможно, добавили. Я рекомендую использовать это вместо этого. Он называется SQL Server Scripter, и его можно найти здесь:
https://bitbucket.org/jez9999/sqlserverscripter
Я удивлен, что никто не упомянул об этом, потому что это действительно полезно: вы можете выгрузить базу данных (ее схему и данные) в script, используя SQL Server Management Studio.
Щелкните правой кнопкой мыши базу данных, выберите "Задачи | Сгенерировать скрипты...", а затем выберите script конкретные объекты базы данных. Выберите те, которые вы хотите скопировать, в новую БД (вы, вероятно, хотите выбрать хотя бы Таблицы и Схемы). Затем на экране "Установить параметры сценариев" нажмите "Дополнительно", прокрутите вниз до "Типы данных до script" и выберите "Схема и данные". Нажмите "ОК" и завершите создание script. Вы увидите, что теперь вы создали длинный script для вас, который создает таблицы базы данных и вставляет в них данные! Затем вы можете создать новую базу данных и изменить оператор USE [DbName]
в верхней части script, чтобы отобразить имя новой базы данных, для которой вы хотите скопировать старый. Запустите script, а старую схему базы данных и данные будут скопированы в новую!
Это позволяет вам делать все это из студии SQL Server Management, и нет необходимости касаться файловой системы.
Ответ 4
Ниже приводится то, что я делаю, чтобы скопировать базу данных из производственного env в локальное env:
- Создайте пустую базу данных на локальном сервере sql
- Щелкните правой кнопкой мыши по новой базе данных → задачи → импортировать данные
- В Мастере импорта и экспорта SQL Server выберите имя продукта env servername в качестве источника данных. И выберите свою новую базу данных в качестве целевых данных.
Ответ 5
Сложно отделить ваше производство дБ или другое дБ и работать с этим простоем, поэтому я почти всегда использую метод резервного копирования/восстановления.
Если вы также хотите, чтобы ваш синхронизатор входа в систему, проверьте статью MS KB на использование хранимой процедуры proc sp_help_revlogin.
Ответ 6
Метод detach/copy/attach приведет к удалению базы данных. Это не то, что вы хотели бы получить на производстве.
Резервное копирование/восстановление будет работать, только если у вас есть права на запись на рабочий сервер. Я работаю с Amazon RDS, и я этого не делаю.
Метод импорта/экспорта на самом деле не работает из-за внешних ключей - если вы не делаете таблицы один за другим в том порядке, в котором они ссылаются друг на друга. Вы можете импортировать/экспортировать в новую базу данных. Это скопирует все таблицы и данные, но не внешние ключи.
Это звучит как обычная операция, которую нужно делать с базой данных. Почему SQL Server не справляется с этим? Каждый раз, когда мне приходилось это делать, это расстраивало.
При этом единственным безболезненным решением, с которым я столкнулся, был Sql Azure Migration Tool, который поддерживается общество. Он также работает с SQL Server.
Ответ 7
Я запускаю SP для DROP таблицы (-ов), а затем используйте пакет DTS для импорта последних производных таблиц в мою область разработки.
Затем я возвращаюсь домой и возвращаюсь на следующее утро. Это не изящно; но он работает для меня.
Ответ 8
Если вы хотите взять копию живой базы данных, выполните метод резервного копирования/восстановления.
[В SQLS2000, не уверенном в 2008 году:] Имейте в виду, что если вы используете учетные записи SQL Server в этой базе данных, в отличие от учетных записей Windows, если основная база данных отличается или не синхронизирована на сервере разработки, учетные записи пользователей не будут переведены при восстановлении. Я слышал о SP, чтобы переназначить их, но я не помню, какой из них был.
Ответ 9
Я использовал EMS SQL Backup, и у него есть задача доставки базы данных, которую можно легко планировать. Необходимо указать общую сетевую папку. Копирование выполняется с помощью резервного копирования/копирования/восстановления, но может быть установлено быстро.
Похоже, что нет возможности обрабатывать логины в программе, и вам придется делать это вручную.