답변:
전체 복구 모드로 전환하면 파일 그룹으로이 작업을 수행 할 수 있지만 실제로는 어색합니다. 데이터를 기본 파일 그룹에두고 인덱스를 별도 (기본이 아닌 키) 파일 그룹에 넣습니다.
그런 다음 매일 밤 1 차의 파일 그룹 백업을 수행하고 X 분마다 트랜잭션 로그 백업을 수행하도록 백업을 스 태거합니다.
재해가 발생하면 기본 파일 그룹 자체를 복원합니다. 데이터가 갑자기 온라인이지만 인덱스는 그렇지 않습니다. 그러나 정상 상태로 돌아가려면 해당 데이터를 새로운 깨끗한 데이터베이스로 내보내고 거기에서 인덱스를 추가해야합니다. 모든 파일 그룹을 복원하지 않고 데이터베이스를 완전히 온라인 상태로 만들 수 없으며 "다른 파일 그룹이 더 이상 필요하지 않습니다"라고 말할 수 없습니다.
작동 방식에 대한 자세한 내용은 파일 그룹 복원에 대한 비디오 자습서를 확인하십시오 .
솔직히, 당신은 다른 사람들이 여기서 제기하는 다른 문제를 극복하더라도 실제로 이것을하고 싶지 않습니다.
응급 상황에서 백업을 복원 할 때 인덱스가 다시 작성되기를 기다리지 않을 때까지 성능이 저하 될 수 있습니다.
인덱스없이 백업을 복원하려는 상황을 생각할 수 없으므로 모든 경우에 동시에 백업하려고합니다.
이 문제에 대한 다른 해결책을 찾아야 할 것입니다 ...
-아담
이것이 지원되지 않는 것처럼 들립니다. 이 버그 리포트 정보에서 :
이것에 많은 관심이 있었으므로,이면에서 일어나는 일과이 기능을 구현하는 것이 무엇을 의미하는지 조금 더 자세히 설명하겠습니다. 일부 유형의 인덱스 페이지는 별도의 할당 단위로 분리되는 반면 다른 유형의 페이지는 데이터 페이지와 혼합됩니다. 현재 범위가 할당되었는지 확인하기 위해 할당 비트 맵 만 살펴보면 이제 각 할당 단위에 저장된 내용을 해석해야합니다. 또한 이제 데이터를 복사하는 데이터 파일의 선형 스캔을 수행 할 수 없으며 파일에서 건너 뜁니다. 데이터 구조에 대한 이러한 모든 해석은 백업 속도를 크게 저하시킵니다. 백업의 허점을 설명하기 위해 고정해야하는 많은 구조가 있기 때문에 복원이 더욱 흥미로워집니다. 그렇지 않으면 백업되지 않은 페이지를 가리키는 할당 맵이 있고 페이지에 가비지 등이 있습니다. 따라서이를 구현하면 데이터를 더 적게 저장하고 더 오래 걸리며 많은 시간이 소요됩니다. 더 오래 복원합니다. 고려해야 할 다른 측면은 이것이 제대로 작동하려면 많은 엔지니어링 노력이 필요하다는 것입니다. 표면적으로는 문제가되지 않지만,보고자하는 다른 기능은 구축되지 않을 것입니다.
미친 생각일지도 모르지만 여기에 간다.
물론 데이터베이스가 하루 중 일부 다운 타임을 허용하는 경우에만 실제로이 작업을 수행 할 수 있습니다.
또한 SQL Server는 이러한 인덱스를 힙으로 변환하는 데 많은 시간을 소비하므로 클러스터형 인덱스를 삭제하지 마십시오.
추가 디스크 공간을 구입하는 것이 아직 쉬운 솔루션처럼 보입니까?
압축 백업 을 고려 했습니까 ? 이것은 2008 년의 새로운 기능이며 옵션 일 수 있습니다.