Dasar-dasar Log Transaksi SQL Server

Apa itu Log Transaksi?

Ada persyaratan dalam sistem basis data relasional bahwa transaksi harus tahan lama. Ini adalah "D" dalam properti ACID transaksi. Sistem harus memastikan bahwa jika terjadi crash mendadak, transaksi dapat diulang. SQL Server memenuhi persyaratan ini dengan menangkap semua transaksi dalam file fisik yang disebut file log transaksi .

Intinya, setiap kali transaksi dilakukan, SQL Server mencatat perubahan yang dihasilkan oleh transaksi tersebut dalam log transaksi. Bahkan jika transaksi belum disimpan dalam file data, transaksi tersebut tersedia di log transaksi dan dapat diputar ulang jika terjadi crash tiba-tiba.

Model Pemulihan dan Log Transaksi

SQL Server beroperasi di bawah tiga model pemulihan – Penuh, Dicatat Massal, dan Sederhana.

Di bawah mode pemulihan penuh, SEMUA transaksi dicatat. Dengan demikian, database dapat sepenuhnya pulih jika terjadi crash. Ini juga berarti bahwa cadangan basis data dapat dipulihkan ke titik waktu tertentu jika transaksi atau cadangan terkait tersedia. Di bawah mode Pemulihan Penuh dan Dicatat Massal, log transaksi akan terpotong setiap kali ada pencadangan log yang dijalankan.

Di bawah mode Pemulihan Sederhana, SEMUA transaksi masih dicatat. Namun, operasi log transaksi terpotong setiap kali database mengeksekusi pos pemeriksaan.

Sebuah pos pemeriksaan terjadi ketika SQL Server menulis buffer kotor ke file data. Buffer kotor adalah halaman penting yang disimpan di memori yang telah diubah oleh transaksi, seperti status di memori tidak cocok dengan status di disk. Namun, kami tidak akan membahas ini di sini. Dalam mode Pemulihan Sederhana, SQL Server menangkap semua perubahan ini di Log Transaksi untuk menyimpannya hingga dipertahankan.

Struktur Log Transaksi

Log transaksi adalah file fisik yang terlihat di lapisan OS server tempat database SQL Server di-host. Setiap database memiliki satu log transaksi, tetapi dimungkinkan untuk mengonfigurasi lebih banyak. Masalahnya, memiliki beberapa log SQL transaksi tidak membawa keuntungan kinerja apa pun. SQL Server menulis ke log transaksi secara berurutan - satu file harus penuh sebelum file berikutnya digunakan. Namun, beberapa file yang disimpan di disk terpisah dapat menghemat waktu jika file pertama penuh.

Secara internal, file log transaksi adalah serangkaian file log virtual. Ukuran dan jumlah file tersebut memengaruhi waktu yang diperlukan untuk mencadangkan database atau membuatnya online. Itu selalu merupakan ide yang baik untuk mengukur log transaksi dengan benar dan memastikan pengaturan pertumbuhan otomatis sesuai dengan tingkat aktivitas yang diharapkan. Maka pertumbuhan file tidak akan terlalu sering terjadi.

Apa yang Membuat Log Tumbuh?

Mari kita mulai dengan membuat database kecil menggunakan kode di Listing 1. File data berukuran 4MB, file log berukuran 2MB untuk memulai. Basis data produksi Anda tidak akan pernah sebesar ini terutama dengan praktik populer pra-alokasi . Kami memilih ukuran seperti itu hanya untuk tujuan demonstrasi.

-- Listing 1: Create a Small Database

create database tranlogexperiment
on primary 
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go

Dalam database tersebut, kami membuat satu tabel untuk pernyataan bahasa manipulasi data (DML) lebih lanjut (Daftar 2).

-- Listing 2: Create a Table

use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)

Dengan mengeksekusi kode di Daftar 3, kami memeriksa dan memverifikasi apa yang telah kami lakukan.

-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';

select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');

Perhatikan Ukuran file kolom. Kami melanjutkan untuk meminta pertumbuhan log transaksi dengan menjalankan INSERT dan DELETE 100.000 kali (Daftar 4).

-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000

Listing 4 menyisipkan satu baris ke dalam txn_log tabel dan menghapus baris yang sama, mengulangi tindakan ini 100.000 kali.

Secara keseluruhan, tabel tidak tumbuh karena aktivitas ini, tetapi log transaksi tumbuh secara signifikan. Saat kami mengulangi kueri di Listing 3 setelah menjalankan pernyataan DML dari Listing 4, kami melihat seberapa banyak log transaksi telah berkembang:

Log transaksi bertambah dari 4MB menjadi 40MB karena aktivitas ini meskipun file data tidak diubah ukurannya. Ini menunjukkan kepada kita dengan jelas bahwa ukuran log transaksi tidak ada hubungannya dengan ukuran data. Dampak pada ukuran berasal dari aktivitas (DML) yang terjadi pada database.

Bagaimana Kami Mengelola Log Transaksi?

Administrator basis data yang mengelola instance SQL Server dari penginstalan IaaS lokal harus mencadangkan pencadangan log transaksi secara teratur. Sangat membantu jika memiliki konfigurasi pemulihan bencana seperti Log Shipping atau AlwaysOn AG . Konfigurasi tersebut melakukan backup secara otomatis.

Dalam mode pemulihan penuh, cadangan log SQL Server akan memotong bagian log transaksi yang tidak lagi diperlukan untuk pemulihan. Pemotongan log menghapus file log virtual yang tidak aktif. Dengan cara ini, ia mengosongkan ruang di log transaksi untuk digunakan kembali.

Kode di Listing 6 menunjukkan ukuran log transaksi dan berapa banyak ruang kosong yang kita miliki di dalamnya.

-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name], 
    name AS [Logical File Name], 
    type_desc,
    size/128.0 AS [Current Size (MB)],  
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);

Kami juga dapat mengecilkan log transaksi fisik menggunakan kode di Listing 7. Sebelum menyusut, pastikan untuk memiliki cadangan log transaksi. Dalam produksi, yang terbaik adalah menjadwalkan pencadangan log untuk menghindari pertumbuhan file log fisik yang tidak terkendali dan memastikan data disimpan. Dengan opsi pemulihan bencana seperti Log Shipping atau AlwaysOn AG dikonfigurasi, ini sudah diberikan.

Kami dapat menanyakan log_reuse_wait_desc kolom di sys.databases tampilan katalog untuk menentukan kondisi apa pun yang mencegah penciutan log transaksi. Perhatikan bahwa kami menanyakan kolom ini di Listing 3.

Kondisi seperti itu dapat berupa pos pemeriksaan yang tertunda, pencadangan log yang tertunda, pencadangan atau pemulihan yang sedang berlangsung, transaksi jangka panjang yang aktif, dan aktivitas serupa dalam database.

-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO

Kami menggunakan kode di Listing 8 untuk membuat cadangan database. Dalam kasus khusus kami, pertama-tama kami harus membuat cadangan lengkap karena cadangan log selalu merujuk pada cadangan lengkap. Cadangan penuh "terakhir" memulai rantai saat menangani pemulihan titik waktu.

-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';

Saat menjalankan database dalam mode Pemulihan Sederhana, log transaksi terpotong di setiap pos pemeriksaan . Dalam mode ini, pencadangan log tidak dimungkinkan.

Lokasi file log transaksi harus berukuran tepat untuk mengakomodasi transaksi jangka panjang yang kadang-kadang terjadi. Jika tidak, log transaksi masih dapat mengisi ruang disk. Gambar 4 menunjukkan apa yang terjadi pada log secara internal ketika cadangan diambil. Perhatikan bahwa file fisiknya masih 40 MB, tetapi sekarang kami memiliki sekitar 37 MB ruang kosong.

Apa yang Terjadi dalam Mode Pemulihan Sederhana?

Sekarang, mari kita atur tranlogexperiment database ke mode Pemulihan Sederhana.

-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;

Saat kita mengeksekusi kode yang disajikan sebelumnya di Listing 4, kita akan mendapatkan perilaku yang sedikit berbeda.

Gambar 6 menunjukkan pertumbuhan log transaksi dalam mode Pemulihan Sederhana ketika kami mengeksekusi kode di Listing 4. Ukuran file log fisik hanya 15 MB. Ini setengah kurang dari itu di bawah Model Pemulihan Penuh sebelumnya. Perhatikan juga ruang kosong sebesar 11,5 MB.

Apakah ini berarti pertumbuhan log lebih sedikit?

Tidak. Gambar 7 menunjukkan bahwa saat sesi sedang dieksekusi, SQL Server kami juga melakukan beberapa checkpoint. Ini memotong log dan memberi ruang bagi transaksi untuk melanjutkan log yang bertambah secara berkala.

Kesimpulan

Log transaksi adalah komponen yang sangat penting dari database SQL Server. Ini berdampak pada semua yang memerlukan atau bergantung pada pemulihan – pencadangan, pemulihan, pemulihan bencana, dan sebagainya. Anda juga dapat mencatat aktivitas db.

Dalam artikel ini, kita telah membahas sifat log transaksi, aspek pengelolaannya dengan benar, dan menunjukkan perilaku DML dalam database dengan mode Pemulihan Penuh atau Sederhana. Namun, masih banyak yang harus dipelajari tentang log transaksi. Entri dalam referensi akan menjadi titik awal yang baik untuk Anda.

Referensi s

Log transaksi
Database &Penyimpanan SQL Server