축소는 악마라는 것을 알고 있습니다. 페이지 순서를 바꾸고 피부암, 데이터 조각화 및 지구 온난화를 담당합니다. 목록이 계속됩니다 ... 즉, 100GB 데이터베이스가 있고 하나의 테이블이 아니라 50GB의 데이터를 삭제하지만 데이터베이스의 전체 수준에서 오래된 데이터를 일반 정리하면 90 %를 차지합니다. 테이블-이것이 데이터베이스 축소에 대한 적절한 사용 사례를 구성합니까?
그렇지 않은 경우 데이터베이스에서 이러한 비율의 데이터를 제거한 후 집을 정리하기 위해 취해야 할 적절한 조치는 무엇입니까? 인덱스 다시 작성 및 통계 업데이트라는 두 가지를 생각할 수 있습니다. 또 뭐요?
답변:
재구성 및 축소는 실제로 권장되지 않습니다.
데이터베이스가 오프라인에서 제공하는 앱을 사용할 수있는 경우 축소하기 전에 모든 인덱스와 기본 / 외부 키 제약 조건을 제거하여 프로세스 속도를 높이고 인덱스 조각화를 줄일 수 있습니다. 현재 존재하지 않는 색인 페이지가 아닌 데이터 페이지가 섞여서 프로세스 속도가 빨라집니다.) 모든 색인과 키를 다시 작성하십시오.
축소 후 인덱스를 다시 작성하면 인덱스가 크게 조각화되어서는 안된다는 것을 의미하며 축소 중에 인덱스를 다시 작성하면 나중에 다시 조각화를 일으킬 수있는 파일 내의 페이지 할당에 많은 작은 "구멍"이 남지 않습니다.
응용 프로그램을 오프라인으로 할 수있는 경우 다른 옵션은 모든 데이터를 동일한 구조의 새로운 데이터베이스로 마이그레이션하는 것입니다. 빌드 프로세스가 확실하면 현재 DB에서 데이터베이스를 생성하지 않으면 빈 DB를 빠르게 빌드 할 수 있어야합니다 (현재 데이터베이스의 백업을 복원하고 테이블의 모든 내용을 자르거나 삭제하고 전체 축소를 수행).
많은 인덱싱 된 데이터 (이 경우 100 %)를 변경할 때 훨씬 효율적일 수 있으므로 대상의 모든 인덱스를 삭제하고 나중에 다시 생성 할 수 있습니다. 복사 프로세스 속도를 높이려면 다른 물리적 드라이브에있는 대상 데이터베이스의 데이터 파일을 소스로 가져 오십시오 (헤드 이동 감소에 신경 쓸 필요가없는 SSD를 사용하지 않는 한), 데이터를 이동할 수 있습니다 완료되면 소스 위치로.
또한 원본 복사본을 비우지 않고 새 대상으로 만드는 경우 모든 현재 데이터와 몇 개월 분량의 성장을 포함하는 초기 크기로 대상을 생성하면 데이터 복사가 조금 더 빨라집니다. 프로세스 전체에 걸쳐 새로운 공간을 매번 할당하지는 않습니다.
데이터를 새로운 데이터베이스로 마이그레이션하면 축소 작업의 의도 된 동작이 복제되지만 조각화가 훨씬 적으므로 재구성 및 축소의 의도하지 않은 결과로 인해 축소를 사용하는 것보다 낫습니다. 축소는 단순히 파일의 끝에서 블록을 가져와 처음에 가까운 공간에 배치하여 관련 데이터를 함께 유지하려는 노력을 기울이지 않습니다.
나중에 부분적으로 사용되는 페이지가 적을 가능성이 높으므로 결과는 공간적으로 더 효율적일 것으로 생각됩니다. 축소는 부분 사용 된 페이지를 이동 시키며, 특히 테이블의 클러스터 된 키 / 인덱스 (테이블이있는 경우) 순서대로 대상에 삽입하고 다른 인덱스를 생성하는 경우 데이터를 이동하면 전체 페이지가 생성 될 가능성이 높습니다. 데이터가 모두 마이그레이션 된 후
당신이 경우 물론 당신이 애플 리케이션은 단지 수축을 수행하는 모든 오프라인 취할 수없는 경우에하는 것은 그래서 당신의 유일한 옵션입니다 정말로 그와 함께 공간 이동을 회수 할 필요가있다. 데이터, 액세스 패턴, 공통 작업 세트 크기, 서버의 RAM 용량 등에 따라 추가 내부 조각화가 그다지 중요하지 않을 수 있습니다.
복사 작업의 경우 SSIS 또는 기본 T-SQL도 마찬가지로 작동합니다 (SSIS 옵션의 효율성은 떨어지지 만 나중에 유지 관리가 더 쉬울 수 있음). 인덱스와 함께 마지막에 FK 관계를 만들면 두 경우 모두 간단한 "각 테이블에 대해 복사"를 수행 할 수 있습니다. 물론 일회성, 축소 + 재구성도 괜찮을 것입니다.하지만 정기적 인 축소를 고려하지 않도록 사람들을 놀라게하고 싶습니다! (사람들이 매일 일정을 잡는 것을 알고 있습니다).
데이터베이스가 다시 커질까요? 그렇다면 축소 작업에 투입하려는 노력은 낭비가 될 것입니다. 파일 크기가 줄어들고 더 많은 데이터를 추가하면 파일이 다시 커져야하기 때문입니다. 거래는 그 성장이 일어날 때까지 기다려야합니다. 최적이 아닌 자동 성장 설정 및 / 또는 느린 드라이브가있는 경우이 성장 활동은 상당히 고통 스럽습니다.
데이터베이스를 축소하면 사용 가능한 디스크 공간을 어떻게 사용할 것입니까? 이 데이터베이스가 다시 커질 수 있도록 공간을 확보하려면 다시 바퀴를 돌리십시오.
파일 에이 모든 여유 공간이 생겼으므로 색인을 재구성하여 더 잘 최적화 할 수 있습니다 (여유 공간이있을 때이 작업을 수행하는 것이 훨씬 고통 스럽습니다). 작은 옷장과 큰 침실에서 스웨터를 바꾸려고 노력하십시오).
따라서 이것이 주요 정리 작업이 아니고 실제로 동일한 수준의 데이터로 다시 증가하지 않는 한 그대로 그대로두고 다른 최적화 영역에 중점을 둡니다.
공간이 부족한 경우 데이터가 커지지 않으면 축소되지만 일반적인 성장을 가능하게하는 적절한 채우기 비율로 인덱스를 다시 작성하십시오.
최종 목표가 실제로 백업 크기를 줄이는 것이라면 트랜잭션 로그를 지우고 포괄적 인 백업 전략을 구현하고 db를 백업 할 때 압축 옵션을 사용하십시오.
일반적으로 5GB가 자주 증가 할 것으로 예상되지 않는 한 5GB의 자동 증가를 권장하지 않습니다. 그렇지 않으면 간헐적 인 성능 문제가 발생할 수 있습니다. 데이터 크기는 먼저 1 년 동안 필요한 것으로 설정해야하며 자동 증가는 테스트 한 크기가 운영 성능에 영향을 미치지 않는 크기로 설정되어야합니다. SQL Server에서 데이터베이스 축소 단추를 건드리지 마십시오를 참조하십시오 ! 마이크 월시.
축소하기 전에 인덱스를 다시 작성하면 인덱스가 잘못 배치됩니다. 다시 빌드하고 축소하는 것은 좋지 않습니다. 축소는 공간을 복구하기 위해 인덱스를 엉망으로 만듭니다. 따라서 미리 재구성 한 후 축소는 의미가 없습니다. Thomas LaRock의 자동 축소 사용시기를 참조하십시오 .
축소 후 다시 인덱싱하는 것보다 이것이 더 잘 작동하는지 모르겠지만 다른 옵션은 적절한 크기의 새 데이터 파일을 만들고 모든 데이터를 그 위치로 옮기는 것입니다. 이 경우 먼저 다시 색인을 작성하여 실제 데이터 크기가 무엇인지 알 수 있습니다. 한 가지 발견은 이것이 기본 데이터 파일의 첫 번째 파일 인 경우 비울 수 없다고 생각합니다. 축소 한 다음 나중에 데이터를 다시 이동하면 페이지 반전을 피할 수 있습니다. 그러나 솔리드 스테이트로 전환하려는 경우 큰 차이는 없습니다.
이 길로 늦게 돌아 왔습니다. 아직도, 우리는 테스트 환경에서 수축 사용을 오랫동안 숙고하고 테스트 해 왔습니다. 주제에 따라,이 있는 정신과 의사는 실행 가능한 옵션이 때 시간은. 그러나 적용시기와 방법을 아는 것은 장기 및 단기 모두에서 적절한 실행에 필수적입니다.
이 시나리오에서는 최근에 압축, 파티셔닝, 아카이빙 및 일반 중복 데이터 삭제를 포함하여 대규모 DB에 수많은 변경 사항을 추가했습니다. 결과적으로, 기본 데이터 파일의 사용 된 부분이 예전보다 절반 이하로 떨어졌습니다. 그러나 모든 짐을 운반하는 것이 무엇입니까? 특히 웹상의 일부 기사와 달리 데이터 파일의 크기는 백업 / 복원 기간과 직접적으로 관련됩니다. 많은 기사와 달리 실제 시나리오에는 제거 된 것보다 주어진 페이지에 더 많은 데이터가로드되기 때문입니다.
요컨대 축소를위한 훌륭한 시나리오가 열립니다.
이렇게하면 DB의 시스템 객체, 통계, 절차 및 기타 데이터 만 남게됩니다. 축소는 훨씬 빨라지고 훨씬 빠르며, 주요 데이터 객체에 대해 더 이상 인덱스 유지 관리가 필요하지 않으며 순서대로 깔끔하게 생성되어 향후 조각화의 위험을 최소화 할 수 있습니다.