このページでは、既知のエラーと、推奨されるトラブルシューティング手順について説明します。
移行ジョブのエラー
移行ジョブのプロセスで、実行時にエラーが発生することがあります。
- ソース データベースのパスワードが間違っているなど、一部のエラーは復元可能です。これらのエラーが修正されると、移行ジョブは自動的に再開されます。
- データ レプリケーションのエラーなど、一部のエラーは回復不能です。これらのエラーを修正したら、移行ジョブを再開する必要があります。
エラーが発生すると、移行ジョブのステータスが Failed に変わり、サブステータスに失敗前の最後のステータスが反映されます。エラーのトラブルシューティングを行うには、失敗した移行ジョブに移動してエラーを表示し、エラー メッセージに記載されている手順に沿って操作します。エラーの詳細を表示するには、移行ジョブのリンクを使用して Cloud Monitoring に移動します。ログは特定の移行ジョブにフィルタされます。
次の表に、問題の例とその解決方法を示します。
| 症状 | 考えられる原因 | 次の方法をお試しください |
|---|---|---|
エラー メッセージ: Database Migration Service can't set up a tunnel to be
connected to the bastion host。
|
Database Migration Service が踏み台インスタンスにアクセスできないか、踏み台インスタンスが接続を受け入れていません。 | ソース接続プロファイルと SSH トンネル サーバー構成でフォワード SSH トンネルの設定を確認し、もう一度お試しください。 |
エラー メッセージ: Database Migration Service can't connect to the database または Database Migration Service private connectivity error, cannot connect to the database。 |
Database Migration Service が移行元の Oracle データベースへの接続を確立できませんでした。 |
プロジェクトからソース データベースにアクセスできることを確認します。 ソース接続の構成方法に関連する設定を確認します。 特定の Oracle エラーコード（ |
エラー メッセージ: Archiving mode is not ARCHIVELOG |
ソース データベースが ARCHIVELOG モードで実行されていない。 |
ARCHIVELOG モードを使用するようにソース データベースを構成します。詳細については、
移行元 Oracle データベースを構成するをご覧ください。 |
エラー メッセージ: Supplemental logging ("ALL COLUMN LOGGING") isn't turned
on for the tables listed below。
|
ソース データベースでサプリメンタル ログデータが有効になっていない。 | 追加ログデータを有効にして、モードを ALL に設定します。詳細については、
移行元 Oracle データベースを構成するをご覧ください。 |
エラー メッセージ: No Archive Log Files were found in the source |
Database Migration Service は、クローズされたアーカイブ ログのみを読み取ります。ソース データベースにログが見つかりませんでした。 |
データベースにアクティブな書き込みオペレーションがない場合は、少なくとも 1 つの |
エラー メッセージ: We're missing the necessary permissions to read
from the source。
|
移行元データベースの移行ユーザー アカウントに必要な権限がありません。 |
Database Migration Service は、移行元の接続プロファイルで構成したユーザー アカウントとして移行元に接続します。このアカウントには、ソース データベースのデータを読み取るための特定の権限セット（ 移行ユーザー アカウントに必要な権限があることを確認します。詳細については、 移行元 Oracle データベースを構成するをご覧ください。 |
エラー メッセージ: Unable to connect to the destination database |
移行先データベースへの接続中に問題が発生しました。 | プロジェクトから宛先データベースにアクセスできることを確認します。 宛先接続の構成方法に関連する設定を確認します。 |
エラー メッセージ: The following tables don't exist in the destination database: {table_names} |
移行しようとしているリストされたテーブルが、移行先データベースに存在しません。 | Database Migration Service は、ソーススキーマを変換するときに、必要なテーブルと定義を作成します。 |
エラー メッセージ: password authentication failed for user {username} |
移行先データベースのユーザー名またはパスワードが正しく構成されていません。 | 移行先の PostgreSQL 接続プロファイルが、正しいユーザー名とパスワードで正しく構成されていることを確認します。 |
エラー メッセージ: The following tables in the destination database
don't have primary keys: {table_names}。
|
エラー メッセージに表示されているテーブルは、宛先データベースに存在しますが、主キーがありません。 |
Database Migration Service のコンバージョン ワークスペースでは、スキーマを変換するときに、主キーのないテーブルに主キーが自動的に追加されます。 以前のコンバージョン ワークスペースを使用している場合は、移行先で主キーを手動で作成する必要があります。詳細については、 以前のコンバージョン ワークスペースをご覧ください。 |
警告: The following tables have foreign keys: {table_names}。 |
エラー メッセージに表示されているテーブルは、宛先データベースに存在しますが、外部キーがあります。 |
Database Migration Service はトランザクション方式でデータを複製しないため、テーブルが順序どおりに移行されない可能性があります。外部キーが存在し、外部キーを使用する子テーブルが親テーブルの前に移行されると、レプリケーション エラーが発生することがあります。 このようなデータの完全性の問題を回避するには、移行ユーザーに |
エラー メッセージ: Unable to resume replication as log position is lost |
このエラーは、レプリケーション プロセスが長時間一時停止され、ログの位置が失われた場合に発生することがあります。 | 移行ジョブは、ログの保持期間より長く（またはそれに近い期間）一時停止しないでください。ログの位置が失われた場合は、移行ジョブを再作成する必要があります。 |
エラー メッセージ: ORA-00942: table or view does not exist |
このエラーは、Oracle サーバーでのキャッシュ保存が原因で発生することがあります。 | データベース ユーザーを再作成して、キャッシングの問題を解決します。 |
| 移行ジョブがフルダンプ フェーズのままで、変更データ キャプチャ（CDC）フェーズに進みません。 | Database Migration Service が一部のテーブルに対してまだフルダンプを実行しているか、エラーが原因で 1 つ以上のテーブルでフルダンプを完了できません。 |
|
接続に関する問題
このセクションでは、ネットワーク接続に関する潜在的な問題のトラブルシューティング手順について説明します。
移行先データベースに接続できません: EOF
接続テストを実行すると、[DATABASE] unable to connect to the destination database: EOF エラー メッセージが返されます。
考えられる原因: サービス アタッチメントが正しく構成されていない。
対応策:
サービス アタッチメントの Terraform 構成ファイルで、enable_proxy_protocol が false に設定されていることを確認します。プロキシ プロトコルは、NGINX や Apache などの HTTP サーバーでのみサポートされています。
gcloud を使用して Private Service Connect の設定を作成する場合、プロキシ プロトコルはデフォルトで無効になっています。
接続タイムアウト、接続拒否
接続テストの実行が失敗するか、タイムアウトする。これは、Private Service Connect の設定内でルーティングが誤って構成されていることが原因である可能性があります。この問題には、いくつかの理由が考えられます。
考えられる原因: Private Service Connect NAT CIDR の範囲が、踏み台が配置されている Private Service Connect サブネット（具体的には踏み台 VM の nic0 インターフェース）にアクセスできるようにするファイアウォール ルールがありません。
試すべきこと: 組織のポリシーで内部ファイアウォール ルールが制限されていないことを確認します。たとえば、
PSC が有効になっていない Cloud SQL インスタンスの宛先プライベート IP 接続を構成するための Terraform スクリプトの例で定義されている psc_sp_in_fw ファイアウォール ルールなどです。
考えられる原因: プロキシがダウンしている。指定されたポートにリスナーがないため、接続がハングします。
試してみること: 踏み台 VM への SSH 接続を確立し、次のコマンドを使用してプロキシを検索します。
netstat -tunalp | grep PORT
コマンドに対するレスポンスを分析します。
空のレスポンスが返された場合、プロキシは停止しています。次のコマンドを実行してみてください。
sudo su; cd /。sudo dpkg -s dante-serverを実行して、Dante サーバーがインストールされているかどうかを確認します。プロキシがインストールされている場合は、次のメッセージが表示されます。
Status: install ok installedプロキシがインストールされていない場合、ルーターが見つからないことが原因である可能性があります。ルーターを追加し、
apt-get install dante-serverを実行してプロキシをダウンロードできるかどうかを確認します。
プロキシが実行中で、指定されたポートでリッスンしている場合は、次の手順で接続を開いてみます。
PostgreSQL クライアントをインストールします。
sudo apt-get install postgresql-client。PostgreSQL データベースに接続します。
psql -h 127.0.0.1 -p PORT -U DBUSERNAME -W（パスワードの入力を求められます）。次のように置き換えます。
PORT: データベースのポート番号。DBUSERNAME: PostgreSQL データベースへの接続に使用するユーザー名。
telnet クライアントをインストールします。
sudo apt-get install telnettelnet クライアントに接続します。
telnet 127.0.0.1 PORTPORTは、データベースのポート番号に置き換えます。
コマンドの結果に応じて、次の対応を行います。
コマンドで接続を開けない場合は、プロキシログを調べて根本原因を特定します。根本原因は、Cloud SQL インスタンスの設定によって異なる場合があります。
telnet を使用して接続が開かれたものの、クライアントでハングする場合は、踏み台インスタンスの IP アドレスのルーティングに問題がある可能性があります。VM のターミナルで「
ip route」と入力します。セカンダリnic（nic1、DB_SUBNETWORK_GATEWAYIP アドレス）を使用して Cloud SQL インスタンスのプライベート IP アドレスに接続をルーティングするルーティング ルールを見つけられるかどうかを確認します。
考えられる原因: サービス アタッチメントが、Database Migration Service からのエンドポイント接続を受け入れていません。サービス アタッチメントには、承認されたプロジェクトのリストが保持されます。Database Migration Service プロジェクトは、このリストに含まれていません。
解決方法: この問題を解決するには、次のいずれかを試してください。
Google Cloud コンソールで、[Private Service Connect] に移動します。
[公開サービス] タブで、サービス アタッチメントに対する Database Migration Service からの接続を承認します（保留中の場合）。
リクエスト元のプロジェクトをサービス アタッチメントの許可リストに登録されたプロジェクトに追加します（拒否された場合）。
Terraform で許可リストに登録されたプロジェクトを追加する方法については、 Terraform のドキュメントをご覧ください。
gcloudで許可リストに登録されたプロジェクトを追加する方法については、 Google Cloud CLI のリファレンス ドキュメントをご覧ください。
これで問題が解決しない場合は、接続プロファイルを再作成します。
Private Service Connect 接続に関連付けられている 接続プロファイルを削除し、再作成します。
Oracle SCAN エラーのトラブルシューティング
このセクションでは、単一クライアント アクセス名（SCAN）機能を使用して Oracle Real Application Clusters（RAC）ソースから移行する際に発生する可能性のある問題について説明します。
Oracle SCAN データベースへの接続を確立できない
接続テストの実行が失敗するか、タイムアウトする。
考えられる原因: Oracle SCAN ソース データベースに直接接続を確立しようとしている可能性があります。Database Migration Service は、Oracle RAC 環境の SCAN 機能を使用するデータベースへの直接接続をサポートしていません。
解決方法: この問題を解決するには、次のいずれかを試してください。
いずれかのノードに直接接続します。
Oracle Connection Manager を使用する。
HAProxy などのリバース プロキシ ソリューションを使用して、プライベート接続構成を作成します。