Là một DBA, việc giải quyết các vấn đề về hiệu suất thường là một sự kiện phản ứng; vấn đề xảy ra, bạn phải trả lời. Đôi khi bạn đang xem xét một phiên bản SQL Server mà bạn biết rõ, đôi khi nó có thể là lần đầu tiên bạn gặp một môi trường. Điều này cũng xảy ra trong thế giới tư vấn. Khi giúp đỡ một khách hàng lâu năm, tôi đã có thông tin chi tiết về môi trường. Tuy nhiên, khi chúng tôi nhận được email từ một người mà chúng tôi chưa từng làm việc trước đó và đó là tình huống khẩn cấp mà họ muốn được trợ giúp ngay lập tức, chúng tôi không có kiến thức nền tảng về môi trường và không biết mình đang bước vào vấn đề gì. Chúng tôi cung cấp hỗ trợ mà không cần thông qua quá trình thu thập và phân tích dữ liệu mở rộng, bắt đầu mọi sự tham gia của khách hàng mới.
Vì lý do này, tôi có một bộ năm mục mà tôi sẽ kiểm tra ngay lập tức khi tôi đối đầu với một môi trường mới. Thông tin tôi thu thập tạo tiền đề cho cách tôi tiếp cận khắc phục sự cố về sau và mặc dù thông tin này hiếm khi xác định được THE vấn đề cụ thể, nó giúp tôi loại trừ điều gì KHÔNG vấn đề, đôi khi cũng quan trọng.
Phương pháp thu thập dữ liệu
Tôi nhận ra rằng mọi người có một cách tiếp cận khác nhau khi tiếp cận một môi trường mới. Có một số tập lệnh miễn phí, có sẵn rộng rãi mà bạn có thể tải xuống và chạy để cung cấp cho bạn “cơ sở” cho một phiên bản SQL Server (có lưu ý đến các tập lệnh DMV của Glenn Berry). Trọng tâm ở đây không phải là làm thế nào bạn thu thập dữ liệu, đó là cái gì dữ liệu bạn thu thập và những gì bạn phân tích đầu tiên .
Thuộc tính máy chủ
Điều đầu tiên tôi muốn biết khi xem xét một phiên bản là phiên bản và phiên bản SQL Server. Cách nhanh nhất để lấy thông tin này là thực hiện:
SELECT @@VERSION;
Với kết quả đầu ra này, tôi có thể kiểm tra bản dựng để xác định gói dịch vụ, bản cập nhật tích lũy và các bản sửa lỗi được áp dụng và tôi biết phiên bản nào được sử dụng. Tôi cũng muốn biết liệu phiên bản có được nhóm hay không, vì vậy tôi cũng thực thi:
SELECT SERVERPROPERTY('IsClustered'); Đôi khi tôi có thông tin này từ khách hàng, nhưng việc xác minh sẽ không khó khăn gì vì phiên bản và phiên bản có thể ảnh hưởng đến các bước khắc phục sự cố tiếp theo và các đề xuất. Ví dụ:một khách hàng gần đây đã liên hệ với chúng tôi về sự cố hiệu suất không liên tục mà họ gặp phải với SQL Server 2008. Kiểm tra nhanh phiên bản cho thấy rằng họ đang chạy SQL Server 2008 SP3 và có một số Bản cập nhật tích lũy được phát hành sau SP3 giải quyết một loạt vấn đề hiệu năng. Mặc dù tôi đã thu thập thêm thông tin trước khi đưa ra khuyến nghị rằng họ áp dụng CU mới nhất, nhưng đây là một dấu hiệu đỏ ngay lập tức về điều gì có thể gây ra sự cố.
sys.configurations
Chế độ xem danh mục này giúp xây dựng dựa trên nền tảng bắt đầu với các thuộc tính máy chủ và giúp chúng tôi hiểu cách cá thể được cấu hình. Với chế độ xem này, tôi tìm kiếm các cài đặt đã được thay đổi so với cài đặt mặc định, nhưng lẽ ra không nên và những cài đặt không đã được sửa đổi, nhưng nên.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Xem xét cài đặt bộ nhớ máy chủ tối đa (MB), điều này giới hạn số lượng bộ nhớ có sẵn cho vùng đệm. Giá trị mặc định là 2147483647, nhưng nó phải được thay đổi thành giá trị nhỏ hơn tổng bộ nhớ trên máy chủ để đảm bảo có nhiều bộ nhớ cho HĐH, các ứng dụng khác và các tác vụ SQL Server khác yêu cầu bộ nhớ không được lấy từ vùng đệm . Để được hướng dẫn về cách đặt giá trị thích hợp cho bộ nhớ máy chủ tối đa (MB), tôi khuyên bạn nên đăng bài của Jonathan, Máy chủ SQL của tôi thực sự cần bao nhiêu bộ nhớ?
Ngược lại, cài đặt tăng mức độ ưu tiên có giá trị mặc định là 0 và luôn được để như vậy. Trên thực tế, Microsoft khuyên bạn không nên thay đổi nó và tùy chọn này sẽ bị xóa trong bản phát hành SQL Server trong tương lai.
sys.databases
Sau khi tôi hiểu cá thể được cấu hình như thế nào, tiếp theo tôi sẽ xem những gì tồn tại ở cấp cơ sở dữ liệu.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Khi tôi kiểm tra đầu ra của chế độ xem danh mục này, tôi tìm kiếm các mẫu chống - bất kỳ thứ gì xuất hiện ngoài dự kiến hoặc không điển hình - trong dữ liệu. Kết quả đầu ra có lợi cho việc phân tích nhanh - nhiều cài đặt liệt kê 0 hoặc 1 cho giá trị (tắt hoặc bật) và tôi ghi nhớ những điều khác biệt. Tôi hy vọng các thống kê tự động tạo và thống kê tự động cập nhật sẽ được bật (đặt thành 1). Tôi hy vọng tính năng tự động đóng và tự động thu nhỏ sẽ bị tắt (đặt thành 0). Tôi muốn xem đối chiếu là gì đối với cơ sở dữ liệu người dùng, cụ thể là liệu tất cả chúng có cùng đối chiếu hay không và đối chiếu đó có giống với tempdb hay không. Tôi cũng lưu ý các tùy chọn bảo mật như chuỗi cơ sở dữ liệu chéo và tùy chọn is_trustworthy, cả hai đều bị tắt (0) theo mặc định. Nếu tôi nhận thấy rằng bất kỳ cài đặt nào trong số này sai lệch so với những gì tôi mong đợi, tôi lưu ý và tiếp tục. Tôi không ngừng thu thập hoặc phân tích để thực hiện thay đổi, vì tôi chỉ thu thập thông tin nhanh nhất có thể để hiểu rõ về môi trường.
Ngoài việc kiểm tra cài đặt cho cơ sở dữ liệu, tôi cũng lưu ý đến số lượng cơ sở dữ liệu người dùng. Không có “đúng số lượng” cơ sở dữ liệu người dùng cho một phiên bản - một phiên bản có thể hoạt động kém với một cơ sở dữ liệu và nó có thể hoạt động tuyệt vời với 100. Có vô số yếu tố đang diễn ra và số lượng cơ sở dữ liệu chỉ đơn giản là một điểm dữ liệu đáng chú ý.
Nhật ký Lỗi
Tôi thừa nhận, tôi đã từng bỏ qua SQL Server ERRORLOG; nó giống như một suy nghĩ sau khi tôi điều tra sự cố SQL Server. Sau đó, tôi nhận ra lỗi trong cách làm của mình, và tôi đã không coi đó là điều hiển nhiên. Tôi có xu hướng điều hướng qua Management Studio để truy cập nhật ký (trong Management | SQL Server Logs), mặc dù bạn có thể sử dụng quy trình lưu trữ sp_readerrorlog hoặc duyệt tệp và mở trình soạn thảo văn bản yêu thích của bạn.
Trong ERRORLOG, tôi tìm kiếm các lỗi gần đây - ví dụ như bất kỳ thứ gì liên quan đến bộ nhớ - và tôi cũng tìm kiếm các cờ theo dõi nào, nếu có, đang được sử dụng. Tôi cũng kiểm tra xem Khóa các trang trong bộ nhớ có được bật hay không, bộ nhớ đệm có bị xóa (cố ý hay không) và nếu có bất kỳ hoạt động bất thường nào khác xảy ra thường xuyên. Tùy thuộc vào mức độ khẩn cấp của vấn đề, tôi cũng xem xét nhật ký Windows (Sự kiện, Ứng dụng và Bảo mật), một lần nữa, không chỉ tìm lỗi mà còn cả các mẫu thông báo không mong muốn.
Thống kê Chờ
Khu vực cuối cùng của SQL Server mà tôi xem xét khi xem xét vấn đề hiệu suất trên một phiên bản không xác định là thống kê chờ. Mỗi phiên bản SQL Server sẽ có các lần đợi - cho dù mã được điều chỉnh tốt đến đâu, bất kể phần cứng đằng sau nó là bao nhiêu. Là một DBA, bạn muốn biết các trường hợp chờ điển hình của mình là gì và khi tôi đang xem xét một môi trường mới, tôi không biết ngay liệu các lần chờ mà tôi thấy là điển hình hay do vấn đề hiệu suất. Tôi hỏi khách hàng xem họ có số liệu thống kê về thời gian chờ cơ sở hay không, và nếu không, tôi hỏi liệu tôi có thể xóa chúng và để chúng bắt đầu tích lũy trong khi sự cố hiệu suất xảy ra hay không. Để kiểm tra số liệu thống kê về thời gian chờ, bạn có thể sử dụng tập lệnh trong bài đăng có tham chiếu của Paul Randal hoặc phiên bản trong truy vấn DMV của Glenn.
Khi bạn xem lại thống kê chờ tích lũy, bạn sẽ có phần cuối cùng cung cấp “bức tranh toàn cảnh” về phiên bản SQL Server và thông tin bạn cần để bắt đầu khắc phục sự cố. Việc kiểm tra số liệu thống kê về thời gian chờ trước khi khắc phục sự cố không phải là hiếm, nhưng chỉ chờ đợi không đủ thông tin để xác định những gì bạn cần điều tra tiếp theo trừ khi bạn cũng hiểu cấu hình SQL Server cơ bản.
Các bước tiếp theo
Như tôi đã đề cập trước đó, thường không có một phần dữ liệu nào cho bạn biết vấn đề hiệu suất nằm ở đâu, mà nhiều điểm dữ liệu thu được giúp bạn đi đúng hướng. Cách bạn nắm bắt thông tin đó là tùy thuộc vào bạn, nhưng sau khi xem lại kết quả đầu ra, bạn nên hiểu rõ về cách cấu hình môi trường SQL Server và kiến thức đó, kết hợp với thống kê chờ, có thể giúp bạn quyết định điều cần điều tra tiếp theo. Khắc phục sự cố hoạt động tốt nhất với cách tiếp cận có phương pháp, vì vậy hãy bắt đầu với những điều cơ bản và bắt đầu làm việc, và khi bạn nghĩ rằng bạn đã xác định được nguyên nhân gốc rễ, hãy tìm hiểu thêm một chút và tìm thêm một hoặc hai phần bằng chứng hỗ trợ cho kết quả của bạn. Sau khi có dữ liệu đó, bạn có thể đưa ra đề xuất để giúp cải thiện hoặc giải quyết vấn đề.
