Data Management:DBS の一般的なエラーとトラブルシューティング

エラー

バックアップスケジュール設定のエラー

ソースデータベース接続チェックの失敗

バックアップと復元の事前チェックエラー

• ソースデータベース接続チェックの失敗

• ソースデータベース権限チェックの失敗

• OSS 接続チェックの失敗

• ソースデータベースの binlog ステータスチェックの失敗

• ソースデータベースのバイナリログフォーマットチェックの失敗

• binlog_row_image パラメーターチェックの失敗

• ソースデータベースのサーバーIDチェックの失敗

• ソースデータベースの binlog ファイルチェックの失敗

• ストレージエンジンチェックの失敗

• MySQL パスワードフォーマットチェックの失敗

• オブジェクト名の競合

高度なダウンロードタスクのエラー

• DBS-DownloadTask.Region

• DBS-DownloadTask.InstanceInfo

• DBS-DownloadTask.DbType

• DBS-DownloadTask.CustinId

• DBS-DownloadTask.CustinName

• DBS-DownloadTask.user

• DBS-DownloadTask.Instance.Version

• DBS-DownloadTask.Instance.Storage.Type

• DBS-DownloadTask.Instance.Param

• DBS-DownloadTask

タスクの実行エラー

• DBS-000000

• DBS-000001

• DBS-000002

• DBS-000003

• DBS-000004

• DBS-000005

• DBS-000006

• DBS-000007

• DBS-002003

• DBS-002009

• DBS-102001

• DBS-105001

• DBS-106001

• DBS-202002

• DBS-203101

• DBS-203102

• DBS-203103

• DBS-203104

• DBS-203201

• DBS-203202

• DBS-203203

• DBS-203205

• DBS-203206

• DBS-203240

• DBS-203301

• DBS-203302

• DBS-301005

• DBS-301502

• DBS-301503

• DBS-301504

• DBS-301505

• DBS-302035

• DBS-400001

• DBS-999999 または エラーコードなし

バックアップスケジュールのエラー

ソースデータベース接続の失敗

シナリオ：バックアップスケジュールの設定中に、接続テストに失敗します。

バックアップと復元の事前チェックエラー

ソースデータベース接続の失敗

このエラーは、バックアップスケジュールまたは復元タスクの事前チェック中に発生します。

対処法：「バックアップスケジュールの設定」のよくあるエラーにあるソースデータベース接続テストの失敗をご参照ください。

データベース権限チェックの失敗

シナリオ：このエラーは、バックアップスケジュールまたは復元タスクの事前チェック中に発生します。

OSS チェックの失敗

シナリオ：バックアップスケジュールまたは復元タスクの事前チェックが失敗します。

ソースデータベースのバイナリログ事前チェックの失敗

シナリオ：ソースデータベースのバイナリログ事前チェックが失敗します。

解決策：この事前チェックでは、ソースデータベースでバイナリロギング機能が有効になっていることを確認します。事前チェックが失敗した場合、この機能が無効になっていることを意味します。この問題を解決するには、次の手順に従ってください。

1. セルフマネージド MySQL ソースデータベースをホストするサーバーにログインします。

2. MySQL の設定ファイル my.cnf で、次の設定を変更します。

   log_bin=mysql_bin
   binlog_format=row
   server_id=2 # 1 より大きい整数である必要があります。これは設定例です。
   binlog_row_image=full # このパラメーターは、ソースデータベースが MySQL 5.6 以降を実行している場合に必要です。

   説明

   my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスはインストール環境によって異なる場合があります。

3. 次のコマンドを実行して MySQL サービスを再起動します。

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   説明

   [$Mysql_Dir] を MySQL のインストールディレクトリに置き換えてください。

4. セルフマネージド MySQL ソースデータベースにログインし、次の SQL ステートメントを実行して、バイナリロギング機能が有効になっていることを確認します。

   SHOW variables LIKE '%log_bin%';

   次の出力は、この機能が有効であることを示しています。

   MariaDB [pro1]> show variables like '%log_bin%';
   +----------------------------------+-------+
   | Variable_name                    | Value |
   +----------------------------------+-------+
   | log_bin                          | ON    |
   | log_bin_trust_function_creators  | OFF   |
   | sql_log_bin                      | ON    |
   +----------------------------------+-------+
   3 rows in set (0.00 sec)

5. DBS の事前チェックを再実行します。

ソースバイナリログフォーマットチェックの失敗

現象：ソースデータベースのバイナリログフォーマットの事前チェックが失敗します。

対処法：このチェックは、ソースデータベースのバイナリログフォーマットが ROW に設定されていることを確認します。事前チェックが失敗した場合、フォーマットが ROW に設定されていません。この問題を解決するには、次の手順に従ってください。

1. セルフマネージド MySQL ソースデータベースが稼働しているサーバーにログインします。

2. MySQL 設定ファイル my.cnf を変更して、binlog_format パラメーターを ROW に設定します。

   log_bin=mysql_bin
   binlog_format=ROW  # バイナリログフォーマットを ROW に設定します。
   server_id=2 # これは 1 より大きい整数である必要があります。これは値の一例です。
   binlog_row_image=full # ソースデータベースが MySQL 5.6 以降を実行している場合、このパラメーターが必要です。

   説明

   my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスは、インストール環境によって異なる場合があります。

3. 次のコマンドを実行して、MySQL を再起動します。

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   説明

   [$Mysql_Dir] を MySQL インストールディレクトリに置き換えてください。

4. セルフマネージド MySQL ソースデータベースにログインし、次の SQL ステートメントを実行して、バイナリログフォーマットが ROW に設定されていることを確認します。

   SHOW variables LIKE "%binlog_format%";

   次の出力は、バイナリログフォーマットが ROW に設定されていることを示します。

   mysql> show variables like "%binlog_format%";
   +-----------------+-------+
   | Variable_name   | Value |
   +-----------------+-------+
   | binlog_format   | ROW   |
   +-----------------+-------+
   1 row in set (0.01 sec)

5. DBS 事前チェックを再度実行します。

binlog_row_image チェックの失敗

シナリオ：ソースデータベースの binlog_row_image パラメータの事前チェックが失敗します。

解決策：このチェックは MySQL 5.6 以降に適用されます。このチェックでは、binlog_row_image パラメータが full に設定されているかどうかを確認します。失敗した場合、バイナリログが完全な行イメージを記録していないことを意味します。この問題を解決するには、次の手順に従ってください。

1. セルフマネージド MySQL ソースデータベースをホストしているサーバーにログインします。

2. MySQL の my.cnf 設定ファイルを変更して、binlog_row_image パラメータを full に設定します。

   log_bin=mysql_bin
   binlog_format=row # binlog フォーマットを row に設定します。
   server_id=2 # 1 より大きい整数である必要があります。この値は一例です。
   binlog_row_image=full # このパラメータは、ソースデータベースが MySQL 5.6 以降の場合に必要です。

   説明

   my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスは異なる場合があります。

3. 次のコマンドを実行して MySQL を再起動します。

   [$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
   [$Mysql_Dir]/bin/safe_mysqld &

   説明

   [$Mysql_Dir] を MySQL のインストールディレクトリに置き換えてください。

4. セルフマネージド MySQL ソースデータベースに再度ログインし、次の SQL ステートメントを実行して、binlog_row_image パラメータが full に設定されていることを確認します。

   show variables like "%binlog_row_image%";

5. 事前チェックを再度実行します。

ソースデータベースの server_id チェックの失敗

シナリオ：ソースデータベースの server_id チェックが失敗します。

解決策: MySQL 増分データ移行タスクを開始すると、事前チェックフェーズでソースデータベースに対して server_id チェックが実行されます。 以下に、セルフマネージド MySQL ソースデータベースでの server_id チェックの失敗を解決する方法を説明します。

1. 自己管理型の MySQL データベースサーバーにログインし、次の SQL 文を実行して、server_id パラメーターの値を確認します。

   SHOW variables LIKE '%server_id%';

2. server_id パラメーターは 1 より大きい整数に設定する必要があります。次の SQL ステートメントを実行して、server_id の値を変更します。

   SET global server_id=[$ID];

   説明

   • [$ID] を 1 より大きい整数に置き換えます。ID が一意であり、他のデータベースサーバーで使用されていないことを確認してください。

   • セルフマネージドデータベースがプライマリ/セカンダリモードの場合、この変更がプライマリセカンダリレプリケーションに影響を与えないことを確認してください。

   • このステートメントを実行した後、設定ファイル内の server_id の値も変更する必要があります。そうしないと、再起動するとこの変更は元に戻ります。

3. 事前チェックを再実行します。

ソースデータベースのバイナリログチェックの失敗

シナリオ：セルフマネージド MySQL データベースのバックアップスケジュールを開始すると、バイナリログチェックが失敗します。

対処法：

1. MySQL CLI で次のコマンドを実行して、バイナリロギングが有効になっているかどうかを確認します。

   SHOW variables LIKE 'log_%';

2. 出力の 'log_bin' の値が 'OFF' の場合、バイナリロギングは無効になっています。Linux システムで有効にするには、'vim' コマンドを使用して my.cnf 設定ファイルを編集します。

   mysql> show variables like 'log_%';
   +-----------------------------------------+---------------------+
   | Variable_name                           | Value               |
   +-----------------------------------------+---------------------+
   | log_bin                                 | OFF                 |
   | log_bin_basename                        |                     |
   | log_bin_index                           |                     |
   | log_bin_trust_function_creators         | OFF                 |
   | log_bin_use_v1_row_events               | OFF                 |
   | log_builtin_as_identified_by_password   | OFF                 |
   | log_error                               | /var/log/mysqld.log |
   | log_error_verbosity                     | 3                   |
   | log_output                              | FILE                |
   | log_queries_not_using_indexes           | OFF                 |
   | log_slave_updates                       | OFF                 |
   | log_slow_admin_statements               | OFF                 |
   | log_slow_slave_statements               | OFF                 |
   | log_statements_unsafe_for_binlog        | ON                  |
   | log_syslog                              | OFF                 |
   | log_syslog_facility                     | daemon              |
   | log_syslog_include_pid                  | ON                  |
   | log_syslog_tag                          |                     |
   | log_throttle_queries_not_using_indexes  | 0                   |
   | log_timestamps                          | UTC                 |
   | log_warnings                            | 2                   |
   +-----------------------------------------+---------------------+
   21 rows in set (0.00 sec)

   # /etc/my.cnf ファイルを開きます。
   vim /etc/my.cnf
   
   # i を押して編集モードに入ります。
   # 次のパラメータを追加します。
   log_bin = mysql_bin
   binlog_format = row
   server_id = 2
   expire_logs_days = 30
   
   # Esc を押して編集モードを終了し、:wq を入力して変更を保存して終了します。

3. セルフマネージド MySQL データベースを再起動します。

   systemctl restart mysqld

   説明

   設定ファイルの変更は、データベースインスタンスを再起動した後にのみ有効になります。オフピーク時間帯にセルフマネージドデータベースインスタンスを再起動することを推奨します。

   MySQL が再起動したら、ステップ 1 のコマンドを実行して、バイナリロギングが有効になっていることを確認します。その後、バックアップスケジュールを再起動します。

ストレージエンジンチェックの失敗

対処法： このチェックでは、ソースデータベースが増分データ移行でサポートされていないストレージエンジンを使用しているかどうかを確認します。MySQL から MySQL への増分データ移行では、FEDERATED および MRG_MyISAM ストレージエンジンはサポートされていません。チェックが失敗した場合、移行対象のテーブルがこれらのストレージエンジンのいずれかを使用していることを意味します。

MySQL パスワードフォーマットのチェック

シナリオ：バックアップスケジュールまたは復元タスクの事前チェックに失敗します。

解決策：古いパスワードフォーマットが検出されました。old_passwords を参照してください。

オブジェクト名の競合

シナリオ： 復元するために選択したオブジェクトが、復元先の既存のデータベースオブジェクトと同じ名前です。

高度なダウンロードタスクの一般的なエラー

症状： ApsaraDB RDS コンソールのインスタンスのバックアップと復元 詳細ページで、高度なダウンロードタスクを作成するために[インスタンスバックアップファイルのダウンロード] ボタンをクリックすることができません。

DBS-DownloadTask.Region

原因：現在のリージョンでは、この機能は利用できません。

解決策：この機能をリクエストするには、DingTalk グループ (ID: 35585947) でサポートチームにお問い合わせください。

DBS-DownloadTask.InstanceInfo

原因：ダウンロードサービスが ApsaraDB RDS インスタンスの情報の取得に失敗しました。

解決策：ApsaraDB RDS インスタンスが異常な状態にあるか、削除済みであるかを確認してください。

DBS-DownloadTask.DbType

原因： ApsaraDB RDS インスタンスのデータベースエンジンが、高度なダウンロード機能をサポートしていません。

解決策：高度なダウンロード機能は、ApsaraDB RDS for MySQL と ApsaraDB RDS for PostgreSQL でのみ利用できます。

DBS-DownloadTask.CustomerId

原因：この機能は、ご利用の ApsaraDB RDS インスタンスではまだ有効になっていません。

解決策：この機能は段階的なリリース中の可能性があり、ご利用のインスタンスではまだ利用できません。カスタマーサポートグループ (DingTalk グループ ID: 35585947) にてテクニカルサポートへお問い合わせいただき、ご要件をお伝えください。

DBS-DownloadTask.CustinName

原因：この機能は段階的なロールアウト中のため、お客様の ApsaraDB RDS インスタンスではまだ有効になっていません。

解決策：アクセスをリクエストするには、DingTalk グループ (ID: 35585947) でテクニカルサポートにお問い合わせください。

DBS-DownloadTask.user

原因：この機能は、お客様の ApsaraDB RDS インスタンスでは有効になっていません。

解決策：この機能は段階的なリリース期間中であるため、お客様のインスタンスではまだ利用できない可能性があります。DingTalk グループ (Group ID: 35585947) でテクニカルサポートに問い合わせて、リクエストを送信してください。

DBS-DownloadTask.Instance.Version

考えられる原因： ApsaraDB RDS インスタンスのマイナーエンジンバージョンが古くなっています。

DBS-DownloadTask.Instance.Storage.Type

原因：ApsaraDB RDS インスタンスのストレージタイプは、高度なダウンロード機能に対応していません。

解決策：高度なダウンロード機能は、クラウドディスクを使用するインスタンスでのみサポートされています。ApsaraDB RDS インスタンスの 基本情報 ページに移動し、ストレージタイプ が クラウドディスク であることを確認してください。

DBS-DownloadTask.Instance.Param

原因： ApsaraDB RDS インスタンスのパラメータ設定が正しくないため、高度なダウンロード機能は利用できません。

解決策：お使いの ApsaraDB RDS インスタンスのマイナーエンジンバージョンが古くなっていないこと、およびバックアップデータが暗号化されていないことを確認してください。 詳細については、「高度なダウンロードの前提条件」をご参照ください。

DBS-DownloadTask

考えられる原因： ApsaraDB RDS インスタンスが高度なダウンロード機能をサポートしていません。

共通タスクエラー

DBS-000000

シナリオ： 物理フルバックアップの失敗。

原因： サービスがバックアップスケジュールで指定されたバックアップゲートウェイに接続できず、再試行が最大 100 回に達したためタスクが失敗します。一般的な原因は、バックアップゲートウェイがオフラインになっていることです。

DBS-000000 Scheduling failed, the task has been retried, exceeding the maximum limit

解決策：

1. 対象のバックアップスケジュールの [タスクの設定] ページで、バックアップゲートウェイのステータスが [オフライン] になっているかどうかを確認します。

2. 左側のナビゲーションペインで、[バックアップゲートウェイ] をクリックします。[バックアップゲートウェイ] ページで、[バックアップゲートウェイのホスト名] で対象のゲートウェイを見つけます。IP アドレス、ホスト名、および最終ハートビート時刻が正しいことを確認します。現在のステータスは [ステータス] 列に表示されます。

3. バックアップゲートウェイがインストールされているサーバーの実行ステータスとネットワーク構成を確認します。

   サーバーが正常に稼働しており、ネットワーク接続が安定している場合は、バックアップゲートウェイを再起動してください。一部の古いバージョンのバックアップゲートウェイには脆弱性がある可能性があります。バックアップゲートウェイのアップグレードを推奨します。詳細については、「バックアップゲートウェイのアップグレード」をご参照ください。

   説明

   これらの手順を完了してもバックアップゲートウェイが起動しない場合は、DingTalk グループでテクニカルサポートへお問い合わせください。

DBS-000001

シナリオ：論理完全バックアップタスクが失敗します。

原因：リトライ回数の上限を超えた、または 7 時間以上ハングしたため、タスクが失敗しました。

DBS-000001 Scheduling failed, the task has been retried, exceeding the maximum limit or hang more than 7 hours

解決策：タスクを再起動し、ステータスを監視してください。エラーが解消されない場合は、DingTalk グループでサポートに問い合わせてください。

DBS-000002

シナリオ：論理スキーマバックアップまたは完全バックアップ中に失敗が発生します。

原因：利用可能なサービスリソースがありません。

DBS-000002 Because the current system has no available resources, scheduling timeout...

解決策：DingTalk グループでテクニカルサポートにご連絡いただき、障害の診断を依頼してください。

DBS-000003

シナリオ：リンタスクが失敗しました。

原因：このタスクのインスタンスが見つかりませんでした。

DBS-000003  No instance was found for this task

解決策：サポートが必要な場合は、DingTalk グループ でテクニカルサポートにお問い合わせください。

DBS-000004

シナリオ：物理バックアップまたは復元タスクを開始できません。

原因：物理バックアップまたは復元タスクのスケジューリング中に例外が発生しました。

DBS-000004 + [詳細なエラーメッセージ]

解決策：タスクをリトライしてください。エラーが解決しない場合は、DingTalk グループ でテクニカルサポートにご連絡ください。

DBS-000005

現象：論理バックアップまたは復元タスクの開始に失敗しました。

原因：スケジューリングエラーが発生しました。

DBS-000005 + [詳細なエラーメッセージ]

解決策：タスクをリトライしてください。エラーが解決しない場合は、DingTalk グループでテクニカルサポートにお問い合わせください。

DBS-000006

シナリオ：物理バックアップまたは復元タスクが開始前にタイムアウトします。

原因：スケジューリングエラーまたはリソースの問題により、タスクの開始に失敗します。

DBS-000006 + [詳細なエラーメッセージ]

解決策：失敗したタスクをリトライしてください。タスクが再度失敗する場合は、DingTalk グループ でテクニカルサポート にお問い合わせください。

DBS-000007

シナリオ：論理バックアップまたは復元タスクの開始時にタイムアウトが発生します。

原因：タスクの起動中にスケジューリングエラーまたはリソースの問題が発生します。

DBS-000007 + [詳細なエラーメッセージ]

解決策：失敗したタスクを再起動してください。エラーが解決しない場合は、カスタマーグループを通じてサポートへお問い合わせください。

DBS-002003

シナリオ：SQL Server データベースのネイティブ物理完全バックアップが失敗します。

原因：データベースにアクセスできません。この問題は、必要なデータベース権限がない場合、データベースが存在しない場合、またはデータベースの状態によってアクセスが許可されない場合に発生します。

DBS-002003, message:User does not have permission to alter database 'UFTData305999_000002', the database does not exist, or the database is not in a state that allows access checks..
DBS-002003, message:User does not have permission to alter database 'UFDATA
DBS-002003, message:User 'guest' does not have permission to run DBCC LOGIN
DBS-002003 ["The TCP/IP connection to the host localhost, port 1433 has failed. Error: "Connection refused: connect. Verify the connection properties, check that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port, and that no firewall is blocking TCP connections to the port."."].

解決策：

1. データベースがオンラインであることを確認します。オフラインの場合は、オンラインにします。

2. データベースが復元中の場合は、復元が完了するまで待ってからタスクを再起動します。

3. 接続が暗号化されているかどうかを確認します。

   SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

4. レジストリで、トランスポート層セキュリティ (TLS) 暗号化が有効になっているかどうかを確認します。

   HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
   ## 1.x は TLS のバージョンを示します。たとえば、1.0、1.1、1.2、または 1.3 です。

   このレジストリ エントリが存在し、その値が 1 の場合、TLS 暗号化は有効になっています。TLS 暗号化を無効にするには、次の手順を実行します：

   1. レジストリ エントリの値を 1 から 0 に変更します。

   2. Windows のスタート検索ボックスで [インターネット オプション] を検索します。[詳細設定] タブをクリックし、下にスクロールして、[TLS 1.0 を使用する]、[TLS 1.1 を使用する]、[TLS 1.2 を使用する]、および [TLS 1.3 を使用する] のチェックボックスのチェックを外してから、[OK] をクリックします。変更は、コンピューターを再起動した後に有効になります。

   3. コンピューターを再起動し、バックアップ タスクを再試行します。

DBS-002009

シナリオ：スキーマバックアップの失敗。

DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Connect db jdbc:mysql://*:*?useSSL=false timeout.

解決策：トラブルシューティングについては、このトピックの「ソースデータベースへの接続テストの失敗」セクションをご参照ください。まず、データベースアカウント名、パスワード、アカウント権限、ソース IP、またはファイアウォールルールの変更により接続が失敗したかどうかを確認してください。これらの設定が変更されていない場合は、ネットワークマッピングを確認して再生成してください。

1. 対象のバックアップスケジュールの [タスクの設定] ページに移動し、[基本情報] セクションの右上隅にある [バックアップオブジェクトの編集] をクリックします。

2. データベースアカウント名とパスワードを再入力し、[接続テスト] をクリックします。

   接続テスト中、システムはバックグラウンドでネットワークマッピングをチェックし、必要に応じて再生成します。設定ページには、[データベースアカウント名] と [パスワード] のフィールドが含まれています。[接続方法] には、[非暗号化接続] または [SSL 暗号化接続] を選択できます。

   説明

   ソースデータベースの正しい設定で接続テストが失敗した場合でも、DingTalk グループでテクニカルサポートへお問い合わせください。

3. 接続テストが成功したら、[次へ] をクリックします。

4. バックアップ対象のデータベースとテーブルを再選択し、[保存] をクリックしてバックアップスケジュールを更新します。

   [保存] をクリックすると、新しい設定が有効になり、バックアップが直ちに開始されます。このアクションは、ソースデータベースとワークロードに影響を与える可能性があります。オフピーク時間に設定を変更することを推奨します。

DBS-102001

シナリオ：さまざまな状況で発生する可能性があります。

原因：バックアップは完了しますが、バックアップオブジェクトのメタデータベースへの報告に失敗します。これはスキーマバックアップでよく見られる問題です。タスクをリトライすることで問題が解決する場合があります。

DBS-102001 java.lang.IllegalStateException: The RecordSplit must be in FAILED or SUCCE

解決策：タスクをリトライしてください。問題が解決しない場合は、DingTalk グループでテクニカルサポートへお問い合わせください。

DBS-105001

シナリオ： このエラーはさまざまな操作中に発生する可能性があります。

原因： メタデータベースへのハートビート報告がタイムアウトします。

DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Too many connections

解決策： タスクをリトライしてください。問題が解決しない場合は、DingTalk グループでテクニカルサポートへお問い合わせください。

DBS-106001

シナリオ：このエラーは、さまざまな段階で発生する可能性があります。

考えられる原因： OSS 内部エラー。

DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: Please conta...
DBS-106001  error task count 2 reached to the max limit.

解決策：サポートが必要な場合は、DingTalk グループでお問い合わせください。

DBS-202002

シナリオ：お客様所有の OSS バケットへのデータバックアップのタスクが失敗します。

原因：料金滞納により OSS サービスが停止しています。

DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

DBS-203101

シナリオ：SQL Server データベースのネイティブ物理完全バックアップが失敗します。

DBS-203101 Connect db failure

解決策：

1. SQL Server Management Studio (SSMS) を使用してポート番号を指定してログインし、データベースが存在し、稼働していることを確認してください。

   デフォルトでは、ポート番号を指定せずにログインできます。ポート番号を指定するには、ホスト名の後にカンマを付けて追加します。例：localhost,1433。

   説明

   TCP 接続にのみ対応しています。

2. データベースで SSL 暗号化が有効になっていないことを確認します。[SQL Server 構成マネージャー] を開きます。左側のペインで、[SQL Server ネットワークの構成] > [MSSQLSERVER のプロトコル] に移動します。右クリックして [プロパティ] を選択します。[フラグ] タブで、[強制的に暗号化] が [はい] に設定されているかどうかを確認します。[はい] に設定されている場合は、[いいえ] に変更します。

DBS-203102

シナリオ：SQL Server データベースのネイティブ物理バックアップが失敗した場合。

DBS-203102 Could not find database ......

解決策：

1. データベースが削除されたかどうかを確認してください。削除されている場合は、バックアップ対象を再設定してください。

   対象のバックアップスケジュールの [タスクの設定] ページで、[基本情報] セクションにある [バックアップ対象の編集] をクリックします。

   説明

   新しい設定を保存すると、直ちにバックアップが開始されます。このプロセスは、ソースデータベースおよび業務に影響を与える可能性があります。

2. ソースデータベースの名前が変更されたかどうかを確認してください。変更されている場合は、前のステップの手順に従ってバックアップ対象を再設定してください。

3. データベースがオンラインであることを確認してください。

4. データベースが回復状態にある場合は、回復が完了するまで待ってから、タスクを再起動してください。

5. データベースの自動クローズ機能が有効になっている場合は、 False に設定してください。 SQL Server Management Studio (SSMS) で、対象のデータベースを右クリックし、[プロパティ] を選択します。 [オプション] ページで、[自動] セクションにある設定を確認します。

DBS-203103

シナリオ： SQL Server データベースの完全ネイティブ物理バックアップが失敗します。

原因：データベースがシャットダウンしています。

DBS-203103 The database server already shutdown

解決策：データベースサービスを起動してください。

DBS-203104

シナリオ： SQL Server データベースのネイティブ物理完全バックアップが失敗します。

原因： VDI コンポーネントの問題。

DBS-203104 Wait VDI timeout 30s

解決策： Windows イベントを確認して、VDI コンポーネントの問題をトラブルシューティングしてください。問題を解決した後、タスクをリトライしてください。問題が見つからない場合は、しばらく待ってからバックアップをリトライしてください。エラーが解決しない場合は、DingTalk グループ へお問い合わせください。

DBS-203201

シナリオ：このエラーは、SQL Server データベースのネイティブ物理完全バックアップ中に発生します。

考えられる原因：

DBS-203201 database xxx backupable lsn {1} exceeded limit {2}

database XXXXXX  backupable lsn 10000000000000000009 exceeded limit 10000000000000000001,,already increment backup name:,backup datetime:2024-01-19 00:00:00

DBS-203202

シナリオ：SQL Server データベースの増分バックアップが失敗します。

DBS-203202 BACKUP LOG {0} cannot be performed because there is no current database backup

解決策：完全バックアップを手動で実行してから、失敗した増分バックアップを再起動してください。

DBS-203203

シナリオ： SQL Server データベースのトランザクションログバックアップ中にエラーが発生します。

原因：データベースの復旧モデルが FULL に設定されていないため、トランザクションログバックアップはサポートされていません。

DBS-203203 Only support increment trnsaction log backup in FULL MODE, database {0}

ALTER DATABASE [your_database_name] SET RECOVERY FULL

DBS-203205

シナリオ： SQL Server データベースのネイティブ物理完全バックアップが失敗します。

原因：データベースがオフラインです。

DBS-203205 database  state is； DBS-203205 database AIS20210425120342 state is {1}

DBS-203206

シナリオ：SQL Server データベースのネイティブ物理完全バックアップが失敗します。

原因：データベースが利用できない、または破損しているため、開くことができません。

DBS-203206 message:Database 'UFTData992044_000002' cannot be opened due to

DBS-203240

シナリオ： SQL Server ネイティブ物理完全バックアップ。

原因： アカウントに sysadmin 権限がありません。

DBS-203240, message:User 'guest' does not have permission to run DBCC LOGIN

DBS-203301

現象：SQL Server データベースの完全復元が失敗します。

DBS-203301：データベース {0} の末尾ログはバックアップされていません。失いたくない作業がログに含まれている場合は、`BACKUP LOG WITH NORECOVERY` を使用してログをバックアップしてください。`RESTORE` ステートメントの `WITH REPLACE` 句または `WITH STOPAT` 句を使用して、ログの内容を上書きすることもできます。

解決策：

1. 末尾ログをバックアップするには、次のコマンドを実行します。

   BACKUP LOG [復元するデータベースの名前] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

2. 失敗した完全復元タスクを再実行します。

DBS-203302

シナリオ：SQL Server データベースのネイティブ物理完全バックアップからの復元が失敗します。

原因：トランザクションログバックアップは LSN {0} で終了していますが、復元を続行するために必要な LSN {1} に達していません。これは、ログバックアップチェーンにギャップがあることを示しています。

DBS-203302 the log in this backup set terminates at LSN {0}, which is too early to apply to the database. A more recent log backup that includes LSN {1} can be restored

解決策：サポートが必要な場合は、DingTalk グループでテクニカルサポートに問い合わせてください。

DBS-301005

シナリオ： Oracle インスタンスで物理完全バックアップが失敗します。

原因： Oracle インスタンスがアーカイブモードになっていません。物理完全バックアップにはアーカイブモードが必要です。

DBS-301005, message:INNER_ERROR[301005]:database is no archive mode
DBS-301005, message:INNER_ERROR[301005]:user="" ConnectString="" standalone params= ......

解決策：アーカイブモードを有効にしてください。詳細な手順については、アーカイブモードの有効化をご参照ください。

DBS-301502

シナリオ： MySQL の物理バックアップ中にエラーが発生します。

原因：バックアップ中に、redo ログに記録できない DDL 操作が実行されます。

DBS-301502, without redo logging

解決策： DDL 操作が実行中でないときにバックアップをリトライしてください。

DBS-301503

シナリオ： MySQL の物理バックアップが失敗します。

原因： REDO ログ の生成速度がバックアップ速度を上回っています。

DBS-301503, log copying being too slow

解決策： REDO ログファイル のサイズを増やし、バックアップをオフピーク時間に設定してください。

DBS-301504

シナリオ：MySQL インスタンスの物理バックアップが失敗します。

原因：このエラーは、Database Backup Service のバックアッププロセスに必要な暗号化情報が欠落しているために発生します。

DBS-301504, missing encryption

解決策：回避策として、テーブルの暗号化を無効にしてから、バックアップをリトライしてください。暗号化を無効にできない場合は、カスタマーサービスへお問い合わせいただき、バックアップスケジュールの返金をリクエストしてください。

DBS-301505

シナリオ： MySQL データベースの物理バックアップが失敗しました。

原因：システムがバックアッププロセスを終了しました。

DBS-301505, signal: terminated

解決策：タスクを再起動してください。

DBS-302035

シナリオ： Oracle データベースのフル物理バックアップが失敗します。

原因： Oracle インスタンスのロールを取得できません。

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

解決策：

1. データベースインスタンスをホストするサーバーにログインします。

2. 次のコマンドを実行して、システム管理者としてデータベースにログインします。

   sqlplus / as sysdba

3. 次の SQL ステートメントを実行して、結果が返されるかどうかを確認します。

   select database_role from v$database;

   結果が返されない場合は、原因を調査してください。結果が返される場合は、DingTalk グループ でサポートに連絡してください。

DBS-400001

シナリオ：フル ネイティブ物理バックアップまたは全データ変換タスクが失敗します。

原因：バックアップスケジュール仕様が不十分なため、タスクがメモリ不足になります。

DBS-400001 , message :Java heap space. 
DBS-400001 java.lang.OutOfMemoryError: Java heap space

解決策：バックアップスケジュール仕様をアップグレードしてください。復元タスクなどの緊急タスクのメモリ制限を一時的に増やすには、DingTalk グループ でテクニカルサポートにご連絡ください。手順については、「バックアップスケジュールのアップグレード」をご参照ください。

DBS-999999 またはエラーコードなし

シナリオ： 任意のタスク中にエラーが発生します。

原因： 例外が未定義であるか、システムが対応するエラーコードを返せませんでした。

DBS-999999 + [エラーメッセージ]

解決策： エラーメッセージをコピーしてこのトピック内で検索し、別のエラーコードがこの問題に該当するかどうかを確認してください。解決策が見つからない場合は、DingTalk グループ でテクニカルサポートにお問い合わせください。