Kiểm tra tình trạng máy chủ SQL chủ động, Phần 4:LỖI

Có rất nhiều điều bạn có thể nói về lịch sử và tầm quan trọng. Lịch sử của một đất nước, của nền văn minh, của mỗi chúng ta. Tôi thích những câu trích dẫn và thích câu này của Teddy Roosevelt (anh chàng tuyệt vời):

Tại sao tôi viết về lịch sử (hoặc cố gắng) về lịch sử trong một blog về SQL Server? Bởi vì lịch sử trong SQL Server cũng quan trọng. Khi sự cố hiệu suất tồn tại trong SQL Server, lý tưởng nhất là khắc phục sự cố trực tiếp, nhưng trong một số trường hợp, thông tin lịch sử có thể cung cấp một khẩu súng hút thuốc hoặc ít nhất là một điểm khởi đầu. Một nguồn thông tin lịch sử tuyệt vời trong SQL Server là LỖI. Tôi đã đề cập trong bài đăng ban đầu của mình, Các vấn đề về hiệu suất:Cuộc gặp gỡ đầu tiên, rằng LỖI đã từng là một suy nghĩ sau đó đối với tôi. Không còn nữa. Trong quá trình kiểm tra của khách hàng, chúng tôi luôn nắm bắt các LỖI và mặc dù chúng tôi được thông báo về bất kỳ cảnh báo mức độ nghiêm trọng cao nào (được ghi vào nhật ký), chúng tôi không quên tìm thấy thông tin thú vị khác trong nhật ký. Chúng tôi chuẩn bị cho tương lai bằng cách sử dụng thông tin lịch sử trong nhật ký; thông tin có thể giúp chúng tôi khắc phục sự cố hoặc sự cố tiềm ẩn trước khi nó trở nên nghiêm trọng.

Xem ERRORLOG

Trước hết, chúng tôi sẽ xem xét một số tùy chọn để xem ERROLOG. Nếu tôi được kết nối với một phiên bản, tôi thường sẽ điều hướng đến phiên bản đó thông qua SSMS (Management | SQL Server Logs, nhấp chuột phải vào nhật ký và chọn View SQL Server Log). Từ cửa sổ này, tôi chỉ có thể cuộn qua nhật ký hoặc sử dụng các tùy chọn Bộ lọc hoặc Tìm kiếm để thu hẹp tập hợp kết quả. Tôi cũng có thể xem nhiều tệp bằng cách chọn chúng trong ngăn bên trái.

Nếu tôi đang xem dữ liệu được ghi lại trong một trong những cuộc kiểm tra sức khỏe của chúng tôi, tôi sẽ chỉ mở tệp nhật ký trong trình soạn thảo văn bản và xem lại chúng (tôi cũng có tùy chọn truy cập vào trình xem và tải chúng). Các tệp nhật ký tồn tại trong thư mục nhật ký (vị trí mặc định:C:\ Program Files \ Microsoft SQL Server \ MSSQL12.SQL2014 \ MSSQL \ Log) nếu tôi muốn xem chúng trên máy chủ. Nhiều người trong số các bạn có thể thích xem và / hoặc tìm kiếm nhật ký bằng thủ tục không có tài liệu sp_readerrorlog hoặc thủ tục được lưu trữ mở rộng xp_readerrorlog.

Và cuối cùng, nếu bạn đã sử dụng PowerShell, thì đó cũng là một tùy chọn để đọc nhật ký theo cách đó (xem bài đăng này:Sử dụng PowerShell để phân tích cú pháp SQL Server 2012 Nhật ký lỗi). Phương pháp là tùy thuộc vào bạn - sử dụng những gì bạn biết và những gì phù hợp với bạn - đó là nội dung thực sự quan trọng. Và hãy nhớ rằng có những lúc bạn chỉ cần đọc qua nhật ký để hiểu thứ tự của các sự kiện và có những thời điểm khác, bạn có thể tìm kiếm để tìm một lỗi hoặc một phần thông tin cụ thể.

Có gì trong ERRORLOG?

Vậy chúng ta có thể tìm thấy thông tin nào trong LỖI, ngoài lỗi? Tôi đã liệt kê nhiều mục mà tôi thấy hữu ích nhất bên dưới. Lưu ý rằng đây không phải là một danh sách đầy đủ (và tôi chắc rằng nhiều người trong số các bạn sẽ có đề xuất về những gì có thể được thêm vào - hãy đăng nhận xét và tôi có thể cập nhật điều này!), Nhưng một lần nữa, đây là những gì tôi đang tìm kiếm đầu tiên khi tôi chủ động xem xét một ví dụ.

• Máy chủ là vật lý hay ảo (tìm mục Nhà sản xuất hệ thống)
• Cờ theo dõi được bật khi khởi động
  • Trong mục nhập thông số khởi động Sổ đăng ký, nếu bạn cuộn hết cỡ sang bên phải, bạn sẽ thấy liệu có bật cờ theo dõi nào không:
    
    Cờ theo dõi được bật khi khởi động
• Cờ theo dõi được bật hoặc tắt sau khi phiên bản bắt đầu
  • Nếu người dùng (hoặc một ứng dụng) bật hoặc tắt cờ theo dõi bằng cách sử dụng DBCC TRACEON hoặc DBCC TRACEOFF, một mục nhập sẽ xuất hiện trong nhật ký
• Số lõi và ổ cắm được SQL Server phát hiện
  • Tôi luôn muốn xác minh rằng SQL Server xem tất cả phần cứng có sẵn - và nếu không, đó là một lá cờ đỏ để điều tra thêm. Để có một ví dụ điển hình, hãy xem bài đăng của Jonathan, Các vấn đề về hiệu suất với SQL Server 0212 Enterprise Edition Theo Cấp phép CAL và bài đăng của Glenn, Cân bằng đồng đều các giấy phép lõi SQL Server có sẵn của bạn trên NUMA, cũng bao gồm một số TSQL tiện dụng để truy vấn nhật ký.
  • Lưu ý rằng văn bản cho mục nhập này khác nhau giữa các phiên bản SQL Server.
• Lượng bộ nhớ được SQL Server phát hiện
  • Một lần nữa, tôi muốn xác minh rằng SQL Server xem tất cả bộ nhớ có sẵn cho nó.
• Xác nhận rằng các trang trong bộ nhớ đã khóa (LPIM) đã được bật
  • Mặc dù tùy chọn này được bật qua Chính sách Bảo mật của Windows, bạn có thể xác nhận rằng nó đã được bật bằng cách tìm thông báo "Sử dụng các trang bị khóa trong trình quản lý bộ nhớ" trong nhật ký.
  • Xin lưu ý rằng nếu bạn đang sử dụng Trace Flag 834 thì thông báo sẽ không cho biết các trang bị khóa mà sẽ cho biết rằng các trang lớn đang được sử dụng cho vùng đệm.
• Phiên bản CLR đang được sử dụng
• Đăng ký Tên chính của Dịch vụ (SPN) thành công hay thất bại
• Mất bao lâu để cơ sở dữ liệu trực tuyến
  • Nhật ký ghi lại khi cơ sở dữ liệu khởi động và khi cơ sở dữ liệu trực tuyến - tôi kiểm tra xem liệu có cơ sở dữ liệu nào mất quá nhiều thời gian để hiển thị hay không.
• Trạng thái của điểm cuối Nhà môi giới dịch vụ và sao chép cơ sở dữ liệu - quan trọng nếu bạn đang sử dụng một trong hai tính năng
• Xác nhận rằng Khởi tạo Tệp Tức thì (IFI) đã được bật *
  • Theo mặc định, thông tin này không được ghi lại, nhưng nếu bạn bật Cờ theo dõi 3004 (và 3605 để buộc đầu ra vào nhật ký), khi bạn tạo hoặc phát triển tệp dữ liệu, bạn sẽ thấy thông báo trong nhật ký cho biết IFI có được sử dụng hay không.
• Trạng thái của Dấu vết SQL
  • Khi bạn bắt đầu hoặc dừng SQL Trace, nó sẽ được ghi lại và tôi sẽ xem liệu có tồn tại bất kỳ dấu vết nào ngoài dấu vết mặc định hay không (tạm thời hoặc lâu dài). Nếu bạn đang chạy một công cụ giám sát của bên thứ ba, chẳng hạn như Cố vấn Hiệu suất của SQL Sentry, bạn có thể thấy một dấu vết hoạt động luôn chạy, nhưng chỉ ghi lại các sự kiện cụ thể hoặc bạn có thể thấy một dấu vết bắt đầu, chạy trong một thời gian ngắn, sau đó ngừng lại. Tôi không quan tâm đến một hoặc hai dấu vết bổ sung, trừ khi họ ghi lại nhiều sự kiện, nhưng tôi chắc chắn chú ý khi nhiều dấu vết đang chạy.
• Lần cuối cùng CHECKDB được hoàn thành
  • Thông báo này thường bị mọi người hiểu nhầm - khi phiên bản khởi động, nó sẽ đọc trang khởi động cho mỗi cơ sở dữ liệu và ghi chú khi CHECKDB chạy thành công lần cuối. Hầu hết mọi người không đọc toàn bộ tin nhắn:
    
    Ngày hoàn tất thành công lần cuối DBCC CHECKDB

    Ngày hoàn thành CHECKDB là ngày 11 tháng 11 năm 2012, nhưng ngày ERRORLOG là ngày 7 tháng 7 năm 2015. Điều quan trọng cần hiểu là SQL Server không chạy CHECKDB dựa trên cơ sở dữ liệu khi khởi động, nó sẽ kiểm tra giá trị dbcclastknowngood trên trang khởi động (để xem khi nào giá trị đó được cập nhật, hãy xem bài đăng của tôi, Kiểm tra gì Cập nhật dbcclastknowngood. Ngoài ra, nếu DBCC CHECKDB chưa bao giờ được chạy trên cơ sở dữ liệu, thì không có mục nhập sẽ hiển thị cho cơ sở dữ liệu tại đây.

• Hoàn thành CHECKDB
  • Khi CHECKDB được chạy trên cơ sở dữ liệu, kết quả đầu ra sẽ được ghi vào nhật ký.
• Các thay đổi đối với cài đặt phiên bản
  • Nếu bạn thay đổi cài đặt cấp phiên bản (ví dụ:bộ nhớ máy chủ tối đa, ngưỡng chi phí cho tính song song) bằng cách sử dụng sp_configure hoặc thông qua giao diện người dùng (lưu ý rằng nó không ghi lại ai đã thay đổi nó).

• Các thay đổi đối với cài đặt cơ sở dữ liệu
  • Có ai đó đã bật AUTO_SHRINK không? Thay đổi tùy chọn PHỤC HỒI thành ĐƠN GIẢN rồi quay lại ĐẦY ĐỦ? Bạn sẽ tìm thấy nó ở đây.
• Các thay đổi đối với trạng thái cơ sở dữ liệu
  • Nếu ai đó lấy cơ sở dữ liệu NGOẠI TUYẾN (hoặc mang nó ONLINE), điều này sẽ được ghi lại.
• Thông tin bế tắc *
  • Nếu bạn cần nắm bắt thông tin bế tắc, không muốn chạy theo dấu vết, và bạn đang chạy SQL Server 2005 đến 2008R2, hãy sử dụng cờ theo dõi 1222 để ghi thông tin bế tắc vào nhật ký ở định dạng XML. Đối với những người bạn sử dụng SQL Server 2000 trở xuống, bạn có thể theo dõi cờ 1204 (cờ theo dõi này cũng có sẵn trong SQL Server 2005+, nhưng nó xuất ra thông tin tối thiểu). Nếu bạn đang chạy SQL Server 2012 trở lên, thì điều này không cần thiết vì phiên sự kiện system_health nắm bắt thông tin này (và nó cũng có trong năm 2008 và 20082, nhưng bạn phải kéo nó từ ring_buffer so với đích event_file).
• Thông báo FlushCache
  • Nếu bộ đệm ẩn đang bị SQL Server xóa do quá trình điểm kiểm tra vượt quá khoảng thời gian khôi phục cho cơ sở dữ liệu, bạn sẽ thấy một tập hợp các thông báo FlushCache trong nhật ký (xem bài đăng này của Bob Dorr để biết thêm thông tin). Đừng nhầm lẫn những thông báo này với những thông báo hiển thị khi bạn chạy DBCC FREEPROCCACHE hoặc DBCC FREESYSTEMCACHE:
    
    Thông báo sau khi chạy DBCC FREEPROCCACHE hoặc DBCC FREESYSTEMCACHE

• AppDomain dỡ tin nhắn
  • Nhật ký cũng ghi chú khi AppDomains được tạo và bạn sẽ chỉ thấy nếu bạn đang sử dụng CLR. Nếu tôi thấy AppDomain không tải thông báo vì áp lực bộ nhớ, thì đó là điều cần điều tra thêm.

Có thông tin khác trong nhật ký hữu ích, chẳng hạn như chế độ xác thực đang được sử dụng, kết nối quản trị viên chuyên dụng (DAC) có được bật hay không, v.v. nhưng tôi cũng có thể lấy thông tin đó từ sys.configurations và tôi kiểm tra những thông tin đó có đường cơ sở phiên bản Tôi đã thảo luận trước đó (Kiểm tra tình trạng máy chủ SQL chủ động, Phần 3:Cài đặt phiên bản và cơ sở dữ liệu).

Điều gì không có trong ERROLOG mà bạn có thể mong đợi?

Đây là danh sách ngắn, hiện tại, tôi đoán một số bạn có thể đã tìm thấy những thứ khác mà bạn nghĩ sẽ có trong nhật ký nhưng không phải…

• Thêm hoặc xóa các tệp cơ sở dữ liệu hoặc nhóm tệp
• Bắt đầu hoặc dừng các Phiên sự kiện mở rộng
  • Tuy nhiên, nếu bạn triển khai Trình kích hoạt DDL hoặc Thông báo Sự kiện cấp máy chủ, bạn có thể ghi lại thông tin này. Xem bài đăng của Jonathan, Ghi nhật ký Sự kiện mở rộng thay đổi đối với ERRORLOG, để biết thêm chi tiết.
• Chạy DBCC DROPCLEANBUFFERS không hiển thị trong ERRORLOG

Quản lý nhật ký

Hãy nhớ rằng theo mặc định, SQL Server chỉ giữ sáu (6) tệp nhật ký gần đây nhất (ngoài tệp hiện tại) và tệp nhật ký sẽ cuộn qua mỗi khi SQL Server khởi động lại. Do đó, đôi khi bạn có thể có các tệp nhật ký cực kỳ lớn, mất một lúc để mở và rất khó tìm hiểu. Mặt khác, nếu bạn gặp phải trường hợp phiên bản được khởi động lại một vài lần, bạn có thể mất thông tin quan trọng. Bạn nên tăng số lượng tệp được giữ lại lên giá trị cao hơn (ví dụ:30) và tạo công việc Đại lý để cuộn qua tệp mỗi tuần một lần bằng cách sử dụng sp_cycle_errorlog.

Ngoài việc quản lý các tệp, bạn có thể ảnh hưởng đến thông tin nào được ghi vào nhật ký. Một trong những mục nhập phổ biến nhất tạo ra sự lộn xộn trong ERRORLOG là mục nhập sao lưu thành công:

Đã hoàn tất sao lưu thành công

Nếu bạn có một trường hợp có nhiều cơ sở dữ liệu và bản sao lưu nhật ký giao dịch được thực hiện với bất kỳ mức độ thường xuyên nào (ví dụ:15 phút một lần), bạn sẽ thấy nhật ký nhanh chóng lấp đầy các thông báo, điều này khiến việc tìm ra vấn đề thực sự khó khăn hơn. May mắn thay, bạn có thể sử dụng cờ theo dõi 3226 để vô hiệu hóa các thông báo sao lưu thành công (lỗi sẽ vẫn hiển thị trong nhật ký và tất cả các mục sẽ vẫn tồn tại trong msdb).

Một bộ thông báo khác làm lộn xộn nhật ký là thông báo đăng nhập thành công. Đây là một tùy chọn bạn định cấu hình cho phiên bản trên tab Bảo mật:

Tùy chọn bảo mật để ghi lại các lần đăng nhập thành công và / hoặc thất bại

Nếu bạn ghi nhật ký đăng nhập thành công hoặc đăng nhập không thành công và thành công, bạn có thể có tệp nhật ký rất lớn, ngay cả khi bạn cuộn qua tệp hàng ngày (nó sẽ phụ thuộc vào số lượng người dùng kết nối). Tôi khuyên bạn chỉ nên ghi lại những lần đăng nhập không thành công. Đối với các doanh nghiệp có yêu cầu ghi lại các lần đăng nhập thành công, hãy xem xét sử dụng tính năng Kiểm tra, được thêm vào SQL Server 2008. Lưu ý bên:Nếu bạn thay đổi cài đặt Kiểm tra đăng nhập, nó sẽ không có hiệu lực cho đến khi bạn khởi động lại phiên bản.

Đừng đánh giá thấp ERRORLOG

Như bạn có thể thấy, có một số thông tin tuyệt vời trong ERRORLOG để bạn sử dụng không chỉ khi khắc phục sự cố về hiệu suất hoặc điều tra lỗi mà còn khi bạn chủ động theo dõi một phiên bản. Bạn có thể tìm thấy thông tin trong nhật ký mà không tìm thấy ở bất kỳ nơi nào khác; đảm bảo rằng bạn đang kiểm tra nó một cách thường xuyên và không để nó như một suy nghĩ sau đó.

Xem các phần khác trong loạt bài này:

• Phần 1:Dung lượng đĩa
• Phần 2:Bảo trì
• Phần 3:Cài đặt Phiên bản và Cơ sở dữ liệu