Log transaksi mengembang secara tidak terduga atau menjadi penuh di komputer yang menjalankan SQL Server

Dalam SQL Server 7.0, SQL Server 2000, dan SQL Server tahun 2005, dengan pengaturan autogrow, file log transaksi dapat memperluas secara otomatis.

Biasanya, ukuran file log transaksi menstabilkan ketika itu dapat memegang maksimum jumlah transaksi yang dapat terjadi antara transaksi log pemenggalan bahwa pos pemeriksaan atau transaksi login Backup memicu.

Namun, dalam beberapa situasi mungkin log transaksi menjadi sangat besar dan kehabisan ruang atau menjadi penuh. Biasanya, Anda menerima pesan galat berikut ketika file log transaksi mengambil yang tersedia disk space dan tidak dapat memperluas lagi: Jika Anda menggunakan SQL Server 2005, Anda menerima pesan kesalahan pesan yang ini mirip dengan berikut: Selain untuk pesan galat ini, SQL Server dapat menandai database curiga karena kurangnya ruang untuk ekspansi log transaksi. Untuk informasi tambahan tentang cara memulihkan dari situasi ini, lihat "Ruang Disk tidak cukup" topik dalam SQL Server buku Online.

Selain itu, ekspansi log transaksi dapat mengakibatkan situasi berikut:

• File log transaksi sangat besar.
• Transaksi mungkin gagal dan mungkin mulai memutar kembali.
• Transaksi mungkin memakan waktu lama untuk menyelesaikan.
• Masalah kinerja yang mungkin terjadi.
• Memblokir dapat terjadi.

Penyebab

Ekspansi log transaksi mungkin terjadi karena berikut alasan atau skenario:

• Tidak terikat transaksi
• Sangat besar transaksi
• Operasi: DBCC DBREINDEX dan membuat indeks
• Sementara memulihkan dari Backup log transaksi
• Aplikasi-aplikasi client tidak memproses semua hasil
• Kueri waktu sebelum log transaksi selesai perluasan dan Anda menerima pesan kesalahan 'Log lengkap' palsu
• Unreplicated transaksi

Catatan Dalam SQL Server 2005, Anda dapat meninjau log_reuse_wait dan log_reuse_wait_desc kolom sys.databases katalog pandangan untuk menentukan hal-hal berikut:

• Mengapa log transaksi ruang tidak kembali
• Mengapa log transaksi tidak terpotong

Transaksi tidak terikat

Transaksi eksplisit tetap tidak terikat jika Anda tidak mengeluarkan eksplisit KOMIT atau ROLLBACK perintah. Ini paling sering terjadi ketika aplikasi masalah batal atau melakukan transaksi SQL membunuh perintah tanpa perintah ROLLBACK yang bersangkutan. Pembatalan transaksi terjadi, tetapi tidak mengembalikan; oleh karena itu, SQL Server tidak bisa memotong setiap transaksi yang terjadi setelah ini karena transaksi dibatalkan masih terbuka. Kamu bisa menggunakan DBCC OPENTRAN Transact-SQL referensi untuk memverifikasi apakah ada aktif transaksi dalam database pada waktu tertentu. Untuk informasi lebih lanjut tentang skenario khusus ini, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: Selain itu, baca topik "DBCC OPENTRAN" dalam SQL Server buku secara Online.

Skenario yang dapat mengakibatkan tidak terikat transaksi:

• Aplikasi desain yang mengasumsikan bahwa semua kesalahan menyebabkan rollbacks.
• Desain aplikasi yang tidak benar-benar memperhitungkan rekening SQL Server perilaku ketika gulung kembali ke bernama transaksi atau khusus bersarang bernama transaksi. Jika Anda mencoba untuk mengembalikan ke batin-bernama transaksi, Anda menerima pesan galat berikut:
  Server: Msg 6401, tingkat 16, negara bagian 1, baris 13 tidak bisa memutar kembali InnerTran. Tidak transaksi atau savepoint nama itu ditemukan.
  Setelah SQL Server menghasilkan pesan kesalahan, terus pernyataan berikutnya. Ini oleh desain. Untuk selengkapnya, lihat "Bersarang transaksi" atau "di dalam SQL Server"topik dalam SQL Server buku Online.
  
  Microsoft menganjurkan Setelah ketika Anda merancang aplikasi Anda:
  • Hanya membuka satu transaksi unit (mempertimbangkan kemungkinan bahwa proses lain dapat menghubungi Anda).
  • Memeriksa @@ TRANCOUNT sebelum Anda mengeluarkan KOMIT, Kembalikan, kembali, atau serupa perintah atau pernyataan.
  • Menulis kode Anda dengan asumsi yang lain @@ TRANCOUNT mungkin "sarang" Anda dan rencana untuk luar @@ TRANCOUNT untuk digulung kembali ketika terjadi kesalahan.
  • Review savepoint dan menandai pilihan untuk transaksi. (Ini tidak melepaskan kunci!)
  • Melakukan pengujian lengkap.
• Sebuah aplikasi yang memungkinkan interaksi pengguna di dalam transaksi. Hal ini menyebabkan transaksi untuk tetap terbuka untuk waktu yang lama, yang penyebab yang menghalangi dan transaksi login pertumbuhan karena transaksi terbuka tidak akan terpotong dan transaksi baru ditambahkan ke log setelah terbuka transaksi.
• Sebuah aplikasi yang tidak memeriksa @@ TRANCOUNT untuk memverifikasi bahwa ada transaksi tidak terbuka.
• Jaringan atau kesalahan lainnya yang menutup aplikasi klien koneksi ke SQL Server tanpa memberitahu itu.
• Sambungan penggabungan. Setelah pekerja benang dibuat, SQL Server reuses mereka jika mereka tidak melayani sambungan. Jika sambungan pengguna mulai transaksi dan terputus sebelum melakukan atau bergulir kembali transaksi, dan hubungan yang kemudian reuses sama benang, sebelumnya transaksi masih tetap terbuka. Situasi ini menghasilkan kunci yang tetap terbuka dari transaksi sebelumnya dan mencegah pemotongan dari berkomitmen transaksi dalam log, yang mengakibatkan besar login ukuran file.Untuk informasi lebih lanjut tentang sambungan penggabungan, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:
  164221  (http://support.microsoft.com/kb/164221/ ) Cara mengaktifkan koneksi penggabungan dalam aplikasi ODBC

Transaksi yang sangat besar

Daftar penelepon dalam file log transaksi yang terpotong pada transaksi-transaksi oleh dasar. Jika cakupan transaksi besar, yang transaksi dan transaksi dimulai setelah itu tidak dihapus dari transaksi masuk kecuali jika selesai. Hal ini dapat mengakibatkan file log yang besar. Jika transaksi ini cukup besar, log file mungkin menggunakan ruang disk yang tersedia dan menyebabkan "log transaksi penuh" jenis pesan galat seperti 9002 kesalahan. Untuk informasi tambahan tentang apa yang harus dilakukan ketika Anda menerima kesalahan jenis ini pesan ini disediakan dalam bagian "Informasi lebih lanjut" pada artikel ini. Selain itu, dibutuhkan banyak waktu dan SQL Server overhead untuk roll kembali besar transaksi.

Operasi: DBCC DBREINDEX dan membuat indeks

Karena dari perubahan dalam model pemulihan dalam SQL Server 2000 Ketika Anda menggunakan modus pemulihan penuh dan Anda menjalankan DBCC DBREINDEX, transaksi log dapat memperluas secara signifikan lebih dibandingkan dengan SQL Server 7.0 di mode pemulihan setara dengan penggunaan pilih ke atau massal salinan dan dengan "Trunc. Logoff di chkpt.".

Meskipun ukuran transaksi login Setelah operasi DBREINDEX mungkin menjadi masalah, pendekatan ini menyediakan lebih baik log mengembalikan kinerja.

Sementara memulihkan dari transaksi log backup

Ini dijelaskan dalam berikut Basis Pengetahuan Microsoft Artikel:
Jika Anda menetapkan SQL Server 2000 menggunakan login massal mode dan Anda mengeluarkan massal salinan atau pilih ke pernyataan, sejauh setiap berubah ditandai dan kemudian membuat cadangan ketika Anda membuat cadangan log transaksi. Meskipun ini memungkinkan Anda untuk membuat cadangan log transaksi dan pulih dari kegagalan bahkan Setelah Anda menjalankan operasi massal, ini menambah ukuran transaksi log. SQL Server 7.0 tidak menyertakan fitur ini. Catatan hanya SQL Server 7.0 extent yang berubah, tapi itu tidak merekam extent sebenarnya. Oleh karena itu, penebangan mengambil secara signifikan lebih banyak ruang di SQL Server 2000 daripada di SQL Server 7.0 dalam massal-Log mode tapi tidak sebanyak itu tidak penuh modus.

Aplikasi-aplikasi client tidak memproses semua hasil

Jika Anda mengeluarkan permintaan untuk SQL Server dan Anda tidak menangani hasil segera, Anda dapat memegang kunci dan mengurangi concurrency pada Anda server.

Sebagai contoh, misalkan Anda mengeluarkan permintaan yang memerlukan baris dari dua halaman untuk mengisi Anda hasil. SQL Server mem-parsing, compiles, dan menjalankan query. Ini berarti bahwa bersama kunci ditempatkan pada dua halaman yang berisi baris yang harus Anda miliki untuk memenuhi permintaan Anda. Selain itu, Anggaplah bahwa tidak semua baris cocok ke SQL Server TDS satu paket (metode yang server berkomunikasi dengan klien). TDS paket diisi dan dikirim untuk klien. Jika semua baris dari halaman pertama yang sesuai pada paket TDS, SQL Server melepaskan kunci bersama pada halaman tetapi meninggalkan kunci bersama pada Halaman kedua. SQL Server kemudian menunggu untuk klien untuk meminta lebih banyak data (Anda dapat melakukan ini dengan menggunakan DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults, atau FetchLast/FetchFirst sebagai contoh).

Ini berarti bahwa kunci bersama diadakan sampai klien permintaan sisa data. Lain proses yang permintaan data dari halaman kedua mungkin diblokir.

Kueri waktu sebelum log transaksi selesai perluasan dan Anda menerima pesan kesalahan 'Log lengkap' palsu

Dalam situasi ini, meskipun ada cukup ruang disk, Anda masih menerima pesan galat "keluar dari ruang".

Situasi ini bervariasi untuk SQL Server 7.0 dan SQL Server 2000.

Permintaan dapat menyebabkan transaksi login otomatis memperluas jika log transaksi hampir penuh. Ini dapat mengambil waktu tambahan, dan permintaan mungkin berhenti atau dapat melebihi time-out yang periode karena ini. SQL Server 7.0 kembali kesalahan 9002 dalam situasi ini. Masalah ini tidak berlaku untuk SQL Server 2000.

Dalam SQL Server 2000, jika Anda memiliki Auto-menyusut pilihan diaktifkan untuk database, ada waktu yang sangat kecil selama log transaksi mencoba untuk memperluas secara otomatis, tetapi tidak dapat karena Auto-menyusut fungsi berjalan secara bersamaan. Ini juga dapat menyebabkan palsu contoh-contoh kesalahan 9002.

Biasanya, perluasan otomatis file log transaksi terjadi dengan cepat. Namun, dalam situasi berikut, itu mungkin memakan waktu lebih lama daripada biasa:

• Pertumbuhan bertahap terlalu kecil.
• Server lambat karena berbagai alasan.
• Disk drive tidak cukup cepat.

Transaksi unreplicated

Ukuran log transaksi penerbit database dapat memperluas jika Anda menggunakan replikasi. Transaksi yang mempengaruhi benda-benda yang direplikasi ditandai sebagai "Untuk replikasi." Transaksi ini, seperti transaksi tidak terikat, tidak dihapus setelah Checkpoint atau setelah Anda kembali ke atas log transaksi sampai tugas log-pembaca salinan transaksi ke database distribusi dan unmarks mereka. Jika masalah dengan log-pembaca tugas untuk mencegah dari membaca ini transaksi di The penerbit database, ukuran log transaksi dapat terus memperluas sebagai jumlah transaksi non-direplikasi meningkat. Anda dapat menggunakan DBCC OPENTRAN Transact-SQL referensi untuk mengidentifikasi tertua non-direplikasi transaksi.

Untuk informasi lebih lanjut mengenai pemecahan masalah unreplicated transaksi, lihat topik "sp_replcounters" dan "sp_repldone" dalam SQL Server Buku secara Online.

Untuk informasi selengkapnya, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:

Log transaksi untuk database dikelola sebagai satu set Virtual file log (VLFs) berdasarkan ukuran yang menentukan SQL Server internal ukuran total log file dan kenaikan pertumbuhan digunakan ketika log memperluas. Log selalu mengembang dalam satuan seluruh VLFs dan itu hanya dapat memampatkan untuk VLF batas. VLF dapat ada di salah satu dari tiga negara: aktif, RECOVERABLE, dan dapat digunakan kembali.

• AKTIF: Bagian aktif log dimulai pada urutan minimal log nomor (LSN) yang mewakili transaksi (tidak terikat) aktif. Aktif bagian dari log berakhir di terakhir-ditulis LSN. VLFs yang berisi bagian log aktif dianggap aktif VLFs. (ruang yang tidak digunakan dalam log fisik bukan merupakan bagian dari setiap VLF.)
• DIPULIHKAN: Bagian log yang mendahului aktif tertua transaksi hanya diperlukan untuk mempertahankan urutan log backup untuk tujuan pemulihan.
• REUSABLE: Jika Anda tidak menjaga backup log transaksi, atau jika Anda sudah didukung log, SQL Server reuses VLFs sebelum aktif tertua transaksi.

Ketika SQL Server mencapai akhir berkas log fisik, itu mulai menggunakan kembali ruang dalam file fisik dengan mengeluarkan MENGELILINGI kembali operasi ke awal dari file. Akibatnya, SQL Server mendaur-ulang ruang dalam file log yang tidak lagi diperlukan untuk pemulihan atau cadangan tujuan. Jika urutan cadangan log yang dipertahankan, bagian dari log sebelum minimum LSN tidak ditimpa sampai Anda kembali atas atau memotong mereka masuk catatan. Setelah Anda melakukan log cadangan, SQL Server dapat lingkaran kembali untuk awal file. Setelah SQL Server lingkaran kembali untuk mulai menulis daftar penelepon sebelumnya dalam file log, bagian dapat digunakan kembali log ini kemudian antara akhir log logis dan bagian aktif dari log.

Untuk informasi tambahan, lihat topik "Transaksi Log fisik arsitektur" dalam SQL Server buku secara Online. Selain itu, Anda dapat melihat diagram yang sangat baik dan diskusi ini pada halaman 190 "Dalam SQL Server 7.0" (Soukup, Ron. Di dalam Microsoft SQL Server 7.0, Microsoft Press, 1999), dan juga di halaman 182 melalui 186 "Dalam SQL Server 2000" (Delaney, Kalen. Di dalam Microsoft SQL Server 2000, Microsoft Press, 2000). Memiliki database SQL Server 7.0 dan SQL Server 2000 pilihan untuk autogrow dan autoshrink. Anda dapat menggunakan opsi ini untuk membantu Anda untuk mengecilkan atau memperluas log transaksi.

Untuk informasi lebih lanjut tentang bagaimana ini pilihan dapat mempengaruhi server Anda, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: Ada perbedaan antara pemotongan versus kompresi file log transaksi. Ketika memotong SQL Server file log transaksi, ini berarti bahwa isi file (misalnya, transaksi berkomitmen) akan dihapus. Namun, ketika Anda melihat ukuran file dari perspektif ruang disk (misalnya, dalam Windows Explorer atau dengan menggunakan DIR perintah) ukuran tetap tidak berubah. Namun, ruang di dalam berkas .ldf sekarang digunakan kembali oleh transaksi yang baru. Hanya ketika SQL Server menyusut ukuran file log transaksi, apakah Anda benar-benar melihat perubahan dalam ukuran fisik log file.

Untuk informasi lebih lanjut tentang cara untuk mengecilkan transaksi log, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:Untuk informasi lebih lanjut tentang SQL Server 6,5 log transaksi penggunaan, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft:

Bagaimana cara menemukan pertanyaan yang mengkonsumsi sejumlah besar ruang log di SQL Server 2005

Dalam SQL Server 2005, Anda dapat menggunakan tampilan dinamis manajemen sys.dm_tran_database_transactions (DMV) untuk menemukan pertanyaan yang mengkonsumsi sejumlah besar ruang log. Kolom berikut dalam sys.dm_tran_database_transactions DMV dapat berguna:

• database_transaction_log_bytes_used
• database_transaction_log_bytes_used_system
• database_transaction_log_bytes_reserved
• database_transaction_log_bytes_reserved_system
• database_transaction_log_record_count

Kau bisa query kolom sql_handle sys.dm_exec_requests DMV untuk mendapatkan teks sebenarnya pernyataan yang mengkonsumsi sejumlah besar ruang log. Anda dapat melakukannya dengan bergabung sys.dm_tran_database_transactions DMV dan sys.dm_tran_session_transactions DMV pada kolom transaction_id, dan kemudian menambahkan tambahan bergabung dengan sys.dm_exec_requests pada kolom session_id.

Untuk informasi lebih lanjut tentang sys.dm_tran_database_transactions DMV, kunjungi Web site Microsoft Developer Network (MSDN) berikut: Untuk informasi lebih lanjut tentang sys.dm_tran_session_transactions DMV, kunjungi Website MSDN berikut: Untuk informasi lebih lanjut tentang sys.dm_exec_requests DMV, kunjungi Website MSDN berikut: