Tại sao nên sử dụng mức cách ly READ UNCOMMITTED?

Trong tiếng Anh đơn giản, những nhược điểm và lợi thế của việc sử dụng là gì

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

trong một truy vấn cho các ứng dụng .NET và các ứng dụng dịch vụ báo cáo?

Mức cô lập này cho phép đọc bẩn. Một giao dịch có thể thấy những thay đổi không được cam kết thực hiện bởi một số giao dịch khác.

Để duy trì mức độ cô lập cao nhất, DBMS thường thu được các khóa trên dữ liệu, điều này có thể dẫn đến mất đồng thời và chi phí khóa cao. Mức cô lập này thư giãn tài sản này.

Bạn có thể muốn xem bài viết trên Wikipedia vềREAD UNCOMMITTED một vài ví dụ và đọc thêm.

Bạn cũng có thể quan tâm đến việc kiểm tra bài viết trên blog của Jeff Atwood về cách anh ấy và nhóm của anh ấy giải quyết vấn đề bế tắc trong những ngày đầu của Stack Overflow. Theo Jeff:

Nhưng có nolocknguy hiểm không? Bạn có thể kết thúc việc đọc dữ liệu không hợp lệ với read uncommitted? Vâng, trên lý thuyết. Bạn sẽ thấy không thiếu các phi hành gia kiến ​​trúc cơ sở dữ liệu, những người bắt đầu bỏ khoa học ACID về bạn và tất cả trừ kéo chuông báo cháy tòa nhà khi bạn nói với họ rằng bạn muốn thử nolock. Đó là sự thật: lý thuyết thật đáng sợ. Nhưng đây là những gì tôi nghĩ: "Về lý thuyết không có sự khác biệt giữa lý thuyết và thực hành. Trong thực tế có."

Tôi sẽ không bao giờ khuyên bạn nên sử dụng nolock như một cách tổng quát "tốt cho những gì bạn cảm thấy khó chịu" đối với bất kỳ vấn đề bế tắc cơ sở dữ liệu nào bạn có thể gặp phải. Bạn nên cố gắng chẩn đoán nguồn gốc của vấn đề trước.

Nhưng trong thực tế, việc thêm nolockvào các truy vấn mà bạn hoàn toàn biết là những việc đơn giản, đơn giản chỉ đọc dường như không bao giờ dẫn đến vấn đề ... Miễn là bạn biết bạn đang làm gì.

Một thay thế cho READ UNCOMMITTEDcấp độ mà bạn có thể muốn xem xét là READ COMMITTED SNAPSHOT. Trích dẫn Jeff một lần nữa:

Ảnh chụp nhanh dựa trên một phương pháp theo dõi thay đổi dữ liệu hoàn toàn mới ... không chỉ là một thay đổi logic nhỏ, nó yêu cầu máy chủ xử lý dữ liệu theo cách khác. Khi phương thức theo dõi thay đổi dữ liệu mới này được bật, nó sẽ tạo một bản sao hoặc ảnh chụp nhanh của mọi thay đổi dữ liệu. Bằng cách đọc các ảnh chụp nhanh này thay vì dữ liệu trực tiếp tại các thời điểm tranh chấp, Khóa chung không còn cần thiết cho việc đọc và hiệu suất cơ sở dữ liệu tổng thể có thể tăng.

Điều này có thể hữu ích để xem tiến trình của các truy vấn chèn dài, thực hiện bất kỳ ước tính sơ bộ nào (như COUNT(*)hoặc thô SUM(*)), v.v.

Nói cách khác, kết quả mà các truy vấn đọc bẩn trả về là tốt miễn là bạn coi chúng là ước tính và không đưa ra bất kỳ quyết định quan trọng nào dựa trên chúng.

Trường hợp sử dụng yêu thích của tôi read uncommitedlà để gỡ lỗi một cái gì đó đang xảy ra trong một giao dịch.

Khởi động phần mềm của bạn dưới trình gỡ lỗi, trong khi bạn đang thực hiện các dòng mã, nó sẽ mở một giao dịch và sửa đổi cơ sở dữ liệu của bạn. Trong khi mã bị dừng, bạn có thể mở một bộ phân tích truy vấn, đặt ở mức cô lập không được đọc và thực hiện các truy vấn để xem những gì đang xảy ra.

Bạn cũng có thể sử dụng nó để xem các quy trình chạy dài có bị kẹt hoặc cập nhật chính xác cơ sở dữ liệu của bạn không.

Thật tuyệt nếu công ty của bạn thích làm các thủ tục lưu trữ quá phức tạp.

Ưu điểm là nó có thể nhanh hơn trong một số tình huống. Nhược điểm là kết quả có thể sai (dữ liệu chưa được cam kết có thể được trả lại) và không có gì đảm bảo rằng kết quả có thể lặp lại.

Nếu bạn quan tâm đến độ chính xác, đừng sử dụng cái này.

Thêm thông tin về MSDN :

Thực hiện đọc bẩn, hoặc khóa cách ly 0, có nghĩa là không có khóa chia sẻ nào được ban hành và không có khóa độc quyền nào được vinh danh. Khi tùy chọn này được đặt, có thể đọc dữ liệu không được cam kết hoặc bẩn; các giá trị trong dữ liệu có thể được thay đổi và các hàng có thể xuất hiện hoặc biến mất trong tập dữ liệu trước khi kết thúc giao dịch. Tùy chọn này có tác dụng tương tự như đặt NOLOCK trên tất cả các bảng trong tất cả các câu lệnh CHỌN trong một giao dịch. Đây là hạn chế ít nhất trong bốn cấp độ cách ly.

Khi nào thì dùng được READ UNCOMMITTED?

Nguyên tắc

Tốt : Báo cáo tổng hợp lớn hiển thị tổng số thay đổi liên tục.

Rủi ro : Gần như mọi thứ khác.

Tin tốt là phần lớn các báo cáo chỉ đọc thuộc danh mục Tốt đó.

Chi tiết hơn ...

Ok để sử dụng nó:

• Gần như tất cả các báo cáo tổng hợp hướng tới người dùng cho dữ liệu hiện tại, không tĩnh, ví dụ như doanh số hàng năm. Nó có nguy cơ sai số (có thể <0,1%) thấp hơn nhiều so với các yếu tố không chắc chắn khác như lỗi nhập liệu hoặc chỉ là sự ngẫu nhiên khi dữ liệu chính xác được ghi lại từng phút.

Điều đó có thể bao gồm phần lớn những gì một bộ phận Kinh doanh thông minh sẽ làm, nói, SSRS. Tất nhiên, ngoại lệ, là bất cứ thứ gì có dấu $ ở phía trước nó. Nhiều người chiếm tiền với sự nhiệt tình hơn nhiều so với việc áp dụng cho các số liệu cốt lõi liên quan cần có để phục vụ khách hàng và tạo ra số tiền đó. (Tôi đổ lỗi cho kế toán).

Khi rủi ro

• Bất kỳ báo cáo đi xuống mức chi tiết. Nếu chi tiết đó là bắt buộc, nó thường ngụ ý rằng mỗi hàng sẽ có liên quan đến một quyết định. Trong thực tế, nếu bạn không thể kéo một tập hợp con nhỏ mà không chặn thì đó có thể là lý do chính đáng để nó hiện đang được chỉnh sửa.

• Dữ liệu lịch sử. Nó hiếm khi tạo ra sự khác biệt thực tế nhưng trong khi người dùng hiểu dữ liệu thay đổi liên tục không thể hoàn hảo, họ không cảm thấy giống nhau về dữ liệu tĩnh. Đọc bẩn sẽ không bị tổn thương ở đây nhưng đôi khi đọc có thể được. Xem như bạn không nên có khối trên dữ liệu tĩnh nào, tại sao lại mạo hiểm?

• Gần như bất cứ thứ gì cung cấp cho ứng dụng cũng có khả năng ghi.

Khi thậm chí kịch bản OK không ổn.

• Có bất kỳ ứng dụng hoặc quá trình cập nhật nào sử dụng các giao dịch lớn không? Những người gỡ bỏ sau đó chèn lại rất nhiều hồ sơ bạn đang báo cáo? Trong trường hợp đó, bạn thực sự không thể sử dụng NOLOCKtrên các bảng đó cho bất cứ điều gì.

Về báo cáo, chúng tôi sử dụng nó trên tất cả các truy vấn báo cáo của mình để ngăn truy vấn làm chậm cơ sở dữ liệu. Chúng tôi có thể làm điều đó bởi vì chúng tôi đang kéo dữ liệu lịch sử, chứ không phải dữ liệu tối đa.

Sử dụng READ_UNCOMMITTED trong trường hợp nguồn rất khó thay đổi.

• Khi đọc dữ liệu lịch sử. ví dụ: một số nhật ký triển khai đã xảy ra hai ngày trước.
• Khi đọc siêu dữ liệu một lần nữa. ví dụ ứng dụng dựa trên siêu dữ liệu.

Không sử dụng READ_UNCOMMITTED khi bạn biết souce có thể thay đổi trong quá trình tìm nạp.

Điều này sẽ cung cấp cho bạn đọc bẩn và hiển thị cho bạn các giao dịch chưa được cam kết. Đó là câu trả lời rõ ràng nhất. Tôi không nghĩ rằng đó là một ý tưởng tốt để sử dụng điều này chỉ để tăng tốc độ đọc của bạn. Có nhiều cách khác để làm điều đó nếu bạn sử dụng một thiết kế cơ sở dữ liệu tốt.

Nó cũng thú vị để lưu ý những gì không xảy ra. ĐỌC UNCOMMITTED không chỉ bỏ qua các khóa bảng khác. Nó cũng không gây ra bất kỳ ổ khóa nào.

Hãy xem xét bạn đang tạo một báo cáo lớn hoặc bạn đang di chuyển dữ liệu ra khỏi cơ sở dữ liệu của mình bằng cách sử dụng câu lệnh CHỌN lớn và có thể phức tạp. Điều này sẽ khiến khóa được chia sẻ có thể được chuyển thành khóa bảng chung trong suốt thời gian giao dịch của bạn. Các giao dịch khác có thể đọc từ bảng, nhưng cập nhật là không thể. Đây có thể là một ý tưởng tồi nếu cơ sở dữ liệu sản xuất của nó kể từ khi sản xuất có thể dừng hoàn toàn.

Nếu bạn đang sử dụng READ UNCOMMITTED, bạn sẽ không đặt khóa chia sẻ trên bàn. Bạn có thể nhận được kết quả từ một số giao dịch mới hoặc bạn có thể không phụ thuộc vào nơi mà dữ liệu được chèn vào và thời gian giao dịch CHỌN của bạn đã đọc. Bạn cũng có thể nhận được cùng một dữ liệu hai lần nếu ví dụ phân tách trang xảy ra (dữ liệu sẽ được sao chép sang một vị trí khác trong tệp dữ liệu).

Vì vậy, nếu dữ liệu rất quan trọng đối với bạn rằng dữ liệu có thể được chèn trong khi thực hiện CHỌN, thì ĐỌC KHÔNG HOÀN THÀNH có thể có ý nghĩa. Bạn phải xem xét rằng báo cáo của bạn có thể có một số lỗi, nhưng nếu nó dựa trên hàng triệu hàng và chỉ một vài trong số chúng được cập nhật trong khi chọn kết quả thì điều này có thể "đủ tốt". Giao dịch của bạn cũng có thể thất bại tất cả cùng nhau vì tính duy nhất của một hàng có thể không được đảm bảo.

Một cách tốt hơn hoàn toàn có thể là sử dụng SNAPSHOT ISOLATION LEVEL nhưng các ứng dụng của bạn có thể cần một số điều chỉnh để sử dụng điều này. Một ví dụ về điều này là nếu ứng dụng của bạn có một khóa độc quyền trên một hàng để ngăn người khác đọc nó và chuyển sang chế độ chỉnh sửa trong UI. SNAPSHOT ISOLATION LEVEL cũng đi kèm với một hình phạt hiệu suất đáng kể (đặc biệt là trên đĩa). Nhưng bạn có thể khắc phục điều đó bằng cách ném phần cứng vào vấn đề. :)

Bạn cũng có thể xem xét khôi phục bản sao lưu cơ sở dữ liệu để sử dụng để báo cáo hoặc tải dữ liệu vào kho dữ liệu.

Nó có thể được sử dụng cho một bảng đơn giản, ví dụ như trong bảng kiểm toán chỉ chèn, trong đó không có cập nhật cho hàng hiện có và không có fk cho bảng khác. Chèn là một chèn đơn giản, không có hoặc có ít cơ hội quay trở lại.

Tôi luôn luôn sử dụng READ UNCOMMITTED ngay bây giờ. Nó nhanh với các vấn đề ít nhất. Khi sử dụng các cách ly khác, bạn sẽ hầu như luôn gặp phải một số vấn đề Chặn.

Miễn là bạn sử dụng các trường Tăng tự động và chú ý hơn một chút đến các phần chèn thì tiền phạt của bạn và bạn có thể nói lời tạm biệt với các vấn đề chặn.

Bạn có thể mắc lỗi với READ UNCOMMITED nhưng thành thật mà nói, rất dễ dàng để đảm bảo các phần chèn của bạn là bằng chứng đầy đủ. Chèn / Cập nhật sử dụng kết quả từ một lựa chọn là điều duy nhất bạn cần để ý. (Sử dụng READ CAM KẾT tại đây hoặc đảm bảo rằng việc đọc bẩn sẽ không gây ra sự cố)

Vì vậy, hãy đọc Dirty Reads (Đặc biệt cho các báo cáo lớn), phần mềm của bạn sẽ chạy mượt hơn ...