Một trang web chúng tôi lưu trữ gần đây đã trải qua thời gian tải chậm. Nó đã được loại trừ rằng vấn đề nằm ở máy chủ web và nó có thể liên quan đến cơ sở dữ liệu.
Những bước hoặc quy trình nào tôi phải thực hiện để xác nhận hoặc loại trừ rằng SQL Server là lý do cho thời gian tải chậm? Ngoài ra, không có đường cơ sở, điều gì có thể là hành vi / đặc điểm của SQL Server để tìm ra điều đó có thể chỉ ra rằng có vấn đề?
Câu trả lời:
Tôi muốn đề nghị bạn cần một tuyên bố vấn đề dứt khoát hơn - đó có phải là tất cả các trang web không? Nếu chỉ là một số, những trang web đó đang làm gì? Thời gian tải chấp nhận được là bao nhiêu và thời gian tải hiện tại là bao nhiêu? Có phải tất cả người dùng, hoặc chỉ một số?
Tôi đã từng là một quản trị viên web và kiểm tra đầu tiên của tôi sẽ là máy chủ web - bộ nhớ và CPU có ổn không? Các bản ghi hệ điều hành và web hiển thị bất cứ điều gì? Các kịch bản có thể xuất ra một bản ghi để hiển thị những gì đang xảy ra? ví dụ: tôi đã từng đặt công cụ cơ sở dữ liệu vào một phần và ghi thời gian / thời lượng cho từng hoạt động cơ sở dữ liệu vào nhật ký khi được kích hoạt.
Nếu bạn cần kiểm tra Máy chủ SQL, hãy kiểm tra nhật ký SQL & NT và kiểm tra lại bộ nhớ, đĩa IO và CPU - trình quản lý tác vụ sẽ cung cấp cho bạn lý tưởng về hai trong số này (không phải đĩa IO). Tốt nhất, SQL Server nên ở trên một hộp chuyên dụng thay vì chia sẻ với bất cứ thứ gì.
Trong khi ai đó đang sử dụng trang web, hãy xem Activity Monitor hoặc sp_who2 - bạn có thể thấy truy vấn không? Có bất kỳ chặn? Tiếp tục làm mới ... nếu truy vấn có thể chạy / bị treo / chạy trong một thời gian, thì bạn cần tìm lý do tại sao nó chậm. Nếu bạn không thể thấy truy vấn ở các trạng thái đó, thì đó có thể không phải là Máy chủ SQL.
Quy trình lưu trữ tiện dụng này sẽ cho bạn biết những gì đang xảy ra vào lúc này trong một phần nghìn giây trên máy chủ cơ sở dữ liệu của bạn:
SQL 2000: http://cookingwithsql.com/source/sp_now.sql
SQL 2005 trở lên: http://cookingwithsql.com/source/Now.sql
Tôi đã viết một mô tả chi tiết về "sp_now" ở đây: http://www.sqlmag.com/article/tsql3/prove-that-the-database-isn-t-to-blame
Đầu tiên, kích hoạt Trình giám sát hoạt động . Bạn thấy gì trong Tổng quan - có rất nhiều phiên chờ đợi? Bây giờ hãy xem trong Resource Waitits - là máy chủ đang vật lộn để vào I / O đĩa, hay nó đang dành rất nhiều thời gian để chờ khóa. Bạn cũng có thể thấy các câu lệnh SQL đắt tiền gần đây. Để biết thêm chi tiết, bạn có thể xem phần Hoạt động hoặc kích hoạt SQL Profiler (với lời cảnh báo rằng bản thân nó là một hoạt động đắt tiền - đừng làm cho tình huống xấu trở nên tồi tệ hơn!).
Tất nhiên có nhiều thứ để điều chỉnh hiệu năng hơn điều này - nhưng điều này sẽ nhanh chóng cho bạn thấy SQL Server thực sự đang làm gì. Và một thực tế quan trọng cần nhớ: cơ sở dữ liệu sẽ thử làm bất cứ công việc gì bạn đưa ra, nhưng nó không thể luôn đoán được ý định của bạn. Nếu ứng dụng đang gửi SQL xấu (ví dụ: CHỌN nhiều hàng hơn mức cần thiết và lọc chúng trong ứng dụng, tôi đã thấy điều này nhiều lần) hoặc thiết kế lược đồ bị lỗi (ví dụ: thiếu chỉ mục) thì cách khắc phục sự cố cơ sở dữ liệu nhận thức ngoài cơ sở dữ liệu. Các Tuning Advisor có thể giúp bạn chẩn đoán loại vấn đề.
Khi bạn đã loại bỏ tất cả những gì là không thể, thì bất cứ điều gì còn lại, dù không thể, đều phải là sự thật. - Sherlock Holmes
Để hoàn thiện, hãy cân nhắc việc chứng minh rằng mọi thứ khác không thể là vấn đề. Loại bỏ phần cứng, bao gồm RAM, NIC, bộ định tuyến, cáp; loại bỏ các quy trình máy chủ; loại bỏ các phần mềm khác, như máy chủ web, máy chủ proxy, v.v.
Đối với nhiều tổ chức, chỉ cần tìm ra "mọi thứ ngoài cơ sở dữ liệu" có thể là một cái mở mắt.
Tất cả các cấu hình máy chủ và dịch vụ web là khác nhau. Cách tốt nhất để giải quyết vấn đề này là không nhìn thấy nhiều nếu SQL Server của bạn làm chậm trang web của bạn, nhưng nhận ra rằng đó luôn là cách tốt nhất để đảm bảo SQL của bạn được viết theo cách tối ưu hóa tốt, sử dụng các thủ tục được lưu trữ cho mọi thứ và tránh truy vấn thông qua. Các truy vấn chuyển qua đã là mã kế thừa từ đầu những năm 90 và không có nơi nào hiệu quả như các thủ tục được lưu trữ.
Ngoài ra, nếu bạn đã viết các truy vấn tab chéo, đặc biệt là đối với các bảng lớn, hãy cân nhắc việc lặp lại dữ liệu để tránh sử dụng các truy vấn tab chéo (các truy vấn được lồng trong các phép nối hoặc phép nối kép). Nếu bạn có nhiều truy vấn tab chéo và lặp lại dữ liệu trong các trường bổ sung không phải là một tùy chọn, hãy kiểm tra xem các truy vấn tab chéo của bạn có trả về số lượng hàng tối thiểu không. Đừng cố lọc các tab chéo thông qua bộ lọc DISTINCT / DISTINCTROW. Cũng tránh sử dụng các kích hoạt vì điều này sẽ mở ra một lớp DML. Lớp DML bổ sung trong hầu hết các công cụ cơ sở dữ liệu có thể dễ dàng cắt giảm một nửa hiệu suất của công cụ DB. Cách tốt nhất để tối ưu hóa các tab chéo là chơi xung quanh với các trường tham gia cho đến khi bạn nhận được số lượng hàng tối thiểu phản ánh số lượng hàng trong hầu hết các bảng bên trái (cho một liên kết bên trái) hoặc hầu hết các bảng bên phải (trong một liên kết bên phải ).
Cũng làm bạn tốt nhất để tránh nhiều đến nhiều truy vấn. Nhiều truy vấn chỉ thực sự được sử dụng cho các báo cáo hoặc tích hợp với các nguồn dữ liệu của bên thứ ba mà hệ thống ban đầu không được thiết kế để tích hợp.
Ngoài những trường hợp ngoại lệ này Nếu một cơ sở dữ liệu được chuẩn hóa đúng cách, bạn sẽ không bao giờ thấy nhiều người tham gia.
Mặc dù tôi tôn trọng điều này không trực tiếp trả lời câu hỏi của bạn nếu bạn đã thực hiện lời khuyên này trong bài viết này, nhưng vấn đề thực sự là bạn cần một dịch vụ web mạnh hơn, có lẽ là một máy chủ đám mây.
Hy vọng lời khuyên này sẽ giúp.