NOLOCK luôn xấu?

Tôi là một Nhà phát triển Báo cáo muốn thực hiện các truy vấn của mình hiệu quả nhất có thể. Tôi đã từng làm việc với một DBA, người đã nói với tôi - tôi tin bởi vì tôi luôn xử lý các báo cáo trên Máy chủ sản xuất - để sử dụng NOLOCKtrong mọi truy vấn.

Bây giờ, tôi làm việc với một DBA đã bị cấm NOLOCKtrong mọi trường hợp - ngay cả khi một báo cáo của tôi (do thiếu chỉ số đáng kể trên một vài bảng) đang dừng sao chép và cập nhật hệ thống. Theo tôi, trong trường hợp này, một điều NOLOCKsẽ là một điều tốt.

Vì hầu hết các khóa đào tạo SQL của tôi đã xuất hiện nhiều DBA khác nhau với những ý kiến ​​rất khác nhau, tôi muốn hỏi điều này với nhiều DBA khác nhau.

Nếu báo cáo của bạn chặn cập nhật rằng DBA của bạn là đúng: bạn tuyệt đối không nên sử dụng NOLOCK. Thực tế rất rằng có là mâu thuẫn là một dấu hiệu rõ ràng rằng nếu bạn sẽ sử dụng bẩn lần đọc bạn sẽ nhận được báo cáo không chính xác.

Theo tôi, luôn có những lựa chọn thay thế tốt hơn NOLOCK:

• Các bảng sản xuất của bạn chỉ đọc có hiệu lực và không bao giờ được sửa đổi? Đánh dấu cơ sở dữ liệu chỉ đọc!
• Quét bảng gây ra xung đột khóa? Lập chỉ mục các bảng một cách thích hợp, lợi ích là nhiều.
• Không thể sửa đổi / không biết cách lập chỉ mục phù hợp? Sử dụng cách ly SNAPSHOT .
• Không thể thay đổi ứng dụng để sử dụng ảnh chụp nhanh? Bật đọc ảnh chụp nhanh cam kết !
• Bạn đã đo lường tác động của phiên bản hàng và có bằng chứng nó ảnh hưởng đến hiệu suất? Bạn không thể lập chỉ mục dữ liệu? và bạn ổn với báo cáo không chính xác ? Sau đó, ít nhất hãy làm cho mình một ưu tiên và sử dụng SET TRANSACTION ISOLATION LEVEL, không phải là một gợi ý truy vấn. Sau này sẽ dễ dàng hơn để sửa mức cô lập thay vì sửa đổi mọi truy vấn.

Nó không phải lúc nào cũng xấu.

Tất nhiên, nó cho phép bạn đọc các giá trị không được cam kết (có thể được khôi phục và do đó không bao giờ tồn tại một cách hợp lý) cũng như cho phép các hiện tượng như đọc các giá trị nhiều lần hoặc hoàn toàn không.

Các mức cô lập duy nhất đảm bảo rằng bạn sẽ không gặp phải bất kỳ sự bất thường nào như vậy là tuần tự hóa / ảnh chụp nhanh. Có thể bỏ qua các giá trị đọc lặp lại nếu một hàng được di chuyển (do cập nhật khóa) trước khi quét đến hàng này, các giá trị cam kết đã đọc có thể được đọc hai lần nếu cập nhật khóa khiến hàng đọc trước đó di chuyển về phía trước.

nolockTuy nhiên, những vấn đề này có nhiều khả năng phát sinh hơn bởi vì theo mặc định, ở mức cô lập này, nó sẽ sử dụng quét theo thứ tự phân bổ khi ước tính có hơn 64 trang được đọc . Cũng như danh mục các vấn đề phát sinh khi các hàng di chuyển giữa các trang do cập nhật khóa chỉ mục, các lần quét phân bổ này cũng dễ bị ảnh hưởng bởi các phân tách trang (trong đó các hàng có thể bị bỏ lỡ nếu trang mới được phân bổ sớm hơn trong tệp so với điểm đã quét hoặc đọc hai lần nếu một trang đã quét được chia thành một trang sau trong tệp).

Ít nhất là đối với các truy vấn đơn giản (bảng đơn), có thể không khuyến khích việc sử dụng các lần quét này và có được một lần quét theo thứ tự nolockbằng cách chỉ cần thêm một ORDER BY index_keytruy vấn để thuộc Orderedtính của IndexScanlà true.

Nhưng nếu ứng dụng báo cáo của bạn không cần số liệu hoàn toàn chính xác và có thể chấp nhận xác suất lớn hơn về sự không nhất quán đó thì có thể chấp nhận được.

Nhưng chắc chắn bạn không nên chọn nó trên tất cả các truy vấn với hy vọng đó là nút "turbo" kỳ diệu. Cũng như xác suất gặp phải kết quả dị thường cao hơn ở mức cô lập đó hoặc không có kết quả nào cả (lỗi "Không thể tiếp tục quét với NOLOCK do di chuyển dữ liệu") thậm chí có trường hợp hiệu suất nolock có thể tệ hơn nhiều .

Khách hàng của bạn có chịu đựng được kết quả không nhất quán trong các báo cáo không? Nếu câu trả lời là không, bạn không nên sử dụng NOLOCK - bạn có thể nhận kết quả sai theo đồng thời. Tôi đã viết một vài ví dụ ở đây , ở đây và ở đây . Các ví dụ này cho thấy đầu ra không nhất quán trong READ READ CAMEDED và REPEATABLE READ, nhưng bạn cũng có thể điều chỉnh chúng và nhận kết quả sai với NOLOCK.

Hầu hết các báo cáo tôi tạo không chạy trên dữ liệu hiện tại. Hầu hết các khách hàng đang chạy báo cáo là dữ liệu của ngày hôm qua. Câu trả lời của bạn sẽ thay đổi nếu đó là trường hợp?

Nếu đó là trường hợp, thì bạn có thêm một tùy chọn có thể:
Thay vì chạy các truy vấn của bạn trên cơ sở dữ liệu sản xuất và làm rối tung các khóa và NOLOCK, bạn có thể chạy các báo cáo của mình từ một bản sao của cơ sở dữ liệu sản xuất.

Bạn có thể thiết lập nó để nó tự động được khôi phục từ bản sao lưu mỗi đêm .
Rõ ràng các báo cáo của bạn đang chạy trên các máy chủ trên các trang web của khách hàng, vì vậy tôi không biết nếu thiết lập điều này sẽ là một giải pháp khả thi cho bạn.
(nhưng sau đó một lần nữa ... dù sao họ cũng nên có bản sao lưu, vì vậy tất cả những gì bạn cần là một số không gian máy chủ để khôi phục chúng)

Tôi là một nhà phát triển nội bộ, vì vậy điều này dễ dàng hơn đối với tôi vì tôi có toàn quyền kiểm soát các máy chủ và cơ sở dữ liệu.

Bạn có thể làm điều này ít nhất cho các báo cáo chỉ cần dữ liệu từ ngày hôm qua trở lên. Có thể một số báo cáo sẽ phải ở lại trên cơ sở dữ liệu sản xuất, nhưng ít nhất bạn chuyển một phần tải sang cơ sở dữ liệu khác (hoặc thậm chí tốt hơn, một máy chủ khác).

Tôi cũng gặp tình huống tương tự:
Chúng tôi đang sử dụng một bản sao cơ sở dữ liệu sản xuất như thế này cho gần như tất cả các công cụ báo cáo, nhưng có một vài truy vấn yêu cầu dữ liệu ngày nay.