Xóa dấu vết mặc định

[Phần 1 | Phần 2 | Phần 3]

Theo tinh thần của những lời khen ngợi gần đây của Grant Fritchey và những nỗ lực của Erin Stellato kể từ khi tôi nghĩ trước khi chúng tôi gặp nhau, tôi muốn tham gia vào ban nhạc để thổi kèn và thúc đẩy ý tưởng bỏ dấu vết để ủng hộ Sự kiện mở rộng. Khi ai đó nói theo dõi , hầu hết mọi người ngay lập tức nghĩ rằng Hồ sơ . Mặc dù Profiler là cơn ác mộng đặc biệt của riêng nó, nhưng hôm nay tôi muốn nói về dấu vết mặc định của SQL Server.

Trong môi trường của chúng tôi, nó được kích hoạt trên tất cả hơn 200 máy chủ sản xuất và nó thu thập rất nhiều rác mà chúng tôi sẽ không bao giờ điều tra. Trên thực tế, quá nhiều rác, những sự kiện quan trọng mà chúng ta có thể thấy hữu ích để khắc phục sự cố được tung ra khỏi các tệp theo dõi trước khi chúng ta có cơ hội. Vì vậy, tôi bắt đầu xem xét triển vọng tắt nó đi, bởi vì:

nó không miễn phí (chi phí của người quan sát đối với bản thân hoạt động theo dõi, I / O liên quan đến việc ghi vào các tệp theo dõi và không gian mà họ sử dụng);
trên hầu hết các máy chủ, nó không bao giờ được xem xét ; trên những người khác, hiếm khi; và,
rất dễ dàng để bật lại để khắc phục sự cố cụ thể, riêng lẻ.

Một số thứ khác ảnh hưởng đến giá trị của dấu vết mặc định. Nó không thể định cấu hình theo bất kỳ cách nào - bạn không thể thay đổi các sự kiện mà nó thu thập, bạn không thể thêm bộ lọc và bạn không thể kiểm soát số lượng tệp nó lưu giữ (5), dung lượng chúng có thể nhận được (20 MB mỗi tệp) hoặc nơi chúng được lưu trữ (SERVERPROPERTY('ErrorLogFileName') ). Vì vậy, chúng tôi hoàn toàn chịu được khối lượng công việc - trên bất kỳ máy chủ nhất định nào, chúng tôi không thể dự đoán dữ liệu có thể quay ngược trở lại bao xa (các sự kiện có TextData lớn hơn chẳng hạn, giá trị có thể chiếm nhiều dung lượng hơn và đẩy ra các sự kiện cũ nhanh hơn). Đôi khi nó có thể quay trở lại một tuần, những lần khác nó có thể quay trở lại chỉ vài phút.

Phân tích trạng thái hiện tại

Tôi đã chạy đoạn mã sau đối với 224 trường hợp sản xuất, chỉ để hiểu loại nhiễu nào đang lấp đầy dấu vết mặc định trong môi trường của chúng tôi. Điều này có lẽ phức tạp hơn mức cần thiết và thậm chí không phức tạp như truy vấn cuối cùng mà tôi đã sử dụng, nhưng đó là một điểm khởi đầu phù hợp để phân tích phân tích các loại sự kiện cấp cao hiện đang được nắm bắt:

;WITH filesrc ([path]) AS
(
  SELECT REVERSE(SUBSTRING(p, CHARINDEX(N'\', p), 260)) + N'log.trc'
  FROM (SELECT REVERSE([path]) FROM sys.traces WHERE is_default = 1) s(p)
),
tracedata AS 
(
  SELECT Context = CASE 
    WHEN DDL = 1 THEN 
      CASE WHEN LEFT(ObjectName,8) = N'_WA_SYS_' 
                THEN 'AutoStat: ' + DBType
           WHEN LEFT(ObjectName,2) IN (N'PK', N'UQ', N'IX') AND ObjectName LIKE N'%[_#]%' 
                THEN UPPER(LEFT(ObjectName,2)) + ': tempdb'
           WHEN ObjectType = 17747 AND ObjectName LIKE N'TELEMETRY%' 
                THEN 'Telemetry' 
                ELSE 'Other DDL in ' + DBType END
    WHEN EventClass = 116 THEN 
      CASE WHEN TextData LIKE N'%checkdb%' THEN 'DBCC CHECKDB'
           -- several more of these ...
           ELSE UPPER(CONVERT(nchar(32), TextData)) END
    ELSE DBType END,
    EventName = CASE WHEN DDL = 1 THEN 'DDL' ELSE EventName END, 
    EventSubClass,
    EventClass, 
    StartTime
  FROM
  (
    SELECT DDL = CASE WHEN t.EventClass IN (46,47,164) THEN 1 ELSE 0 END, 
      TextData = LOWER(CONVERT(nvarchar(512), t.TextData)), 
      EventName = e.[name],
      t.EventClass, 
      t.EventSubClass, 
      ObjectName = UPPER(t.ObjectName), 
      t.ObjectType, 
      t.StartTime,
      DBType = CASE WHEN t.DatabaseID = 2 OR t.ObjectName LIKE N'#%' THEN 'tempdb'
                    WHEN t.DatabaseID IN (1,3,4)  THEN 'System database'
                    WHEN t.DatabaseID IS NOT NULL THEN 'User database' ELSE '?' END
    FROM filesrc CROSS APPLY sys.fn_trace_gettable(filesrc.[path], DEFAULT) AS t
    LEFT OUTER JOIN sys.trace_events AS e ON t.EventClass = e.trace_event_id
  ) AS src WHERE (EventSubClass IS NULL) 
           OR (EventSubClass = CASE WHEN DDL = 1 THEN 1 ELSE EventSubClass END) -- ddl_phase
)
SELECT [Instance] = @@SERVERNAME, 
       EventName,   
       Context, 
       EventCount = COUNT(*), 
       FirstSeen  = MIN(StartTime), 
       LastSeen   = MAX(StartTime) 
INTO #t FROM tracedata 
GROUP BY GROUPING SETS ((), (EventName, Context));

(Vị từ EventSubClass ở đó để ngăn việc đếm kép các sự kiện DDL.
Đối với bản đồ các giá trị EventClass, tôi đã liệt kê chúng trong câu trả lời này trên Stack Exchange.)

Và kết quả không đẹp (kết quả điển hình từ một máy chủ ngẫu nhiên). Phần sau không thể hiện kết quả chính xác của truy vấn đó, nhưng tôi đã dành một chút thời gian để tổng hợp kết quả thành một định dạng dễ hiểu hơn, để xem mức độ hữu ích của dữ liệu và mức độ nhiễu (nhấp để phóng to):

Hầu như tất cả tiếng ồn (99,94%). Điều hữu ích duy nhất mà chúng tôi cần từ dấu vết mặc định là các sự kiện tăng trưởng và thu nhỏ tệp, vì chúng là thứ duy nhất chúng tôi không nắm bắt ở nơi khác theo cách này hay cách khác. Nhưng ngay cả điều đó chúng ta không phải lúc nào cũng có thể dựa vào, bởi vì dữ liệu cuộn đi quá nhanh.

Một cách khác, tôi cắt dữ liệu:sự kiện cũ nhất cho mỗi trường hợp. Một số trường hợp có nhiều nhiễu đến mức chúng không thể giữ dữ liệu theo dõi mặc định trong hơn một vài phút! Tôi đã làm mờ tên máy chủ nhưng đây là dữ liệu thực (đây là 20 máy chủ có lịch sử ngắn nhất - nhấp để phóng to):

Ngay cả khi dấu vết đang thu thập chỉ thông tin liên quan và điều gì đó thú vị đã xảy ra, chúng tôi sẽ phải hành động nhanh chóng để nắm bắt thông tin đó, tùy thuộc vào máy chủ. Nếu nó xảy ra:

20 phút trước , sau đó nó sẽ biến mất trên 15 phiên bản .
giờ này hôm qua , nó sẽ biến mất trên 105 phiên bản .
hai ngày trước , nó sẽ biến mất trên 115 phiên bản .
hơn một tuần trước , nó sẽ biến mất trên 139 phiên bản .

Chúng tôi cũng có một số máy chủ ở đầu bên kia, nhưng chúng không quan tâm đến bối cảnh này; những máy chủ đó theo cách đó đơn giản vì không có gì thú vị xảy ra ở đó (ví dụ:chúng không bận hoặc là một phần của bất kỳ khối lượng công việc quan trọng nào).

Mặt khác…

Việc điều tra theo dõi mặc định đã phát hiện ra một số cấu hình sai trên một số máy chủ của chúng tôi:

Một số máy chủ vẫn được bật tính năng đo từ xa . Tôi là tất cả để giúp Microsoft trong một số môi trường nhất định, nhưng không phải trả bất kỳ chi phí nào trên các hệ thống quan trọng của doanh nghiệp.
Một số tác vụ đồng bộ hóa nền đã thêm thành viên vào các vai trò một cách mù quáng , lặp đi lặp lại, mà không kiểm tra xem họ đã ở những vai trò đó chưa. Điều này không có hại, đặc biệt là vì những sự kiện này sẽ không còn lấp đầy dấu vết mặc định nữa, nhưng chúng cũng có khả năng lấp đầy các cuộc kiểm toán với tiếng ồn và có thể có các hoạt động áp dụng lại mù khác xảy ra theo cùng một kiểu.
Ai đó đã bật chế độ tự động uống nước ở đâu đó (rất tiếc!), vì vậy đây là điều tôi muốn theo dõi và ngăn chặn điều này xảy ra lần nữa (XE mới cũng sẽ ghi lại những sự kiện này).

Điều này dẫn đến các nhiệm vụ tiếp theo để khắc phục những vấn đề này và / hoặc thêm các điều kiện để tự động hóa hiện tại đã được thực hiện. Vì vậy, chúng tôi có thể ngăn chặn sự tái diễn mà không cần chỉ dựa vào việc may mắn xảy ra với chúng trong một số lần xem xét theo dõi mặc định trong tương lai, trước khi chúng được triển khai.

… nhưng vấn đề vẫn còn

Nếu không, mọi thứ đều là thông tin mà chúng tôi không thể hành động hoặc, như được mô tả trong hình trên, là các sự kiện chúng tôi đã nắm bắt ở nơi khác. Và một lần nữa, dữ liệu duy nhất tôi quan tâm từ dấu vết mặc định mà chúng tôi chưa nắm bắt được bằng các phương tiện khác là các sự kiện liên quan đến tăng trưởng và thu nhỏ tệp (mặc dù dấu vết mặc định chỉ ghi lại nhiều loại tự động).

Nhưng vấn đề lớn hơn không thực sự là âm lượng của tiếng ồn. Tôi có thể xử lý các tệp theo dõi lớn với rất nhiều rác, vì mệnh đề WHERE được phát minh cho chính xác mục đích này. Vấn đề thực sự là các sự kiện quan trọng đã biến mất quá nhanh.

Câu trả lời

Câu trả lời, ít nhất trong kịch bản của chúng tôi, rất đơn giản:vô hiệu hóa theo dõi mặc định, vì nó không có giá trị chạy nếu không thể dựa vào nó.

Nhưng với số lượng tiếng ồn như trên, những gì nên thay thế nó? Có gì không?

Bạn có thể muốn một phiên Sự kiện mở rộng ghi lại mọi thứ dấu vết mặc định được ghi lại. Nếu vậy, Jonathan Kehayias sẽ giúp bạn. Điều này sẽ cung cấp cho bạn thông tin tương tự, nhưng với quyền kiểm soát những thứ như lưu giữ, nơi dữ liệu được lưu trữ và khi bạn cảm thấy thoải mái hơn, khả năng loại bỏ dần dần một số sự kiện ồn ào hơn hoặc ít hữu ích hơn theo thời gian.

Kế hoạch của tôi linh hoạt hơn một chút và nhanh chóng trở thành một quy trình "đơn giản" để thực hiện những điều sau trên tất cả các máy chủ trong môi trường (thông qua CMS):

phát triển phiên Sự kiện mở rộng chỉ ghi lại các sự kiện thay đổi tệp (cả thủ công và tự động)
vô hiệu hóa theo dõi mặc định
tạo một chế độ xem để giúp các nhóm của chúng tôi dễ dàng sử dụng dữ liệu mục tiêu

Lưu ý rằng Tôi không khuyên bạn vô hiệu hóa theo dõi mặc định một cách mù quáng , chỉ giải thích lý do tại sao tôi chọn làm như vậy trong môi trường của chúng tôi. Trong các bài đăng sắp tới của loạt bài này, tôi sẽ hiển thị phiên Sự kiện mở rộng mới, chế độ xem hiển thị dữ liệu cơ bản, mã tôi đã sử dụng để triển khai những thay đổi này cho tất cả các máy chủ và các tác dụng phụ tiềm ẩn mà bạn nên lưu ý.

[Phần 1 | Phần 2 | Phần 3]

Xóa dấu vết mặc định - Phần 1

Phân tích trạng thái hiện tại

Mặt khác…

… nhưng vấn đề vẫn còn

Câu trả lời