次の方法で共有

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

  • [アーティクル]

このトピックでは、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 を実行し、さらに、そのデータベースのストアド プロシージャやその他のユーザー定義コードなどのコードを調べます。

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

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

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

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

    注意注

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

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

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

例

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

  1. 次の Transact-SQL ステートメントを実行してデータベースをデタッチします。

    USE master;
GO
EXEC sp_detach_db @dbname = N'MyDatabase';
GO

  2. 任意の方法で、データ ファイルとログ ファイルを新しい場所にコピーします。

    重要な注意事項重要

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

    ファイルをネットワーク経由でリモート コンピューターのディスクにコピーするには、そのリモート コンピューターの UNC (Universal Naming Convention) 名を使用します。 UNC 名の形式は、**\\Servername\Sharename\Path\**Filename です。 ローカル ハード ディスクにファイルを書き込む場合と同様、リモート ディスクでのファイルの読み取りや書き込みに必要な適切な権限が、SQL Server のインスタンスで使用するユーザー アカウントに許可されている必要があります。

  3. 次の 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 回限りで済み、今後のキー ローテーション方法には影響を与えません。

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