Mức độ cách ly được đọc có bao giờ dẫn đến bế tắc (Sql Server) không?

Question

Sự hiểu biết của tôi về deadlocks là - hai quy trình cố gắng tranh giành cho cùng một tài nguyên - thường là hai quy trình cố gắng 'ghi' vào cùng một hàng dữ liệu. Nếu tất cả một tiến trình đang làm là đọc dữ liệu - và quá trình khác đang cập nhật dữ liệu, thì sự tranh chấp tài nguyên như thế nào? Tuy nhiên, trong cơ sở dữ liệu của chúng tôi, được đặt thành cấp độ giao dịch mặc định 'ReadCommitted', chúng tôi đang thấy một số ngoại lệ bế tắc. ReadComitted definitin - Dữ liệu đã được sửa đổi (nhưng chưa cam kết) không thể đọc được. Điều đó là tốt - nhưng SQL Server nên ném một ngoại lệ bế tắc nếu nó gặp phải 'đọc bẩn' này diễn ra? Bất kỳ ai có trải nghiệm thế giới thực với kịch bản này? Tôi tìm thấy một bài đăng trên blog (bởi nhà phát triển stackoverflow, không kém :) tuyên bố rằng điều này có thể đúng.

Cảm ơn

Answer 1

Có, điều đó có thể xảy ra. Hãy tưởng tượng bạn có hai quy trình với mỗi giao dịch riêng. Bản cập nhật đầu tiên TableA sau đó cố gắng cập nhật TableB. Bản cập nhật thứ hai TableB sau đó cố gắng cập nhật TableA. Nếu bạn không may mắn, cả hai quy trình quản lý để hoàn thành bước đầu tiên của họ và sau đó chờ đợi vô thời hạn cho người khác để hoàn thành bước thứ hai.

Ngẫu nhiên, đó là một trong những cách phổ biến nhất để tránh deadlocks: nhất quán theo thứ tự mà bạn cập nhật bảng của mình. Nếu cả hai quá trình cập nhật TableA trước thì TableB, bế tắc sẽ không xảy ra.

Answer 2

ReadComitted giao dịch Isolation Cấp ban đầu có được một Shared Lock trên tức là tài nguyên trong khi đọc hàng nhưng khi chúng tôi cố gắng cập nhật hàng công ty không giành một Exclusive lock trên các nguồn lực. Nhiều người dùng có thể có khóa chia sẻ trên cùng một hàng và nó sẽ không có hiệu lực nhưng ngay sau khi một người dùng cố gắng cập nhật hàng Nó sẽ có một Khóa độc quyền trên hàng có thể dẫn đến A dead lock khi người dùng có thể xem bản ghi lần đầu tiên vì chia sẻ khóa trên hàng nhưng bây giờ khi người dùng cố gắng cập nhật nó Nó đã có một khóa độc quyền trên nó bởi người dùng thứ nhất. Hãy tưởng tượng một kịch bản mà User1 và User2 Cả hai đã chia sẻ khóa và khi họ cố gắng cập nhật một số bản ghi, cả hai đều nhận được các khóa Exclusive trên các hàng mà người dùng khác cần thực hiện giao dịch. điều này sẽ dẫn đến một DEAD LOCK.
Trong trường hợp một DeadLock nếu máy chủ SQL Priority Level is not set sẽ đợi một lúc và sau đó nó sẽ RollBack giao dịch là cheaper để quay trở lại.
Chỉnh sửa
Có nếu User1 chỉ đọc dữ liệu và User2 trys để Cập nhật một số dữ liệu và có chỉ mục không nhóm trên bảng đó, có thể.

1) User1 đang đọc một số dữ liệu và nhận khóa chia sẻ trên chỉ mục không được nhóm để thực hiện tra cứu, sau đó cố gắng lấy khóa được chia sẻ trên trang liên kết dữ liệu để trả lại dữ liệu .

2) User2 người đang viết/Cập nhật đầu tiên có được khóa khóa trên trang cơ sở dữ liệu chứa dữ liệu, sau đó cố gắng lấy khóa độc quyền trên chỉ mục để cập nhật chỉ mục.