SQL 2016 Xác nhận máy chủ SQL: Tệp: <pageref.cpp>, line = 951 Xác nhận thất bại

Tôi hiện đang nâng cấp kho dữ liệu của chúng tôi từ SQL 2012 lên SQL 2016. Tôi có song song cả hai DW cũ và mới của tôi chạy song song.

Quá trình ETL của tôi (Khung được phát triển trong SSIS bởi bên thứ 3) đã chạy thành công hơn 2 năm vào năm 2012 nhưng không thành công vào năm 2016. Cho đến nay, cơ sở dữ liệu và quy trình ETL giống hệt nhau.

Cả hai Máy chủ đều là máy ảo chạy trên VMWare. Máy chủ cũ là Win 2008 với RAM 24Gb. SQL 2012 Std. Tối đa mem đặt thành 16Gb. Máy chủ mới là Win 2012 với 64Gb RAM. Nhà phát triển SQL 2016 Tối đa mem đặt thành 50Gb. DW mới đang chạy v13.0.1601.5 RTM Developer Edition (64-bit).

Trong khi chạy ETL của tôi, các bước tải sử dụng Hợp nhất SQL vào bảng thứ nguyên hoặc bảng thực tế không thành công với lỗi sau.

Toàn văn:

MÔ TẢ: Xác nhận máy chủ SQL: Tệp :, line = 951 Xác nhận thất bại = 'IS_OFF (BUF_MINLOGGED, m_buf-> bstat) || pageModifyType! = PageModifyType_Contents || GetPagePtr () -> IsTextPage () '. Lỗi này có thể liên quan đến thời gian. Nếu lỗi vẫn còn sau khi chạy lại câu lệnh, hãy sử dụng DBCC CHECKDB để kiểm tra cơ sở dữ liệu về tính toàn vẹn cấu trúc hoặc khởi động lại máy chủ để đảm bảo cấu trúc dữ liệu trong bộ nhớ không bị hỏng.

Theo khuyến cáo, tôi đã chạy DBCC và không tìm thấy lỗi nào. Tôi cũng đã khởi động lại SQL. Sau đó tôi đã khởi động lại quy trình ETL và gặp lỗi tương tự.

Các tìm kiếm của tôi cho lỗi này cho thấy đã biết lỗi trong SQL 2008, 2012 & 2014 và đã được sửa trong các bản cập nhật hotfix & tích lũy tiếp theo. vì vậy tôi hơi ngạc nhiên khi thấy nó xuất hiện trở lại vào năm 2016.

Các liên kết tôi tìm thấy nói rằng nó ảnh hưởng đến SSIS khi cố gắng chèn nếu cơ sở dữ liệu nằm trong mô hình khôi phục Nhật ký đơn giản hoặc hàng loạt. (Tôi đang chạy trong mô hình khôi phục đơn giản)

Một cách giải quyết được đề xuất là thay đổi mô hình khôi phục Db thành FULL. Tôi đã thử cái này và nó hoạt động, nhưng nó không phải là một giải pháp cho Kho dữ liệu.

Có ai khác gặp phải điều này với năm 2016?

Bất cứ ai có thể đề nghị giải pháp thay thế?

Cập nhật:

26/7/2016: Tôi đã áp dụng Bản cập nhật quan trọng KB3164398 (v13.0.1708.0) và sự cố vẫn còn tồn tại.

27/7/2016: Tôi đã áp dụng Cập nhật tích lũy CU1 KB3164674 (v13.0.2149.0).

3/8/2016: Lỗi xảy ra qua đêm trên khối lập phương nhỏ nhất của chúng tôi. CU1 đã không khắc phục vấn đề. Hôm nay tôi đã báo cáo lỗi trên MS Connect Và tôi cũng đã đăng nhập một cuộc gọi hỗ trợ với Microsoft.

12/8/2016: Hỗ trợ MS ban đầu đã trả lời, nhưng câu trả lời là "Chúng tôi không có cách khắc phục cho điều đó". Anh chàng Hỗ trợ sẽ thảo luận với các đồng nghiệp và quay lại với tôi. 8 ngày sau tôi không nghe tin gì từ anh ấy.

Mặc dù tôi không có "sửa chữa", chúng tôi đã tìm thấy một cách giải quyết phù hợp với chúng tôi. Xem câu trả lời được đăng của tôi.

29/9/2016. Tôi đã áp dụng CU2 tuần trước. Vào thứ năm, chúng tôi đã vô tình chạy một phiên bản cũ của sự hợp nhất mà lại thất bại với cùng một lỗi. Vì vậy .. CU2 cũng không sửa nó.

23/1/2017 : Tôi đã áp dụng 2016 SP1 CU1 và tôi tin rằng điều này đã giải quyết được vấn đề. Cụ thể là KB3205964

Nhìn vào KB bạn có một vài lựa chọn / cách giải quyết:

1. Chuyển sang mô hình phục hồi FULL. Bạn nói rằng "đây không phải là một lựa chọn cho kho" nhưng thực sự chỉ là vấn đề thiết lập sao lưu nhật ký giao dịch một cách thường xuyên, ví dụ như 15 phút và sau đó xử lý chúng. SSIS / Gói bảo trì có nhiệm vụ chứng khoán để thực hiện việc này . Bạn sẽ mất các giao dịch được đăng nhập hàng loạt, nhưng tôi chưa bao giờ thấy những giao dịch này đã tạo ra sự khác biệt lớn trong thời gian chạy, chỉ là kích thước nhật ký. Bạn thậm chí có thể sao lưu nhật ký đến nul mà tôi sẽ không mô tả ở đây. Nếu bạn không chắc chắn phải làm gì, hãy hỏi bạn DBA địa phương. Không gian đĩa và lưu giữ bản sao lưu nhật ký giao dịch là những vấn đề dễ giải quyết hơn so với các lỗi nghiêm trọng. Khi vấn đề này cuối cùng được giải quyết, bạn có thể chuyển trở lại.
2. KB đề cập đến "nhiều câu lệnh BULK INSERT trong một giao dịch phân phối đơn". Không rõ câu hỏi của bạn về cách chèn hàng loạt của bạn được thiết lập. Bạn có đang sử dụng SSIS để chạy các tác vụ 'Thực thi SQL' sử dụngMERGEchỉ huy? 'Nhiều BULK INSERT' nghĩa là gì ở đây? Có cách nào để chuyển đổi cách tiếp cận của bạn sang BULK INSERT duy nhất, ví dụ một lần không? Trong SSIS, bạn có thể tạm thời đặt 'MaxConcienExecutables' thành 1, xem điều đó có giúp ích không. Buộc nó vào một biến cấu hình để bạn có thể thay đổi lại sau. Rõ ràng nó sẽ làm mọi thứ chậm lại nhưng bạn thích ETL của mình kết thúc hơn là thất bại nhanh chóng. Làm mọi thứ song song là một mô hình tốt và là một thế mạnh thực sự của SSIS, nhưng bạn chỉ có thể đi nhanh như thành phần chậm nhất của mình; giả sử bạn có 10 thứ nguyên mất một phút và một thực tế mất một giờ, ETL của bạn kết thúc sau một giờ chạy song song hoặc 1 giờ 10 phút chạy một cách an toàn.
3. MERGElà tốt nhưng có một vài vấn đề. Bạn có thể xem xét chuyển đổi trở lại INSERT/ UPDATE. Ngoài ra bạn nên được sử dụng HOLDLOCKvới MERGEtheo ở đây . Bạn có sử dụng gợi ý đó? Nó có làm cho bất kỳ sự khác biệt cho vấn đề này nếu bạn làm? Chúng tôi đã gặp sự cố trong bản dựng SQL 2014 đầu tiên khi sử dụng MERGEDML ( OUTPUTmệnh đề) có thể tổng hợp vào cột lưu trữ gây ra loại xác nhận này - Tôi đã khiến họ loại bỏ các chỉ mục của cột trong các kích thước mà họ đã thêm mà không cho tôi biết.
4. Những loại xử lý giao dịch bạn đang làm? Đôi khi với ETL, vị trí được lặp lại chỉ bằng cách chạy lại. Đôi khi bạn cần nó để thất bại và rollback. Làm thế nào bạn thực hiện điều này? Có thể được thay đổi để nó không phải là "giao dịch phân tán duy nhất"?

Chúc may mắn.

Tôi tin rằng điều này đã được giải quyết trong 2016 SP1 CU1.

Cụ thể bởi KB3205964

Điều này được khắc phục bằng cách áp dụng bản cập nhật tích lũy 1 (CU1) cho MSSQL2016, xem liên kết https://support.microsoft.com/en-us/kb/3164674

Tôi tin rằng chúng tôi đã tìm thấy một cách giải quyết khác. Tôi đang đăng câu trả lời của mình vì tôi nghĩ nó có thể hữu ích và nó đủ khác với đề xuất của wBob.

Chúng tôi đã thay đổi phần chèn của câu lệnh hợp nhất để nó chèn vào bảng tạm thời thay vì mục tiêu ban đầu.

Khi câu lệnh hợp nhất thực thi, chúng tôi sẽ chèn từ #table vào mục tiêu.

Điều đó không lý tưởng, nhưng ít nhất việc hợp nhất vẫn xử lý sự phức tạp của 'upert' bằng cách đánh dấu các hàng đã hết hạn / hết hạn.

Chúng tôi thấy rằng đây là một sự đánh đổi chấp nhận được so với việc viết lại hoàn toàn việc hợp nhất dưới dạng các bản cập nhật và chèn riêng biệt.

CREATE TABLE #Activity(
[ETL_ActivitySurrogateKey] [int] IDENTITY(1,1) NOT NULL,
[Field1] [varchar](255) NULL,
)

-- Insert statements for procedure here
INSERT INTO #Activity ( [Field1],2,3,etc )

SELECT [Field1],2,3,etc
FROM 
(
    MERGE [DDS_OZ_CC].[dimActivity] AS target 
    USING (
      SELECT [Field1],2,3,etc
      FROM [STAGE_OZ_CC].[Transform_Activity]
      ) as source
    ON
    (
      target.RowIsCurrent = source.RowIsCurrent
         AND target.[Field1] = source.[Field1]
    )
    WHEN MATCHED 
        AND (        
        EXISTS (SELECT target.Level5Id EXCEPT SELECT source.Level5Id)
    )
    THEN
      UPDATE SET 
        ETL_ValidToDateTime = source.ETL_ValidFromDateTime 
       ,ETL_RowIsCurrent = 0 
       ,ETL_LastTouchedBy = source.ETL_LastTouchedBy 
       ,ETL_RowChangeReason = 'SCD2 Retired' 

    WHEN NOT MATCHED THEN 
    INSERT 
    (    
     [Field1],2,3,etc
    )
    VALUES (      
      source.[Field1],2,3,etc
    )
       WHEN NOT MATCHED BY SOURCE AND target.ETL_RowIsCurrent = 1
       THEN UPDATE SET
       ETL_RowIsCurrent = 0 
       ,ETL_RowChangeReason = 'Fact Removed' 
       ,ETL_LastTouchedBy = 'Unknown'

  OUTPUT
    $action      
      ,source.[Field1],2,3,etc    

  ) AS MergeOutput
  (
    action  
    ,[Field1],2,3,etc   
  ) 

  WHERE ACTION = 'UPDATE' AND ETL_RowIsCurrent = 1

    INSERT INTO [DDS_OZ_CC].[dimActivity]
    ( [Field1],2,3,etc  )
    SELECT [Field1],2,3,etc
    FROM #Activity

    END