Tại sao phải mất quá lâu để xem nhật ký trên máy chủ?


7

Tôi chỉ cố gắng tìm kiếm thêm thông tin dài dòng cho một nhiệm vụ kế hoạch bảo trì thất bại. Tôi mở trình xem tệp nhật ký và đánh dấu vào ô để xem nhật ký cho gói bảo trì của mình. Không có bộ lọc hoạt động bên cạnh đó trong ví dụ này. Sau đó tôi chơi trò chơi đang chờ .....

Tôi đã mất gần 20 phút để hiển thị các bản ghi. Vì vậy, tôi nghĩ rằng nó có thể chỉ dành thời gian để tải tất cả các bản ghi từ đầu của máy chủ này. Tôi đã giảm bộ lọc xuống còn khoảng 3 ngày vì đó là tất cả những gì tôi cần. Điều đó đến nhanh hơn nhưng vẫn mất 4 phút để hiển thị. Lưu ý đây là lần đầu tiên trên máy tính của tôi, tôi đã cố gắng xem các nhật ký này để có thể đóng một yếu tố. Tôi cũng đã cố gắng xem các bản ghi trực tiếp trên máy chủ nhưng nhận được kết quả thời gian tương tự.

Đây có phải là mệnh cho khóa học? Tôi có nên xem các bản ghi là một trải nghiệm như thế này không? Có điều gì tôi nên làm hoặc kiểm tra? Tôi có kế hoạch kiểm tra tuổi đăng nhập và xem liệu nó có thể bị thanh trừng không nhưng điều đó có còn ảnh hưởng đến việc xem nhật ký chỉ trong một khoảng thời gian X ngày ngắn không?


@MarmiK DBCC LOGINFOđược sử dụng để xem các VLF trong nhật ký giao dịch, có thể bạn đang nhầm lẫn với nó xp_readerrorlog. Nó không giống như Microsoft làm cho những điều này hợp lý, tôi biết.
Nic

@Nic như Brent đã đưa ra câu trả lời, vì vậy tôi đã xóa nhận xét của mình, nhưng để hỗ trợ những gì AMTwo nói, chúng tôi có thể định cấu hình công việc cắt bớt nhật ký.
MarmiK

Câu trả lời:


8

Có, đọc nhật ký mất nhiều thời gian trong trình xem tệp nhật ký. Một vài điều cần khắc phục:

Hãy thử sử dụng xp_readerrorlog với các tham số được lọc để chỉ nhận dữ liệu bạn muốn:

  • @ p1 là tệp nhật ký bạn muốn xem (0 là hiện tại, 1 là tệp lưu trữ đầu tiên, 2 là thứ hai, v.v.)
  • @ p2 là null cho nhật ký lỗi, 2 cho Đại lý
  • @ p3 và @ p4 là các chuỗi để tìm kiếm ở đầu ra

Bằng cách đó bạn chỉ cần có được các hàng bạn muốn.

Nếu bạn thấy mình làm điều này thường xuyên, hãy chạy một công việc để xoay vòng nhật ký lỗi theo định kỳ (tôi thích hàng tuần) để bạn không phải sàng lọc quá nhiều thứ. Ngoài ra, hãy đảm bảo bạn không đăng nhập sao lưu thành công hoặc đăng nhập thành công vào nhật ký lỗi.


Ngoài ra, hãy đảm bảo bạn không đăng nhập sao lưu thành công hoặc đăng nhập thành công vào nhật ký lỗi. Tôi được thừa hưởng một môi trường nơi điều này hiện đang được thực hiện. Tôi nghĩ rằng đó là vì tất cả các công việc đều gửi email mà quản trị viên cuối cùng thích nhìn thấy mỗi sáng. Tôi có một cảm giác tốt khi nhìn thấy lịch sử. Tôi cho rằng tôi có thể cho rằng không có gì đăng nhập là tốt. Nói chung điều này là thêm rất nhiều tiếng ồn vào các bản ghi có?
Matt

6

Theo mặc định, SQL Server sẽ chỉ cuộn qua nhật ký lỗi khi cá thể khởi động lại. Nếu bạn có thời gian hoạt động máy chủ tuyệt vời (có lẽ bạn chỉ vá và khởi động lại một vài lần mỗi năm), nhật ký lỗi có thể trở nên khá lớn (tôi đã thấy nó đạt tới nhiều GB trong một số trường hợp nhất định).

Nhật ký lỗi được lưu trữ dưới dạng tệp văn bản, do đó, việc mở nó trong trình xem nhật ký về cơ bản yêu cầu SQL Server mở và phân tích toàn bộ tệp văn bản - nếu bạn đã từng mở tệp văn bản 10 GB, bạn biết điều này có thể bị chậm.

Tôi thường có một công việc sẽ cuộn qua nhật ký lỗi Máy chủ SQL mỗi tuần một lần, để nhật ký đó đủ nhỏ để mở nhanh - và cũng quay trở lại đủ xa một tệp duy nhất có những gì tôi cần.

Để cuộn lại nhật ký của bạn, chỉ cần chạy quy trình được lưu trữ này (và lên lịch Công việc Tác nhân để chạy nó hàng tuần:

EXEC sp_cycle_errorlog;

Bạn vẫn sẽ thấy các bản ghi lưu trữ cũ trong Object Explorer: ObjectExplorerLogs

Và bạn có thể xem nhiều nhật ký trong Trình xem nhật ký: Trình xem

Bạn cũng có thể muốn giới hạn số lượng tệp nhật ký lưu trữ mà bạn giữ trên máy chủ của mình. Để thực hiện việc này, Nhấp chuột phải vào thư mục "Nhật ký máy chủ SQL" trong Object Explorer và chọn "Cấu hình". Sau đó đánh dấu hộp kiểm và đặt số lượng tệp nhật ký tối đa. Lưu giữ nhật ký

Nói chung, bạn nên sai ở phía cài đặt này cao hơn bạn nghĩ bạn cần. Nếu bạn gặp sự cố khi máy chủ đột nhiên khởi động lại nhiều lần hoặc dịch vụ SQL Server được tái chế nhiều lần, nhật ký lỗi sẽ chuyển qua mỗi lần khởi động lại và nhật ký của bạn sẽ không quay trở lại bao nhiêu tuần bạn muốn.

Bạn cũng có thể thiết lập lưu giữ nhật ký thông qua xp_instance_regwrite. Trong ví dụ dưới đây, nó đang đặt giá trị này để giữ lại 10 nhật ký lỗi:

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', 
    N'Software\Microsoft\MSSQLServer\MSSQLServer', 
    N'NumErrorLogs', 
    REG_DWORD, 
    10
GO

2

Bạn chắc chắn nên cuộn nhật ký Lỗi SQL và Nhật ký Lỗi Tác nhân SQL như @AMtwo đã đề xuất trong nhận xét ở trên.

Vì câu hỏi liên quan đến việc đọc nhật ký kế hoạch bảo trì, tôi sẽ giải thích làm thế nào bạn có thể giữ kích thước có thể quản lý và mở một cách nhanh chóng.

Để ghi nhật ký gói bảo trì, bạn muốn tạo một tệp mới mỗi lần Kế hoạch bảo trì được thực thi.

nhập mô tả hình ảnh ở đây

Nhấp vào biểu tượng đó và bạn nhận được cửa sổ sau. 'Tạo một tệp mới' nên được mặc định và xác nhận điều đó. Không kiểm tra 'Nối vào tệp' vì điều đó sẽ tạo một tệp duy nhất cho tất cả thực thi.

nhập mô tả hình ảnh ở đây

Bạn có thể có một nhiệm vụ bảo trì khác để dọn sạch các tệp nhật ký cũ hơn xx ngày để tránh việc lấp đầy đĩa.


2

Gói bảo trì tạo tệp nhật ký của riêng họ nếu bạn chọn tùy chọn đó. Khi nhìn vào lịch sử MP, nó đang đọc từ [msdb]. [Dbo]. [Sysmaintplan_log] và [msdb]. [Dbo]. [Sysmaintplan_logdetail], không phải các tệp văn bản đó. Làm sạch cái này với Nhiệm vụ Dọn dẹp Lịch sử, vì việc này sẽ dọn sạch các bảng và tệp.

SQL Server ERRORLog và Agentlog nên được duy trì đúng cách, nhưng MP là một cuộc trò chuyện / nỗ lực riêng biệt

Theo truyền thống lớn của MS ... không có chỉ mục nào trên các bảng đó, ngoại trừ được nhóm trên [msdb]. [Dbo]. [Sysmaintplan_log]

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.