Menghapus jejak default – Bagian 1

[ Bagian 1 | Bagian 2 | Bagian 3 ]

Dalam semangat kata-kata kasar Grant Fritchey baru-baru ini, dan upaya Erin Stellato sejak saya pikir sebelum kami bertemu, saya ingin ikut-ikutan untuk terompet dan mempromosikan gagasan menghilangkan jejak demi Acara yang Diperpanjang. Saat seseorang mengatakan jejak , kebanyakan orang langsung berpikir Profiler . Sementara Profiler adalah mimpi buruknya sendiri, hari ini saya ingin berbicara tentang jejak default SQL Server.

Di lingkungan kami, ini diaktifkan di semua 200+ server produksi, dan mengumpulkan banyak sampah yang tidak akan pernah kami selidiki. Begitu banyak sampah, pada kenyataannya, peristiwa penting yang mungkin berguna bagi kami untuk memecahkan masalah peluncuran file jejak sebelum kami mendapatkan kesempatan. Jadi saya mulai mempertimbangkan prospek untuk mematikannya, karena:

• ini tidak gratis (overhead pengamat dari aktivitas pelacakan itu sendiri, I/O yang terlibat dengan penulisan ke file pelacakan, dan ruang yang mereka konsumsi);
• di sebagian besar server, tidak pernah dilihat; pada orang lain, jarang; dan,
• mudah untuk mengaktifkan kembali untuk pemecahan masalah khusus dan terisolasi.

Beberapa hal lain mempengaruhi nilai jejak default. Ini tidak dapat dikonfigurasi dengan cara apa pun — Anda tidak dapat mengubah acara mana yang dikumpulkannya, Anda tidak dapat menambahkan filter, dan Anda tidak dapat mengontrol berapa banyak file yang disimpan (5), seberapa besar yang dapat diperoleh (masing-masing 20 MB) , atau di mana mereka disimpan (SERVERPROPERTY('ErrorLogFileName') ). Jadi, kami sepenuhnya bergantung pada beban kerja — di server mana pun, kami tidak dapat memprediksi seberapa jauh data akan berjalan (peristiwa dengan TextData yang lebih besar) nilai, misalnya, dapat mengambil lebih banyak ruang, dan mendorong acara lama lebih cepat). Terkadang bisa kembali seminggu, di lain waktu bisa kembali hanya beberapa menit.

Menganalisis Status Saat Ini

Saya menjalankan kode berikut terhadap 224 instance produksi, hanya untuk memahami jenis kebisingan apa yang mengisi jejak default di seluruh lingkungan kita. Ini mungkin lebih rumit dari yang seharusnya, dan bahkan tidak serumit kueri terakhir yang saya gunakan, tetapi ini adalah titik awal yang layak untuk menganalisis perincian jenis peristiwa tingkat tinggi yang sedang direkam:

;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));

Dan hasilnya tidak cantik (khas hasil dari server acak). Berikut ini tidak mewakili keluaran persis dari kueri tersebut, tetapi saya menghabiskan beberapa waktu untuk menggabungkan hasilnya ke dalam format yang lebih mudah dicerna, untuk melihat seberapa banyak data yang berguna dan seberapa banyak noise (klik untuk memperbesar):

Hampir semua kebisingan (99,94%). Satu-satunya hal berguna yang kami butuhkan dari pelacakan default adalah pertumbuhan file dan peristiwa menyusut, karena itu adalah satu-satunya hal yang tidak kami tangkap di tempat lain dengan satu atau lain cara. Tetapi bahkan itu tidak selalu dapat kami andalkan, karena data bergulir begitu cepat.

Cara lain saya memotong data:acara terlama per instance. Beberapa instance memiliki begitu banyak noise sehingga mereka tidak dapat menyimpan data pelacakan default selama lebih dari beberapa menit! Saya mengaburkan nama server tetapi ini adalah data nyata (ini adalah 20 server dengan riwayat terpendek – klik untuk memperbesar):

Bahkan jika jejak itu mengumpulkan hanya info yang relevan, dan sesuatu yang menarik terjadi, kita harus bertindak cepat untuk menangkapnya, tergantung pada server. Jika itu terjadi:

• 20 menit yang lalu , maka itu akan hilang pada 15 kali .
• kali ini kemarin , itu akan hilang pada 105 kali .
• dua hari yang lalu , itu akan hilang pada 115 kali .
• lebih dari seminggu yang lalu , itu akan hilang pada 139 kali .

Kami juga memiliki beberapa server di ujung yang lain, tetapi mereka tidak menarik dalam konteks ini; server tersebut seperti itu hanya karena tidak ada hal menarik yang terjadi di sana (mis. mereka tidak sibuk atau bagian dari beban kerja penting).

Di sisi positifnya…

Menyelidiki jejak default memang mengungkapkan beberapa kesalahan konfigurasi pada beberapa server kami:

• Beberapa server masih telemetri diaktifkan . Saya siap membantu Microsoft di lingkungan tertentu, tetapi tidak dengan biaya tambahan apa pun pada sistem penting bisnis.
• Beberapa tugas sinkronisasi latar belakang adalah menambahkan anggota ke peran secara membabi buta , berulang-ulang, tanpa memeriksa apakah mereka sudah dalam peran tersebut. Ini tidak berbahaya, terutama karena peristiwa ini tidak lagi mengisi jejak default, tetapi kemungkinan besar juga memenuhi audit dengan kebisingan, dan mungkin ada operasi penerapan ulang buta lainnya yang terjadi dalam pola yang sama.
• Seseorang telah mengaktifkan penyusutan otomatis di suatu tempat (astaga!), jadi ini adalah sesuatu yang ingin saya lacak dan cegah agar tidak terjadi lagi (XE baru juga akan merekam peristiwa ini).

Hal ini menyebabkan tugas tindak lanjut untuk memperbaiki masalah ini dan/atau menambahkan kondisi ke otomatisasi yang sudah ada. Jadi kami dapat mencegah pengulangan tanpa hanya mengandalkan keberuntungan yang terjadi pada mereka di beberapa tinjauan pelacakan default di masa mendatang, sebelum diluncurkan.

…tapi masalahnya tetap ada

Jika tidak, semuanya adalah informasi yang tidak dapat kami tindak lanjuti atau, seperti yang dijelaskan dalam grafik di atas, peristiwa yang telah kami tangkap di tempat lain. Dan lagi, satu-satunya data yang saya minati dari jejak default yang belum kita tangkap dengan cara lain adalah peristiwa yang berkaitan dengan pertumbuhan dan penyusutan file (meskipun pelacakan default hanya menangkap variasi otomatis).

Tetapi masalah yang lebih besar sebenarnya bukanlah volume kebisingan. Saya dapat menangani file jejak besar yang besar dengan banyak sampah, karena klausa WHERE diciptakan untuk tujuan ini. Masalah sebenarnya adalah bahwa peristiwa penting menghilang terlalu cepat.

Jawabannya

Jawabannya, setidaknya dalam skenario kami, sederhana:nonaktifkan jejak default, karena tidak layak dijalankan jika tidak dapat diandalkan.

Tapi mengingat jumlah noise di atas, apa yang harus menggantikannya? Apa saja?

Anda mungkin menginginkan sesi Acara yang Diperpanjang yang merekam semuanya jejak default ditangkap. Jika demikian, Jonathan Kehayias telah membantu Anda. Ini akan memberi Anda informasi yang sama, tetapi dengan kontrol atas hal-hal seperti retensi, tempat data disimpan, dan, saat Anda merasa lebih nyaman, kemampuan untuk menghapus beberapa peristiwa yang lebih mengganggu atau kurang berguna, secara bertahap, seiring waktu.

Rencana saya sedikit lebih agresif, dan dengan cepat menjadi proses "sederhana" untuk melakukan hal berikut di semua server di lingkungan (melalui CMS):

1. mengembangkan sesi Peristiwa yang Diperpanjang yang hanya merekam peristiwa perubahan file (baik manual maupun otomatis)
2. nonaktifkan jejak default
3. buat tampilan untuk memudahkan tim kami menggunakan data target

Perhatikan bahwa Saya tidak menyarankan Anda untuk menonaktifkan jejak default secara membabi buta , hanya menjelaskan mengapa saya memilih untuk melakukannya di lingkungan kita. Dalam posting mendatang dalam seri ini, saya akan menunjukkan sesi Acara Perpanjangan baru, tampilan yang memperlihatkan data yang mendasarinya, kode yang saya gunakan untuk menerapkan perubahan ini ke semua server, dan potensi efek samping yang harus Anda ingat.

[ Bagian 1 | Bagian 2 | Bagian 3 ]