SQL Server: Database macet dalam keadaan "Memulihkan"

Saya membuat cadangan basis data:

BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing

Dan kemudian mencoba mengembalikannya:

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE --force restore over specified database

Dan sekarang database macet dalam keadaan memulihkan.

Beberapa orang berteori bahwa itu karena tidak ada file log di cadangan, dan itu perlu digulung ke depan menggunakan:

RESTORE DATABASE MyDatabase
WITH RECOVERY 

Kecuali itu, tentu saja, gagal:

Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Dan apa yang Anda inginkan dalam situasi bencana adalah pemulihan yang tidak akan berhasil.

Cadangan berisi data dan file log:

RESTORE FILELISTONLY 
FROM DISK = 'MyDatabase.bak'

Logical Name    PhysicalName
=============   ===============
MyDatabase    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log  C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF

Anda perlu menggunakan WITH RECOVERYopsi, dengan RESTOREperintah basis data Anda , untuk menjadikan basis data Anda online sebagai bagian dari proses pemulihan.

Ini tentu saja hanya jika Anda tidak bermaksud untuk memulihkan cadangan log transaksi apa pun, yaitu Anda hanya ingin mengembalikan cadangan database dan kemudian dapat mengakses database.

Perintah Anda akan terlihat seperti ini,

RESTORE DATABASE MyDatabase
   FROM DISK = 'MyDatabase.bak'
   WITH REPLACE,RECOVERY

Anda mungkin lebih berhasil menggunakan panduan pemulihan database di SQL Server Management Studio. Dengan cara ini Anda dapat memilih lokasi file tertentu, opsi menimpa, dan opsi DENGAN Pemulihan.

Saya mengalami situasi ini memulihkan database ke contoh SQL Server 2005 Edisi Standar menggunakan Symantec Backup Exec 11d. Setelah pekerjaan pemulihan selesai, database tetap dalam status "Memulihkan". Saya tidak punya masalah ruang disk - database tidak keluar dari keadaan "Memulihkan".

Saya menjalankan kueri berikut terhadap contoh SQL Server dan menemukan bahwa database segera dapat digunakan:

RESTORE DATABASE <database name> WITH RECOVERY

Begini cara melakukannya:

1. Hentikan layanan (MSSQLSERVER);
2. Ganti nama atau hapus file Database dan Log (C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...) atau di mana pun Anda memiliki file;
3. Mulai layanan (MSSQLSERVER);
4. Hapus database yang bermasalah;
5. Kembalikan database lagi.

Saya mengalami kejadian serupa dengan menghentikan server sekunder pengiriman log. Setelah perintah untuk menghapus server dari pengiriman log dan menghentikan pengiriman log dari server primer database pada server sekunder terjebak dalam memulihkan status setelah perintah

RESTORE DATABASE <database name> WITH RECOVERY

Pesan basis data:

RESTORE DATABASE berhasil memproses 0 halaman dalam 18,530 detik (0,000 MB / detik).

Basis data dapat digunakan kembali setelah 18 detik tersebut.

Saya punya masalah serupa dengan memulihkan menggunakan SQL Management Studio. Saya mencoba mengembalikan cadangan database ke yang baru dengan nama yang berbeda. Pada awalnya ini gagal dan setelah memperbaiki nama file database baru itu berhasil dilakukan - dalam hal apapun masalah yang saya jelaskan kembali terjadi bahkan jika saya mendapatkan ini benar dari pertama kali. Jadi, setelah restorasi, database asli tetap dengan (Memulihkan ...) di sebelah namanya. Mempertimbangkan jawaban-jawaban dari forum di atas (Bhusan's), saya mencoba menjalankan editor permintaan di samping sebagai berikut:

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

yang memperbaiki masalah ini. Saya mengalami kesulitan pada awalnya karena nama database yang berisi karakter khusus. Saya menyelesaikan ini dengan menambahkan tanda kutip ganda di sekitar - tanda kutip tunggal tidak akan berfungsi memberikan kesalahan "Sintaks salah dekat ...".

Ini adalah solusi minimal yang saya coba untuk menyelesaikan masalah ini (database macet dalam keadaan memulihkan) dan saya harap ini dapat diterapkan pada lebih banyak kasus.

OK, saya memiliki masalah yang sama dan persis seperti dalam kasus Pauk, itu disebabkan oleh server kehabisan ruang disk saat memulihkan dan menyebabkan keadaan pemulihan permanen. Bagaimana mengakhiri keadaan ini tanpa menghentikan layanan SQL Server?

Saya telah menemukan solusinya :)

Drop database *dbname*

DENGAN opsi RECOVERY digunakan secara default ketika perintah RESTORE DATABASE / RESTORE LOG dijalankan. Jika Anda terjebak dalam proses "memulihkan", Anda dapat mengembalikan database ke status online dengan menjalankan:

RESTORE DATABASE YourDB WITH RECOVERY
GO

Jika ada kebutuhan untuk mengembalikan beberapa file, perintah CLI masing-masing memerlukan DENGAN NORECOVERY dan DENGAN PEMULIHAN - hanya file terakhir dalam perintah yang HARUS DENGAN PEMULIHAN untuk mengembalikan database online:

RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO

Anda dapat menggunakan wisaya SQL Server Management Studio juga:

Ada juga proses pemulihan virtual, tetapi Anda harus menggunakan solusi pihak ke-3. Biasanya Anda dapat menggunakan cadangan basis data sebagai basis data online hidup. ApexSQL dan Idera memiliki solusi sendiri. Ditinjau oleh SQL Hammer tentang ApexSQL Restore . Pemulihan virtual adalah solusi yang baik jika Anda berurusan dengan sejumlah besar cadangan. Proses pemulihan jauh lebih cepat dan juga dapat menghemat banyak ruang pada disk drive. Anda dapat melihat infografis di sini untuk perbandingan.

Ini mungkin cukup jelas, tetapi itu membuat saya tersandung sekarang:

Jika Anda mengambil cadangan tail-log, masalah ini juga dapat disebabkan oleh opsi ini diperiksa di wisaya Pemulihan SSMS - "Biarkan basis data sumber dalam kondisi pemulihan (DENGAN NORECOVERY)"

Saya menemukan alasannya.

Jika klien yang mengeluarkan RESTORE DATABASE perintah terputus selama pemulihan, pemulihan akan macet.

Aneh bahwa server, ketika diberitahu untuk mengembalikan database dengan koneksi klien, tidak akan menyelesaikan pemulihan kecuali klien tetap terhubung sepanjang waktu.

yang ini berhasil:

http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/8dd1b91d-3e14-4486-abe6-e3a550bfe457

Saya mengalami situasi di mana database saya menunjukkan status pemulihan dan saya tidak bisa menjalankan pertanyaan apa pun dan tidak bisa terhubung dengan perangkat lunak kami.

Apa yang saya lakukan untuk keluar dari situasi ini adalah:

1. Hentikan semua layanan terkait SQL dari layanan windows.

2. Saya membuka folder DATA tempat file Ldf dan Mdf berada di direktori SQL, biasanya seperti: "C: \ Program Files *********** \ MSSQL \ DATA

3. Kemudian saya menyalin file Ldf dan Mdf dari database: [nama db] .mdf dan [nama db] _log.ldf

Saya menyalin kedua file ini ke folder lain.

4. Kemudian saya memulai semua layanan terkait SQL (pada langkah 1) lagi dari layanan windows.

5. Memulai studio MS SQL Management saya dengan login normal.

6. Klik kanan pada database pelakunya dan tekan DELETE (untuk menghapus database sama sekali).

7. Semua file LDF dan MDF yang terkait dengan database ini telah hilang dari folder DATA (disebutkan dalam langkah 2).

8. Membuat database baru dengan nama yang sama (nama yang sama dengan yang saya hapus pada langkah 6 - database pelakunya).

9. Kemudian [nama database] -> klik kanan -> tugas -> Ambil Offline.

10. Saya kemudian menyalin kedua file (dari langkah 3) kembali ke folder DATA (langkah 2).

11. [nama database] -> klik kanan -> tugas -> Bawa Online.

Saya punya. dalam nama basis data saya, dan kueri tidak berfungsi karena itu (mengatakan sintaks salah dekat '.') Kemudian saya menyadari bahwa saya memerlukan braket untuk nama:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

Dalam kasus saya, itu cukup untuk menjatuhkan basis data yang menggantung dalam keadaan "Memulihkan ..." dengan perintah SQL

 drop database <dbname> 

di jendela permintaan.

Kemudian saya mengklik kanan pada Databases dan memilih Refresh yang menghapus entri di Management Studio. Setelah itu saya melakukan pemulihan baru yang berfungsi dengan baik (perhatikan bahwa membuatnya offline tidak berfungsi, restart layanan SQL tidak berfungsi, server reboot tidak berfungsi juga).

Saya punya masalah ini ketika saya juga menerima kesalahan TCP di log peristiwa ...

Jatuhkan DB dengan sql atau klik kanan di atasnya di "hapus" manajer dan mengembalikan lagi.

Saya sebenarnya sudah mulai melakukan ini secara default. Script drop DB, buat kembali dan kemudian kembali.

Secara default, setiap RESTORE DATABASEdilengkapi dengan RECOVERYpengaturan. Opsi 'NORECOVERY', pada dasarnya memberitahu SQL Server bahwa database sedang menunggu lebih banyak file restore (bisa berupa file DIFF dan LOG file dan, dapat menyertakan file cadangan tail-log, jika mungkin). Opsi 'PEMULIHAN', selesaikan semua transaksi dan biarkan database siap melakukan transaksi.

Begitu:

1. jika basis data Anda diatur dengan model pemulihan SEDERHANA , Anda hanya dapat melakukan opsi pengembalian LENGKAPNORECOVERY , ketika Anda memiliki cadangan DIFF . Tidak ada cadangan LOG yang diizinkan dalam SIMPLE basis data model pemulihan .
2. Jika tidak, jika database Anda diatur dengan model pemulihan FULL atau BULK-LOGGED , Anda dapat melakukan pengembalian LENGKAP diikuti oleh NORECOVERYopsi, kemudian melakukan DIFF diikuti oleh NORECOVERY, dan, akhirnya, lakukan pengembalian LOG dengan RECOVERYopsi.

Ingat, THE RESTORE TERAKHIR QUERY HARUS RECOVERYMEMILIH . Bisa dengan cara eksplisit atau tidak. Dalam term T-SQL, situasinya:

1.

 USE [master]
    GO
    RESTORE DATABASE Database_name 
    FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD, 
    RECOVERY -- This option could be omitted.
    GO

DENGAN opsi REPLACE harus digunakan dengan hati-hati karena dapat menyebabkan kehilangan data

Atau, jika Anda melakukan cadangan FULL dan DIFF, Anda dapat menggunakan ini

   USE [master]
    GO
    RESTORE DATABASE Database_name
      FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
       NOUNLOAD,NORECOVERY
    GO
    RESTORE DATABASE Database_name
      FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1, 
     NOUNLOAD, RECOVERY
    GO

 2. USE [master]
    GO
   -- Perform a Tail-Log backup, if possible. 
   BACKUP LOG Database_name
   GO
   -- Restoring a FULL backup
   RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1, 
     NOUNLOAD,NORECOVERY
  GO 
  -- Restore the last DIFF backup
  RESTORE DATABASE Database_name
    FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1,
     NORECOVERY,NOUNLOAD
  GO
  -- Restore a Log backup
  RESTORE LOG Database_name
    FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2,
    RECOVERY, NOUNLOAD
  GO

Tentu saja, Anda dapat melakukan pengembalian dengan opsi STATS = 10 yang memberitahu SQL Server untuk melaporkan setiap 10% selesai.

Jika Anda suka, Anda dapat mengamati proses atau mengembalikan dalam kueri berbasis waktu nyata. Sebagai berikut:

USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time 
    FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a 
        WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO

Semoga bantuan ini.

Mungkin juga ada masalah menghapus database yang macet jika snapshot diaktifkan. Bagi saya ini berhasil:

1. Pertama saya mengikuti langkah Tipu Delacablu (baca beberapa posting ke atas)
2. jalankan perintah: drop database [database Anda], yang akan memberi Anda kesalahan saat memberi tahu nama database snapshot
3. jalankan perintah: drop database [database snapshot], lalu jalankan perintah di langkah 2 lagi.

Sudahkah Anda mencoba menjalankan VERIFIKASI SAJA? Hanya untuk memastikan itu cadangan suara.

http://msdn.microsoft.com/en-us/library/ms188902.aspx

Saya sudah mendapatkan kasus MyDbName (Restoring ...) karena batas berlisensi SQL Express.

Dalam file log, saya menemukan ini:

BUAT DATABASE atau ALTER DATABASE gagal karena ukuran basis data kumulatif yang dihasilkan akan melebihi batas lisensi Anda sebesar 10240 MB per basis data.

Jadi, jika Anda mencoba mengembalikan basis data yang lebih besar, Anda perlu mengubah server SQL Express Anda ke edisi Pengembang misalnya.

Mengalami masalah serupa saat memulihkan database menggunakan studio manajemen server SQL dan macet ke mode pemulihan. Setelah beberapa jam pelacakan masalah, kueri berikut berhasil bagi saya. Kueri berikut mengembalikan basis data dari cadangan yang ada ke keadaan sebelumnya. Saya percaya, tangkapannya adalah memiliki file .mdf dan .log dalam direktori yang sama.

RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY

1. Biarkan periksa dan jalankan Layanan SQL Agent terlebih dahulu.

2. Menggunakan T-SQL berikut:

   SELECT filename FROM master.sys.sysaltfiles WHERE dbid = DB_ID ('db_name');

3. Menggunakan T-SQL terus menerus:

   KEMBALIKAN DATABASE DARI DISK = 'DB_path' DENGAN RESTART, REPLACE;

Semoga bantuan ini!

Semua opsi berbasis DENGAN PEMULIHAN tidak bekerja untuk saya.

Apa yang dilakukan adalah melakukan pengembalian lengkap dari Management Studio.

USE [master]
RESTORE DATABASE Sales_SSD
FROM  DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak' 
WITH  FILE = 1,  
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',  
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',  
NOUNLOAD,  REPLACE,  STATS = 5

Saya memiliki masalah yang sama ... walaupun saya tidak tahu mengapa database saya mengalami masalah ini karena drive saya tidak penuh ... Sepertinya rusak atau semacamnya. Saya mencoba semua di atas tidak ada yang sepenuhnya bekerja, saya terutama berpikir saran untuk menghentikan layanan dan menghapus file mdf dan ldf akan bekerja ... tetapi masih membeku saat dipulihkan?

Saya akhirnya menyelesaikan ini dengan menghapus file seperti yang disebutkan, tetapi alih-alih mencoba mengembalikan DB lagi saya menyalin file .mdf dan .ldf yang baru dan melampirkannya menggunakan wizard Front End Attachment. Relief, berhasil !!

Butuh SELAMANYA untuk menyalin file-file baru karena saya menggunakan Mesin Virtual ... jadi menyalin dan menempel menggunakan clipboard butuh waktu satu jam, jadi saya hanya akan merekomendasikan ini sebagai upaya terakhir.

Apa yang diperbaiki untuk saya adalah

1. menghentikan contoh
2. membuat cadangan file .mdf dan .ldf di folder data
3. Mulai ulang instance
4. hapus database yang macet pulihkan
5. mengembalikan file .mdf dan .ldf ke folder data
6. Lampirkan instance ke file .mdf dan .ldf

RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY

Gunakan perintah berikut untuk menyelesaikan masalah ini

RESTORE DATABASE [DatabaseName] WITH RECOVERY