Truyền số lượng lớn (84 triệu hàng) dữ liệu một cách hiệu quả

Tôi có khoảng 84 triệu hàng. Trong số chúng cần được chuyển đến một cơ sở dữ liệu riêng biệt trên cùng một máy chủ, sau đó tôi xóa để xóa khoảng 60 triệu hàng khỏi cơ sở dữ liệu nguồn.

84 triệu hàng đều nằm trong cùng một bảng. Chỉ riêng bảng đó đã chiếm 90% toàn bộ cơ sở dữ liệu.

Vậy ... Nguồn: 84 triệu hàng -> 24 triệu hàng Đích: 0 hàng -> 84 triệu hàng

Nguồn đang chạy chế độ phục hồi đầy đủ, đích sẽ chạy đơn giản.

Tôi đang tự hỏi điều gì sẽ là cách hiệu quả nhất để làm điều này?

Kế hoạch A:

1) CHỌN VÀO đích CHỌN * TỪ nguồn

2) Nguồn TRUNCATE

3) CHỌN VÀO nguồn CHỌN * TỪ điểm đến WHERE keep_condition = 1

Kế hoạch B:

1) Khôi phục bản sao lưu cơ sở dữ liệu nguồn làm cơ sở dữ liệu đích

2) Bỏ mọi bảng trừ bảng cần thiết trên cơ sở dữ liệu đích

3) Nguồn TRUNCATE

4) CHỌN VÀO nguồn CHỌN * TỪ đích đến WHERE keep_condition = 1

Kế hoạch C:

1) CHỌN VÀO đích CHỌN * TỪ nguồn

2) XÓA nguồn WHERE keep_condition = 0

hay cái gì khác?

Cảm ơn

Tôi sẽ nói thêm rằng, tuy nhiên, bạn quyết định tiếp cận điều này, bạn sẽ cần phải xử lý các giao dịch này . Gần đây tôi đã rất may mắn với bài viết được liên kết và tôi đánh giá cao cách nó tận dụng các chỉ mục trái ngược với hầu hết các giải pháp theo đợt mà tôi thấy.

Ngay cả khi đăng nhập tối thiểu, đó là những giao dịch lớn và bạn có thể dành nhiều thời gian để xử lý sự phân nhánh của tăng trưởng nhật ký bất thường (VLF, cắt ngắn, kích thước phải, v.v.).

Cảm ơn

"Hiệu quả" có thể áp dụng cho việc sử dụng tệp nhật ký, hiệu năng I / O, thời gian CPU hoặc thời gian thực hiện.

Tôi sẽ cố gắng để đạt được một hoạt động đăng nhập tối thiểu, sẽ khá hiệu quả từ góc độ đăng nhập. Điều này sẽ giúp bạn tiết kiệm một số thời gian thực hiện một phần thưởng. Nếu bạn có không gian tempdb, những điều sau đây có thể phù hợp với bạn.

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;

Để một hoạt động được ghi lại tối thiểu xảy ra, một số điều kiện phải đúng, bao gồm không có bản sao lưu hiện đang chạy, cơ sở dữ liệu được đặt ở BULK_LOGGEDchế độ khôi phục và tùy thuộc vào chỉ mục của bạn, bảng mục tiêu có thể phải trống. Một số hành vi này cũng đã thay đổi (được cải thiện) từ SQL Server 2005 sang 2008.

Sau đó, một lần nữa, mà không biết chi tiết cụ thể của bảng và dữ liệu của bạn, bất kỳ tùy chọn nào khác của bạn có thể hoạt động tốt hơn. Hãy thử sử dụng

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. và xem cái nào hoạt động tốt nhất.

EDIT : Khi thực hiện các hoạt động được ghi nhật ký hàng loạt, hãy đảm bảo bạn tạo bản sao lưu (nhật ký đầy đủ hoặc nhật ký giao dịch) trước và sau hoạt động nếu bạn cần khả năng khôi phục tại thời điểm và bạn nghi ngờ rằng hoạt động khác có thể đang diễn ra trong cơ sở dữ liệu tại cùng thời gian mà công việc ETL của bạn đang chạy.

Tôi đã viết một bài đăng trên blog về các hoạt động được ghi lại tối thiểu một thời gian trước đây, có các liên kết trong đó đến các bài viết và tài liệu khác.

Tại sao không BCP?

1. Sao lưu nguồn gốc
2. Thay đổi sourcedb thành đăng nhập hàng loạt

3. Mở dấu nhắc lệnh

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. kiểm tra dữ liệu

8. Từ SSMS Rút ngắn bảng nguồn
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Thay đổi nguồn gốc trở lại đầy đủ

Đừng nghĩ rằng bạn nên khuyến nghị thay đổi mô hình khôi phục mà không cần sao lưu cơ sở dữ liệu đầy đủ hoặc sao lưu t-log trước và sau . Một trong những tính năng của mô hình khôi phục BULK_LOGGED là bạn sẽ mất khả năng thực hiện khôi phục tại thời điểm cho các nhật ký t có chứa các hoạt động được ghi nhật ký hàng loạt. Kịch bản cổ điển: sao lưu toàn bộ hàng đêm, sao lưu t-log hàng giờ. Bạn thay đổi mô hình khôi phục thành đăng nhập hàng loạt và bắt đầu hoạt động. Đã xảy ra lỗi và giao dịch quay trở lại (hoặc bạn chưa sử dụng). Tuy nhiên, bạn không chắc chắn điều gì khác đang diễn ra trong cơ sở dữ liệu nên bạn muốn khôi phục lại điểm tốt đã biết.

Khi nào bạn có thể khôi phục trở lại? Sao lưu t-log hàng giờ không chứa các hoạt động được ghi nhật ký hàng loạt, có khả năng mất n phút giao dịch. Một bản sao lưu đầy đủ hoặc sao lưu t-log trước khi thay đổi mô hình khôi phục sẽ tạo ra một điểm dự phòng. Cái nào bạn chọn phụ thuộc vào RTO của bạn.

Bỏ các phân vùng ra khỏi một bảng là một cách thực sự nhanh chóng và tiết kiệm tài nguyên để loại bỏ các khối dữ liệu lớn khỏi một bảng. Bảng này được phân vùng theo cách hỗ trợ phân chia nguồn / đích của bạn, câu trả lời sẽ là khôi phục một bản sao, loại bỏ các bảng dự phòng và (các) phân vùng dự phòng khỏi đích và thả các phân vùng bổ sung từ nguồn.

Tuy nhiên, chi phí cho phép phân vùng có thể làm cho điều này trở thành một hoạt động đắt tiền hơn, tuy nhiên.