Log Transaksi SQL Server

Setiap database SQL Server berisi satu atau lebih file log transaksi selain file data. File log merekam semua transaksi dan modifikasi basis data yang dibuat oleh masing-masing transaksi.

Artikel ini berfokus pada log transaksi dan bagaimana SQL Server mencatat modifikasi data untuk menggunakan data untuk pemulihan kerusakan database.

Pengantar File Log Transaksi SQL Server

Seperti yang kita ingat, setiap transaksi adalah "semua atau tidak sama sekali". Jika sebagian transaksi gagal, seluruh transaksi gagal, dan status basis data tetap tidak berubah.

SQL Server menyimpan catatan setiap transaksi yang dilakukan pada database ke dalam file log. Jika beberapa bencana memerlukan shutdown SQL Server, ia menggunakan log transaksi untuk memulihkan database ke status yang konsisten dengan integritas data.

Setelah restart, SQL Server memulai proses pemulihan crash. Ia membaca file log transaksi untuk memastikan bahwa semua data yang valid disimpan dalam file data, dan transaksi yang tidak terikat dibatalkan.

Selama operasi normal, SQL Server menggunakan log transaksi juga. Informasi yang terkandung dalam file diperlukan untuk mengidentifikasi apa yang perlu dilakukan SQL Server saat transaksi dibatalkan karena kesalahan atau pernyataan ROLLBACK yang ditentukan pengguna.

Bagaimana SQL Server Menggunakan Log Transaksi

Log transaksi adalah file fisik dengan ekstensi LDF . SQL Server membuatnya secara otomatis untuk database baru apa pun bersama dengan file data utama (.MDF ) yang menyimpan objek database dan data itu sendiri.

Setiap kali kode T-SQL mengubah objek database atau data yang ada di dalamnya, detail perubahan dicatat sebagai catatan log dalam file log transaksi.

Catatan log berisi informasi tentang perubahan spesifik yang dibuat ke database (misalnya, menyisipkan satu baris). Oleh karena itu, kami akan memiliki serangkaian catatan log untuk menggambarkan efek dari satu transaksi secara penuh.

Arsitektur Log Transaksi

Log Nomor Urutan

Catatan log memiliki Nomor Urutan Log yang unik dan meningkat secara otomatis (LSN ), yang memungkinkan kami menemukan catatan ini di log transaksi. LSN menjelaskan perubahan data dan berisi informasi berikut:

operasi dan baris yang terpengaruh
data versi lama dan baru
transaksi yang melakukan modifikasi

LSN terdiri dari tiga angka:

LSN =::

Setiap halaman file data memiliki LSN di header halamannya yang mengidentifikasi catatan log terbaru yang perubahannya tercermin pada halaman. Ini sangat penting untuk pemulihan kerusakan.

Saat pemulihan kerusakan berjalan, ini membandingkan LSN catatan log untuk transaksi yang dilakukan atau tidak dikomit dengan LSN di halaman file data untuk menentukan apakah ada pengulangan atau pembatalan yang harus dilakukan pada catatan log tertentu.

Saat Anda membuat database, praktik yang baik adalah menentukan ukuran log transaksi . Jika Anda tidak melakukannya, SQL Server akan secara otomatis membuat log transaksi dengan ukuran default.

Ukuran default log transaksi database baru lebih besar dari 0,5MB atau 25% dari ukuran total semua file data yang dibuat dalam pernyataan CREATE DATABASE yang sama.

Anda harus sangat berhati-hati karena bagian baru dari log transaksi selalu diinisialisasi nol . Jika Anda memiliki pernyataan CREATE DATABASE tanpa menentukan ukuran file log, dan Anda membuat, misalnya, database 1 TB, SQL Server akan membuat log transaksi 250 GB.

Karena log harus diinisialisasi nol, log tidak menggunakan inisialisasi file instan. Fitur ini ditambahkan di SQL Server 2005 untuk memungkinkan file data dibuat atau dikembangkan hampir secara instan.

Kita dapat melihat apa yang terjadi ketika kita MEMBUAT DATABASE – inisialisasi nol terjadi pada log kita menggunakan trace flag 3004 yang mencetak pesan tentang inisialisasi nol dan trace flag 3605 yang memungkinkan untuk mencetak pesan log tersebut dengan tanda pelacakan 3004.

Demo berikut menunjukkan bagaimana Anda dapat melihat file log zeroing terjadi.

1. Jalankan script berikut untuk memastikan bahwa kita tidak memiliki database bernama DBTest2014

USE master;
GO
 
IF DATABASEPROPERTY(N'DBTest2014', N'Version')>0
  BEGIN
    ALTER DATABASE DBTest2014 SET SINGLE_USER
      WITH ROLLBACK IMMEDIATE;
    DROP DATABASE DBTest2014;
  END
GO

2. Aktifkan tanda pelacakan untuk menonton inisialisasi nol

DBCC TRACEON (3605, 3004, -1);
GO
3. Flush the error log
EXEC sp_cycle_errorlog;
GO

3. Buat database

CREATE DATABASE DBTest2014 ON PRIMARY (
  NAME = N'DBTest2014',
  FILENAME = N'D:\DBTest2014_data.mdf')
LOG ON (
  NAME= N'DBTest2014_log',
  FILENAME= N'D:\DBTest2014_log.ldf',
  SIZE = 10MB,
  FILEGROWTH = 10 MB);
GO

4. Baca file log kesalahan

EXEC sys.xp_readerrorlog;
GO

File Log Virtual

Log transaksi dibagi secara internal menjadi serangkaian potongan yang disebut file log virtual (VLF ) untuk menyederhanakan pengelolaan.

Setiap kali log transaksi dibuat, ia memberikan sejumlah VLF tertentu. VLF yang baru dibuat tidak aktif dan tidak digunakan. VLF aktif tidak dapat digunakan kembali sampai dibuat tidak aktif dengan pembersihan log.

Namun, ada satu pengecualian – VLF pertama dalam database baru selalu aktif karena setiap log transaksi harus memiliki setidaknya satu VLF aktif.

Setiap file log juga memiliki halaman header file yang membutuhkan 8 KB di awal file log transaksi. Halaman header file menyimpan metadata tentang file seperti ukuran dan pengaturan pertumbuhan otomatis.

Jumlah dan ukuran VLF di bagian baru dari log transaksi ditentukan oleh SQL Server. Tidak mungkin untuk mengonfigurasinya.

Jika ukuran yang baru ditambahkan adalah:

<1MB tidak relevan untuk diskusi
<64MB akan ada 4 VLF baru (masing-masing 1/4 dari ukuran pertumbuhan)
64MB hingga 1GB akan ada 8 VLF baru (masing-masing 1/8 dari ukuran pertumbuhan)
> 1 GB akan ada 16 VLF baru (masing-masing 1/16 dari ukuran pertumbuhan)

Ini berlaku untuk log transaksi yang dibuat pertama kali dan untuk setiap pertumbuhan manual atau otomatis yang terjadi. Ketika Anda mengetahui rumus jumlah potensial VLF dan ukuran potensialnya, ada baiknya mengelola log. Terlalu sedikit atau terlalu banyak VLF dapat menyebabkan masalah kinerja dengan operasi log transaksi.

Nomor Urutan VLF

Setiap VLF memiliki nomor urut untuk secara unik mengidentifikasi VLF dalam log transaksi. Nomor urut bertambah satu setiap kali sistem manajemen log mengaktifkan VLF berikutnya. Rantai nomor urut memberikan set VLF yang aktif saat ini.

Awal dari bagian aktif log transaksi dimulai dengan VLF yang memiliki nomor urut terendah dan masih aktif. VLF tidak aktif memiliki nomor urut, tetapi bukan bagian dari bagian log aktif.

Bagian aktif dari log memiliki catatan log yang diperlukan untuk beberapa alasan oleh SQL Server.

Saat Anda pertama kali membuat database baru, nomor urut VLF tidak akan dimulai dari 1. Nomor urut ini dimulai dengan nomor urut VLF tertinggi dalam log transaksi database model, ditambah 1 . Tidak mungkin kehabisan nomor urut VLF. SQL Server memiliki kode yang akan memaksa instans untuk dimatikan jika nomor urut VLF pernah mendekati nol (jika nomor urut VLF berikutnya lebih kecil dari yang sebelumnya).

VLF dan Blok Log

Di dalam VLF, ada blok log berukuran bervariasi. Ukuran minimum blok log adalah 512 byte dan blok log bertambah hingga ukuran maksimum 60 KB . Ukuran diatur ketika salah satu kasus berikut terjadi:

Sebuah transaksi menghasilkan catatan log untuk melakukan penyelesaian pembatalan transaksi
Ukuran blok log mencapai 60KB tanpa melakukan atau membatalkan transaksi

Ada catatan log di dalam blok log (berwarna pada diagram). Catatan log juga berukuran bervariasi. Diagram menunjukkan bahwa catatan log dari beberapa transaksi bersamaan dapat ada dalam blok log yang sama. Catatan log disimpan dalam urutan yang ditulis mirip dengan file halaman data.

Setiap VLF berisi header VLF dengan informasi berikut:

Apakah VLF aktif atau tidak.
Nomor urut log saat VLF dibuat.
Bit paritas saat ini untuk semua blok 512-byte di VLF.

Bit paritas mulai dari 64 untuk pertama kali penggunaan VLF. Jika VLF menjadi tidak aktif, tetapi diaktifkan kembali lebih lanjut, bit paritas akan menjadi 128. Ini digunakan selama pemulihan kerusakan.

Memeriksa detail log transaksi – DBCC LOGINFO

Satu-satunya cara untuk melihat struktur log transaksi adalah dengan menggunakan DBCC LOGINFO yang tidak berdokumen. memerintah. Sintaks untuk perintahnya adalah:

DBCC LOGINFO [({'dbname | dbid'})]

Jika Anda tidak menentukan dbname dan menawar , itu akan membuang Anda konten log untuk database saat ini.

Hasilnya adalah satu baris untuk setiap VLF yang ada di log transaksi untuk database itu. Kolom yang dikembalikan adalah:

RecoveryUnitId — ditambahkan di SQL Server 2012 tetapi saat ini tidak digunakan
Id File — ID file log transaksi dalam database.
Ukuran File — Ukuran VLF dalam byte.
MulaiOffset — mulai offset VLF dalam file log transaksi, dalam byte
FSeqNo — Nomor urut VLF
Status — Apakah VLF aktif atau tidak (0 =tidak aktif, 2 =aktif, 1 – tidak digunakan)
Paritas — bit paritas saat ini (64 atau 128, atau 0 jika VLF tidak pernah aktif)
BuatLSN — LSN saat VLF dibuat (0 =VLF dibuat saat file log transaksi pertama kali dibuat). Semua VLF lain yang ditambahkan setelah pembuatan awal file log transaksi akan memiliki CreateLSN bukan nol.

Kita dapat menjalankan perintah berikut untuk DBTest2014 database yang telah kita buat tadi:

DBCC LOGINFO (N'DBTest2014');
GO

Lihat hasilnya:

DBCC SQLPERF (LOGSPACE)

Satu-satunya cara di Transact-SQL untuk memeriksa jumlah log yang digunakan adalah DBCC SQLPERF. Sintaks untuk perintahnya adalah:

DBCC SQLPERF
(
     [ LOGSPACE ]
     |
          [ "sys.dm_os_latch_stats" , CLEAR ]
     |
     [ "sys.dm_os_wait_stats" , CLEAR ]
)
     [WITH NO_INFOMSGS ]

Perintah mengembalikan kumpulan hasil dengan satu baris per database: