すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:クラウドへの増分バックアップデータの移行 (クラウドディスク上の SQL Server 2008 R2 および SQL Server 2012 以降)

最終更新日:Jun 23, 2026

ApsaraDB RDS for SQL Server は、クラウドへの増分データ移行を可能にします。まず、完全バックアップファイルを Alibaba Cloud Object Storage Service (OSS) にアップロードし、次に ApsaraDB RDS コンソールを使用して指定された ApsaraDB RDS for SQL Server インスタンスにデータを復元します。最後に、差分バックアップファイルまたはログバックアップファイルをインスタンスにインポートして移行を完了します。このプロセスにより、ダウンタイムを数分に短縮できます。

ユースケース

RDS SQL Server への増分データ移行は、次のユースケースで使用します:

  • 論理移行ではなく、バックアップファイルを使用して RDS SQL Server への物理移行を実行したい場合。

    説明
    • 物理移行はファイルベースですが、論理移行はデータから DML ステートメントを生成し、移行先の RDS SQL Server インスタンスで実行します。

    • 物理移行では、移行先データベースがソースデータベースと 100% 同一であることが保証されます。一方、論理移行ではこの一貫性を保証できません。たとえば、インデックスの断片化や統計情報などの属性が移行後に異なる場合があります。

  • ダウンタイムを数分に抑える必要がある場合。

    説明

    より長いダウンタイム (たとえば 2 時間の停止) が許容でき、データベースが 100 GB 未満の場合は、完全バックアップファイルを使用してデータベースを移行してください。

前提条件

  • ご利用の RDS for SQL Server インスタンスは、次の要件を満たす必要があります:

    • インスタンスは SQL Server 2012 以降を実行しているか、クラウドディスクを使用する SQL Server 2008 R2 インスタンスである必要があります。

    • インスタンスに、移行しようとしているデータベースと同じ名前のデータベースが含まれていないこと。

    • インスタンスの利用可能なストレージ容量は、移行するデータファイルのサイズよりも大きい必要があります。ストレージ容量が不足している場合は、インスタンスストレージをスペックアップしてください。

  • オンプレミスの SQL Server データベースの復元モードは、FULL である必要があります。

    説明
    • 増分データ移行にはトランザクションログバックアップが必要です。Simple 復元モデルはトランザクションログバックアップをサポートしていません。

    • 差分バックアップファイルが大きいと、増分データ移行が長引く可能性があります。

  • RAM ユーザーとしてログインする場合、次の要件を満たす必要があります:

    • RAM ユーザーには、AliyunOSSFullAccess および AliyunRDSFullAccess 権限が必要です。詳細については、「RAM を使用した OSS へのアクセスコントロール」および「RAM を使用した RDS へのアクセスコントロール」をご参照ください。

    • ご利用の Alibaba Cloud アカウントが、RDS の公式サービスアカウントに OSS リソースへのアクセスを許可していることを確認してください。

      権限付与の方法

      1. RDS for SQL Server インスタンスの 復元 ページに移動し、OSS バックアップデータをクラウド上で復元する をクリックします。

      2. インポートガイド で、次へ を 2 回クリックして、ステップ 3. データのインポート に進みます。

        ページの左下隅に RDS 公式サービスアカウントに OSS へのアクセスを許可しました というメッセージが表示された場合、権限は付与されています。そうでない場合は、ページ上の 権限付与アドレス をクリックして権限を付与します。

        image

    • Alibaba Cloud アカウントで手動でアクセスポリシーを作成し、それを RAM ユーザーにアタッチする必要があります。

      ポリシーの内容

      {
          "Version": "1",
          "Statement": [
              {
                  "Action": [
                      "ram:GetRole"
                  ],
                  "Resource": "acs:ram:*:*:role/AliyunRDSImportRole",
                  "Effect": "Allow"
              }
          ]
      }

事前準備

自己管理データベースで DBCC CHECKDB コマンドを実行し、allocation errorsconsistency errors を確認します。期待される出力は次のとおりです。

...
CHECKDB found 0 allocation errors and 0 consistency errors in database 'xxx'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

注意事項

  • 移行レベル:このソリューションは単一のデータベースのみを移行します。複数のデータベースまたはすべてのデータベースを移行するには、「SQL Server インスタンスレベルのクラウド移行」をご参照ください。

  • バージョンの互換性:自己管理 SQL Server インスタンスからのバックアップを、それより古い SQL Server バージョンを実行している ApsaraDB RDS for SQL Server インスタンスに復元することはできません。

  • 権限管理:ApsaraDB RDS サービスアカウントに OSS へのアクセスを許可すると、Resource Access Management (RAM) に `AliyunRDSImportRole` という名前のロールが作成されます。このロールを変更または削除しないでください。変更または削除すると、クラウド移行タスクが失敗します。誤ってこのロールを変更または削除した場合は、移行ウィザードを使用して権限を再付与する必要があります。

  • アカウント管理:移行完了後、既存のデータベースアカウントは使用できません。ApsaraDB RDS コンソールで新しいアカウントを作成する必要があります。

  • OSS ファイルの保持:クラウド移行タスクが完了する前に OSS からバックアップファイルを削除しないでください。削除すると、タスクは失敗します。

  • バックアップファイルの要件

    • ファイル名の制限:バックアップファイル名に特殊文字 (例:`!@#$%^&*()_+-=`) を含めることはできません。含めると、クラウド移行は失敗します。

    • ファイル拡張子:ApsaraDB RDS は、次の拡張子を持つバックアップファイルをサポートしています:`.bak` (完全バックアップ)、`.diff` (差分バックアップ)、および `.trn` または `.log` (ログバックアップ)。ApsaraDB RDS は他のファイルタイプを認識しません。

      説明
      • 実際には、ファイルの拡張子が必ずしもそのバックアップタイプを示すわけではありません。たとえば、`.bak` ファイルには、完全バックアップ、差分バックアップ、またはトランザクションログバックアップが含まれている場合があります。

      • ApsaraDB RDS コンソールからダウンロードした SQL Server ログバックアップファイルは、デフォルトで `.zip.log` 形式になります。これは、ステップ 1 の公式スクリプトで生成される `.bak` バックアップファイルとは異なります。ファイル形式を変換した後、増分クラウド移行にそのファイルを使用できます。

        処理方法: ファイル拡張子を `.zip` に変更し、ファイルを解凍します。次に、解凍された `database_name.lbak` ファイルの名前を `.bak` 拡張子に変更します。最後に、この `.bak` ファイルを増分ログバックアップとして OSS にアップロードし、クラウド移行に使用します。

ワークフロー例

移行フェーズ

ステップ

説明

完全データ移行フェーズ

ステップ 1. 00:00 以前

事前準備を完了します:

  • DBCC CHECKDB 整合性チェックを実行します。

  • ローカルバックアップシステムを無効にします。

  • データベースを FULL 復元モデルに変更します。

ステップ 2. 00:01

ソースデータベースの完全バックアップを実行します。所要時間:約 1 時間。

ステップ 3. 02:00

バックアップファイルを OSS バケットにアップロードします。所要時間:約 1 時間。

ステップ 4. 03:00

ApsaraDB RDS コンソールで、完全バックアップファイルを復元します。所要時間:約 19 時間。

増分移行フェーズ

ステップ 5. 22:00

ソースデータベースの増分ログバックアップを実行し、OSS にアップロードします。所要時間:約 20 分。

ステップ 6. 22:20

ログバックアップファイルを復元します。所要時間:約 10 分。

ステップ 7. 22:30

  • ステップ 5 とステップ 6 を繰り返し、トランザクションログを繰り返しバックアップし、OSS にアップロードし、ApsaraDB RDS インスタンスに復元します。最終的なログバックアップファイルが可能な限り小さくなるようにします (例:500 MB 未満)。

  • ソースデータベースへのアプリケーションの書き込みを停止します。その後、最終ログバックアップを実行して移行を完了します。

切り替え

ステップ 8. 22:34

最終ログバックアップは約 4 分で復元されます。その後、データベースをオンラインにできます。

ステップ 9. 22:35

データベースはオンラインです。DBCC チェックを非同期で実行することを選択した場合、この最終ステップには約 1 分かかります。

このワークフローは、必要なアプリケーションのダウンタイムが非常に短いことを示しています。最終ログバックアップの直前にアプリケーションの書き込みを停止するだけで済みます。この例では、合計ダウンタイムは 5 分未満です。

ステップ 1: ローカルデータベースのバックアップ

  1. バックアップスクリプトをダウンロードし、SSMS で開きます。

  2. 次のパラメーターを変更します。

    パラメーター

    説明

    @backup_databases_list

    バックアップするデータベースのリストをセミコロンまたはカンマで区切って指定します。

    @backup_type

    実行するバックアップのタイプ。有効な値:

    • FULL: 完全バックアップ

    • DIFF: 差分バックアップ

    • LOG: ログバックアップ

    @backup_folder

    バックアップファイルのローカルディレクトリ。このディレクトリが存在しない場合、スクリプトは自動的に作成します。

    @is_run

    バックアップを実行するかどうかを決定します。有効な値:

    • 1: バックアップを実行します。

    • 0: チェックのみを実行し、バックアップは実行しません。

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

    スクリプトは、選択したバックアップタイプに関係なく、デフォルトで `.bak` ファイルを生成します。

ステップ 2: バックアップファイルの OSS へのアップロード

  1. バックアップファイルを OSS にアップロードするには、まずバケットを作成する必要があります。

    • すでに OSS にバケットがある場合は、次の要件を満たしていることを確認してください:

      • バケットのストレージクラス標準ストレージ です。ストレージクラスは、低頻度アクセス (IA)、アーカイブ、コールドアーカイブ、またはディープコールドアーカイブにすることはできません。

      • バケットでデータ暗号化が有効になっていません。

    • OSS にバケットがない場合は、作成します。 (OSS を有効化していることを確認してください。)

      1. OSS コンソールにログインし、バケット をクリックし、次に Create bucket をクリックします。

      2. 次の主要なパラメーターを設定します。他のパラメーターはデフォルト値のままにします。

        重要
        • バケットはこのデータ移行にのみ使用され主要なパラメーターのみを設定する必要があります。移行が完了したら、データ漏えいを防ぎ、関連する料金を回避するために、バケットを速やかに削除してください。

        • バケットを作成する際にデータ暗号化を有効にしないでください。

        パラメーター

        説明

        バケット名

        バケットの名前。名前はグローバルに一意である必要があり、バケット作成後は変更できません。

        命名規則:

        • 小文字、数字、ハイフン (-) のみを含めることができます。

        • 小文字または数字で開始および終了する必要があります。

        • 長さは 3~63 文字である必要があります。

        migratetest

        地理

        バケットが存在するリージョン。ECS インスタンスからのアップロードと RDS インスタンスへの復元に内部ネットワークを使用するには、ECS インスタンス、バケット、および RDS インスタンスが同じリージョンにある必要があります。

        中国 (杭州)

        ストレージタイプ

        標準ストレージ を選択します。このトピックで説明されている移行方法は、他のストレージクラスのバケットをサポートしていません。

        標準

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

    ローカルデータベースをバックアップした後、バックアップファイルを RDS インスタンスと同じリージョンにある OSS バケットにアップロードします。これにより、内部ネットワーク経由での通信が可能になり、インターネットトラフィック料金を回避し、アップロード速度を向上させることができます。次のいずれかの方法を使用できます:

    ossbrowser ツールを使用する (推奨)

    1. ossbrowser をダウンロードします。

    2. たとえば、Windows x64 システムでは、ダウンロードした `oss-browser-win32-x64.zip` パッケージを解凍し、`oss-browser.exe` アプリケーションをダブルクリックします。

    3. アクセスキー ログイン方法を使用し、Access Key IDAccess Key Secret を入力し、他のパラメーターはデフォルト値のままにして、ログイン をクリックします。

      説明

      AccessKey は、データセキュリティを確保するための本人確認に使用されます。AccessKey ペアは安全に保管してください。

    4. ログイン後、バケットリストでターゲットバケット (例:migratetest) をクリックして、そのファイル管理ページを開きます。

    5. 上传图标 をクリックし、アップロードするバックアップファイルを選択して、[開く] をクリックします。

    OSS コンソールを使用してファイルをアップロードする

    説明

    5 GB 未満のファイルには OSS コンソールを使用することを推奨します。

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

    2. 左側のナビゲーションウィンドウで、バケット をクリックします。ターゲットバケットを見つけて、その名前 (例:migratetest) をクリックして詳細ページを開きます。

    3. ファイルリスト タブで、Upload File をクリックします。

    4. [オブジェクトのアップロード] パネルで、バックアップファイルを アップロードするファイル エリアにドラッグするか、ファイルの選択 をクリックします。オブジェクト ACL 設定はデフォルトの [バケットから継承] のままにします。この方法での最大ファイルサイズは 5 GB です。5 GB を超えるファイルをアップロードするには、ossutil などのツールを使用してマルチパートアップロードを実行します。

    5. ページ下部の Upload File をクリックします。

    OSS API を使用してマルチパートアップロードを行う

    説明

    5 GB を超えるファイルにはマルチパートアップロード API を使用することを推奨します。

    次の Java の例は、環境変数からアクセス認証情報を取得する方法を示しています。このコードを実行する前に、環境変数が設定されていることを確認してください。その他の例については、「マルチパートアップロード」をご参照ください。

    import com.aliyun.oss.*;
    import com.aliyun.oss.common.auth.*;
    import com.aliyun.oss.common.comm.SignVersion;
    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 {
            // 例として中国 (杭州) リージョンのエンドポイントを使用します。実際のエンドポイントを指定してください。
            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)。フルパスにバケット名を含めることはできません。
            String objectName = "exampledir/exampleobject.txt";
            // アップロードするローカルファイルのパス。
            String filePath = "D:\\localpath\\examplefile.txt";
            // バケットが配置されているリージョンを指定します。たとえば、バケットが中国 (杭州) リージョンにある場合、リージョンを cn-hangzhou に設定します。
            String region = "cn-hangzhou";
    
            // OSSClient インスタンスを作成します。
            // OSSClient インスタンスが不要になったら、shutdown メソッドを呼び出してリソースを解放します。
            ClientBuilderConfiguration clientBuilderConfiguration = new ClientBuilderConfiguration();
            clientBuilderConfiguration.setSignatureVersion(SignVersion.V4);
            OSS ossClient = OSSClientBuilder.create()
                    .endpoint(endpoint)
                    .credentialsProvider(credentialsProvider)
                    .clientConfiguration(clientBuilderConfiguration)
                    .region(region)
                    .build();
    
            try {
                // InitiateMultipartUploadRequest オブジェクトを作成します。
                InitiateMultipartUploadRequest request = new InitiateMultipartUploadRequest(bucketName, objectName);
    
                // ObjectMetadata オブジェクトを作成し、Content-Type を設定します。
                ObjectMetadata metadata = new ObjectMetadata();
                if (metadata.getContentType() == null) {
                    metadata.setContentType(Mimetypes.getInstance().getMimetype(new File(filePath), objectName));
                }
                System.out.println("Content-Type: " + metadata.getContentType());
    
                // メタデータをアップロードリクエストにバインドします。
                request.setObjectMetadata(metadata);
    
                // マルチパートアップロードを初期化します。
                InitiateMultipartUploadResult upresult = ossClient.initiateMultipartUpload(request);
                // アップロード ID を返します。
                String uploadId = upresult.getUploadId();
    
                // partETags は PartETag オブジェクトのコレクションです。PartETag オブジェクトは、パートの ETag とパート番号で構成されます。
                List<PartETag> partETags = new ArrayList<PartETag>();
                // 各パートのサイズ。これはパート数を計算するために使用されます。単位:バイト。
                // 最小パートサイズは 100 KB、最大パートサイズは 5 GB です。最後のパートのサイズは 100 KB 未満でもかまいません。
                // パートサイズを 1 MB に設定します。
                final long partSize = 1 * 1024 * 1024L;   
    
                // アップロードするデータのサイズに基づいてパート数を計算します。以下のコードは、File.length() を使用してローカルファイルからアップロードするデータのサイズを取得する方法の例です。
                final File sampleFile = new File(filePath);
                long fileLength = sampleFile.length();
                int partCount = (int) (fileLength / partSize);
                if (fileLength % partSize != 0) {
                    partCount++;
                }
                // パートを走査してアップロードします。
                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);
                    // アップロードするパートのストリームを設定します。
                    // 以下のコードは、ローカルファイルから FileInputStream オブジェクトを作成し、InputStream.skip() メソッドを使用して指定されたデータをスキップする方法の例です。
                    InputStream instream = new FileInputStream(sampleFile);
                    instream.skip(startPos);
                    uploadPartRequest.setInputStream(instream);
                    // パートサイズを設定します。
                    uploadPartRequest.setPartSize(curPartSize);
                    // パート番号を設定します。各アップロードされたパートには、1 から 10,000 の範囲のパート番号があります。パート番号がこの範囲にない場合、OSS は InvalidArgument エラーコードを返します。
                    uploadPartRequest.setPartNumber(i + 1);
                    // パートは順番にアップロードする必要はありません。異なるクライアントからアップロードすることもできます。OSS はパート番号でパートをソートして完全なオブジェクトを作成します。
                    UploadPartResult uploadPartResult = ossClient.uploadPart(uploadPartRequest);
                    // 各パートがアップロードされた後、OSS の応答には PartETag が含まれます。PartETag は partETags に保存されます。
                    partETags.add(uploadPartResult.getPartETag());
    
                    // ストリームを閉じます。
                    instream.close();
                }
    
                // CompleteMultipartUploadRequest オブジェクトを作成します。
                // マルチパートアップロードを完了するときは、すべての有効な partETags を提供する必要があります。OSS が送信された partETags を受信した後、各パートの有効性を検証します。すべてのパートが検証された後、OSS はこれらのパートを結合して完全なオブジェクトにします。
                CompleteMultipartUploadRequest completeMultipartUploadRequest =
                        new CompleteMultipartUploadRequest(bucketName, objectName, uploadId, partETags);
    
                // マルチパートアップロードを完了します。
                CompleteMultipartUploadResult completeMultipartUploadResult = ossClient.completeMultipartUpload(completeMultipartUploadRequest);
                System.out.println("Upload successful, ETag: " + 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 a 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 バックアップデータをクラウド上で復元する をクリックします。

  4. インポートガイド ページで、次へ を 2 回クリックして、[データのインポート] ステップに進みます。

    説明

    OSS バックアップデータを RDS に移行する機能を初めて使用する場合は、RDS アカウントに OSS へのアクセスを許可する必要があります。権限付与 をクリックして必要な権限を付与してください。そうしないと、OSS バケット ドロップダウンリストは空になります。

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

    クラウド移行タスクが完了するのを待ちます。更新 をクリックして、タスクの最新のステータスを表示します。タスクが失敗した場合は、タスクの説明にあるエラーメッセージに基づいて問題をトラブルシューティングします。詳細については、「よくあるエラー」をご参照ください。

    パラメーター

    説明

    データベース名

    RDS インスタンス上のターゲットデータベースの名前。名前は SQL Server の命名規則に準拠する必要があります。

    重要
    • 移行を開始する前に、ターゲットインスタンスにバックアップファイル内のデータベースと同じ名前の既存のデータベースまたはアタッチされていないデータベースファイルがないことを確認してください。

    • バックアップファイルで指定されたデータベースと同じ名前のデータベースがターゲットインスタンスにすでに存在する場合、または同じ名前のアタッチされていないデータベースファイルが存在する場合、クラウド移行は失敗します。

    OSS バケット

    バックアップファイルが保存されている OSS バケットを選択します。

    OSS ファイル

    虫眼鏡アイコンをクリックして、プレフィックスによるバックアップファイルのあいまい検索を実行します。結果には、ファイル名、ファイルサイズ、最終更新日時が表示されます。移行するバックアップファイルを選択します。

    クラウド移行計画

    [データベースを開かない] を選択します。

    • 即時アクセス (完全バックアップ):移行する単一の完全バックアップファイルがある場合、クラウドへの完全データ移行にこの方法を使用します。このオプションでは、`CreateMigrateTask` 操作は次のパラメーターを使用します:`BackupMode = FULL` および `IsOnlineDB = True`

    • アクセス保留 (増分バックアップ):完全バックアップファイルの後に差分バックアップまたはログファイルを移行する場合、クラウドへの増分データ移行にこの方法を使用します。このオプションでは、`CreateMigrateTask` 操作は次のパラメーターを使用します:`BackupMode = UPDF` および `IsOnlineDB = False`。

ステップ 4: 差分バックアップまたはログバックアップのインポート

自己管理 SQL Server データベースの完全バックアップを移行した後、差分バックアップまたはログバックアップファイルをインポートします。

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

  2. 左側のナビゲーションウィンドウで 復元 をクリックし、次に バックアップデータのアップロード履歴 タブをクリックします。

  3. タスクリストで対応するタスクを見つけ、[操作] 列の 増分ファイルのアップロード をクリックします。増分ファイルを選択し、OK をクリックします。

    説明
    • 複数のログバックアップファイルがある場合は、それぞれに個別の移行タスクを作成します。

    • 最終バックアップファイルが 500 MB を超えないようにしてください。これにより、増分クラウド移行に必要な時間が最小限に抑えられます。

    • 最終ログバックアップファイルを生成する前に、自己管理データベースへのすべての書き込み操作を停止してください。これにより、自己管理データベースと RDS for SQL Server インスタンス間のデータ整合性が確保されます。

ステップ 5: データベースのオープン

バックアップファイルをインポートした後、ApsaraDB RDS for SQL Server インスタンス上のデータベースは `In Recovery` または `Restoring` 状態になります。高可用性版インスタンスの場合、状態は `In Recovery` で、ベーシック版インスタンスの場合、状態は `Restoring` です。どちらの状態でも、データベースは読み取りおよび書き込み操作には使用できません。データベースを利用可能にするには、データベースを開く必要があります。

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

  2. 左側のナビゲーションウィンドウで、復元 を選択し、次に クラウド上へのデータバックアップの記録 タブをクリックします。

  3. タスクリストで、バックアップファイルインポートのレコードを見つけ、[操作] 列の データベースを開く をクリックします。

  4. データベース整合性チェックオプションを選択し、決定 をクリックします。

    説明

    データベース整合性チェックには、次のオプションがあります:

    • 非同期 DBCC:このオプションは、データベースが開いた後に `DBCC CHECKDB` 操作を非同期で実行します。この方法は、データベースをより速くオンラインにすることでダウンタイムを最小限に抑えます。データベースが大きく、`DBCC CHECKDB` 操作に時間がかかる場合に最適です。サービスのダウンタイムに敏感で、チェックの即時結果が必要ない場合にこのオプションを使用します。CreateMigrateTask API 呼び出しでは、このオプションは `CheckDBMode` パラメーターを `AsyncExecuteDBCheck` に設定します。

    • 同期 DBCC:このオプションは、データベースが開くときに `DBCC CHECKDB` 操作を実行します。この方法により、データ整合性を即座に検証し、エラーを特定できます。データ検証を優先する場合にこのオプションを使用しますが、データベースを開くのにかかる時間が増加することに注意してください。CreateMigrateTask API 呼び出しでは、このオプションは `CheckDBMode` パラメーターを `SyncExecuteDBCheck` に設定します。

ステップ 6: クラウド移行バックアップ詳細の表示

クラウド移行タスクのバックアップファイルの詳細を表示するには、RDS インスタンスの左側のナビゲーションウィンドウにある 復元 ページに移動します。クラウド上へのデータバックアップの記録 タブで、タスクを見つけ、右端の列にある ファイルの詳細を表示します をクリックします。

説明

クラウド移行後、システムは RDS インスタンスの自動バックアップポリシーに基づいて自動的にバックアップを作成します。このバックアップは指定されたバックアップ時間に実行され、調整可能です。結果のバックアップセットには移行されたデータが含まれ、復元 ページで利用できます。

次のスケジュール時刻より前にバックアップが必要な場合は、手動バックアップを実行できます。

よくあるエラー

完全バックアップデータ移行中の一般的なエラーについては、「完全バックアップデータ移行における一般的なエラー」をご参照ください。

増分アップロード中に次のエラーが発生することがあります:

  • データベースを開けませんでした

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

    • 原因:ソース SQL Server データベースが、選択した ApsaraDB RDS for SQL Server インスタンスエディションでサポートされていない高度な機能を使用しています。たとえば、ソース SQL Server インスタンスが Enterprise Edition でデータ圧縮またはパーティショニングが有効になっており、データを Web Edition を実行する ApsaraDB RDS for SQL Server インスタンスに移行する場合にこのエラーが発生します。

    • 解決策:

  • バックアップチェーンの LSN の不一致

    • エラーメッセージ:このバックアップセットのログは LSN XXX から始まりますが、これはデータベースに適用するには新しすぎます。RESTORE LOG は異常終了しています。

    • 原因:SQL Server では、差分バックアップまたはログバックアップは、その開始ログシーケンス番号 (LSN) が以前に復元されたバックアップファイルの LSN と一致する場合にのみ復元できます。LSN が一致しない場合にこのエラーが発生します。

    • 解決策:増分アップロード用に LSN が一致するバックアップファイルを選択してください。バックアップファイルは時系列順にアップロードするようにしてください。

  • 非同期 DBCC CHECKDB の失敗

    • エラーメッセージ: 非同期 DBCC checkdb 失敗: CHECKDB はテーブル 'XXX' (オブジェクト ID XXX) で 0 個のアロケーションエラーと 2 個の整合性エラーを検出しました。

    • 原因:バックアップファイルが ApsaraDB RDS for SQL Server インスタンスに復元された後、システムは非同期 DBCC CHECKDB を実行します。このチェックが失敗した場合、ソースデータベースにすでに整合性エラーが含まれていたことを示します。

    • 解決策:

      • 移行先の ApsaraDB RDS for SQL Server インスタンスで、次のコマンドを実行します:

        DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)
        重要

        この修復コマンドはデータ損失を引き起こす可能性があります。

      • ソースインスタンスで次のコマンドを実行してエラーを修復し、増分アップロードを再試行します。

        DBCC CHECKDB (DBName,REPAIR_ALLOW_DATA_LOSS)
  • 増分アップロード用のバックアップファイルタイプが正しくない

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

    • 原因:ApsaraDB RDS for SQL Server インスタンスへの増分アップロード中、システムは完全バックアップが復元された後、ログバックアップファイルまたは差分バックアップファイルのみを受け付けます。再度完全バックアップファイルを選択した場合にこのエラーが発生します。

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

  • データベース数が制限を超えています

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

    • 原因:データベースを最大データベース数に達したインスタンスに移行しようとすると、このエラーが発生します。

    • 解決策:データベースを別の ApsaraDB RDS for SQL Server インスタンスに移行するか、現在のインスタンスから不要なデータベースを削除してください。

  • RAM ユーザーの権限が不十分

    • Q1: 「データ移行タスクの作成」のステップ 5 で、すべてのパラメーターが設定されているにもかかわらず、決定 ボタンがグレーアウトしてクリックできないのはなぜですか?

    • A1: これは、RAM ユーザーに必要な権限がない場合に発生する可能性があります。このトピックの前提条件セクションを参照し、必要な権限を付与してください。

    • Q2: RAM ユーザーが `AliyunRDSImportRole` を付与しようとしたときに発生する `no permission` エラーを解決するにはどうすればよいですか?

    • A2: Alibaba Cloud アカウントを使用して、RAM ユーザーに一時的に `AliyunRAMFullAccess` 権限を付与してください。RAM ユーザーに権限を付与する手順については、「RAM を使用して ApsaraDB RDS の権限を管理する」をご参照ください。

  • 増分バックアップが誤った完全バックアップに復元された

    • エラーメッセージ:この差分バックアップは、データベースが正しい状態にないため復元できません。RESTORE DATABASE は異常終了しています。

    • 原因:新しい増分バックアップが古い完全バックアップに復元された場合にこのエラーが発生します。これにより、差分バックアップファイルの LSN が `NORECOVERY` オプションで復元された完全バックアップファイルの LSN と一致しないため、バックアップチェーンが壊れます。

    • 解決策:正しいバックアップファイルを選択し、正しい順序でアップロードしていることを確認してください。ソースインスタンスの `msdb.dbo.backupset` テーブルをクエリして、完全バックアップファイルと差分バックアップファイルの順序と LSN の関係を確認できます。

  • 複数ファイルのストライプバックアップに関するエラー

    • エラーメッセージ:(xxx.bak) の検証に失敗しました。エラーメッセージ:メディアセットには xxx 個のメディアファミリーがありますが、1 つしか提供されていません。すべてのメンバーを提供する必要があります。VERIFY DATABASE は異常終了しています。

    • 原因:ソースデータベースはストライプバックアップ機能を使用してバックアップされており、1 つの完全バックアップが複数の .bak ファイルに書き込まれています。しかし、移行タスクにはこれらのファイルのうち 1 つしか提供されていません。ApsaraDB RDS for SQL Server は、単一のタスクで複数のバックアップファイルからのデータ移行をサポートしていません。

    • 解決策:ソースデータベースを単一の .bak ファイルにバックアップし、再度アップロードを試みてください。

API リファレンス

API

説明

CreateMigrateTask

OSS からのバックアップファイルを ApsaraDB RDS for SQL Server インスタンスに復元することで、データ移行タスクを作成します。

CreateOnlineDatabaseTask

データ移行タスクの一部として復元されたデータベースをオンラインにします。

DescribeMigrateTasks

ApsaraDB RDS for SQL Server インスタンスのデータ移行タスクを一覧表示します。

DescribeOssDownloads

データ移行タスクのバックアップファイルの詳細を返します。