MS SQLデータベースリカバリチェーン

多くの場合、バックアップ/テストサーバー上のバックアップチェーンによってデータベースを復元するタスクがあります。データベースは直接バックアップされず、msdbにはエントリがありませんが、本稼働サーバーから取得されたバックアップがあります。 メインサーバーと復元する予定のワークステーションのセットが異なる場合、msdbデータベースのコピーを復元するオプションは適切でない場合があります。 バックアップのあるファイルが少ない場合、特にバックアップがログシップに属している場合、ファイルの論理的な順序を復元することは難しくありません。 この場合、すべては簡単です。時刻と日付はファイル名に格納されます（ファイル名の時刻はUTCに格納されていることに注意する必要があります）。 しかし、バックアップに構造がなく、ファイルがたくさんあり、それらを簡単な方法で整理することができない場合、またはどのログ配布ファイルから寄付を開始するかをどのように単純に決定できますか？ この問題に対処した場合、おそらく同様のエラーが発生しています。

メッセージ4305、レベル16、状態1、行1

このバックアップセットのログは、LSN 30643000001846100001で始まり、データベースに適用するには最新ではありません。 LSN 30643000001845500001を含む以前のログバックアップを復元できます。

または

このバックアップセットのログはLSN 9386000024284900001で終了しますが、データベースに適用するには早すぎます。 LSN 9417000002731000001を含む最新のログバックアップを復元できます。



この記事では、最小限の手作業で復旧チェーンを正しく構築し、そのようなエラーを回避する方法を説明します。 秘repositoryは、リカバリリポジトリにデータを入力し、Management Studioのリカバリチェーンロジックを使用することです。



1）最初に、バックアップ/テストサーバーのデータベースで、バックアップに関するメタデータを生成する必要があります。

リポジトリを埋めます

RESTORE VERIFYONLY FROM DISK = ' ' WITH LOADHISTORY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

有名なORACLEコマンドの類似物

RMAN>カタログの開始...



ディスクからバックアップを読み取るこのコマンドは、イメージの正当性の最小限の必要な検証を実行し、成功した場合、このイメージについてmsdbにバックアップサーバーレコードを作成します。



また、特定のフォルダーからバックアップの履歴をダウンロードするスクリプトは次のようになります。

（ネストされたディレクトリを処理するためのロジックを追加できます）

 declare @Path nvarchar(255) declare @Name nvarchar(255) select @Path = N'\\ServerName\D$\LogShipingDir\DevDB\' IF OBJECT_ID('tempdb..#filetmp') IS NOT NULL DROP TABLE #filetmp ; create table #filetmp (Name nvarchar(255) NOT NULL, depth int NOT NULL, IsFile bit NULL ) insert #filetmp EXECUTE master.dbo.xp_dirtree @Path, 1, 1 DECLARE @filename varchar(200) DECLARE @SQL nvarchar(300) DECLARE FileList_Cursor CURSOR FAST_FORWARD FOR select name from #filetmp where IsFile=1 and name like '%DevDB%' OPEN FileList_Cursor; FETCH NEXT FROM FileList_Cursor INTO @filename; WHILE @@FETCH_STATUS = 0 BEGIN set @SQL=@Path+@filename; print @SQL; RESTORE VERIFYONLY FROM DISK = @SQL WITH LOADHISTORY FETCH NEXT FROM FileList_Cursor INTO @filename; END; CLOSE FileList_Cursor; DEALLOCATE FileList_Cursor;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

！ 注意：スクリプトはかなり長い時間実行されます（1つのファイルの処理時間は、このファイルからのバックアップの回復時間に匹敵します）



スクリプトは、システムテーブルにバックアップ情報を入力します。 リポジトリへの同じ追加は、バックアップからの通常のリカバリ中に発生します。 これは、情報をリカバリリポジトリに入力するために非標準のリカバリ方法でバックアップシステムを使用する場合に適しています。

1.a）それ以外の場合、代替手段でバックアップを行う場合、完全なバックアップに関するデータもダウンロードする必要があります。 たとえば、Veritas NetBackupのリカバリはインターフェースを介して行われます







この段階で、バックアップチェーンをさらに復元する場合は、NORECOVERYパラメーターを使用してベースを復元することが重要です。



リポジトリでのリカバリの結果、VDIデバイスはバックアップが配置されているデバイスになり、SQLサーバーからアクセスできなくなりますが、このエントリはリカバリチェーンの開始点として必要です。







2）msdbリカバリリポジトリに入力した後、リカバリ自体を開始できます。

Management Studioで、リカバリウィンドウを開き、リカバリリポジトリを作成したベースを選択します。 インターフェイスは、ロードされたメタデータのLSNチェーンに基づいて、データベースの1つのインカネーションのリカバリチェーンを構築しようとします。 リストを作成するためのバックアップに関する情報は、可能な限り完全で、チェーン全体を含む必要があります。







復旧チェーンが構築されていない場合、次の理由により復旧は不可能です。

-ベースの異なる化身からのバックアップがある、または

-復旧チェーンを開始するための完全バックアップはありません。

不完全なチェーンは、ファイルがないか、イメージにエラーがあるために発生する可能性があります。



必要なパラメータをすべて指定したら、リカバリスクリプトを保存し、すでに実行した手順を削除して、非標準のソース（Veritas Netbackupなど）から復元します。