RESTORE の引数 (Transact-SQL)

このトピックでは、RESTORE {DATABASE|LOG} ステートメントと、関連する補助ステートメント RESTORE FILELISTONLY、RESTORE HEADERONLY、RESTORE LABELONLY、RESTORE REWINDONLY、RESTORE VERIFYONLY の「構文」に記載されている引数について説明します。ほとんどの引数は、これら 6 つのステートメントのサブセットでのみサポートされています。それぞれの引数の説明では、その引数を使用できるステートメントについても示します。

トピック リンク アイコンTransact-SQL 構文表記規則

引数

  • DATABASE
    使用できるステートメント: RESTORE

    対象のデータベースを指定します。ファイルとファイル グループのリストを指定した場合は、そのファイルとファイル グループだけが復元されます。

    データベースで完全な復旧モデルまたは一括ログ復旧モデルを使用しているとき、SQL Server ではほとんどの場合において、データベースの復元前にログ末尾のバックアップが必要になります。RESTORE DATABASE ステートメントに WITH REPLACE 句または WITH STOPAT 句のいずれかが指定されていない場合、最初にログ末尾のバックアップを行わずに、データベースを復元しようとするとエラーが発生します。これらの句は、データのバックアップ終了後の時間またはトランザクションの指定が必要となる句です。ログ末尾のバックアップに関する詳細については、「ログ末尾のバックアップ」を参照してください。

  • LOG
    使用できるステートメント: RESTORE

    トランザクション ログ バックアップをこのデータベースに適用することを指定します。トランザクション ログは順番に適用する必要があります。SQL Server では、バックアップされたトランザクション ログがチェックされ、トランザクションが正しいデータベースに正しい順序で読み込まれていることが確認されます。複数のトランザクション ログを適用するには、最後の復元操作を除くすべての復元操作で NORECOVERY オプションを使用します。

    注意

    通常、最後に復元されるログは、ログ末尾のバックアップです。ログ末尾のバックアップは、データベースを復元する直前にバックアップされるログで、データベースが失敗した後などに作成されます。損傷した可能性があるデータベースに関するログ末尾のバックアップを使用すると、まだバックアップされていないログ (ログの末尾) がキャプチャされるので、作業の抜けや失敗を防ぐことができます。詳細については、「ログ末尾のバックアップ」を参照してください。

    詳細については、「トランザクション ログのバックアップ」を参照してください。

  • { database_name | **@**database_name_var}
    使用できるステートメント: RESTORE

    ログまたはデータベース全体の復元先データベースを指定します。この名前を変数 (**@database_name_var) として指定する場合は、文字列定数 (@**database_name_var = database_name)、または ntext と text を除く文字列データ型の変数のいずれかを使用して指定できます。

  • <file_or_filegroup_or_page> [ ,...n ]
    使用できるステートメント: RESTORE

    RESTORE DATABASE または RESTORE LOG ステートメントに含める論理ファイル、論理ファイル グループ、またはページの名前を指定します。ファイルまたはファイル グループのリストを指定できます。

    データベースで単純復旧モデルを使用している場合、FILE および FILEGROUP オプションは、対象のファイルまたはファイル グループが読み取り専用の場合、または PARTIAL 復元を使用する場合のみ指定できます (後者の場合、結果としてファイル グループの機能停止につながります)。

    データベースで完全復旧モデルまたは一括ログ復旧モデルを使用している場合、RESTORE DATABASE を使用して 1 つ以上のファイル、ファイル グループ、ページを復元した後では、通常、復元したデータを含むこれらのファイルにトランザクション ログを適用する必要があります。トランザクション ログを適用すると、これらのファイルとデータベースの残りの部分の一貫性がとれるようになります。ただし、次の場合は例外となります。

    • 復元するファイルが、前回のバックアップ時まで読み取り専用であった場合。この場合、トランザクション ログを適用する必要はありません。RESTORE ステートメントでは、この状況が報告されます。

    • バックアップにプライマリ ファイル グループが含まれており、部分復元を実行する場合。この場合、バックアップ セットから自動的にログが復元されるので、復元ログは必要ありません。

    • FILE = { logical_file_name_in_backup| **@**logical_file_name_in_backup_var}
      データベースの復元に含めるファイルの名前を指定します。

    • FILEGROUP = { logical_filegroup_name | **@**logical_filegroup_name_var }
      データベースの復元に含めるファイル グループの名前を指定します。

         指定したファイル グループが読み取り専用で、部分復元を行う場合 (WITH PARTIAL を使用する場合) のみ、FILEGROUP は単純復旧モデルで使用できます。このとき、復元されなかった読み書き可能なファイル グループは機能していないとマークされ、ここで復元されたデータベースには以降復元できなくなります。

    • READ_WRITE_FILEGROUPS
      読み書き可能なファイル グループをすべて選択します。このオプションは、読み書き可能なファイル グループを復元した後で、読み取り専用のファイル グループを復元する場合に特に便利です。

    • PAGE = 'file:page [ ,...n ]'
      ページ復元の対象となる 1 ページまたは複数ページのリストを指定します (ページ復元は、完全復旧モデルまたは一括ログ復旧モデルを使用しているデータベースに対してのみサポートされています)。値は次のとおりです。

      • PAGE
        1 つ以上のファイルおよびページで構成されるリストです。

      • file
        復元する特定ページを含むファイルのファイル ID です。

      • page
        ファイル内の復元対象ページのページ ID です。

      • n
        複数のページを指定できることを示すプレースホルダーです。

        復元シーケンスで 1 つのファイルに復元できる最大ページ数は、1,000 ページです。ただし、ファイルに含まれる損傷ページの数が多い場合は、ページでなくファイル全体を復元することをお勧めします。

      注意

      ページ復元は復旧されません。

      ページ復元の詳細については、「ページ復元の実行」を参照してください。

    • [ ,...n ]
      複数のファイル、ファイル グループ、およびページをコンマ区切りリストに指定できることを示すプレースホルダーです。数値の制限はありません。

  • FROM { <backup_device> [ ,...n]| <database_snapshot> }
    通常、バックアップの復元元であるバックアップ デバイスを指定します。または、RESTORE DATABASE ステートメントの中で FROM 句を使用して、データベースを元に戻すためのデータベース スナップショットの名前を指定することもできます。この場合、WITH 句は使用できません。

    FROM 句を省略した場合、バックアップの復元は行われず、代わりにデータベースが復旧されます。この機能により、NORECOVERY オプションで復元されているデータベースを復旧したり、スタンバイ サーバーに切り替えることができます。FROM 句を省略する場合は、WITH 句の中で NORECOVERY、RECOVERY、または STANDBY を指定する必要があります。

    • <backup_device> [ ,...n]
      復元操作に使用する、論理バックアップ デバイスまたは物理バックアップ デバイスを指定します。

使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLYRESTORE REWINDONLY、および RESTORE VERIFYONLY

      - \<backup_device\>::=  
        バックアップ操作に使用する論理バックアップ デバイスまたは物理バックアップ デバイスを、次のように指定します。
        
          - { logical_backup_device_name | **@**logical_backup_device_name_var }  
            データベースの復元元である、**sp_addumpdevice** で作成されたバックアップ デバイスの論理名を指定します。この名前は識別子の規則に従っている必要があります。バックアップ デバイス名を変数 (**@**logical_backup_device_name_var) として指定する場合、文字列定数 (**@**logical_backup_device_name_var = logical_backup_device_name)、または ntext と text を除く文字列データ型の変数のいずれかを使用して指定できます。
        
          - {DISK | TAPE } **=** { **'**physical_backup_device_name**'** | **@**physical_backup_device_name_var }  
            指定したディスク デバイスまたはテープ デバイスから、バックアップを復元することを許可します。ディスクまたはテープを表すデバイスの種類を、実際のデバイス名 (たとえば完全なパスとファイル名) と共に指定してください。たとえば、「DISK = 'Z:\\SQLServerBackups\\AdventureWorks2008R2.bak'」または「TAPE = '\\\\.\\TAPE0'」のように指定します。デバイス名を変数 (**@**physical_backup_device_name_var) として指定する場合、文字列定数 (**@**physical_backup_device_name_var = 'physcial_backup_device_name')、または ntext と text を除く文字列データ型の変数のいずれかを使用して指定できます。
            
            ネットワーク サーバーを UNC 名で指定する場合は、デバイスの種類に DISK を指定してください (UNC 名にはマシン名を含める必要があります)。UNC 名の使用方法の詳細については、「[バックアップ デバイス](ms179313\(v=sql.105\).md)」を参照してください。
            
            RESTORE 操作を実行するには、SQL Server を実行するアカウントに、リモート コンピューターまたはネットワーク サーバーへの読み取りアクセス権が与えられている必要があります。
    
      - n  
        最大 64 個のバックアップ デバイスをコンマ区切りリストに指定できることを示すプレースホルダーです。
        
        以下に示すように、復元シーケンスで必要になるバックアップ デバイスの数が、バックアップが含まれるメディア セットの作成で使用したデバイスの数と同じになるかどうかは、復元をオフラインとオンラインのどちらで行うかによって決まります。
        
          - オフライン復元の場合は、バックアップの作成時よりも少ない数のデバイスでバックアップを復元できます。
        
          - オンライン復元の場合は、バックアップの作成時に使用されたすべてのバックアップ デバイスが必要です。それより少ない数のデバイスで復元しようとしても失敗します。
        
        たとえば、サーバーに接続している 4 つのテープ ドライブに、データベースがバックアップされているとします。これをオンライン復元する場合は、サーバーに 4 つのドライブを接続する必要がありますが、オフライン復元する場合は、マシンに接続しているドライブが 3 つ以下でもバックアップを復元できます。
        
        詳細については、「[SQL Server でのバックアップ メディアの操作](ms191316\(v=sql.105\).md)」を参照してください。
    
    <div class="alert">
    
    <table>
    <colgroup>
    <col style="width: 100%" />
    </colgroup>
    <thead>
    <tr class="header">
    <th><img src="images/ms143715.alert_note(ja-jp,SQL.105).gif" title="注意" alt="注意" class="note" /><strong>注</strong></th>
    </tr>
    </thead>
    <tbody>
    <tr class="odd">
    <td><p>ミラー化されたメディア セットからバックアップを復元する場合は、各メディア ファミリに対して 1 つのミラーだけを指定できますが、エラーが発生したとき、他に複数のミラーを用意しておくと復元に関する問題をすばやく解決できる場合があります。損傷したメディア ボリュームは、別のミラーの対応するボリュームで代替できます。オフライン復元の場合は、メディア ファミリの数よりも少ない数のデバイスから復元できますが、各ファミリは一度しか処理されないことに注意してください。</p></td>
    </tr>
    </tbody>
    </table>
    
    </div>

  - \<database_snapshot\>::=  

使用できるステートメント: RESTORE DATABASE

      - DATABASE_SNAPSHOT **=**database_snapshot_name  
        database_snapshot_name で指定したデータベース スナップショットにデータベースを戻します。DATABASE_SNAPSHOT オプションは、データベース全体の復元にのみ使用できます。元に戻す操作では、データベース スナップショットがデータベース全体のバックアップの代わりとなります。
        
        また、元に戻す操作では、指定したデータベース スナップショットが、データベース上の唯一のデータベース スナップショットであることが必要です。元に戻す操作の実行中は、データベース スナップショットと出力先データベースの両方が In restore としてマークされます。詳細については、「[RESTORE DATABASE](ms186858\(v=sql.105\).md)」の「解説」を参照してください。

WITH オプション

復元操作で使用するオプションを指定します。各オプションを使用するステートメントの一覧については、このトピックに後述される「WITH オプションと対応ステートメントの一覧」を参照してください。

注意

ここでは、WITH オプションが「RESTORE {DATABASE|LOG}」の「構文」で示されている順序と同じ順序で編成されています。

  • PARTIAL
    使用できるステートメント: RESTORE DATABASE

    部分復元操作で、プライマリ ファイル グループと指定したセカンダリ ファイル グループを復元することを指定します。PARTIAL オプションでは暗黙的にプライマリ ファイル グループが選択されるので、FILEGROUP = 'PRIMARY' を指定する必要はありません。セカンダリ ファイル グループを復元するには、FILE オプションまたは FILEGROUP オプションで明示的にファイル グループを指定する必要があります。

    PARTIAL オプションは、RESTORE LOG ステートメントでは使用できません。

    SQL Server 2005 からは、PARTIAL オプションによって段階的な部分復元の初期段階を開始できるようになりました。この場合、残りのファイル グループは後で復元することができます。詳細については、「段階的な部分復元の実行」を参照してください。

    注意

    段階的な部分復元の初期段階は、Microsoft SQL Server 2000 のデータベースの部分復元に代わるものです。これまでのデータベースの部分復元は、データベースの損傷部分 (ファイル グループのサブセット) だけを新しい場所に復元し、損傷または消失したデータを元のデータベースにコピーできるようにすることを目的としたものでした。部分的に復元されたデータベースを運用データベースとして使用することは想定されておらず、またパフォーマンス向上のため、RESTORE ステートメントでは通常の安全性チェックの多くが無視されていました。しかし、SQL Server 2005 以降のバージョンでは、PARTIAL オプションでそれらの安全性チェックが実行されるようになりました。

  • [ RECOVERY | NORECOVERY | STANDBY ]
    使用できるステートメント: RESTORE

    • RECOVERY
      復元操作に対して、コミットされていないトランザクションをロールバックすることを指定します。復旧操作の後、データベースは使用可能な状態になります。NORECOVERY、RECOVERY、または STANDBY のいずれも指定しない場合は、RECOVERY が既定値になります。

      この後 RESTORE 操作 (差分バックアップからの RESTORE LOG または RESTORE DATABASE) を予定している場合は、代わりに NORECOVERY または STANDBY を指定してください。

      以前のバージョンの SQL Server で作成したバックアップ セットを復元するときには、データベースのアップグレードが必要になる場合があります。このアップグレードは、WITH RECOVERY が指定されていれば自動的に実行されます。詳細については、「トランザクション ログ バックアップの適用」を参照してください。

      注意

      FROM 句を省略する場合は、WITH 句の中で NORECOVERY、RECOVERY、または STANDBY を指定する必要があります。

    • NORECOVERY
      復元操作に対して、コミットされていないトランザクションをロールバックしないことを指定します。別のトランザクション ログを後で適用する必要がある場合は、NORECOVERY または STANDBY オプションのいずれかを指定してください。NORECOVERY、RECOVERY、または STANDBY のいずれも指定しない場合は、RECOVERY が既定値になります。NORECOVERY オプションを使用したオフライン復元操作が行われている間、データベースは使用できません。

      データベース バックアップと 1 つ以上のトランザクション ログを復元する場合や、複数の RESTORE ステートメントが必要な場合 (データベース全体を復元してからデータベースの差分バックアップを復元する場合など) は、最後の RESTORE ステートメントを除くすべての RESTORE ステートメントに、WITH NORECOVERY オプションを指定する必要があります。推奨事項としては、複数段階に分かれた復元シーケンスで、すべてのステートメントに WITH NORECOVERY を使用して目的の復旧ポイントまで復旧を行います。その後で、個別の RESTORE WITH RECOVERY ステートメントを使用して、復旧のみを行うことをお勧めします。

      ファイルまたはファイル グループの復元操作で NORECOVERY を使用した場合、データベースは復元操作の後も復元中の状態になります。これは、次の状況で効果的です。

      • 復元スクリプトが実行されていて、ログが常に適用される場合。

      • ファイルが順番に復元されており、2 つの復元操作の間でデータベースを使用できないようにする場合。

      場合によっては、RESTORE WITH NORECOVERY では、ロールフォワード セットがデータベースとの一貫性を保てるポイントまでロールフォワードされることがあります。このような場合、ロールバックは発生せず、データはオフラインのままになります。これはこのオプションに想定されている動作ですが、データベース エンジンからは情報メッセージが返され、RECOVERY オプションを使用してロールフォワード セットを復旧できるようになったことが示されます。

    • STANDBY **=**standby_file_name
      スタンバイ ファイルを指定します。このファイルを使用すると、復旧の結果を元に戻すことができます。STANDBY オプションは、部分復元を含むオフライン復元で使用でき、オンライン復元では使用できません。オンライン復元操作に STANDBY オプションを指定すると、復元操作は失敗します。また、データベースのアップグレードが必要な場合も、STANDBY は使用できません。

      注意

      SQL Server 2000 では、このファイルは "UNDO ファイル" と呼ばれていました。

      スタンバイ ファイルは、RESTORE WITH STANDBY の Undo パスにおいて変更されるページに対して、"書き込み時コピー" のプリイメージを保持するために使用されます。スタンバイ ファイルを使用すると、トランザクション ログの復元の間では、読み取り専用でデータベースにアクセスできます。また、このファイルは、ウォーム スタンバイ サーバーを使用する場合や、特別な復旧状況 (ログの復元の間にデータベースを調査する場合など) で使用できます。RESTORE WITH STANDBY 操作の後、次に RESTORE 操作を行うと、UNDO ファイルは自動的に削除されます。次に RESTORE 操作を行う前にスタンバイ ファイルを手動で削除した場合は、データベース全体をもう一度復元する必要があります。データベースが STANDBY の状態にある間、このスタンバイ ファイルは他のデータベース ファイルと同様に扱う必要があります。ただし他のデータベース ファイルと異なり、このファイルは、アクティブな復元操作の実行中のみ、データベース エンジンによって開かれたままになります。

      standby_file_name で指定するスタンバイ ファイルの場所は、データベースのログに格納されます。指定した名前が既存のファイルのものである場合はファイルが上書きされ、そうでない場合はデータベース エンジンによってファイルが作成されます。

      スタンバイ ファイルのサイズ要件は、復元操作において、コミットされていないトランザクションを元に戻す操作がどれだけあるかによって決まります。

      重要な注意事項重要

      指定したスタンバイ ファイルが格納されるドライブでディスク領域がなくなった場合、復元操作は停止します。

    RECOVERY と NORECOVERY の比較の詳細については、「RESTORE」の「解説」を参照してください。

  • LOADHISTORY
    使用できるステートメント: RESTORE VERIFYONLY

    復元操作で情報が msdb 履歴テーブルに読み込まれることを指定します。LOADHISTORY オプションを指定した場合は、確認中の 1 つのバックアップ セットに対して、メディア セットに格納されている SQL Server バックアップに関する情報が、msdb データベース内のバックアップ履歴テーブルと復元履歴テーブルに読み込まれます。履歴テーブルの詳細については、「システム テーブル (Transact-SQL)」を参照してください。

<general_WITH_options> [ ,...n ]

RESTORE DATABASE および RESTORE LOG ステートメントでは、一般的な WITH オプションをすべて使用できます。一部のオプションは、以下で説明するように 1 つ以上の補助ステートメントでも使用できます。

復元操作オプション

以下のオプションは、復元操作の動作に影響します。

  • MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ...n ]
    使用できるステートメント: RESTORE および RESTORE VERIFYONLY

    logical_file_name_in_backup で論理名が指定されるデータ ファイルまたはログ ファイルを、復元時、operating_system_file_name で指定される位置に移動します。バックアップ セット内のデータ ファイルまたはログ ファイルの論理ファイル名は、バックアップ セットが作成されたときのデータベース内における論理名と同じです。

    n は追加の MOVE ステートメントを指定できることを示すプレースホルダーです。バックアップ セットから新しい位置に復元する論理ファイルごとに、MOVE ステートメントを指定してください。既定では、logical_file_name_in_backup ファイルは元の位置に復元されます。

    注意

    バックアップ セットに含まれる論理ファイルの一覧を取得するには、RESTORE FILELISTONLY を使用します。

    RESTORE ステートメントを使用して、データベースを同じサーバーに再配置したり、別のサーバーにコピーするとき、データベース ファイルの再配置によって既存ファイルとの衝突が発生するのを防ぐために、MOVE オプションが必要になる場合があります。

    RESTORE LOG で MOVE オプションを使用する場合は、復元するログの対象期間中に追加されたファイルを再配置するためにのみ使用してください。たとえば、ログ バックアップにファイル file23 のファイル追加操作が含まれる場合、このファイルは RESTORE LOG で MOVE オプションを使って再配置します。

    RESTORE VERIFYONLY ステートメントを使用して、データベースを同じサーバーに再配置するか別のサーバーにコピーする場合は、対象となるサーバーに利用可能な容量が十分あるかどうか、および既存のファイルと衝突する可能性がないかどうかを確認するために、MOVE オプションが必要になる場合があります。

    詳細については、「バックアップと復元によるデータベースのコピー」を参照してください。

  • REPLACE
    使用できるステートメント: RESTORE

    指定したデータベースと同じ名前のデータベースが既に存在していても、SQL Server でデータベースとその関連ファイルを作成することを指定します。この場合、既存のデータベースは削除されます。REPLACE オプションを指定しない場合、安全性チェックが行われます。これにより、他のデータベースを誤って上書きするのを防止できます。安全性チェックで次の両方に該当した場合は、RESTORE DATABASE ステートメントで現在のサーバーにデータベースが復元されることはありません。

    • RESTORE ステートメントで指定したデータベースが、現在のサーバー上に既に存在する。

    • データベース名が、バックアップ セットに記録されているデータベース名と異なる。

    REPLACE を指定すると、既存のファイルが復元するデータベースに属するかどうかを確認できない場合も、RESTORE でそのファイルを上書きできます。通常、RESTORE では既存のファイルは上書きされません。WITH REPLACE は、RESTORE LOG オプションと同じ方法で使用することもできます。

    REPLACE を使用すると、データベースを復元する前のログ末尾のバックアップも必須ではなくなります。

    詳細については、「REPLACE オプションの使用」を参照してください。

  • RESTART
    使用できるステートメント: RESTORE

    SQL Server で中断されていた復元操作を再開することを指定します。RESTART では、中断された時点から復元操作が再開されます。

  • RESTRICTED_USER
    使用できるステートメント: RESTORE

    新しく復元したデータベースへのアクセスを、db_ownerdbcreatorsysadmin の各ロールのメンバーに制限します。RESTRICTED_USER は、DBO_ONLY に置き換わるオプションです。DBO_ONLY は、SQL Server 2008 で廃止されました。

    RECOVERY オプションと共に使用します。

    詳細については、「データベース オプションの設定」を参照してください。

バックアップ セット オプション

以下のオプションは、復元されるバックアップを含んでいるバックアップ セットに適用されます。

  • FILE ={ backup_set_file_number | **@**backup_set_file_number }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLY、および RESTORE VERIFYONLY

    復元するバックアップ セットを特定します。たとえば、backup_set_file_number が 1 の場合はバックアップ メディアの 1 番目のバックアップ セットを示し、backup_set_file_number が 2 の場合は 2 番目のバックアップ セットを示します。バックアップ セットの backup_set_file_number は、RESTORE HEADERONLY ステートメントを使用して取得できます。

    値を指定しない場合は、RESTORE HEADERONLY を除き、既定値の 1 が使用されます。RESTORE HEADERONLY では、メディア セットにあるすべてのバックアップ セットが処理されます。詳細については、後の「バックアップ セットの指定」を参照してください。

    重要な注意事項重要

    この FILE オプションはデータベース ファイルを指定する FILE オプション (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }) とは関連はありません。

  • PASSWORD = { password | **@**password_variable }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLY、および RESTORE VERIFYONLY

    バックアップ セットのパスワードを指定します。バックアップ セットのパスワードは文字列です。

    注意

    この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。

    バックアップ セットの作成時にパスワードを設定した場合、このバックアップ セットから復元操作を実行するときにはそのパスワードが必要になります。間違ったパスワードを指定した場合や、パスワードが設定されていないバックアップ セットにパスワードを指定した場合はエラーになります。

    重要な注意事項重要

    このパスワードは、メディア セットを保護する手段としては強力なものではありません。詳細については、各ステートメントの「権限」を参照してください。

メディア セット オプション

以下のオプションは、メディア セット全般に適用されます。

  • MEDIANAME = { media_name | **@**media_name_variable}
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY、および RESTORE VERIFYONLY

    メディアの名前を指定します。メディア名を指定する場合、その名前がバックアップ ボリューム上のメディア名と一致している必要があります。一致していない場合、復元操作は終了します。RESTORE ステートメントにメディア名を指定しない場合は、バックアップ ボリューム上のメディア名と一致するかどうかの確認は行われません。

    重要な注意事項重要

    バックアップ操作と復元操作で同じメディア名を一貫して使用することで、復元操作で選択されたメディアに対する安全性チェックが強化されます。

  • MEDIAPASSWORD = { mediapassword | **@**mediapassword_variable }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY、および RESTORE VERIFYONLY

    メディア セットのパスワードを指定します。メディア セットのパスワードは文字列です。

    注意

    この機能は、将来のバージョンの Microsoft SQL Server では削除される予定です。新しい開発作業では、この機能の使用を避け、現在この機能を使用しているアプリケーションは修正するようにしてください。

    メディア セットのフォーマット時にパスワードを設定した場合、メディア セット上のバックアップ セットにアクセスするときにはそのパスワードが必要になります。間違ったパスワードを指定した場合や、パスワードが設定されていないメディア セットにパスワードを指定した場合はエラーになります。

    重要な注意事項重要

    このパスワードは、メディア セットを保護する手段としては強力なものではありません。詳細については、各ステートメントの「権限」を参照してください。

  • BLOCKSIZE = { blocksize | **@**blocksize_variable }
    使用できるステートメント: RESTORE

    物理ブロック サイズをバイト単位で指定します。サポートされるサイズは、512、1024、2048、4096、8192、16384、32768、および 65536 (64 KB) バイトです。テープ デバイスの場合の既定値は 65536 バイトで、他のデバイスの場合の既定値は 512 バイトです。通常は、RESTORE でデバイスに適するブロック サイズが自動的に選択されるので、このオプションは不要です。ブロック サイズは、自動的に選択された値よりも明示的に指定された値が優先されます。

    CD-ROM からバックアップを復元する場合は、BLOCKSIZE=2048 と指定します。

    注意

    このオプションがパフォーマンスに影響するのは、通常、テープ デバイスから読み取るときだけです。

データ転送オプション

このオプションでは、バックアップ デバイスからのデータ転送を最適化できます。

  • BUFFERCOUNT = { buffercount | **@**buffercount_variable }
    使用できるステートメント: RESTORE

    復元操作に使用される I/O バッファーの総数を指定します。任意の正の整数を指定できますが、バッファー数が多いと Sqlservr.exe プロセスで仮想アドレス空間が不足し、"メモリ不足" エラーの原因となる場合があります。

    バッファーで使用される仮想アドレス空間の合計は、buffercount*****maxtransfersize の計算によって算出されます。

  • MAXTRANSFERSIZE = { maxtransfersize | **@**maxtransfersize_variable }
    使用できるステートメント: RESTORE

    バックアップ メディアと SQL Server の間で使用される最大転送単位をバイト単位で指定します。有効値は 65536 バイト (64 KB) の倍数で、最大有効値は 4194304 バイト (4 MB) です。

エラー管理オプション

このオプションでは、復元操作でバックアップのチェックサムを有効にするかどうか、およびエラー発生時に操作を停止するかどうかを指定できます。

  • { CHECKSUM | NO_CHECKSUM }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY、および RESTORE VERIFYONLY

    既定の動作では、チェックサムがある場合はチェックサムの確認が行われ、チェックサムがない場合は確認せずに動作が続行されます。

    • CHECKSUM
      バックアップ チェックサムを必ず確認することを指定します。バックアップにバックアップ チェックサムがない場合、復元操作は失敗し、チェックサムがないことを示すメッセージが返されます。

      注意

      ページ チェックサムは、バックアップ チェックサムが使用されている場合にのみバックアップ操作に関連します。

      既定では、無効なチェックサムが検出されると、RESTORE によってチェックサム エラーがレポートされ処理が停止しますが、CONTINUE_AFTER_ERROR を指定した場合は、破損による影響がない限り、チェックサム エラーと無効なチェックサムを含むページ番号が返された後、処理が続行します。

      バックアップ チェックサムの使用方法の詳細については、「バックアップ中および復元中のメディア エラーの検出と処置」を参照してください。

    • NO_CHECKSUM
      復元操作によるチェックサムの検証を、明示的に無効にします。

  • { STOP_ON_ERROR | CONTINUE_AFTER_ERROR }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY、および RESTORE VERIFYONLY

    • STOP_ON_ERROR
      最初にエラーが発生した時点で、復元操作を停止することを指定します。これは RESTORE の既定の動作ですが、VERIFYONLY では既定の動作ではありません。VERIFYONLY の既定の動作は、CONTINUE_AFTER_ERROR になります。

    • CONTINUE_AFTER_ERROR
      エラーが発生した後も、復元操作を続行することを指定します。

      エラーが発生しても続行する場合の詳細については、「バックアップの破損による SQL Server 復元エラーの対応」を参照してください。

      バックアップに破損したページが含まれている場合は、エラーがない別のバックアップ、たとえばページが破損する前に作成したバックアップなどを使用して、復元操作をもう一度実行することをお勧めします。ただし、最終的な手段として、復元ステートメントの CONTINUE_AFTER_ERROR オプションを使用して破損したバックアップを復元し、データの復旧を試みることもできます。

監視オプション

このオプションでは、バックアップ デバイスからのデータ転送を監視できます。

  • STATS [ = percentage ]
    使用できるステートメント: RESTORE および RESTORE VERIFYONLY

    指定したパーセンテージが完了するたびにメッセージを表示します。進行状況を判断する場合に使用できます。percentage を省略した場合、SQL Server では約 10% 完了するごとにメッセージが表示されます。

    STATS オプションでは、次のパーセンテージをレポートするためのしきい値に達した時点で、完了したパーセンテージがレポートされます。このしきい値は、指定したパーセンテージを正確に反映するものではありません。たとえば、STATS=10 の場合、データベース エンジンでは正確に 40% ではなく、43% の時点でメッセージが表示される場合があります。大きいバックアップ セットの場合、これは重要な問題にはなりません。それは、完了した I/O コール間の完了パーセンテージの差異はそれほど大きくないためです。

テープ オプション

このオプションはテープ デバイスにのみ適用されます。テープ以外のデバイスが使用される場合、このオプションは無視されます。

  • { REWIND | NOREWIND }
    このオプションはテープ デバイスにのみ適用されます。テープ以外のデバイスが使用される場合、このオプションは無視されます。

    • REWIND
      使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLY、および RESTORE VERIFYONLY

      SQL Server でテープを解放して巻き戻します。既定値は REWIND です。

    • NOREWIND
      使用できるステートメント: RESTORE および RESTORE VERIFYONLY

      これ以外の復元ステートメントで NOREWIND を指定するとエラーが発生します。

      SQL Server でバックアップ操作の後テープを開いたままにしておくことを指定します。このオプションを使用すると、1 つのテープに対して複数のバックアップ操作を実行する場合のパフォーマンスを向上できます。

      NOREWIND は暗黙的に NOUNLOAD も意味しています。この 2 つのオプションを同一の RESTORE ステートメント内で同時に使用することはできません。

      注意

      NOREWIND を使用する場合、テープ ドライブの所有権は SQL Server インスタンスによって保持されます。同じプロセス内で実行される BACKUP ステートメントや RESTORE ステートメントで REWIND オプションまたは UNLOAD オプションが使用されるか、サーバー インスタンスがシャットダウンすると、所有権は解放されます。テープを開いたままにすると、他のプロセスはそのテープにアクセスできません。開いているテープの一覧を表示する方法、および開いているテープを閉じる方法については、「バックアップ デバイス」を参照してください。

  • { UNLOAD | NOUNLOAD }
    使用できるステートメント: RESTORERESTORE FILELISTONLYRESTORE HEADERONLYRESTORE LABELONLYRESTORE REWINDONLY、および RESTORE VERIFYONLY

    このオプションはテープ デバイスにのみ適用されます。テープ以外のデバイスが使用される場合、このオプションは無視されます。

    注意

    UNLOAD または NOUNLOAD はセッションの設定であり、セッションが終了するまで、または代わりとなるオプションの指定によりリセットされるまで有効です。

    • UNLOAD
      バックアップ完了後、テープの巻き戻しおよびアンロードを自動的に行うことを指定します。UNLOAD はセッション開始時の既定の設定です。

    • NOUNLOAD
      RESTORE 操作の後、テープ ドライブにテープを読み込んだままにすることを指定します。

<replication_WITH_option>

このオプションは、バックアップ作成時にデータベースがレプリケートされた場合にのみ使用します。

  • KEEP_REPLICATION
    使用できるステートメント: RESTORE

    KEEP_REPLICATION は、ログ配布と共に動作するようにレプリケーションを設定する場合に使用します。これによって、データベースまたはログのバックアップをウォーム スタンバイ サーバーで復元し、データベースが復旧したときに、レプリケーションの設定が削除されるのを防ぐことができます。NORECOVERY オプションを指定してバックアップを復元する場合、このオプションは指定できません。復元の後、レプリケーションが適切に機能するには、次のことが必要です。

    • ウォーム スタンバイ サーバーにある msdb データベースおよび master データベースが、プライマリ サーバーにある msdb データベースおよび master データベースと同期していること。

    • ウォーム スタンバイ サーバーの名前が、プライマリ サーバーと同じ名前に変更されていること。

<change_data_capture_WITH_option>

このオプションは、バックアップ作成時にデータベースで変更データ キャプチャが有効になっていた場合にのみ使用します。

  • KEEP_CDC
    使用できるステートメント: RESTORE

    KEEP_CDC は、データベースまたはログのバックアップを別のサーバーで復元してデータベースを復旧するときに、変更データ キャプチャの設定が削除されないようにするために使用する必要があります。NORECOVERY オプションを指定してバックアップを復元する場合は、このオプションを指定できません。

    KEEP_CDC を指定してデータベースを復元すると、変更データ キャプチャ ジョブは作成されません。データベースを復元した後にログから変更を抽出するには、復元されたデータベースに対してキャプチャ プロセス ジョブとクリーンアップ ジョブを再作成します。詳細については、「sys.sp_cdc_add_job (Transact-SQL)」を参照してください。

<service_broker_WITH_options>  [ ,...n ]

Service Broker のメッセージ配信を有効または無効にするか、新しい Service Broker 識別子を設定します。メッセージ配信および Service Broker 識別子の詳細については、「Service Broker の ID の管理」を参照してください。このオプションは、バックアップ作成時にデータベースで Service Broker が有効になっていた (アクティブ化されていた) 場合にのみ使用します。

  • { ENABLE_BROKER  | ERROR_BROKER_CONVERSATIONS  | NEW_BROKER }
    使用できるステートメント: RESTORE DATABASE

    • ENABLE_BROKER
      復元の終わりに Service Broker メッセージ配信を有効にして、メッセージをすぐに送信できるようにすることを指定します。既定では、Service Broker メッセージ配信は復元中に無効化されています。データベースは、既存の Service Broker 識別子を保持します。

    • ERROR_BROKER_CONVERSATIONS
      データベースがアタッチまたは復元されていることを示すエラーと共に、すべてのメッセージ交換を終了します。これによりアプリケーションは、既存のメッセージ交換に対して、通常のクリーンアップを実行できます。Service Broker メッセージ配信はこの操作が完了するまで無効になり、その後有効になります。データベースは、既存の Service Broker 識別子を保持します。

    • NEW_BROKER
      データベースに新しい Service Broker 識別子を割り当てることを指定します。データベースは新しい Service Broker と見なされるため、データベースにおける既存のメッセージ交換は、終了ダイアログ メッセージを生成せずに、直ちに削除されます。古い Service Broker 識別子を参照するルートは、新しい識別子を使用して作成し直す必要があります。

<point_in_time_WITH_options>

使用できるステートメント: RESTORE {DATABASE|LOG} (完全復旧モデルまたは一括ログ復旧モデルの場合のみ)

STOPAT、STOPATMARK、または STOPBEFOREMARK 句で目的の復旧ポイントを指定することで、特定の時点またはトランザクションにデータベースを復元できます。指定された時間またはトランザクションへの復元は、常にログ バックアップから行われます。復元シーケンスのすべての RESTORE LOG ステートメントで、同一の STOPAT、STOPATMARK、STOPBEFOREMARK のいずれかの句で目的の時間またはトランザクションを指定する必要があります。

特定の時点への復元の前提条件として、最初にエンド ポイントが目的の復旧ポイントよりも前になっているデータベースの完全バックアップを復元する必要があります。復元するデータベース バックアップを識別しやすくするには、RESTORE DATABASE ステートメントで WITH STOPAT、WITH STOPATMARK、WITH STOPBEFOREMARK のいずれかの句をオプションで指定し、データのバックアップが指定した目的の時間よりも後になっている場合はエラーが発生するようにします。ただし、目的の時間が指定されている場合でも常にデータのバックアップ全体が復元されます。

注意

特定の時点を指定する WITH オプションは RESTORE_DATABASE と RESTORE_LOG で似ていますが、mark_name 引数をサポートするのは RESTORE LOG だけです。

  • { STOPAT | STOPATMARK | STOPBEFOREMARK }

    • STOPAT = { 'datetime' | **@**datetime_var }
      datetime または **@**datetime_var パラメーターで指定された日時の状態にデータベースを復元するように指定します。日時の指定の詳細については、「日時データの使用」を参照してください。

      STOPAT に変数を使用する場合、変数のデータ型は varchar、char、smalldatetime、または datetime であることが必要です。指定した日付と時刻以前に書き込まれたトランザクション ログ レコードだけが、データベースに適用されます。

      注意

      指定した STOPAT 時間が前回のログ バックアップ後である場合、データベースは、NORECOVERY を指定して RESTORE LOG を実行した場合と同様に、復旧されていない状態のままになります。

      詳細については、「バックアップ内の特定の時点へのデータベースの復元」を参照してください。

    • STOPATMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
      復旧を、指定された復旧ポイントに指定します。指定したトランザクションは復旧に含められますが、このトランザクションがコミットされるのは、トランザクションの実際の生成時に既にコミットされていた場合のみです。

      lsn_number パラメーターは、RESTORE DATABASE と RESTORE LOG の両方でサポートされています。このパラメーターは、ログ シーケンス番号を指定します。

      mark_name パラメーターは、RESTORE LOG ステートメントでのみサポートされています。このパラメーターは、ログ バックアップでトランザクション マークを識別します。

      RESTORE LOG ステートメントで AFTER datetime を省略した場合は、指定した名前を持つ最初のマークで復旧が停止します。AFTER datetime を指定すると、datetime 以降の指定した名前を持つ最初のマークで復旧が停止します。

      注意

      指定したマーク、LSN、または時間が前回のログ バックアップ後である場合、データベースは、NORECOVERY を指定して RESTORE LOG を実行した場合と同様に、復旧されていない状態のままになります。

      詳細については、「マークされたトランザクションの使用 (完全復旧モデル)」および「ログ シーケンス番号 (LSN) への復旧」を参照してください。

    • STOPBEFOREMARK = { 'mark_name' | 'lsn:lsn_number' } [ AFTER 'datetime' ]
      復旧を、指定された復旧ポイントまでに指定します。指定したトランザクションは復旧に含められず、WITH RECOVERY を使用していればロールバックされます。

      lsn_number パラメーターは、RESTORE DATABASE と RESTORE LOG の両方でサポートされています。このパラメーターは、ログ シーケンス番号を指定します。

      mark_name パラメーターは、RESTORE LOG ステートメントでのみサポートされています。このパラメーターは、ログ バックアップでトランザクション マークを識別します。

      RESTORE LOG ステートメントで AFTER datetime を省略した場合は、指定した名前を持つ最初のマークの直前で復旧が停止します。AFTER datetime を指定すると、datetime 以降の指定した名前を持つ最初のマークの直前で復旧が停止します。

    重要な注意事項重要

    部分復元シーケンスで FILESTREAM ファイル グループを除外した場合、特定の時点への復元はサポートされません。復元シーケンスを強制的に実行して続行することもできます。ただし、RESTORE ステートメントから除外された FILESTREAM ファイル グループは復元できません。特定の時点への復元を強制的に実行するには、STOPAT、STOPATMARK、または STOPBEFOREMARK オプションに CONTINUE_AFTER_ERROR オプションを組み合わせて指定します。CONTINUE_AFTER_ERROR を指定した場合、部分復元シーケンスは正常に実行されますが、FILESTREAM ファイル グループは復旧できなくなります。

結果セット

結果セットについては、次のトピックを参照してください。

説明

追加説明については、次のトピックを参照してください。

バックアップ セットの指定

バックアップ セットには、正常に終了したバックアップ操作 1 回分のバックアップが含まれます。RESTORE、RESTORE FILELISTONLY、RESTORE HEADERONLY、および RESTORE VERIFYONLY ステートメントは、単一または複数の指定バックアップ デバイス上のメディア セット内にある単一のバックアップ セットに対して機能します。したがって、該当するメディア セット内の必要なバックアップを指定する必要があります。バックアップ セットの backup_set_file_number は、RESTORE HEADERONLY ステートメントを使用して取得できます。

復元するバックアップ セットを指定するときのオプションは次のとおりです。

FILE ={ backup_set_file_number | **@**backup_set_file_number }

ここで、backup_set_file_number はメディア セット内のバックアップの位置を示します。たとえば、backup_set_file_number が 1 (FILE = 1) の場合はバックアップ メディア内の最初のバックアップ セットを示し、backup_set_file_number が 2 (FILE = 2) の場合は 2 番目のバックアップ セットを示します。

次の表で説明するように、このオプションの動作はステートメントによって異なります。

ステートメント

バックアップ セットの FILE オプションの動作

RESTORE

既定のバックアップ セット ファイル番号は 1 です。1 つの RESTORE ステートメントでは、1 つのバックアップ セットの FILE オプションのみが許可されます。ここではバックアップ セットを順序どおり指定することが重要です。

RESTORE FILELISTONLY

既定のバックアップ セット ファイル番号は 1 です。

RESTORE HEADERONLY

既定では、メディア セット内のすべてのバックアップ セットが処理されます。RESTORE HEADERONLY の結果セットでは、メディア セット内における位置など、各バックアップ セットに関する情報が返されます。特定のバックアップ セットの情報が返されるようにするには、そのバックアップ セットの位置番号を FILE オプションの backup_set_file_number 値として使用します。

注意
テープ メディアの場合、RESTORE HEADER では、読み込まれているテープのバックアップ セットのみが処理されます。

RESTORE VERIFYONLY

backup_set_file_number の既定値は 1 です。

注意

バックアップ セットを指定する FILE オプションは、データベース ファイルを指定する FILE オプション (FILE = { logical_file_name_in_backup | @logical_file_name_in_backup_var }) とは関連はありません。

WITH オプションと対応ステートメントの一覧

WITH オプション BLOCKSIZE、BUFFERCOUNT、MAXTRANSFERSIZE、PARTIAL、KEEP_REPLICATION、{ RECOVERY | NORECOVERY | STANDBY }、REPLACE、RESTART、RESTRICTED_USER、および { STOPAT | STOPATMARK | STOPBEFOREMARK } は、RESTORE ステートメントでのみ使用できます。

注意

PARTIAL オプションは、RESTORE DATABASE でのみ使用できます。

次の表は、1 つ以上のステートメントで使用できる WITH オプションと、各オプションの対応ステートメントの一覧です。チェックマーク (√) はそのオプションが使用できることを示し、ダッシュ (—) は使用できないことを示します。

WITH オプション

RESTORE

RESTORE FILELISTONLY

RESTORE HEADERONLY

RESTORE LABELONLY

RESTORE REWINDONLY

RESTORE VERIFYONLY

{ CHECKSUM

| NO_CHECKSUM }

{ CONTINUE_AFTER_ERROR

| STOP_ON_ERROR }

FILE1

LOADHISTORY

MEDIANAME

MEDIAPASSWORD

MOVE

PASSWORD

{ REWIND | NOREWIND }

REWIND のみ

REWIND のみ

REWIND のみ

STATS

{ UNLOAD | NOUNLOAD }

1 FILE **=**backup_set_file_number。{FILE | FILEGROUP} とは異なります。

例については、次のトピックを参照してください。