디스크 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로 옮기고 사용되지 않은 다른 파일을 제거하기 위해 예약 된 창을 사용합니다. 다운 타임을 최소화하기 때문에 이것을 좋아합니다. 그러나 이것이 얼마나 오래 걸릴지, 그것이 일어나는 동안 성능이 저하되는지 여부는 알 수 없습니다.
이를 테스트 할 수있는로드 및 성능 환경이 없습니다. 전략이 준비 환경에서 작동하지만 성능이 아닌 영향은 아닌지 확인할 수 있습니다.
don't know how long it will take to do a differential analysis of 1.4TB
최소한 그 데이터를 읽는 데 걸리는 한. 나는 rsync 아이디어가 많은 것을 절약한다고 생각하지 않습니다. rsync는 느린 네트워크에 대처하기 위해 만들어졌습니다.