Pemeriksaan Kesehatan SQL Server Proaktif, Bagian 4:ERRORLOG

Ada begitu banyak yang dapat Anda katakan tentang sejarah dan pentingnya. Sejarah suatu negara, peradaban, kita masing-masing. Saya suka kutipan dan menyukai kutipan ini dari Teddy Roosevelt (pria keren):

Mengapa saya menulis puisi (atau mencoba) tentang sejarah di blog tentang SQL Server? Karena sejarah di SQL Server juga penting. Ketika ada masalah kinerja di SQL Server, sangat ideal untuk memecahkan masalah secara langsung, tetapi dalam beberapa kasus, informasi historis dapat memberikan senjata api, atau setidaknya titik awal. Sumber informasi historis yang bagus di SQL Server adalah ERRORLOG. Saya menyebutkan dalam posting asli saya, Masalah Kinerja:Pertemuan Pertama, bahwa ERRORLOG dulunya merupakan renungan bagi saya. Tidak lagi. Selama audit klien, kami selalu menangkap ERRORLOG, dan sementara kami diberi tahu untuk setiap peringatan tingkat keparahan tinggi (yang ditulis ke log), tidak jarang ditemukan informasi menarik lainnya di log. Kami mempersiapkan masa depan dengan menggunakan info historis di log; informasi tersebut dapat membantu kami memperbaiki masalah, atau potensi masalah, sebelum menjadi bencana besar.

Melihat ERRORLOG

Pertama, kami akan meninjau beberapa opsi untuk melihat ERROLOG. Jika saya terhubung ke sebuah instance, saya biasanya akan menavigasi ke sana melalui SSMS (Management | SQL Server Logs, klik kanan pada log, dan pilih View SQL Server Log). Dari jendela ini saya bisa menggulir log, atau menggunakan opsi Filter atau Pencarian untuk mempersempit kumpulan hasil. Saya juga dapat melihat banyak file dengan memilihnya di panel sebelah kiri.

Jika saya melihat data yang diambil dalam salah satu audit kesehatan kami, saya hanya akan membuka file log di editor teks dan meninjaunya (saya memiliki opsi untuk masuk ke penampil dan memuatnya juga). File log ada di folder log (lokasi default:C:\Program Files\Microsoft SQL Server\MSSQL12.SQL2014\MSSQL\Log) jika saya ingin melihatnya di server. Banyak dari Anda mungkin lebih suka melihat dan/atau mencari log menggunakan sp_readerrorlog prosedur tidak berdokumen atau prosedur tersimpan diperpanjang xp_readerrorlog.

Dan akhirnya, jika Anda semua menyukai PowerShell, itu juga merupakan opsi untuk membaca log seperti itu (lihat posting ini:Gunakan PowerShell untuk Mengurai Log Kesalahan SQL Server 2012). Metodenya terserah Anda – gunakan apa yang Anda ketahui dan apa yang cocok untuk Anda – kontenlah yang benar-benar penting. Dan ingat bahwa ada saat-saat di mana Anda hanya perlu membaca log untuk memahami urutan peristiwa, dan ada saat-saat lain di mana Anda mungkin mencari untuk menemukan kesalahan atau informasi tertentu.

Apa yang ada di ERRORLOG?

Jadi informasi apa yang bisa kita temukan di ERRORLOG, selain kesalahan? Saya telah mencantumkan banyak item yang menurut saya paling berguna di bawah ini. Perhatikan bahwa ini bukan daftar yang lengkap (dan saya yakin banyak dari Anda akan memiliki saran tentang apa yang dapat ditambahkan – jangan ragu untuk mengirim komentar dan saya dapat memperbarui ini!), tetapi sekali lagi, inilah yang saya mencari pertama ketika saya secara proaktif melihat sebuah instance.

• Apakah servernya fisik atau virtual (cari entri Produsen Sistem)
• Tanda pelacakan diaktifkan saat startup
  • Dalam entri untuk parameter startup Registry, jika Anda menggulir ke kanan, Anda akan melihat apakah ada tanda jejak yang diaktifkan:
    
    Tanda Pelacakan diaktifkan saat startup
• Tanda pelacakan diaktifkan atau dinonaktifkan setelah instance dimulai
  • Jika pengguna (atau aplikasi) mengaktifkan atau menonaktifkan tanda pelacakan menggunakan DBCC TRACEON atau DBCC TRACEOFF, entri akan muncul di log
• Jumlah inti dan soket yang terdeteksi oleh SQL Server
  • Saya selalu ingin memverifikasi bahwa SQL Server melihat semua perangkat keras yang tersedia – dan jika tidak, itu adalah tanda bahaya untuk diselidiki lebih lanjut. Untuk contoh yang baik, lihat posting Jonathan, Masalah Kinerja dengan SQL Server 0212 Enterprise Edition Di Bawah Lisensi CAL, dan posting Glenn, Menyeimbangkan Lisensi Inti SQL Server yang Tersedia Secara Merata di NUMA Nodes, yang juga menyertakan beberapa TSQL praktis untuk menanyakan log.
  • Perhatikan bahwa teks untuk entri ini bervariasi antara versi SQL Server.
• Jumlah memori yang terdeteksi oleh SQL Server
  • Sekali lagi, saya ingin memverifikasi bahwa SQL Server melihat semua memori yang tersedia untuknya.
• Konfirmasi bahwa Halaman Terkunci di Memori (LPIM) diaktifkan
  • Meskipun opsi ini diaktifkan melalui Kebijakan Keamanan Windows, Anda dapat mengonfirmasi bahwa opsi ini diaktifkan dengan mencari pesan "Menggunakan halaman terkunci di pengelola memori" di log.
  • Perhatikan bahwa jika Anda menggunakan Trace Flag 834, pesan tidak akan mengatakan halaman terkunci, melainkan halaman besar sedang digunakan untuk kumpulan buffer.
• Versi CLR sedang digunakan
• Berhasil atau gagalnya pendaftaran Service Principal Name (SPN)
• Berapa lama waktu yang dibutuhkan database untuk online
  • Catatan log saat database dimulai, dan saat online – saya memeriksa untuk melihat apakah database membutuhkan waktu yang terlalu lama untuk muncul.
• Endpoint Status Broker Layanan dan Pencerminan Basis Data – penting jika Anda menggunakan salah satu fitur
• Konfirmasi bahwa Inisialisasi File Instan (IFI) diaktifkan*
  • Secara default, informasi ini tidak dicatat, tetapi jika Anda mengaktifkan Trace Flag 3004 (dan 3605 untuk memaksa output ke log), saat Anda membuat atau mengembangkan file data, Anda akan melihat pesan di log untuk menunjukkan apakah IFI sedang digunakan atau tidak.
• Status Pelacakan SQL
  • Ketika Anda memulai atau menghentikan Pelacakan SQL, itu akan dicatat, dan saya melihat apakah ada jejak di luar jejak default yang ada (baik untuk sementara atau jangka panjang). Jika Anda menjalankan alat pemantauan pihak ketiga, seperti Performance Advisor SQL Sentry, Anda mungkin melihat pelacakan aktif yang selalu berjalan, tetapi hanya merekam peristiwa tertentu, atau Anda mungkin melihat pelacakan dimulai, berjalan dalam durasi singkat, lalu berhenti. Saya tidak peduli dengan satu atau dua jejak tambahan, kecuali jika mereka merekam banyak peristiwa, tapi saya pasti memperhatikan saat banyak jejak berjalan.
• Terakhir kali CHECKDB selesai
  • Pesan ini sering disalahpahami oleh orang-orang – saat instance dijalankan, ia membaca halaman boot untuk setiap database dan mencatat saat CHECKDB terakhir kali berhasil dijalankan. Kebanyakan orang tidak membaca keseluruhan pesan:
    
    Tanggal DBCC CHECKDB terakhir berhasil diselesaikan

    Tanggal penyelesaian CHECKDB adalah 11 November 2012, tetapi tanggal ERRORLOG adalah 7 Juli 2015. Penting untuk dipahami bahwa SQL Server tidak jalankan CHECKDB terhadap database saat startup, ia memeriksa nilai dbcclastknowngood pada halaman boot (untuk melihat kapan itu diperbarui, lihat posting saya, Apa yang Memeriksa Pembaruan dbcclastknowngood. Juga, jika DBCC CHECKDB tidak pernah dijalankan terhadap database, maka tidak ada entri akan muncul untuk database di sini.

• CHECKDB selesai
  • Saat CHECKDB dijalankan terhadap database, output dicatat dalam log.
• Perubahan pada pengaturan instance
  • Jika Anda mengubah setelan tingkat instans (mis. memori server maksimal, ambang biaya untuk paralelisme) menggunakan sp_configure atau melalui UI (perhatikan bahwa ini tidak mencatat siapa mengubahnya).

• Perubahan pada pengaturan basis data
  • Apakah seseorang mengaktifkan AUTO_SHRINK? Ubah opsi PEMULIHAN ke SEDERHANA lalu kembali ke PENUH? Anda akan menemukannya di sini.
• Perubahan status basis data
  • Jika seseorang mengambil database OFFLINE (atau membawanya ONLINE), ini akan dicatat.
• Informasi kebuntuan*
  • Jika Anda perlu menangkap informasi kebuntuan, tidak ingin menjalankan jejak, dan Anda menjalankan SQL Server 2005 hingga 2008R2, gunakan trace flag 1222 untuk menulis informasi kebuntuan ke log dalam format XML. Bagi Anda yang menggunakan SQL Server 2000 dan di bawahnya, Anda dapat melacak bendera 1204 (tanda jejak ini juga tersedia di SQL Server 2005+, tetapi mengeluarkan informasi minimal). Jika Anda menjalankan SQL Server 2012 atau lebih tinggi, ini tidak diperlukan, karena sesi acara system_health menangkap informasi ini (dan itu juga ada di 2008 dan 20082, tetapi Anda harus menariknya dari ring_buffer versus target event_file).
• Pesan FlushCache
  • Jika cache sedang dihapus oleh SQL Server karena proses pos pemeriksaan melebihi interval pemulihan untuk database, Anda akan melihat serangkaian pesan FlushCache di log (lihat posting ini oleh Bob Dorr untuk informasi selengkapnya). Jangan bingung pesan ini dengan yang muncul saat Anda menjalankan DBCC FREEPROCCACHE atau DBCC FREESYSTEMCACHE:
    
    Pesan setelah menjalankan DBCC FREEPROCCACHE atau DBCC FREESYSTEMCACHE

• AppDomain membongkar pesan
  • Log juga mencatat saat AppDomains dibuat, dan Anda hanya akan melihatnya jika menggunakan CLR. Jika saya melihat AppDomain membongkar pesan karena tekanan memori, itu adalah sesuatu untuk diselidiki lebih lanjut.

Ada informasi lain di log yang berguna, seperti mode otentikasi yang digunakan, apakah Koneksi Admin Khusus (DAC) diaktifkan atau tidak, dll. tetapi saya juga bisa mendapatkannya dari sys.configurations dan saya memeriksanya dengan baseline instance Saya telah membahas sebelumnya (Pemeriksaan Kesehatan SQL Server Proaktif, Bagian 3:Pengaturan Instans dan Basis Data).

Apa yang tidak ada di ERROLOG, yang mungkin Anda harapkan?

Ini adalah daftar singkat, untuk saat ini, karena saya menduga beberapa dari Anda mungkin telah menemukan hal-hal lain yang Anda pikir akan ada di log tetapi tidak…

• Menambahkan atau menghapus file database atau grup file
• Memulai atau menghentikan Sesi Acara yang Diperpanjang
  • Namun, jika Anda menerapkan Pemicu DDL atau Pemberitahuan Peristiwa tingkat server, Anda dapat mencatat informasi ini. Lihat postingan Jonathan, Logging Perubahan Acara yang Diperpanjang ke ERRORLOG, untuk detail lebih lanjut.
• Menjalankan DBCC DROPCLEANBUFFERS memang muncul di ERRORLOG

Mengelola Log

Ingatlah bahwa secara default, SQL Server hanya menyimpan enam (6) file log terbaru (selain file saat ini), dan file log bergulir setiap kali SQL Server dimulai ulang. Akibatnya, terkadang Anda dapat memiliki file log yang sangat besar yang membutuhkan waktu lama untuk dibuka dan sulit untuk digali. Di sisi lain, jika Anda mengalami kasus di mana instance dimulai ulang beberapa kali, Anda mungkin kehilangan informasi penting. Direkomendasikan untuk menambah jumlah file yang disimpan ke nilai yang lebih tinggi (misalnya 30), dan membuat tugas Agen untuk menggulung file seminggu sekali menggunakan sp_cycle_errorlog.

Selain mengelola file, Anda dapat memengaruhi informasi apa yang ditulis ke log. Salah satu entri paling umum yang membuat kekacauan di ERRORLOG adalah entri pencadangan yang berhasil:

Pencadangan berhasil diselesaikan

Jika Anda memiliki instans dengan banyak basis data dan pencadangan log transaksi dilakukan dengan keteraturan apa pun (misalnya setiap 15 menit), Anda akan melihat log dengan cepat terisi dengan pesan, yang membuat pencarian masalah sebenarnya menjadi lebih sulit. Untungnya, Anda dapat menggunakan trace flag 3226 untuk menonaktifkan pesan pencadangan yang berhasil (kesalahan akan tetap muncul di log, dan semua entri akan tetap ada di msdb).

Kumpulan pesan lain yang mengacaukan log adalah pesan login yang berhasil. Ini adalah opsi yang Anda konfigurasikan untuk instans pada tab Keamanan:

Opsi keamanan untuk mencatat login yang berhasil dan/atau gagal

Jika Anda mencatat login yang berhasil, atau login yang gagal dan berhasil, Anda dapat memiliki file log yang sangat besar, bahkan jika Anda memutar file setiap hari (itu akan tergantung pada berapa banyak pengguna yang terhubung). Saya sarankan menangkap login yang gagal saja. Untuk bisnis yang memiliki persyaratan untuk mencatat login yang berhasil, pertimbangkan untuk menggunakan fitur Audit, ditambahkan di SQL Server 2008. Catatan tambahan:Jika Anda mengubah pengaturan Audit login, itu tidak akan berlaku sampai Anda memulai ulang instans.

Jangan meremehkan ERRORLOG

Seperti yang Anda lihat, ada beberapa informasi hebat di ERRORLOG untuk Anda gunakan tidak hanya saat Anda memecahkan masalah kinerja atau menyelidiki kesalahan, tetapi juga saat Anda secara proaktif memantau sebuah instance. Anda dapat menemukan informasi di log yang tidak ditemukan di tempat lain; pastikan Anda memeriksanya secara teratur dan tidak mengabaikannya.

Lihat bagian lain dalam seri ini:

• Bagian 1 :Ruang Disk
• Bagian 2 :Pemeliharaan
• Bagian 3 :Instance dan Pengaturan Basis Data