SQL Server Database dalam Mode Pemulihan: 10 Perbaikan [2026]

SQL Server Database dalam mode pemulihan? Dapatkan 10 solusi teruji sekarang! Solusi langkah demi langkah, mulai dari perbaikan mudah hingga perbaikan lanjutan.

1. Paham SQL Server Mode Pemulihan Basis Data

1.1 Apa itu Mode Pemulihan di SQL Server

Ketika sebuah SQL Server database menunjukkan status “Dalam Pemulihan”, artinya SQL Server sedang melakukan pemulihan kerusakan atau pemulihan transaksi untuk memastikan konsistensi basis data. Proses otomatis ini menjaga integritas data dengan memutar ulang transaksi yang telah dikomit dan mengembalikan transaksi yang belum dikomit.

Mode pemulihan biasanya terjadi setelah terjadi penghentian mendadak, pemadaman listrik, atau selama pemulihan basis data. Meskipun ini merupakan mekanisme perlindungan yang normal, masalah muncul ketika SQL Server basis data dalam pemulihan memerlukan waktu yang sangat lama atau nampak macet.

1.2 Tiga Fase Pemulihan Basis Data

SQL Server pemulihan mengikuti tiga fase berbeda:

1.2.1 Tahap Analisis

SQL Server Memindai log transaksi dari titik pemeriksaan terakhir untuk mengidentifikasi halaman kotor dan transaksi aktif. Proses ini membuat Tabel Halaman Kotor (DPT) dan Tabel Transaksi Aktif (ATT) untuk melacak apa yang perlu dipulihkan.

1.2.2 Fase Redo (Roll Forward)

Sistem akan memutar ulang semua transaksi yang telah dikomit yang belum ditulis ke disk sebelum kerusakan terjadi. Hal ini memastikan semua perubahan yang telah dikomit diterapkan dengan benar ke berkas basis data.

1.2.3 Fase Pembatalan (Rollback)

Setiap transaksi yang belum dikomit akan dibatalkan untuk menjaga konsistensi basis data. Setelah selesai, basis data akan tersedia untuk operasi normal.

1.3 Gejala Umum dan Pesan Kesalahan

Ketika Anda SQL Server db sedang dalam pemulihan, Anda biasanya akan melihat:

Nama basis data menunjukkan “(Dalam Pemulihan)” di SQL Server Studio Manajemen
Kegagalan login dengan pesan “database sedang dipulihkan”
Entri log kesalahan yang menunjukkan persentase kemajuan pemulihan
Status basis data menunjukkan “PEMULIHAN” saat ditanyakan

2. Akar Penyebab SQL Server Masalah Mode Pemulihan

2.1 Operasi Pemulihan yang Tidak Lengkap

Most penyebab umum terjadi saat memulihkan dari beberapa file cadangan menggunakan TIDAK ADA PEMULIHAN pilihan tanpa final DENGAN PEMULIHAN perintah. Hal ini membuat basis data menunggu operasi pemulihan tambahan.

2.2 Masalah Log Transaksi

Berkas log transaksi yang besar atau Berkas Log Virtual (VLF) yang berlebihan secara signifikan memperlambat pemulihan. Ketika MS SQL sedang dalam proses pemulihan dengan ribuan VLF, prosesnya bisa memakan waktu berjam-jam atau berhari-hari.

2.3 Masalah Terkait Sistem

Kegagalan perangkat keras, pemadaman listrik, atau ruang disk yang tidak mencukupi dapat mengganggu operasi database normal, memicu proses pemulihan yang lama selama pemulihan.tart.

2.4 Korupsi Basis Data

File basis data yang rusak menghalangi penyelesaian pemulihan yang berhasil, sehingga basis data terhenti dalam mode pemulihan tanpa batas waktu.

3. DiagnosaostLangkah-Langkah Penting Sebelum Memperbaiki

3.1 Memeriksa SQL Server Log Kesalahan

Sebelum mencoba perbaikan, periksa SQL Server Log kesalahan untuk pesan progres pemulihan. Cari entri yang menunjukkan persentase penyelesaian dan perkiraan waktu tersisa.

Open SQL Server Studio Manajemen
Navigasi ke Pengelolaan -> SQL Server Log
Tinjau entri terbaru untuk nama basis data Anda
Cari indikator fase pemulihan (Fase 1, 2, atau 3 dari 3)

3.2 Pemantauan Kemajuan Pemulihan

Gunakan tampilan manajemen dinamis untuk melacak operasi pemulihan aktif:

SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP';

3.3 Memeriksa Status Basis Data

Verifikasi status basis data saat ini untuk memahami status pemulihan:

SELECT name, state_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';

4. Perbaikan #1: Tunggu Pemulihan Alami Selesai

Terkadang kesabaran adalah solusi terbaik ketika Anda SQL Server Basis data sedang dalam proses pemulihan. Pendekatan ini berhasil ketika pemulihan berjalan normal tetapi membutuhkan waktu lebih lama dari yang diperkirakan.

4.1 Kapan Harus Bersabar

Izinkan penyelesaian alami ketika:

Log kesalahan menunjukkan kemajuan yang stabil dengan perkiraan waktu yang menurun
Tidak ada kesalahan korupsi yang dilaporkan
Database baru-baru ini mengalami transaksi besar
Jumlah VLF dapat dikelola (di bawah 1,000)

4.2 Pemantauan Kemajuan Pemulihan

Estimasi waktu pemulihan dalam log kesalahan seringkali tidak akurat. Fokuslah pada persentase kemajuan, bukan waktu yang tersisa. Basis data besar dengan riwayat transaksi yang ekstensif mungkin memerlukan beberapa jam untuk pemulihan penuh.

5. Perbaikan #2: Gunakan RESTORE DATABASE WITH RECOVERY

Perbaikan ini mengatasi operasi pemulihan yang tidak lengkap di mana langkah pemulihan terakhir terlewat. Gunakan ini saat Anda SQL Server db dalam pemulihan dihasilkan dari proses pemulihan menggunakan NORECOVERY.

5.1 Memahami Perintah

The PULIHKAN DATABASE DENGAN PEMULIHAN perintah melengkapi proses pemulihan dengan mengembalikan transaksi yang belum terkomit dan membuat basis data daring.

5.2 Langkah Implementasi

Open SQL Server Studio Manajemen
Sambungkan ke SQL Server contoh
Klik Baru > Kueri dengan Koneksi Saat Ini
Menjalankan: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
Tunggu konfirmasi penyelesaian

Peringatan: Gunakan perintah ini hanya jika Anda yakin tidak ada operasi pemulihan tambahan yang tertunda.

6. Perbaikan #3: Selesaikan Masalah Log Transaksi

Masalah log transaksi merupakan penyebab utama waktu pemulihan yang lama. Perbaikan ini mengatasi masalah log penuh, VLF yang berlebihan, dan ruang log yang terus-menerus. SQL Server dalam pemulihan

6.1 Mencadangkan Log Transaksi

Kosongkan ruang log dengan membuat cadangan log transaksi:

Open SQL Server Studio Manajemen
Klik kanan database Anda -> Tasks -> Back Up
Perubahan Jenis cadangan untuk Log Transaksi
Tentukan tujuan pencadangan
Klik OK untuk mengeksekusi

6.2 Mengelola Berkas Log Virtual (VLF)

Periksa jumlah VLF dengan:

DBCC LOGINFO('YourDatabaseName');

Jika Anda memiliki lebih dari 1,000 VLF, kurangi dengan:

Mencadangkan log transaksi
Mengecilkan berkas log: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
Menumbuhkan file log dalam potongan besar (1GB atau lebih)

6.3 Mengecilkan File Log dengan Aman

Kecilkan log hanya selama masa pemeliharaan ketika tidak ada transaksi aktif yang berjalan. Selalu cadangkan basis data sebelum melakukan operasi penyusutan.

7. Perbaikan #4: Jalankan DBCC CHECKDB dan Perbaiki

Korupsi basis data dapat mencegah penyelesaian pemulihan yang berhasil. DBCC CHECKDB adalah perintah bawaan yang dapat mengidentifikasi dan memperbaiki masalah korupsi kecil yang membuat MS SQL tetap dalam mode pemulihan.

7.1 Memeriksa Kerusakan Basis Data

Start dengan pendekatan standar untuk memverifikasi integritas basis data. Coba DBCC CHECKDB secara langsung terlebih dahulu:

Menjalankan: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Tinjau hasil untuk kesalahan konsistensi
Dokumentasikan semua pesan korupsi

Jika DBCC CHECKDB gagal Jika muncul pesan kesalahan seperti "Basis data sedang dipulihkan. Menunggu hingga pemulihan selesai", artinya basis data sedang aktif dalam mode pemulihan dan memblokir akses. Jika demikian, lanjutkan ke bagian 7.3 untuk menggunakan mode DARURAT.

7.2 Opsi Perbaikan untuk Basis Data yang Dapat Diakses

Jika DBCC CHECKDB berhasil dijalankan dan ditemukan kerusakan, gunakan langkah-langkah perbaikan berikut:

Atur basis data ke mode pengguna tunggal: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Mencoba perbaikan yang aman: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Jika tidak berhasil, gunakan: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Kembali ke multi-pengguna: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Menggunakan Mode Darurat Saat Database Tidak Dapat Diakses

Mode darurat hanya diperlukan ketika basis data macet dalam proses pemulihan dan menolak upaya DBCC CHECKDB normal. Mode ini menandai basis data sebagai READ_ONLY dan menonaktifkan pencatatan. Gunakan pendekatan ini ketika akses standar gagal:

Atur mode darurat: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
Tetapkan pengguna tunggal: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Jalankan pemeriksaan integritas: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Jika ditemukan korupsi, jalankan perbaikan aman terlebih dahulu: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Jika gagal, gunakan perbaikan dengan kehilangan data: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Atur multi-pengguna: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
Ditetapkan secara daring: ALTER DATABASE [YourDatabaseName] SET ONLINE;

Penting: Mode DARURAT mengabaikan proses pemulihan normal dan hanya boleh digunakan saat basis data benar-benar tidak dapat diakses. Selalu coba pendekatan DBCC CHECKDB standar terlebih dahulu sebelum beralih ke mode DARURAT.

Anda dapat menemukan panduan yang lebih lengkap tentang cara menggunakan DBCC CHECKDB.

8. Perbaikan #5: Pulihkan dari Cadangan

Ketika metode lain gagal atau integritas data dipertanyakan, memulihkan dari cadangan bersih sering kali menjadi pilihan terbaik.ost solusi yang dapat diandalkan untuk menyelesaikan SQL Server basis data dalam masalah pemulihan.

8.1 Kapan Memilih Pemulihan Cadangan

Pertimbangkan pemulihan cadangan saat:

Pemulihan telah berjalan selama lebih dari 24 jam tanpa kemajuan
Kesalahan korupsi mencegah perbaikan yang berhasil
Anda memiliki cadangan terverifikasi terbaru yang tersedia
Kehilangan data sejak pencadangan terakhir dapat diterima

8.2 Proses Restorasi Langkah demi Langkah

Open SQL Server Studio Manajemen
Klik kanan Database -> Pulihkan Database
Pilih alat di bawah Sumber
Klik Add dan telusuri file cadangan Anda
Pilih cadangan dan klik OK
Pilih Timpa database yang ada jika diperlukan
Klik OK untuk starrestorasi t

8.3 Pemulihan Titik Waktu

Untuk meminimalkan kehilangan data, gunakan cadangan log transaksi untuk memulihkan ke titik waktu tertentu. Pastikan Anda memiliki rantai cadangan log yang tidak terputus dari pencadangan penuh hingga titik pemulihan yang diinginkan.

8.4 Referensi

Anda dapat mempelajari informasi lebih lanjut dari kami panduan lengkap tentang cara mencadangkan dan memulihkan SQL Server database.

9. Perbaikan #6: Nonaktifkan Properti AUTO CLOSE

Properti database AUTO CLOSE dapat menyebabkan siklus pemulihan berulang, sehingga tampak bahwa SQL Server db terus-menerus dalam pemulihan. Menonaktifkan properti ini akan menyelesaikan masalah.

9.1 Memahami Masalah AUTO CLOSE

Ketika TUTUP OTOMATIS diaktifkan, SQL Server menutup basis data setelah koneksi terakhir berakhir, lalu membukanya kembali untuk koneksi baru. Pembukaan berulang ini memicu proses pemulihan setiap kali.

9.2 Menonaktifkan AUTO CLOSE

Open SQL Server Studio Manajemen
Klik kanan database Anda -> Properties
Pilih Opsi dari panel kiri
set Tutup Otomatis untuk Salah
Klik OK untuk menerapkan perubahan

Atau, gunakan T-SQL:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Perbaikan #7: Restart SQL Server Pelayanan

Layanan restarIni dapat mengatasi proses pemulihan yang macet, tetapi harus digunakan dengan hati-hati karena akan mengatasitarpemulihan dari awal. Perbaikan ini berfungsi ketika SQL Server dalam pemulihan tampak benar-benar beku.

10.1 Ketika Layanan Restart Membantu

Soaltart layanan ketika:

Kemajuan pemulihan terhenti selama beberapa jam
Log kesalahan tidak menunjukkan entri baru
Database lainnya berfungsi normal
Anda mampu menanggung waktu henti yang lama

10.2 Res Amantart Prosedur

Open SQL Server Manajer Konfigurasi
Navigasi ke SQL Server Australia Profesional
Cari SQL Server misalnya Anda ingin restart, lalu klik kanan SQL Server (Nama Instansi)
Pilih Soaltart
Tunggu hingga layanan terisi penuhtart
Pantau log kesalahan untuk kemajuan pemulihan

Catatan: Soaltarhal ini akan menyebabkan pemulihan dimulai dari start, berpotensi memperpanjang waktu pemulihan total.

11. Perbaikan #8: Perbaiki Database dengan Melepas dan Memasang Kembali

Untuk kasus ekstrem, lepaskan dan pasang kembali basis data:

Lepaskan basis data: EXEC sp_detach_db 'YourDatabaseName';
Lampirkan hanya file MDF: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
Ini membangun kembali log transaksi baru

Peringatan: Metode ini dapat mengakibatkan hilangnya data. Gunakan hanya jika opsi lain sudah tidak ada lagi.

12. Perbaikan #9: Menangani Masalah Pencerminan Basis Data

Konfigurasi pencerminan basis data dapat menyebabkan masalah pemulihan yang unik. Perbaikan ini mengatasi masalah khusus pencerminan yang membuat basis data tetap dalam status pemulihan.

12.1 Masalah Pemulihan Spesifik Pencerminan

Basis data yang dicerminkan mungkin macet dalam proses pemulihan karena masalah koneksi mitra atau masalah titik akhir. Baik basis data utama maupun basis data cermin dapat menampilkan status pemulihan.

12.2 Solusi Pemulihan Cermin

Soaltarke titik akhir pencerminan:

Temukan nama titik akhir: SELECT * FROM sys.endpoints WHERE type = 4;
Titik akhir pemberhentian: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
Startitik akhir t: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Jika titik akhir restarJika gagal, putuskan kemitraan pencerminan:

Menjalankan: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
Menjalankan: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
Konfigurasi ulang pencerminan setelah database online

13. Perbaikan #10: Gunakan Alat Pemulihan Profesional

Alat pemulihan pihak ketiga menyediakan kemampuan perbaikan tingkat lanjut saat terpasang SQL Server Metode-metode ini gagal. Alat-alat ini seringkali dapat memulihkan data dari basis data yang rusak parah.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery memiliki tingkat pemulihan yang tinggi, disertai pilihan yang komprehensif.

Berikut langkah-langkah penggunaannya:

Hentikan SQL Server Layanan.
Buat salinan file basis data dalam mode pemulihan, termasuk file MDF primer dan file NDF sekunder.
Start itu SQL Server Layanan.
Start DataNumen SQL Recovery.
Pilih salinan, bukan berkas asli, sebagai sumber basis data yang akan dipulihkan.
Klik “Start Pemulihan” dan ikuti petunjuk untuk memulihkan basis data.
Setelah proses pemulihan, database pemulihan baru akan muncul di SQL Server yang berisi semua data yang dipulihkan.

13.2 Kapan Harus Mempertimbangkan Alat Pihak Ketiga

Gunakan alat profesional saat:

Opsi perbaikan bawaan gagal atau melaporkan kerusakan yang parah
Tidak ada cadangan terbaru yang tersedia
Data penting harus dipulihkan meskipun ada kerusakan
Metode pemulihan standar mengakibatkan hilangnya data yang signifikan

14. Praktik Terbaik Pencegahan

14.1 Tugas Pemeliharaan Rutin

Terapkan praktik-praktik ini untuk mencegah SQL Server database dalam masalah pemulihan:

Jadwalkan pencadangan penuh dan log secara berkala: Pertahankan rantai cadangan yang lengkap
Pantau jumlah VLF: Jaga VLF di bawah 100 untuk kinerja optimal
Ukuran file log rencana: Pra-ukuran log untuk menghindari pertumbuhan otomatis yang berlebihan
Jalankan DBCC CHECKDB biasa: Deteksi korupsi sejak dini

14.2 Pemantauan dan Peringatan

Siapkan pemantauan proaktif:

Konfigurasikan peringatan untuk perubahan status basis data
Memantau ruang disk pada drive file log
Lacak transaksi jangka panjang
Peringatan tentang jumlah VLF yang berlebihan

14.3 Perangkat Keras dan Infrastruktur

Pastikan infrastruktur yang andal:

Gunakan penyimpanan cepat untuk log transaksi (sebaiknya SSD)
Terapkan catu daya redundan
Pisahkan data dan file log pada drive yang berbeda
Mempertimbangkan solusi ketersediaan tinggi 'like' Grup Ketersediaan Selalu Aktif

15. Pemecahan Masalah Skenario Kompleks

15.1 Beberapa Masalah Basis Data

Ketika beberapa basis data macet dalam pemulihan:

Periksa masalah di seluruh sistem (ruang disk, memori)
Prioritaskan database penting untuk pemulihan
Pertimbangkan masalah perangkat keras yang memengaruhi seluruh instans
Tinjau perubahan atau pembaruan sistem terkini

15.2 Pertimbangan Basis Data Besar

Untuk basis data lebih dari 1TB:

Harapkan waktu pemulihan yang lebih lama (berpotensi berhari-hari)
Pastikan alokasi memori yang memadai
Pertimbangkan pengaturan pemrosesan paralel
Pantau ruang tempdb selama pemulihan

15.3 Kapan Harus Menghubungi Dukungan Microsoft

Hubungi Dukungan Microsoft untuk:

Sistem produksi kritis tanpa opsi cadangan
Tersangka SQL Server bug perangkat lunak
Lingkungan perusahaan yang membutuhkan pemulihan terjamin
Skenario Selalu Aktif atau pengelompokan yang Kompleks

16. Tanya Jawab

T: Berapa lama seharusnya SQL Server berapa lama waktu yang dibutuhkan untuk pemulihan basis data?

J: Waktu pemulihan bergantung pada ukuran basis data, volume transaksi, dan kinerja perangkat keras. Basis data kecil biasanya pulih dalam hitungan menit, sementara basis data besar dengan log transaksi yang ekstensif dapat memakan waktu beberapa jam. Perkiraan waktu yang ditampilkan dalam log kesalahan seringkali tidak akurat, jadi fokuslah pada persentase kemajuan.

T: Bisakah saya berhenti? SQL Server selama pemulihan tanpa kehilangan data?

A: Berhenti SQL Server selama pemulihan umumnya aman tetapi akan restarproses pemulihan dari awal ketika layanan restarts. Ini memperpanjang waktu pemulihan total tetapi tidak menyebabkan kehilangan data tambahan melebihi apa yang terjadi selama insiden awal.

T: Apa perbedaan antara “Dalam Pemulihan” dan “Pemulihan Tertunda”?

A: “Dalam Pemulihan” berarti SQL Server sedang aktif melakukan operasi pemulihan. “Pemulihan Tertunda” menunjukkan proses pemulihan gagaltart, biasanya disebabkan oleh file yang hilang, izin yang tidak memadai, atau masalah ruang disk yang harus diselesaikan sebelum pemulihan dapat dilanjutkan.

Anda dapat menemukan informasi lebih rinci tentang “Pemulihan Tertunda” di panduan komprehensif.

T: Apakah saya akan kehilangan data jika saya menggunakan REPAIR_ALLOW_DATA_LOSS?

J: Ya, REPAIR_ALLOW_DATA_LOSS dapat menghapus data yang rusak untuk memulihkan konsistensi basis data. Selalu coba REPAIR_REBUILD terlebih dahulu, yang akan memperbaiki masalah struktural tanpa kehilangan data. Gunakan REPAIR_ALLOW_DATA_LOSS hanya sebagai pilihan terakhir jika Anda tidak memiliki opsi pemulihan lain.

T: Dapatkah saya mengakses basis data lain saat satu basis data sedang dalam pemulihan?

A: Ya, database lain pada database yang sama SQL Server Instans tetap dapat diakses selama pemulihan. Hanya basis data yang sedang dipulihkan yang tidak tersedia. Namun, operasi pemulihan dapat memengaruhi kinerja server secara keseluruhan.

T: Apa yang menyebabkan basis data macet dalam mode pemulihan?

A: Penyebab umumnya meliputi operasi pemulihan yang tidak tuntas menggunakan NORECOVERY, File Log Virtual (VLF) yang berlebihan, transaksi besar yang belum terkomit, kerusakan basis data, ruang disk yang tidak mencukupi, dan masalah perangkat keras. Basis data yang mengaktifkan AUTO CLOSE juga mungkin tampak terus-menerus masuk ke mode pemulihan.

T: Bagaimana saya tahu apakah pemulihan mengalami kemajuan atau macet?

A: Memantau SQL Server Log kesalahan untuk pesan progres pemulihan yang menunjukkan persentase penyelesaian. Gunakan sys.dm_exec_requests untuk memeriksa apakah DB S aktif.TARPerintah TUP. Jika persentase meningkat seiring waktu, pemulihan sedang berlangsung. Tidak ada entri log baru selama beberapa jam dapat mengindikasikan proses macet.

T: Apakah aman untuk res?tart SQL Server layanan selama pemulihan?

A: RestarTing aman tetapi harus digunakan dengan hati-hati. Ini akan bertahantarpemulihan dari awal, berpotensi menggandakan waktu pemulihan. Hanya restart jika pemulihan nampaknya benar-benar macet tanpa kemajuan selama berjam-jam, atau jika Anda menduga prosesnya benar-benar macet.

T: Apa perbedaan antara AUTO CLOSE dan mode pemulihan?

A: AUTO CLOSE secara otomatis menutup basis data ketika tidak ada koneksi, lalu membukanya kembali untuk koneksi baru. Pembukaan berulang ini memicu proses pemulihan singkat setiap kali, sehingga basis data tampak terus-menerus dalam pemulihan. Menonaktifkan AUTO CLOSE akan mengatasi masalah ini.

T: Dapatkah pencadangan log transaksi membantu selama pemulihan?

J: Pencadangan log transaksi dapat mengosongkan ruang log jika drive log penuh, sehingga memungkinkan pemulihan untuk dilanjutkan. Namun, Anda tidak dapat mencadangkan log database yang saat ini dalam mode pemulihan. Pencadangan log lebih bermanfaat untuk pencegahan dan pemulihan.ost-pemeliharaan pemulihan.

T: Kapan saya harus menghubungi Dukungan Microsoft?

A: Hubungi Dukungan Microsoft untuk sistem produksi penting di mana metode pemulihan bawaan gagal, jika Anda mencurigai SQL Server bug perangkat lunak, untuk skenario Always On atau pengelompokan yang kompleks, atau ketika lingkungan perusahaan memerlukan pemulihan data terjamin dengan waktu henti minimal.

T: Bagaimana cara mencegah basis data macet saat pemulihan?

A: Terapkan pencadangan penuh dan log secara berkala, pantau dan kelola jumlah VLF, pastikan ruang disk memadai, gunakan prosedur penonaktifan yang tepat, pertahankan keandalan perangkat keras, nonaktifkan TUTUP OTOMATIS pada basis data produksi, dan jalankan operasi DBCC CHECKDB secara berkala guna mendeteksi kerusakan sejak dini.

T: Apa itu VLF dan mengapa itu memengaruhi pemulihan?

A: Berkas Log Virtual (VLF) adalah segmen internal dalam berkas log transaksi. Terlalu banyak VLF (lebih dari 1,000) secara signifikan memperlambat pemulihan karena SQL Server harus memproses masing-masing secara individual. Pengaturan ukuran dan pertumbuhan berkas log yang tepat membantu mempertahankan jumlah VLF yang optimal.

T: Dapatkah saya memulihkan dari cadangan saat basis data sedang dalam pemulihan?

A: Anda tidak dapat memulihkan basis data yang saat ini dalam mode pemulihan. Anda harus menunggu pemulihan selesai, menghentikan SQL Server layanan, atau memulihkan ke nama basis data yang berbeda. Untuk situasi mendesak, pertimbangkan untuk memulihkan ke nama basis data baru, lalu mengganti namanya setelah masalah pemulihan teratasi.

17. Kesimpulan dan Langkah Selanjutnya

17.1 Ringkasan Solusi Utama

Ketika Anda SQL Server database sedang dalam pemulihan, stardengan pendekatan berikut ini secara berurutan:

Periksa log kesalahan dan pantau kemajuan
Tunggu penyelesaian alami jika kemajuannya stabil
Gunakan RESTORE WITH RECOVERY untuk pemulihan yang tidak lengkap
Atasi masalah log transaksi
Jalankan DBCC CHECKDB atau alat profesional untuk korupsi
Pertimbangkan pemulihan cadangan untuk kasus yang parah

Most SQL Server DB dalam situasi pemulihan dapat diselesaikan dalam hitungan jam menggunakan metode yang telah terbukti ini. Untuk skenario yang kompleks, jangan ragu untuk menggunakan teknik canggih atau alat profesional.

17.2 Sumber Daya Tambahan

Untuk bantuan selanjutnya:

Microsoft SQL Server Dokumentasi
SQL Server Forum Komunitas
Blog administrasi basis data dan sumber daya teknis
Layanan pemulihan basis data profesional

Perawatan dan pemantauan rutin mencegah most Masalah pemulihan. Terapkan praktik pencegahan yang diuraikan dalam panduan ini untuk meminimalkan munculnya masalah pemulihan MS SQL di masa mendatang.

tentang Penulis

Yuan Sheng adalah administrator basis data senior (DBA) dengan lebih dari 10 tahun pengalaman di SQL Server lingkungan dan manajemen basis data perusahaan. Ia telah berhasil menyelesaikan ratusan skenario pemulihan basis data di berbagai organisasi jasa keuangan, layanan kesehatan, dan manufaktur.

Yuan mengkhususkan diri dalam SQL Server Pemulihan basis data, solusi ketersediaan tinggi, dan optimasi kinerja. Pengalaman langsungnya yang luas mencakup pengelolaan basis data multi-terabyte, penerapan Always On Availability Group, dan pengembangan strategi pencadangan dan pemulihan otomatis untuk sistem bisnis yang sangat penting.

Melalui keahlian teknis dan pendekatan praktisnya, Yuan berfokus pada pembuatan panduan komprehensif yang membantu administrator basis data dan profesional TI memecahkan masalah kompleks SQL Server tantangan secara efisien. Dia selalu mengikuti perkembangan terbaru SQL Server rilis dan teknologi basis data Microsoft yang terus berkembang, secara berkala menguji skenario pemulihan untuk memastikan rekomendasinya mencerminkan praktik terbaik di dunia nyata.

Memiliki pertanyaan tentang SQL Server pemulihan atau butuh panduan pemecahan masalah basis data tambahan? Yuan menyambut masukan dan saran untuk meningkatkan sumber daya teknis ini.

SQL Server Database dalam Mode Pemulihan: 10 Perbaikan Terbukti [Panduan 2026]