MS SQL Server chậm lại theo thời gian?

Có bất kỳ ai trong số bạn có kinh nghiệm sau đây, và bạn đã tìm thấy một giải pháp:

Một phần lớn của back-end trang web của chúng tôi là MS SQL Server 2005. Mỗi tuần hoặc hai tuần trang web bắt đầu chạy chậm hơn - và tôi thấy các truy vấn mất nhiều thời gian hơn và lâu hơn để hoàn thành trong SQL. Tôi có một truy vấn mà tôi muốn sử dụng:

USE master
select text,wait_time,blocking_session_id AS "Block",
percent_complete, * from sys.dm_exec_requests 
CROSS APPLY sys.dm_exec_sql_text(sql_handle)  AS s2 order by start_time asc

Điều này khá hữu ích ... nó cung cấp một ảnh chụp nhanh tất cả mọi thứ đang chạy ngay tại thời điểm đó đối với máy chủ SQL của bạn. Điều tuyệt vời là ngay cả khi CPU của bạn được chốt ở mức 100% vì một số lý do và Activity Monitor không chịu tải (Tôi chắc chắn một số bạn đã ở đó) truy vấn này vẫn trả về và bạn có thể thấy truy vấn nào đang giết DB của bạn.

Khi tôi chạy cái này hoặc Trình giám sát hoạt động trong thời gian SQL bắt đầu chạy chậm, tôi không thấy bất kỳ truy vấn cụ thể nào gây ra sự cố - chúng TẤT CẢ chạy chậm hơn trên bảng. Nếu tôi khởi động lại Dịch vụ MS SQL thì mọi thứ đều ổn, nó sẽ tăng tốc - trong một hoặc hai tuần cho đến khi nó xảy ra lần nữa.

Không có gì tôi có thể nghĩ đã thay đổi, nhưng điều này mới chỉ bắt đầu vài tháng trước ... Ý tưởng?

--Thêm

Xin lưu ý rằng khi cơ sở dữ liệu này chậm xảy ra, không có vấn đề gì nếu chúng ta nhận được 100 nghìn lượt xem trang một giờ (thời gian bận rộn hơn trong ngày) hoặc 10 nghìn lượt xem trang một giờ (thời gian chậm) tất cả các truy vấn mất nhiều thời gian hơn bình thường. Máy chủ không thực sự bị căng thẳng - CPU không cao, việc sử dụng đĩa dường như không thể kiểm soát được ... nó có cảm giác như bị phân mảnh chỉ mục hoặc một cái gì đó tương tự nhưng dường như không phải là trường hợp

Theo như kết quả dán của truy vấn tôi đã dán ở trên, tôi thực sự không thể làm điều đó. Truy vấn trên liệt kê thông tin đăng nhập của người dùng thực hiện tác vụ, toàn bộ truy vấn, v.v. và tôi thực sự không muốn đưa ra tên của cơ sở dữ liệu, bảng, cột và thông tin đăng nhập trực tuyến của mình :) ... Tôi có thể cho bạn biết rằng các truy vấn đang chạy tại thời điểm đó là bình thường, các truy vấn tiêu chuẩn cho trang web của chúng tôi chạy mọi lúc, không có gì ngoài định mức.

- Ngày 24

Đã khoảng hai tuần kể từ lần khởi động lại cuối cùng. Tôi đã thực hiện một số thay đổi: Tôi đã tìm thấy một vài truy vấn trong đó chúng tôi đang sử dụng rất nhiều bảng tạm thời hoàn toàn không cần thiết và các nhà phát triển của chúng tôi thay đổi cách họ thực hiện nó. Tôi đã điều chỉnh kích thước của một số cơ sở dữ liệu đang phát triển liên tục (chậm nhưng chắc chắn) thành kích thước thông minh cho sự phát triển của chúng. Tôi đã điều chỉnh cài đặt tự động phát triển để mọi thứ trở nên thông minh hơn (chúng được đặt TẤT CẢ để tăng trưởng 1MB). Cuối cùng tôi đã dọn sạch MSDB một chút. Chúng tôi đăng nhập vận chuyển và thực sự không cần phải giữ các điểm dự phòng hàng năm và hàng năm, tôi đã viết một số tập lệnh giữ điều này chỉ trong một vài tháng. Tôi sẽ tiếp tục cập nhật chủ đề này, vì còn quá sớm để biết vấn đề đã được giải quyết chưa.

Chúng tôi đã tìm thấy nó. Hóa ra đó thực sự là một máy chủ web có vấn đề với một trong các nhóm ứng dụng của nó. Nó sẽ bị kẹt khi chạy cùng một tập các truy vấn (điều này xảy ra để xử lý các bảng tạm thời). Nó sẽ chỉ lặp và lặp và cuối cùng làm cho máy chủ SQL buồn. Khi nhóm máy / ứng dụng vi phạm này được tìm thấy và 'đặt xuống', mọi thứ đã được giải quyết.

Bạn phải tự hỏi, điều gì xảy ra khi khởi động lại dịch vụ SQL? Rất nhiều thứ, nhưng hai điểm liên quan xuất hiện trong tâm trí:

1) Bộ nhớ SQL được giải phóng.

Nó có thể (không chắc chắn như thế nào khả năng), nếu thiết lập MaxMemory của bạn được đặt quá cao, mà các dịch vụ SQL phát triển để sử dụng tất cả các bộ nhớ có sẵn, và Windows khởi động để trao đổi những thứ quan trọng ra các tập tin hoán đổi. Kiểm tra để đảm bảo rằng MaxMemory được đặt thành một giá trị hợp lý, để lại đủ bộ nhớ bổ sung cho bất kỳ thứ gì khác cần chạy trên hộp đó (nó có phải là máy chủ SQL chuyên dụng không? Hay đó cũng là máy chủ ứng dụng?)

2) TempDB được xây dựng lại từ các kích thước mặc định.

Kiểm tra kích thước tệp tempdb mặc định của bạn, đặc biệt là kích thước mặc định và khoảng thời gian tăng trưởng của tệp Nhật ký TempDB. Nếu khoảng thời gian tăng trưởng được đặt quá THẤP, thì nhật ký có thể tạo ra một số phân mảnh nội bộ đáng kinh ngạc, có thể làm chậm đáng kể việc sử dụng bình thường. Xem những hai bài viết trên blog tuyệt vời bởi Kimberly Tripp.

Bạn có sử dụng nhiều bảng tạm thời hoặc con trỏ không? Kiểm tra bất kỳ con trỏ đang được đóng và giải quyết chính xác. Ngoài ra, hãy coi chừng các máy chủ được liên kết - chúng tôi phải sử dụng trình điều khiển lỗi cho máy chủ Informix được liên kết cũ và định kỳ có nghĩa là chúng tôi phải khởi động lại máy chủ.

Nếu nó có vẻ kỳ lạ thì hãy tìm những thứ kỳ lạ.

Nếu điều chỉnh cài đặt máy chủ sql không giúp thử trình quản lý tác vụ windows: đi tới tab quy trình, sau đó tùy chọn> cột> thêm thời gian cpu, xử lý, đọc, ghi, khác và các tùy chọn bộ nhớ.

Quay trở lại danh sách quy trình. Đối với mỗi cột sắp xếp theo cao nhất đến thấp nhất và nhìn vào 5 quy trình hàng đầu. Bất cứ điều gì khác thường? ví dụ: rò rỉ bộ nhớ trên một tiến trình sẽ có số lượng tay cầm kỳ quái. Chúng tôi có một số máy in * ki có thêm tay cầm cho quy trình DCSLoader cứ sau 2 giây. Sau một vài tuần, một máy liệt kê rất nhiều bộ nhớ và cpu miễn phí, nhưng một quá trình với 100.000 tay cầm và sẽ hầu như không di chuyển con trỏ chuột.

Kiểm tra danh sách nhiệm vụ theo lịch trình của bạn quá. Nói với AV của bạn không quét các tập tin .mdf.

Dave,

Bạn đã kiểm tra số liệu thống kê chờ? truy vấn bạn đưa ra ở trên liệt kê cột 'last_wait_type'. cột đó có thể có một số chi tiết liên quan đến những gì các truy vấn đang chờ (mạng, cpu, v.v.)

Nếu "Mô hình khôi phục" sao lưu của bạn là ĐẦY ĐỦ, thì việc sao lưu DB và sau đó sao lưu nhật ký giao dịch có cải thiện mọi thứ không? Trên một hệ thống sắp hết dung lượng đĩa, loại điều này có thể giải thích vấn đề.

Tôi dường như có một cấu hình rất giống với cấu hình của bạn (16Gb, được nâng cấp lên 32Gb và MD1000 với một terabyte của đĩa, xe bốn bánh kép).

Điều duy nhất đã giúp tôi chẩn đoán những vấn đề kỳ quái như thế trong quá khứ là beta_lockinfo của Erland Sommarskog. Chạy nó khi nó chậm thời gian và so sánh.

Ngoài ra, tôi đã có một số vấn đề điên rồ với SQL 2005 trước SP2, nhưng SP3 thực sự ổn định.

Hy vọng điều này cung cấp thêm thông tin hữu ích:

SELECT  D.text SQLStatement,
        A.Session_ID SPID,
        C.BlkBy,
        ISNULL(B.status, A.status) Status,
        A.login_name Login,
        A.host_name HostName,
        DB_NAME(B.Database_ID) DBName,
        B.command,
        ISNULL(B.cpu_time, A.cpu_time) CPUTime,
        ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO,
        A.last_request_start_time LastBatch,
        A.program_name
FROM    sys.dm_exec_sessions A
        LEFT JOIN sys.dm_exec_requests B
        ON A.session_id = B.session_id
        LEFT JOIN (
                   SELECT   A.request_session_id SPID,
                            B.blocking_session_id BlkBy
                   FROM     sys.dm_tran_locks AS A
                            INNER JOIN sys.dm_os_waiting_tasks AS B
                            ON A.lock_owner_address = B.resource_address
                  ) C
        ON A.Session_ID = C.SPID
        OUTER APPLY sys.dm_exec_sql_text(sql_handle) D
WHERE   DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's
ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC

Hãy chắc chắn rằng db vẫn ổn với:

DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database.
DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views

Theo dõi logspace với:

DBCC SQLPERF(LOGSPACE)

Nếu bạn thấy việc mở rộng đang diễn ra, điều đó chắc chắn sẽ làm mọi thứ chậm lại. Nếu bạn chạy cái này, bạn sẽ thấy không gian log của bạn gần hơn và gần hơn 100%, sau đó nhật ký sẽ mở rộng và tỷ lệ phần trăm sẽ co lại khi nó có một khoảng trống. Hy vọng rằng bạn sẽ không bao giờ thấy nó mở rộng trước khi bản sao lưu của bạn khởi động và xóa nhật ký.

Chủ yếu là cấu hình ngốc. Xảy ra.

• Đầu tiên, bạn thực sự nên thường xuyên chạy phân mảnh chỉ mục trong một lần bảo trì. Lên lịch cho nó như một hoạt động, ngay trước hoặc sau khi bạn thực hiện sao lưu.

• Thứ hai, không tự động điền cơ sở dữ liệu của bạn và đặc biệt không tự động thu thập nó. Tùy thuộc vào tải autogrow / autoshrink về cơ bản là các cài đặt tự sát.

Không thấy SQL Server chậm như vậy bao giờ. Bạn có thể đăng kết quả của truy vấn đó trong thời gian căng thẳng hugh không? Chắc chắn không có gì cuối cùng của bạn làm quá tải SQL Server tại thời điểm đó?