| Oracle® Big Data SQLユーザーズ・ガイド リリース3.2.1 E92089-05 |
|
 前 |
 次 |
Oracle Big Data SQLのトラブルシューティングと一般的な理解に役立つ注意事項をまとめたものを次に示します。
Oracle Databaseサーバーで、Big Data SQL診断データ収集ツールbdscheckswを使用して、Oracle Big Data SQLの簡単なサニティ・テストを実行できます。このスクリプトでは、Oracle DatabaseとHadoopクラスタの両側からOracle Big Data SQLインストールに関する診断情報を収集して分析します。このスクリプトは、データベース・サーバーの$ORACLE_HOME/binにあります。
構文
bdschecksw Required_Params [Options]
次の表では、bdscheckswで使用する必須およびオプションのパラメータについて説明します。
表C-1 bdscheckswのパラメータ
| パラメータ | 説明 | 必須またはオプション |
|---|---|---|
-h, --help |
コマンド・ヘルプを表示して終了します。 | オプション |
-d, --dbhome ORACLE_HOME |
Oracle Databaseサーバー上のOracleインストールへのパス。 | bdscheckswが実行されるOracle DatabaseサーバーでORACLE_HOME環境変数が定義されていない場合のみ必須。 |
-s, --sid=[ORACLE_SID] |
Oracle DatabaseサーバーのSID。 | bdscheckswが実行されるOracle DatabaseサーバーでORACLE_SID環境変数が定義されていない場合のみ必須。 |
-g, --gihome=Grid_Infrastructure_home Oracle_Database_node_IP_address |
Oracle Databaseサーバー上のグリッド・インフラストラクチャのパス。 | bdscheckswが実行されるOracle DatabaseサーバーでGI_HOME環境変数が定義されていない場合のみ必須。 |
-y, --giuser Oracle_Database_node_IP_address Grid_Infrastructure_home |
GI_HOME管理者名またはGI_HOMEの所有者(OSユーザー名)。 |
|
-q, --sqlplus Oracle_Database_node_IP_address username |
Oracle DatabaseサーバーのSQLPlusユーザー名。ユーザーは、パスワードを要求されます。 | 必須。 |
-c, --cell DNS short name [...n] |
Hadoopクラスタ・セル・ノード。DNS短縮名(FQDNからドメイン名を除いたもの)をデリミタの空白とともに使用します。1つのノードが複数のネットワークに存在することもあるため、IPアドレスは使用しないでください。 | Hortonworks HDPの場合のみ、必須です。 |
-u, --uname Hadoop_cluster_node_username |
Oracle DatabaseサーバーからHadoopクラスタに対してリモート・コマンドを実行するための資格証明。これは通常、oracleユーザーです。 |
ユーザー名およびパスワードは常に必須です。 |
-p,--pdb=PDB_CONTAINER |
Oracle Databaseサーバーのプラガブル・データベースのコンテナ名。 | プラガブル・データベース(PDB)コンテナが、bdscheckswが実行されるOracle Databaseサーバーで構成されている場合にのみ必要です。 |
-k, --key SSH_identity_key_file |
SSH (セキュア・シェル)鍵ファイルへのパス。 | -uおよび-pに加えてオプションのSSHアイデンティティ(または鍵)ファイルを使用し、公開鍵認証のアイデンティティ(秘密鍵)の読取り元となるファイルを選択します。 |
-r, --cluster Hadoop_cluster_name |
Hadoopクラスタ名。 | オプション。 |
-t, --trace |
テストの実行中に、extprocおよびlog4jトレーシングを有効にします。 | オプション。 |
-f, --file=file_path |
出力をファイルにリダイレクトします。 | オプション。 |
-i, --interactive |
対話形式で(一度に全部ではなく)コマンドライン引数を入力します。 | オプション。 |
-x |
拡張モード。 | オプション。root権限が必要です。 |
-v, --verbose |
冗長レポート・モード。 | オプション。(レポートでの完全詳細の場合に推奨。) |
終了ステータス
bdscheckswスクリプトは、次のステータス・コードのいずれかを戻します。
表C-2 bdscheckswのステータス・コード
| ステータス | 説明 |
|---|---|
| 0 | 成功 |
| 1 | 軽微な問題(対話型モードでの応答なしなど)。 |
| 2 | 重大な問題(無効なコマンドライン引数など)。 |
例
$ ./bdschecksw -d /u03/app/oracle/product/$ORACLE_HOME/dbhome_1 -s orcl -p pdborcl -g /u03/app/oracle/product/$ORACLE_HOME/grid -q sys -u oracle -vOracle Big Data SQLが機能していることを確認するための一連の基本チェックを次に示します。
Oracle Databaseサーバーで、$ORACLE_HOME/bigdatasqlのhadoop_<hcluster>.envファイルを使用して、環境をソーシングします。
oracle LinuxユーザーとしてOracle Databaseサーバーに対してkinitを実行します。また、可能な場合は、oracleユーザーとして各Big Data SQLデータノードに対してkinitを実行します。 注意:
データノードに対してkinitを実行しなくてもこのテストは実行できますが、テストでのオフロードは機能しません。オフロードが機能していることを確認するために、最終的にはデータノードに対してkinitを実行する必要があります。テキスト・ファイルを作成して複数行のランダム・テキストを追加します。
テキスト・ファイルをHDFSに/user/oracle/test.txtとしてコピーします。
$ hadoop fs -put test.txt /user/oracle/test.txt
ORACLE_HDFS型のOracle外部表を定義します。
CREATE TABLE bds_test (line VARCHAR2(4000))
ORGANIZATION EXTERNAL
( TYPE ORACLE_HDFS DEFAULT DIRECTORY DEFAULT_DIR LOCATION ('/user/oracle/test.txt') )
REJECT LIMIT UNLIMITED;
Select * from bds_test;
select n.name, s.value /* , s.inst_id, s.sid */ from v$statname n, gv$mystat s where n.name like '%XT%' and s.statistic# = n.statistic#;
Hive表を定義します。
HueまたはHive/Beelineコマンドライン経由で、あるいはOracle SQL DeveloperをHive JDBCドライバとともに使用してHiveに接続します。
CREATE TABLE bds_test_hive (line string);
LOAD DATA INPATH '/user/oracle/test.txt' OVERWRITE INTO TABLE bds_test_hive;
外部表ORACLE_HIVEを定義します。
CREATE TABLE bds_test_hive (line VARCHAR2(4000))
ORGANIZATION EXTERNAL
( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR
ACCESS PARAMETERS
(com.oracle.bigdata.tablename=default.bds_test_hive)
)
REJECT LIMIT UNLIMITED;
表C-3 Big Data SQLのデータベース・オブジェクト
| タイプ | オブジェクト |
|---|---|
ディレクトリ |
|
データベース・リンク(パブリック) これらにより、Big Data SQLはMTA(マルチスレッド・エージェント)にアクセスできるようになります。 |
|
データ・ディクショナリ・ビュー |
|
Hiveデータ・ディクショナリのファンクションおよびプロシージャ 「 |
|
表 |
SYS.HIVE_URI$: DBA以外のユーザー用のセキュリティ表。 |
統計 |
|
表C-4 $ORACLE_HOME/bigdatasqlディレクトリ
| サブディレクトリまたはファイル名 | 内容の説明 |
|---|---|
|
このORACLE_HOMEにインストールされている、すべてのクラスタに関連する設定が格納されます。これには、次のものを格納する、各クラスタのサブディレクトリが含まれます。
|
|
このORACLE_HOMEで実行されている、すべてのデータベースに関連する設定が格納されます。このORACLE_HOMEで実行されている各データベースのサブディレクトリが含まれます。各データベースのサブディレクトリには、次のものを含むbigdata_configディレクトリが格納されます。
各データベースのサブディレクトリには、次のものも含まれます。
|
|
JDKインストールへのソフト・リンク。別のバージョンが存在する可能性がありますが、Oracle Big Data SQLによってインストールされるバージョンは |
|
Oracle Big Data SQLのJava JARディレクトリ |
|
|
|
通常、このディレクトリは空です。 |
|
2タイプのextprocからのJavaログ・ファイルが格納されます。ファイル名の一部であるPIDを使用して、探しているextprocを特定します(1つのログ・ファイルのみが現在実行中の |
|
Hadoopクライアントの環境を設定します。各クラスタのインストールには、これらの |
|
インストールされているcp2hadoop (Hadoopにコピー)ツールキットへのソフト・リンク。Oracle Big Data SQL 3.2.1によってインストールされるツールキットのバージョンは |
表C-5 外部プロシージャ・エージェント
| エージェント | 説明 |
|---|---|
|
|
|
外部表を問い合せる際に使用されるBDSマルチスレッド・エージェント。これは、Oracle Clusterwareによって起動/停止されますが、 この
extprocbds_<dbname>_<hcluster>が実行されていない場合は、おそらくRACクラスタ内のすべてのデータベース・サーバーでbds_database_install.shを実行していません。C部分のログ・ファイルは、$ORACLE_HOME/hs/logにあります(ただし、ロギングを確認するには、$ORACLE_HOME/hs/admin/initbdsを編集してTRACE_LEVEL=ONを追加した後、再起動する必要があります)。JVM部分のログ・ファイルは、$ORACLE_HOME/bigdatasql/logに格納されます(ただし、bigdata-log4j.propertiesを設定して再起動する必要があります)。再起動するには、(プロセスでkill -9を実行する方が手早い方法ですが)次に示す方法をお薦めします。$ crsctl stop resource bds_<dbname>_<hcluster> $ crsctl start resource bds_<dbname>_<hcluster> |
注意:
前述の表の外部プロシージャはいずれも、データベースへのコールバックを実行しますが、これは、セキュアな外部パスワード・ストア機能を使用することでブロックできます。セキュアな外部パスワード・ストア(SQLNET.WALLET_OVERRIDE=TRUE)を使用する場合は、My Oracle Supportでドキュメント2126903.1を参照してください。表C-6 ログ・ファイルとトレース・ファイル
| ディレクトリまたはファイル名 | 説明 |
|---|---|
|
|
|
|
データベースの |
データベース・セッションからのログ・ファイルが格納されます。これらからは有用な情報を取得できます。
|
|
crsctl stop has export CELLCLIENT_TRACE_LEVEL="all,4" export CELLCLIENT_AUTOFLUSH_LEVEL="all,4" crsctl start has |
|
データベース・サーバーのIPアドレスとサブネット範囲を記録します。コモディティ・サーバーのOracle Big Data SQLの場合、このファイルには、インフィニバンドRDSからTCP/UDPにプロトコルを切り替えるパラメータ( |
Kerberosファイル: |
HadoopクラスタでKerberosを使用している場合、データベースでKerberosを設定する必要があり、 Oracle Big DataのSQLインストーラでは、このためのcronジョブをHadoopクラスタとOracle Databaseシステムの両方に、自動的に設定するディレクティブをJaguar構成ファイルに提供するようになりました。詳細は、インストレーション・ガイドの構成ファイルの説明を参照してください。 |
次の表に、Big Data SQLのトラブルシューティングに役立つ情報を提供できるHadoopサーバーのオブジェクトを示します。
表C-7 トラブルシューティングに役立つHadoop側のデータノードのアーティファクト
| データノードのアーティファクト | 説明 |
|---|---|
|
|
ログ・ファイル |
|
| その他のデータノードのアーティファクト |
|
ユーザーがOracle Big Data SQL外部表にかかわるSELECT問合せを発行します。
データベースが、SQL内のオブジェクトの1つがORACLE_HIVE型の外部表であることを確認します。
データベースは、外部表定義のcom.oracle.bigdata.clusterパラメータからクラスタ名を特定します(特定できない場合、デフォルト・クラスタを使用します)。
データベースは、com.oracle.bigdata.tablenameパラメータからHive表名を特定します(特定できない場合、Hive表名はOracle表名と同じであると想定します)。
データベースは、ORACLE_HIVE外部表の実装で、extprocbds_<dbname>_<hcluster>マルチスレッド・エージェントによって呼び出される外部プロシージャを使用することを認識します。
注意:
問合せの第1フェーズでは、Hiveメタデータを取得する必要があります。この第1フェーズでエラーが発生すると、次のように始まるエラーが表示されます。ODCIEXTTABLEOPENの"OPEN"に注目してください。 ORA-29913: error in executing ODCIEXTTABLEOPEN callout
データベースは、パブリック・データベース・リンクのBDSQL$_DEFAULT_CLUSTERまたはBDSQL$_<hcluster>を使用して、extprocbds_dbname>_hcluster>マルチスレッド・エージェントのスレッドにデータベース・セッションを接続するかリスナーに問うための接続文字列を検索します。
extprocbds_<dbname>_<hcluster>がすでにOracle Clusterwareによって起動されており、$ORACLE_HOME/bigdatasql/databases/<database name>/bigdata_configディレクトリからの構成情報を使用しています。
extprocbds_<dbname>_<hcluster>は、前述の構成情報を使用してHadoopクライアント・ライブラリを実行するJVMを生成しています。Hadoopクライアント・ライブラリは、bds-exa-install.shスクリプトの実行時に、Oracle Big Data ApplianceからOracle Databaseサーバーにコピーされています。
extprocbds_<dbname>_<hcluster>は、JVMおよびHiveメタストア・クライアント・ライブラリを使用して、Hiveメタストアを(thrift://hostname>:9083などのURLを使用して)コールし、Hive表のメタデータ(列、入力形式、SerDe、その他の表プロパティ)を取得します。
この時点で、HiveメタストアがKerberos認証によって保護されている場合、Oracle Databaseサーバーのextprocbds JVMで実行されているHiveクライアント・ライブラリは、ローカルKerberosチケットをHiveサーバーに送信しようとします。これは、データベースを実行しているoracle Linuxユーザー・アカウントが所有するチケットになります。
extprocbds_<dbname>_<hcluster>は、Hiveメタストアをコールして、Hive表の中にデータを保持する入力パスのリストを取得します。
extprocbds_<dbname>_<hcluster>は、Hadoop MapReduceのライブラリおよびロジックを使用して、入力パスのリストをスプリット/ブロックのリストに変換します。次に、HDFSネームノードにすべてのスプリット/ブロックの場所(レプリカを含む)を要求します。
HDFSがKerberosで保護されている場合、データベースのoracle Linuxユーザー・アカウントからのKerberosチケットを使用する必要があります。
圧縮が使用されている場合、この時点で、JVMは特定の圧縮Javaライブラリまたはネイティブ・ライブラリをロードする必要があります。これらが標準以外のライブラリである場合、Oracle DatabaseサーバーとHadoop側の両方にそれらをインストールする必要があります。たとえば、LZO圧縮では、データベース側とHadoop側の両方で追加のインストールおよび構成を実行する必要があります。
この時点で、"記述"フェーズが実行され、データベースはHive表の構造の他、データの全ブロックの場所(レプリカを含む)も認識します。この情報は、メタデータ・ペイロードとも呼ばれます。今度は、"フェッチ"フェーズを開始します。
Oracle Exadataシステムでも使用されるデータベース・インテリジェント・ストレージ・レイヤーのKCFIS (Kernel Cache File Intelligent Storage)が、データのブロックが格納されるホスト名を、グリッドのdiskmonプロセスによって保持されているアクティブなBDSQLサーバー・ホストのリストと比較します。(diskmonのBDSQLサーバー・ホストのリストはV$CELLで確認できます)。
注意:
問合せの第2フェーズでは、データをフェッチする必要があります。この第2フェーズでエラーが発生すると、次のように始まるエラーが表示されます。ODCIEXTTABLEFETCHの"FETCH"に注目してください。ORA-29913: error in executing ODCIEXTTABLEFETCH callout
データノードのホスト名のリストがBDSQLホスト名のリストと一致した場合、データベースはローカル・ブロック(グラニュルとも呼ばれる)のリストを各BDSQLサーバーに送信します。また、データベースはBDSQLサーバーにアクセス先の表、列および構造に関するメタデータを送信します。パフォーマンス上、これはパラレルで非同期に実行されます。
注意:
データベース統計の"cell XT granules requested for predicate offload"および"cell XT granule bytes requested for predicate offload"は、この時点で更新されます。 データノード上で実行されているBDSQLプロセスが、検疫されたSQL_IDのローカル・リストに照らしてSQL_IDをチェックします。SQL_IDが検疫リストと一致した場合、データノードのBDSQLプロセスはエラーを返します。ただし、ユーザーはこのエラーを確認する必要はありません。かわりに、データベースが、まず別のセルを試した後、その処理自体を実行しようとします。(手順15および16を参照してください)。
SQL_IDがデータノードのBDSQLプロセスによって検疫されなかった場合、BDSQLプロセスは、送信されたブロック/グラニュルのリストに照らしてSmartScanの処理を実行します。
ヒント:
ストレージ索引およびSmartScan処理のその他の特徴の詳細は、The Data Warehouse Insiderのブログ・エントリBig Data SQL Quick Start. Storage Indexes - Part10を参照してください。BDSQLオフロード・プロセスが、/opt/oracle/bigdatasql/bdcell-<cell version>/bigdata.propertiesから構成情報をすでに読み取っています。
BDSQLプロセスは、前述の構成で定義されているプロパティに基づいてJVMをすでにロードしています。
Hive表に特殊なInputFormatクラスまたはSerdeクラスが含まれる場合、前述の構成で定義されているクラスパスに基づいて検出できれば、JVMはそのようなクラスをロードします。一部の一般的なInputFormats (デリミタ付きテキストなど)について、オラクル社では、そのような形式を通常のJavaコードよりも速く処理できるCコードを作成しています。
Kerberos認証が使用されている場合、BDSQLのJVMはローカルKerberosチケットをHDFSデータノード・プロセスに送信します。これは、BDSQLが稼働しているデータノードでoracle Linuxユーザーに関連付けられたKerberosチケットです。
Sentry認証が使用されている場合は、oracle LinuxユーザーのKerberosチケットのアイデンティティにHive表および基礎となるHDFSデータに対するアクセス権が付与されている必要があります。
BDSQLサーバーが、実行時に"cell XT granule IO bytes saved by storage index"などの統計を更新します。
データベースkcfisレイヤーが、データノードのBDSQLプロセスから返される結果を収集し、次のバッチのブロック/グラニュルをBDSQLプロセスに送信します。
バイト数が返されると、データベースが、"cell interconnect bytes returned by XT smart scan"統計を更新します。
特定のブロックについてBDSQLプロセスで問題が発生した場合、データベースは、その処理を別のBDSQLプロセスに送信しようとします(失敗したブロックのレプリカがある場所を捜します)。
データベースは、"cell XT granule predicate offload retries"統計を更新します。
再試行後でも、BDSQLプロセスでブロックを正常にオフロードできない場合、データベースは"フォールバック"してextprocbds_<db>_<cluster>内のJVMでその処理を実行します。
これは、生データを処理のためにデータベース・サーバーに移動する必要があるため、遅くなります。
Hive表に特殊なInputFormatまたはSerdeが含まれる場合、extprocbds_<db>_<cluster>のJVMは、データベースのbigdata.propertiesファイルで定義されているクラスパス構成に基づいて、それらをロードする必要があります。
入力パス/ブロック/グラニュルがすべて処理されるまで、外部表データ・ソースからの結果は引き続き収集されます。
ユーザーがOracle Big Data SQLデータ・ディクショナリ・ビューのいずれか(all_hive_tablesなど)を問い合せます。
Oracle Big Data SQL 2.0以前では、これがuser_hive_*ビューであり、ユーザーがDBAでなかった場合、ユーザーはSYS.HIVE_URI$表にリストされている必要がありました。Oracle Big Data SQL 3.0では、HIVE_URI$チェックが削除されています。
ビューが、GetHiveTable pl/sqlパイプライン・テーブル・ファンクションにアクセスします。
GetHiveTableファンクションが、SYS.DBMSHADOOPLIBライブラリを使用して外部プロシージャとして実装されるHiveMetadata型で実装されます。
Oracle Databaseが、このデータベース・セッション用に"extproc"の新しいインスタンスを生成します。extprocが、設定用の$ORACLE_HOME/hs/admin/extproc.oraファイルを読み取ります。
CコードをトレースするためにTRACE_LEVEL=ONと設定できます。ログ・ファイルは$ORACLE_HOME/hs/logに書き込まれます。
デフォルトでは、extproc.oraに誤りがあって、ログに「Error in assignment statement」メッセージが書き込まれることがあります。文"SET EXTPROC_DLLS=" (等号記号の後に値なし)は有効ではありません。TRACE_LEVEL=ONを使用する場合は、この行をコメント・アウトします。
extprocが、libkubsagt.soライブラリ(SYS.DBMSHADOOPLIB)をアタッチします。
Libkubsagt12.soが、JVMを起動してHiveMetadata.jarをロードします。
JVMは、$ORACLE_HOME/bigdatasql/bigdata_config/内の構成情報を使用して、クラスタのリストおよびHiveメタストア接続情報を識別します。
JVMに関するロギングは、$ORACLE_HOME/bigdatasql/bigdata_config/bigdata-log4j.propertiesに基づいています。ログ・ファイルは$ORACLE_HOME/bigdatasql/logに書き込まれます。データベース・セッションごとに新しいログ・ファイルが1つ存在します。
HiveMetadata.jarのJavaコードは、Hiveメタストア・クライアント・ライブラリを使用してHiveメタストアに接続し、すべてのデータベースおよびすべての表に関するデータを取得します。
HiveメタストアがKerberosによって保護されている場合、JVMは、データベースを実行しているoracle LinuxユーザーのKerberosチケットを送信しようとします。
Javaコードが、データベースにリクエスト・データを返します。
extprocbds_<db>_<hcluster>の再起動:
$ crsctl stop res bds_<dbname>_<hcluster>
手早い方法ですが、最良ではありません。最良な方法は、extprocbds_*プロセスを強制終了して、復帰するのを待ちます。
extprocの再起動。
これにより、新しいデータベース・セッションが開始されます。
データノードでのOracle Big Data SQLソフトウェアの再起動:
Cloudera ManagerまたはAmbari Web UIを使用します。
手早い方法ですが、最良ではありません。最良な方法は、bdsqloflsrvプロセスを強制終了して、復帰するのを待ちます。
Oracle Big Data Appliance (ノード1でrootとしてログオン)に対するコマンドライン・メソッド:
$ bdacli stop big_data_sql_cluster $ bdacli start big_data_sql_cluster
単一データノードでのOracle Big Data SQL検疫のチェック:
$ bdscli -e list quarantine detail
すべてのデータノードに対して検疫をチェックするには、次のようにします。
$ dcli -g cells.lst bdscli -e list quarantine detail
単一データノードでのOracle Big Data SQL検疫のクリア:
$ bdscli -e drop quarantine all
すべてのデータノードに対して検疫をクリアするには、次のようにします。
$ dcli -g cells.lst bdscli -e drop quarantine all適切なオフロードについての統計のチェック:
SQLモニター・ヒント(/*+ MONITOR*/)を使用します。
XTの統計を問い合せます。"retries"がゼロかつ"bytes returned"がゼロより大きいことを確認します。
データノードでのログ・ファイルの検索:
すべてのデータノードに対して検疫をクリアします。
データノードの/opt/oracle/bigdatasql/bdcell-12.1/bigdata-log4j.propertiesでLogプロパティを設定します。
データノードでbdsqloflsrvを再起動します。
ディレクトリをログ・ファイル・ディレクトリ(/opt/oracle/bigdatasql/bdcell-12.1/log)に変更します。
tail -f bigdata-log4j.log
調べているノードに関するデータが問合せに含まれるようにします(つまり、問合せでは多数のブロックが含まれるファイルにアクセスする必要があります。少数のブロックにしかアクセスしない場合、データノードにまったく処理が要求されないという結果になります)。
新しいデータベース・セッションを作成して(XTの統計をリセットするため)、問合せを実行します。
ヒント:
必ずSQLモニターで表示する場合は、/*+MONITOR*/ hintを使用します。データノードのbigdata-log4j.logに新しいエントリが表示されます。
Oracle Databaseサーバーで、XTの統計を問い合せて、retries=0およびbytes returned>0であることを確認します。
データベースでのログ・ファイルの検索:
すべてのデータノードに対して検疫をクリアします。
新しいデータベース・セッションを作成します(XTの統計をリセットするため)。
select host_name from v$instance;
Linuxレベルでそのインスタンスのデータベース・サーバーにログインします。
$ORACLE_HOME/bigdatasql/bigdata-log4j.propertiesでログのプロパティを設定します。
そのインスタンスでextprocbds_<db>_<hcluster>を再起動し、ログのプロパティ変更を収集します。
XTトレースを有効にします。
次のコマンドは、外部表のロギングを有効にします。
alter session set "_xt_trace"="low","compilation","execution";
次のコマンドは、トレースをさらに追加します。
alter session set events 'trace[KCFIS] disk high, memory high';
問合せを実行します。
ヒント:
必ずSQLモニターで表示する場合は、/*+ MONITOR */ hintを使用します。XTの統計を問い合せて、retries=0およびbytes returned>0であるかどうかを確認します。
select n.name, s.value /* , s.inst_id, s.sid */ from v$statname n, gv$mystat s where n.name like '%XT%' and s.statistic# = n.statistic# ;
JVMログ・ファイル($ORACLE_HOME/bigdatasql)を調べます。(extprocbds_*プロセスと同じPIDのものを探します。)
データベースのtrace_fileを調べます。
select value from v$diag_info WHERE name = 'Default Trace File';
次に示すように、JVMプロパティをbigdata.propertiesファイルに追加できます。これは、目立ちにくく低いレベルのKerberosの問題に役立つことがあります。
java.options=-Dsun.security.krb5.debug=true
データベースではextprocプロセスとextprocbds_<dbname>_<hcluster>プロセスによってJVMが実行され、データノードではbdsqloflsrvプロセスによってJVMが実行されます。これを確認するには、"jps"コマンドを実行します。
$ORACLE_HOME/bigdatasql/jdk*/bin/jps
Javaスキルを非常に簡単に操れる場合は、Oracle JVisualVMまたはOracle JConsoleを使用してJVMに接続することもできます。
パッチ・エラーおよびデータパッチ・エラーの原因と結果は多種多様です。1つ実行できることは、必要なパッチがロードされているかを確認することです。
エラー・スタックの'FETCH_OPEN'のコールで、誤った数または型の引数を見つけた場合
正しいパッチがロードされているかどうかを判別するDBA_REGISTRY_SQLPATCHの問合せの根拠となるエラー・スタックの例を次に示します。
ORA-29913: error in executing ODCIEXTTABLEFETCH callout ORA-29400: data cartridge error ORA-06550: line 1, column 25: PLS-00306: wrong number or types of arguments in call to 'FETCH_OPEN' ORA-06550: line 1, column 14:PL/SQL: Statement ignored
これは、いくつかの問題の1つを示している場合があります。
バンドル・パッチが正しく適用されていない。
データパッチが実行されていないため、Oracle Big Data SQLのインストール済のバージョンで必要なパッチがインストールされていない。
その場合、『Oracle Big Data SQL Master Compatibility Matrix』 (My Oracle SupportのドキュメントID 2119369.1)でこのインストールに対する要件として規定されているパッチが適用されているかどうかを判別するために、次の問合せを実行します。
select PATCH_ID, PATCH_UID, VERSION, STATUS, DESCRIPTION from DBA_REGISTRY_SQLPATCH order by BUNDLE_SERIES
たとえば、BP 12.1.0.2.160419 (22806133)が適用されたOracle Big Data SQL 3.0.1の場合、問合せによって次の結果が返されます。
PATCH_ID PATCH_UID VERSION STATUS DESCRIPTION ---------- ---------- ------- ---- ------- -- ------------ 22806133 19983161 12.1.0.2 SUCCESS DATABASE BUNDLE PATCH: 12.1.0.2.160419 (22806133)
問合せが失敗した場合またはインストール済のバンドルに対する正しいパッチが見つからない場合は、データパッチにおける問題の詳細をMy Oracle Supportの1609718.1で確認してください。
