SQL Server:データベースが「復元中」の状態のまま


564

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

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

3
私はまったく同じ問題を抱えていて、すべての解決策が失敗しました。興味深いことに、SQLサーバーに直接ログオンし、DROP DATABASE dbSSMSを介してコマンドを発行し、それが機能しました(以前は別のマシンからSSMSを使用してコマンドを発行していました)。他の解決策もうまくいくと思います。
Salman A

回答:


437

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

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

コマンドは次のようになります。

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

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


3
彼がしていることをしているとき、私は回復ステートメントを使う必要がなかった。WITH REPLACEで十分です。
サム

8
はい、NORECOVERYを使用していましたが、復元プロセスがハングします。WITH RECOVERYを使用してREPLACE
すると

これは私の問題を解決しました。復元の途中でSANに障害が発生しましたが、これは迅速かつクリーンなソリューションでした。
登録ユーザー

今日、SQL Server 2005データベースで同様の問題が発生しました。私の場合、問題を解決するために、WITH句に「、RESTART」を追加する必要がありました。以前の操作が成功しなかったことを示すエラーメッセージが表示されました。
XpiritO 2011

3
@FistOfFury同じデータベースに対する以前の復元操作が一時停止/スリープ状態の場合は、はい。インプロセスリストアを単に停止/キャンセルするだけでも同じ効果があります。
John Sansom 2013年

692

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

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

RESTORE DATABASE <database name> WITH RECOVERY

4
DBが2時間復元でスタックしました。このコマンドを別のマシンからマスターに対して実行したところ、問題が解決しました。ありがとう!
ピート

11
+1、落とし穴あり。これを実行すると、データベースはすでに完全に回復しているというエラーメッセージが表示されました。しかし、それでも「回復中」の状態であることがわかりました。そこで、Management Studioで右クリックして[更新]をクリックすると、通常に戻りました。
dario_ramos 2012

2
Mng Studioウィザードを使用して復元し、新しいデータベース名を入力しましたが、誤ってファイル名を既存のデータベースと同じままにしました。「復元に失敗しましたが、ログの末尾は成功しました」というエラーが発生し、それらのファイルに接続されているデータベースが復元状態のままになっています。このコマンドは、データベースを以前の状態に復元したようです。
クリス

3
これはうまくいきました。バックアップをサイドデータベースに復元しようとしましたが、メインデータベースが何らかの理由で復元状態になりました。これは実際に私のDBを回復しました。本当にありがとう!
Aravindh 2014年

2
一部のSSMS復元ウィザードのデフォルトでは、ソースDBが復元状態のままになるため、ユーザーを心配することなく、さまざまなバックアップまたはログの復元を続行できます。このコマンドは、完了後にDBを通常に戻す適切な方法です。
Tim Lehner、2015

102

方法は次のとおりです。

  1. サービス(MSSQLSERVER)を停止します。
  2. データベースファイルとログファイル(C:\ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ Data ...)またはファイルがある場所の名前を変更または削除します。
  3. サービス(MSSQLSERVER)を開始します。
  4. 問題のあるデータベースを削除します。
  5. データベースを再度復元します。

ティプ、ありがとう。元のポスターと同様の問題がありましたが、復元中にサーバーがディスク領域を使い果たし、永続的な復元状態が発生したことが原因でした。
Pauk、

8
データベースを削除しないのはなぜですか?そうすれば、サービスを停止する必要はありません。
ErikE 2012

8
@ErikE私にとって、SQLサーバーは、実際には復元していなかったとしても、復元の途中でデータベースを削除することはできないと述べました...
Erik Philips

@ErikPhilipsその場合、サービスの停止に戻ったと思います。スタックリストアの問題が発生するのは毎回ですか、それとも特定の場合のみですか。
ErikE 2013

5
私の場合、drop database <dbname>クエリウィンドウでSQLコマンドを使用して、状態が "Restoring ..."でハングしているデータベースを削除するだけで十分です。次に、データベースを右クリックして[ 更新]を選択すると、Management Studioのエントリが削除されました。その後、正常に機能する新しい復元を実行しました(オフラインにしても機能せず、SQLサービスの再起動も機能せず、サーバーの再起動も機能しないことに注意してください)。
Matt

84

ログ配布セカンダリサーバーの停止に関しても、同様の問題が発生しました。サーバーをログ配布から削除し、プライマリサーバーからのログ配布を停止するコマンドの後、コマンドの実行後にセカンダリサーバーのデータベースが復元ステータスでスタックしました。

RESTORE DATABASE <database name> WITH RECOVERY

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

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

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


6
すでにデータベースを復元したがRECOVERYオプションを忘れた場合に特に役立ちます...
JBickford

2
このデータベースのバックアップを別のDB名に復元した後、これを「復元中」の状態のままにするために必要なすべてのことでした。本当にありがとう。
Sean

81

SQL Management Studioを使用した復元で同様の問題が発生しました。データベースのバックアップを別の名前の新しいデータベースに復元しようとしました。最初これは失敗し、新しいデータベースのファイル名を修正した後、正常に実行されました-いずれにしても、私が最初からこれを正しく取得した場合でも、私が説明している問題が再発しました。そのため、復元後、元のデータベースの名前の横に(復元中...)が残っていました。上記のフォーラム(ブーサンのもの)の回答を考慮して、次の側のクエリエディターで実行してみました。

RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

問題を修正しました。データベース名に特殊文字が含まれているため、最初は困っていました。二重引用符を追加してこれを解決しました-単一引用符は「...に近い構文が正しくありません」というエラーが発生して機能しません。

これは、この問題を解決するために私が試した最小のソリューションでした(データベースが復元状態でスタックする)。もっと多くのケースに適用できるといいのですが。


2
完全に機能しました-何度も分解する必要はありません。80 Gb以上の3 Dbにはそれぞれ時間がかかります!ありがとう!
Christer

1
私はほとんど本番環境でそれを行いました。私は最初にそれをローカルで試しました、これと同じ状況になって、あなたのコメントを見つけました。教訓:スクリプトを使用し、重要な状況ではSSMSを信頼しない。
Mariusz 2017

1
データベースのコピーのみのファイルバックアップを新しいデータベースに復元するときにこの問題が発生しました。元のデータベースはエラーを示しました。このソリューションは機能し、「RESTORE DATABASEは0.263秒(0.000 MB /秒)で0ページを正常に処理しましという応答がありましたなので、SQL Serverはデータベースの状態について混乱していたようです。
R. Schreurs 2017年

1
私にとってはうまくいきましたが、二重引用符を削除したときだけ-パラメータとして[MY_DB_NAME]を使用しました。
StackOverflowUser 2018

34

OK、同様の問題があり、Paukの場合とまったく同じです。復元中にサーバーのディスク領域が不足し、永続的な復元状態が発生したためです。SQL Serverサービスを停止せずにこの状態を終了するにはどうすればよいですか?

私は解決策を見つけました:)

Drop database *dbname*

29

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

RESTORE DATABASE YourDB WITH RECOVERY
GO

複数のファイルを復元する必要がある場合、CLIコマンドにはWITH NORECOVERYとWITH RECOVERYがそれぞれ必要です。データベースをオンラインに戻すには、コマンドの最後のファイルのみに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ウィザードも使用できます。

ここに画像の説明を入力してください

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


23

これはかなり明白かもしれませんが、ちょうど今私をつまずかせました:

ログ末尾のバックアップを取っている場合、この問題は、SSMS復元ウィザードでこのオプションをオンにすることでも発生する可能性があります-「ソースデータベースを復元状態のままにします(NORECOVERYあり)」

ここに画像の説明を入力してください


7
この状態の場合、最善の策は次のとおりです。1.データベースを右クリックし、[タスク]-> [復元]-> [トランザクションログ]に移動します。2.テールログのバックアップに使用されたバックアップファイルを見つけます。3.復元します。バックアップ復元が成功し、データベースがオンラインに戻ります。
Ryan Gross

16

理由がわかりました。

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

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


10
すべてのSQLコマンドでは、クライアントが常時接続されている必要があります。
mrdenny 2009

2
@mrdenny:クライアントが切断すると変更が元に戻されると思いました。
Ian Boyd、

MicrosoftのPHP PDOドライバーでこのコマンドを実行すると、同じ問題が発生します。ただし、Microsoft SQL Server Management Studioで実行すると、問題なく動作します。私のphpアプリケーションを常時接続する方法を知りたいですか?
channa ly 2012

ここでも同様に、接続が切断された可能性があるため、DBが復元/シングルユーザーでスタックしました。新しいセッションから他のすべてのSPIDを削除しましたが、まだスタックしています。ソリューションとしてデータベースを削除できました。
crokusek 2012

10

これはうまくいきました:

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

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

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

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

  2. LdfファイルとMdfファイルが存在するDATAフォルダーをSQLディレクトリに開きました。通常は次のようになります: "C:\ Program Files *********** \ MSSQL \ DATA

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

これらのファイルを両方とも別のフォルダにコピーしました。

  1. 次に、SQLサービスに関連するすべてのサービスを(ステップ1で)Windowsサービスから再び開始しました。

  2. MS SQL Management Studioを通常のログインで開始しました。

  3. 原因のデータベースを右クリックし、DELETEキーを押します(データベースをまったく削除します)。

  4. このデータベースに関連するすべてのLDFおよびMDFファイルは、DATAフォルダーから削除されています(ステップ2で説明)。

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

  6. 次に、[データベース名]->右クリック->タスク->オフラインにします。

  7. 次に、両方のファイルをコピーし(ステップ3から)、DATAフォルダー(ステップ2)に戻しました。

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


これも私にとってはうまくいきました。ステップ10では、既存のファイルを上書きすることを選択しました。
Divi perdomo

8

持っていた 。私のデータベース名で、そのためクエリが機能しませんでした( '。'の近くに間違った構文があると言います)そして、名前の括弧が必要であることに気付きました:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

5

私の場合、SQLコマンドで"Restoring ..."状態でハングしていたデータベース削除するだけで十分でした

 drop database <dbname> 

クエリウィンドウ内。

次に、データベースを右クリックして[ 更新]を選択すると、Management Studioのエントリが削除されました。その後、正常に機能する新しい復元を実行しました(オフラインにしても機能せず、SQLサービスの再起動も機能せず、サーバーの再起動も機能しませんでした)。


3

イベントログでTCPエラーも受け取ったとき、この問題が発生しました...

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

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


3

デフォルトでは、すべてRESTORE DATABASERECOVERYセットアップが付属しています。'NORECOVERY'オプションは、基本的にデータベースが追加の復元ファイル(DIFFファイルとLOGの可能性があります)を待機していることをSQL Serverに通知しますファイルの可能性があり、可能であればテールログバックアップファイルを含めることができます)。'RECOVERY'オプションは、すべてのトランザクションを終了し、データベースがトランザクションを実行できるようにします。

そう:

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

覚えておいて、LASTはQUERYが持っていなければならないRESTORE RECOVERYOPTIONを。それは明示的な方法かそうでないかもしれません。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

 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

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

必要に応じて、プロセスを観察したり、リアルタイムベースのクエリで復元したりできます。次のように:

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

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


2

スナップショットが有効になっている場合、スタックしたデータベースの削除で問題が発生することもあります。私にとってこれはうまくいきました:

  1. 最初に私はTipu Delacabluのステップに従いました(いくつかの投稿を読んでください)
  2. コマンドの実行:drop database [your database]。これにより、スナップショットデータベースの名前を通知するエラーが表示されます。
  3. コマンドを実行:データベース[スナップショットデータベース]を削除し、手順2のコマンドを再度実行します。


1

MyDbNameを取得しました(復元中...)SQL Expressのライセンス制限によりケースが発生しました。

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

結果の累積データベースサイズが データベースあたりのライセンス制限10240 MB超えるため、CREATE DATABASEまたはALTER DATABASEが失敗しました

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


それはTFSデータベースであり、TFSクライアントはすでに私に言った:データベースがいっぱいです。
cskwg

1

SQLサーバー管理スタジオを使用してデータベースを復元しているときに同様の問題に遭遇し、復元モードで立ち往生しました。数時間の問題追跡の後、次のクエリがうまくいきました。次のクエリは、データベースを既存のバックアップから以前の状態に復元します。私が信じるのは、同じディレクトリに.mdfファイルと.logファイルがあることです。

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

0
  1. まず、SQLエージェントサービスを確認して実行します。
  2. 次のT-SQLを使用します。

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

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

    ディスクからデータベースを復元= 'DB_path' WITH RESTART、REPLACE;

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


0

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

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

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

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


0

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

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

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

この回答が提供する追加の洞察を、古く、受け入れられ、非常に支持されている回答と比較して指摘してください。これは、評判を得るためにコピーしたという印象を避けるのに役立ちます。彼らはStackOverflowの無料コードの書き込みサービスであるという誤った印象を与えるためにも、(主な目に見える違いである)コードのみの回答は、ここに感謝されていません
Yunnosch

以前の回答との類似性をより明確にするために、フォーマットを修正しました。しかし、将来もっと読みやすい答えを出そうとする場合に備えて、ここでstackoverflow.com/editing-helpを行うことを学ぶことができます。
ユンノシュ

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.