web-dev-qa-db-ja.com

SQL Server：データベースが「復元中」状態のままになる

データベースをバックアップしました。

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

それからそれを復元しようとしました：

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

そして今、データベースは復元中の状態のままです。

バックアップにログファイルがないため、次のようにロールフォワードする必要があると考える人もいます。

RESTORE DATABASE MyDatabase
WITH RECOVERY

それ以外は、もちろん失敗します。

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.

そして、壊滅的な状況であなたが望んでいるのは、まさにうまくいかない復元です。

バックアップにはデータとログファイルの両方が含まれます。

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
sql-serverbackuprestore
531
Ian Boyd

データベースのRESTOREコマンドでWITH RECOVERYオプションを使用して、復元プロセスの一環としてデータベースをオンラインにする必要があります。

これは、トランザクションログのバックアップを復元するつもりがない場合、つまりデータベースのバックアップを復元してからデータベースにアクセスできるようにする場合に限り、もちろん可能です。

あなたの命令はこのように見えるべきです、

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

SQL Server Management Studioのデータベースの復元ウィザードを使用すると、さらに成功する可能性があります。このようにして、特定のファイルの場所、上書きオプション、およびWITH Recoveryオプションを選択できます。

415
John Sansom

Symantec Backup Exec 11dを使ってデータベースをSQL Server 2005 Standard Editionインスタンスに復元する状況がありました。復元ジョブが完了した後、データベースは「復元中」の状態のままです。ディスク容量の問題はありませんでした - データベースは単に「復元中」状態から出ていませんでした。

SQL Serverインスタンスに対して次のクエリを実行したところ、データベースがすぐに使用可能になったことがわかりました。

RESTORE DATABASE <database name> WITH RECOVERY
645
Evan Anderson

これを行う方法は次のとおりです。

  1. サービスを停止します（MSSQLSERVER）。
  2. データベースとログファイル（C：¥Program Files¥Microsoft SQL Server¥MSSQL.1¥MSSQL¥Data ...）の名前を変更するか削除します。
  3. サービスを開始します（MSSQLSERVER）。
  4. 問題のあるデータベースを削除してください。
  5. データベースをもう一度復元します。
96
Tipu Delacablu

私は、ログ配布のセカンダリサーバーを停止することで同様の事件を起こしました。ログ配布からサーバーを削除し、プライマリサーバーからのログ配布を停止するコマンドを実行した後、セカンダリサーバー上のデータベースがコマンド実行後に復元ステータスで停止しました

RESTORE DATABASE <database name> WITH RECOVERY

データベースメッセージ：

RESTORE DATABASEは18.530秒で0ページを正常に処理しました（0.000 MB /秒）。

データベースはそれらの18秒後に再び使用可能になりました。

82
Hans

SQL Management Studioを使用した復元でも同様の問題がありました。データベースのバックアップを別の名前の新しいバックアップに復元しようとしました。最初はこれが失敗し、新しいデータベースのファイル名を修正した後に正常に実行されました。いずれにせよ、私が説明した問題は、最初からこの権利を得たとしても再発しました。したがって、復元後、元のデータベースの名前の横に（Restoring ...）が残りました。上記のフォーラム（Bhusan's）の回答を考慮して、私は以下の側のクエリエディタで実行してみました：

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

これで問題は解決しました。データベース名に特殊文字が含まれているため、最初は問題がありました。二重引用符を前後に追加することでこれを解決しました - 一重引用符では「構文が正しくありません...」というエラーが表示されません。

これは私がこの問題を解決しようと試みた最小の解決策であり（データベースを復元中の状態で動かなくしている）、それがより多くのケースに適用できることを私は望んでいる。

71
Demetris Leptos

OK、私はPaukの場合と全く同じ問題を抱えています。それは復元中にサーバがディスクスペースを使い果たしたために発生したため、永久的な復元状態を引き起こしました。 SQL Serverサービスを停止せずにこの状態を終了する方法

解決策が見つかりました:)

Drop database *dbname*
34
Marko

RESTORE DATABASE/RESTORE LOGコマンドが実行されると、WITH RECOVERYオプションがデフォルトで使用されます。 「復元」プロセスで動けなくなった場合は、次のコマンドを実行してデータベースをオンライン状態に戻すことができます。

RESTORE DATABASE YourDB WITH RECOVERY
GO

複数のファイルを復元する必要がある場合、CLIコマンドにはそれぞれWITH NORECOVERYおよびWITH RECOVERYが必要です。データベースをオンラインに戻すには、command内の最後のファイルだけにWITH RECOVERYが必要です。

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

SQL Server Management Studioウィザードも使用できます。

enter image description here

仮想復元プロセスもありますが、サードパーティのソリューションを使用する必要があります。通常、データベースのバックアップをオンラインのライブデータベースとして使用できます。 ApexSQLとIderaには独自のソリューションがあります。 SQL Hammerによるレビュー ApexSQL復元について 。大量のバックアップを処理している場合は、仮想リストアが優れた解決策です。復元プロセスははるかに高速であり、またディスクドライブ上のスペースを大幅に節約することができます。比較のために infographic を見てください。

29
Marko Krstic

これはかなり明白かもしれませんが、それは今私をつまずきました：

ログ末尾のバックアップを取っている場合は、SSMSの復元ウィザードでこのオプションをオンにして「ソースデータベースを復元状態のままにしておく（WITH NORECOVERY）」の場合もあります。

enter image description here

23
TrailJon

私はその理由を考え出しました。

RESTORE DATABASEコマンドを発行したクライアントが復元中に切断した場合、復元は停止します。

クライアント接続によってデータベースを復元するように指示されたときに、クライアントがずっと接続されたままでない限り、サーバーが復元を完了しないことは奇妙です。

15
Ian Boyd

これはうまくいった：

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

データベースに復元状態が表示され、クエリを実行できず、ソフトウェアに接続できないという状況がありました。

この状況から抜け出すために私がしたことは、

  1. WindowsサービスからすべてのSQL関連サービスを停止します。

  2. LdfファイルとMdfファイルがSQLディレクトリにあるDATAフォルダを開きました。通常は "C：\ Program Files ***********\MSSQL\DATAです。

  3. その後、データベースのLdfファイルとMdfファイルの両方をコピーしました。[db name] .mdfと[db name] _log.ldf

両方のファイルを別のフォルダにコピーしました。

  1. それから私は（ステップ1で）すべてのSQL関連サービスをWindowsサービスから再開しました。

  2. 通常のログインで私のMS SQL Management studioを始めました。

  3. 原因となるデータベースを右クリックしてDELETEを押します（データベースを完全に削除します）。

  4. このデータベースに関連するすべてのLDFファイルとMDFファイルは、DATAフォルダから取得されています（手順2で説明）。

  5. 同じ名前の新しいデータベースを作成しました（手順6で削除したデータベースと同じ名前 - 原因データベース）。

  6. それから[データベース名] - >右クリック - >タスク - >オフラインにする。

  7. 次に、両方のファイルを（手順3から）DATAフォルダにコピーして戻しました（手順2）。

  8. [データベース名] - >右クリック - >タスク - >オンラインにする。

10
Ameen Abuhilal

持っていた 。私のデータベース名では、そのためにクエリが機能しませんでした（ '。'の近くに不正確な構文を言って）そして、私は名前のための括弧が必要であることに気づきました：

RESTORE DATABASE [My.DB.Name] WITH RECOVERY
6
Ashkan Sirous

私の場合は、 データベースを削除するだけで十分でした 状態で停止していました "復元しています..." SQLコマンドで

 drop database <dbname>

クエリウィンドウで。

次に、 データベース を右クリックし、 更新 を選択してManagement Studioのエントリを削除しました。その後、私はうまくいった新しい復元をしました（それをオフラインにしてもうまくいきませんでした、SQLサービスの再起動はうまくいきませんでした、サーバー再起動もうまくいきませんでした）。

5
Matt

デフォルトでは、すべてのRESTORE DATABASEにRECOVERYが設定されています。 'NORECOVERY'オプションは、基本的にSQL Serverに、データベースがもっと多くのリストアファイル（DIFFファイルとLOGファイル、そしてtailを含めることができる）を待っていることを伝えます。可能であれば、-logバックアップファイル）。 'RECOVERY'オプションは、すべてのトランザクションを終了し、データベースがトランザクションを実行できるようにします。

そう：

  1. データベースにSIMPLE復旧モデルが設定されている場合は、DIFFがある場合にのみFULLリストアをNORECOVERYオプションで実行できます。 _バックアップ。 SIMPLEリカバリモデルデータベースでは、LOGバックアップは許可されません。
  2. それ以外の場合、データベースがFULLまたはBULK-LOGGED復旧モデルで設定されている場合は、FULL restoreの後にNORECOVERYオプションを実行します。 DIFFに続けてNORECOVERYを実行し、最後にRECOVERYオプションを指定してLOG restoreを実行します。

覚えておいて、最後の復元クエリはRECOVERYオプションを持たなければならない。それは明示的な方法でもそうでなくてもかまいません。 T-SQLの問題では、

  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

WITH REPLACEオプションはデータの損失につながる可能性があるため注意して使用する必要があります

あるいは、FULLおよびDIFFバックアップを実行する場合は、これを使用できます。

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

もちろん、オプションSTATS = 10を使用して復元を実行することもできます。これは、10％完了ごとに報告するようにSQL Serverに指示します。

お望みであれば、プロセスを観察したり、リアルタイムのクエリで復元したりできます。次のように：

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

この助けを願っています。

3
BMDaemon

イベントログにTCPエラーが記録されたときにも、この問題が発生しています...

SQLでDBを削除するか、マネージャの「削除」でそれを右クリックして、再度復元します。

私は実際にこれをデフォルトで始めました。 DBドロップをスクリプト化し、再作成してから復元します。

3
ZeusT

スナップショットが有効になっていると、動かなくなったデータベースの削除に問題が生じる可能性もあります。私にとってこれはうまくいった：

  1. 最初に Tipu Delacablu stepsをフォローしました。
  2. 実行コマンド：drop database [your database]。スナップショットデータベースの名前を知らせるエラーが表示されます。
  3. run command：drop database [snapshot database]してから、手順2のコマンドをもう一度実行します。
2
Martin

あなたは唯一の検証を実行してみましたか？それが確実なバックアップであることを確認するためだけに。

http://msdn.Microsoft.com/ja-jp/library/ms188902.aspx

1
Sam

素晴らしい議論。最大ユーザーが行う最も一般的な間違いは、複数のバックアップを持つリカバリオプションを使用してデータベースを復元することです。これにより、データベースはRESTORING状態になります。

ポイントインタイムリカバリを実行している場合は、最初にRestore with NoRecoveryを実行してください。最後のバックアップオプションでは、Restore with Recoveryを使用する必要があります。

バックアップと復元について reference1 と reference2 を読んでください。

0
Sean Smith

私は同じ問題を抱えていました...私のドライブがいっぱいでなかったので私のデータベースがなぜこの問題を経験したかわかりませんが…それはそれが破損したか何かになったようです。上記のすべてを試してみましたが、どれも完全にはうまくいきませんでした。特に、サービスを停止してmdfファイルとldfファイルを削除するという提案はうまくいくと思いました。

前述のようにファイルを削除することでこの問題を解決しましたが、再度DBを復元するのではなく、新しい.mdfファイルと.ldfファイルを上書きコピーし、フロントエンド添付ファイルウィザードを使用してこれらを添付しました。安心、うまくいった！

私が仮想マシンを使用しているときに新しいファイルをコピーするのにFOREVERがかかりました...そのため、クリップボードを使用したコピーと貼り付けには1時間かかるので、最後の試みとしてのみお勧めします。

0
Anthony Griggs

SQL Expressライセンスの制限により、MyDbName（Restoring ...）のケースがあります。

ログファイルで、これを見つけました。

CREATE DATABASEまたはALTER DATABASE 失敗したため結果の累積データベースサイズは10240 MBのライセンス制限を超えるデータベースごとになります。

したがって、より大きなデータベースを復元しようとしている場合は、たとえば、SQL ExpressサーバーをDeveloperエディションに切り替える必要がありますなどです。

0
Dmitry Pavlov

WITH RECOVERYベースのオプションはすべて私にとってはうまくいきませんでした。

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
earthling42
  1. 最初にSQL Agent Serviceをチェックして実行しましょう。

  2. 以下のT-SQLを使用します。

    ファイル名をmaster.sys.sysaltfilesから選択します。WHERE dbid = DB_ID（ 'db_name'）;

  3. T-SQLを継続的に使用する

    RESTART、REPLACEを使用してDISK = 'DB_path'からデータベースを復元します。

この助けを願っています！

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

私にとってそれを直したのは

  1. インスタンスを停止する
  2. dataフォルダに.mdfファイルと.ldfファイルのバックアップを作成します。
  3. インスタンスを再起動します
  4. 復元したデータベースを削除する
  5. .mdfファイルと.ldfファイルをデータフォルダーに戻します。
  6. インスタンスを.mdfファイルと.ldfファイルに添付します。
0
ChadJPetersen