우리는 거대한 생산 데이터베이스를 가지고 있으며 크기는 약 300GB입니다. 삭제 쿼리의 성능을 향상시키는 방법이 있습니까? 현재 삭제 속도는 분당 1-10k 사이이며 매우 느립니다.
답변
단일 명령문에서 많은 수의 행을 삭제하려는 경우 로그 활동을 기다리는 중일 수 있습니다. 그래서 당신은 할 수 있습니다 :
- 성장 이벤트로 인해 속도가 느려지지 않도록 로그의 크기가 적절한 지 확인하십시오. 기본값을 사용하면 로그가 1MB에서 시작하여 10 % 증가 할 수 있습니다. 성장 이벤트는 비용이 많이 들고 10GB의 삭제를 기록하는 경우 VLF에서 수행하는 작업으로 인해 현재뿐만 아니라 향후에도 성능이 저하됩니다.
- 전체 테이블을 삭제하려면
TRUNCATE또는DROP/를 사용하십시오CREATE. - 대부분 의 테이블을 삭제하는 경우을 사용
SELECT INTO하여 유지하려는 데이터를 다른 테이블에 넣은TRUNCATE다음 작은 부분을 뒤로 이동하십시오. 또는 이전 테이블을 삭제하고 새 테이블의 이름을 바꾸고 제약 조건 / 권한 등을 다시 적용하십시오. - 한 번에 청크 대신 데이터를 삭제하여 처음부터 로깅의 영향을 최소화하십시오. 이 기사를 참조 하십시오 . 단순 복구로 일시적으로 전환하는 것도 고려할 수 있으므로
CHECKPOINT로그 백업을 수행하는 대신 로그를 지우면되지만 로그 체인을 다시 시작하려면 다시 설정하고 새 전체 백업을 수행해야합니다. .
답변
힌트가 있지만 어떤 버전을 사용하고 있습니까? 엔터프라이즈 에디션입니까? 어쨌든:
- 가능하면 트랜잭션 로그를 더 빠른 디스크로 이동하십시오.
- 어디를 분석하십시오 . 인덱스를 사용하여 삭제할 레코드를 식별합니까? 그렇지 않은 경우 색인을 추가 할 수 있습니까?
- 테이블에 삭제할 수있는 인덱스가 있습니까? 그렇다면 삭제하십시오.
- 이 테이블에 외래 키가 있습니까? 실제로 삭제 속도가 느려질 수 있습니다.
- 엔터프라이즈 버전이 있고 병목 현상이 디스크 IO 인 경우 행 수준의 압축은 약간의 도움을 줄 수 있습니다 (또는 데이터에 따라 다름)
- 테이블을 분할 할 수 있습니까? 로컬 인덱스 및 파티션 삭제가 더 빠를 수 있습니다.
- 활동 모니터를 통해 병목 현상이 발생하는 위치를 조사하십시오.
세부 정보를 추가하면 큰 데이터베이스로 작업 할 때 유효한 단일 답변이 없습니다.
답변
청크별로 청크를 삭제하십시오. 아마도 루프에서 삭제하고, 각 삭제 반복은 자체 트랜잭션입니다. 그런 다음 각 루프 반복이 끝나면 로그를 지우십시오.
또한 레코드를 삭제하기 위해 청크의 값으로 사용할 숫자를 찾아야합니다. 철저한 테스트가 필요합니다. 먼저 UAT에서 청크 값을 테스트 할 수 있으면 더 좋습니다.
진행 방법에 대해서는 큰 삭제 작업을 청크로 나누는 것을 참조하십시오.
답변
큰 테이블에 재귀 외래 키가 있으면 삭제 속도가 느려질 수 있습니다.
그렇다면 적절한 시간을 찾고 종속 서비스를 비활성화하고 재귀 외래 키를 비활성화하고 대량 삭제를 수행 한 다음 외래 키를 다시 복원하십시오.
답변
몇 가지 포인트를 더 추가하는 중 …
- 술어에 인덱스가 있는지 확인하고 통계도 참조하십시오.
- 많은 수의 행을 삭제하고 임시 테이블 옵션을 원하지 않는 경우.
tablock옵션 을 찾으십시오. - 삭제 트리거 후 트리거가 있는지 확인하십시오.
도움이 필요하면 사용중인 쿼리, 테이블 정보 및 차단 정보를 게시하십시오.