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. If DBCC printed error messages, contact your system administrator.

• 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"
                ],
                "Resource": "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は、トランザクションの完全バックアップファイル、差分バックアップファイル、またはログバックアップファイルにすることができます。

  • バックアップファイルが上記のサフィックスを使用しない場合、システムはバックアップファイルのタイプを識別できない可能性があります。 これは後続の操作に影響します。

  • バックアップファイルが自己管理型SQL Serverインスタンスのログバックアップファイルであり、ApsaraDB RDSコンソールでダウンロードした場合、ダウンロードしたバックアップファイルのデフォルトの形式は. zip.logの代わりに. bak. ダウンロードしたバックアップファイルは、ファイル形式を変換した後、クラウド移行に使用できます。 . bakファイルは、ステップ1で生成されたバックアップスクリプトファイルを参照します。 詳細については、「データバックアップファイルとログバックアップファイルのダウンロード」をご参照ください。

    次の操作では、ファイル形式を変換する方法について説明します。. zip解凍の場合は、解凍済みの名前を変更します。database_name.lbakファイルをサフィックス付きのファイルに. bakをアップロードし、. bakクラウド移行用の増分ログバックアップファイルとしてOSSバケットにファイルを追加します。

移行プロセス

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

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

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

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

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

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

   実行後、. bakファイルは、指定したバックアップの種類に関係なく自動的に生成されます。

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

   import com.aliyun.oss.ClientException;
   import com.aliyun.oss.OSS;
   import com.aliyun.oss.common.auth.*;
   import com.aliyun.oss.OSSClientBuilder;
   import com.aliyun.oss.OSSException;
   import com.aliyun.oss.internal.Mimetypes;
   import com.aliyun.oss.model.*;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.InputStream;
   import java.util.ArrayList;
   import java.util.List;
   
   public class Demo {
   
       public static void main(String[] args) throws Exception {
           // In this example, the endpoint of the China (Hangzhou) region is used. Specify your actual endpoint. 
           String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
           // Obtain access credentials from environment variables. Before you run the sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are configured. 
           EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
           // Specify the name of the bucket. Example: examplebucket. 
           String bucketName = "examplebucket";
           // Specify the full path of the object. Example: exampledir/exampleobject.txt. Do not include the bucket name in the full path of the object. 
           String objectName = "exampledir/exampleobject.txt";
           // Specify the full path of the local file that you want to upload. 
           String filePath = "D:\\localpath\\examplefile.txt";
           // Specify the region in which the bucket is located. For example, if the bucket is located in the China (Hangzhou) region, set the region to cn-hangzhou.
           String region = "cn-hangzhou";
   
           // Create an OSSClient instance. 
           ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
           clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);        
           OSS ossClient = OSSClientBuilder.create()
           .endpoint(endpoint)
           .credentialsProvider(credentialsProvider)
           .clientConfiguration(clientBuilderConfiguration)
           .region(region)               
           .build();
           
           try {
               // Create an InitiateMultipartUploadRequest object. 
               InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
   
               // The following sample code provides an example on how to specify the request headers when you initiate a multipart upload task: 
                ObjectMetadata metadata = new ObjectMetadata();
               // metadata.setHeader(OSSHeaders.OSS_STORAGE_CLASS, StorageClass.Standard.toString());
               // Specify the caching behavior of the web page for the object. 
               // metadata.setCacheControl("no-cache");
               // Specify the name of the downloaded object. 
               // metadata.setContentDisposition("attachment;filename=oss_MultipartUpload.txt");
               // Specify the content encoding format of the object. 
               // metadata.setContentEncoding(OSSConstants.DEFAULT_CHARSET_NAME);
               // Specify whether existing objects are overwritten by objects that have the same names when the multipart upload task is initiated. In this example, this parameter is set to true, which indicates that existing objects cannot be overwritten by objects with the same names. 
               // metadata.setHeader("x-oss-forbid-overwrite", "true");
               // Specify the server-side encryption method that you want to use to encrypt each part of the object that you want to upload. 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_ENCRYPTION, ObjectMetadata.KMS_SERVER_SIDE_ENCRYPTION);
               // Specify the algorithm that you want to use to encrypt the object. If you do not specify this parameter, the object is encrypted by using AES-256. 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_DATA_ENCRYPTION, ObjectMetadata.KMS_SERVER_SIDE_ENCRYPTION);
               // Specify the ID of the customer master key (CMK) that is managed by Key Management Service (KMS). 
               // metadata.setHeader(OSSHeaders.OSS_SERVER_SIDE_ENCRYPTION_KEY_ID, "9468da86-3509-4f8d-a61e-6eab1eac****");
               // Specify the storage class of the object. 
               // metadata.setHeader(OSSHeaders.OSS_STORAGE_CLASS, StorageClass.Standard);
               // Specify one or more tags for the object. 
               // metadata.setHeader(OSSHeaders.OSS_TAGGING, "a:1");
               // request.setObjectMetadata(metadata);
   
               // Specify ContentType based on the object type. If you do not specify this parameter, the default value of ContentType is used, which is application/oct-srream. 
               if (metadata.getContentType() == null) {
                   metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
               }
   
               // Initiate the multipart upload task. 
               InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
               // Obtain the upload ID. 
               String uploadId = upresult.getUploadId();
               // Cancel the multipart upload task or list uploaded parts based on the upload ID. 
               // If you want to cancel a multipart upload task based on the upload ID, obtain the upload ID after you call the InitiateMultipartUpload operation to initiate the multipart upload task.  
               // If you want to list the uploaded parts in a multipart upload task based on the upload ID, obtain the upload ID after you call the InitiateMultipartUpload operation to initiate the multipart upload task but before you call the CompleteMultipartUpload operation to complete the multipart upload task. 
               // System.out.println(uploadId);
   
               // partETags is a set of PartETags. A PartETag consists of the part number and ETag of an uploaded part. 
               List<PartETag> partETags =  new ArrayList<PartETag>();
               // Specify the size of each part, which is used to calculate the number of parts of the object. Unit: bytes. 
               final long partSize = 1 * 1024 * 1024L;   // Set the part size to 1 MB. 
   
               // Calculate the number of parts based on the size of the uploaded data. In the following sample code, a local file is used as an example to describe how to use the File.length() method to obtain the size of the uploaded data. 
               final File sampleFile = new File(filePath);
               long fileLength = sampleFile.length();
               int partCount = (int) (fileLength / partSize);
               if (fileLength % partSize != 0) {
                   partCount++;
               }
               // Upload all parts. 
               for (int i = 0; i < partCount; 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);
                   // Specify the input stream of the multipart upload task. 
                   // In the following sample code, a local file is used as an example to describe how to create a FIleInputstream and use the InputStream.skip() method to skip the specified data. 
                   InputStream instream = new FileInputStream(sampleFile);
                   instream.skip(startPos);
                   uploadPartRequest.setInputStream(instream);
                   // Specify the part size. The size of each part except for the last part must be greater than or equal to 100 KB. 
                   uploadPartRequest.setPartSize(curPartSize);
                   // Specify part numbers. Each part has a part number that ranges from 1 to 10,000. If the part number that you specify does not fall within the specified range, OSS returns the InvalidArgument error code. 
                   uploadPartRequest.setPartNumber( i + 1);
                   // Parts are not necessarily uploaded in order and can be uploaded from different OSS clients. OSS sorts the parts based on the part numbers and combines the parts into a complete object. 
                   UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                   // Each time a part is uploaded, OSS returns a result that contains the PartETag of the part. The PartETag is stored in partETags. 
                   partETags.add(uploadPartResult.getPartETag());
               }
   
   
               // Create a CompleteMultipartUploadRequest object. 
               // When you call the CompleteMultipartUpload operation, you must provide all valid PartETags. After OSS receives the PartETags, OSS verifies all parts one by one. After all parts are verified, OSS combines these parts into a complete object. 
               CompleteMultipartUploadRequest completeMultipartUploadRequest =
                       new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
   
               // The following sample code provides an example on how to configure the access control list (ACL) of the object when you initiate a multipart upload task: 
               // completeMultipartUploadRequest.setObjectACL(CannedAccessControlList.Private);
               // Specify whether to list all parts that are uploaded by using the current upload ID. For OSS SDK for Java 3.14.0 and later, you can set PartETags in CompleteMultipartUploadRequest to null only when you list all parts uploaded to the OSS server to combine the parts into a complete object. 
               // Map<String, String> headers = new HashMap<String, String>();
               // If you set x-oss-complete-all to yes in the request, OSS lists all parts that are uploaded by using the current upload ID, sorts the parts by part number, and then performs the CompleteMultipartUpload operation. 
               // If you set x-oss-complete-all to yes in the request, the request body cannot be specified. If you specify the request body, an error is reported. 
               // headers.put("x-oss-complete-all","yes");
               // completeMultipartUploadRequest.setHeaders(headers);
   
               // Complete the multipart upload task. 
               CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
               System.out.println(completeMultipartUploadResult.getETag());
           } catch (OSSException oe) {
               System.out.println("Caught an OSSException, which means your request made it to OSS, "
                       + "but was rejected with an error response for some reason.");
               System.out.println("Error Message:" + oe.getErrorMessage());
               System.out.println("Error Code:" + oe.getErrorCode());
               System.out.println("Request ID:" + oe.getRequestId());
               System.out.println("Host ID:" + oe.getHostId());
           } catch (ClientException ce) {
               System.out.println("Caught an ClientException, which means the client encountered "
                       + "a serious internal problem while trying to communicate with OSS, "
                       + "such as not being able to access the network.");
               System.out.println("Error Message:" + ce.getMessage());
           } finally {
               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インスタンスに移行します。 購入方法の詳細については、「ApsaraDB RDS For SQL Serverインスタンスの作成と使用」をご参照ください。

      説明

      SQL Serverエディションの詳細については、「異なるSQL ServerバージョンとRDSエディションを実行するApsaraDB 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ユーザーに必要な権限がありません。

  • エラー1

    • エラー: ステップ3: クラウド移行タスクの作成のサブステップ5に記載されているパラメーターは正しく設定されていますが、[OK] ボタンは暗くなっています。

    • 原因: 必要な権限を持たないRAMユーザーを使用しています。

    • 解決策: RAMユーザーに必要な権限を付与するには、このトピックの「前提条件」セクションを参照してください。

  • エラー2

    • エラー: RAMユーザーにAliyunRDSImportRole権限を付与する権限がないことを示すメッセージが表示されます。

    • 原因: 使用しているRAMユーザーに必要な権限がありません。

    • 解決策: Alibaba Cloudアカウントを使用して、RAMユーザーにAliyunRAMFullAccess権限を付与します。 詳細については、「RAMを使用したApsaraDB RDS権限の管理」をご参照ください。

関連する API 操作