このページでは、次の既知のエラーと推奨されるトラブルシューティングの手順について説明します。
移行ジョブのエラー
移行ジョブ プロセスでは、ランタイム中にエラーが発生することがあります。
- エラーには、ソース データベースの不正なパスワードなど、回復可能なものもあります。これらのエラーが修正されると、移行ジョブは自動的に再開されます。
- データ レプリケーションのエラーなど、復元できないエラーもあります。これらのエラーが修正されたら、移行ジョブを再起動する必要があります。
エラーが発生すると、移行ジョブのステータスが 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 データベースへの接続を確立できませんでした。 |
プロジェクトからソース データベースにアクセスできることを確認します。 移行元の接続構成方法に関連する設定を確認します。
|
エラー メッセージ: 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 サブネット(具体的には踏み台 VM nic0
インターフェース)に Private Service Connect NAT CIDR 範囲がアクセスできるようにするファイアウォール ルールがありません。
試すこと: 組織のポリシーで、内部ファイアウォール ルール(
PSC 対応でない AlloyDB for PostgreSQL インスタンスの宛先プライベート 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 telnet
telnet クライアントに接続します。
telnet 127.0.0.1 PORT
PORT
は、データベースのポート番号に置き換えます。
コマンドの結果に応じて、次の対応を行います。
コマンドで接続を開けない場合は、プロキシログを確認して根本原因を特定します。根本原因は、AlloyDB for PostgreSQL インスタンスの設定によって異なります。
telnet を使用して接続が開いているにもかかわらずクライアントでハングアップする場合は、踏み台インスタンスの IP アドレスのルーティングが問題である可能性があります。VM のターミナルで
ip route
と入力します。セカンダリnic
(nic1
、DB_SUBNETWORK_GATEWAY
IP アドレス)を使用して、AlloyDB for PostgreSQL インスタンスのプライベート 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 などのリバース プロキシ ソリューションを使用して、プライベート接続構成を作成します。