최소한의 다운타임으로 데이터베이스 이동하기
- Version : SQL Server 2005, 2008, 2008R2, 2012
SQL Server를 운영하다보면 디스크의 공간 부족 또는 디스크의 성능 등으로 인하여 새로운 드라이브로 데이터베이스를 이동해야하는 상황이 발생 할 수 있다. 이때 대용량 데이터베이스를 최소한의 다운타임으로 이동하기 위한 여러가지 방법에 대해서 알아보자. 각 방법에는 장단점이 있다.
[데이터베이스 분리 후 이동하여 연결하기]
데이터베이스를 이동 할 때 많이 사용하는 방법이다. 데이터베이스를 분리하여 데이터 파일을 이동한 다음 데이터베이스를 연결 하는 방법이다.
exec sp_detach_db DBName
File Move
exec sp_attach_db DBName, Filepath |
- sp_detach_db : http://technet.microsoft.com/library/ms188031.aspx
- create database..for attach : http://technet.microsoft.com/library/ms176061.aspx
장점
- 데이터베이스를 이동하는 가장 쉬운 방법이다.
- 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
단점
- 파일이 이동하는 동안 데이터베이스를 사용할 수 없다.
- 복제 된 데이터베이스가 분리 된 경우 배포를 할 수 없다.
- 데이터베이스가 분리 되면 모든 메타데이터가 삭제 된다. 어떤 로그인의 계정의 기본 데이터베이스인 경우 mater 데이터베이스로 변경 된다. 또한 데이터베이스간 소유권이 끊어진다.
- 데이터베이스를 분리 하기 전 스냅샷을 모두 삭제 해야 한다.
- 데이터베이스가 미러링 되어 있는 경우 미러링 세션이 종료 될 때 까지 분리 할 수 없다.
[데이터베이스 백업 후 백업 파일을 이용하여 복원]
데이터베이스를 백업하고 WITH MOVE switch를 사용하여 새 파일의 위치를 지정하는 방법이다.
- RESTORE WITH MOVE SWITCH : http://www.mssqltips.com/sqlservertip/3113/sql-server-database-restore-with-move-or-not-with-move/
장점
- 백업과 복원 방법만 알면 누구나 할 수 있다.
- 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
단점
- 데이터베이스 복원이 완료 될 때까지 데이터베이스나 파일 그룹에 액세스 할 수 없다.
- 백업 후 데이터가 변경된 경우 최근 백업을 다시 복원해야 한다.
[데이터베이스 OFFLINE 후 데이터베이스 이동]
데이터베이스를 오프라인으로 설정하고 수동으로 파일을 이동. 데이터베이스의 메타 데이터를 업데이트하는 명령을 실행하고 다시 온라인 시키는 방법이다.
장점
- 데이터베이스 분리처럼 Detach – Attach 방법을 사용한다.
- 테이블과 인덱스에 조각화를 생성하지 않는다.
- 데이터베이스 분리와 달리 메타 데이터를 보존 한다.
- 배포 및 미러된 데이터베이스도 작업 할 수 있다.
단점
- 파일이 이동하는 동안 데이터베이스에 액세스 할 수 없다.
[새로운 파일 그룹을 추가하여 이동]
새로운 파일 그룹을 생성하고 테이블과 인덱스를 새로운 파일그룹에 다시 작성한다. 작업이 완료되면 기존 파일 그룹 삭제가 가능하다.
장점
- 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
- 데이터베이스 메타 데이터가 보존 된다.
단점
주 파일 그룹에 대해서는 작동 하지 않는다.
- 데이터베이스 설계가 변경되기 때문에 신중한 테스트가 필요하다.
- 이전의 방법보다 많은 작업이 필요하다.
[로그 전달을 사용한 데이터베이스 이동]
로그 전달을 구성하여 데이터베이스를 이동한다. 복구모드가 심플일 경우 전체 복구 모두로 전환하여 구성 할 수 있다.
장점
- 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
- 데이터베이스 메타 데이터가 보존된다.
- 로그 전달 중에도 사용자는 기존 데이터베이스에 계속 액세스 할 수 있다.
단점
- SQL Server Agent 실행이 필요하다.
- 공유 폴더를 사용하기 때문에 폴더 사용 권한 검토가 필요하다.
- 로그 전달에 대한 전문적인 지식이 필요하다.
[수동으로 로그 전달 및 복원]
필자가 주로 사용하는 방법으로 대용량 데이터베이스의 경우 전체 백업을 수행하여 먼저 복원해 놓고 주기적으로 트랜잭션 로그 백업을 복사하여 복원하는 방법이다. 마지막에 사용자 접근을 차단하고 마지막 로그 백업을 실행하여 새로운 데이터베이스에 복원한다.
장점
- 테이블과 인덱스에 대한 조각화를 생성하지 않는다.
- 데이터베이스 복원 시 이름 변경 및 파일 경로 변경 가능하다.
- 데이터베이스 메타 데이터가 보존된다.
- 기존 데이터베이스에는 사용자가 계속 액세스 할 수 있다.
- 로그 전달보다 적은 구성이 사용된다.(백업, 복원만 하면 됨)
단점
- 백업을 복원할 때 WITH MOVE 옵션을 사용해야 한다.
[DBCC SHRINK FILE 후 데이터베이스 이동]
DBCC SHRINKFILE 명령을 사용하여 빈 공간을 축소. 데이터베이스를 이동하는 방법이다. (굳이 추천하고 싶은 방법은 아니다.) 이 방법은 위의 모든 방법보다 가장 느린 방법이다. 이 방법은 성능에 영향을 미칠 수 있으므로 주의해야 한다.
장점
- SHRINK FILE 작업 시 사용자가 데이터베이스에 계속 액세스 할 수 있다.
단점
- 다른 방법보다 더 오래 걸릴 수 있다.
- 테이블과 인덱스에 조각화를 많이 생산한다.
- 로그가 기록되므로 전체 복구 모드의 경우 적합하지 않다.
- SQL 로그 전달이 구성되어 있는 경우 권장되지 않는다.
- 많은 시스템 리소스(특히 디스크IO)를 소비하므로 시스템 성능에 문제가 발생 할 수 있다.
대용량의 데이터베이스를 이동해야 하는 경우 각 운영 환경에 맞는 방법을 선택하여 최적의 시나리오를 구성하여 연습을 해야 한다. 특히 백업과 파일이동, 복원의 경우 해당 파일의 용량, 복사에 따른 네트워크 속도, 디스크의 성능 등을 고려하여 시간을 산정하면 최소한의 다운타임으로 이동이 가능하리라 생각한다.
[참고자료]
강성욱 / jevida@naver.com
Microsoft SQL Server MVP
Blog : http://sqlmvp.kr
Facebook : http://facebook.com/sqlmvp
