Tải dữ liệu hàng loạt và Nhật ký giao dịch


7

Tôi hiện đang làm việc trên một dự án nhập số lượng lớn dữ liệu từ các tệp phẳng (csv) khoảng 18 tệp khác nhau, mỗi tệp liên kết đến một bảng cụ thể thông qua một số quy trình được lưu trữ.

Tôi đã làm theo các bước như được tư vấn trong hướng dẫn Hiệu suất tải dữ liệu .

Cơ sở dữ liệu ở BulkLoggedchế độ khôi phục để giảm thiểu việc ghi nhật ký, khi thực hiện quy trình được lưu trữ bên dưới trên một tệp chứa 600000 hàng tôi gặp lỗi

Msg 9002, Cấp 17, Trạng thái 4, Quy trình SP_Import__DeclarationClparentHistory_FromCSV, Dòng 34
Nhật ký giao dịch cho cơ sở dữ liệu đã đầy. Để tìm hiểu lý do tại sao không gian trong nhật ký không thể được sử dụng lại, hãy xem cột log numuse_wait_desc trong sys.database

(đối với mục đích thử nghiệm, tôi thực hiện sao lưu toàn bộ trước khi bắt đầu nhập).

Nhìn vào log_reuse_wait_desctôi thấy như sau:

log_reuse_wait_desc KIỂM TRA . Tất cả các nhập khác được nhập thành công.

Bất kỳ đầu vào trong việc giải quyết này sẽ được hoan nghênh.

PROCEDURE [dbo].[SP_Import_DeclarationClearanceHistory_FromCSV]
    @FilePath [nvarchar](1000)
AS
BEGIN
    -- Creating a Temproary Table for importing the data from csv file.
    DBCC TRACEON(610)

    CREATE TABLE #DeclarationClearanceHistory
    (
          [ItemID] [int] IDENTITY(1, 1) NOT NULL ,
          [CMSDeclarationID] [bigint] NOT NULL ,
          [StatusCode] [nvarchar](10) NOT NULL ,
          [SubStatus] [nvarchar](10) NULL ,
          [DepartmentCode] [nvarchar](10) NULL ,
          [StartDate] [datetime] NULL ,
          [EndDate] [datetime] NULL ,
          PRIMARY KEY CLUSTERED ( [ItemID] ASC )
            WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
                   IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
                   ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY]
        )
    ON  [PRIMARY]

    -- Inserting all the from csv to temproary table using BULK INSERT
    EXEC ('BULK INSERT #DeclarationClearanceHistory
    FROM ''' + @FilePath + '''
    WITH ( FIELDTERMINATOR = ''<,>'', ROWTERMINATOR =''\n'', FIRSTROW = 2, KEEPIDENTITY, CODEPAGE = ''ACP'', ORDER = ''ITEMID ASC'' );') ;

    -- By using MERGE statement, inserting the record if not present and updating if exist.
    MERGE dbo.DeclarationClearanceHistory AS TargetTable                            -- Inserting or Updating the table.
        USING #DeclarationClearanceHistory AS SourceTable                           -- Records from the temproary table (records from csv file).
        ON ( TargetTable.ItemID = SourceTable.ItemID )      -- Defining condition to decide which records are alredy present
        WHEN NOT MATCHED BY TARGET 
            THEN INSERT (
                          ItemID ,
                          CMSDeclarationID ,
                          StatusCode ,
                          SubStatus ,
                          DepartmentCode ,
                          StartDate ,
                          EndDate
                        )
               VALUES   ( SourceTable.ItemID ,
                          SourceTable.CMSDeclarationID ,
                          SourceTable.StatusCode ,
                          SourceTable.SubStatus ,
                          SourceTable.DepartmentCode ,
                          SourceTable.StartDate ,
                          SourceTable.EndDate
                        )
        WHEN MATCHED -- If  matched then UPDATE
            THEN UPDATE
               SET      TargetTable.ItemID = SourceTable.ItemID ,
                        TargetTable.CMSDeclarationID = SourceTable.CMSDeclarationID ,
                        TargetTable.StatusCode = SourceTable.StatusCode ,
                        TargetTable.SubStatus = SourceTable.SubStatus ,
                        TargetTable.DepartmentCode = SourceTable.DepartmentCode ,
                        TargetTable.StartDate = SourceTable.StartDate ,
                        TargetTable.EndDate = SourceTable.EndDate ;
DBCC TRACEOFF(610)
END

Câu trả lời:


4

Nhận xét đầu tiên của tôi là bạn đang thực hiện ELT (Trích xuất, Tải, Chuyển đổi) chứ không phải là ETL (Trích xuất, Chuyển đổi, Tải). Mặc dù ELT tận dụng các lợi thế quan hệ dựa trên thiết lập và có thể rất nhanh, đôi khi chúng rất chuyên sâu (khó lưu trữ). Cụ thể, nhật ký t. Điều này là do việc chuyển đổi được thực hiện trên đĩa (thường là cập nhật hoặc chèn). Tôi thích ETL khi có thể, vì việc chuyển đổi được thực hiện trong bộ đệm và khi được thực hiện chính xác, yêu cầu ghi t-log tối thiểu. Bộ đệm là giá rẻ. Lưu trữ nhanh thì không. Đối với một số hoạt động hàng loạt, nhật ký t là một nút cổ chai không thêm giá trị.

Dưới đây là một vài điều bạn đang làm nhưng tôi không khuyến nghị.

  1. Tải số lượng lớn vào tempdb. Tôi khuyên bạn nên thực hiện tải số lượng lớn trên một bảng thực trong cơ sở dữ liệu đích. Sau đó, bạn có thể kích thước tệp của mình phù hợp và không lo ảnh hưởng đến tempdb.
  2. Gói thủ tục độc lập với nhau. Chia hai thủ tục này lên. Tải trọng lớn và hợp nhất là độc lập với nhau. Việc tách chúng thành các thủ tục riêng lẻ làm cho chúng có thể kiểm tra mô đun / đơn vị hơn.

Có vẻ như bạn có các quy tắc đăng nhập tối thiểu được bảo hiểm khá tốt. Bạn đang tải vào một B-Tree trống không có cụm không sử dụng, sử dụng tf 610, khóa đặt hàng được chỉ định, trong chế độ ghi nhật ký hàng loạt. Bên ngoài bảng tạm thời, mọi thứ có vẻ ổn ở đây. Miễn là tập tin thực sự được sắp xếp theo khóa, bạn nên làm tốt. Bạn đang bật nhật ký trên tempdb hoặc cơ sở dữ liệu người dùng?

Trên câu lệnh hợp nhất:

CẬP NHẬT sẽ luôn được đăng nhập đầy đủ. Bạn đang thay đổi một phần khá đáng kể trong bảng của bạn? Nếu vậy, bạn có thể xem xét thực hiện hợp nhất trong bộ nhớ (tác vụ luồng dữ liệu SSIS hoặc .Net) sau đó tải hàng loạt vào một bảng mới. Đây là công việc nhiều hơn, nhưng hầu hết các công việc được thực hiện trong bộ đệm và nhật ký t tối thiểu được sử dụng. Một bản chèn được ghi tối thiểu có thể nhanh hơn bản cập nhật được ghi đầy đủ nếu phần thay đổi là đáng kể.

Vì bạn đang sử dụng tf 610, nên phần chèn có thể ghi nhật ký tối thiểu khi sử dụng gợi ý khóa. Xem tại đây để biết thêm thông tin về việc hợp nhất với tablock: http://bloss.msdn.com/b/sqlserverst Storageengine / archive / 2010/06/03 / minimal-loggging-and-emge-state.aspx Lưu ý, bản cập nhật sẽ vẫn còn đăng nhập đầy đủ nếu bạn đi tuyến đường này.


Cảm ơn vi đa trả lơi. Liên kết được cung cấp chứng minh hữu ích, tôi sắp thử nó. Tuy nhiên, tôi đã tạo để thử nghiệm một bảng thực sự để xem liệu có thể tìm thấy bất kỳ lợi ích nào không. Với tuyên bố sau DBCC TRACEON (610) BULK INSERT Temp_DeclarationClparentHistory TỪ 'DeclarationClparentHistory.csv' VỚI (FIELDTERMINATOR = '<,>', ROWTERMINATOR = '\ n', FIRSTROW = 2 (ITEMID ASC)); DBCC TRACEOFF (610) Nhưng tôi vẫn gặp lỗi tương tự với lần này log numuse_wait_desc nói sao lưu log, trong khi tôi sao lưu toàn bộ wsa đã thực hiện trước đó
Raymond

Bạn đã chia các thủ tục lên? Cái nào đang bật nhật ký? Việc chèn số lượng lớn hoặc hợp nhất?
brian

Có, tôi đã phân chia các thủ tục. Chèn số lượng lớn là một trong đó xuất hiện nhật ký cơ sở dữ liệu người dùng.
Raymond

1
Tôi tin rằng tôi thấy vấn đề. Không chắc chắn làm thế nào tôi nhìn này. Việc chèn số lượng lớn không sử dụng tùy chọn tablock. msdn.microsoft.com/en-us/l Library / ms190422.aspx TABLOCK là viên đạn thứ hai của các điều kiện tiên quyết.
brian

1
Nhìn nó kìa. Nhưng tôi đã có thể nhập thành công bằng cách đưa Checkpoint rõ ràng vào quy trình lưu trữ trước khi hợp nhất như Thomas Stringer đã đề cập và chia tệp thành 2. Tôi hiện đang tích hợp Bảng Temp vật lý. Hy vọng nó sẽ tốt hơn.
Raymond

4

Khi bạn thấy CHECKPOINTlog_Vuse_wait_desc cho cơ sở dữ liệu đó, đó là do không có điểm kiểm tra nào xảy ra kể từ lần cuối cùng nhật ký bị cắt.

Bạn có thể giảm bớt vấn đề này bằng cách khởi động một CHECKPOINTlệnh thủ công .

Tài liệu tham khảo hỗ trợ :
Các yếu tố có thể trì hoãn các điểm kiểm tra cắt ngắn
và phần hoạt động của nhật ký


Cảm ơn vi đa trả lơi. Đọc trên liên kết thứ 2 được cung cấp đã đề cập rằng Điểm kiểm tra được tạo khi "Thao tác ghi nhật ký tối thiểu được thực hiện trong cơ sở dữ liệu; ví dụ: thao tác sao chép hàng loạt được thực hiện trên cơ sở dữ liệu đang sử dụng mô hình khôi phục Nhật ký hàng loạt." . Không phải điều gì đang xảy ra bằng cách sử dụng kết hợp: Trace 610, phục hồi đăng nhập hàng loạt và chèn hàng loạt?
Raymond
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.