0 đến 60:Chuyển sang các điểm kiểm tra gián tiếp

Trong một mẹo gần đây, tôi đã mô tả một tình huống trong đó phiên bản SQL Server 2016 dường như đang gặp khó khăn với thời gian điểm kiểm tra. Nhật ký lỗi được điền với một số lượng đáng báo động các mục nhập FlushCache như sau:

FlushCache: cleaned up 394031 bufs with 282252 writes in 65544 ms (avoided 21 new dirty bufs) for db 19:0
      average writes per second: 4306.30 writes/sec
      average throughput:        46.96 MB/sec, I/O saturation: 53644, context switches 101117
      last target outstanding:   639360, avgWriteLatency 1

Tôi hơi bối rối vì vấn đề này, vì hệ thống chắc chắn không hoạt động tốt - nhiều lõi, bộ nhớ 3TB và bộ nhớ XtremIO. Và không có thông báo FlushCache nào được ghép nối với các cảnh báo I / O 15 giây kể từ trong nhật ký lỗi. Tuy nhiên, nếu bạn xếp một loạt cơ sở dữ liệu giao dịch cao trên đó, quá trình xử lý điểm kiểm tra có thể trở nên khá chậm chạp. Không phải quá nhiều vì I / O trực tiếp, mà là quá trình điều chỉnh nhiều hơn phải được thực hiện với một số lượng lớn các trang bẩn (không chỉ từ cam kết các giao dịch) nằm rải rác trên một lượng lớn bộ nhớ như vậy và có khả năng chờ đợi trên trình ghi chậm (vì chỉ có một giao dịch cho toàn bộ phiên bản).

Tôi đã đọc nhanh một số bài viết rất có giá trị:

• Cách các điểm kiểm tra hoạt động và những gì được ghi lại
• Điểm kiểm tra cơ sở dữ liệu (SQL Server)
• Checkpoint làm gì cho tempdb?
• Một huyền thoại SQL Server DBA mỗi ngày:(15/30) chỉ ghi các trang từ các giao dịch đã cam kết
• Thông báo FlushCache có thể không phải là một IO đình trệ thực tế
• Điểm kiểm tra gián tiếp và tempdb - tốt, xấu và không hiệu quả
• Thay đổi Thời gian Khôi phục Mục tiêu của Cơ sở dữ liệu
• Cách hoạt động:Khi nào thông báo FlushCache được thêm vào Nhật ký lỗi máy chủ SQL?
• Các thay đổi trong hành vi của điểm kiểm tra SQL Server 2016
• Khoảng thời gian khôi phục mục tiêu và điểm kiểm tra gián tiếp - Mặc định mới là 60 giây trong SQL Server 2016
• SQL 2016 - Nó chỉ chạy nhanh hơn:Mặc định điểm kiểm tra gián tiếp
• Máy chủ SQL:RAM lớn và Điểm kiểm tra DB

Tôi nhanh chóng quyết định rằng tôi muốn theo dõi thời lượng điểm kiểm tra cho một số cơ sở dữ liệu rắc rối hơn này, trước và sau khi thay đổi khoảng thời gian khôi phục mục tiêu của chúng từ 0 (cách cũ) thành 60 giây (cách mới). Trở lại vào tháng 1, tôi đã mượn phiên Sự kiện mở rộng từ một người bạn và đồng nghiệp người Canada Hannah Vernon:

CREATE EVENT SESSION CheckpointTracking ON SERVER 
ADD EVENT sqlserver.checkpoint_begin
(
  WHERE 
  (
       sqlserver.database_id = 19 -- db4
    OR sqlserver.database_id = 78 -- db2
    ...
  )
)
, ADD EVENT sqlserver.checkpoint_end
(
  WHERE 
  (
       sqlserver.database_id = 19 -- db4
    OR sqlserver.database_id = 78 -- db2
    ...
  )
)
ADD TARGET package0.event_file
(
  SET filename = N'L:\SQL\CP\CheckPointTracking.xel',
      max_file_size = 50, -- MB
      max_rollover_files = 50
)
WITH 
(
  MAX_MEMORY = 4096 KB,
  MAX_DISPATCH_LATENCY = 30 SECONDS, 
  TRACK_CAUSALITY = ON,
  STARTUP_STATE = ON
);
GO
 
ALTER EVENT SESSION CheckpointTracking ON SERVER 
  STATE = START;

Tôi đã đánh dấu thời gian mà tôi thay đổi từng cơ sở dữ liệu, sau đó phân tích kết quả từ dữ liệu Sự kiện mở rộng bằng cách sử dụng truy vấn được xuất bản trong mẹo ban đầu. Kết quả cho thấy sau khi thay đổi thành các điểm kiểm tra gián tiếp, mỗi cơ sở dữ liệu đi từ các điểm kiểm tra trung bình 30 giây đến các điểm kiểm tra trung bình chưa đến 1/10 giây (và ít hơn nhiều điểm kiểm tra trong hầu hết các trường hợp). Có rất nhiều thứ để giải nén từ hình ảnh này, nhưng đây là dữ liệu thô mà tôi đã sử dụng để trình bày lập luận của mình (nhấp để phóng to):

Bằng chứng của tôi

Khi tôi đã chứng minh được trường hợp của mình trên các cơ sở dữ liệu có vấn đề này, tôi đã được bật đèn xanh để triển khai điều này trên tất cả các cơ sở dữ liệu người dùng của chúng tôi trong môi trường của chúng tôi. Đầu tiên trong dev và sau đó là production, tôi chạy phần sau thông qua truy vấn CMS để đánh giá số lượng cơ sở dữ liệu mà chúng ta đang nói đến:

DECLARE @sql nvarchar(max) = N'';
 
SELECT @sql += CASE
  WHEN (ag.role = N'PRIMARY' AND ag.ag_status = N'READ_WRITE') OR ag.role IS NULL THEN N'
    ALTER DATABASE ' + QUOTENAME(d.name) + N' SET TARGET_RECOVERY_TIME = 60 SECONDS;' 
  ELSE N'
    PRINT N''-- fix ' + QUOTENAME(d.name) + N' on Primary.'';' 
  END
FROM sys.databases AS d 
OUTER APPLY
(
  SELECT role = s.role_desc, 
    ag_status = DATABASEPROPERTYEX(c.database_name, N'Updateability')
    FROM sys.dm_hadr_availability_replica_states AS s
    INNER JOIN sys.availability_databases_cluster AS c
       ON s.group_id = c.group_id 
       AND d.name = c.database_name
    WHERE s.is_local = 1
) AS ag
WHERE d.target_recovery_time_in_seconds <> 60
  AND d.database_id > 4 
  AND d.[state] = 0 
  AND d.is_in_standby = 0 
  AND d.is_read_only = 0;
 
SELECT DatabaseCount = @@ROWCOUNT, Version = @@VERSION, cmd = @sql;
 
--EXEC sys.sp_executesql @sql;

Một số lưu ý về truy vấn:

• database_id > 4
  Tôi không muốn chạm vào master và tôi không muốn thay đổi tempdb nhưng vì chúng tôi không sử dụng SQL Server 2017 CU mới nhất (xem KB # 4497928 vì một lý do rằng chi tiết này quan trọng). Quy tắc sau loại trừ model , vì việc thay đổi mô hình sẽ ảnh hưởng đến tempdb vào lần chuyển đổi dự phòng / khởi động lại tiếp theo. Tôi có thể đã thay đổi msdb và tôi có thể quay lại làm điều đó vào một lúc nào đó, nhưng trọng tâm của tôi ở đây là cơ sở dữ liệu người dùng.
  
• [state] / is_read_only / is_in_standby
  
• OUTER APPLY (...)
  Chúng tôi muốn hạn chế các hành động của mình đối với cơ sở dữ liệu là cơ sở chính trong AG hoặc hoàn toàn không phải trong AG (và cũng phải tính đến AG phân tán, nơi chúng tôi có thể là cơ sở chính và cục bộ nhưng vẫn không thể ghi được) . Nếu bạn tình cờ chạy kiểm tra phụ, bạn không thể khắc phục sự cố ở đó, nhưng bạn vẫn sẽ nhận được cảnh báo về nó. Cảm ơn Erik Darling đã giúp giải quyết vấn đề logic này và Taylor Martell đã tạo động lực cho những cải tiến.
  
• Nếu bạn có các phiên bản đang chạy các phiên bản cũ hơn như SQL Server 2008 R2 (tôi đã tìm thấy một phiên bản!), bạn sẽ phải tinh chỉnh điều này một chút, vì target_recovery_time_in_seconds cột không tồn tại ở đó. Tôi đã phải sử dụng SQL động để giải quyết vấn đề này trong một trường hợp, nhưng bạn cũng có thể tạm thời di chuyển hoặc loại bỏ những trường hợp đó nằm trong hệ thống phân cấp CMS của bạn. Bạn cũng không thể lười biếng như tôi và chạy mã trong Powershell thay vì cửa sổ truy vấn CMS, nơi bạn có thể dễ dàng lọc ra các cơ sở dữ liệu được cung cấp bất kỳ số thuộc tính nào trước khi gặp phải các vấn đề về thời gian biên dịch.

Trong quá trình sản xuất, có 102 phiên bản (khoảng một nửa) và tổng số 1.590 cơ sở dữ liệu sử dụng cài đặt cũ. Mọi thứ đều có trên SQL Server 2017, vậy tại sao cài đặt này lại phổ biến như vậy? Bởi vì chúng được tạo trước khi các điểm kiểm tra gián tiếp trở thành mặc định trong SQL Server 2016. Dưới đây là một mẫu kết quả:

Kết quả một phần từ truy vấn CMS.

Sau đó, tôi chạy lại truy vấn CMS, lần này với sys.sp_executesql không ghi nhớ. Mất khoảng 12 phút để chạy nó trên tất cả 1.590 cơ sở dữ liệu. Trong vòng một giờ, tôi đã nhận được báo cáo về việc mọi người quan sát thấy sự sụt giảm đáng kể của CPU trên một số trường hợp bận hơn.

Tôi vẫn còn nhiều việc phải làm. Ví dụ:tôi cần kiểm tra tác động tiềm ẩn đối với tempdb , và liệu có trọng lượng nào trong trường hợp sử dụng của chúng ta đối với những câu chuyện kinh dị mà tôi đã nghe hay không. Và chúng tôi cần đảm bảo rằng cài đặt 60 giây là một phần trong quá trình tự động hóa của chúng tôi và tất cả các yêu cầu tạo cơ sở dữ liệu, đặc biệt là những yêu cầu được viết theo tập lệnh hoặc được khôi phục từ các bản sao lưu.