Các truy vấn SQL đơn giản không kết thúc [đã đóng]

Tôi hoàn toàn không biết cách đặt câu hỏi vì chúng tôi chưa biết nhiều, nhưng tôi muốn hỏi sớm hơn vì điều này có vẻ như là một điều không nên bỏ qua.

Tuần này chúng tôi bắt đầu có vấn đề với máy chủ cơ sở dữ liệu của chúng tôi. Nó dường như là một vấn đề nhất quán dữ liệu và nó biểu hiện bằng thời gian chờ ngay cả trên các truy vấn rất đơn giản và các bảng nhỏ. Chúng tôi đã "khắc phục" sự cố bằng cách khởi động lại máy chủ vào đầu tuần này và nó đã biến mất, nhưng bây giờ có vẻ như nó sẽ quay trở lại và lần này là trên các bảng quan trọng hơn. Chẳng hạn, tôi vừa thực hiện một số điều tra và tôi đang xem một truy vấn như thế này:

SELECT * FROM table WHERE id = 1234

cho một ID cụ thể. Bảng có khoảng hơn 30 triệu hàng. Nhưng có vẻ như nó chỉ xảy ra đối với một phần nhỏ hồ sơ. Tôi đặt cược khi tôi khởi động lại máy chủ hoặc sao lưu và khôi phục cơ sở dữ liệu trên một máy chủ khác, tất cả sẽ ổn. Nhưng tôi sẽ cố gắng.

Tại thời điểm này, tôi đang chạy:

DBCC CHECKTABLE ('table', NOINDEX)

nhưng có vẻ như nó sẽ chạy mãi mãi. Khi chúng tôi gặp sự cố lần đầu tiên, tôi đã kiểm tra bảng vi phạm và nó vẫn ổn. Bàn mới này lớn hơn nhiều.

Một số thông tin kỹ thuật cơ bản:

• Máy chủ SQL 2008 R2, Windows Server 2008 R2
• AWS / EC2, m2.2xlộng, RAM 32 GB, RAID 4 x 1TB 0
• hầu như không có đĩa IO, có vẻ như hầu hết db nằm trong bộ nhớ
• tổng kích thước db: 100GB

Khối lượng ELB là "thương hiệu" mới. Chúng tôi đã tạo ra chúng trong tuần này.

Chỉnh sửa: Tôi chỉ sử dụng lệnh sau:

SELECT
    sqltext.TEXT,
    req.session_id,
    req.blocking_session_id,
    req.wait_type,
    req.wait_time,
    req.last_wait_type,
    req.wait_resource,
    req.open_transaction_count,
    req.transaction_id,
    req.total_elapsed_time
FROM
    sys.dm_exec_requests req
CROSS APPLY
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

và nhận thấy rằng truy vấn của tôi, nó đang chờ khóa chia sẻ (LCK_M_S) trong đó phiên chặn đang chờ một khóa chia sẻ khác bị chặn bởi một phiên không tồn tại.

Chỉnh sửa 2: OK, phiên tồn tại (tôi thấy nó sử dụng sys.dm_exec_sessions), nhưng hiện tại nó không xuất hiện để làm bất cứ điều gì.

Chỉnh sửa 3: Tôi không thể tìm thấy bất cứ điều gì thú vị về phiên này. Tôi thấy nó đến từ máy chủ web nào, nhưng không nhiều.

Chỉnh sửa 4: Chỉnh sửa 4: Chúng tôi đã tìm thấy một lỗi có thể có trong mã của chúng tôi: một chức năng không đảm bảo kết nối cơ sở dữ liệu bị đóng. Mặt khác, có vẻ như giao dịch mà chức năng đang sử dụng được sử dụng được xử lý chính xác trong trường hợp tất cả các khóa phải được xóa. Nó vẫn chưa rõ ràng đối với tôi, nhưng dường như đó là lý do có thể. Chúng tôi sẽ sửa lỗi và để mắt đến nó.

Đối với tôi, sự cố này là do kết nối cơ sở dữ liệu bị mở do Visual Studio tạm dừng ở chế độ gỡ lỗi. Dừng quá trình gỡ lỗi cho phép truy vấn hoàn thành ngay lập tức.

Loại chờ cho truy vấn khi nó được treo là gì? Điều này sẽ cho bạn biết chính xác những gì nó đang chờ đợi. Đi tìm và cài đặt sp_whoisactive trên máy chủ và chạy quy trình được lưu trữ khi bạn gặp sự cố. Điều này sẽ cho bạn thấy spid và cung cấp cho bạn loại chờ đợi.

Điều lạ lùng là bạn đang bị chặn bởi ai đó viết vào hàng đó hoặc một hàng khác trên trang đó hoặc bạn đang chờ đĩa phản hồi.

Cố gắng chạy DBCC CHECKDBtrên DB vấn đề và đợi cho đến khi nó kết thúc. Nếu có sự không nhất quán dữ liệu vật lý tạo ra một hành vi lạ như vậy, thì quá nguy hiểm khi làm việc với DB này vì bạn có thể mất tất cả dữ liệu của mình.

1. Làm sao lưu càng sớm càng tốt.
2. Kiểm tra DB.

NHƯNG

Nếu bảng có các cột BLOB với lượng dữ liệu tương đối lớn, việc kiểm tra đối với bảng này sẽ mất nhiều thời gian.

không thực sự chắc chắn những gì bạn mong đợi như một câu trả lời nhưng nếu bảng có hơn 30 triệu hàng, dự kiến ​​rằng comand DBCC sẽ hoạt động trong một thời gian dài.

Khi bạn nói:

Nhưng có vẻ như nó chỉ xảy ra với một phần nhỏ hồ sơ

bạn có nghĩa là bạn lo lắng rằng toàn bộ bảng không được quét ong? Điều đó là bình thường nếu bạn có một chỉ mục trên ID, chỉ mục sẽ được quét sẽ dẫn đến số lần đọc ít hơn.