Sao chép một số hàng của luồng dữ liệu trong SSIS


7

Tôi có một luồng dữ liệu để di chuyển dữ liệu từ cơ sở dữ liệu cũ sang cơ sở dữ liệu mới. Thiết kế cũ có tất cả dữ liệu và thông tin lịch sử (thay đổi) được lưu trữ trong một bảng duy nhất có "phiên bản" (số nguyên tăng) so với hàng.

Thiết kế mới có hai bảng, một bảng cho trạng thái "hiện tại" của dữ liệu và bảng kiểm toán (hoặc lịch sử) ghi lại các thay đổi bằng cách sử dụng kích hoạt. Do đó, chỉ có một hàng tồn tại cho dữ liệu "hiện tại" và có nhiều hàng lịch sử.

Trong gói SSIS của tôi, tôi đang sử dụng các thành phần sau để sao chép dữ liệu hiện tại vào một bảng nhưng sau đó gửi tất cả dữ liệu vào bảng kiểm toán.

Luồng dữ liệu SSIS

Multicast được sử dụng để phân chia luồng dữ liệu và Phân chia có điều kiện xác định hàng "hiện tại" và gửi nó đến bảng Đơn hàng (bảng không thực sự được gọi là Thứ tự , trước khi bất kỳ ai nhận xét về việc sử dụng một từ dành riêng cho tên bảng).

Tôi đã tạo luồng này vì tôi không thể thấy cách sử dụng Phân chia có điều kiện để gửi tất cả dữ liệu đến đích Kiểm toán và chỉ hàng hiện tại cho hàng khác.

Tôi giả định rằng việc tạo tất cả dữ liệu trùng lặp và sau đó loại bỏ nó thành Trash Destination không hiệu quả lắm và vì tôi có khoảng 52 triệu hàng để di chuyển, tôi lo lắng việc chuyển đổi sẽ mất nhiều ngày.

Có cách nào tốt hơn (hiệu quả hơn) để đạt được sự phân chia dữ liệu không?

Lưu ý về dữ liệu: Tôi đã áp dụng a row_number()cho dữ liệu cho phép tôi xác định hàng "hiện tại" là số 1, tất cả các hàng bao gồm "hiện tại" cần phải đi đến đích của bảng Kiểm toán.

EDIT: Tôi đã tìm thấy một giải pháp thay thế cho Multicast và Chia tách có điều kiện được đề xuất bởi bài đăng trên blog này từ SSIS Junkie: Nhiều kết quả đầu ra từ một chuyển đổi tập lệnh đồng bộ

Nó sử dụng một Thành phần Script để gửi dữ liệu đến một hoặc nhiều đầu ra. Tôi đang thử phương pháp đó để xem liệu nó có nhanh hơn không nhưng sau khi thấy câu trả lời và đề xuất của Kenneth về việc xóa Điểm đến Thùng rác, tôi không chắc nó sẽ như thế nào.


Thành phần script thực sự sẽ cải thiện hiệu suất. nó làm giảm lượng dữ liệu giải phóng bộ nhớ.
Kenneth

Câu trả lời:


3

Tôi thấy không có vấn đề rõ ràng với luồng dữ liệu đó. Tôi luôn đề nghị thực hiện càng nhiều công việc càng tốt trong các truy vấn nguồn của bạn, vì vậy nếu bạn có thể tạo bộ dữ liệu ngay từ đầu cho phép bạn điền cả hai bảng thông qua một phân tách đơn giản, chắc chắn nó sẽ sử dụng ít bộ nhớ hơn. Nhưng những thứ như vậy không phải lúc nào cũng có thể tùy thuộc vào nguồn dữ liệu và định dạng dữ liệu.

Ngoài ra, đích rác là tốt cho phát triển / gỡ lỗi nhưng không tốt trong sản xuất. Loại bỏ nó. Hãy để 'Dữ liệu không mong muốn' được chia nhỏ. SSIS có thể tìm ra phần còn lại.

Miễn là bạn tránh chặn các thành phần (UNION, MERGE, v.v.) thì không có lý do gì quá trình này sẽ mất nhiều ngày. Tôi thường xuyên xử lý hàng triệu hàng trong SSIS mà không gặp vấn đề gì. SSIS chỉ chậm như người thiết kế quy trình.

Hiện tại nó có vấn đề về hiệu suất?


Cảm ơn, tôi đã không nhận ra rằng bạn chỉ có thể để đầu ra từ Chia tách có điều kiện bị ngắt kết nối. Khi tôi kiểm tra gói trên một tập hợp con của dữ liệu (khoảng 32m hàng) thì mất 20 giờ. Điều đó cảm thấy chậm đối với tôi nhưng nó đã đọc dữ liệu từ một cơ sở dữ liệu và ghi vào cơ sở dữ liệu khác trên cùng một máy chủ; vì vậy đó có thể là một vấn đề
Tony

Nghe cũng chậm. Nếu đây là hoạt động một lần và 20 giờ là chấp nhận được, tôi sẽ không lo lắng về nó quá nhiều. Nếu đây là một quá trình lặp lại, tôi sẽ bắt đầu tìm cách tối ưu hóa. Số lượng hàng không cho tôi biết nhiều. Nó sẽ liên quan nhiều hơn đến kích thước của dữ liệu trong bộ đệm, độ trễ mạng, v.v.
Kenneth

1
Tôi đồng ý, đó là thời gian chậm chạp :) Tôi đã nhờ các nhân viên mạng kiểm tra hộp gói đang chạy và họ phát hiện ra lỗi cấu hình mạng, vì vậy dữ liệu không thể vào và ra khỏi hộp đủ nhanh. Tôi cũng đã thay đổi nguồn OLE DB thành tệp RAW (dữ liệu được đổ vào hộp SISS) vì vậy tôi chỉ ghi vào DB. Hai thay đổi đó đã giảm thời gian tải xuống 45 phút!
Tony
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.