SQL Server Pangkalan Data dalam Mod Pemulihan: 10 Pembetulan [2026]

SQL Server pangkalan data dalam mod pemulihan? Dapatkan 10 pembetulan terbukti sekarang! Penyelesaian langkah demi langkah daripada pembaikan mudah kepada pembaikan lanjutan.

1. Memahami SQL Server Mod Pemulihan Pangkalan Data

1.1 Apakah dalam Mod Pemulihan SQL Server

Apabila seorang SQL Server pangkalan data menunjukkan status "Dalam Pemulihan", ini bermakna SQL Server sedang melakukan pemulihan ranap atau pemulihan transaksi untuk memastikan konsistensi pangkalan data. Proses automatik ini mengekalkan integriti data dengan memainkan semula transaksi yang komited dan melancarkan semula transaksi yang tidak komited.

Mod pemulihan biasanya berlaku selepas penutupan yang tidak dijangka, kegagalan kuasa, atau semasa pemulihan pangkalan data. Walaupun ini adalah mekanisme perlindungan biasa, masalah timbul apabila SQL Server pangkalan data dalam pemulihan mengambil masa yang luar biasa lama atau kelihatan tersekat.

1.2 Tiga Fasa Pemulihan Pangkalan Data

SQL Server pemulihan mengikut tiga fasa yang berbeza:

1.2.1 Fasa Analisis

SQL Server mengimbas log transaksi dari pusat pemeriksaan terakhir untuk mengenal pasti halaman kotor dan transaksi aktif. Ia mencipta Jadual Halaman Kotor (DPT) dan Jadual Transaksi Aktif (ATT) untuk menjejaki perkara yang memerlukan pemulihan.

1.2.2 Fasa Buat Semula (Gulir Ke Hadapan)

Sistem memainkan semula semua transaksi komited yang tidak ditulis pada cakera sebelum ranap sistem. Ini memastikan semua perubahan komited digunakan dengan betul pada fail pangkalan data.

1.2.3 Buat Asal Fasa (Kembali)

Sebarang urus niaga yang tidak komited akan ditarik balik untuk mengekalkan konsistensi pangkalan data. Setelah lengkap, pangkalan data tersedia untuk operasi biasa.

1.3 Gejala Biasa dan Mesej Ralat

Apabila anda SQL Server db sedang dalam pemulihan, anda biasanya akan melihat:

Nama pangkalan data menunjukkan "(Dalam Pemulihan)" dalam SQL Server Studio Pengurusan
Kegagalan log masuk dengan mesej "pangkalan data sedang dipulihkan".
Entri log ralat menunjukkan peratusan kemajuan pemulihan
Keadaan pangkalan data menunjukkan "PULIH" apabila ditanya

2. Punca Punca SQL Server Isu Mod Pemulihan

2.1 Operasi Pemulihan Tidak Lengkap

Punca paling biasa berlaku apabila memulihkan daripada berbilang fail sandaran menggunakan NORECOVERY pilihan tanpa perlawanan akhir DENGAN PEMULIHAN perintah. Ini meninggalkan pangkalan data menunggu operasi pemulihan tambahan.

2.2 Masalah Log Transaksi

Fail log transaksi yang besar atau Fail Log Maya (VLF) yang berlebihan melambatkan pemulihan dengan ketara. Apabila MS SQL dalam pemulihan dengan beribu-ribu VLF, proses itu boleh mengambil masa berjam-jam atau hari untuk disiapkan.

2.3 Isu Berkaitan Sistem

Kegagalan perkakasan, gangguan bekalan elektrik atau ruang cakera yang tidak mencukupi boleh mengganggu operasi pangkalan data biasa, mencetuskan proses pemulihan yang panjang semasa mula semula.

2.4 Rasuah Pangkalan Data

Fail pangkalan data yang rosak menghalang penyiapan pemulihan yang berjaya, meninggalkan pangkalan data tersekat selama-lamanya dalam mod pemulihan.

3. Langkah Diagnostik Sebelum Membaiki

3.1 Memeriksa SQL Server Log Ralat

Sebelum mencuba pembaikan, periksa SQL Server log ralat untuk mesej kemajuan pemulihan. Cari entri yang menunjukkan peratusan penyiapan dan anggaran masa yang tinggal.

Buka SQL Server Studio Pengurusan
Navigasi ke Pengurusan -> SQL Server Balak
Semak entri terbaharu untuk nama pangkalan data anda
Cari penunjuk fasa pemulihan (Fasa 1, 2, atau 3 daripada 3)

3.2 Memantau Kemajuan Pemulihan

Gunakan pandangan pengurusan dinamik untuk menjejaki 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 Menyemak Keadaan Pangkalan Data

Sahkan keadaan pangkalan data semasa untuk memahami status pemulihan:

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

4. Betulkan #1: Tunggu Pemulihan Semulajadi Selesai

Kadangkala kesabaran adalah penyelesaian terbaik apabila anda SQL Server pangkalan data sedang dalam pemulihan. Pendekatan ini berfungsi apabila pemulihan berjalan secara normal tetapi mengambil masa lebih lama daripada yang dijangkakan.

4.1 Bila Perlu Bersabar

Benarkan penyiapan semula jadi apabila:

Log ralat menunjukkan kemajuan yang stabil dengan anggaran masa yang semakin berkurangan
Tiada kesilapan rasuah dilaporkan
Pangkalan data baru-baru ini mengalami transaksi besar
Kiraan VLF boleh diurus (di bawah 1,000)

4.2 Memantau Kemajuan Pemulihan

Anggaran masa pemulihan dalam log ralat selalunya tidak tepat. Fokus pada peratusan kemajuan dan bukannya masa yang tinggal. Pangkalan data besar dengan sejarah transaksi yang luas mungkin memerlukan beberapa jam untuk pemulihan lengkap.

5. Betulkan #2: Gunakan PULIHKAN PANGKALAN DATA DENGAN PEMULIHAN

Pembetulan ini menyelesaikan operasi pemulihan yang tidak lengkap di mana langkah pemulihan terakhir telah ditinggalkan. Gunakan ini apabila anda SQL Server db dalam pemulihan terhasil daripada proses pemulihan menggunakan NORECOVERY.

5.1 Memahami Perintah

. PULIHKAN PANGKALAN DATA DENGAN PEMULIHAN arahan melengkapkan proses pemulihan dengan melancarkan semula transaksi yang tidak komited dan membawa pangkalan data dalam talian.

5.2 Langkah-langkah Pelaksanaan

Buka SQL Server Studio Pengurusan
Sambungkan ke anda SQL Server contohnya
Klik Baharu > Pertanyaan dengan Sambungan Semasa
Laksanakan: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
Tunggu pengesahan siap

Amaran: Hanya gunakan arahan ini jika anda pasti tiada operasi pemulihan tambahan belum selesai.

6. Betulkan #3: Selesaikan Isu Log Transaksi

Masalah log urus niaga adalah punca utama masa pemulihan yang dilanjutkan. Pembaikan ini menangani log penuh, VLF berlebihan dan isu ruang log yang disimpan SQL Server dalam pemulihan.

6.1 Menyandarkan Log Transaksi

Kosongkan ruang log dengan membuat sandaran log transaksi:

Buka SQL Server Studio Pengurusan
Klik kanan pangkalan data anda -> Tugas -> Kembali Up
Tukar Jenis sandaran kepada Log Transaksi
Tentukan destinasi sandaran
Klik OK untuk melaksanakan

6.2 Mengurus Fail Log Maya (VLF)

Semak kiraan VLF dengan:

DBCC LOGINFO('YourDatabaseName');

Jika anda mempunyai lebih 1,000 VLF, kurangkannya dengan:

Membuat sandaran log transaksi
Mengecilkan fail log: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
Mengembangkan fail log dalam ketulan besar (1GB atau lebih)

6.3 Mengecilkan Fail Log Dengan Selamat

Hanya mengecilkan log semasa tetingkap penyelenggaraan apabila tiada transaksi aktif berjalan. Sentiasa sandarkan pangkalan data sebelum mengecilkan operasi.

7. Betulkan #4: Jalankan DBCC CHECKDB dan Pembaikan

Rasuah pangkalan data boleh menghalang penyiapan pemulihan yang berjaya. DBCC CHECKDB ialah arahan terbina dalam yang boleh mengenal pasti dan membaiki isu rasuah kecil yang mengekalkan MS SQL dalam mod pemulihan.

7.1 Menyemak Rasuah Pangkalan Data

Mulakan dengan pendekatan standard untuk mengesahkan integriti pangkalan data. Cuba DBCC CHECKDB secara langsung terlebih dahulu:

Laksanakan: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Semak keputusan untuk ralat konsistensi
Dokumentasikan sebarang mesej rasuah

Jika DBCC CHECKDB gagal dengan ralat seperti "Pangkalan Data sedang dipulihkan. Menunggu sehingga pemulihan selesai," ini bermakna pangkalan data sedang aktif dalam mod pemulihan dan menyekat akses. Dalam kes ini, teruskan ke bahagian 7.3 untuk menggunakan mod KECEMASAN.

7.2 Pilihan Pembaikan untuk Pangkalan Data Boleh Dicapai

Jika DBCC CHECKDB berjalan dengan jayanya dan mendapati rasuah, gunakan langkah pembaikan ini:

Tetapkan pangkalan data kepada mod pengguna tunggal: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Cuba pembaikan selamat: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Jika tidak berjaya, gunakan: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Kembali kepada berbilang pengguna: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 Menggunakan Mod Kecemasan Apabila Pangkalan Data Tidak Boleh Dicapai

Mod kecemasan diperlukan hanya apabila pangkalan data tersekat dalam pemulihan dan menolak percubaan DBCC CHECKDB biasa. Ia menandakan pangkalan data sebagai READ_ONLY dan melumpuhkan pengelogan. Gunakan pendekatan ini apabila akses standard gagal:

Tetapkan mod kecemasan: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
Tetapkan pengguna tunggal: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
Jalankan semakan integriti: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
Jika rasuah ditemui, jalankan pembaikan selamat dahulu: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
Jika gagal, gunakan pembaikan dengan kehilangan data: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
Tetapkan berbilang pengguna: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
Tetapkan dalam talian: ALTER DATABASE [YourDatabaseName] SET ONLINE;

penting: Mod KECEMASAN memintas proses pemulihan biasa dan hanya boleh digunakan apabila pangkalan data tidak boleh diakses sepenuhnya. Sentiasa cuba pendekatan DBCC CHECKDB standard dahulu sebelum meningkat kepada mod KECEMASAN.

Anda boleh mencari panduan yang lebih komprehensif tentang cara menggunakan DBCC CHECKDB.

8. Betulkan #5: Pulihkan daripada Sandaran

Apabila kaedah lain gagal atau integriti data diragui, pemulihan daripada sandaran bersih selalunya merupakan penyelesaian yang paling boleh dipercayai untuk menyelesaikannya. SQL Server pangkalan data dalam isu pemulihan.

8.1 Bila Memilih Pemulihan Sandaran

Pertimbangkan pemulihan sandaran apabila:

Pemulihan telah berjalan selama lebih 24 jam tanpa kemajuan
Kesilapan rasuah menghalang pembaikan yang berjaya
Anda mempunyai sandaran yang disahkan baru-baru ini tersedia
Kehilangan data sejak sandaran terakhir boleh diterima

8.2 Proses Pemulihan Langkah demi Langkah

Buka SQL Server Studio Pengurusan
Klik kanan Pangkalan data lain -> Pulihkan Pangkalan Data
pilih Peranti di bawah Sumber
Klik Tambah dan semak imbas ke fail sandaran anda
Pilih sandaran dan klik OK
Pilih Tulis ganti pangkalan data sedia ada jika diperlukan
Klik OK untuk memulakan pemulihan

8.3 Pemulihan Titik-dalam-Masa

Untuk kehilangan data yang minimum, gunakan sandaran log transaksi untuk memulihkan ke titik masa tertentu. Pastikan anda mempunyai rangkaian sandaran log yang tidak terputus daripada sandaran penuh anda ke titik pemulihan yang diingini.

8.4 Rujukan

Anda boleh mengetahui lebih banyak maklumat daripada kami panduan komprehensif tentang cara membuat sandaran dan memulihkan SQL Server pangkalan data.

9. Betulkan #6: Lumpuhkan AUTO CLOSE Property

Sifat pangkalan data AUTO CLOSE boleh menyebabkan kitaran pemulihan berulang, menjadikannya kelihatan bahawa anda SQL Server db sentiasa dalam pemulihan. Melumpuhkan sifat ini menyelesaikan masalah.

9.1 Memahami Isu AUTO CLOSE

Apabila AUTO CLOSE didayakan, SQL Server menutup pangkalan data selepas sambungan terakhir tamat, kemudian membukanya semula untuk sambungan baharu. Pembukaan berulang ini mencetuskan proses pemulihan setiap kali.

9.2 Melumpuhkan AUTO CLOSE

Buka SQL Server Studio Pengurusan
Klik kanan pangkalan data anda -> Hartanah
pilih Pilihan dari panel kiri
Tetapkan Tutup Auto kepada Palsu
Klik OK untuk menerapkan perubahan

Sebagai alternatif, gunakan T-SQL:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. Pembaikan #7: Mulakan Semula SQL Server Servis

Mulakan semula perkhidmatan boleh menyelesaikan proses pemulihan yang tersekat, tetapi harus digunakan dengan berhati-hati kerana ia akan memulakan semula pemulihan dari awal. Pembetulan ini berfungsi apabila SQL Server dalam pemulihan kelihatan beku sepenuhnya.

10.1 Apabila Perkhidmatan Dimulakan Semula Membantu

Mulakan semula perkhidmatan apabila:

Kemajuan pemulihan telah terhenti selama beberapa jam
Log ralat tidak menunjukkan entri baharu
Pangkalan data lain berfungsi seperti biasa
Anda mampu membayar masa rehat yang dilanjutkan

10.2 Prosedur Mula Semula yang Selamat

Buka SQL Server Pengurus Konfigurasi
Navigasi ke SQL Server Perkhidmatan
Cari SQL Server contoh yang anda ingin mulakan semula, kemudian klik kanan SQL Server (Nama Contoh)
pilih restart
Tunggu sehingga perkhidmatan dimulakan semula sepenuhnya
Pantau log ralat untuk kemajuan pemulihan

Catatan: Memulakan semula akan menyebabkan pemulihan bermula dari awal, berpotensi memanjangkan jumlah masa pemulihan.

11. Betulkan #8: Baiki Pangkalan Data dengan Melepas dan Menyambung Semula

Untuk kes yang melampau, tanggalkan dan pasang semula pangkalan data:

Tanggalkan pangkalan data: EXEC sp_detach_db 'YourDatabaseName';
Lampirkan hanya fail MDF: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
Ini membina semula log transaksi baharu

Amaran: Kaedah ini boleh mengakibatkan kehilangan data. Hanya gunakan apabila pilihan lain sudah habis.

12. Betulkan #9: Mengendalikan Isu Pencerminan Pangkalan Data

Konfigurasi pencerminan pangkalan data boleh menyebabkan masalah pemulihan yang unik. Pembetulan ini menangani isu khusus pencerminan yang mengekalkan pangkalan data dalam keadaan pemulihan.

12.1 Masalah Pemulihan Khusus Pencerminan

Pangkalan data bercermin mungkin tersekat dalam pemulihan disebabkan masalah sambungan rakan kongsi atau masalah titik akhir. Kedua-dua pangkalan data utama dan cermin boleh menunjukkan status pemulihan.

12.2 Mencerminkan Penyelesaian Pemulihan

Mulakan semula titik akhir pencerminan:

Cari nama titik akhir: SELECT * FROM sys.endpoints WHERE type = 4;
Hentikan titik akhir: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
Titik akhir mula: ALTER ENDPOINT [EndpointName] STATE = STARTED;

Jika permulaan semula titik akhir gagal, putuskan perkongsian pencerminan:

Laksanakan: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
Jalankan: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
Konfigurasikan semula pencerminan setelah pangkalan data berada dalam talian

13. Betulkan #10: Gunakan Alat Pemulihan Profesional

Alat pemulihan pihak ketiga menyediakan keupayaan pembaikan lanjutan apabila terbina dalam SQL Server kaedah gagal. Alat ini selalunya boleh memulihkan data daripada pangkalan data yang rosak teruk.

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery mempunyai kadar pemulihan yang tinggi, bersama-sama dengan pilihan yang komprehensif.

Berikut adalah langkah-langkah untuk menggunakannya:

Hentikan SQL Server Perkhidmatan.
Buat salinan fail pangkalan data dalam mod pemulihan, termasuk kedua-dua fail MDF utama dan fail NDF kedua.
Mulakan SQL Server Perkhidmatan.
Start DataNumen SQL Recovery.
Pilih salinan, bukannya fail asal, sebagai sumber pangkalan data untuk dipulihkan.
Klik “Mulakan Pemulihan” dan ikut arahan untuk memulihkan pangkalan data.
Selepas proses pemulihan, pangkalan data pemulihan baharu akan muncul dalam SQL Server yang mengandungi semua data yang dipulihkan.

13.2 Bila Perlu Pertimbangkan Alat Pihak Ketiga

Gunakan alat profesional apabila:

Pilihan pembaikan terbina dalam gagal atau melaporkan rasuah yang meluas
Tiada sandaran terbaru tersedia
Data kritikal mesti dipulihkan walaupun terdapat rasuah
Kaedah pemulihan standard mengakibatkan kehilangan data yang ketara

14. Amalan Terbaik Pencegahan

14.1 Tugas Penyelenggaraan Berkala

Laksanakan amalan ini untuk mencegah SQL Server pangkalan data dalam isu pemulihan:

Jadualkan sandaran penuh dan log tetap: Mengekalkan rantaian sandaran yang lengkap
Pantau kiraan VLF: Pastikan VLF di bawah 100 untuk prestasi optimum
Pelan saiz fail log: Log pra-saiz untuk mengelakkan autogrowth yang berlebihan
Jalankan DBCC CHECKDB biasa: Mengesan rasuah lebih awal

14.2 Pemantauan dan Makluman

Sediakan pemantauan proaktif:

Konfigurasikan makluman untuk perubahan keadaan pangkalan data
Pantau ruang cakera pada pemacu fail log
Jejaki transaksi yang telah lama berjalan
Makluman tentang kiraan VLF yang berlebihan

14.3 Perkakasan dan Infrastruktur

Memastikan infrastruktur yang boleh dipercayai:

Gunakan storan pantas untuk log transaksi (sebaik-baiknya SSD)
Laksanakan bekalan kuasa berlebihan
Asingkan data dan fail log pada pemacu yang berbeza
Pertimbangkan penyelesaian ketersediaan tinggi seperti Sentiasa Mengenai Kumpulan Ketersediaan

15. Menyelesaikan Masalah Senario Kompleks

15.1 Pelbagai Isu Pangkalan Data

Apabila berbilang pangkalan data tersekat dalam pemulihan:

Semak isu seluruh sistem (ruang cakera, memori)
Utamakan pangkalan data kritikal untuk pemulihan
Pertimbangkan masalah perkakasan yang menjejaskan keseluruhan contoh
Semak perubahan atau kemas kini sistem terkini

15.2 Pertimbangan Pangkalan Data Besar

Untuk pangkalan data melebihi 1TB:

Jangkakan masa pemulihan yang lebih lama (berkemungkinan hari)
Pastikan peruntukan memori mencukupi
Pertimbangkan tetapan pemprosesan selari
Pantau ruang tempdb semasa pemulihan

15.3 Bila Perlu Menghubungi Sokongan Microsoft

Hubungi Sokongan Microsoft untuk:

Sistem pengeluaran kritikal tanpa pilihan sandaran
Diharapkan SQL Server bug perisian
Persekitaran perusahaan yang memerlukan pemulihan yang terjamin
Kompleks Sentiasa Hidup atau senario kelompok

16. Soalan Lazim

S: Berapa lama sepatutnya SQL Server pemulihan pangkalan data biasanya diambil?

J: Masa pemulihan bergantung pada saiz pangkalan data, volum transaksi dan prestasi perkakasan. Pangkalan data kecil biasanya pulih dalam beberapa minit, manakala pangkalan data besar dengan log transaksi yang luas mungkin mengambil masa beberapa jam. Anggaran masa yang ditunjukkan dalam log ralat selalunya tidak tepat, jadi fokus pada peratusan kemajuan.

S: Boleh saya berhenti SQL Server semasa pemulihan tanpa kehilangan data?

A: Berhenti SQL Server semasa pemulihan secara amnya selamat tetapi akan memulakan semula proses pemulihan dari awal apabila perkhidmatan dimulakan semula. Ini memanjangkan jumlah masa pemulihan tetapi tidak menyebabkan kehilangan data tambahan melebihi apa yang berlaku semasa insiden asal.

S: Apakah perbezaan antara "Dalam Pemulihan" dan "Pemulihan Menunggu"?

A: “Dalam Pemulihan” bermaksud SQL Server sedang giat menjalankan operasi pemulihan. “Pemulihan Belum Selesai” menunjukkan proses pemulihan gagal dimulakan, biasanya disebabkan oleh fail yang hilang, kebenaran yang tidak mencukupi atau masalah ruang cakera yang mesti diselesaikan sebelum pemulihan dapat diteruskan.

Anda boleh mendapatkan maklumat lebih terperinci tentang "Pemulihan Belum Selesai" dalam kami panduan komprehensif.

S: Adakah saya akan kehilangan data jika saya menggunakan REPAIR_ALLOW_DATA_LOSS?

J: Ya, REPAIR_ALLOW_DATA_LOSS boleh mengalih keluar data yang rosak untuk memulihkan konsistensi pangkalan data. Sentiasa cuba REPAIR_REBUILD dahulu, yang membetulkan isu struktur tanpa kehilangan data. Hanya gunakan REPAIR_ALLOW_DATA_LOSS sebagai pilihan terakhir apabila anda tidak mempunyai pilihan pemulihan lain.

S: Bolehkah saya mengakses pangkalan data lain semasa satu pangkalan data dalam pemulihan?

J: Ya, pangkalan data lain yang sama SQL Server contoh kekal boleh diakses semasa pemulihan. Hanya pangkalan data yang sedang menjalani pemulihan tidak tersedia. Walau bagaimanapun, operasi pemulihan mungkin memberi kesan kepada prestasi pelayan keseluruhan.

S: Apakah yang menyebabkan pangkalan data tersekat dalam mod pemulihan?

A: Punca biasa termasuk operasi pemulihan yang tidak lengkap menggunakan NORECOVERY, Fail Log Maya (VLF) yang berlebihan, urus niaga besar tanpa komitmen, rasuah pangkalan data, ruang cakera yang tidak mencukupi dan isu perkakasan. AUTO CLOSE pangkalan data yang didayakan juga mungkin kelihatan sentiasa memasuki pemulihan.

S: Bagaimanakah saya tahu sama ada pemulihan mencapai kemajuan atau tersekat?

A: Pantau SQL Server Log ralat untuk mesej kemajuan pemulihan yang menunjukkan peratusan penyiapan. Gunakan sys.dm_exec_requests untuk menyemak arahan STARTUP DB yang aktif. Jika peratusan meningkat dari semasa ke semasa, pemulihan sedang berjalan. Tiada entri log baharu selama beberapa jam mungkin menunjukkan proses tersekat.

S: Adakah selamat untuk dimulakan semula SQL Server perkhidmatan semasa pemulihan?

A: Mulakan semula adalah selamat tetapi harus digunakan dengan berhati-hati. Ia akan memulakan semula pemulihan dari awal, berpotensi menggandakan masa pemulihan. Hanya mulakan semula jika pemulihan kelihatan terhenti sepenuhnya tanpa kemajuan selama berjam-jam, atau jika anda mengesyaki proses itu benar-benar tersekat.

S: Apakah perbezaan antara AUTO CLOSE dan mod pemulihan?

J: AUTO CLOSE menutup pangkalan data secara automatik apabila tiada sambungan wujud, kemudian membukanya semula untuk sambungan baharu. Pembukaan berulang ini mencetuskan proses pemulihan ringkas setiap kali, menjadikannya kelihatan pangkalan data sentiasa dalam pemulihan. Melumpuhkan AUTO CLOSE menyelesaikan isu ini.

S: Bolehkah sandaran log transaksi membantu semasa pemulihan?

A: Sandaran log transaksi boleh mengosongkan ruang log jika pemacu log penuh, berpotensi membolehkan pemulihan diteruskan. Walau bagaimanapun, anda tidak boleh membuat sandaran log pangkalan data yang sedang dalam mod pemulihan. Sandaran log lebih berguna untuk pencegahan dan penyelenggaraan pasca pemulihan.

S: Bilakah saya harus menghubungi Sokongan Microsoft?

J: Hubungi Sokongan Microsoft untuk sistem pengeluaran kritikal yang kaedah pemulihan terbina dalam gagal, apabila anda mengesyaki SQL Server pepijat perisian, untuk kompleks Sentiasa Hidup atau senario pengelompokan, atau apabila persekitaran perusahaan memerlukan pemulihan data yang terjamin dengan masa henti yang minimum.

S: Bagaimanakah saya boleh menghalang pangkalan data daripada tersekat dalam pemulihan?

J: Laksanakan sandaran penuh dan log biasa, pantau dan urus kiraan VLF, pastikan ruang cakera yang mencukupi, gunakan prosedur penutupan yang betul, kekalkan kebolehpercayaan perkakasan, lumpuhkan AUTO CLOSE pada pangkalan data pengeluaran dan jalankan operasi DBCC CHECKDB biasa untuk mengesan rasuah lebih awal.

S: Apakah itu VLF dan mengapa ia menjejaskan pemulihan?

J: Fail Log Maya (VLF) ialah segmen dalaman dalam fail log transaksi. Terlalu banyak VLF (lebih 1,000) pemulihan yang perlahan kerana SQL Server mesti memproses setiap satu secara individu. Tetapan saiz fail log dan pertumbuhan yang betul membantu mengekalkan kiraan VLF yang optimum.

S: Bolehkah saya memulihkan daripada sandaran semasa pangkalan data dalam pemulihan?

J: Anda tidak boleh memulihkan melalui pangkalan data yang sedang dalam mod pemulihan. Anda mesti sama ada menunggu pemulihan selesai, hentikan SQL Server perkhidmatan, atau pulihkan kepada nama pangkalan data yang berbeza. Untuk situasi yang mendesak, pertimbangkan untuk memulihkan nama pangkalan data baharu dan kemudian menamakannya semula setelah isu pemulihan diselesaikan.

17. Kesimpulan dan Langkah Seterusnya

17.1 Ringkasan Penyelesaian Utama

Apabila anda SQL Server pangkalan data sedang dalam pemulihan, mulakan dengan pendekatan ini mengikut susunan:

Semak log ralat dan pantau kemajuan
Tunggu penyiapan semula jadi jika kemajuan adalah stabil
Gunakan PULIH DENGAN PEMULIHAN untuk pemulihan yang tidak lengkap
Atasi isu log transaksi
Jalankan DBCC CHECKDB atau alat profesional untuk rasuah
Pertimbangkan pemulihan sandaran untuk kes yang teruk

jambatan SQL Server db dalam situasi pemulihan menyelesaikan dalam beberapa jam menggunakan kaedah terbukti ini. Untuk senario yang rumit, jangan teragak-agak untuk menggunakan teknik lanjutan atau alat profesional.

17.2 Sumber Tambahan

Untuk bantuan lebih lanjut:

microsoft SQL Server dokumentasi
SQL Server Forum Komuniti
Blog pentadbiran pangkalan data dan sumber teknikal
Perkhidmatan pemulihan pangkalan data profesional

Penyelenggaraan dan pemantauan yang kerap dapat mencegah kebanyakan masalah pemulihan. Laksanakan amalan pencegahan yang digariskan dalam panduan ini untuk meminimumkan kejadian MS SQL dalam masalah pemulihan pada masa hadapan.

Mengenai Penulis

Yuan Sheng ialah pentadbir pangkalan data kanan (DBA) dengan lebih 10 tahun pengalaman dalam SQL Server persekitaran dan pengurusan pangkalan data perusahaan. Beliau telah berjaya menyelesaikan ratusan senario pemulihan pangkalan data merentas perkhidmatan kewangan, penjagaan kesihatan dan organisasi pembuatan.

Yuan pakar dalam SQL Server pemulihan pangkalan data, penyelesaian ketersediaan tinggi dan pengoptimuman prestasi. Pengalaman praktikalnya yang luas termasuk mengurus pangkalan data berbilang terabait, melaksanakan Kumpulan Ketersediaan Sentiasa Dihidupkan, dan membangunkan strategi sandaran dan pemulihan automatik untuk sistem perniagaan yang kritikal misi.

Melalui kepakaran teknikal dan pendekatan praktikalnya, Yuan menumpukan pada mencipta panduan komprehensif yang membantu pentadbir pangkalan data dan profesional IT menyelesaikan kompleks SQL Server cabaran dengan cekap. Dia kekal terkini dengan yang terkini SQL Server keluaran dan teknologi pangkalan data Microsoft yang sedang berkembang, menguji senario pemulihan secara kerap untuk memastikan cadangannya mencerminkan amalan terbaik dunia sebenar.

Ada soalan tentang SQL Server pemulihan atau memerlukan panduan penyelesaian masalah pangkalan data tambahan? Yuan mengalu-alukan maklum balas dan cadangan untuk menambah baik sumber teknikal ini.

SQL Server Pangkalan Data dalam Mod Pemulihan: 10 Pembetulan Terbukti [Panduan 2026]