대량의 데이터 (84 백만 행)를 효율적으로 전송

약 84 백만 행이 있습니다. 이들 중 모두 동일한 서버의 별도 데이터베이스로 전송해야하며 소스 데이터베이스에서 약 6 천만 개의 행을 삭제하기 위해 삭제합니다.

8 천 8 백만 행이 모두 같은 테이블에 있습니다. 이 테이블만으로도 전체 데이터베이스의 90 %를 차지합니다.

그래서 ... 출처 : 84 백만 행-> 2 천 4 백만 행 목적지 : 0 행-> 8 천 8 백만 행

소스가 전체 복구 모드를 실행 중이고 대상이 단순하게 실행 중입니다.

이 작업을 수행하는 가장 효율적인 방법이 무엇인지 궁금합니다.

계획 A :

1) 대상 SELECT * FROM 소스에 삽입

2) TRUNCATE 소스

3) 소스 선택에 삽입 * keep_condition = 1 인 대상에서

계획 B :

1) 원본 데이터베이스의 백업을 대상 데이터베이스로 복원

2) 대상 데이터베이스에서 필요한 것을 제외한 모든 테이블을 삭제하십시오.

3) TRUNCATE 소스

4) 소스 선택에 삽입 * keep_condition = 1 인 대상에서

계획 C :

1) 대상 SELECT * FROM 소스에 삽입

2) keep_condition = 0 인 소스를 삭제하십시오.

또는 다른 것?

감사

나는 덧붙일 것이지만, 당신 이 이것에 접근하기로 결정 했다면 , 당신은 이러한 거래를 일괄 처리해야합니다 . 최근에 링크 된 기사를 사용하여 행운을 빕니다. 배치 된 대부분의 솔루션과 달리 인덱스를 활용하는 방법에 감사드립니다.

최소한의 로그조차도 큰 트랜잭션 이므로 비정상적인 로그 증가 (VLF, 잘림, 올바른 크기 등)의 결과를 처리하는 데 많은 시간을 할애 할 수 있습니다.

감사

"효율적"은 로그 파일 사용, I / O 성능, CPU 시간 또는 실행 시간에 적용될 수 있습니다.

로깅 측면에서 볼 때 매우 효율적인 최소 로깅 작업을 수행하려고합니다. 이를 통해 실행 시간을 보너스로 절약 할 수 있습니다. tempdb 공간이 있으면 다음이 적합 할 수 있습니다.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

최소한으로 기록 된 작업을 수행하려면 현재 실행중인 백업이없고 데이터베이스가 BULK_LOGGED복구 모드로 설정되어 있고 인덱스에 따라 대상 테이블이 비어 있어야하는 등 여러 가지 조건이 충족되어야합니다 . 이 동작 중 일부는 SQL Server 2005에서 2008로 변경 (개선)되었습니다.

그런 다음 테이블과 데이터의 특성을 모른 채 다른 옵션이 더 잘 수행 될 수 있습니다. 사용해보십시오

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. 어떤 것이 가장 효과가 좋은지 확인하십시오.

편집 : 대량 로그 작업을 수행 할 때 특정 시점 복원 기능이 필요하고 데이터베이스의 다른 활동이 진행중인 것으로 의심되는 경우 작업 전후에 백업 (전체 또는 트랜잭션 로그)을 만들어야합니다. ETL 작업이 실행되는 동시에.

얼마 전에 최소한으로 기록 된 작업에 대한 블로그 게시물 을 작성했으며 다른 게시물 및 설명서에 대한 링크가 있습니다.

왜 BCP가 아닌가?

1. sourcedb를 백업하십시오
2. sourcedb를 대량 로그로 변경

3. 명령 프롬프트 열기

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. 데이터를 확인

8. SSMS에서 sourcedb 테이블 자르기
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. sourcedb를 다시 전체로 변경

이전과 이후에 전체 데이터베이스 백업 또는 t-log 백업없이 복구 모델을 변경하지 않는 것이 좋습니다 . BULK_LOGGED 복구 모델의 기능 중 하나는 대량 로그 작업이 포함 된 t- 로그에 대한 특정 시점 복구 기능을 사용할 수 없다는 것입니다. 기본 시나리오 : 야간 전체 백업, 시간별 t- 로그 백업. 복구 모델을 대량 로그로 변경하고 작업을 시작합니다. 문제가 발생하여 트랜잭션이 롤백됩니다 (또는 사용하지 않은 경우). 그러나 데이터베이스에서 다른 작업이 무엇인지 확실하지 않으므로 알려진 적절한 지점으로 복원하려고합니다.

언제 다시 복원 할 수 있습니까? 대량 로그 작업이 포함 되지 않은 마지막 시간별 t- 로그 백업으로 인해 n 분의 트랜잭션이 손실 될 수 있습니다. 복구 모델을 변경하기 전에 전체 백업 또는 t-log 백업을 수행하면 대체 지점이 생성됩니다. 어느 것을 선택 하느냐는 RTO에 따라 다릅니다.

테이블에서 파티션을 삭제하는 것은 테이블에서 많은 양의 데이터를 제거하는 정말 빠르고 효율적인 리소스입니다. 이 테이블은 소스 / 대상 분할을 지원하는 방식으로 분할되었으므로 답은 사본을 복원하고 중복 테이블과 중복 분할 영역을 대상에서 삭제하고 보완 분할 영역을 소스에서 삭제하는 것입니다.

그러나 파티셔닝을 활성화하는 비용으로 인해 전체적으로 더 비싼 작업이 될 수 있습니다.