Sepanjang karir saya sebagai profesional data, baik di dalam Microsoft maupun sebagai konsultan, saya telah menemukan salah satu bagian yang paling disalahpahami dari database SQL Server adalah log transaksi. Kurangnya pengetahuan tentang bagaimana log transaksi bekerja dan perlu dikelola, atau hanya kesalahpahaman sederhana, dapat menyebabkan semua jenis masalah produksi, termasuk:
- Log transaksi tumbuh di luar kendali dan berpotensi kehabisan ruang
- Masalah kinerja karena penciutan berulang pada log transaksi
- Masalah kinerja dari masalah yang dikenal sebagai fragmentasi VLF , yang saya bahas di postingan ini
- Ketidakmampuan untuk memulihkan ke titik waktu yang diinginkan menggunakan cadangan log transaksi
- Ketidakmampuan untuk melakukan pencadangan tail-log selama pemulihan bencana (lihat di sini untuk penjelasan pencadangan tail-log)
- Berbagai masalah seputar failover dan pemulihan kinerja
Dengan posting ini, saya memulai seri sesekali pada log transaksi dan cara kerjanya dan harus dikelola, dan saya akan menyentuh semua masalah di atas selama ini. Dalam postingan ini, saya akan menjelaskan apa itu logging dan mengapa itu diperlukan.
Terminologi Dasar seputar Logging
Ketika saya berbicara tentang mekanisme apa pun di SQL Server, saya menemukan ada masalah ayam dan telur di mana saya perlu menggunakan kata atau frasa sebelum saya menjelaskannya. Untuk menghindari masalah itu dalam seri ini, saya akan mulai dengan menjelaskan beberapa terminologi yang perlu digunakan saat membahas logging, dan saya akan memperluas banyak istilah ini seiring berjalannya seri.
Transaksi, Komit, dan Kembalikan
Transaksi mencakup perubahan atau serangkaian perubahan ke database. Ia memiliki awal yang pasti dan akhir yang pasti. Permulaannya adalah ketika pernyataan TRANSAKSI BEGIN digunakan, atau SQL Server secara otomatis memulai transaksi untuk Anda. Akhir dapat menjadi salah satu dari empat hal:
- Transaksi dilakukan ketika pernyataan COMMIT TRANSACTION dijalankan
- Transaksi dilakukan ketika SQL Server secara otomatis melakukan transaksi dalam kasus transaksi komit otomatis
- Transaksi selesai bergulir kembali setelah pernyataan TRANSAKSI ROLLBACK dijalankan
- Transaksi selesai bergulir kembali setelah terjadi masalah, dan SQL Server secara otomatis membatalkan transaksi
Saat transaksi dilakukan, perubahan transaksi yang dibuat diselesaikan dalam database dan tahan lama di log transaksi SQL Server di disk. Perhatikan bahwa saya berkata, "di log transaksi." Perubahan aktual pada halaman file data di memori *tidak* ditulis ke disk saat transaksi dilakukan. Mereka tidak perlu dibuat tahan lama di file data karena perubahannya sudah tahan lama di log transaksi. Akhirnya, halaman file data akan ditulis ke disk melalui operasi pos pemeriksaan.
Sebaliknya, saat transaksi digulung kembali, data perubahan transaksi yang dilakukan tidak ada lagi di database. Masih akan ada beberapa perubahan fisik dalam database, karena mengembalikan transaksi berarti melakukan lebih banyak perubahan, tetapi Anda dapat menganggap transaksi yang dibatalkan tidak memengaruhi data dalam database.
Pos pemeriksaan dan operasi rollback adalah topik yang layak untuk posting mereka sendiri, jadi saya akan menjelaskannya nanti di seri ini.
Saya membahas ketiga istilah ini secara lebih mendalam dalam tutorial Pengantar Transaksi SQL Server di blog SentryOne.
Logging, Catatan Log, dan Log Transaksi SQL Server
Logging berarti membuat deskripsi yang tahan lama tentang perubahan ke database, hampir selalu dalam konteks transaksi. Ketika perubahan dibuat, perubahan dijelaskan dalam catatan log. Catatan log biasanya memiliki informasi yang cukup di dalamnya untuk memungkinkan perubahan diputar ulang di database atau diputar kembali di database jika diperlukan.
Catatan log ini awalnya akan berada di memori dan dapat ditulis ke disk sebelum transaksi dilakukan, tetapi pasti harus ditulis ke disk sebelum transaksi dapat selesai melakukan, jika tidak, transaksi tidak akan tahan lama. Pengecualian untuk aturan ini adalah ketika durabilitas tertunda fitur diaktifkan, yang dibahas Aaron Bertrand di pos ini.
Catatan log disimpan dalam log transaksi (satu atau lebih file log di disk), yang memiliki arsitektur internal yang agak rumit, dan saya akan membahasnya dan lebih banyak lagi tentang catatan log di posting berikutnya dalam seri ini.
Pemulihan Kerusakan
Crash adalah saat SQL Server dimatikan secara tidak terduga, dan berbagai database yang diubah tidak dapat dimatikan dengan benar (memastikan semua halaman file data yang diubah ditulis ke disk dan database ditandai sebagai dimatikan dengan bersih).
Ketika SQL Server dijalankan, ia memeriksa semua database untuk melihat apakah ada yang tidak ditandai sebagai dimatikan dengan bersih. Jika ditemukan, database itu harus melalui pemulihan kerusakan. Ini memastikan hal berikut:
- Untuk setiap transaksi yang dilakukan sebelum crash, pastikan semua perubahan dalam transaksi tercermin dalam database (yaitu, memutar ulang transaksi)
- Untuk setiap transaksi yang tidak dilakukan sebelum crash, pastikan tidak ada perubahan dalam transaksi yang tercermin dalam database (yaitu, roll back transaksi)
Dengan kata lain, pemulihan kerusakan membuat database konsisten secara transaksi sejak kecelakaan terjadi. Pemulihan kerusakan digunakan:
- Saat SQL Server memulai dan menemukan database yang perlu dipulihkan
- Selama failover ke salinan sekunder database
- Di akhir urutan pemulihan yang melibatkan pencadangan (lihat di sini)
Pemulihan kerusakan adalah proses yang kompleks dan memerlukan beberapa postingan lagi dalam seri ini sebelum saya dapat menjelaskannya secara mendalam.
Mengapa Pencatatan Diperlukan?
Alasan paling dasar untuk logging adalah untuk memungkinkan database SQL Server membuat transaksi tahan lama, sehingga mereka dapat dipulihkan selama pemulihan kerusakan atau dibatalkan jika diperlukan selama operasi database normal. Jika tidak ada logging, database akan menjadi tidak konsisten secara transaksi dan mungkin secara struktural rusak setelah crash.
Tanpa logging, sejumlah fitur lain di SQL Server tidak akan mungkin, termasuk:
- Cadangan data yang dapat dipulihkan secara konsisten
- Cadangan log transaksi SQL Server yang dapat digunakan selama operasi pemulihan dan untuk mengimplementasikan pengiriman log
- Replikasi, yang mengandalkan kemampuan untuk memanen transaksi dari log transaksi
- Ubah Pengambilan Data, yang menggunakan Agen Pembaca Log replikasi transaksional untuk mengumpulkan perubahan dari log transaksi
- Grup pencerminan dan ketersediaan basis data, yang mengandalkan pengiriman catatan log ke salinan sekunder basis data untuk diputar ulang
SQL Server (dan semua server database serupa) menggunakan apa yang disebut write-ahead logging . Ini berarti deskripsi perubahan harus ditulis ke disk sebelum perubahan itu sendiri untuk menjamin kemampuan memulihkan database secara crash dengan benar. Jika perubahan ditulis ke file data sebelum catatan log menjelaskannya, dan SQL Server macet, tidak akan ada cara untuk mengetahui apa yang harus diputar kembali, dan database akan menjadi tidak konsisten. Pemesanan ini bersifat invarian, terlepas dari tingkat isolasi, jenis transaksi, atau apakah fitur durabilitas tertunda digunakan. Catat catatan terlebih dahulu, halaman data kemudian.
Hanya Puncak Gunung Es
Seperti yang Anda lihat dari posting pengantar ini, sejumlah besar masuk ke log transaksi dan masuk ke database SQL Server, dan semua yang telah saya lakukan sejauh ini adalah mendefinisikan beberapa terminologi tingkat tinggi dan menjelaskan mengapa logging diperlukan. Saya harap Anda akan bergabung dengan saya saat saya berkembang dan masuk lebih dalam seiring berjalannya seri!
