Oracle インジェストのトラブルシューティング
ベータ版
この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。
このページでは、Databricks Lakeflow Connect の Oracle 統合 CDC コネクタに関する一般的な問題とその解決方法について説明します。
一般的なパイプラインのトラブルシューティング
このセクションのトラブルシューティング手順は、 Lakeflowコネクトのすべてのインジェスト パイプラインに適用されます。
パイプラインの実行中に失敗した場合は、失敗したステップをクリックし、エラーメッセージがエラーの性質に関する十分な情報を提供しているかどうかを確認してください。

また、右側のパネルで Update details をクリックし、 Logs をクリックして、パイプラインの詳細ページからクラスター ログを確認して download することもできます。Logsをスキャンして、エラーまたは例外がないか確認してください。

ソース構成を確認する
パイプラインの更新が失敗した場合は、ソースデータベースが正しく構成されていることを確認してください:
-
アーカイブ Logs モードが有効になっていることを確認します:
SQLSELECT LOG_MODE FROM V$DATABASE;クエリーは
ARCHIVELOGを返す必要があります。 -
補足的なログ記録が有効になっていることを確認します:
SQLSELECT supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_all FROM V$DATABASE;このクエリーは、データベースレベルでのみ補足ロギングを報告します。代わりに個々のテーブルで補足ロギングを有効にした場合、テーブルが正しく構成されていても、これらの列は引き続き
NOを返す可能性があります。特定のテーブルを確認するには、ALL_LOG_GROUPSをクエリーします:SQLSELECT log_group_type FROM ALL_LOG_GROUPS WHERE owner = '<schema>' AND table_name = '<table>'; -
レプリケーションユーザーが
DBX_ORACLE_SETUP_UTIL.GRANT_PERMISSIONSによって付与された権限を持っていることを確認してください。Oracle データベースのユーザー要件を参照してください。
補足ログの検証に失敗しました
Databricks は、レプリケートする各テーブルに少なくとも主キーの補足ロギングがあることを検証します。テーブルは、補足ロギングが直接有効になっている場合、またはカタログやデータベースから継承している場合に、このチェックを満たします。最小限の補足ロギングだけでは、このチェックを満たしません。
テーブルでプライマリキーの補足ロギングを有効にします:
ALTER TABLE <schema>.<table> ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
プライマリキーロギングと完全な補足ロギングのどちらを選択するかについては、どの補足ロギング方法を選択すべきか? を参照してください。
ウォレットが閉じられた状態の TDE 暗号化データ
データベースに Transparent Data Encryption(TDE)で暗号化されたテーブルスペースまたは列がある場合、暗号化ウォレット(キーストア)が開いている必要があります。そうでない場合、LogMiner は暗号化された列に対して Unsupported Type を報告し、検証は失敗します。ウォレットのステータスを確認します:
SELECT STATUS FROM V$ENCRYPTION_WALLET;
ステータスは OPEN である必要があります。統合キーストアを使用するマルチテナントデータベースの場合は、CDB$ROOT でウォレットを開きます。
ORA-12514: リスナーは現在、要求されたサービスを認識していません
Unity Catalog接続内のサービス名に到達できません。データベースに DB_DOMAIN が設定されている場合、プラガブルデータベース (PDB) サービスはドメイン修飾名で登録されます。接続には、ドメイン修飾された CDB$ROOT サービス名を使用します。データベース・ドメインを参照してください。
マルチテナント データベース:ユーザーが変更データを表示できない
マルチテナント(CDB)データベースについては、以下を確認してください:
- レプリケーションユーザーは共通ユーザーです(
C##プレフィックス)。 - ユーザーには
CONTAINER_DATA=ALLが設定されています。セットアップツールがこれを自動的に設定します。CDB環境のコンテナアクセスを参照してください。 - パイプライン内の
source_catalogは、CDB$ROOTサービス名です。
処理前にパージされたアーカイブ Logs
パイプラインが処理する前に Oracle がアーカイブLogsを削除した場合、影響を受けるテーブルには完全更新が必要です。 [[ ## completed ##]]これを回避するには、アーカイブLogsの保持期間を長くしてください。Databricks では、アーカイブ Logs を少なくとも 48 時間保持することを推奨しています。
PERMISSION_DENIED: クラスターを作成する権限がありません
Databricks アカウント管理者に連絡して Unrestricted cluster creation 権限を付与してもらうか、カスタムクラスターポリシーを使用してください。要件を参照してください。
取り込み中にテーブルがスキップされる
LogMinerは、サポートされていないデータ型やストレージ属性(例:BFILE、ネストされたテーブル、ID列など)を含むテーブルを無視します。LogMinerの制限事項を参照してください。
取り込みウィザードでのスキーマまたはテーブルの検出がタイムアウトしました
大規模な Oracle 環境(例:100 以上のスキーマまたは 1,000 以上のテーブル)では、スキーマとテーブルを検出するステップがタイムアウトする可能性があります。レプリケートする予定のスキーマとテーブルに対してのみ、レプリケーション ユーザーに SELECT 権限を付与します。これにより検出範囲が縮小され、タイムアウトを回避できます。テーブルに対する SELECT 権限の付与を参照してください。
default認証:defaultの認証情報を設定できません
このエラーが発生した場合は、現在のユーザー資格情報の検出に問題があります。以下を置き換えてみてください。
w = WorkspaceClient()
以下を使用:
w = WorkspaceClient(host=input('Databricks Workspace URL: '), token=input('Token: '))
Databricks SDK for Python ドキュメントの 認証 を参照してください。