SQL Server: Database macet dalam keadaan "Memulihkan"


564

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

3
Saya memiliki masalah yang sama persis dan semua solusi gagal. Menariknya, saya masuk ke server SQL secara langsung dan mengeluarkan DROP DATABASE dbperintah melalui SSMS dan berhasil (sebelumnya saya menggunakan SSMS dari komputer lain untuk mengeluarkan perintah). Saya menduga solusi lain akan berhasil juga.
Salman A

Jawaban:


437

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.


3
Saya tidak pernah harus menggunakan pernyataan pemulihan ketika melakukan apa yang dia lakukan. DENGAN REPLACE harus cukup.
Sam

8
Ya, saya menggunakan NORECOVERY tetapi proses pemulihan macet. Menggunakan DENGAN PEMULIHAN, GANTI itu tidak menggantung proses lagi
Junior Mayhé

Ini menyelesaikan masalah saya. Kami mengalami kegagalan SAN di tengah pemulihan dan ini adalah solusi cepat dan bersih.
Pengguna Terdaftar

Saya memiliki masalah yang sama hari ini dengan database SQL Server 2005. Dalam kasus saya, saya harus menambahkan ', RESTART' ke klausa WITH, untuk menyelesaikan masalah. Itu memberi saya pesan kesalahan yang menyatakan bahwa operasi sebelumnya tidak berhasil.
XpiritO

3
@FistOfFury Jika operasi pemulihan sebelumnya pada database yang sama dalam keadaan ditangguhkan / tidur maka ya. Cukup menghentikan / membatalkan pemulihan proses harus memiliki efek yang sama.
John Sansom

692

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

4
Kami memiliki DB yang macet selama 2 jam. Kami menjalankan perintah ini dari mesin yang berbeda melawan master dan itu memperbaiki kami. Terima kasih!
Pete

11
+1, dengan gotcha. Ketika saya menjalankan ini, saya mendapat pesan kesalahan yang mengatakan bahwa database sudah sepenuhnya pulih. Tapi itu masih menunjukkan status "Pemulihan". Jadi saya klik kanan di Management Studio, tekan Refresh dan itu kembali normal.
dario_ramos

2
Saya dipulihkan menggunakan wizard Studio Mng, memasukkan nama database baru tetapi secara tidak sengaja meninggalkan nama file sama dengan database yang ada. Saya mendapat kesalahan "restore gagal tetapi log tail berhasil" dan database yang dilampirkan ke file-file itu macet dalam keadaan memulihkan. Perintah ini tampaknya telah memulihkan database ke keadaan sebelumnya.
Chris

3
Ini berhasil. Saya mencoba mengembalikan cadangan ke database sisi, tetapi database utama saya masuk ke keadaan memulihkan karena alasan tertentu. Ini sebenarnya memulihkan DB saya. Terima kasih banyak!
Aravindh

2
Beberapa wizard pengembalian SSMS default akan membuat sumber DB dalam keadaan memulihkan sehingga Anda dapat terus memulihkan berbagai cadangan atau log tanpa takut pengguna, dan perintah ini adalah cara yang tepat untuk mengembalikan DB ke normal setelah Anda selesai.
Tim Lehner

102

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.

Tipu, terima kasih untuk itu. Saya punya masalah yang mirip dengan poster asli, tapi itu disebabkan oleh server kehabisan ruang disk sementara memulihkan dan menyebabkan keadaan pemulihan permanen.
Pauk

8
Mengapa tidak drop saja database? Dengan begitu Anda tidak perlu menghentikan layanan.
ErikE

8
@ErikE Bagi saya, SQL server mengatakan tidak dapat menjatuhkan basis data di tengah pemulihan, meskipun tidak benar-benar memulihkan ....
Erik Philips

@ ErikPhilips Dalam hal ini saya kira seseorang kembali untuk menghentikan layanan. Saya bertanya-tanya apakah itu terjadi setiap waktu atau hanya dalam kasus-kasus tertentu dari masalah macet-pulihkan.
ErikE

5
Dalam kasus saya, itu cukup untuk menjatuhkan database yang menggantung dalam keadaan "Memulihkan ..." dengan perintah SQL drop database <dbname>di jendela kueri. 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).
Matt

84

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.


6
Terutama berguna ketika Anda sudah memulihkan database tetapi lupa opsi PEMULIHAN ...
JBickford

2
Ini semua yang saya butuhkan untuk meninggalkan status "Memulihkan" setelah memulihkan cadangan database ini ke nama DB yang berbeda. Terima kasih banyak.
Sean

81

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.


2
Bekerja dengan sempurna - tanpa perlu merobohkannya dan naik lagi. 3 Dbs 80+ Gb masing-masing membutuhkan waktu! Terima kasih!
Christer

1
Saya hampir melakukannya di lingkungan produksi. Saya mencobanya pada lokal pertama, berakhir pada situasi yang sama dan menemukan komentar Anda. Hal yang dipelajari: Gunakan skrip dan jangan percaya pada SSMS dalam situasi penting.
Mariusz

1
Saya mendapatkan masalah ini ketika mengembalikan file salinan-saja cadangan dari database ke database baru. Basis data asli menunjukkan kesalahan. Solusi ini berhasil dan respons yang saya dapatkan adalah "KEMBALIKAN DATABASE berhasil memproses 0 halaman dalam 0,263 detik (0,000 MB / detik)." , jadi sepertinya SQL Server hanya bingung tentang keadaan database.
R. Schreurs

1
Bekerja untuk saya tetapi hanya ketika saya menghapus tanda kutip ganda - Saya baru saja [MY_DB_NAME] sebagai parameter.
StackOverflowUser

34

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*

29

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:

masukkan deskripsi gambar di sini

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.


23

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)"

masukkan deskripsi gambar di sini


7
Jika Anda berada dalam kondisi ini, maka taruhan terbaik Anda adalah: 1. Klik kanan database, buka Tugas-> Pulihkan-> Log Transaksi 2. Temukan file cadangan yang digunakan untuk Tail Log back up 3. Restore cadangan Pemulihan harus berhasil dan mengembalikan database online.
Ryan Gross

16

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.


10
Semua Perintah SQL mengharuskan klien tetap terhubung sepanjang waktu.
mrdenny

2
@ Mrdenny: saya akan berasumsi bahwa perubahan dibatalkan ketika klien terputus.
Ian Boyd

Saya memiliki masalah yang sama menjalankan perintah ini dengan driver PHP PDO dari microsoft. namun ketika dijalankan dengan studio manajemen server microsoft sql Ia bekerja dengan baik. Saya bertanya-tanya bagaimana cara membuat aplikasi php saya terhubung sepanjang waktu?
channa ly

Terjadi di sini juga, DB terjebak dalam mengembalikan / pengguna-tunggal setelah koneksi terputus. Membunuh semua SPID lain dari sesi baru tetapi masih macet. Mampu menjatuhkan database sebagai solusi.
crokusek

10

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.

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

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

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

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

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

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

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

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


Ini juga berhasil bagi saya. Pada langkah 10, saya memilih untuk menimpa file yang ada.
Divi perdomo

8

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

5

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).


3

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.


3

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.


2

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.


1

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.


Itu adalah database TFS dan klien TFS sudah memberi tahu saya: Database penuh.
cskwg

1

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

0
  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!


0

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

0

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.


0

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

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

Harap tunjukkan wawasan tambahan yang diberikan oleh jawaban ini bila dibandingkan dengan jawaban yang lebih lama, diterima, dan sangat tervotifikasi. Itu akan membantu untuk menghindari kesan baru saja menyalinnya dengan harapan mendapatkan reputasi. Juga, jawaban hanya kode (yang merupakan perbedaan utama yang terlihat) tidak dihargai di sini, karena mereka memberikan kesan yang salah bahwa StackOverflow adalah layanan penulisan kode gratis,
Yunnosch

Saya memperbaiki format, hanya untuk membuat kesamaan dengan jawaban yang lebih lama menjadi lebih jelas. Tetapi Anda bisa belajar melakukannya di sini stackoverflow.com/editing-help jika Anda mencoba membuat jawaban yang lebih mudah dibaca di masa mendatang.
Yunnosch

0

Gunakan perintah berikut untuk menyelesaikan masalah ini

RESTORE DATABASE [DatabaseName] WITH RECOVERY
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.