6.8. Oracle コネクターのよくある質問
- Oracle 11g はサポートされますか ?
- Oracle 11g はサポート対象外ですが、ベストエフォートベースで Oracle 11g との後方互換性を確保しています。Red Hat は、互換性に関する懸念を Oracle 11g と通信し、リグレッションが特定されたときにバグ修正を提供するためにコミュニティーに依存しています。
- Oracle LogMiner は非推奨となりましたか ?
- いいえ、Oracle は Oracle 12c で Oracle LogMiner で継続的なマイニングオプションのみを非推奨にし、Oracle 19c 以降のオプションが削除されました。Debezium Oracle コネクターは、このオプションに依存して機能しないため、新しいバージョンの Oracle で安全に使用でき、影響はありません。
- オフセットの位置を変更するにはどうすればよいですか ?
Debezium Oracle コネクターは、scn という名前のフィールドと
commit_という名前の 2 つの重要な値をオフセットに保持します。scnscnフィールドは、変更をキャプチャーする際にコネクターが使用する低基準値の開始位置を表す文字列です。-
コネクターオフセットが含まれるトピックの名前を確認します。これは、
offset.storage.topic設定プロパティーとして設定された値に基づいて設定されます。 コネクターの最後のオフセット(保存されるキー)を見つけ、オフセットを保存するために使用されるパーティションを特定します。これは、Kafka ブローカーのインストールによって提供される
kafkacatユーティリティースクリプトを使用して実行できます。以下に例を示します。kafkacat -b localhost -C -t my_connect_offsets -f 'Partition(%p) %k %s\n' Partition(11) ["inventory-connector",{"server":"server1"}] {"scn":"324567897", "commit_scn":"324567897: 0x2832343233323:1"}inventory-connectorのキーは["inventory-connector",{"server":"server1"}]で、パーティションは11で、最後のオフセットはキーに続くコンテンツになります。以前のオフセットに戻すには、コネクターを停止し、次のコマンドを発行する必要があります。
echo '["inventory-connector",{"server":"server1"}]|{"scn":"3245675000","commit_scn":"324567500"}' | \ kafkacat -P -b localhost -t my_connect_offsets -K \| -p 11これにより、指定のキーと値の
my_connect_offsetsトピックのパーティション11に書き込まれます。この例では、コネクターは324567897ではなく SCN3245675000に戻します。
-
コネクターオフセットが含まれるトピックの名前を確認します。これは、
- コネクターが指定されたオフセット SCN でログを見つけられない場合、どうなりますか ?
Debezium コネクターは、コネクターオフセットに低および高の -watermark SCN 値を維持します。low-watermark SCN は開始位置を表し、コネクターが正常に起動するために利用可能なオンライン redo またはアーカイブログに存在する必要があります。コネクターがこのオフセット SCN を見つけられない場合、利用可能なログには SCN が含まれていないため、コネクターは停止した場所から変更をマイニングできないことを示します。
この場合は、2 つのオプションがあります。1 つ目は、コネクターの履歴トピックとオフセットを削除し、コネクターを再起動して、提案された新しいスナップショットを作成することです。これにより、すべてのトピックコンシューマーでデータ損失が発生することが保証されます。2 つ目は、オフセットを手動で操作し、SCN を redo またはアーカイブログで利用可能な位置に上げることです。これにより、古い SCN 値と新しく提供された SCN 値の間に発生した変更が失われ、トピックに書き込まれません。これは、推奨されません。
- さまざまなマイニング戦略の違いは何ですか ?
Debezium Oracle コネクターは、
log.mining.strategyの 2 つのオプションを提供します。デフォルトは
redo_in_catalogで、ログスイッチが検出されるたびに Oracle データディクショナリーを redo ログに書き込むようコネクターに指示します。このデータディクショナリーは、Oracle LogMiner が redo および アーカイブログを解析する際にスキーマの変更を効果的に追跡するために必要です。このオプションは、通常の数のアーカイブログを生成しますが、データ変更のキャプチャーに影響を与えることなく、キャプチャーされるテーブルをリアルタイムで操作できるようにします。このオプションには通常、より多くの Oracle データベースメモリーが必要で、各ログスイッチの後に Oracle LogMiner セッションとプロセスの起動に若干時間がかかります。別のオプションの
online_catalogは、データディクショナリーを redo ログには書き込みません。代わりに、Oracle LogMiner は常にテーブルの構造の現在の状態が含まれるオンラインデータディクショナリーを使用します。これは、テーブルの構造が変更され、オンラインデータディクショナリーと一致しなくなった場合に、テーブルの構造が変更された場合に Oracle LogMiner はテーブル名または列名を解決できないことを意味します。キャプチャーされるテーブルが頻繁にスキーマの変更が適用される場合は、このマイニングストラテジーのオプションを使用しないでください。すべてのデータの変更をスキーマの変更でロックし、テーブルのログからすべての変更をキャプチャーし、コネクターを停止し、スキーマの変更を適用し、テーブルでデータの変更を再開することが重要です。このオプションは、Oracle データベースメモリーが少なく、Oracle LogMiner セッションは、LogMiner プロセスでデータディクショナリーを読み込んだりする必要がないため、通常、Oracle LogMiner セッションは大幅に高速に起動します。- SYS または SYSTEM ユーザーが行った変更がキャプチャーされないのはなぜですか ?
-
Oracle データベースは、
SYSおよびSYSTEMユーザーアカウントを使用して、変更データキャプチャーに重要ではない redo ログで多数の内部操作を実行します。Debezium Oracle コネクターが Oracle LogMiner から変更を読み取ると、これらの 2 つのユーザーアカウントによる変更は自動的に除外されます。したがって、これらの 2 つのユーザーアカウントのいずれかを使用していて、変更イベントが表示されない場合は、これらのユーザーが行った変更がキャプチャーされない理由になります。システム以外のユーザーアカウントを使用して、キャプチャーするすべての変更を実行する必要があります。 - コネクターが AWS で変更のキャプチャーを停止するのはなぜですか ?
タイムアウト AWS Gateway Load Balancer で 350 秒の修正されたアイドルタイムアウト により、完了までに 350 秒を超える JDBC 呼び出しは無期限にハングする可能性があります。
Oracle LogMiner API の呼び出しが完了するまでに 350 秒以上かかる状況では、タイムアウトが発生し、AWS Gateway Load Balancer がハングアップすることがあります。例えば、大量のデータを処理する LogMiner セッションと Oracle の定期的なチェックポイントタスクが同時に実行された場合、このようなタイムアウトが発生する可能性があります。
AWS Gateway Load Balancer でタイムアウトが発生しないように、Kafka Connect 環境から root または superuser で次の手順を実行して、キープアライブパケットを有効にします。
ターミナルから、以下のコマンドを実行します。
sysctl -w net.ipv4.tcp_keepalive_time=60
/etc/sysctl.confを編集し、以下のように以下の変数の値を設定します。net.ipv4.tcp_keepalive_time=60
Oracle コネクターが
database.hostnameではなくdatabase.urlプロパティーを使用するように再設定し、以下の例のように Oracle 接続文字列記述子(ENABLE=broken)を追加します。database.url=jdbc:oracle:thin:username/password!@(DESCRIPTION=(ENABLE=broken)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=hostname)(Port=port)))(CONNECT_DATA=(SERVICE_NAME=serviceName)))
前述の手順では、TCP ネットワークスタックが 60 秒ごとにキープアライブパケットを送信するように設定します。その結果、LogMiner API への JDBC 呼び出しが完了するまで 350 秒を超える時間がかかる場合、AWS Gateway ロードバランサーはタイムアウトしません。これにより、コネクターはデータベースのトランザクションログから変更の読み取りを続行します。
- ORA-01555 の原因とどのように対処するか
Debezium Oracle コネクターは、最初のスナップショットフェーズの実行時にフラッシュバッククエリーを使用します。フラッシュバッククエリーは、データベースの
UNDO_RETENTIONデータベースパラメーターによって維持されるフラッシュバック領域に依存する特別なタイプのクエリーで、テーブルの内容が指定の時間または指定の SCN の場合はクエリーの結果を返します。デフォルトでは、Oracle は、データベース管理者が増減しない限り、元に戻す領域またはフラッシュバック領域を約 15 分間維持します。大きなテーブルをキャプチャーする設定では、最初のスナップショットを実行するために 15 分以上かかるか、設定されたUNDO_RETENTIONが初期スナップショットを実行するのに時間がかかる場合があります。これにより、最終的にこの例外が発生します。ORA-01555: snapshot too old: rollback segment number 12345 with name "_SYSSMU11_1234567890$" too small
この例外を扱う最初の方法は、データベース管理者と連携し、
UNDO_RETENTIONデータベースパラメーターを一時的に増やすことができるかどうかを確認することです。Oracle データベースの再起動は必要ありません。したがって、データベースの可用性に影響を与えることなく、オンラインで実行できます。ただし、これを変更すると、テーブルスペースに必要な元に戻すデータを保存するための十分なスペースがある場合に、上記の例外またはスナップショットが古くなってしまう例外が発生することがあります。この例外を処理する 2 つ目の方法は、最初のスナップショットに依存しないことです。また、
snapshot.modeをschema_onlyに設定し、代わりに増分スナップショットに依存します。増分スナップショットはフラッシュバッククエリーに依存しないため、ORA-01555 例外の対象ではありません。- ORA-04036 の原因と対処方法
データベースの変更が頻繁に発生すると、Debezium Oracle コネクターは ORA-04036 例外を報告する可能性があります。Oracle LogMiner セッションは、ログスイッチが検出されるまで開始および再利用されます。Oracle LogMiner で最適なパフォーマンスの使用率を提供するため、セッションは再利用されますが、長時間実行されるマイニングセッションが発生すると、PGA メモリーが過剰に使用され、最終的に以下のような例外が発生する可能性があります。
ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT
この例外は、Oracle スイッチがやり直すログや Debezium Oracle コネクターがマイニングセッションを再利用できる期間を指定することで回避できます。Debezium Oracle コネクターは、設定オプション
log.mining.session.max.msを提供します。これは、現在の Oracle LogMiner セッションを終了し、新しいセッションが開始されるまでの時間を制御します。これにより、データベースで許可されている PGA メモリーを超えることなく、データベースリソースをチェックインできます。- ORA-01882 の原因とどのように対処するか
Debezium Oracle コネクターは、Oracle データベースへの接続時に以下の例外を報告する可能性があります。
ORA-01882: timezone region not found
これは、JDBC ドライバーでタイムゾーン情報を正しく解決できない場合に発生します。このドライバーに関連する問題を解決するには、リージョンを使用してタイムゾーンの詳細を解決しないようにドライバーに指示する必要があります。これには、
driver.oracle.jdbc.timezoneAsRegion=falseを使用してドライバーパススループロパティーを指定します。- ORA-25191 の原因とその処理方法
Debezium Oracle コネクターは、Oracle LogMiner ではサポートされていないため、インデックス編集テーブル(IOT)を自動的に無視します。ただし、ORA-25191 例外が出力された場合は、このようなマッピングの一意なケースが原因である可能性があり、これらを自動的に除外するために追加のルールが必要になる場合があります。ORA-25191 例外の例を以下に示します。
ORA-25191: cannot reference overflow table of an index-organized table
ORA-25191 例外が出力された場合は、テーブルとそのマッピング、他の親テーブルに関連するマッピングなどが含まれる Jira issue を発生させてください。回避策として、コネクターがこのようなテーブルにアクセスできないように include/exclude 設定オプションを調整することができます。