OSSバケット内の自己管理データベースのバックアップファイルを使用して、完全バックアップデータをApsaraDB RDS for SQL Serverインスタンスに復元します。 - ApsaraDB RDS

ApsaraDB RDS for SQL Serverインスタンスを使用すると、データをクラウドに簡単に移行できます。自己管理型SQL Serverインスタンスのソースデータベースの完全バックアップデータをObject Storage Service (OSS) バケットにアップロードし、ApsaraDB RDSコンソールを使用して、完全バックアップデータをApsaraDB RDS for SQL Serverインスタンスのターゲットデータベースに移行するだけで済みます。この機能は、データのバックアップ、移行、ディザスタリカバリなどのシナリオで使用できます。

説明

このトピックで説明する操作は、RDSインスタンスがクラウドディスクを使用してSQL Server 2008 R2を実行している場合、またはSQL Server 2012以降を実行している場合にのみ実行できます。
自己管理型SQL Serverインスタンスの完全バックアップデータを、ローカルディスクでSQL Server 2008 R2を実行するRDSインスタンスに移行する方法の詳細については、「自己管理型SQL Serverインスタンスの完全バックアップデータを、ローカルディスクでSQL Server 2008 R2を実行するApsaraDB RDSインスタンスに移行」をご参照ください。

前提条件

RDSインスタンスは、クラウドディスクを使用してSQL Server 2008 R2を実行するか、SQL Server 2012以降を実行します。 RDSインスタンス上のデータベースの名前は、自己管理型SQL Serverインスタンスから移行するデータベースの名前とは異なります。 RDSインスタンスの作成方法の詳細については、「ApsaraDB RDS For SQL Serverインスタンスの作成」をご参照ください。
説明
クラウドディスクでSQL Server 2008 R2を実行するApsaraDB RDSインスタンスは、購入できなくなりました。詳細については、「 [EOS /廃止] クラウドディスクを備えたSQL Server 2008 R2を実行しているApsaraDB RDSインスタンスは、2023年7月14日から購入できなくなりました」をご参照ください。
RDSインスタンスの使用可能なストレージは十分です。使用可能なストレージが不十分な場合は、移行を開始する前にRDSインスタンスのストレージ容量を拡張する必要があります。詳細については、「ApsaraDB RDS For SQL Serverインスタンスの仕様の変更」をご参照ください。
RDSインスタンス用に特権アカウントが作成されます。詳細については、「アカウントとデータベースの作成」をご参照ください。
DBCC CHECKDBステートメントを実行して、自己管理型SQL Serverインスタンスで割り当てエラーまたは整合性エラーが発生しないようにします。割り当てエラーまたは整合性エラーが発生しなかった場合、次の実行結果が返されます。
```
...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
DBCC execution completed. DBCCがエラーメッセージを印刷した場合は、システム管理者に連絡してください。
```
OSSが有効化されています。詳細については、「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"
        }
    ]
}
```

使用上の注意

このトピックで説明する移行方法は、データベースレベルです。一度に単一の自己管理データベースのフルバックアップデータのみをRDSインスタンスに移行できます。自己管理型SQL Serverインスタンス内の複数またはすべてのデータベースのバックアップデータを一度に移行する場合は、インスタンスレベルの移行方法を使用することをお勧めします。詳細については、「セルフマネージドSQL ServerインスタンスからApsaraDB RDS For SQL Serverインスタンスへのデータの移行」をご参照ください。
RDSインスタンスよりも新しいバージョンのデータベースエンジンを実行する自己管理型SQL Serverインスタンスのバックアップファイルを移行することはできません。たとえば、SQL Server 2016を実行する自己管理型インスタンスのバックアップファイルを、SQL Server 2012を実行するRDSインスタンスに移行することはできません。
差分バックアップファイルとログバックアップファイルはサポートされていません。
データ移行の失敗を避けるために、完全バックアップファイルの名前に次の特殊文字が含まれていないことを確認してください:! @ # $ % ^ & * ( ) _ + - =
ApsaraDB RDSのサービスアカウントにOSSバケットへのアクセスを許可すると、AliyunRDSImportRoleという名前のロールがRAMに作成されます。このロールを変更または削除しないでください。このロールを変更または削除した場合、バックアップファイルはOSSバケットからダウンロードできません。この場合、移行ウィザードを使用してサービスアカウントを再承認する必要があります。
RDSインスタンスは、自己管理型SQL Serverインスタンスのアカウントを引き継ぎません。移行が完了したら、ApsaraDB RDSコンソールでRDSインスタンスのアカウントを作成する必要があります。
移行が完了する前に、OSSバケットから完全バックアップファイルを削除しないでください。移行が完了する前に完全バックアップファイルを削除すると、移行は失敗します。
バックアップファイルの名前の末尾には、bak、diff、trn、またはlogを付ける必要があります。次のリストでは、サフィックスについて説明します。
- "bak": フルバックアップファイルを示します。
- "diff": 差分バックアップファイルを示します。
- trnまたはlog: トランザクションのログバックアップファイルを示します。
説明
- バックアップファイルが上記のサフィックスを使用しない場合、システムはバックアップファイルのタイプを識別できない可能性があります。これは後続の操作に影響します。
- デフォルトでは、RDSインスタンスの完全バックアップファイルはZIP形式です。 ZIPファイルをダウンロードする場合は、ZIPファイルを解凍して、名前の末尾にbakが付いている完全なバックアップファイルを取得する必要があります。次に、フルバックアップファイルを使用して、データをRDSインスタンスに移行できます。

課金

このトピックで説明されている方法を使用してデータを移行する場合、OSSバケットの使用に対してのみ課金されます。

シナリオ	課金ルール
OSSバケットへのバックアップファイルのアップロード	無料です。
OSSバケットにバックアップファイルを保存する	ストレージ料金が請求されます。詳細については、料金をご覧ください。 OSSのページにアクセスします。
OSSバケットからRDSインスタンスへのバックアップファイルの移行	内部ネットワークを介してOSSバケットからRDSインスタンスにバックアップファイルを移行する場合、料金は発生しません。インターネット経由でバックアップファイルを移行する場合、アウトバウンドインターネットトラフィックに基づいてOSSバケットに対して課金されます。詳細については、料金をご覧ください。 OSSのページにアクセスします。

ステップ1: 自己管理型インスタンスのソースデータベースのバックアップ

説明

完全バックアップを実行する前に、自己管理インスタンスのソースデータベースへのすべてのデータ書き込みを停止する必要があります。完全バックアッププロセス中に自己管理データベースに書き込まれたデータはバックアップできません。

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

ビジネス要件に基づいてパラメーターを変更します。次の表に、バックアップスクリプトのパラメーターを示します。

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

説明

バックアップスクリプトの [PUBLIC VARIABLES HEREを入力する] セクションのSELECTステートメントの上記パラメーターを変更します。

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

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

重要

OSSバケットが作成されている場合は、バケットが次の要件を満たしているかどうかを確認します。

OSSバケットのストレージクラスはStandardです。ストレージクラスは、標準、低頻度アクセス (IA) 、アーカイブ、コールドアーカイブ、またはディープコールドアーカイブにすることはできません。詳細については、「概要」をご参照ください。
OSSバケットのデータ暗号化は有効になっていません。詳細については、「データ暗号化」をご参照ください。

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

OSSコンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。 [バケット] ページで、[バケットの作成] をクリックします。

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

重要

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

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

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

説明

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

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

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

ossbrowserのダウンロード。詳細については、「ossbrowserへのインストールとログイン」をご参照ください。
ダウンロードしたoss-browser-win32-x64.zipのパッケージを64ビットWindowsオペレーティングシステムで解凍します。次に、oss-browser.exeをダブルクリックしてプログラムを実行します。例として、64ビットWindowsオペレーティングシステムを使用します。
[AKログイン] タブで、[AccessKeyId] および [AccessKeySecret] パラメーターを設定し、他のパラメーターのデフォルト値を保持し、[ログイン] をクリックします。
説明
AccessKeyペアは、Alibaba CloudアカウントのIDを確認し、データセキュリティを確保するために使用されます。 AccessKeyペアの機密を保持することを推奨します。 AccessKeyペアを作成および取得する方法の詳細については、「AccessKeyペアの作成」をご参照ください。
OSSバケットの名前をクリックします。
アイコンをクリックしてアップロードするバックアップファイルを選択し、[開く] をクリックしてバックアップファイルをOSSバケットにアップロードします。

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

説明

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

OSS コンソールにログインします。
左側のナビゲーションウィンドウで、[バケット] をクリックします。 [バケット] ページで、バケットポリシーを設定するバケットの名前をクリックします。
[オブジェクト] ページで、[オブジェクトのアップロード] をクリックします。
バックアップファイルを [アップロードするファイル] セクションにドラッグするか、[ファイルの選択] をクリックしてアップロードするバックアップファイルを選択します。
ページの下部で、[オブジェクトのアップロード] をクリックして、バックアップファイルを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: 移行タスクの作成

[インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDSインスタンスを見つけ、インスタンスのIDをクリックします。
左側のナビゲーションウィンドウで、[バックアップと復元] をクリックします。
ページの右上隅にある [OSSバックアップデータのRDSへの移行] をクリックします。
インポートガイドウィザードで、[次へ] を2回クリックします。
説明
OSSベースの移行ウィザードを初めて使用する場合は、ApsaraDB RDSのサービスアカウントにOSSバケットへのアクセスを許可する必要があります。この場合、[承認] をクリックして承認を完了する必要があります。それ以外の場合、[データのインポート] ステップの [OSSバケット] ドロップダウンリストは空です。

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

パラメーター	説明
データベース名	RDSインスタンスのターゲットデータベースの名前を入力します。ターゲットデータベースは、ソースデータベースから移行されたデータを自己管理型SQL Serverインスタンスに格納するために使用されます。ターゲットデータベースの名前は、オープンソースのSQL Serverの要件を満たす必要があります。重要移行する前に、移行先RDSインスタンスのデータベースの名前が、指定したバックアップファイルを使用して復元するデータベースの名前と異なることを確認する必要があります。さらに、指定されたバックアップファイルを使用して復元するデータベースと同じ名前のデータベースファイルが、ターゲットRDSインスタンスのデータベースに追加されないようにします。上記の両方の要件が満たされている場合は、バックアップセット内のデータベースファイルを使用してデータベースを復元できます。データベースファイルは、復元するデータベースと同じ名前である必要があります。上記の要件のいずれかが満たされない場合、移行は失敗します。
OSSバケット	フルバックアップファイルを格納するOSSバケット。
OSSサブフォルダ名	フルバックアップファイルを格納するOSSサブフォルダーの名前。
OSSファイル	インポートするフルバックアップファイル。検索ボックスにプレフィックスを入力し、アイコンをクリックすると、ファジーマッチモードで完全バックアップファイルを検索できます。名前にプレフィックスが含まれている各完全バックアップファイルの名前、サイズ、および更新時間が表示されます。クラウドに移行するバックアップファイルを選択します。
Cloud Migrationメソッド	即時アクセス (完全バックアップ): 完全バックアップファイルのみを移行する場合は、この移行計画を選択します。この例では、[即時アクセス (フルバックアップ)] を選択します。この場合、CreateMigrateTask操作では、`BackupMode = FULL`および`IsOnlineDB = True`のパラメーター設定が有効になります。アクセス保留 (増分バックアップ): 完全バックアップファイルとログまたは差分バックアップファイルを移行する場合は、この移行方法を選択します。この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。`BackupMode = UPDF`および`IsOnlineDB = False`。
整合性チェックモード	非同期DBCC: DBCC CHECKDBステートメントは、ターゲットデータベースが開かれた後に実行されます。これにより、ターゲットデータベースを開くのに必要な時間が短縮され、アプリケーションのダウンタイムが最小限に抑えられます。ターゲットデータベースが大きい場合、DBCC CHECKDBステートメントの実行に時間がかかります。アプリケーションがダウンタイムの影響を受けやすいが、DBCC CHECKDBステートメントの結果の影響を受けない場合は、この整合性チェックモードを選択することを推奨します。この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。`CheckDBMode = AsyncExecuteDBCheck`。同期DBCC: DBCC CHECKDBステートメントは、ターゲットデータベースが開かれると同時に実行されます。 DBCC CHECKDBステートメントの結果に基づいて、ソースデータベースとターゲットデータベース間の整合性エラーを特定する場合は、この整合性チェックモードを選択することを推奨します。ただし、ターゲットデータベースを開くのに必要な時間が長くなります。この場合、CreateMigrateTask操作で次のパラメーター設定が有効になります。`CheckDBMode = SyncExecuteDBCheck`。

[OK] をクリックします。
移行タスクが完了するまで待ちます。 [更新] をクリックすると、移行タスクの最新の状態が表示されます。移行タスクが失敗した場合は、移行タスクの説明に基づいて障害をトラブルシューティングできます。詳細については、「一般的なエラー」をご参照ください。

ステップ4: 移行タスクを表示する

移行タスクの詳細を表示する場合は、[バックアップと復元] ページに移動し、[バックアップデータのクラウド移行レコード] タブをクリックします。デフォルトでは、このタブには先週の移行タスクが表示されます。

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

[バックアップと復元] ページの [バックアップデータのアップロード履歴] タブの各移行タスクレコードには、タスクの説明が含まれています。移行タスクが失敗した場合、またはエラーが報告された場合は、タスクの説明に基づいて障害またはエラーをトラブルシューティングできます。以下の一般的なエラーが発生する可能性があります。

RDSインスタンス上の既存のデータベースの名前は、ソースデータベースと同じです。
- エラーメッセージ: データベース (xxx) はすでに RDS に存在します。バックアップしてドロップしてから、もう一度実行します。
- 原因: RDSインスタンス上の既存のデータベースの名前がソースデータベースと同じ場合、移行はサポートされていません。このメカニズムは、データのセキュリティを確保するために設計されています。
- 解決策: RDSインスタンスの既存のデータベースを上書きする場合は、データベースをバックアップし、RDSインスタンスからデータベースを削除してから、移行タスクを再度作成して実行します。
差分バックアップファイルが使用されます。
- エラーメッセージ: バックアップセット (xxx.bak) はデータベースの差分バックアップです。フルバックアップのみ使用できます。
- 原因: アップロードするファイルは、完全バックアップファイルではなく、差分バックアップファイルです。このトピックの移行方法では、フルバックアップファイルのみがサポートされます。
ログバックアップファイルが使用されます。
- エラーメッセージ: バックアップセット (xxx.trn) はトランザクションログバックアップです。フルバックアップのみ使用できます。
- 原因: アップロードするファイルは、完全バックアップファイルではなくログバックアップファイルです。このトピックの移行方法では、フルバックアップファイルのみがサポートされます。
完全なバックアップファイルが検証に失敗します。
- エラーメッセージ: "xxx.bak" の確認に失敗しました。バックアップファイルが破損していたか、RDS より新しいバージョンです。
- 原因: 完全バックアップファイルが破損しているか、自己管理型インスタンスがRDSインスタンスよりも新しいバージョンのSQL Serverを実行しています。たとえば、このエラーは、自己管理インスタンスがSQL Server 2016を実行し、RDSインスタンスがSQL Server 2012を実行している場合に発生します。
- 解決策: 完全バックアップファイルが破損している場合は、自己管理型SQL Serverインスタンスで完全バックアップを再度実行します。次に、移行タスクを再度作成して実行します。自己管理インスタンスがRDSインスタンスよりも後のバージョンのSQL Serverを実行する場合は、自己管理インスタンスと同じバージョンまたは後のバージョンを実行する別のRDSインスタンスを選択します。
DBCC CHECKDBステートメントが失敗します。
- エラーメッセージ: DBCC checkdbに失敗しました。
- 原因: 自己管理型SQL Serverインスタンスの割り当てエラーまたは整合性エラーが発生しました。
- 解決策: 自己管理型SQL Serverインスタンスで次のステートメントを実行して、エラーを修正します。次に、移行タスクを再度作成して実行します。
  説明
  次のステートメントを実行すると、データが失われる可能性があります。
```
DBCC CHECKDB (DBName, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS
```
- RDSインスタンスの使用可能なストレージが不足しています。
  - エラーメッセージ: 復元に十分なディスクスペースがありません。スペースが残っています (xxx MB) < needed (xxx MB) 。
  - 原因: RDSインスタンスの使用可能なストレージが、フルバックアップファイルを使用してデータを復元するために必要な最小ストレージ未満です。
  - 解決方法: RDSインスタンスのストレージ容量を拡張します。
- RDSインスタンスの使用可能なストレージが不足しています。
  - エラーメッセージ: Not Enough Disk Space, space left xxx MB < bak file xxx MB.
  - 原因: RDSインスタンスの使用可能なストレージが、フルバックアップファイルのサイズよりも小さいこと。
  - 解決方法: RDSインスタンスのストレージ容量を拡張します。
RDSインスタンスに特権アカウントは作成されません。
- エラーメッセージ： Your RDS doesn't have any init account yet, please create one and grant permissions on RDS console to this migrated database (XXX).
- 原因: RDSインスタンスに特権アカウントが作成されていません。その結果、移行タスクは承認が必要なアカウントを見つけることができません。ただし、完全バックアップファイルはRDSインスタンスに復元されており、移行タスクは成功しています。
- 解決策: RDSインスタンスに特権アカウントを作成します。詳細については、「SQL Server 2012、2014、2016、2017 SE、または2019 SEを実行するApsaraDB RDSインスタンスのアカウントとデータベースの作成」をご参照ください。
RAMユーザーに必要な権限がありません。
[移行タスクの作成] で説明されているパラメーターは正しく設定されていますが、[OK] ボタンは暗くなります。これはなぜですか。
考えられる原因は、RAMユーザーを使用しており、RAMユーザーに必要な権限がないことです。このトピックの「前提条件」セクションに基づいて、必要な権限が付与されていることを確認してください。

API 操作	説明
CreateMigrateTask	データ移行タスクを作成します。
CreateOnlineDatabaseTask	バックアップデータの移行先のデータベースをApsaraDB RDS for SQL Serverインスタンスで開きます。
DescribeMigrateTasks	ApsaraDB RDS for SQL Serverインスタンスのバックアップデータを移行するために作成されたタスクを照会します。
DescribeOssDownloads	ApsaraDB RDS for SQL Serverインスタンスのバックアップデータ移行タスクのバックアップファイルの詳細を照会します。

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