SQL Azure - Một phiên khóa toàn bộ DB để cập nhật và chèn

Question

vấn đề SQL Azure.

Tôi đã có một vấn đề mà biểu hiện là ngoại lệ sau đây trên (asp.net) trang web của chúng tôi:

Timeout hết hạn. Khoảng thời gian chờ đã hết trước khi hoàn thành hoạt động hoặc máy chủ không phản hồi. Tuyên bố đã bị hủy .

Kết quả cập nhật và chèn không bao giờ hoàn thành trong SMSS. Không có bất kỳ khóa X hoặc IX nào hiện diện khi truy vấn: sys.dm_tran_locks và không có giao dịch khi truy vấn sys.dm_tran_active_transactions hoặc sys.dm_tran_database_transactions.

Sự cố xảy ra với mọi bảng trong cơ sở dữ liệu nhưng các cơ sở dữ liệu khác trên cùng một cá thể không gây ra sự cố. Thời gian của vấn đề có thể là bất cứ nơi nào từ 2 phút đến 2 giờ và không xảy ra tại bất kỳ thời gian cụ thể trong ngày.

Cơ sở dữ liệu chưa đầy.

Tại một thời điểm, vấn đề này không giải quyết được nhưng tôi có thể giải quyết vấn đề bằng cách truy vấn sys.dm_exec_connections tìm phiên chạy dài nhất và sau đó giết nó. Điều kỳ lạ là, kết nối đã được 15 phút tuổi, nhưng vấn đề khóa đã có mặt trong hơn 3 giờ.

Tôi có thể kiểm tra bất kỳ điều gì khác không?

EDIT

Như mỗi câu trả lời của Paul bên dưới. Tôi thực sự đã theo dõi vấn đề trước khi anh ta trả lời. Tôi sẽ đăng các bước tôi đã sử dụng để tìm ra điều này bên dưới, trong trường hợp họ giúp đỡ bất kỳ ai khác.

Các truy vấn sau được chạy khi có "khoảng thời gian chờ".

select * from sys.dm_exec_requests 

Như chúng ta có thể thấy, tất cả các yêu cầu WAIT đang chờ đợi trên phiên 1021 đó là yêu cầu sao chép! TM Request cho biết giao dịch DTC và chúng tôi không sử dụng giao dịch được phân phối. Bạn cũng có thể thấy wait_type của SE_REPL_COMMIT_ACK một lần nữa ngụ ý nhân rộng.

select * from sys.dm_tran_locks 

Một lần nữa chờ đợi vào phiên 1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc 

Và vâng, SE_REPL_CATCHUP_THROTTLE có một thời gian chờ đợi tổng cộng 8.094.034 ms, đó là 134.9minutes !!!

Cũng xem diễn đàn sau đây để biết chi tiết về vấn đề này. http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

Tôi đã cho câu trả lời sau đây trong giao tiếp của tôi với Microsoft (chúng tôi đã nhìn thấy vấn đề này với 4 của 15 cơ sở dữ liệu của chúng tôi ở trung tâm EU dữ liệu):

Câu hỏi: Có đã có những thay đổi đối với các giới hạn điều chỉnh mềm này trong ba tuần qua tức là kể từ khi các vấn đề của tôi bắt đầu?

Trả lời: Không, không có.

Câu hỏi: Có cách nào chúng tôi có thể ngăn chặn hoặc được cảnh báo rằng chúng tôi sắp đạt đến giới hạn?

Trả lời: Không. Vấn đề có thể không do ứng dụng của bạn gây ra nhưng có thể do các đối tượng thuê khác là phụ thuộc vào cùng một phần cứng vật lý. Nói cách khác, ứng dụng của bạn có thể tải rất ít và vẫn gặp sự cố. Nói cách khác, lưu lượng truy cập của riêng bạn có thể là nguyên nhân gây ra sự cố này, nhưng nó cũng có thể do những người thuê nhà khác dựa trên cùng một phần cứng vật lý. Không có cách nào để biết trước rằng vấn đề sẽ sớm xảy ra - nó có thể xảy ra bất cứ lúc nào mà không cần cảnh báo. Nhóm hoạt động của Azure Azure không giám sát loại lỗi này, vì vậy chúng sẽ không tự động tìm cách giải quyết vấn đề cho bạn. Vì vậy, nếu bạn chạy vào nó, bạn có hai opitions:

1. Tạo một bản sao của db của bạn và sử dụng đó và hy vọng các db được đặt trên máy chủ khác với ít tải.

2. Liên Windows Azure hỗ trợ và thông báo cho người về vấn đề này và để cho họ làm Lựa chọn 1 cho bạn

Answer 1

Bạn có thể chạy vào SE_REPL * Các vấn đề hiện đang gây rắc rối cho rất nhiều folks sử dụng Sql Azure (công ty của tôi bao gồm).

Khi bạn trải nghiệm timeout, hãy thử kiểm tra yêu cầu chờ đợi của bạn với nhiều loại chờ đợi của:

• SE_REPL_SLOW_SECONDARY_THROTTLE
• SE_REPL_COMMIT_ACK

Run sau đây để kiểm tra các loại chờ đợi của bạn trên các kết nối hiện tại:

SELECT TOP 10 r.session_id, r.plan_handle, 
r.sql_handle, r.request_id, 
r.start_time, r.status, 
r.command, r.database_id, 
r.user_id, r.wait_type, 
r.wait_time, r.last_wait_type, 
r.wait_resource, r.total_elapsed_time, 
r.cpu_time, r.transaction_isolation_level, 
r.row_count 
FROM sys.dm_exec_requests r 

Bạn cũng có thể ch Eck một lịch sử của các loại cho điều này bằng cách chạy:

SELECT * FROM sys.dm_db_wait_stats 
ORDER BY wait_time_ms desc 

Nếu bạn gặp phải rất nhiều SE_REPL * chờ đợi loại và chúng được ở lại đặt trên các kết nối của bạn cho bất kỳ khoảng thời gian, sau đó về cơ bản bạn đang hơi say. Microsoft nhận thức được vấn đề, nhưng tôi đã có một vé hỗ trợ mở cho một tuần với họ bây giờ và họ vẫn đang làm việc trên nó rõ ràng.

SE_REPL * đợi xảy ra khi các lần sao chép Sql Azure rơi xuống phía sau. Về cơ bản, toàn bộ db đình chỉ truy vấn trong khi sao chép bắt kịp:/

Vì vậy, về cơ bản khía cạnh làm cho Sql Azure sẵn sàng cao đang khiến cơ sở dữ liệu trở nên không có sẵn ngẫu nhiên. Tôi sẽ cười nhạo báng nếu nó không giết chết chúng tôi.

Hãy nhìn vào chủ đề này để biết chi tiết: http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8