log transaksi dalam RAM atau file fisik?


9

Saya pemula dalam transaksi, hanya pertanyaan tentang log transaksi. Kita tahu bahwa ketika kita melakukan transaksi, perubahan ditulis ke log transaksi, tetapi apakah transaksi log dalam RAM atau file fisik? Jika ada dalam RAM dan ketika kegagalan sistem terjadi, jelas RAM akan dihapus kembali sehingga kami kehilangan informasi transaksi, jadi bagaimana kami dapat memulihkan komit?

Jawaban:


15

Anda dapat menemukan panduan yang cukup komprehensif untuk pertanyaan ini di sini , tetapi untuk meringkas, SQL Server tidak akan mengembalikan kontrol ke aplikasi yang melakukan transaksi sampai transaksi itu telah dikeraskan ke disk. Secara khusus, setelah telah diperkeras ke file log transaksi, kontrol dapat dikembalikan.

Data, pada titik ini, mungkin tidak dikeraskan ke dalam file data, mungkin masih dalam cache buffer data, tetapi karena telah diperkeras ke dalam log transaksi maka pemulihan database, jika terjadi kegagalan, dapat memulihkan ini transaksi dan tahan perubahan dengan aman.

Ada cache buffer cache dalam memori yang digunakan untuk mengurangi dampak kinerja dari sekuensial menulis ke log transaksi. Buffer di-flush ke disk pada beberapa kondisi, tetapi salah satunya adalah komit transaksi. Sampai data ini dikeraskan, kontrol tidak dikembalikan ke pemanggil, jadi meskipun Anda mengalami kegagalan selama buffer flush ini, konsistensi transaksi tetap dipertahankan karena transaksi ini belum dianggap dilakukan. Anda akan kehilangan perubahan data dalam transaksi itu, tetapi karena tidak dilakukan, aplikasi Anda akan menganggap perubahan itu hilang karena komit tidak pernah selesai.



4

Database terdiri dari dua file, file data dan file log transaksi. Ini disimpan di disk.

Setiap basis data memiliki cache log dalam RAM, ketika transaksi dilakukan, ia akan dipindahkan ke cache log yang menunggu untuk dibilas ke disk. Oleh karena itu untuk sementara ketika sebuah transformasi telah dilakukan dan menunggu untuk dibilas ke disk, ia ada di memori, namun pada akhirnya disimpan pada disk dalam file, bukan RAM.

Saya terlalu menyederhanakan di sini, saya sarankan Anda membaca log transaksi, saya sarankan salah satu kuliah Paul Randals di sini

https://youtu.be/LvlFgxZZOj4


@ kevin apa Terima kasih atas jawaban Anda. Jadi jika kita melakukan satu transaksi dan diperbarui dalam cache log maka sistem gagal sebelum cache log mem-flush ke disk, jadi bagaimana kita bisa memulihkan transaksi?

1
@slowjams dalam hal itu perubahan transaksi yang dilakukan akan dibatalkan, karena tidak stabil pada disk di log pada saat crash terjadi.
Sean Gallardy - Pensiunan Pengguna

3
slowjamsm apa yang Anda desrcibe tidak terjadi. Komit sinkron - tidak selesai sampai semua catatan log hingga saat itu ditulis ke disk ("dikeraskan").
Tibor Karaszi

0

Seperti yang ditulis dari orang lain, log transaksi akan selalu ditulis ke disk, sebelum COMMITkontrol pengembalian ke aplikasi Anda. Untuk alasan ini file log harus selalu ditempatkan pada SSD yang cepat.

Tetapi demi kelengkapan: Dengan setidaknya Windows Server 2016 plus SQL Server 2016 Anda bisa menambahkan NVDIMM (DIMM non-volatile = Flash atau RAM yang didukung baterai) ke server Anda. Dalam hal ini SQL Server akan menggunakan NVDIMMs ini untuk menempatkan log transaksi "panas" pada NVDIMMs, karena mereka bertahan dari peristiwa mati-daya per definisi.

Ini akan meningkatkan kecepatan menulis secara drastis (karena RAM jauh lebih cepat daripada SSD), tetapi Anda hanya akan menyebutkannya pada basis data dengan banyak penulisan / komit kecil (mis. Basis data di belakang toko online yang sibuk atau permainan online dengan banyak pemain bersamaan).


3
Ini bukan jawaban untuk pertanyaan, ini adalah plug untuk disk yang lebih cepat. Log tidak selalu harus di penyimpanan cepat, ada banyak alasan bisnis untuk tidak melakukannya. Jika Anda ingin cepat beli cepat, jika Anda tidak perlu cepat ....
James Jenkins
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.