Chuyển sang RCSI

Công ty tôi làm việc hiện đang sử dụng cơ sở dữ liệu SQL Server (phiên bản Enterprise mới nhất thường dùng) cho một sản phẩm chúng tôi phát triển.

Tôi sẽ mô tả nó như là một cơ sở dữ liệu OLTP có khả năng viết và đọc chuyên sâu với nhiều ứng dụng quan trọng. Ngoài ra, rất nhiều dữ liệu đồ họa và báo cáo được hiển thị từ thông tin trong cùng cơ sở dữ liệu OLTP này (vấn đề riêng biệt) đối với rất nhiều bảng giống nhau được đọc và ghi với tốc độ thường xuyên.

Chúng tôi thường gặp phải sự cố khi việc chặn xảy ra và nó thường làm chậm thời gian các ứng dụng quan trọng hoặc thậm chí gây ra sự cố do sự bế tắc trong các ứng dụng này. Giải pháp chung cho vấn đề này dường như thường là đưa ra nolockgợi ý cho các truy vấn có vấn đề. Tôi thực sự ghét giải pháp này và từ lâu tôi đã cảm thấy rằng đây là cách sai để thử và giải quyết vấn đề này và từ mọi thứ tôi đã đọc, tôi đi đến cùng một kết luận.

Tôi đã cố gắng thuyết phục nhóm của mình trong một thời gian rằng RCSI là thứ mà chúng tôi chắc chắn có thể hưởng lợi từ loại cơ sở dữ liệu đặc biệt của chúng tôi. Họ dường như nghĩ rằng đây là một rủi ro lớn và thường loại bỏ nó vì yếu tố rủi ro nhưng chúng tôi tiếp tục gặp vấn đề về hiệu suất khi chúng tôi chỉ đưa ra nolockgợi ý về nó.

• Làm cách nào tôi có thể giúp chứng minh rằng cơ sở dữ liệu của chúng tôi có thể hưởng lợi rất nhiều từ việc sử dụng RCSI?
• Có các thử nghiệm hiệu suất nào tôi có thể chạy dựa trên cơ sở dữ liệu sản xuất thực tế mà chúng tôi chuyển đổi sang RCSI trong môi trường thử nghiệm không?

Tôi đang tìm kiếm một cách tốt để hiển thị các số liệu cụ thể cho nhóm của chúng tôi để cuối cùng thuyết phục họ, chúng tôi có khả năng nên chuyển sang phương pháp này.

Như tôi chắc chắn rằng bạn đã biết, chỉ vì có rất nhiều người sử dụng NOLOCKkhông không làm cho nó một ý tưởng tốt - sau khi tất cả, nếu bạn quay trở lại đủ xa, rất nhiều người nghĩ rằng chế độ nô lệ, thuốc trừ sâu, amiăng, sơn chì và xăng, vv tất cả đều là những ý tưởng tuyệt vời

NOLOCKcó lợi ích về hiệu suất nhưng không phải vì nó không có khóa - đơn giản là vì nó cho phép người đọc bỏ qua các khóa được thực hiện bởi các độc giả hoặc nhà văn khác. Một truy vấn với NOLOCKvẫn có thể bị chặn tùy thuộc vào người đang làm gì với các bảng bên dưới - ít nhất, các Sch-Skhóa vẫn cần thiết.

Nhưng nhược điểm là rất nhiều và thường bị bỏ qua cho đến khi chúng xảy ra - mọi người rất vui khi các truy vấn của họ "nhanh" - ngay cả khi họ tạo ra dữ liệu không chính xác hoặc không nhất quán, đặc biệt là nếu họ không chú ý. Với NOLOCK/ READ UNCOMMITTED, bạn có thể:

• đọc cùng một hàng hai lần (hàng bạn đã đọc di chuyển trước khi quét thứ tự phân bổ)
• bỏ qua một hàng hoàn toàn (hàng bạn chưa đọc di chuyển phía sau quét)
• đọc một hàng không cam kết có thể không bao giờ tồn tại
• bị lỗi do di chuyển quá nhiều trong quá trình quét
• đọc các cột khác nhau trong một hàng ở trạng thái khác nhau
  • thậm chí một cái gì đó như là một giá trị đơn lẻ ở trạng thái nửa cam kết ( ví dụ tuyệt vời từ Paul White .)

Phải làm gì

Bạn có thể tránh những rủi ro này. Mức cô lập mặc định ( READ COMMITTED) chắc chắn không phải là không có rủi ro về tính nhất quán dữ liệu, chỉ có điều đó NOLOCKbổ sung rất nhiều trong số chúng.

Tôi thấy "ảnh chụp nhanh" bị ném khoảng một chút - trong khi chúng có vẻ giống nhau, đọc cách ly ảnh chụp nhanh được cam kết khác hoàn toàn với cách ly ảnh chụp nhanh . Kendra Little có một bài viết kỹ lưỡng ở đây rất đáng để đọc.

Có người nói "không ai từng bị sa thải vì sử dụng Snapshot Isolation". Tôi thực sự có thể tưởng tượng các kịch bản trong đó điều đó là hoàn toàn có thể. Snapshot Isolation có các ngữ nghĩa khác nhau đáng kể và yêu cầu thay đổi mã phải được thực hiện đúng. Thay đổi nhiều hơn = rủi ro nhiều hơn.

Đọc cách ly Snapshot Snap cam kết có thể được thực hiện với ít hoặc không thay đổi mã và thường là cách mà mọi người muốn nói khi họ đề nghị bạn chuyển từ NOLOCK/ READ UNCOMMITTED. Tuy nhiên, cũng có thể đưa ra các thay đổi hành vi do chỉ cần bật RCSI ở cấp cơ sở dữ liệu (xem mục 3 trong bài đăng của Kendra để biết ví dụ ).

Trong khi cá nhân tôi nghĩ rằng RCSI tốt hơn nhiều NOLOCK, bạn cần lưu ý rằng hiệu suất không được đảm bảo sẽ tốt hơn. RCSI hoạt động bằng cách tạo các phiên bản của các hàng trong tempdb, do đó, bất kỳ phiên đã cho nào cũng có bản sao của hàng nếu nó cần. Nếu tempdb là một nút cổ chai trên hệ thống của bạn, điều này có thể không hoạt động tốt như vậy. Ngoài ra, cho phép đọc ảnh chụp nhanh đã cam kết ở cấp cơ sở dữ liệu có nghĩa là tất cả các thay đổi dữ liệu trong tương lai sẽ thêm 14 byte mỗi hàng.

Điều này có nghĩa là, để cho thấy rằng công tắc này có giá trị, bạn nên trang bị đầy đủ tempdb để hỗ trợ tải bổ sung nếu nó hiện không tối ưu và bạn cần chuẩn bị cho các bảng hiện có của mình để cần thêm dung lượng trên đĩa và, cuối cùng, trong ký ức. Nếu tempdb đã bão hòa hoặc bạn đã gần hết dung lượng đĩa hoặc bộ nhớ đã hết, RCSI có thể không giúp ích được gì.

(Tất nhiên, có nhiều cách khác để cải thiện hiệu suất nói chung, tất nhiên, nếu NOLOCKkhông đáng để mạo hiểm và bạn không có chi phí cho RCSI. Ví dụ, nén có thể là một lựa chọn tốt để giảm I / O khi bạn có rất nhiều chi phí CPU. Các chỉ mục của cột có thể hữu ích cho các khối lượng công việc cụ thể. Và rõ ràng chỉ mục chi tiết và điều chỉnh truy vấn có thể có lợi.)

Đối với câu hỏi trong tầm tay:

Tôi sẽ đề nghị bạn tập trung vào việc đảm bảo rằng các truy vấn của bạn trả về kết quả chính xác, mà không có hiệu suất đáng chú ý - so với mức cô lập mặc định. So sánh NOLOCKlà không thực sự công bằng, trừ khi bạn hoàn toàn thoải mái với tất cả các rủi ro được đề cập ở trên. Bài đăng của Kendra đi qua một số chi tiết về đo lường tác động, nhưng về cơ bản, bạn muốn thực hiện các phép đo trước và sau của cùng một khối lượng công việc với cùng áp lực bên ngoài và đồng thời:

• thời gian truy vấn cho các truy vấn có NOLOCKngày hôm nay ( sys.dm_exec_query_stats)
• số liệu hiệu suất tổng thể - chờ đợi, độ trễ I / O, sử dụng tempdb, sử dụng bộ nhớ, thậm chí tuổi thọ trang

Và bạn sẽ làm điều này bằng bất kỳ phương pháp nào bạn hiện đang sử dụng để đo lường hiệu suất - nếu bạn không có phương pháp luận, tôi có thể đề xuất rằng một công cụ giám sát có thể đáng giá, ngay cả khi chỉ là bản dùng thử. (Tuyên bố miễn trừ trách nhiệm: Tôi đã từng làm việc cho một người .)

Không có phép màu nào "hãy nói cho tôi biết nếu khối lượng công việc của tôi tốt hơn với RCSI so với không" - điều này sẽ phụ thuộc vào khía cạnh hiệu suất nào là quan trọng đối với bạn, gần như bị tắc nghẽn và sẽ chứng minh - trong trường hợp cụ thể của bạn - một khoản lãi hoặc lỗ tổng thể (một lần nữa, giả sử mọi thứ khác vẫn giữ nguyên).

Và nó có thể là trường hợp mà bạn có thể thuyết phục họ bằng các lý lẽ định tính thay vì (hoặc ngoài) chỉ là "số liệu".

Đọc thêm (một số liên kết lặp lại từ trên):

• NOLOCK có bao giờ là lựa chọn đúng đắn? (xem các bình luận, quá)
• Triển khai cách ly Snapshot hoặc đọc cam kết trong máy chủ SQL: Hướng dẫn
• Một chỉ số cho loạt xuất sắc của Paul White về mức độ cô lập
• Thói quen xấu: Đưa NOLOCKmọi nơi

Ở công việc hiện tại của tôi, phần lớn các đối tượng cơ sở dữ liệu sử dụng (NO LOCK) hoặc đọc cách ly chưa hoàn thành. Tôi đồng ý rằng đó là một giải pháp tồi, nhưng nếu bạn quay lại đủ xa thì nó được sử dụng khá thường xuyên.

Tôi không quen thuộc với từ viết tắt RCSI, nhưng khi tìm hiểu nó, tôi thấy rằng nó được gọi là sử dụng Đọc cách ly Snapshot Snap. Có, nếu bạn gặp vấn đề với khóa và khóa chết, bạn nên sử dụng SNAPSHOT ISOLATION.

Tôi nghĩ cách tốt nhất để chứng minh điều này là tạo ra hai bản sao ảo hóa trong hệ thống sản xuất của bạn, sử dụng cách ly ảnh chụp nhanh trên một trong số chúng, mô phỏng mô hình sử dụng thông thường trên mỗi mẫu và xác minh rằng nó cải thiện hiệu suất.

Hoặc chỉ thực hiện trong các môi trường thấp hơn và sau đó khi bạn đã xác minh, nó sẽ ổn định di chuyển các thay đổi sang sản xuất. Không ai từng bị sa thải vì sử dụng Snapshot Isolation.