데이터베이스 파일을 이전 SAN에서 새로운 SAN으로 마이그레이션하려고합니다.이를 구현하는 몇 가지 옵션이 있습니다. (1) 서버의 새 데이터베이스에 전체 백업을 복원하려는 노력의 수준을 살펴볼 것을 제안했습니다. 그러나 (2) 원래 계획은 데이터베이스를 분리했다가 다시 연결하여 이전 SAN에서 새 SAN으로 파일을 복사하는 것이 었습니다.
내 직감은 더 안전하다고 생각되기 때문에 분리, 복사 및 부착 할 것이라고 말했지만 내 순진한 것일 수도 있습니다. 데이터베이스 이름을 바꾸는 과정에서 트랜잭션을 놓치거나 어떻게 든 "뭔가를 깨고"싶지 않습니다.
내 질문은 BACKUP-RESTORE-Replay 옵션에 대한 회의론에 정당화되어 있는지 여부와 그 옵션의 다른 장점이나 위험이 무엇인지 추측합니다.
답변:
개인적으로는 분리 / 연결 메커니즘을 피할 것입니다. 특히 SQL Server 2000에서는 서버를 항상 백업하고 해당 파일을 첨부 할 수 있다고 믿지 않습니다. 나는 당신이 Plan B를 가지고 있다고해서 Plan A가 자동적으로 합리적이지 않다는 이유만으로 이런 일이 제대로 일어나지 않았다는 이야기를 많이 들었습니다.
백업 / 복원을 사용하면 계획 B로 갈 필요가 없습니다. 백업이 실패해도 데이터베이스는 여전히 가동 중입니다. 복원에 실패하면 기존 데이터베이스가 여전히 작동 중입니다. 두 경우 모두 원본 데이터베이스의 작업을 복원하고 나중에 계획을 다시 방문 할 수 있습니다. 여기에 SQL Server 중지 및 / 또는 분리에 대한 추가 보안 외에도 백업 / 복원 방법에서 hoo-has를 테스트 할 수 있음을 의미합니다 (현재 백업을 수행 할 공간이 있고 테스트를 수행 할 다른 인스턴스가 있다고 가정). 복원). 데이터베이스를 분리하거나 SQL Server를 중지하지 않으면 분리 방법을 실제로 테스트 할 수 없으므로 적절한 유지 관리 기간을 벗어나기 란 쉽지 않습니다. 마지막으로, 다른 접근 방식을 사용하면 SQL Server를 분리하거나 종료 할 때까지 파일 복사를 시작할 수 없습니다.
SQL-Server에서 드라이브에서 꺼내기 방법에 비해 다른 이점이 있습니다. 백업 / 복원을 사용하면 다양한 파일을 이전과 다른 드라이브 문자로 옮길 수 있습니다. 예를 들어, 새로운 SAN으로 마이그레이션 할 때 더 많은 볼륨을 가질 수 있었으므로 tempdb를 T : \ (이전에 존재하지 않았 음), 일부 데이터 및 로그 파일 등을 새 드라이브 문자 등으로 옮길 수있었습니다. 우리가 가진 모든 새로운 I / O 용량을 더 잘 활용합니다. SQL Server를 종료 한 다음 디스크를 스왑하면 드라이브 문자와 볼륨 수가 동일해야합니다.
SAN 재구성 및 마이그레이션으로 인해 데이터베이스를 거의 지속적으로 이동했습니다.
한 번에 전체 서버를 이동한다고 가정하면 경로 # 2와 같은 것으로 갈 것입니다. (한 번에 하나의 데이터베이스를 이동하고 결국 서버에서 모든 데이터베이스를 수행하는 경우 파일 경로를 변경해야하기 때문에 더 문제가됩니다.)
"single_user"가 반드시 귀하를 의미하는 것은 아닙니다. 데이터베이스가 DBCC CHECKDB로 이동할 수 있으며 누군가 이미 데이터베이스에 있기 때문에 들어갈 수 없습니다. 데이터베이스에서 "모두 자신 만"부팅하기 위해 실행할 수있는 스크립트를 준비하고 편리한 곳에 보관하십시오. SQL 2000에는 최신 버전과 동일한 "모두 유지"기능이 없습니다.
오래된 트릭 중 하나는 SQL Server 서비스를 일시 중지하는 것입니다. 이렇게하면 새 로그인이 방지되지만 이미 연결된 사람은 평소대로 계속할 수 있습니다. 따라서 : SSMS 창을 통해 연결하여 작업을 수행 한 다음 서비스를 일시 중지 한 다음 바람직하지 않은 연결을 시작하고 SSMS 명령 창 (GUI가 아니라 많은 연결을 만들고 끊습니다)을 통해 작업을 수행 한 다음 일시 중지를 해제하십시오 서비스. 경고 : 클러스터에서 어떻게 작동하는지 잘 모르겠습니다. 장애 조치를 원할 수 있습니다.
작업이 완료 될 때까지 모든 앱 사용자를 서버 외부에 유지하는 방법이 편리합니다. 그렇지 않으면 작업을 수행하는 동안 연결이 시작되어 리소스 경합 및 / 또는 속도 저하가 발생할 수 있습니다. 정확한 상황에 따라 과거에 다음과 같은 방법을 사용했습니다. 앱 서버 끄기 ALTER DATABASE 사용 .. SET RESTRICTED_USER (앱 계정이 db_owner, sysadmin 또는 dbcreator 역할의 멤버 인 경우 문제가됩니다. ) 일요일 오전과 같이 특정 시간에 시스템이 오프라인 상태임을 사용자에게 알려줍니다. ( "실제"24x7 환경에서는 작동하지 않습니다.) 앱 서버 또는 사용자를 향한 NIC의 플러그를 뽑습니다. (이 경우 관리자 전용 네트워크에 연결된 다른 NIC 또는 ILO를 통해 들어갈 수 있습니다.)
많은 수의 데이터베이스를 분리하고 다시 연결하는 것은 많은 작업이 될 수 있습니다. 그렇게 할 경우, 미리 "첨부"스크립트를 작성했는지 확인하십시오.
SQL Server를 중지하고 모든 것을 복사하고 드라이브 문자를 변경하고 SQL Server를 시작하는 데 많은 성공을 거두었습니다. 분리 / 부착이 없습니다. SQL Server가 꺼져 있고 파일을 복사 (MOVING 아님)하고있는 한 시스템 데이터베이스를 이동하더라도 너무 많은 문제가 발생하지 않습니다. 경로가 동일하기 때문에 SQL Server는 서비스가 꺼져있는 동안 변경된 내용을 인식하지 못합니다. 드라이브 문자가 올바른 볼륨으로 돌아가는지 확인하십시오. 그렇지 않으면 문제가 발생합니다.
가장 빈번한 문제는 파일 디렉토리의 ACL을 올바르게 가져 오지 못했습니다. 최신 버전의 SQL Server는 서비스 계정에 필요한 권한 만 설정하는 것이 좋지만 이전 버전은 까다로워 보입니다. ACL을 설정하지 않고 서비스 계정이 로컬 관리자가 아닌 경우 (권장하지 않음) 인스턴스가 시작될 때 하나 이상의 데이터베이스가 열리지 않을 수 있습니다. 당황하지 말고 ACL을 변경하고 데이터베이스를 연결하십시오.
나는 일반적으로 이러한 종류의 작업을 수행하기 위해 ROBOCOPY를 사용합니다. ACL을 유지하기위한 명령 행 스위치가 있습니다.
CRC 계산 / 검증을 사용하는 것은 나쁜 생각이 아니지만 결코 그런 적이 없습니다. 데이터베이스가 백업되면 모든 데이터베이스에서 CHECKDB ()를 실행합니다. 일반적으로 유지 관리 작업을 수동으로 시작하는 것이 아니라 미리 스크립트를 준비합니다. 이렇게하면 몇 분 또는 몇 시간이 걸릴 수있는 큰 데이터베이스를 확인하기 전에 몇 개의 작은 데이터베이스를 먼저 확인할 수 있습니다. CRC 검사 (또는 Redgate Data Compare 도구)가 CHECKDB ()가 놓칠 수있는 것을 발견하고 SQL Server가 그것을 고칠 수 없다면 의심합니다.
파일을 복사 한 후 인스턴스를 다시 시작하기 전에 폴더 중 하나의 이름을 바꾸어 OLD 폴더의 파일 경로를 약간 변경합니다. 이것은 "서버가 여전히 이전 파일을 가리키고 있습니다"문제에 대한 추가 점검입니다.
이전 파일을 삭제하고 이전 저장소의 공간을 복구하고 전체 백업이 성공적으로 실행되었는지 두 배로 확인하십시오. 이 두 백업을 다른 곳으로 테스트 복원하십시오. checkdb () 실행이 양호하고 전체 백업이 양호하면 이전 스토리지를 삭제하고 왼쪽을 종료 할 수 있습니다.
이러한 마이그레이션으로 인해 최악의 문제는 내가 끝났다고 생각한 후에 발생했습니다. SAN 관리자가 문제가 발생하여 파일 시스템이 스크램블되었다고 알려줍니다. (파티셔닝, 재 포맷, 다시 복사)
또 다른 재미있는 문제는 명백한 이유없이 SAN이 느리다는 것입니다. 데이터를 복사하는 데 10 시간이 걸리고 시간 번호 9에서 30 %가 복사되면 문제가있는 것입니다. 전송 시간을 살펴보고 (로코 스코피는 복사 된 %를 표시하고 시간을 예상하거나 Perfmon을 사용할 수 있음) 무언가가 잘못 될 경우 대체 계획을 세웁니다.
또한 볼륨이 파티션되어 있는지 확실하지 않지만 1MB 오프셋을 사용하고 있는지 확인하고 싶을 수도 있습니다. Windows Server 2008 이상에서는 문제가되지 않습니다. 구형 OS에서는 그렇습니다. 이것에는 엄청난 양의 물건이 있으며, 스토리지 담당자가 알아야 할 것이지만 물어볼 것입니다.
먼저 스토리지 배열의 기능을 사용하여 데이터 이동을 처리하는 옵션을 살펴 보겠습니다. 공급 업체가 지원하지 않아 해당 제품을 사용할 수없는 경우 구매하지 않았거나 SAN 관리자가이를 수행하는 방법을 모르는 경우 ...
그런 다음 간단히 다음 단계를 사용합니다.
그게 다야.
SQL Server가 변경된 것이 없다는 것을 알고있는 한 분리 / 연결이 필요하지 않습니다. 문제가 심하게 잘못되면 기존 스토리지 어레이의 기존 LUN에 기존 데이터베이스 사본이 있습니다. 장애 복구는 드라이브 문자를 변경하는 것입니다.