Gejala
Misalnya Anda menggunakan grup ketersediaan AlwaysOn dalam database Microsoft SQL Server 2012 atau SQL Server 2014, dan ada transaksi terbuka yang besar yang memerlukan ruang log tambahan. Ketika file log tidak bisa bertambah karena salah satu alasan berikut, transaksi gagal.
-
Kurangnya ruang file tambahan
-
File log tidak dikonfigurasi untuk tumbuh
-
File log telah mencapai ukuran maksimum yang dikonfigurasi
Selain itu, Anda menerima pesan kesalahan berikut:
Kesalahan: 9002, tingkat keparahan: 17, status: 9. log transaksi untuk database ' <nama database> ' penuh karena ' LOG_BACKUP '.
Setelah Anda menjalankan cadangan log, Anda menerima pesan kesalahan 9002 lainnya:
Kesalahan: 9002, tingkat keparahan: 17, status: 9. log transaksi untuk database ' <nama database> ' penuh karena ' ACTIVE_TRANSACTION '.
Setelah cadangan log lain, Anda akan menerima pesan kesalahan 9002 lainnya yang diikuti dengan pesan kesalahan 5901:
Kesalahan: 9002, tingkat keparahan: 17, status: 9. log transaksi untuk database ' <nama database> ' penuh karena ' AVAILABILITY_REPLICA '.
Tidak dapat menulis catatan Checkpoint dalam database <nama database> karena log di luar angkasa. Hubungi administrator database untuk memotong log atau mengalokasikan lebih banyak ruang ke file log database. Kesalahan: 5901, tingkat keparahan: 16, status: 1. satu atau beberapa unit pemulihan milik database ' <nama database> ' gagal untuk membuat Checkpoint. Hal ini biasanya disebabkan oleh kurangnya sumber daya sistem seperti disk atau memori, atau dalam beberapa kasus karena kerusakan database. Periksa entri sebelumnya dalam log kesalahan untuk informasi lebih detail tentang kegagalan ini.
Ketika pembuatan log atau cadangan berikutnya kemudian diambil selama rollback transaksi, Anda mungkin menerima pesan kesalahan berikut:
MSG 3052, tingkat 16, negara bagian 1, LOG 4CADANGAN tidak dapat membuat log pembaruan untuk database ' <nama database> '. Cadangan log berikutnya akan diperlukan untuk memajukan titik cadangan dari ' <LSN id 1> ' ke ' <lsn id 2> ' setelah ruang log tersedia untuk pembuatan log.
Saat Anda menerima pesan ini, Anda tidak lagi dapat mengirimkan transaksi baru ke database, dan Anda tidak bisa mengembangkan file log atau menambahkan file log lain.
Pemecahan Masalah
Masalah ini pertama kali diperbaiki dalam pembaruan kumulatif SQL Server berikut ini:
Setiap pembaruan kumulatif baru untuk SQL Server berisi semua hotfix dan semua perbaikan keamanan yang disertakan dengan pembaruan kumulatif sebelumnya. Kami menyarankan Anda mengunduh dan menginstal pembaruan kumulatif terbaru untuk SQL Server:
Penyelesaian Masalah
Anda dapat menggunakan penanganan masalah berikut ini untuk memotong log dan melanjutkan aktivitas.
-
Periksa setiap replika sekunder untuk memverifikasi replika sekunder last_hardened_lsn (Lihat sys.dm_hadr_database_replica_states) cocok dengan replika utama last_hardened_lsn. Anda bisa melakukan ini dengan menjalankan kueri berikut ini yang tersambung ke contoh replika utama
SELECT ags.name as AGGroupName, ar.replica_server_name as InstanceName, hars.role_desc, db_name(drs.database_id)as DBName, drs.last_hardened_lsn, drs.log_send_queue_size, drs.synchronization_state_desc as SyncState, ar.availability_mode_desc as SyncMode, CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id LEFT JOIN sys.availability_groups ags ON ar.group_id = ags.group_id LEFT JOIN sys.dm_hadr_availability_replica_states hars ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id WHERE db_name(drs.database_id) = '<database name>'
-
Pada replika utama
-
Menghapus database dari grup ketersediaan.
-
Tambahkan kembali database ke grup ketersediaan.
-
-
Pada setiap replika sekunder
-
Tambahkan kembali database ke grup ketersediaan.
-
Dengan menghapus database dari grup ketersediaan, itu akan segera memotong log-nya dan mengosongkan ruang log. Jika last_hardened_lsn pada setiap replika sekunder identik dengan replika utama, dan tidak ada cadangan log yang diambil selama waktu penghapusan database dari grup ketersediaan dan menambahkan kembali database pada setiap sekunder, replika sekunder akan berhasil ditambahkan kembali tanpa kesalahan atau harus memulihkan cadangan log pada sekunder. Jika replika sekunder tidak terkini dengan replika utama dan Anda harus menghapus database dari grup ketersediaan sebelum sekunder bisa mengejar ketinggalan, replika sekunder tersebut mungkin harus memiliki cadangan log yang dipulihkan untuk menangkapnya sebelum menambahkannya kembali ke grup ketersediaan, atau Jatuhkan database pada replika sekunder dan kembali berbenih dengan cadangan database log transaksi penuh dan.
Status
Microsoft telah mengonfirmasi bahwa ini adalah masalah pada produk Microsoft yang tercantum di bagian "Berlaku untuk".
