Vấn đề khóa cơ sở dữ liệu?


7

Tôi đã gặp phải một vấn đề liên quan đến giao dịch trên cơ sở dữ liệu sản xuất SQL Server 2008. Một tổng quan ngắn gọn là chúng tôi có một trang web có nhiều người dùng đồng thời trên toàn tiểu bang, những người làm công việc loại GUI (Thêm bản ghi, sửa đổi, xem, v.v.) thông qua một trang web ASP.Net.

Mỗi lần chèn và cập nhật được thực hiện trong Giao dịch riêng, được xử lý bởi lớp truy cập dữ liệu. Tôi tin rằng sự cô lập cơ sở dữ liệu được đặt thành Read_Commited.

Tất cả đều hoạt động tốt.

Tuy nhiên, một mô-đun mới đã được thêm vào, trong đó thăm dò một cơ sở dữ liệu riêng để biết thông tin. Nếu có thông tin mới, một quy trình sẽ bắt đầu một giao dịch mới và sử dụng cùng một mã truy cập dữ liệu để đọc từ cơ sở dữ liệu của chúng tôi, cũng như đọc từ một cơ sở dữ liệu riêng biệt khác cho thông tin mới. Sau đó, nó thực hiện vô số kiểm tra để xem nó phải làm gì với dữ liệu mới ... Và bắt đầu thực hiện vô số cập nhật hoặc chèn vào cơ sở dữ liệu của chúng tôi. Đây là tất cả trong một giao dịch lớn. Tất cả các chèn và cập nhật từ cả ứng dụng UI và dịch vụ bỏ phiếu đều trải qua các quy trình CRUD giống nhau. Vì một tin nhắn đến được xử lý có thể chứa rất nhiều thực thể cần cập nhật, thời gian để giao dịch hoàn thành có thể nằm trong khoảng thời gian một giây và một phút.

Mặc dù vậy, điều chúng tôi tìm thấy là khi một tin nhắn lớn hơn được xử lý, giao diện người dùng sẽ khóa và có thể khóa cho người dùng trong 3 phút.

Vì vậy, chúng tôi nghĩ rằng có thể thêm gợi ý 'NOLOCK' vào các lựa chọn có thể hỗ trợ. Nó đã không. Chà, nó có thể đã giúp một chút, nhưng việc khóa máy vẫn đang diễn ra.

Tôi nghĩ rằng nguyên nhân có thể là do tin nhắn đến và một giao dịch được bắt đầu, điều này đang khóa các giao dịch khác hoạt động (Ngay cả các câu lệnh CHỌN mà tôi không hiểu). Cấu hình cơ sở dữ liệu cho thấy rằng ngay cả các lựa chọn đơn giản cũng mất nhiều thời gian để hoàn thành trên UI (Đơn giản, chẳng hạn nhưSELECT fields FROM SingleTable WHERE PrimaryKey = Value

Các chỉ mục của chúng tôi có vẻ ổn ... Chúng tôi có Triggers trên tất cả các bảng chỉ cần sao chép các cập nhật và chèn vào bảng cơ sở dữ liệu AUDIT. Đừng nghĩ họ là vấn đề.

Tôi nghĩ đó là vì giao dịch xung quanh quá trình xử lý tin nhắn đang khóa giao diện người dùng.

Bất cứ ai cũng có thể chia sẻ kinh nghiệm hoặc cho tôi biết nơi tôi có thể tìm kiếm để xem lý do tại sao chúng tôi bị khóa giao diện người dùng? UI nên được ưu tiên. Xử lý tin nhắn là một điều cơ bản ... người dùng cần được ưu tiên ... nhưng có vẻ như các tin nhắn đang khóa cơ sở dữ liệu ... và chúng tôi không chắc chắn liệu UI có khóa xử lý tin nhắn không.

Hy vọng ai đó có thể giúp đỡ. Tôi có thể cung cấp càng nhiều thông tin càng tốt để giúp đỡ.

Câu trả lời:


4

Hãy thử bật tính năng cách ly Ảnh chụp đã đọc (RCSI) (nhưng lưu ý rằng điều này sẽ gây áp lực lên tempDB của bạn, lý tưởng nhất là trên các trục vật lý chuyên dụng của riêng nó).

Có hai cấp độ 'ảnh chụp nhanh' có sẵn trong SQL Server 2005 trở đi: ĐỌC SNAPSHOT đọc lạc quan và viết bi quan; trong khi SNAPSHOT ISOLATION thực hiện đọc lạc quan và viết lạc quan. Đề nghị bạn thử RCSI.

Kích hoạt các mức cô lập dựa trên phiên bản hàng

Để thay đổi cài đặt này, bạn cần chuyển sang chế độ một người dùng để đảm bảo không có truy vấn nào trong chuyến bay (sau đó sẽ thất bại):

ALTER DATABASE dbname 
SET SINGLE_USER WITH ROLLBACK IMMEDIATE; 
GO

ALTER DATABASE dbname
SET READ_COMMITTED_SNAPSHOT ON; 
GO

ALTER DATABASE dbname
SET MULTI_USER; 
GO

Chúng tôi đã thử điều này - nhưng nó dường như không giúp được gì. Ngoài ra, khi chúng tôi đưa nó vượt qua các lỗi cơ sở hạ tầng, các DBA chúng tôi không hài lòng với việc bật cách ly ảnh chụp nhanh - vì nó phải được kích hoạt DB rộng. Tôi sẽ lờ mờ một lần nữa, nhưng các DBA đã nói rằng chúng tôi cần phân tích thêm về tùy chọn này.

2
"Chúng tôi đã thử điều này - nhưng dường như không có ích" - Đề nghị bạn đưa thông tin quan trọng này vào câu hỏi của bạn. Cấu hình tempDB của bạn là gì? Bạn đã điểm chuẩn hệ thống con I / O của mình chưa ??
Mitch Wheat

Cảm ơn Mitch - bài kiểm tra của tôi không dài lắm ... Vì vậy, tôi sẽ thử lại vào thứ Hai. Nhưng họ sẽ hỏi nó có ảnh hưởng gì đến phần còn lại của hệ thống. Ngoài ra, các triệu chứng tôi đề cập ở trên có giống như các vấn đề khóa do giao dịch lớn gây ra không?

2

Vấn đề chặn phiên đã được thảo luận một vài lần.

Tôi chắc rằng bạn có thể tìm thấy một số tài liệu tham khảo tốt trong các câu hỏi sau:

Trước tiên, bạn cần tìm nếu bạn thực sự có một vấn đề chặn. Điều đó có thể dễ dàng tìm thấy đặc biệt bằng cách sử dụng thủ tục lưu trữ WhoIsActive của Adam Machanic (điều này phải được chạy thủ công khi bạn tin rằng phiên cụ thể của bạn bị chặn hoặc có thể được tự động hóa) hoặc một số báo cáo khác hiển thị các phiên chặn. Để hiểu rõ hơn về thời gian và thời lượng của các tình huống chặn, bạn nên chuẩn bị tốt hơn một số dấu vết phía máy chủ sẽ thu thập thông tin cần thiết về các phiên bị chặn.

Chi tiết về việc tìm và chống chặn bạn có thể tìm thấy trong câu trả lời này .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.