SQL Server - Có bao nhiêu loại thời gian chờ có thể xảy ra và làm thế nào?

Khi làm việc với SQL Server, có thể có nhiều máy chủ ứng dụng truy cập vào nó và mỗi ứng dụng có thể có một hoặc nhiều kết nối. Mỗi kết nối có khả năng có thể có nhiều giao dịch (vui lòng sửa cho tôi nếu tôi sai). Mỗi giao dịch có thể thực hiện truy vấn hoặc SQL không truy vấn.

Theo kinh nghiệm của tôi, tôi dễ dàng chạy vào thời gian chờ nếu tôi truy vấn một bảng bị khóa riêng. Tôi cũng thấy SQL Server phát hiện và ném ngoại lệ bế tắc thay vì hết thời gian nếu hai ứng dụng khác nhau khóa trên cùng một tài nguyên. Tôi cũng hiển thị thời gian chờ xây dựng lại chỉ mục, điều này có thể do ai đó vẫn có kết nối với bảng.

Tuy nhiên, tôi cũng gặp phải một loại bế tắc trong đó SQL Server không phát hiện ra hoặc hết thời gian. Trong ứng dụng này, nó đã mở hai kết nối, hai giao dịch riêng biệt, trong đó giao dịch thứ nhất đã khóa một tài nguyên và giao dịch thứ 2 cố gắng truy cập vào cùng một tài nguyên, nhưng nó đã không đóng giao dịch đầu tiên.

Ai đó sẽ cung cấp một danh sách các loại thời gian chờ và / hoặc bế tắc, nó sẽ giúp tôi tránh các loại trường hợp này khi làm việc trên ứng dụng.

Từ quan điểm ứng dụng, có:

• hết thời gian kết nối (ứng dụng sẵn sàng chờ bao lâu để thiết lập kết nối với SQL Server)
• hết thời gian chờ lệnh (ứng dụng sẵn sàng chờ lệnh hoàn thành trong bao lâu, bao gồm cả việc kéo kết quả xuống từ SQL Server)

Quay trở lại những ngày kinh điển của tôi, mặc định của chúng lần lượt là 15 và 30 giây , tôi không biết chúng là gì theo mặc định trong .NET ngày hôm nay.

SQL Server có bộ thời gian chờ riêng, ví dụ:

• Hết thời gian truy vấn từ xa. Mặc định là 600 giây (10 phút).
• Hết thời gian đăng nhập từ xa. Mặc định là 10 giây.
• Truy vấn chờ. Mặc định là -1 (25 x chi phí truy vấn).
• Toàn thời gian xử lý giao thức xử lý. Mặc định là 60 giây.

Bạn có thể thấy những giá trị này cho hệ thống của bạn ở đây:

SELECT * FROM sys.configurations
WHERE configuration_id IN (1519,1520,1541,1557);

Ngoài ra còn có @@LOCK_TIMEOUT(mặc định là -1 (vô cùng)). Đây là thời gian SQL Server sẽ đợi trên một tài nguyên bị chặn. Bạn có thể ghi đè lên phiên này cho một phiên cụ thể bằng cách sử dụng SET LOCK_TIMEOUT. Thêm chi tiết tại đây .

Những bế tắc tôi cho rằng cũng có thể rơi vào loại này. Hệ thống quét các tình huống bế tắc cứ sau 5 giây và không có công thức ma thuật nào để xác định khi nào sự bế tắc sẽ xảy ra liên quan đến khi bất kỳ yêu cầu liên quan nào bắt đầu. Điều này là do SQL Server không để giao dịch cũ nhất giành chiến thắng; nó chọn nạn nhân dựa trên DEADLOCK_PRIORITY và lượng tài nguyên ước tính cần thiết để đưa nạn nhân trở lại. Thêm chi tiết tại đây .

Ngoài ra còn có thời gian chờ cấp bộ nhớ (có thể được tùy chỉnh bằng Resource Governor). Tùy thuộc vào sự tương tranh, một truy vấn sẽ không nhất thiết thất bại nếu nó hết thời gian chờ trước khi có được tất cả bộ nhớ được yêu cầu, nó sẽ chỉ chạy với số lượng được phân bổ (và do đó có thể kém hiệu quả hơn). Nếu thất bại, bạn có thể sẽ thấy Msg 8645.

Bạn có thể có ý tưởng cho các tình huống hết thời gian tiềm năng khác có thể xảy ra trong SQL Server bằng cách xem lại các thông báo lỗi này:

SELECT message_id, [text]
  FROM sys.messages 
  WHERE language_id = 1033 
  AND ([text] LIKE '%timeout%' OR [text] LIKE '%time out%')

Tuy nhiên tôi không nghĩ rằng đó là thực tế, khả thi hoặc hiệu quả cho bất cứ ai cố gắng cung cấp cho bạn một danh sách đầy đủ và đầy đủ về mọi tình huống hết thời gian có thể. Giải quyết các vấn đề bạn đang gặp phải, thay vì giải quyết sớm một loạt vấn đề mà có lẽ bạn sẽ không bao giờ ...

Có ba khái niệm khác nhau được chạm vào đây. Hy vọng rằng điều này cung cấp một lời giải thích tốt về những gì họ đang có, và từ đó bạn có thể tìm ra cách để tránh chúng.

Chặn (còn gọi là khóa trực tiếp)
Chặn xảy ra khi truy vấn cố lấy khóa, nhưng phải đợi trong hàng đợi khóa trước khi khóa được cấp. Nó có thể xuất hiện từ bên ngoài rằng truy vấn không làm gì cả, vì nó đang chờ (các) quá trình khác giải phóng (các) khóa trước nó trong hàng đợi. Chặn có thể gây ra bế tắc nếu các khóa được mua theo một thứ tự cụ thể (tôi mô tả điều này dưới đây).

Hết giờ Hết
giờ xảy ra khi khách hàng đưa ra yêu cầu về tài nguyên và chờ phản hồi. Nếu không có phản hồi nào được nhận trong một khoảng thời gian nhất định, lỗi sẽ được đưa ra bởi khách hàng thay vì chờ đợi mãi mãi. Thời gian chờ có thể xảy ra vì nhiều lý do (chặn hoặc truy vấn thực hiện rất nhiều công việc hoặc mạng rất chậm hoặc ...), nhưng cuối cùng tất cả là do khách hàng đang chờ và quyết định rằng họ không muốn còn chờ gì nữa

Sự bế tắc Sự bế
tắc xảy ra khi hai hoặc nhiều quá trình giữ các khóa đối với tài nguyên và cũng cố gắng thực hiện các khóa đối với các tài nguyên được giữ bởi các tiến trình khác. Điều này tạo ra một tình huống mà không có truy vấn nào có thể tiếp tục trừ khi một trong số chúng bị chấm dứt / khôi phục. Tôi đã chứng minh làm thế nào điều này hoạt động trong một video demo ở đây .