質問

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

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
役に立ちましたか?

解決

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

あなたが唯一のデータベースのバックアップを復元してから、データベースにアクセスできるようにしたい、すなわち、任意のトランザクションログのバックアップを復元する予定がない場合にのみ、

これは、もちろんです。

あなたのコマンドは次のようになり、

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

あなたは、SQL Server Management Studioでデータベースの復元ウィザードを使用して、より多くの成功事例のを有することができます。この方法で、あなたは、特定のファイルの場所、overwriteオプション、およびWITH回復オプションを選択することができます。

他のヒント

私はこのような状況がSymantec Backup Exec 11dは使用してSQL Server 2005のStandard Editionのインスタンスにデータベースを復元しました。リストアジョブが完了した後、データベースには、「復元」状態のままでした。私は単純に「復元」状態から出て来なかったデータベースissues--何のディスクスペースがありませんでした。

私は、SQL Serverインスタンスに対して次のクエリを実行し、データベースがすぐに使用可能になったことが判明します:

RESTORE DATABASE <database name> WITH RECOVERY

その方法は次のとおりです。

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

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

RESTORE DATABASE <database name> WITH RECOVERY

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

  

18.530秒でDATABASE正常に処理0ページを復元   (0.000メガバイト/秒)。

データベースがこれら18秒後に再び使用可能であった。

私は、SQL Management Studioを使用して復元すると同様の問題がありました。私は別の名前で新しいものにデータベースのバックアップを復元しようとしました。最初は、これは失敗し、それが正常に実行された新しいデータベースのファイル名を固定した後 - どのような場合に問題を私が初めてからこの権利を得た場合でも、再発生して記述しています。だから、復元後、元のデータベースは、名前の横に(...復元)で残りました。

:私は次側のクエリエディタで実行してみました(Bhusanの)上記のフォーラムの答えを考えます
RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"

これは問題を修正しました。私は最初の理由は、特殊文字が含まれていたデータベース名の時にトラブルを抱えていました。私の周りに二重引用符を追加することでこれを解決 - 単一引用符は、「不適切な構文近く...」エラーを与えて動作しないでしょう。

これは私がこの問題(状態を復元することで立ち往生データベース)を解決しようとした最小限のソリューションだったと私はそれがより多くのケースに適用されることを願ってます。

OK、私は同様の問題があり、それがPaukの場合にあったとおりに、それを復元するので、永久的な回復状態を引き起こしながら、ディスクの空き容量が不足しているサーバーによって引き起こされました。 SQL Serverサービスを停止せずにこの状態を終了するには?

私が見つけた解決策:)

Drop database *dbname*

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

RESTORE DATABASE YourDB WITH RECOVERY
GO

複数のファイルをリストアする必要がある場合、CLIコマンドは、WITH NORECOVERYをそれぞれRECOVERY WITH必要です - コマンドで唯一の最後のファイルを、データベースのオンラインを取り戻すRECOVERY WITH持っている必要があります:

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は独自のソリューションを持っています。 によってレビュー>。復元仮想あなたは、バックアップの多数を扱っている場合は良い解決策です。プロセスを復元はるかに高速であり、また、ディスク・ドライブ上の多くのスペースを節約することができます。あなたは、いくつかの比較のために、ここでインフォグラフィックの上で見ることができます。

これはかなり明白かもしれないが、それは今私をつまずいます:

あなたはログ末尾のバックアップを取っている場合は、

この問題はまた、SSMSでチェックこのオプションはウィザードを復元させることによって引き起こされることができます -

「(NORECOVERY WITH)復元状態にソースデータベースを残します」

ここに画像の説明を入力します

私はなぜ考え出します。

復元、復元中にRESTORE DATABASEコマンドの切断を発行したクライアントが立ち往生されます。

これは、クライアントが全体の時間を接続したまましない限り、クライアント接続でデータベースを復元するように言わサーバは、復元を完了しないこと。

奇妙です

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

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

データベースが復元中の状態を示しているにもかかわらず、クエリを実行できず、ソフトウェアに接続できないという状況がありました。

この状況から抜け出すために私がしたことは次のとおりです。

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

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

  3. 次に、データベースの Ldf ファイルと Mdf ファイルの両方をコピーしました。[データベース名].mdf および [データベース名]_log.ldf

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

  1. 次に、Windows サービスからすべての SQL 関連サービス (手順 1) を再度開始しました。

  2. 通常のログインで MS SQL Management スタジオを起動しました。

  3. 原因となっているデータベースを右クリックし、DELETE キーを押します (データベースを完全に削除する場合)。

  4. このデータベースに関連するすべての LDF および MDF ファイルが DATA フォルダー (手順 2 で説明) から削除されました。

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

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

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

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

私が持っていました。私のデータベース名で、およびクエリが(近くに不適切な構文を言って「」)そのため動作しませんでしたそれから私は私が名前のためのブラケットが必要であることを実現します:

RESTORE DATABASE [My.DB.Name] WITH RECOVERY

私の場合はこれで十分でした データベースを削除する 状態でぶら下がっていたもの 「復元中…」 SQLコマンドを使って

 drop database <dbname> 

クエリウィンドウで。

それから私は右クリックしました データベース そして選ばれた リフレッシュ これにより、Management Studio のエントリが削除されました。その後、新しい復元を実行しましたが、正常に機能しました(オフラインにすることは機能せず、SQL サービスの再起動も機能せず、サーバーの再起動も機能しませんでした)。

私はまた、イベントログにTCPエラーを受け取ったときに、私はこの問題を抱えている...

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

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

デフォルトでは、すべての RESTORE DATABASE 付いています RECOVERY 設定。「NORECOVERY」オプションは、基本的に、データベースがさらなる復元ファイルを待っていることを SQL Server に伝えます ( 差分 ファイルと ログ ファイル、および可能であればログ末尾のバックアップ ファイルを含めることができます)。「RECOVERY」オプションでは、すべてのトランザクションを終了し、データベースがトランザクションを実行できるようにします。

それで:

  1. データベースが次のように設定されている場合 単純 復旧モデルでは、実行できるのは 満杯 で復元する NORECOVERY オプションがある場合、 差分 バックアップ。いいえ ログ バックアップは許可されます 単純 復旧モデルデータベース。
  2. それ以外の場合、データベースが次のように設定されている場合は、 満杯 または 一括ログ記録 リカバリ モデルを実行できます。 満杯 復元に続いて NORECOVERYオプションを選択してから、次の操作を実行します 差分 に続く NORECOVERY, 、そして最後に実行します ログ で復元する RECOVERY オプション。

覚えて、 最後の復元クエリには必ず必要なものがあります 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 オプションは、データ損失につながる可能性があるため、注意して使用する必要があります。

または、完全バックアップと差分バックアップを実行する場合は、これを使用できます。

   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

もちろん、オプションを使用して復元を実行することもできます ステータス = 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

これがお役に立てば幸いです。

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

  1. まずはフォローしてみました ティプ・デラカブル 手順 (いくつかの投稿を読んでください)
  2. コマンドを実行します:データベース [あなたのデータベース] を削除すると、スナップショット データベースの名前を示すエラーが表示されます。
  3. コマンドを実行します:データベース [スナップショット データベース] を削除し、手順 2 のコマンドを再度実行します。

あなただけのVERIFYを実行しようとしたことがありますか?ただ、それは音のバックアップだことを確認します。

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

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

    dbid = db_id( 'db_name');

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

    disk = 'db_path'からデータベースを再起動して復元します。

これがお役に立てば幸いです!

すべての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

私はそれが壊れているか、何か得たようにです...私のデータベースは、この問題を経験し、なぜ私のドライブに空きがあったように、私は知りませんが...同じ問題がありました。私は、特にサービスを停止し、MDFとLDFファイルを削除する提案が働くだろうと思った...しかし、それはまだ復元上に凍結した、完全に働いていたそれらのどれも上記の全てを試してみました?

に述べたように、私は、ファイルを削除することによって、これを解決することになったが、代わりに再びDBを復元しようと、私は新鮮な.mdfファイルと.ldfファイルの上にコピーされ、フロントエンドの添付ファイルウィザードを使用して、これらを添付します。救済、それが働きました!

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

私はそれを持っています MyDbName (復元中...) この場合、SQL Express のライセンス制限が原因です。

ログ ファイルで次のことがわかりました。

データベースの作成またはデータベースの変更 失敗したため 結果の累積データベースサイズはそうでしょう ライセンス制限の 10240 MB を超えていますデータベースごとに。

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

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

  1. インスタンスを停止する
  2. データ フォルダーに .mdf ファイルと .ldf ファイルのバックアップを作成する
  3. インスタンスを再起動します
  4. データベースを削除して復元が停止している
  5. .mdf ファイルと .ldf ファイルをデータ フォルダーに戻します。
  6. インスタンスを .mdf および .ldf ファイルにアタッチします。
RESTORE DATABASE {DatabaseName}
   FROM DISK = '{databasename}.bak'
   WITH REPLACE, RECOVERY
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top