デタッチとアタッチを使用したデータベースのアップグレード (Transact-SQL)

[アーティクル]
06/25/2013

このトピックでは、SQL Server 2012 でデタッチ操作とアタッチ操作を使用し、SQL Server 2005、SQL Server 2008、または SQL Server 2008 R2 のデータベースをアップグレードする方法について説明します。 SQL Server 2012 にアタッチした後は、データベースが直ちに使用可能となり、自動的にアップグレードされます。

このトピックの内容

作業を開始する準備:

制限事項と制約事項

推奨事項
SQL Server データベースをアップグレードするには:

デタッチ操作とアタッチ操作の使用
補足情報: SQL Server データベースのアップグレード後

作業を開始する準備

制限事項と制約事項

システムデータベースをアタッチすることはできません。
アタッチとデタッチを行うと、cross db ownership chaining オプションが 0 に設定され、複数データベースの組み合わせ所有権が無効になります。組み合わせ所有権の有効化の詳細については、「cross db ownership chaining サーバー構成オプション」を参照してください。
レプリケートされたデータベースをアタッチする際に、そのデータベースがデタッチではなくコピーされたものである場合は、次の点を考慮してください。
- 同じサーバーインスタンスのアップグレードされたバージョンにデータベースをアタッチする場合は、アタッチ操作が完了した後、sp_vupgrade_replication を実行してレプリケーションをアップグレードする必要があります。詳細については、「sp_vupgrade_replication (Transact-SQL)」を参照してください。
- バージョンに関係なく別のサーバーインスタンスにデータベースをアタッチする場合は、アタッチ操作が完了した後、sp_removedbreplication を実行してレプリケーションを削除する必要があります。詳細については、「sp_removedbreplication (Transact-SQL)」を参照してください。

推奨事項

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

デタッチとアタッチを使用してデータベースをアップグレードするには

データベースをデタッチします。詳細については、「データベースのデタッチ」を参照してください。

必要に応じて、デタッチされたデータベースファイルとログファイルを移動します。

新しいログファイルを作成する場合であっても、ログファイルをデータファイルと一緒に移動する必要があります。場合によっては、データベースの再アタッチに既存のログファイルが必要になります。したがって、デタッチしたログファイルを使わずにデータベースを正常にアタッチできるまで、デタッチしたログファイルは必ずすべて保管しておいてください。

注
ログファイルを指定せずにデータベースのアタッチを試みると、アタッチ操作は元の場所でログファイルを検索します。元の場所にログの元のコピーが依然として存在する場合は、そのコピーがアタッチされます。元のログファイルが使用されないようにするには、新しいログファイルのパスを指定するか、ログファイルの元のコピーを (新しい場所にコピーした後で) 削除します。

ログファイルを指定せずにデータベースのアタッチを試みると、アタッチ操作は元の場所でログファイルを検索します。元の場所にログの元のコピーが依然として存在する場合は、そのコピーがアタッチされます。元のログファイルが使用されないようにするには、新しいログファイルのパスを指定するか、ログファイルの元のコピーを (新しい場所にコピーした後で) 削除します。

コピーしたファイルを SQL Server 2012 のインスタンスにアタッチします。詳細については、「データベースのアタッチ」を参照してください。

[トップに戻る] リンクで使用される矢印アイコン [Top]

例

次の例では、データベースのコピーを以前のバージョンの SQL Server からアップグレードします。 Transact-SQL ステートメントは、アタッチするサーバーインスタンスに接続されたクエリエディターウィンドウで実行しています。

次の Transact-SQL ステートメントを実行してデータベースをデタッチします。
```
USE master;
GO
EXEC sp_detach_db @dbname = N'MyDatabase';
GO
```
任意の方法で、データファイルとログファイルを新しい場所にコピーします。

重要

実稼動データベースの場合は、データベースとトランザクションログを別のディスクに配置します。

ファイルをネットワーク経由でリモートコンピューターのディスクにコピーするには、そのリモートコンピューターの UNC (Universal Naming Convention) 名を使用します。 UNC 名の形式は、**\\Servername\Sharename\Path\**Filename です。ローカルハードディスクにファイルを書き込む場合と同様、リモートディスクでのファイルの読み取りや書き込みに必要な適切な権限が、SQL Server のインスタンスで使用するユーザーアカウントに許可されている必要があります。
次の Transact-SQL ステートメントを使用して、移動したデータベースとログをアタッチします (ログのアタッチは省略できます)。
```
USE master;
GO
CREATE DATABASE MyDatabase 
    ON (FILENAME = 'C:\MySQLServer\MyDatabase.mdf'),
    (FILENAME = 'C:\MySQLServer\Database.ldf')
    FOR ATTACH;
GO
```
SQL Server Management Studio では、新しくアタッチされたデータベースはオブジェクトエクスプローラーにすぐに表示されません。このデータベースを表示するには、オブジェクトエクスプローラーで、[表示] をクリックし、[最新の情報に更新] をクリックします。オブジェクトエクスプローラーの [データベース] ノードを展開すると、データベースの一覧に新しくアタッチされたデータベースが表示されるようになります。

重要
実稼動データベースの場合は、データベースとトランザクションログを別のディスクに配置します。

補足情報: SQL Server データベースのアップグレード後

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

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

アップグレード前のユーザーデータベースの互換性レベルが 90 または 100 の場合は、アップグレード後も互換性レベルは変わりません。アップグレード前の互換性レベルが 80 以下の場合、アップグレードされたデータベースの互換性レベルは 90 に設定されます。これは、SQL Server 2012 でサポートされている下限の互換性レベルです。詳細については、「ALTER DATABASE 互換性レベル (Transact-SQL)」を参照してください。

アップグレードされたサーバーインスタンスでのメタデータの管理

データベースを別のサーバーインスタンスにアタッチするときは、ユーザーおよびアプリケーションに一貫した使用環境を提供するために、アタッチ先のサーバーインスタンスで、ログイン、ジョブ、権限などのデータベースのメタデータの一部またはすべてを作成し直す必要が生じる場合があります。詳細については、「データベースを別のサーバーインスタンスで使用できるようにするときのメタデータの管理 (SQL Server)」を参照してください。

3DES から AES へのサービスマスターキーとデータベースマスターキーの暗号化の変更

SQL Server 2012 は、AES 暗号化アルゴリズムを使用してサービスマスターキー (SMK) とデータベースマスターキー (DMK) を保護します。 AES は、以前のバージョンで使用されていた 3DES よりも新しい暗号化アルゴリズムです。データベースが最初に SQL Server の新しいインスタンスにアタッチまたは復元されるとき、データベースマスターキー (サービスマスターキーにより暗号化されたもの) のコピーはまだサーバーに格納されていません。 OPEN MASTER KEY ステートメントを使用して、データベースマスターキー (DMK) の暗号化を解除する必要があります。 DMK の暗号化が解除されると、ALTER MASTER KEY REGENERATE ステートメントを使用して、サービスマスターキー (SMK) で暗号化された DMK のコピーをサーバーに提供することにより、将来、自動的に暗号化解除することも可能となります。データベースを以前のバージョンからアップグレードした場合、新しい AES アルゴリズムを使用するように DMK を再作成する必要があります。 DMK の再作成方法の詳細については、「ALTER MASTER KEY (Transact-SQL)」を参照してください。 DMK キーを再作成して AES にアップグレードするのに必要な時間は、DMK によって保護されているオブジェクトの数によって異なります。 DMK キーを再作成して AES にアップグレードする作業は、1 回限りで済み、今後のキーローテーション方法には影響を与えません。