데이터베이스를 복사하는 가장 좋은 방법 (SQL Server 2008)

데이터베이스를 복사하는 가장 좋은 방법 (SQL Server 2008)

---

바보 같은 질문-프로덕션 서버의 인스턴스로 개발 서버를 새로 고치고 싶은 환경에서 인스턴스를 복사하는 가장 좋은 방법은 무엇입니까?

나는 백업-복원을했지만, 나는 분리-복사-첨부를 들었고, 한 사람은 그가 파일 시스템 사이에서 데이터 파일을 복사하겠다고 말했다 ....

이 세 가지 (또는 두 가지, 마지막 하나는 의심스러운 것 같음) 허용되는 방법입니까?

내 이해는 두 번째 방법이 더 빠르지 만 분리 측면으로 인해 소스에서 다운 타임이 필요하다는 것입니다.

또한이 상황 (개발 서버에 정확한 프로덕션 사본을 원함)에서 로그인 등을 전송하는 데 허용되는 관행은 무엇입니까? 사용자 데이터베이스 + master + msdb 만 백업하고 복원해야합니까?

---

데이터베이스를 복사하는 가장 빠른 방법은 detach-copy-attach 방법이지만 프로덕션 사용자는 prod db가 분리되는 동안 데이터베이스에 액세스 할 수 없습니다. 예를 들어 프로덕션 DB가 밤에 아무도 사용하지 않는 POS 시스템 인 경우 이와 같은 작업을 수행 할 수 있습니다.

프로덕션 DB를 분리 할 수없는 경우 백업 및 복원을 사용해야합니다.

새 인스턴스에없는 경우 로그인을 만들어야합니다. 시스템 데이터베이스를 복사하지 않는 것이 좋습니다.

SQL Server Management Studio를 사용하여 필요한 로그인을 만드는 스크립트를 만들 수 있습니다. 생성해야하는 로그인을 마우스 오른쪽 버튼으로 클릭하고 Script Login As / Create를 선택합니다.

분리 된 사용자가 나열됩니다.

EXEC sp_change_users_login 'Report'

이 사용자의 로그인 ID와 비밀번호가 이미있는 경우 다음을 수행하여 수정하십시오.

EXEC sp_change_users_login 'Auto_Fix', 'user'

이 사용자에 대한 새 로그인 ID 및 비밀번호를 작성하려면 다음을 수행하여 수정하십시오.

EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'

---

가장 쉬운 방법은 실제로 스크립트입니다.

프로덕션에서 실행 :

USE MASTER;

BACKUP DATABASE [MyDatabase]
TO DISK = 'C:\temp\MyDatabase1.bak' -- some writeable folder. 
WITH COPY_ONLY

이 하나의 명령은 프로덕션 가용성이나 백업 일정 등을 방해하지 않고 데이터베이스의 전체 백업 복사본을 단일 파일로 만듭니다.

복원하려면 개발자 또는 테스트 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

그런 다음이 스크립트를 각 서버에 저장하십시오. 원 클릭 편리함.

편집 :
논리 이름이 일치하지 않는다는 것을 복원 할 때 오류가 발생하면 다음과 같이 얻을 수 있습니다.

RESTORE FILELISTONLY
FROM disk = 'C:\temp\MyDatabaseName1.bak'

SQL Server 로그인 (Windows 인증이 아님)을 사용하는 경우 매번 (개발 / 테스트 시스템에서) 복원 한 후이를 실행할 수 있습니다.

use MyDatabaseName;
sp_change_users_login 'Auto_Fix', 'userloginname', null, 'userpassword';

---

업데이트 :
아래의 조언은 SQL Server Management Studio를 사용하여 DB를 스크립팅하는 방법을 알려 주지만 SSMS의 기본 설정은 어떤 이유로 데이터베이스의 모든 중요한 부분 (예 : 인덱스 및 트리거!)을 놓치고 있습니다. 그래서 추가했을 수있는 거의 모든 유형의 DB 개체를 포함하는 데이터베이스를 올바르게 스크립팅하기 위해 자체 프로그램을 만들었습니다. 대신 이것을 사용하는 것이 좋습니다. SQL Server Scripter라고하며 여기에서 찾을 수 있습니다 :
https://bitbucket.org/jez9999/sqlserverscripter

---

정말 유용하기 때문에 아무도 이것을 언급하지 않았다는 것에 놀랐습니다 . SQL Server Management Studio를 사용하여 데이터베이스 (스키마 및 데이터)를 스크립트로 덤프 할 수 있습니다 .

데이터베이스를 마우스 오른쪽 단추로 클릭하고 "작업 | 스크립트 생성 ..."을 선택한 다음 특정 데이터베이스 개체를 스크립팅하도록 선택합니다. 새 DB로 복사 할 항목을 선택합니다 (최소한 테이블과 스키마를 선택하는 것이 좋습니다). 그런 다음 "스크립팅 옵션 설정"화면에서 "고급"을 클릭하고 "스크립팅 할 데이터 유형"으로 스크롤 한 다음 "스키마 및 데이터"를 선택합니다. 확인을 클릭하고 스크립트 생성을 마칩니다. 이 이제 데이터베이스의 테이블을 만들어 당신을위한 긴 스크립트를 생성 한 것을 볼 수 와 그들에 데이터를 삽입을! 그런 다음 새 데이터베이스를 만들고 이전 데이터베이스 USE [DbName]를 복사하려는 새 데이터베이스의 이름을 반영하도록 스크립트 상단의 문을 변경할 수 있습니다. 스크립트와 이전 데이터베이스 실행 '

This allows you to do the whole thing from within SQL Server Management studio, and there's no need to touch the file system.

---

Below is what I do to copy a database from production env to my local env:

1. Create an empty database in your local sql server
2. Right click on the new database -> tasks -> import data
3. In the SQL Server Import and Export Wizard, select product env's servername as data source. And select your new database as the destination data.

---

Its hard to detach your production dB or other running dB's and deal with that downtime, so I almost always use a Backup / restore method.

If you also want to make sure to keep your login's in sync check out the MS KB article on using the stored proc sp_help_revlogin to do this.

---

The detach/copy/attach method will take down the database. That's not something you'd want in production.

The backup/restore will only work if you have write permissions to the production server. I work with Amazon RDS and I don't.

The import/export method doesn't really work because of foreign keys - unless you do tables one by one in the order they reference one another. You can do an import/export to a new database. That will copy all the tables and data, but not the foreign keys.

This sounds like a common operation one needs to do with database. Why isn't SQL Server handling this properly? Every time I had to do this it was frustrating.

That being said, the only painless solution I've encountered was Sql Azure Migration Tool which is maintained by the community. It works with SQL Server too.

---

I run an SP to DROP the table(s) and then use a DTS package to import the most recent production table(s) onto my development box. Then I go home and come back the following morning. It's not elegant; but it works for me.

---

If you want to take a copy of a live database, do the Backup/Restore method.

[In SQLS2000, not sure about 2008:] Just keep in mind that if you are using SQL Server accounts in this database, as opposed to Windows accounts, if the master DB is different or out of sync on the development server, the user accounts will not translate when you do the restore. I've heard about an SP to remap them, but I can't remember which one it was.

참고URL : https://stackoverflow.com/questions/2043726/best-way-to-copy-a-database-sql-server-2008