新しい場所と名前でデータベースを復元する方法 (Transact-SQL)

このトピックでは、新しい場所と新しい名前 (省略可能) でデータベースの完全バックアップを復元する方法について説明します。この手順に従うと、同じサーバー インスタンスまたは別のサーバー インスタンスでデータベースを移動したり、データベースのコピーを作成できます。データベースの移動に関する考慮事項については、「バックアップと復元によるデータベースのコピー」を参照してください。

前提条件と推奨事項

• 暗号化されたデータベースを復元するには、データベースの暗号化に使用された証明書または非対称キーにアクセスできることが必要です。証明書または非対称キーがないと、データベースは復元できません。このため、バックアップが必要である間は、データベース暗号化キーの暗号化に使用する証明書を保持しておく必要があります。詳細については、「SQL Server の証明書と非対称キー」を参照してください。

• セキュリティを確保するため、不明なソースや信頼されていないソースからのデータベースは、アタッチまたは復元しないことをお勧めします。そのようなデータベースには、意図しない Transact-SQL コードを実行したり、スキーマまたは物理データベース構造を変更することによりエラーを発生させる悪意のあるコードが含まれている可能性があるからです。不明または信頼できないソースのデータベースを使用する前に、実稼働用ではないサーバーでそのデータベースに対し DBCC CHECKDB を実行し、さらに、そのデータベースのストアド プロシージャやその他のユーザー定義コードなどのコードを調べます。

アップグレード後のデータベース互換性レベル

tempdb、model、msdb、および Resource データベースの互換性レベルは、アップグレード後、100 に設定されます。master システム データベースは、互換性レベルが 80 を下回っている場合は、アップグレード前の互換性レベルを保持します。アップグレード前の master の互換性レベルが 80 を下回っている場合は、アップグレード後、80 に設定されます。

アップグレード前のユーザー データベースの互換性レベルが 80 または 90 の場合は、アップグレード後も互換性レベルは変わりません。アップグレード前の互換性レベルが 70 以下の場合、アップグレードされたデータベースの互換性レベルは 80 に設定されます。これは、SQL Server 2008 でサポートされている下限の互換性レベルです。

注意
新しいユーザー データベースには、model データベースの互換性レベルが継承されます。

手順

データベースを新しい場所と名前に復元するには

1. 必要に応じて、復元するデータベースの完全バックアップを含んでいるバックアップ セット内のファイルの論理名と物理名を判断します。このステートメントは、バックアップ セットに保存されているデータベースとログ ファイルのリストを返します。基本構文は次のとおりです。

   RESTORE FILELISTONLY FROM <backup_device> WITH FILE = backup_set_file_number

   注意
   バックアップ セットの backup_set_file_number は、RESTORE HEADERONLY ステートメントを使用して取得できます。

   このステートメントは、多くの WITH オプションもサポートします。詳細については、「RESTORE FILELISTONLY (Transact-SQL)」を参照してください。

2. RESTORE DATABASE ステートメントを使用し、データベースの完全バックアップを復元します。既定で、データとログ ファイルが元の場所に復元されます。データベースを再配置するには、MOVE オプションを使用して、各データベース ファイルを再配置し、既存ファイルとの衝突が発生するのを防ぎます。

   データベースを新しい場所と新しい名前に復元するための基本的な Transact-SQL 構文は以下のとおりです。

   RESTORE DATABASE new_database_name

   FROM backup_device [ ,...n ]

   [ WITH

      {

           [ RECOVERY | NORECOVERY ]

      [ , ] [ FILE ={ backup_set_file_number | @backup\_set\_file\_number } ]

      [ , ] MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ,...n ]

      }

   ;

   注意
   データベースを別のディスクに再配置する準備をする場合は、容量が十分あるかどうか、および既存のファイルと衝突する可能性がないかどうかを確認してください。この作業は、RESTORE VERIFYONLY ステートメントを使用して、RESTORE DATABASE ステートメントで使用するのと同じ MOVE パラメータを指定する必要があります。

   次の表で、データベースを新しい場所に復元するという点で、この RESTORE ステートメントの引数を説明します。これらの引数の詳細については、「RESTORE (Transact-SQL)」を参照してください。

   • new_database_name
     データベースの新しい名前。

     注意
     異なるサーバー インスタンスにデータベースを復元している場合は、新しい名前ではなく元のデータベース名を使用することができます。

   • backup_device [ ,...n ]
     データベース バックアップを復元する 1 ～ 64 個のバックアップ デバイスのコンマ区切りリストを指定します。物理バックアップ デバイスを指定したり、対応する論理バックアップ デバイス (定義されている場合) を指定したりできます。物理バックアップ デバイスを指定するには、DISK オプションまたは TAPE オプションを使用します。

     { DISK | TAPE } **=**physical_backup_device_name

     詳細については、「バックアップ デバイス」を参照してください。

   • { RECOVERY | NORECOVERY }
     データベースで完全復旧モデルを使用している場合は、データベースの復元後にトランザクション ログ バックアップを適用しなければならない場合があります。この場合は、NORECOVERY オプションを指定します。

     そうでない場合は、既定の RECOVERY オプションを使用します。

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

     このオプションを指定しない場合、既定ではバックアップ デバイスの 1 番目のバックアップ セットを使用します。

     詳細については、「RESTORE の引数 (Transact-SQL)」の「バックアップ セットの指定」を参照してください。

   • MOVE 'logical_file_name_in_backup' TO 'operating_system_file_name' [ ,...n ]
     logical_file_name_in_backup で指定されるデータまたはログ ファイルが、operating_system_file_name で指定される位置に復元されることを指定します。バックアップ セットから新しい位置に復元する論理ファイルごとに、MOVE ステートメントを指定してください。

     オプション	説明
     logical_file_name_in_backup	バックアップ セット内のデータまたはログ ファイルの論理名を指定します。バックアップ セット内のデータ ファイルまたはログ ファイルの論理ファイル名は、バックアップ セットが作成されたときのデータベース内における論理名と同じです。 注意 バックアップ セットに含まれる論理ファイルの一覧を取得するには、RESTORE FILELISTONLY を使用します。
     operating_system_file_name	logical_file_name_in_backup で指定したファイルの新しい場所を指定します。ファイルはこの場所に復元されます。 必要に応じて、operating_system_file_name は復元されたファイルの新しいファイル名を指定します。これは、同じサーバー インスタンスで既存のデータベースのコピーを作成する場合に必要です。
     n	追加の MOVE ステートメントを指定できることを示すプレースホルダです。

注意

SQL Server 2005 または SQL Server 2000 のデータベースを SQL Server 2008 に復元した後は、データベースが直ちに使用可能となり、自動的にアップグレードされます。データベースにフルテキスト インデックスがある場合、アップグレード プロセスでは、upgrade_optionサーバー プロパティの設定に応じて、インポート、リセット、または再構築が行われます。アップグレード オプションがインポート (upgrade_option = 2) または再構築 (upgrade_option = 0) に設定されている場合、アップグレード中はフルテキスト インデックスを使用できなくなります。インデックスを作成するデータ量によって、インポートには数時間、再構築には最大でその 10 倍の時間がかかることがあります。なお、アップグレード オプションがインポートに設定されており、フルテキスト カタログが使用できない場合は、関連付けられたフルテキスト インデックスが再構築されます。upgrade_option サーバー プロパティの設定を変更するには、sp_fulltext_service を使用します。

例

説明

この例では、MyAdvWorks という新しいデータベースを作成します。MyAdvWorks は、AdventureWorks_Data と AdventureWorks_Log という 2 つのファイルが含まれた既存の AdventureWorks データベースのコピーです。このデータベースは、単純復旧モデルを使用しています。AdventureWorks データベースはサーバー インスタンスに既に存在するため、バックアップ内のファイルを新しい場所に復元する必要があります。RESTORE FILELISTONLY ステートメントは、復元するデータベース内のファイル数と名前を判断するために使用します。データベース バックアップは、バックアップ デバイスの 1 番目のバックアップ セットです。

注意
AdventureWorks データベースの完全バックアップを作成する方法については、「データベースの完全バックアップを作成する方法 (Transact-SQL)」を参照してください。

注意
特定日時への復元を含む、トランザクション ログのバックアップと復元の例では、次の MyAdvWorks の例と同様、AdventureWorks から作成した MyAdvWorks_FullRM データベースを使用します。ただし、作成された MyAdvWorks_FullRM データベースは、ALTER DATABASE MyAdvWorks_FullRM SET RECOVERY FULL を実行して完全復旧モデルを使用するように変更する必要があります。

コード

USE master
GO
-- First determine the number and names of the files in the backup.
-- AdventureWorks_Backup is the name of the backup device.
RESTORE FILELISTONLY
   FROM AdventureWorks_Backup
-- Restore the files for MyAdvWorks.
RESTORE DATABASE MyAdvWorks
   FROM AdventureWorks_Backup
   WITH RECOVERY,
   MOVE 'AdventureWorks_Data' TO 'D:\MyData\MyAdvWorks_Data.mdf', 
   MOVE 'AdventureWorks_Log' TO 'F:\MyLog\MyAdvWorks_Log.ldf'
GO

関連項目

参照

RESTORE (Transact-SQL)

概念

データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理

バックアップと復元のセキュリティについての考慮事項

バックアップと復元によるデータベースのコピー

チュートリアル