Việc chạy một truy vấn lớn trên cơ sở dữ liệu thứ cấp trong một nhóm khả dụng có ảnh hưởng đến hiệu suất giao dịch trong cơ sở dữ liệu chính không?

Tôi cần cung cấp dữ liệu thời gian thực hoặc gần như thời gian thực cho báo cáo SSRS và Tableau. Tôi không muốn hệ thống OLTP sản xuất bị ảnh hưởng tiêu cực bởi các truy vấn chạy dài. Việc chạy một truy vấn lớn trên cơ sở dữ liệu thứ cấp trong một nhóm khả dụng có ảnh hưởng đến hiệu suất giao dịch trong cơ sở dữ liệu chính không?

Việc chạy một truy vấn lớn trên cơ sở dữ liệu thứ cấp trong một nhóm khả dụng có ảnh hưởng đến hiệu suất giao dịch trong cơ sở dữ liệu chính không?

Nó phụ thuộc vào chế độ đồng bộ hóa mà bạn đã sử dụng khi định cấu hình nhóm Sẵn có - Đồng bộ hóa hoặc Async!

Trên bản sao phụ , tất cả các giao dịch chỉ sử dụng cấp độ cách ly Snapshot và tất cả các gợi ý khóa cũng bị bỏ qua. Đó là lý do tại sao việc kiểm tra khối lượng công việc của bạn khi nắm lấy Luôn luôn là rất quan trọng.

From: Tối thiểu hóa việc chặn luồng REDO khi chạy khối lượng công việc báo cáo trên Bản sao phụ

Mặc dù ánh xạ khối lượng công việc báo cáo thành cách ly ảnh chụp nhanh giúp loại bỏ việc chặn giữa khối lượng công việc DML như được áp dụng bởi luồng REDO trên bản sao thứ cấp và khối lượng công việc đọc hoặc báo cáo, nó không loại bỏ khả năng chặn luồng REDO khi thực hiện thao tác DDL .

Nếu sử dụng

• Chế độ đồng bộ

  • Sự cố chặn trên bản sao phụ của bạn sẽ ảnh hưởng đến hiệu suất của các truy vấn của bạn trên Bản sao chính. Vì vậy, một khối lượng công việc đọc (chọn) chạy trên thứ cấp có thể chặn luồng làm lại từ việc áp dụng các thay đổi đến từ bản sao chính. Điều này có nghĩa là bản sao chính phải chờ thay đổi được áp dụng cho tất cả các bản sao SYNC thứ cấp trước khi nó cam kết cục bộ & có thể kết thúc trong thời gian chờ hoặc chặn hoặc khóa chết.

    Chủ đề REDO có thể được nhìn thấy trên Trung tâm có thể đọc được dưới dạng DB STARTUPlệnh trong sys.dm_exec_requests. Nếu luồng đó đang bị chặn, thì khối lượng công việc đọc của bạn trên phụ có thể gây ra tác động lên chính.

    Để biết thêm chi tiết, hãy kiểm tra - Kịch bản 1: Bị chặn REDO do truy vấn lớn trên bản sao phụ

• Chế độ không đồng bộ

  • Chính không chờ đợi sự thừa nhận từ thứ cấp. Một vấn đề chặn trên thứ cấp chỉ bị cô lập với thứ cấp trong đó hàng đợi làm lại sẽ phát triển trên thứ cấp cho đến khi các khóa được xóa và luồng làm lại có thể áp dụng các khối nhật ký. Điều này sẽ không ảnh hưởng đến bản sao chính.

Định nghĩa của bạn về "thời gian thực hoặc gần như thời gian thực" cần suy nghĩ nhiều hơn về phương pháp đồng bộ được sử dụng, độ trễ mạng và mức độ bận rộn là bản sao chính và hoạt động nhật ký cần được vận chuyển thứ cấp.

SQL Server 2016 đã thực hiện một số cải tiến chính trong lĩnh vực Luôn luôn, ví dụ:

• Cải thiện thuật toán nén & Nén song song dữ liệu khối nhật ký
• Cải thiện 4x đến 5x trong thông lượng vận chuyển khối log
• và nhiều người khác - Nó chỉ chạy nhanh hơn !