온라인 상태에서 SQL Server 데이터베이스를 새 디스크로 이동


11

디스크 I / O로 인해 어려움을 겪고있는 1.4TB SQL Server 데이터베이스가 있습니다. 우리는 모든 문제를 해결할 서버에 새로운 SSD 어레이를 설치했으며 데이터베이스를 이동하는 가장 좋은 방법에 대해서만 논의하고 있습니다. 다운 타임없이 할 수 있다면 이상적입니다. 그러나 2 일 동안의 다운 타임과 2 일 간의 성능 저하 (예 : 데이터 복사 중) 중 하나를 선택하는 것이 바람직 할 수 있습니다.

지금까지 우리가 생각 해낸 솔루션은 다음과 같습니다.

  • 간단한 사본. DB를 오프라인 상태로 만들고 파일을 복사하고 SQL Server의 위치를 ​​변경 한 후 다시 온라인 상태로 만듭니다. 대략적인 수치는이 작업에 최대 5 시간이 소요될 것으로 예상되는데 이는 실제로 허용되지 않지만 가장 쉬운 솔루션입니다.

  • 블록 레벨 사본. rsync와 유사한 유틸리티를 사용하여 DB가 작동하는 동안 파일을 백그라운드에서 복사합니다. 마이그레이션 할 준비가되면 DB를 오프라인으로 전환하고이 유틸리티를 사용하여 차등 복사를 수행 한 다음 SQL 파일을 새 파일로 지정하고 온라인 상태로 만듭니다. 여기서 타이밍을 알 수 없습니다. 1.4TB의 차등 분석을 수행하고이를 복사하는 데 시간이 얼마나 걸리는지 알 수 없습니다. 또 다른 문제는 블록 수준 복사본이 SQL Server에서 읽을 수없는 상태로 파일을 남겨두고 시간을 낭비한다는 것입니다.

  • SQL 마이그레이션. 새 디스크에 새로운 1.4TB SQL 데이터 파일을 만들고 다른 모든 파일에서 자동 증가를 비활성화하십시오. 그런 다음 다른 모든 데이터 파일에서 DBBC SHRINKFILE (-file_name-, EMPTYFILE)을 차례로 실행하십시오. 모든 데이터가 저장되면 일정 시점에 MDF 파일을 SSD로 옮기고 사용되지 않은 다른 파일을 제거하기 위해 예약 된 창을 사용합니다. 다운 타임을 최소화하기 때문에 이것을 좋아합니다. 그러나 이것이 얼마나 오래 걸릴지, 그것이 일어나는 동안 성능이 저하되는지 여부는 알 수 없습니다.

이를 테스트 할 수있는로드 및 성능 환경이 없습니다. 전략이 준비 환경에서 작동하지만 성능이 아닌 영향은 아닌지 확인할 수 있습니다.


데이터 파일이 LVM 파티션에 저장되어 있습니까?
Marco

1
don't know how long it will take to do a differential analysis of 1.4TB최소한 그 데이터를 읽는 데 걸리는 한. 나는 rsync 아이디어가 많은 것을 절약한다고 생각하지 않습니다. rsync는 느린 네트워크에 대처하기 위해 만들어졌습니다.
usr

2
EMPTYFILE을 사용하는 대신 SSD에있는 새 파일 그룹으로 모든 인덱스를 다시 작성합니다. 그렇게하면 인덱스가 훌륭하고 조각 모음 된 것처럼 보입니다. EMPTYFILE이 확실하지 않을 수 있습니다.
usr

답변:


14

전체 데이터베이스를 이동하는 한 가지 방법은 BACKUPRESTORE입니다. 최종 전환 중에는 데이터베이스를 사용할 수 없지만 계획시 다운 타임을 최소화해야합니다. 이 절차에서는 FULL또는 BULK_LOGGED복구 모델을 가정합니다 .

1) 전체 백업을 수행하십시오 (또는 기존 백업을 사용하십시오).

2) 최신 전체 백업을 다른 데이터베이스 이름으로 복원하여 WITH MOVE원하는대로 SSD 스토리지에 파일을 재배치하는 NORECOVERY옵션과 후속 차등 및 로그 백업을 복원 할 수있는 옵션을 지정합니다 .

3) 트랜잭션 로그 백업을 통한 최종 컷 오버 시점까지 및 새 데이터베이스에 증분 변경 사항을 적용하십시오 RESTORE...WITH NORECOVERY. 이렇게하면 새 데이터베이스로 최종 전환되는 가동 중지 시간이 최소화됩니다.

4) 새 데이터베이스로 전환하려면 응용 프로그램을 오프라인으로 전환하고 최종 트랜잭션 로그 백업을 수행 한 다음 새 데이터베이스에 적용하십시오 WITH RECOVERY. 마지막으로 원래 데이터베이스의 이름을 다른 이름으로 바꾸고 재배치 된 데이터베이스의 이름을 원래 이름으로 바꿉니다. 편리하게 이전 데이터베이스를 삭제하십시오.

단순 복구 모델에서는 유사한 프로세스를 사용할 수 있지만 3 단계 트랜잭션 로그 백업 / 복원은 수행 할 수 없습니다. 대신, 최종 단계에서 차등 데이터베이스 백업 / 복원을 사용하십시오. 초기 FULL백업 이후의 변경 양에 따라 더 많은 가동 중지 시간이 필요할 수 있습니다 .


예, 동일한 서버 DB 이동에서 가장 단순하고 빠른 것으로 생각되는 것은 없습니다.
Marian

-6
Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.

2
당신은 질문에 대답하지 않기 때문에 투표를 받고 있습니다. 논의중인 상황에는 서버가 하나뿐입니다.
AakashM

또한 DB를 이동하는 좋은 방법은 미러링, 로그 전달, 가용성 그룹, 백업 및 기타입니다. 불행히도 문제가 해결되지는 않습니다.
Marian

하나의 서버에서 두 개의 인스턴스를 만들고 두 인스턴스간에 복제를 수행 할 수 있습니다.
Avinash Mendse
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.