Tôi đã có một thiết lập AG 4 nút như sau:
Cấu hình phần cứng VM của tất cả các nút:
- Phiên bản doanh nghiệp Microsoft SQL Server 2017 (RTM-CU14) (KB4484710)
- 16 vCPU
- RAM 356 GB (câu chuyện dài đến thế này ...)
- mức độ song song tối đa: 1 (theo yêu cầu của nhà cung cấp ứng dụng)
- ngưỡng chi phí cho song song: 50
- bộ nhớ máy chủ tối đa (MB): 338944 (331 GB)
Cấu hình AG:
- Nút 1: Cam kết chính hoặc đồng bộ Thứ cấp không thể đọc được, được định cấu hình cho chuyển đổi dự phòng tự động
- Nút 2: Cam kết chính hoặc đồng bộ Thứ hai không thể đọc được, được định cấu hình cho chuyển đổi dự phòng tự động
- Nút 3: Bộ thứ cấp có thể đọc được với Cam kết không đồng bộ, được định cấu hình cho chuyển đổi dự phòng thủ công
- Nút 4: Bộ thứ cấp có thể đọc được với Cam kết không đồng bộ, được định cấu hình cho chuyển đổi dự phòng thủ công
Truy vấn trong câu hỏi:
Không có gì điên rồ về truy vấn này, nó cung cấp một bản tóm tắt các mục công việc nổi bật trong các hàng đợi khác nhau trong ứng dụng. Bạn có thể xem mã từ một trong các liên kết kế hoạch thực hiện bên dưới.
Hành vi thực thi trên nút chính:
Khi được thực thi trên nút Chính, thời gian thực hiện thường ở khoảng 1 giây. Dưới đây là kế hoạch thực hiện và bên dưới là các số liệu thống kê được thu thập từ THỐNG KÊ IO và THỐNG KÊ THỜI GIAN từ nút chính:
(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 500 ms, elapsed time = 656 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
Hành vi thực thi trên nút phụ chỉ đọc:
Khi thực hiện trên Nút phụ chỉ đọc (tức là Nút 3 hoặc Nút 4), truy vấn này sử dụng cùng một kế hoạch thực hiện (đây là một liên kết kế hoạch khác) và gần như thống kê thực hiện được hiển thị (ví dụ: có thể có thêm một vài trang quét vì những kết quả này luôn thay đổi), nhưng ngoại trừ thời gian của CPU, chúng trông rất giống nhau. Dưới đây là các số liệu thống kê được thu thập từ THỐNG KÊ IO và THỐNG KÊ THỜI GIAN từ nút phụ chỉ đọc:
(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row affected)
SQL Server Execution Times:
CPU time = 55719 ms, elapsed time = 56335 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
Những chi tiết khác:
Tôi cũng đã chạy cả hai sp_WhoIsActivevà kịch bản của Paul RandalWaitingTasks.sql trên phần thứ cấp trong khi truy vấn này đang được thực thi, nhưng tôi không thấy bất kỳ sự chờ đợi nào xảy ra, điều này thực sự gây thất vọng:
Đây cũng không phải là một trường hợp có độ trễ AG vì trạng thái Đồng bộ hóa thực sự khá tốt:
--https://sqlperformance.com/2015/08/monitoring/availability-group-replica-sync
SELECT
ar.replica_server_name,
adc.database_name,
ag.name AS ag_name,
drs.is_local,
drs.synchronization_state_desc,
drs.synchronization_health_desc,
--drs.last_hardened_lsn,
--drs.last_hardened_time,
drs.last_redone_time,
drs.redo_queue_size,
drs.redo_rate,
(drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
drs.last_commit_lsn,
drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc
ON drs.group_id = adc.group_id AND
drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar
ON drs.group_id = ar.group_id AND
drs.replica_id = ar.replica_id
ORDER BY
ag.name,
ar.replica_server_name,
adc.database_name;
Truy vấn này dường như là người phạm tội tồi tệ nhất. Các truy vấn khác cũng mất thời gian thứ hai giây trên Nút chính có thể mất 1 - 5 giây trên nút Phụ và trong khi hành vi không nghiêm trọng, thì nó có vẻ gây ra sự cố.
Cuối cùng, tôi cũng đã xem xét các máy chủ và kiểm tra các quy trình bên ngoài như Quét A / V, các công việc bên ngoài tạo ra I / O bất ngờ, v.v. và đã ra về tay không. Tôi không nghĩ rằng điều này được gây ra bởi bất cứ điều gì ngoài quy trình SQL Server.
Câu hỏi:
Chỉ là buổi trưa tôi ở đó và đã là một ngày dài, vì vậy tôi nghi ngờ tôi đang thiếu một cái gì đó rõ ràng ở đây. Hoặc là hoặc chúng tôi đã có một cái gì đó được định cấu hình sai, điều này là có thể vì chúng tôi đã có một số cuộc gọi đến Nhà cung cấp và MS liên quan đến môi trường này.
Đối với tất cả các cuộc điều tra của tôi, tôi dường như không thể tìm thấy điều gì gây ra sự khác biệt về hiệu suất này. Tôi hy vọng sẽ thấy một số loại chờ đợi xảy ra trên các nút thứ cấp, nhưng không có gì. Làm thế nào tôi có thể khắc phục sự cố này để xác định nguyên nhân gốc? Có ai nhìn thấy hành vi này trước đây và tìm cách giải quyết nó?
CẬP NHẬT # 1
Sau khi hoán đổi trạng thái của nút thứ ba (một trong những bản sao Chỉ đọc) thành không thể đọc được và sau đó trở lại để có thể đọc được dưới dạng thử nghiệm, bản sao đó vẫn đang được giữ bởi một giao dịch mở, với bất kỳ truy vấn khách nào hiển thị HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONINGchờ đợi.
Chạy một DBCC OPENTRANlệnh mang lại kết quả như sau:
Oldest active transaction:
SPID (server process ID): 420s
UID (user ID) : -1
Name : QDS nested transaction
LSN : (941189:33148:8)
Start time : May 7 2019 12:54:06:753PM
SID : 0x0
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Khi tra cứu SPID này sp_who2, nó hiển thị nó như là một BACKGROUNDquá trình QUERY STORE BACKđược liệt kê dưới dạng lệnh.
Mặc dù chúng tôi có thể thực hiện sao lưu TLog, tôi nghi ngờ chúng tôi đang chạy vào chức năng tương tự của lỗi đã được giải quyết này , vì vậy tôi có kế hoạch mở một vé với MS về vấn đề đặc biệt này ngày hôm nay.
Tùy thuộc vào kết quả của vé đó, tôi sẽ cố gắng ghi lại dấu vết ngăn xếp cuộc gọi theo đề xuất của Joe và xem chúng tôi sẽ đi đâu.
Cập nhật cuối cùng (Vấn đề tự giải quyết)
Sau khi làm lu mờ mốc 52 giờ của giao dịch Cửa hàng Truy vấn đang mở (như được xác định ở trên), AG đã quyết định tự động chuyển đổi dự phòng. Trước khi điều này xảy ra, tôi đã thực hiện một số số liệu bổ sung. Mỗi liên kết này , được cung cấp bởi Sean, cơ sở dữ liệu trong câu hỏi đã có một phiên bản lưu trữ rất lớn dành riêng cho cơ sở dữ liệu này, đặc biệt là tại một thời điểm tôi đã ghi 1651360 trang trong reserved_page_countlĩnh vực và 13210880 cho reserved_space_kbgiá trị.
Theo ERRORLOG, việc chuyển đổi dự phòng xảy ra sau 5 phút khắc phục các lỗi cứng giao dịch liên quan đến QDS base transactionvà QDS nested transactiongiao dịch.
Việc chuyển đổi dự phòng đã gây ra sự cố mất điện khoảng 10 phút trong trường hợp của tôi. Cơ sở dữ liệu có kích thước ~ 6TB và hoạt động rất tốt, vì vậy theo tôi thì thực sự khá tốt. Mặc dù nút chính mới trực tuyến trong thời gian này, không có truy vấn khách nào có thể hoàn thành vì tất cả chúng đều đang QDS_LOADDBchờ loại chờ.
Sau khi chuyển đổi dự phòng, số lượng cửa hàng phiên bản giảm xuống còn 176 cho reserved_page_countvà 1408 cho reserved_space_kb. Các truy vấn đối với các Bản sao chỉ đọc phụ cũng bắt đầu thực hiện nhanh như thể chúng được chạy từ bản chính, vì vậy có vẻ như hành vi biến mất hoàn toàn, do hậu quả của việc chuyển đổi dự phòng.
QDS_LOADDB- nếu bạn muốn tránh điều đó trong tương lai, nhưng vẫn tiếp tục Truy vấn Cửa hàng, bạn có thể sử dụng các cờ theo dõi được đề xuất bởi Microsoft. Cụ thể, 7752 sẽ cho phép các truy vấn thực thi trước khi Cửa hàng truy vấn đã khởi tạo (vì vậy bạn có thể bỏ lỡ một số truy vấn, nhưng cơ sở dữ liệu của bạn sẽ hoạt động).
7752trông đặc biệt hữu ích. Cảm ơn vì tiền hỗ trợ!