Подтвердить что ты не робот

Лучший способ скопировать базу данных (SQL Server 2008)

Тупой вопрос - какой лучший способ скопировать экземпляры в среду, где я хочу обновить сервер разработки экземплярами с производственного сервера?

Я сделал резервное восстановление, но я слышал, что detach-copy-attach и один парень даже сказали мне, что он просто скопирует файлы данных между файловыми системами....

Являются ли эти три (или два, последние звучат вроде подозреваемого) принятыми методами?

Я понимаю, что второй метод работает быстрее, но требует времени простоя источника из-за аспекта отсоединения.

Кроме того, в этой ситуации (желая получить точную копию продукции на dev-сервере), какая принятая практика для переноса логинов и т.д.? Должен ли я просто создавать резервные копии и восстанавливать пользовательские базы данных + master + msdb?

4b9b3361

Ответ 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, и у него есть задача доставки базы данных, которую можно легко планировать. Необходимо указать общую сетевую папку. Копирование выполняется с помощью резервного копирования/копирования/восстановления, но может быть установлено быстро. Похоже, что нет возможности обрабатывать логины в программе, и вам придется делать это вручную.