Đây là câu hỏi tiếp theo từ: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically
Mặc dù vậy, tôi vẫn gặp tình huống bế tắc / hết thời gian trong ứng dụng ASP.NET khi chạy các báo cáo lớn đồng thời READ_COMMITTED_SNAPSHOT ON.
Vì vậy, tôi có hai câu hỏi:
- Làm cách nào tôi có thể kiểm tra xem Ảnh chụp nhanh Cấp độ Cách ly Giao dịch có hoạt động như mong đợi / không?
- Tôi giả sử rằng các khóa ngoại (trong các bảng của Ứng dụng web cho các bảng báo cáo) chịu trách nhiệm cho các khóa chết. Tôi tìm thấy bài viết thú vị này :
Lưu ý SQL Server có được các khóa được chia sẻ khi xác thực các khóa ngoại, ngay cả khi giao dịch đang sử dụng ảnh chụp nhanh đã cam kết (đọc cam kết sử dụng phiên bản hàng) hoặc mức cô lập ảnh chụp nhanh. Hãy chú ý điều này khi kiểm tra biểu đồ khóa chết từ các giao dịch khi các mức cô lập giao dịch này được sử dụng. Nếu bạn thấy các khóa được chia sẻ, hãy kiểm tra xem liệu các khóa được lấy trên một đối tượng được tham chiếu bởi khóa ngoại.
Làm cách nào tôi có thể kiểm tra xem FK có thực sự chịu trách nhiệm cho các tình huống Bế tắc / Hết giờ không, điều đó có nghĩa là tôi có thể xóa các khóa ngoại đó để ngăn chặn bế tắc (điều gì sẽ là một nỗ lực chấp nhận được)?
Lưu ý : Tôi chỉ đọc từ các bảng gây ra bế tắc.
Bất kỳ suy nghĩ về chủ đề này được đánh giá rất cao.
Chỉnh sửa Dưới đây là một đồ thị bế tắc . Có lẽ ai đó có thể giúp tôi hiểu những gì gây ra bế tắc. Có vẻ như nó xảy ra mà không có bất kỳ báo cáo nào chạy chỉ do ứng dụng web gây ra, khi hai giao dịch muốn ghi cùng một bảng (một bản cập nhật và một lần chèn, phần chèn là dưới dạng Thủ tục lưu trữ). Tại sao nó lại khóa trang và làm thế nào để chỉ khóa hàng? Chèn-SP đã sử dụng TRANSACTION ISOLATION LEVEL REPEATABLE READ.
Tôi có một nghi ngờ mạnh mẽ rằng hai kích hoạt (một cập nhật và một chèn) chịu trách nhiệm cho các bế tắc. Đây là trình kích hoạt chèn:
CREATE TRIGGER [dbo].[CreateRMAFiDates]
ON [dbo].[RMA]
AFTER INSERT
AS
BEGIN
SET NOCOUNT ON;
UPDATE RMA
SET [fiCreationDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
[fiPopDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
[fiManufactureDate]=(SELECT idDate FROM tdefDate
WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
FROM INSERTED;
ENDVì vậy, trình kích hoạt này cập nhật Bảng RMA, nguyên nhân khiến trình kích hoạt cập nhật kích hoạt (điều tương tự). Liệu đồ thị bế tắc có xác nhận giả định của tôi không? Tôi nghĩ rằng tôi sẽ xóa các kích hoạt đó và tạo một SP đang chạy mỗi ngày một lần, điều đó là hoàn toàn đủ, bởi vì các cột này chỉ dành cho SSAS-Cube (Molap).
Chỉnh sửa : Nhân tiện, không còn bế tắc nữa kể từ khi tôi xóa các kích hoạt này :)