ApsaraDB RDS:セルフマネージド型SQL Serverインスタンスの増分バックアップデータを、クラウドディスクでSQL Server 2008 R2を実行するか、またはSQL Server 2012以降を実行するApsaraDB RDSインスタンスに移行する

シナリオ

このトピックの移行方法は、次のシナリオに適しています。

• 論理モードではなく物理モードでRDSインスタンスのターゲットデータベースにデータを移行します。

  説明

  • 物理移行では、物理バックアップファイルを使用してデータを移行できます。 論理移行を使用すると、実行されたDMLステートメントをRDSインスタンスのターゲットデータベースに書き込むことができます。

  • 物理移行により、ソースデータベースとターゲットデータベース間の100% データの整合性が確保されます。 論理移行は、100% データの一貫性を保証できません。 例えば、インデックス断片化および統計情報は、移行後に変化し得る。

• 分レベルのダウンタイムでデータを移行します。

  説明

  自己管理型SQL Serverインスタンスのデータ量が100 GB未満で、時間の影響を受けるサービスを提供しない場合は、完全バックアップファイルを使用してデータをRDSインスタンスに移行することをお勧めします。 移行により、2時間のダウンタイムが発生する可能性があります。 詳細については、「セルフマネージド型SQL Serverインスタンスのフルバックアップデータを、クラウドディスクでSQL Server 2008 R2を実行するか、またはSQL Server 2012以降を実行するApsaraDB RDSインスタンスに移行する」をご参照ください。

前提条件

• RDSインスタンスは、クラウドディスクを使用してSQL Server 2008 R2を実行するか、SQL Server 2012以降を実行します。 RDSインスタンス上の既存のデータベースの名前は、自己管理型SQL Serverインスタンス上のソースデータベースの名前とは異なります。 RDSインスタンスの作成方法の詳細については、「ApsaraDB RDS For SQL Serverインスタンスの作成」をご参照ください。

  説明

  クラウドディスクでSQL Server 2008 R2を実行するRDSインスタンスは、購入できなくなりました。 詳細については、「 [EOS /廃止] クラウドディスクを備えたSQL Server 2008 R2を実行しているApsaraDB RDSインスタンスは、2023年7月14日から購入できなくなりました」をご参照ください。

• RDSインスタンスの使用可能なストレージは十分です。 使用可能なストレージが不十分な場合は、移行を開始する前にRDSインスタンスのストレージ容量を拡張する必要があります。 詳細については、「ApsaraDB RDS For SQL Serverインスタンスの仕様の変更」をご参照ください。

• RDSインスタンス用に特権アカウントが作成されます。 詳細については、「アカウントとデータベースの作成」をご参照ください。

• 自己管理型SQL Serverインスタンスは、FULL復旧モデルを使用します。

  説明

  • トランザクションログのバックアップは、自己管理型SQL Serverインスタンスの増分バックアップデータをRDSインスタンスに移行する場合に必要です。 自己管理型SQL ServerインスタンスがSIMPLE復旧モデルを使用している場合、トランザクションログはバックアップできません。

  • 差分バックアップファイルのサイズが大きい場合、自己管理型SQL Serverインスタンスの増分バックアップデータをRDSインスタンスに移行するために必要な時間が長くなることがあります。

• 自己管理型SQL Serverインスタンスで実行されるDBCC CHECKDBステートメントの出力は、割り当てエラーまたは整合性エラーが発生しないことを示しています。 割り当てエラーまたは整合性エラーが発生しなかった場合、次の実行結果が返されます。

  ...
  CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
  DBCC execution completed. DBCCがエラーメッセージを印刷した場合は、システム管理者に連絡してください。

• OSSが有効化されています。 詳細については、「OSSの有効化」をご参照ください。

• OSSバケットとRDSインスタンスは同じリージョンにあります。 詳細については、「手順2: 生成された完全バックアップファイルをOSSバケットにアップロードする」をご参照ください。

• RAMユーザーを使用する場合は、次の要件が満たされていることを確認してください。

  • AliyunOSSFullAccessおよびAliyunRDSFullAccessポリシーはRAMユーザーにアタッチされます。 RAMユーザーに権限を付与する方法の詳細については、「RAMを使用してOSS権限を管理する」および「RAMを使用してApsaraDB RDS権限を管理する」をご参照ください。

  • ApsaraDB RDSのサービスアカウントは、Alibaba Cloudアカウントを使用してOSSバケットにアクセスすることで承認されます。

  • カスタムポリシーは、Alibaba Cloudアカウントを使用して手動で作成され、RAMユーザーにアタッチされます。 カスタムポリシーの作成方法の詳細については、「カスタムポリシーの作成」の「JSONタブでカスタムポリシーを作成する」をご参照ください。

    カスタムポリシーには次のコンテンツを使用する必要があります。

    {
        "Version": "1",
        "Statement": [
            {
                "Action": [
                    "ram:GetRole"
                ],
                "リソース": "acs:ram:*:*:role/AliyunRDSImportRole" 、
                "Effect": "Allow"
            }
        ]
    }

使用上の注意

• このトピックで説明する移行方法は、データベースレベルです。 自己管理型SQL Serverインスタンス上の1つのデータベースのバックアップデータのみをRDSインスタンスに一度に移行できます。 自己管理型SQL Serverインスタンス上の複数またはすべてのデータベースのバックアップデータを一度に移行する場合は、インスタンスレベルの移行方法を使用することをお勧めします。 詳細については、「セルフマネージドSQL ServerインスタンスからApsaraDB RDS For SQL Serverインスタンスへのデータの移行」をご参照ください。

• 新しいバージョンのSQL Serverから以前のバージョンのSQL Serverへの移行はサポートされていません。 たとえば、自己管理型SQL ServerインスタンスがSQL Server 2016を実行し、RDSインスタンスがSQL Server 2012を実行している場合、自己管理型SQL ServerインスタンスのバックアップデータをRDSインスタンスに移行することはできません。

• バックアップファイルの名前には、アットマーク (@) や縦棒 (|) などの特殊文字を含めることはできません。 バックアップファイルの名前に特殊文字が含まれている場合、移行は失敗します。

• ApsaraDB RDSのサービスアカウントにOSSバケットへのアクセスを許可すると、リソースアクセス管理 (RAM) にAliyunRDSImportRoleという名前のロールが作成されます。 このロールは変更または削除しないでください。 このロールを変更または削除した場合、バックアップファイルはOSSバケットからダウンロードできません。 このロールを変更または削除する場合は、移行ウィザードを使用してサービスアカウントを再承認する必要があります。

• RDSインスタンスは、自己管理型SQL Serverインスタンスのアカウントを引き継ぎません。 移行が完了したら、ApsaraDB RDSコンソールでRDSインスタンスのアカウントを作成する必要があります。

• 移行が完了する前に、OSSバケットからバックアップファイルを削除しないでください。 移行が完了する前にバックアップファイルを削除すると、移行は失敗します。

• バックアップファイルの名前は、bak、diff、trn、またはlogで接尾辞を付ける必要があります。 次のリストでは、サフィックスについて説明します。

  • bak: 完全バックアップファイルを示します。

  • diff: 差分バックアップファイルを示します。

  • trnまたはlog: トランザクションのログバックアップファイルを示します。

  説明

  このトピックで提供されているバックアップスクリプトを使用してバックアップファイルが生成されていない場合、またはバックアップファイルが上記のサフィックスを使用していない場合、システムはバックアップファイルのタイプを識別できないことがあります。 これは後続の操作に影響します。

移行プロセス

前述の移行は、ダウンタイムを最小限に抑える方法の例を示しています。 アプリケーションは引き続き実行でき、最後のログバックアップまでアプリケーションを停止する必要はありません。 この例では、アプリケーションのダウンタイムは5分を超えません。

ステップ1: ソースデータベースのバックアップ

1. バックアップスクリプトファイルをダウンロードします。 次に、SQL Server Management Studio (SSMS) を使用してファイルを開きます。

2. 次のパラメーターを設定します。

   パラメーター	説明
   @backup_databases_list	バックアップするソースデータベースの名前。 複数のデータベースを指定する場合は, これらのデータベースの名前をセミコロン (;) またはコンマ (,) で区切ります。
   @backup_type	バックアップの種類。 有効な値： "FULL": フルバックアップ "DIFF": 差分バックアップ "LOG": ログバックアップ
   @backup_folder	バックアップファイルの格納に使用されるディレクトリ。 指定されたディレクトリが存在しない場合、システムは自動的にディレクトリを作成します。
   @is_run	バックアップまたはチェックを実行するかどうかを指定します。 有効な値： "1"：バックアップを実行します。 0: チェックのみを実行します。

3. バックアップスクリプトを実行します。

手順2: バックアップファイルをOSSバケットにアップロードする

1. OSSバケットを作成します。

   1. OSSコンソールにログインします。

   2. 左側のナビゲーションウィンドウで、[バケット] をクリックします。 [バケット] ページで、[バケットの作成] をクリックします。

   3. 次のパラメーターを設定します。 他のパラメーターのデフォルト値を保持します。

      重要

      • 作成されたOSSバケットはデータ移行にのみ使用され、データ移行が完了すると使用されなくなります。 キーパラメーターのみを設定する必要があります。 データのリークや過剰なコストを防ぐために、できるだけ早い機会にデータ移行が完了した後にOSSバケットを削除することを推奨します。

      • OSSバケットの作成時にデータ暗号化を有効にしないでください。 詳細については、「データ暗号化」をご参照ください。

      パラメーター	説明	例
      バケット名	OSS バケットの名前。 名前はグローバルに一意であり、設定後に変更することはできません。 命名規則: 名前には、小文字、数字、およびハイフン (-) を使用できます。 先頭と末尾は小文字または数字である必要があります。 名前の長さは 3 ~ 63 文字である必要があります。	migratetest
      リージョン	OSS バケットの名前です。 内部ネットワークを介してElastic Compute Service (ECS) インスタンスからOSSバケットにデータをアップロードし、内部ネットワークを介してRDSインスタンスにデータを復元する場合は、OSSバケット、ECSインスタンス、およびRDSインスタンスが同じリージョンにあることを確認してください。	中国 (杭州)
      ストレージクラス	バケットのストレージクラス。 [標準] を選択します。 このトピックで説明するクラウド移行操作は、他のストレージクラスのバケットでは実行できません。	標準

2. バックアップファイルをOSSバケットにアップロードします。

   説明

   RDSインスタンスとOSSバケットが同じリージョンにある場合、内部ネットワークを介して相互に通信できます。 内部ネットワークを使用してバックアップデータをアップロードできます。 この方法は高速で、インターネットトラフィックの料金は発生しません。 ターゲットRDSインスタンスと同じリージョンにあるOSSバケットにバックアップファイルをアップロードすることを推奨します。

   自己管理型SQL Serverインスタンスの完全バックアップが完了したら、次のいずれかの方法を使用して、生成された完全バックアップファイルをOSSバケットにアップロードする必要があります。

   方法1: ossbrowserツールを使用する (推奨)

   1. ossbrowserのダウンロード。 詳細については、「ossbrowserへのインストールとログイン」をご参照ください。

   2. ダウンロードしたoss-browser-win32-x64.zipのパッケージを64ビットWindowsオペレーティングシステムで解凍します。 次に、oss-browser.exeをダブルクリックしてプログラムを実行します。 例として、64ビットWindowsオペレーティングシステムを使用します。

   3. [AKログイン] タブで、[AccessKeyId] および [AccessKeySecret] パラメーターを設定し、他のパラメーターのデフォルト値を保持し、[ログイン] をクリックします。

      説明

      AccessKeyペアは、Alibaba CloudアカウントのIDを確認し、データセキュリティを確保するために使用されます。 AccessKeyペアの機密を保持することを推奨します。 AccessKeyペアを作成および取得する方法の詳細については、「AccessKeyペアの作成」をご参照ください。

   4. OSSバケットの名前をクリックします。

   5. アイコンをクリックしてアップロードするバックアップファイルを選択し、[開く] をクリックしてバックアップファイルをOSSバケットにアップロードします。

   方法 2: OSS コンソールを使用する

   説明

   バックアップファイルのサイズが5 GB未満の場合は、OSSコンソールでバックアップファイルをアップロードすることを推奨します。

   1. OSS コンソールにログインします。

   2. 左側のナビゲーションウィンドウで、[バケット] をクリックします。 [バケット] ページで、バケットポリシーを設定するバケットの名前をクリックします。

   3. [オブジェクト] ページで、[オブジェクトのアップロード] をクリックします。

   4. バックアップファイルを [アップロードするファイル] セクションにドラッグするか、[ファイルの選択] をクリックしてアップロードするバックアップファイルを選択します。

   5. ページの下部で、[オブジェクトのアップロード] をクリックして、バックアップファイルをOSSバケットにアップロードします。

   方法3: OSS APIを呼び出す

   説明

   バックアップファイルのサイズが5 GBを超える場合は、OSS APIを呼び出して、マルチパートアップロードを使用してバックアップファイルをOSSバケットにアップロードすることを推奨します。

   この例では、Javaプロジェクトを使用して、環境変数からアクセス資格情報を取得する方法を説明します。 サンプルコードを実行する前に、環境変数が設定されていることを確認してください。 アクセス資格情報の設定方法の詳細については、「アクセス資格情報の設定」をご参照ください。 サンプルコードの詳細については、「マルチパートアップロード」をご参照ください。

   com.aliyun.oss.ClientExceptionをインポートします。com.aliyun.oss.OSSをインポートします。impor t com.aliyun.oss.com mon.auth.*;
   com.aliyun.oss.OSSClientBuilderをインポートします。com.aliyun.oss.OSSExceptionをインポートします。com.aliyun.oss.int ernal.Mimetypesをインポートします。com.aliyun.oss.mo delをインポートします。*;
   java.io. ファイルをインポートします。java.io.FileInputStreamをインポートします。java.io.InputStreamをインポートします。java.util.ArrayListをインポートします。java.util.Listをインポートします。public classデモ {
   
       public static void main(String[] args) throws Exception {
           // この例では、中国 (杭州) リージョンのエンドポイントが使用されます。 実際のエンドポイントを指定します。 
           String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
           // 環境変数からアクセス資格情報を取得します。 サンプルコードを実行する前に、OSS_ACCESS_KEY_IDおよびOSS_ACCESS_KEY_SECRET環境変数が設定されていることを確認してください。 
           EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
           // バケットの名前を指定します。 例: examplebucket. 
           String bucketName = "examplebucket";
           // オブジェクトのフルパスを指定します。 例: exampledir/exampleobject.txt。 バケット名をフルパスに含めないでください。 
           文字列objectName = "exampledir/exampleobject.txt";
           // アップロードするローカルファイルのパスを指定します。 
           String filePath = "D :\\ localpath\\examplefile.txt";
   
           // Create an OSSClient instance. 
           OSS ossClient = new OSSClientBuilder().build(endpoint, credentialsProvider);
           try {
               // InitiateMultipartUploadRequestオブジェクトを作成します。 
               InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
   
               // 次のコードは、マルチパートアップロードタスクを開始するときにリクエストヘッダーを指定する方法の例を示しています。 
                ObjectMetadata metadata = new ObjectMetadata();
               // metadata.setHeader(OSSHeaders.OSS_STORAGE_CLASS, StorageClass.Standard.toString());
               // オブジェクトのwebページのキャッシュ動作を指定します。 
               // metadata.setCacheControl("no-cache");
               // オブジェクトのダウンロード時にオブジェクトの名前を指定します。 
               // metadata.setContentDisposition("attachment;filename=oss_MultipartUpload.txt");
               // オブジェクトのコンテンツのエンコード形式を指定します。 
               // metadata.setContentEncoding(OSSConstants.DEFAULT_CHARSET_NAME);
               // マルチパートアップロードタスクの開始時に、既存のオブジェクトが同じ名前のオブジェクトで上書きされるかどうかを指定します。 この例では、このパラメーターはtrueに設定されています。これは、アップロードするオブジェクトと同じ名前の既存のオブジェクトが上書きされないことを示します。 
               // metadata.setHeader("x-oss-forbid-overwrite", "true");
               // アップロードするオブジェクトの各部分の暗号化に使用するサーバー側の暗号化方法を指定します。 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_ENCRYPTION, ObjectMetadata.KMS_SERVER_SIDE_ENCRYPTION);
               // オブジェクトの暗号化に使用されるアルゴリズムを指定します。 このパラメーターを設定しない場合、オブジェクトはAES-256を使用して暗号化されます。 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_DATA_ENCRYPTION, ObjectMetadata.KMS_SERVER_SIDE_ENCRYPTION);
               // key Management Service (KMS) が管理するカスタマーマスターキー (CMK) のIDを指定します。 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_ENCRYPTION_KEY_ID、"9468da86-3509-4f8d-a61e-6eab1eac ****");
               // オブジェクトのストレージクラスを指定します。 
               // metadata.setHeader(OSSHeaders.OSS_STORAGE_CLASS、StorageClass.Standard);
               // オブジェクトのタグを指定します。 オブジェクトに対して一度に複数のタグを指定できます。 
               // metadata.setHeader(OSSHeaders.OSS_TAGGING, "a:1");
               // request.setObjectMetadata (メタデータ);
   
               // オブジェクトタイプに基づいてContentTypeを指定します。 このパラメーターを指定しない場合、ContentTypeフィールドのデフォルト値はapplication/oct-srreamです。 
               if (metadata.getContentType() == null) {
                   metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
               }
   
               // マルチパートアップロードタスクを開始します。 
               InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
               // アップロードIDを取得します。 
               String uploadId = upresult.getUploadId();
               // マルチパートアップロードタスクをキャンセルするか、アップロードIDに基づいてアップロードされたパーツをリストします。 
               // アップロードIDに基づいてマルチパートアップロードタスクをキャンセルする場合は、InitiateMultipartUpload操作を呼び出してマルチパートアップロードタスクを開始した後にアップロードIDを取得します。  
               // アップロードIDに基づいてマルチパートアップロードタスクでアップロードされたパーツを一覧表示する場合は、InitiateMultipartUpload操作を呼び出してマルチパートアップロードタスクを開始した後、CompleteMultipartUpload操作を呼び出してマルチパートアップロードタスクを完了する前に、アップロードIDを取得します。 
               // System.out.println(uploadId);
   
               // partETags is a set of PartETags. PartETagは、アップロードされたパーツのパーツ番号とETagで構成されます。 
               List<PartETag> partETags =  new ArrayList<PartETag>();
               // 各パーツのサイズを指定します。 部品サイズは、オブジェクトの部品数を計算するために使用されます。 単位：バイト 
               final long partSize = 1*1024 * 1024L; // パーツサイズを1 MBに設定します。 
   
               // アップロードされたデータのサイズに基づいて部品数を計算します。 次のコードでは、ローカルファイルを例として使用して、file. length() メソッドを使用してアップロードされたデータのサイズを取得する方法を示します。 
               final File sampleFile=新しいファイル (filePath);
               long fileLength = sampleFile.length();
               int partCount = (int) (fileLength / partSize);
               if (fileLength % partSize != 0) {
                   partCount++;
               }
               // すべての部品をアップロードします。 
               for (int i = 0; i <recordCount; i ++ ) {
                   long startPos = i * partSize;
                   long curPartSize = (i + 1 == partCount) ? (fileLength - startPos) : partSize;
                   UploadPartRequest uploadPartRequest = new UploadPartRequest();
                   uploadPartRequest.setBucketName(bucketName);
                   uploadPartRequest.setKey(objectName);
                   uploadPartRequest.setUploadId(uploadId);
                   // マルチパートアップロードタスクの入力ストリームを指定します。 
                   // 次のコードでは、ローカルファイルを例として使用して、FIleInputstreamを作成し、InputStream.skip() メソッドを使用して指定されたデータをスキップする方法を示します。 
                   InputStream instream = new FileInputStream(sampleFile);
                   instream.skip(startPos);
                   uploadPartRequest.setInputStream(instream);
                   // パーツサイズを指定します。 最後の部分を除く各部分のサイズは100 KB以上でなければなりません。 
                   uploadPartRequest.setPartSize(curPartSize);
                   // 部品番号を設定します。 各部品は、1〜10,000の範囲の部品番号を有する。 指定した数値が範囲内にない場合、OSSはInvalidArgumentエラーコードを返します。 
                   uploadPartRequest.setPartNumber( i + 1);
                   // 部品は順番にアップロードされません。 パーツは、さまざまなOSSクライアントからアップロードできます。 OSSは、部品番号に基づいて部品をソートし、部品を結合して完全なオブジェクトを取得します。 
                   UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                   // 部品がアップロードされると、PartETagを含む結果が返されます。 The PartETag is stored in partETags. 
                   partETags.add(uploadPartResult.getPartETag());
               }
   
   
               // CompleteMultipartUploadRequestオブジェクトを作成します。 
               // CompleteMultipartUpload操作を呼び出すときは、すべての有効なPartETagsを指定する必要があります。 OSSがpartETagsを受信すると、OSSはすべてのパーツを1つずつ検証します。 すべての部品が検証された後、OSSはこれらの部品を完全なオブジェクトに結合します。 
               CompleteMultipartUploadRequest completeMultipartUploadRequest =
                       new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
   
               // マルチパートアップロードタスクが完了したときにオブジェクトのアクセス制御リスト (ACL) を設定する方法の例を次のコードに示します。 
               // completeMultipartUploadRequest.setObjectACL(CannedAccessControlList.Private);
               // 現在のアップロードIDを使用してアップロードされたすべてのパーツを一覧表示するかどうかを指定します。 OSS SDK For Java 3.14.0以降の場合、CompleteMultipartUploadRequestのpartETagsをnullに設定できるのは、OSSサーバーにアップロードされたすべてのパーツをリストして、パーツを完全なオブジェクトに結合する場合のみです。 
               // Map<String, String> headers = new HashMap<String, String>();
               // リクエストでx-oss-complete-allをyesに設定した場合、現在のアップロードIDを使用してアップロードされたすべてのパーツが一覧表示され、パーツ番号でパーツが並べ替えられ、CompleteMultipartUpload操作が実行されます。 
               // リクエストでx-oss-complete-allをyesに設定した場合、リクエスト本文は指定できません。 リクエスト本文を指定すると、エラーが報告されます。 
               // headers.put("x-oss-complete-all","yes");
               // completeMultipartUploadRequest.setHeaders(headers);
   
               // マルチパートアップロードタスクを完了します。 
               CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
               System.out.println(completeMultipartUploadResult.getETag());
           } catch (Exception e) {
               System.out.println("Caught an OSSException, which means your request made it to OSS, "
                       + "しかし、何らかの理由でエラー応答で拒否されました。");
               System.out.println("エラーメッセージ:" + oe.getErrorMessage());
               System.out.println("エラーコード:" + oe.getErrorCode());
               System.out.println("リクエストID:" + oe.getRequestId());
               System.out.println("ホストID:" + oe.getHostId());
           } catch (ClientException e) {
               System.out.println("Caught an ClientException, which means the client encountered "
                       + "a serious internal problem while trying to communicate with OSS, "
                       + 「ネットワークにアクセスできないなど」;
               System.out.println("エラーメッセージ:" + ce.getMessage());
           } 最後に{
               if (ossClient != null) {
                   ossClient.shutdown();
               }
           }
       }
   }

ステップ3: クラウド移行タスクを作成する

1. [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。

2. 左側のナビゲーションウィンドウで、[バックアップと復元] をクリックします。

3. ページの右上隅にある [OSSバックアップデータのRDSへの移行] をクリックします。

4. インポートガイドウィザードで、[次へ] を2回クリックしてデータをインポートします。

   説明

   OSSベースの移行ウィザードを初めて使用する場合は、ApsaraDB RDSのサービスアカウントにOSSバケットへのアクセスを許可する必要があります。 この場合、[承認] をクリックして承認を完了する必要があります。 それ以外の場合、[データのインポート] ステップの [OSSバケット] ドロップダウンリストは空です。

5. 次のパラメーターを設定し、[OK] をクリックします。

   移行タスクが完了するまで待ちます。 [更新] をクリックすると、移行タスクの最新のステータスが表示されます。

   パラメーター	説明
   データベース名	RDSインスタンスのターゲットデータベースの名前を入力します。 ターゲットデータベースは、ソースデータベースから移行されたデータを自己管理型SQL Serverインスタンスに格納するために使用されます。 ターゲットデータベースの名前は、オープンソースのSQL Serverの要件を満たす必要があります。 重要 移行する前に、移行先RDSインスタンスのデータベースの名前が、指定したバックアップファイルを使用して復元するデータベースの名前と異なることを確認する必要があります。 さらに、指定されたバックアップファイルを使用して復元するデータベースと同じ名前のデータベースファイルが、ターゲットRDSインスタンスのデータベースに追加されないようにします。 上記の両方の要件が満たされている場合は、バックアップセット内のデータベースファイルを使用してデータベースを復元できます。 データベースファイルは、復元するデータベースと同じ名前である必要があります。 上記の要件のいずれかが満たされない場合、移行は失敗します。
   OSSバケット	バックアップファイルを保存するOSSバケットを選択します。
   OSSサブフォルダ名	バックアップファイルを保存するOSSバケットの名前を入力します。
   OSSファイル	インポートするバックアップファイルを指定します。 検索ボックスにプレフィックスを入力し、検索アイコンをクリックして、あいまい一致を使用してバックアップファイルを検索できます。 名前にプレフィックスが含まれている各バックアップファイルの名前、サイズ、および更新時間が表示されます。 RDSインスタンスに移行するバックアップファイルを選択します。
   Cloud Migrationメソッド	[アクセス保留 (増分バックアップ)] を選択します。 有効な値： 即時アクセス (完全バックアップ): 完全バックアップファイルのみを移行する場合は、この移行方法を選択します。 この場合、CreateMigrateTask操作では、BackupMode = FULLおよびIsOnlineDB = Trueのパラメーター設定が有効になります。 アクセス保留 (増分バックアップ): 完全バックアップファイルとログまたは差分バックアップファイルを移行する場合は、この移行方法を選択します。 この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。BackupMode = UPDFおよびIsOnlineDB = False。

ステップ4: ログまたは差分バックアップファイルをインポートする

自己管理型SQL Serverインスタンスのソースデータベースの完全バックアップファイルをRDSインスタンスのターゲットデータベースにインポートした後、ログまたは差分バックアップファイルをインポートする必要があります。

1. [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。

2. 左側のナビゲーションウィンドウで、[バックアップと復元] をクリックします。 表示されるページで、[バックアップデータのクラウド移行レコード] タブをクリックします。

3. ターゲットデータベースを検索し、[タスク操作] 列の [増分ファイルのアップロード] をクリックします。 ログまたは差分バックアップファイルを選択し、[OK] をクリックします。

   説明

   • 複数のログまたは差分バックアップファイルがある場合は、同じ方法でログバックアップファイルを1つずつアップロードする必要があります。

   • 最后のログまたは差分バックアップファイルのサイズが500 MBを超えないようにしてください。 これにより、移行を完了するのに必要な時間が最小限に抑えられます。

   • 最後のログまたは差分バックアップファイルが生成される前に、ソースデータベースへのデータ書き込みを停止する必要があります。 これにより、RDSインスタンスのソースデータベースとターゲットデータベース間のデータの整合性が確保されます。

ステップ5: データベースを開く

すべてのバックアップファイルをRDSインスタンスのターゲットデータベースにインポートすると、ターゲットデータベースは [回復中] または [復元中] の状態になります。 RDSインスタンスがRDS High-availability Editionを実行している場合、ターゲットデータベースは [回復中] 状態です。 RDSインスタンスがRDS Basic Editionを実行している場合、ターゲットデータベースは復元状態になります。 このような場合、ターゲットデータベースで読み取りまたは書き込み操作を実行できません。 読み取りおよび書き込み操作を実行する前に、ターゲットデータベースを開く必要があります。

1. [インスタンス] ページに移動します。 上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。 次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。

2. 左側のナビゲーションウィンドウで、[バックアップと復元] をクリックします。 表示されるページで、[バックアップデータのクラウド移行レコード] タブをクリックします。

3. ターゲットデータベースを検索し、[タスク操作] 列の [データベースを開く] をクリックします。

4. 整合性チェックモードを選択し、[OK] をクリックします。

   説明

   ApsaraDB RDSには、次の整合性チェックモードがあります。

   • 非同期DBCC: DBCC CHECKDBステートメントは、ターゲットデータベースが開かれた後に実行されます。 これにより、ターゲットデータベースを開くのに必要な時間が短縮され、アプリケーションのダウンタイムが最小限に抑えられます。 ターゲットデータベースが大きい場合、DBCC CHECKDBステートメントの実行に時間がかかります。 アプリケーションがダウンタイムの影響を受けやすいが、DBCC CHECKDBステートメントの結果の影響を受けない場合は、この整合性チェックモードを選択することを推奨します。 この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。CheckDBMode = AsyncExecuteDBCheck。

   • 同期DBCC: DBCC CHECKDBステートメントは、ターゲットデータベースが開かれると同時に実行されます。 DBCC CHECKDBステートメントの結果に基づいて、自己管理データベースとターゲットデータベース間の整合性エラーを特定する場合は、この整合性チェックモードを選択することを推奨します。 ただし、ターゲットデータベースを開くのに必要な時間が長くなります。 この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。CheckDBMode = SyncExecuteDBCheck。

ステップ6: インポートしたバックアップファイルの詳細を表示する

移行タスクを使用してインポートされたバックアップファイルの詳細を表示する場合は、次の操作を実行します。[バックアップと復元] ページに移動します。 [バックアップデータのクラウド移行レコード] タブをクリックします。 必要な移行タスクを見つけて、[タスク操作] 列の [ファイルの詳細の表示] をクリックします。 次に、インポートしたバックアップファイルの詳細を表示します。

(共通エラーコード 29～31 など)

フルバックアップデータの移行中に発生する可能性のある一般的なエラーの詳細については、「一般的なエラー」をご参照ください。

増分バックアップデータの移行中に、次のエラーが発生する可能性があります。

• ターゲットデータベースを開くことができません。

  • エラーメッセージ: データベースxxxを開けませんでした。

  • 原因: 自己管理型SQL Serverインスタンスでは、一部の高度な機能が有効になっています。 ただし、これらの高度な機能はRDSインスタンスではサポートされていません。 たとえば、自己管理型SQL ServerインスタンスはSQL ServerのEnterprise Editionを実行し、RDSインスタンスはSQL ServerのWeb editionを実行します。 自己管理型SQL Serverインスタンスのデータ圧縮機能とパーティション機能が有効になっている場合、RDSインスタンスでターゲットデータベースを開いたときにこのエラーが報告されます。

  • 解決策：

    • 自己管理型SQL Serverインスタンスの高度な機能を無効にし、データを再度バックアップしてから、OSSを使用してデータを移行します。

    • 自己管理型SQL Serverインスタンスと同じSQL Serverエディションを実行するRDSインスタンスを購入します。 次に、自己管理型SQL Serverインスタンスのソースデータベースのデータを新しいRDSインスタンスに移行します。

• バックアップチェーン内のログシーケンス番号 (LSN) は連続していません。

  • エラーメッセージ: このバックアップセットのログはLSN XXXから始まります。これはデータベースに適用するには遅すぎます。

  • 原因: ログまたは差分バックアップファイルのLSNが、復元に使用された以前のバックアップファイルのLSNとは異なります。

  • 解決策: 復元に使用された以前のバックアップファイルのLSNと同じLSNを持つログまたは差分バックアップファイルを選択します。

• DBCC CHECKDBステートメントは、非同期モードでは実行できません。

  • エラーメッセージ: 非同期DBCC checkdb failed: CHECKDBは、テーブル 'XXX' (オブジェクトID XXX) に0個の割り当てエラーと2個の整合性エラーを検出しました。

  • 原因: 非同期DBCC整合性チェックモードを選択してデータをRDSインスタンスに復元すると、ApsaraDB RDSはDBCC CHECKDBステートメントを実行します。 ターゲットデータベースが整合性チェックに失敗した場合、ソースデータベースで整合性エラーが発生します。

  • 解決策：

    • ターゲットデータベースで次のステートメントを実行します。

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

      説明

      このステートメントを使用してエラーを修正すると、データが失われる可能性があります。

    • ソースデータベースで次のステートメントを実行してエラーを修正し、データを再度移行します。

      DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)

• 選択したバックアップファイルは完全バックアップファイルです。

  • エラーメッセージ: バックアップセット (xxx) はデータベースFULLバックアップです。トランザクションログまたは差分バックアップのみを受け付けます。

  • 原因: 完全バックアップファイルを使用してデータをRDSインスタンスに復元した後、ログまたは差分バックアップファイルのみを選択できます。 フルバックアップファイルを再度選択すると、このエラーが報告されます。

  • 解決策: ログまたは差分バックアップファイルを選択します。

• 指定されたソースデータベースの数が上限を超えています。

  • エラーメッセージ: データベース数の制限により、データベース (xxx) の移行に失敗しました。

  • 原因: 指定されたソースデータベースの数が上限を超えた場合、このエラーが報告されます。

  • 解決策: ソースデータベースのデータを別のRDSインスタンスに移行します。 それ以外の場合は、不要なデータベースを削除します。

• RAMユーザーに必要な権限がありません。

  移行タスクの作成の手順5で説明されているパラメーターは正しく設定されていますが、[OK] ボタンは暗くなります。 これはなぜですか。

  その理由は、RAMユーザーを使用していて、そのRAMユーザーに必要な権限がないためです。 このトピックの「前提条件」セクションに基づいて、必要な権限が付与されていることを確認してください。

関連する API 操作