この章では、Teradata JDBC Driverの使用中に発生する可能性がある問題のトラブルシューティングに関する情報を提供します。
SQLState 08S01のError 804およびエラー メッセージ"Socket communication failure for Packet receive" (または"Packet transmit")は、ネットワーク通信エラーが発生したことを意味します。
[Error 804] [SQLState 08S01] Socket communication failure for Packet receive ...
[Error 804] [SQLState 08S01] Socket communication failure for Packet transmit ...
ネットワーク通信エラーはさまざまな理由で発生する可能性があります。以下に、確率の高いほうから低い順に、接続問題の一般的な原因の一覧を示します。
Teradata Database V2R6.2では、SQLデータ タイプBIGINT (64ビットINTEGER型)のサポートを導入し、Large Decimal機能も導入しました。この機能は、DECIMALデータ タイプの最大精度をDECIMAL(38)まで拡張します。Teradata Database V2R6.1以前のリリースは、DECIMAL(18)の最大精度に制限されています。
最大精度は、データベースのリリースによって違ってきます。この結果、Teradata JDBC Driverでの数値型データの処理方法が影響を受けます。Large Decimalがサポートされていない場合、BigDecimalの最大精度は18です。一方、Large Decimalがサポートされている場合、最大精度値は38になります。
Teradata JDBC Driverが変更されたため、BigDecimal値の精度値が最大精度より大きい場合にはPreparedStatement.setBigDecimalメソッドがDataTruncation例外をスローします。
PreparedStatement setBigDecimalメソッドを使用して1つのパラメータに複数の値をバインドする場合、Teradata JDBC Driverは、そのパラメータにバインドされた最大整数部桁数を決定した後、DECIMAL値の最大精度のデータベース制限内に収まるように必要に応じて各値の小数部の桁を丸めます。最大精度値が18より大きく、現在のデータベースでSQLデータ タイプBIGINTがサポートされていない場合、Teradata JDBC Driver内のPreparedStatement.setLongメソッドはDataTruncation例外をスローします。
Using connection parameter CHARSET=UTF8 with fixed-width CHAR data type result set column values adds trailing space padding per the database's Character Export Width behavior. The CHAR(n) data type is a fixed-width data type (holding n characters), and the database reserves a fixed number of bytes for the CHAR(n) data type in response spools and in network message traffic.
UTF8は、文字ごとに可変のバイト数が必要な可変長の文字エンコーディング スキーマです。UTF8セッション文字セットを使用する場合、データベースは応答スプールとネットワーク メッセージ トラフィックでCHAR(n)データ型が使用できる最大バイト数を予約します。UTF8セッション文字セットを使用する場合、データベースは、予約した最大サイズよりも小さいCHAR(n)値の最後に埋め込み文字を追加するため、すべてのCHAR(n)値が応答スプールとネットワーク メッセージ トラフィックで同じ固定バイト数を使用します。これに対して、UTF16セッション文字セットを使用する場合、文字の埋め込みは追加されません。
SQL SELECT文またはビューでCASTやTRIMを使用することでこの欠点を回避して、固定長のCHARデータ型をVARCHARに変換する例を以下に示します。
CREATE TABLE MyTable (Column1 CHAR(10), Column2 CHAR(10))
SELECT Column1, Column2 FROM MyTable
SELECT CAST(Column1 AS VARCHAR(10)), TRIM(TRAILING FROM Column2) FROM MyTable
CREATE VIEW MyView (C1, C2) AS SELECT CAST(Column1 AS VARCHAR(10)), TRIM(TRAILING FROM Column2) FROM MyTable
または、末尾スペース埋め込み文字なしに固定幅CHARデータ値を必要とするアプリケーションには、接続パラメータCHARSET=UTF16が推奨されます。
Teradata JDBC Driverは、いかなる種類のSQLリクエストでもUSING句の指定をサポートしていません。Teradata JDBC Driverは、名前付きパラメータ マーカーをサポートしません。Teradata JDBC Driverは、名前なし疑問符パラメータ マーカーのみをサポートします。
SQLリクエストでUSING句を指定すると、次のようなデータベース エラーが発生します。
[Error 3889][SQLState 42000] リクエスト内のUSING句が多すぎます。
解決策は、SQLリクエストからUSING句を削除し、名前付きパラメータ マーカーを疑問符パラメータ マーカーに置き換え、JDBC PreparedStatement/CallableStatement setXXXメソッドを使用して値を疑問符パラメータ マーカーにバインドすることです。
表やストアド プロシージャなど、データベース オブジェクトの作成または削除を行なうときに以下のエラーが発生する場合があります。これにはエラー コード2631とSQL状態40001が含まれますが、これは再試行可能なエラーであることを示しています。
com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock.
このエラーが発生した場合、アプリケーションはしばらく待機して失敗した作成または削除の操作を再送信するかどうかを選択できます。
以下のエラーは、JDBC FastLoadを使用していてPreparedStatement setterメソッドを呼び出したときに発生する場合があります。これにはエラー コード2631とSQL状態40001が含まれますが、これは再試行可能なエラーであることを示しています。
com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock
このエラーが発生した場合、アプリケーションはしばらく待機してPreparedStatement setterメソッドを再び呼び出すかどうかを選択できます。エラー2631は一連の例外の一部である場合がある点に注意してください。このため、エラー2631に至るまでには、必ず一連の例外を辿る必要があります。
2つの個別のアプリケーション、またはスレッドを2つ使用した単一のアプリケーションでは、各スレッドまたはアプリケーションが、データベースへそれぞれのJDBC接続を使用していると、デッドロックが発生する可能性があります。
この問題が発生するのは、一方の接続がデータを表に挿入し、もう一方の接続が同じ表からデータを読み取ろうとした場合です。
デフォルト トランザクション分離レベルであるTRANSACTION_SERIALIZABLEを使用している場合、表からデータを読み取っているスレッドまたはアプリケーション上でこの状況が発生すると、そのおよそ2～5分後に、次のエラーが表示されます。エラー コードは2631です。
com.teradata.jdbc.jdbc_4.util.JDBCException:[Teradata Database]: Transaction ABORTed due to deadlock.
このエラーが発生したら、次のどちらかを実行します。
注: このトランザクション レベルは、java.sql.Connection.setTransactionIsolationメソッドを使用して設定されます。この結果、この問題は発生しなくなりますが、ダーティ読取り、反復不可読取り、およびファントム読込みの副作用が発生します。この状況を受け入れることができるかどうかは、個々のアプリケーションごとに判断する必要があります。
データベースでは、バイナリ データ(BLOB)と文字データ(CLOB)を保存する場合に、ラージ オブジェクト(LOB)に対応しています。データベースではまた、XML、JSON、およびST_GeometryなどのLOBに基づく複雑なデータ型にも対応しています。さらに、LOBに基づいてユーザー定義型 (UDT)も作成できます。Teradata JDBC Driverはすべてのデータ型をサポートすると同時に、LOBに基づくデータ型もサポートしています。
データベースの表には最大32個のLOB列を定義できます。BLOBとCLOBは、それぞれVARBYTEとVARCHARデータ型によく似ています。
最大サイズ2 GBのLOB値がサポートされています。LOB列を含む結果セットの場合、データベースはLOBロケーターをTeradata JDBC Driverに送信するため、LOBロケーター(LOB値ではない)のみがデータベースのResultSet行サイズに対する制限に対してカウントされます。アプリケーションは、BlobオブジェクトまたはClobオブジェクトをResultSetから取り出して、後でこれらのBlobオブジェクトまたはClobオブジェクトを別の表に挿入することができます。LOBロケーターがデータベースとTeradata JDBC Driverとの間で転送されるため、このプロセスにより、潜在的に大きいLOB値のネットワーク上での転送を避けられます。
データベースで次のエラーが発生する最も可能性の高い原因は、アプリケーションがResultSetオブジェクトとStatementオブジェクトを適切に閉じていない場合です。
SQLState: HY000
Message: [Teradata Database] : Response limit exceeded.
Vendor: 3130
このエラー メッセージは、SQLリクエストからの応答を指します。これは、単文SQLリクエストまたは複文SQLリクエストからの出力です。
応答制限とは、データベースによって課せられる制限のことであり、接続ごとに、開いている応答の数が最大16個に制限されることを指します。
この問題を解決するためには、アプリケーションを調べ、アプリケーションが、finallyブロックの例外処理で、ResultSetオブジェクト、Statementオブジェクト、LOB InputStreamオブジェクト、およびLOB Readerオブジェクトが必要なくなったら必ず直ちに閉じるようコーディングされているかどうか確認します。アプリケーションがLOBを変更した場合、BlobオブジェクトおよびClobオブジェクトをfinallyブロックで解放する必要があります。
Teradata JDBC Driver 14.00.00.28以降、結果セットの保持機能CLOSE_CURSORS_AT_COMMITがサポートされるようになりました。"保持可能な"結果セットはコミットを通して開いたままであり、これがTeradata JDBC Driverのデフォルトの動作になっています。保持可能な結果セットが不要なアプリケーションは、CLOSE_CURSORS_AT_COMMIT保持機能を指定して、自動コミットまたは明示的なコミットが実行された場合にTeradata JDBC Driverが結果セットを自動的に閉じるように設定できます。詳細については、Connection.setHoldabilityメソッドを参照してください。
アプリケーションは、ResultSetオブジェクト、Statementオブジェクト、LOB InputStreamオブジェクト、およびLOB Readerオブジェクトを閉じるのにガベージ コレクションに依存できません。これは、Javaプログラミング言語が、ガベージ コレクションのタイムリー性を保証しないからです。FINALIZE_AUTO_CLOSE接続パラメータは、Teradata JDBC Driverバージョン14.00.00.08から使用できます。FINALIZE_AUTO_CLOSE接続パラメータは、ガベージ コレクション時のTeradata JDBC Driverの動作を制御します。詳細は、「データベース接続の作成」を参照してください。
Teradata JDBC Driverバージョン14.00.00.08以降、LOG=INFO接続パラメータが指定されると、Teradata JDBC Driverは、データベース エラー3130が発生した場合に、開いている未解決のすべての応答に関する情報をログに記録します。記録される情報には、開いている応答の要求番号、実行依頼の日付/時間、実行依頼元のスレッドID、SQLリクエストテキスト、および実行依頼元のコール スタックがそれぞれ含まれます。この情報は、アプリケーション開発者が、アプリケーション内のどの場所でSQLリクエストを実行依頼して、それ以降それらの要求を閉じていないかを特定するのに役立ちます。
...
2011-12-21.08:56:41.701 TERAJDBC4 INFO [Thread-8] com.teradata.jdbc.jdk6.JDK6_SQL_Connection@17757ad Response limit exceeded.Open response 11 of 16 is request number 154 submitted 2011-12-21.08:56:40.562 by [Thread-8]
SELECT * FROM MyTable ORDER BY 1
at com.teradata.jdbc.jdbc_4.ResponseTracker.notifyReceiveResponse(ResponseTracker.java:64)
at com.teradata.jdbc.jdbc_4.statemachine.StatementReceiveState.action(StatementReceiveState.java:168)
at com.teradata.jdbc.jdbc_4.statemachine.StatementController.runBody(StatementController.java:121)
at com.teradata.jdbc.jdbc_4.statemachine.StatementController.run(StatementController.java:112)
at com.teradata.jdbc.jdbc_4.TDStatement.executeStatement(TDStatement.java:373)
at com.teradata.jdbc.jdbc_4.TDStatement.executeStatement(TDStatement.java:315)
at com.teradata.jdbc.jdbc_4.TDStatement.doNonPrepExecuteQuery(TDStatement.java:303)
at com.teradata.jdbc.jdbc_4.TDStatement.executeQuery(TDStatement.java:1067)
at ...
場合によっては、ResultSetオブジェクトとStatementオブジェクトを適切に閉じていないアプリケーションを変更できないことがあります。例えば、アプリケーションがサードパーティのアプリケーションであるため、ソース コードを入手できない場合が挙げられます。
アプリケーションでLOBを使用しない場合、アプリケーションでScrollable Result Setを使用しない場合、アプリケーションでUpdatable ResultSetsを使用しない場合、アプリケーションで接続ごとに16個より多い応答を開いておく必要がある場合、回避策として接続パラメータLOB_SUPPORT=OFFを使用できます。LOB_SUPPORT接続パラメータの詳細については、「データベース接続の作成」を参照してください。
データベースは、ResultSet LOB列をLOBロケーターとしてTeradata JDBC Driverに送信します。データベースでは、LOBロケーターと連携してKeepResponseモードを使用する必要があります。
KeepResponseモードを使用しない場合、応答が次の場合にデータベースは自動的に応答を閉じます。
接続パラメータLOB_SUPPORT=OFFが指定されている場合、Teradata JDBC DriverはKeepResponseモードを使用しません。つまり、LOBを使用できません。この結果、上記の2つの状況でデータベースは自動的に応答を閉じます。これは、データベースでアプリケーションが接続ごとに開いておける上限の16個に達するのを回避するのに役立ちます。
接続パラメータLOB_SUPPORT=OFFが指定されている場合、Scrollable Result SetおよびUpdatable Result Setを使用できません。Scrollable Result SetまたはUpdatable Result Setを要求すると、データベース エラーが発生するため、例外がスローされます。
[Teradata Database] : Parcel kind or ordering is invalid.
接続パラメータLOB_SUPPORT=OFFが指定されている場合、Teradata JDBC DriverはKeepResponseモードを使用しないため、データベースのMerge Prefetch機能はStatement.setFetchSizeメソッドまたはResultSet.setFetchSizeメソッドで指定された値を無視する場合があります。
Teradata JDBC Driver 16.20.00.11以降では、classpathにterajdbc4.jarをリストする必要があります。
Teradata JDBC Driverの古いバージョンでは、classpathにterajdbc4.jarおよびtdgssconfig.jarをリストする必要があります。
com.teradata.jdbc.TeraDriverのClassNotFoundExceptionを受信した場合、classpathが設定されていない、または正しくclasspathが設定されていないことによって、terajdbc4.jarが見つからないといった問題が発生しています。terajdbc4.jarファイルはclasspathにリストされている必要があります。
Teradata JDBC Driver 16.20.00.11以降では、tdgssconfig.jarは使用されなくなり、classpathにリストされるべきではありません。
Teradata JDBC Driverの古いバージョンでは、tdgssconfig.jarがclasspathにリストされている必要があります。
"UserFile parameter null"エラーが発生した場合は、classpathが設定されていないか、またはclasspathが正しく設定されていないためにtdgssconfig.jarが見つからないことが原因の可能性があります。
次の例外のうちの1つを受信した場合、
classpathが設定されていない、または正しくclasspathが設定されていないことによって、tdgssconfig.jarが見つからないといった問題が発生しています。
classpathは以下のように多くの箇所に設定されている可能性があります(ただし、以下が全てではありません)。
DNSまたは/etc/hostsファイルで次のエントリをチェックします。
COP名の形式はdbcnameCOPnです。dbcnameの先頭にはアルファベットを指定する必要があります。
アプリケーションのパフォーマンスが非常に低下しているような場合には、次のような対処法があります。
例えば、INSERT文を何回も実行依頼するが、そのSQL文が実行依頼ごとに挿入されるデータ値が異なる場合が挙げられます。他にも、例えば、SELECT文を何回も実行依頼するが、実行依頼ごとに、WHERE句条件の比較値が異なる場合が挙げられます。
SQL文にリテラルとしてデータ値を指定し、そのSQL文が実行依頼ごとに異なるリテラル データ値に変更される場合、データベースは、毎回SQL文を構文解析してから実行します。
こうした状況では、代わりに、PreparedStatementを使用する必要があります。SQL文には、実行依頼ごとに変更されるデータ値ごとに?プレースホルダーを用意しておく必要があります。
アプリケーションは、Connection.prepareStatementメソッドを使用して、SQL文を1度プリペアーする必要があります。それぞれの実行依頼に対して、アプリケーションは、Statement.setXXXメソッドを使用してデータ値をすべてバインドし、その後、アプリケーションは、PreparedStatementを実行する必要があります。
アプリケーションは、このバインドと実行のステップを繰り返して、毎回異なるバインド データを使用できます。この手法により、パフォーマンスが大幅に向上しました。これは、データベースが必要とするSQL文の構文解析が1度だけで済み、構文解析した文を何回も繰り返し実行できるからです。
setBinaryStream、setAsciiStream、およびsetCharacterStreamの各メソッドが使用されている場合、Teradata JDBC Driverは、LOBデータを、他のバインドしたパラメータ値とは別にデータベースに送信します。この結果、LOB値は、挿入した行ごとに合計64000バイトのバインド パラメータ値というデータベース制限にカウントされません。
行ごとに小型(<= 64000バイト)のLOB値を1つ以上挿入しているPreparedStatement INSERTのパフォーマンスを向上するためには、setStringメソッドを使用して各CLOB列に値を1つバインドし、setBytesメソッドを使用して各BLOB列に値を1つバインドします。SQL INSERT文は、?パラメータ マーカーをCLOBまたはBLOBにそれぞれキャストする必要があります。
INSERT INTO MyTable(id,clob_col) VALUES(?,CAST(? AS CLOB))
prepStmt.setInt(1,id);
prepStmt.setString(2,"abc");
CAST式付きのsetBytesメソッドを使用すると、Teradata JDBC Driverは、バインドしたパラメータ値をVARBYTE値として送信します。この結果、宛先の列が、64000バイトより大きな値を保持できるBLOBであっても、この値は64000バイトに制限されます。
CAST式付きのsetStringメソッドを使用すると、Teradata JDBC Driverは、バインドしたパラメータ値をVARCHAR値として送信します。この結果、宛先の列が、64000バイトより大きな値を保持できるCLOBであっても、この値は64000バイトに制限されます。Unicodeセッション文字セット(UTF8またはUTF16)が使用されている場合や宛先の列がCHARACTER SET UNICODEに指定されている場合、データベースは、このバインドしたパラメータ値を2バイトUnicode文字に変換します。変換後の値は、64000バイトに制限されます。
この手法が有効なのは、挿入した行ごとに、バインド パラメータ値すべてで、バインドしたパラメータ値すべての合計サイズが64000バイトのデータベース制限を超えない場合に限ります。この手法を使用する必要があるのは、パフォーマンスが重要であり、LOB値を含むバインドしたパラメータ値の合計サイズが、挿入した行ごとに64000バイトを超えないと前もってわかっている場合に限ります。
この手法は、データベースによって、必要な文字セット変換がすべて実行された後、挿入した行ごとに、バインドしたパラメータ値すべてで、バインドしたパラメータ値すべての合計サイズが64000バイトのデータベース制限を超えないなどの、追加の制限を受けます。Unicodeセッション文字セット(UTF8またはUTF16)が使用されている場合や宛先の文字列がCHARACTER SET UNICODEに指定されている場合、データベースは、文字データ タイプ(CHAR、VARCHAR、CLOB)のバインド パラメータ値を2バイトUnicode文字に変換します。これらの2バイトUnicode文字は、挿入した行ごとに、バインドしたパラメータ値すべてで64000バイトのデータベース制限にカウントされます。
Teradata Database 12.0以降では、アプリケーションがResultSetタイプをResultSet.TYPE_SCROLL_INSENSITIVEにするように要求すると、Teradata JDBC Driverはカーソル位置設定を使用して現在の結果セットの最後の行に移動することによって、すばやく効率的に複文要求の次の結果にスキップできます。順方向専用の結果セットを使用している場合、同じスキップ操作を行なうには、最初にJDBCドライバが現在の結果セットのすべての行を取り出す必要があり、大幅に時間がかかる場合があります。
次のメソッドによって、TYPE_SCROLL_INSENSITIVE結果セットを返す文が作成されます。
Connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)
Connection.prepareStatement(sql, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)
Connection.prepareCall(sql, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)
これにより、時間のかかるCOP検出プロセスを回避できます。Teradata JDBC Driverは、DNS検索で返された最初のIPアドレスに接続を試行します。接続に失敗した場合には、後続のIPアドレスが使用されます。Teradata JDBC Driverの接続を使用可能なすべてのノードに分散するには、DNSラウンド ロビンを使用してください。
Linux Red Hat Advanced Server 2.1/3.0 Itaniumでは、Teradata JDBC Driver 3.2を使用するいくつかのクライアント アプリケーションの場合に、Sun Java HotSpot 64-Bit Server Virtual Machineエラー(HotSpot仮想マシン エラーID:4E4154495645294E53543F494116140E435050006F)の発生が観測されています。
このJVMエラーは、以下のシステム構成の場合に観測されます。
Linux RedHat Advanced Server 2.1/3.0 Itaniumプラットホーム上のこのHotSpot JVMエラーは、Sun Microsystemバグ レポート システムに報告されています(インシデント レビュー ID:311761)。
エラー メッセージ: [Teradata Database] : The UserId, Password or Account is invalid.
エラー コード: 8017
この例外の一般的な原因は、ユーザー、パスワード、またはアカウント情報が無効なことです。ただし、次の場合も例外が発生することがあります。
原因 |
Browser、JWT、Kerberos、またはLDAPログオン メカニズムを使用している場合、ユーザーには "logon with null password"権限がありません。 |
対処 |
"grant logon with null password"コマンドを使用してユーザーに権限を付与します。 |
原因 |
LOGMECH=LDAPが指定されていて、ユーザー名/パスワードのクレデンシャルがLOGDATAと別の接続パラメータの両方で冗長的に指定されています。 |
対処 |
LOGDATAを使用するか、別のユーザー名/パスワード パラメータを使用してLDAPを識別します。両方を同時に使用しないでください。 |
原因 |
データベースが日本語サポート モードの場合に、EBCDICバリアント セッション文字セットの1つが指定されています。また、ユーザーID、パスワード、またはアカウントがKanji文字セットで指定されています。 |
対処 |
ユーザーID、パスワード、またはアカウントがKanji文字セットで指定されている場合は、非EBCDICバリアント セッション文字セットを指定します。 |
Kerberosを適切に使用しているにもかかわらず問題が発生する場合は、次のテーブルの共通エラーに対するメッセージと対処を確認してください。
|
エラー メッセージ |
GSS Exception: No valid credentials provided (Mechanism level: Failed to find any Kerberos Ticket) |
|||
|
原因 |
kinitが実行されていません。 |
|||
|
対処 |
Java JDKのjre/binディレクトリにあるkinitプログラムを実行します。 |
|||
|
エラー メッセージ |
java.lang.SecurityException:Unable to locate a login configuration |
|||
|
原因 |
設定ファイルの指定に失敗しました。 |
|||
|
対処 |
JVMオプションの-Djava.security.auth.login.configを使用するか、適切なjava.securityファイルを変更して、構成ファイルを指定します。このための手順については、「Kerberos前提条件の合致」を参照してください。 |
|||
|
エラー メッセージ |
javax.security.auth.login.Login Exception:No Login Modules configured for com.sun.security.jgss.initiate |
|||
|
原因 |
以下の情報が、設定情報に記載されていないか、または誤って記載されています。 com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule sufficient useTicketCache=true; }; |
|||
|
対処 |
上記の情報がログイン設定情報にあることを確認します。ログイン設定の詳細については、「Kerberos前提条件の合致」を参照してください。 |
|||
|
エラー メッセージ |
javax.security.auth.login.LoginException:Pre-authentication information was invalid |
|||
|
原因 |
原因は以下の内のいずれかです。
|
|||
|
対処 |
c:/winntの設定ファイルで、有効なユーザー名とパスワードが使用されているか検証します。ユーザー名はWindowsのActive Directoryユーザーに表示されるとおりに正しく指定する必要があります。 |
|||
|
エラー メッセージ |
[Teradata Database]:Invalid password |
|||
|
原因 |
無効なパスワードは、以下の場合にKerberosのシングル サインオンを使用すると発生します。
|
|||
|
対処 |
システムのログオンとデータベース ユーザー パスワードに同じパスワードが使用されていることを確認します。Kerberosを使用せずにユーザー名とパスワードでログオンすることによって確認できます。それが原因でない場合は、データベース ユーザーが"grant logon with null password"コマンドによりシングル サインオンできるようにデータベース管理者が構成する必要があります。 |
|||
|
エラー メッセージ |
GSSException:No valid credentials provided (Mechanism level: Failed to find any Kerberos Ticket) |
|||
|
原因 |
-Djavax.security.auth.useSubjectCredsOnly=falseを指定しませんでした。 |
|||
|
対処 |
-Djavax.security.auth.useSubjectCredsOnly=falseをアプリケーションを実行するスクリプトに追加します。 |
|||
|
エラー メッセージ |
KrbException:Invalid option setting in ticket request.(101) (Mechanism level: Failed to find any Kerberos Ticket) |
|||
|
原因 |
kinitは、"-f"またはforwardableオプションを使用して実行されませんでした。 |
|||
|
対処 |
forwardableオプションを設定した状態で、Java JDKの"jre/bin"ディレクトリにあるkinitプログラムを実行します。例: kinit -f |
|||
|
エラー メッセージ |
GSSException: Invalid name provided (Mechanism level: Could not load configuration file C:\Documents and Settings\Administrator\WINDOWS\krb5.ini (The system can not find the file specified)) |
|||
|
原因 |
Microsoft Windowsを使用していて、ターミナル サービスが有効な場合は、検索対象のkrb5.iniファイルの場所が変更された可能性があります。 |
|||
|
対処 |
krb5.iniファイルをc:\winntに維持したい場合は、Javaプログラム |
|||
|
エラー メッセージ |
GSSException: Defective token detected (Mechanism level: AP_REP token id does not match!) |
|||
|
原因 |
コンピュータのクロック同期の問題が原因の可能性があります。デフォルトの許容クロック スキュー値は、通常5分です。 |
|||
|
対処 |
関与するシステムのシステム時間を確認します。それらのシステムの時間を同期します。 |
|||
|
エラー メッセージ |
The security of this connection may be compromised because a missing token was discovered during decryption |
|||
|
原因 |
次の行がkrb5.confファイルの [libdefaults] エントリにない場合、このエラーがLinuxクライアントで発生する可能性があります。
default_tkt_enctypes = arcfour-hmac rc4-hmac |
|||
|
対処 |
上記のようにdefault_tkt_enctypesおよびdefault_tgs_enctypesを、krb5.confファイルの[libdefaults]エントリの下に追加します。 |
|||
LDAPは、z/OSからのTeradata JDBC Driverログオンをサポートしていません。
LDAPメカニズムを使用してログオンしようとすると、(URLまたはDataSourceを使用して設定した) LOGDATAパラメータに有効な情報が指定されていても、SQLExceptionとなり、次のエラーが表示されます。
SQLState:28000 Error code:8017
Message: [Teradata Database]:The UserId, Password or Account is invalid.
JDBC FastLoadの実行中にSQLExceptionが起こった場合、一連のSQL例外の一部である場合があります。SQLExceptionの原因の全体像を把握するには、一連のSQL例外全体を辿る必要があります。
同様に、JDBC FastLoadの実行中にSQLWarningが起こった場合、一連のSQL警告の一部である場合があります。SQLWarningの原因の全体像を把握するには、一連のSQL警告の全体を辿る必要があります。
例：
try {
PreparedStatement pstmt = con.prepareStatement("INSERT INTO ...");
try {
SQLWarning w = con.getWarnings();
while (w != null) {
StringWriter sw = new StringWriter();
w.printStackTrace(new PrintWriter(sw, true));
System.out.println("SQL State = " + w.getSQLState() +
", Error Code = " + w.getErrorCode() +
"\n" + sw.toString());
w = w.getNextWarning();
}
// using JDBC FastLoad
w = pstmt.getWarnings();
} finally {
pstmt.close();
}
} catch (SQLException e) {
while (e != null) {
StringWriter sw = new StringWriter();
e.printStackTrace(new PrintWriter(sw, true));
System.out.println("SQL State = " + e.getSQLState() +
", Error Code = " + e.getErrorCode() +
"\n" + sw.toString());
e = e.getNextException();
}
}
JDBC FastLoadの使用中、データ エラーに関する詳細は、上記の一連のSQL例外に含まれる場合があります。データ エラーの詳細の中には、非常に長いものがあります。これらは、「JDBC FastLoad使用時の考慮事項」に記載している2つの一時エラーテーブルのいずれかで示しています。2つの一時エラーテーブルの形式の詳細については、『Teradata FastLoadリファレンス』の「エラーテーブルの形式」セクションを参照してください。
なぜJDBC FastLoadがアクティブでなかったかに関する情報は、接続のSQLWarningにあります。これは、場合によっては一連のSQL警告に含まれています。SQLWarningの原因の全体像を把握するには、一連のSQL警告の全体をスクロール必要があります。
なぜJDBC FastLoadがアクティブでなかったかに関する情報は、URL接続文字列でLOG=INFOと指定することによっても取得できます。結果のLOG出力で"FastLoad "(FastLoadの後のスペースに注意)を検索してください。同じ検索は、JDBC FastLoadがアクティブであったかどうかを知るためにも利用できます。
以下は、JDBC FastLoadがアクティブでなかったことを示すLOG出力のサンプルです。
Cannot FastLoad because statement is NOT an INSERT!
以下は、JDBC FastLoadがアクティブであったことを示すLOG出力のサンプルです。
FastLoad found 2 AMP(s) in anmpc2 and created 2 FastLoadConnection(s) and 2 FastLoadPreparedStatement(s) with SESSIONS=8.
JDBC FastExportの実行中にSQLExceptionが起こった場合、一連のSQL例外の一部である場合があります。SQLExceptionの原因の全体像を把握するには、一連のSQL例外全体を辿る必要があります。同様に、JDBC FastExportの実行中にSQLWarningが起こった場合、一連のSQL警告の一部である場合があります。SQLWarningの原因の全体像を把握するには、一連のSQL警告全体を辿る必要があります。
例：
try {
PreparedStatement pstmt = con.prepareStatement("SELECT ... FROM ...");
try {
// using JDBC FastExport
SQLWarning w = pstmt.getWarnings();
while (w != null) {
StringWriter sw = new StringWriter();
w.printStackTrace(new PrintWriter(sw, true));
System.out.println("SQL State = " + w.getSQLState() +
", Error Code = " + w.getErrorCode() +
"\n" + sw.toString());
w = w.getNextWarning();
}
} finally {
pstmt.close();
}
} catch (SQLException e) {
while (e != null) {
StringWriter sw = new StringWriter();
e.printStackTrace(new PrintWriter(sw, true));
System.out.println("SQL State = " + e.getSQLState() +
", Error Code = " + e.getErrorCode() +
"\n" + sw.toString());
e = e.getNextException();
}
}
なぜJDBC FastExportがアクティブでません かに関する情報は、接続のSQLWarningにあります。これは、場合によっては一連のSQL警告に含まれています。SQLWarningの原因の全体像を把握するには、一連のSQL警告全体を辿る必要があります。
なぜJDBC FastExportがアクティブでなかったかに関する情報は、URL接続文字列でLOG=INFOと指定することによっても取得できます。
Cannot FastExport because statement is not a SELECT!
FastExport found 2 AMP(s) in anmpc2 and created 2 FastExportConnection(s) and 2 FastExportPreparedStatement(s) with SESSIONS=8.
JDBC MonitorでSQLExceptionが起こった場合、一連のSQL例外の一部である場合があります。SQLExceptionの原因の全体像を把握するには、一連のSQL例外の全体を辿る必要があります。
同様に、JDBC MonitorでSQLWarningが起こった場合、一連のSQL警告の一部である場合があります。SQL Warningの原因の全体像を把握するには、一連のSQL警告の全体を辿る必要があります。
以下は例です。
try {
PreparedStatement pstmt = con.prepareStatement("MONITOR VERSION");
try {
//bind input values (not shown)
boolean resultSetAvailable = pstmt.execute();
//get ResultSet (not shown)
SQLWarning w = pstmt.getWarnings();
while (w != null)
StringWriter sw = new StringWriter();
w.printStackTrace(new PrintWriter(sw,true));
System.out.printIn("SQL State = " + w.getSQLState() +
", Error Code = " + w.getErrorCode() +
"\n" + sw.toString());
w = w.getNextWarning();
}
} finally {
pstmt.close();
}
} catch (SQLException e) {
while (e != null) {
StringWriter sw = new StringWriter();
e.printStackTrace(new PrintWriter(sw, true));
System.out.printIn("SQL State = " + e.getSQLState() +
", Error Code = " + e.getErrorCode() +
"\n" + sw.toString());
e = e.getNextException();
}
}
DatabaseMetaDataメソッドはデータベース データ ディクショナリ ビューに対するクエリーを作成します。データ ディクショナリ ビューに対するクエリーのパフォーマンスが遅い場合、正確な最新の統計情報が不足していることが考えられます。
データベース管理者は次のSQLコマンドを定期的に実行し、データ ディクショナリ列と索引に関する統計情報を収集することが推奨されます。
collect statistics on DBC.AccessRights column (DatabaseId)
collect statistics on DBC.AccessRights column (FieldId)
collect statistics on DBC.AccessRights column (GrantorId)
collect statistics on DBC.AccessRights column (Partition)
collect statistics on DBC.AccessRights column (Partition, UserId)
collect statistics on DBC.AccessRights column (UserId)
collect statistics on DBC.AccessRights column (UserId, DatabaseId)
collect statistics on DBC.AccessRights column (UserId, TVMId)
collect statistics on DBC.AccessRights column (TVMId)
collect statistics on DBC.AccessRights column (TVMId, DatabaseId)
collect statistics on DBC.AccessRights index (UserId, DatabaseId) -- TD 14.10以前
collect statistics on DBC.AccessRights index (UserId) -- TD 15.0以降
collect statistics on DBC.AccessRights index (TVMId) -- TD 14.10以前
collect statistics on DBC.DatasetSchemaInfo column (DatasetSchemaId) -- TD 16.0以降
collect statistics on DBC.DBase column (DatabaseId)
collect statistics on DBC.DBase column (DatabaseId, DatabaseName)
collect statistics on DBC.DBase column (DatabaseId, ZoneId) -- TD 15.0以降
collect statistics on DBC.DBase column (DatabaseName)
collect statistics on DBC.DBase column (DatabaseName, DatabaseId)
collect statistics on DBC.DBase column (DatabaseNameI)
collect statistics on DBC.DBase column (JournalId)
collect statistics on DBC.DBase index (DatabaseId)
collect statistics on DBC.Indexes column (CreateUID)
collect statistics on DBC.Indexes column (FieldId)
collect statistics on DBC.Indexes column (IndexNumber)
collect statistics on DBC.Indexes column (IndexType)
collect statistics on DBC.Indexes column (LastAlterUID)
collect statistics on DBC.Indexes column (TableId, DatabaseId)
collect statistics on DBC.Indexes column (TableId, FieldId)
collect statistics on DBC.Indexes column (TableId, IndexNumber, DatabaseId)
collect statistics on DBC.Indexes column (UniqueFlag)
collect statistics on DBC.Indexes column (UniqueFlag, CreateUID)
collect statistics on DBC.Indexes column (UniqueFlag, FieldId)
collect statistics on DBC.Indexes column (UniqueFlag, LastAlterUID)
collect statistics on DBC.Indexes index (TableId)
collect statistics on DBC.ObjectUsage column (DatabaseId) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (DatabaseId, ObjectId) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (DatabaseId, ObjectId, IndexNumber) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (FieldId) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (IndexNumber) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (ObjectId) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (ObjectId, FieldId) -- TD 14.0以降
collect statistics on DBC.ObjectUsage column (UsageType) -- TD 14.0以降
collect statistics on DBC.Owners column (OwneeId)
collect statistics on DBC.Owners column (OwnerId, OwneeId)
collect statistics on DBC.Owners index (OwnerId)
collect statistics on DBC.RoleGrants column (RoleId)
collect statistics on DBC.RoleGrants index (GranteeId)
collect summary statistics on DBC.RoleGrants -- TD 14.0以降
collect statistics on DBC.Roles column (RoleId)
collect statistics on DBC.Roles column (RoleNameI)
collect statistics on DBC.StatsTbl column (IndexNumber) -- TD 13.0以降
collect statistics on DBC.StatsTbl column (StatsType) -- TD 13.0以降
collect statistics on DBC.TempTables column (BaseTableId)
collect summary statistics on DBC.TempTables -- TD 14.0以降
collect statistics on DBC.TVFields column (CreateUID)
collect statistics on DBC.TVFields column (DatabaseId)
collect statistics on DBC.TVFields column (DatasetSchemaId) -- TD 16.0以降
collect statistics on DBC.TVFields column (FieldId)
collect statistics on DBC.TVFields column (FieldName)
collect statistics on DBC.TVFields column (FieldName, TableId)
collect statistics on DBC.TVFields column (FieldType)
collect statistics on DBC.TVFields column (LastAlterUID)
collect statistics on DBC.TVFields column (TableId)
collect statistics on DBC.TVFields column (TableId, DatabaseId)
collect statistics on DBC.TVFields column (TableId, FieldId)
collect statistics on DBC.TVFields column (TableId, FieldId, DatabaseId)
collect statistics on DBC.TVFields column (TableId, FieldName)
collect statistics on DBC.TVFields column (UDTypeId) -- V2R6.1以降
collect statistics on DBC.TVFields column (UDTName) -- V2R6.1以降
collect statistics on DBC.TVM column (CommitOpt) -- TD 12.0以降
collect statistics on DBC.TVM column (CreateUID)
collect statistics on DBC.TVM column (CreatorName)
collect statistics on DBC.TVM column (DatabaseId)
collect statistics on DBC.TVM column (DatabaseId, TVMId)
collect statistics on DBC.TVM column (LastAlterUID)
collect statistics on DBC.TVM column (TableKind)
collect statistics column (TableKind (char(1), character set latin, casespecific)) as ST_TVM_TK0 on DBC.TVM -- TD 15.0以降
collect statistics column (TableKind (char(1), character set latin, not casespecific)) as ST_TVM_TK1 on DBC.TVM -- TD 15.0以降
collect statistics on DBC.TVM column (TVMId)
collect statistics on DBC.TVM column (TVMId, TVMName)
collect statistics on DBC.TVM column (TVMName)
collect statistics on DBC.TVM column (TVMNameI)
collect statistics on DBC.TVM column (DatabaseId, TVMName)
collect statistics on DBC.TVM index (DatabaseId, TVMNameI)
collect statistics on DBC.UDFInfo column (DatabaseId)
collect statistics on DBC.UDFInfo column (DatabaseId, FunctionName)
collect statistics on DBC.UDFInfo column (FunctionId)
collect statistics on DBC.UDFInfo column (FunctionName)
collect statistics on DBC.UDFInfo column (FunctionType)
collect statistics using MaxValueLength 1 column (FunctionType, FunctionName) on DBC.UDFInfo -- TD 14.0以降
collect statistics using MaxValueLength 5 column (FunctionType, FunctionName) on DBC.UDFInfo -- TD 14.0以降
collect statistics on DBC.UDTInfo column (TypeId) -- V2R6.1以降
collect statistics on DBC.UDTInfo column (TypeKind) -- V2R6.1以降
collect statistics on DBC.UDTInfo column (TypeName) -- V2R6.1以降
注: Linuxの遅延ログオンの問題を回避するには、Teradata JDBC Driver 15.00.00.13以降にアップグレードしてください。
Linuxシステムを実行している場合、Teradata JDBC Driverを使用しているJavaアプリケーションは、数秒から数分にわたる遅延ログオン プロセスを経験することがあります。これは、Teradata JDBCへのJDBC接続のデフォルト メカニズムであるTD2メカニズムを使用している場合に生じます。原因は乱数生成に関わる下位の問題であり、次のJava Bugに説明があります。
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6202721 /dev/urandomが選択されてもSHA1PRNGが/dev/randomから読み込む
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6366924 securerandom.sourceまたはjava.security.egd、またはこの両方が1.5.0_05で機能しない
この問題が原因で、すべてのログオンが遅延するわけではありません。問題が生じないまま、問題を再現するテスト プログラムを何度も実行できる場合があります。この問題が疑われる場合は、次のJavaプログラムを実行してください。
問題がなければ、プログラムは数秒で終了します。遅延ログオンがある場合は、プログラムの実行に数分かかります。プログラムはテストの実行ごとに繰返し回数を出力するため、このような遅延はプログラムの出力に見られる一時停止で判断できます。
// This program tests to see if there are delay problems associated the
// use of SecureRandom
import java.security.SecureRandom;
import java.util.*;
import java.math.*;
class secRandomPrb {
public static void main(String args[]) throws Exception {
System.out.println();
System.out.println("Pass 1: getInstance:");
runit(true);
System.out.println();
System.out.println("Pass 2: secureRandom:");
runit(false);
}
public static void runit(boolean secRand) {
SecureRandom srand;
BigInteger x;
int ctr = 0;
try {
for (ctr = 0; ctr < 1000; ctr++) {
if (secRand == true)
srand = SecureRandom.getInstance("SHA1PRNG");
else
srand = new SecureRandom();
byte[] seed = srand.generateSeed(8);
srand.setSeed(seed);
x = new BigInteger(512, srand);
int i = x.intValue();
System.out.print(ctr + " ");
}
}
catch (Exception ex) {
System.out.println("Exception: " + ex);
}
}
}
Linuxの遅延ログオンの問題を解決する最善の方法は、Teradata JDBC Driver 15.00.00.13以降にアップグレードすることです。
Teradata JDBC Driverの古いバージョンを使用する場合は、Linuxの遅延ログオンの問題は/dev/./urandomを/dev/randomのリンクとして、またはsecurerandom.sourceとして指定することで回避できます。
これは、「コマンド ライン引数の使用 」または「/dev/randomのシンボリック リンクへの変更 」に従って実行できます。
推奨される回避策は、Java JVMを開始するコマンド ライン引数を指定する方法です。これにより、この問題が発生する可能性のあるJavaプログラムにのみ変更を加えることができます。コマンド ライン設定
-Djava.security.egd=file:/dev/./urandom
は、この問題を回避します。devとurandomの間にある余分な"."ディレクトリに注意してください。これは必須です。上記のテスト プログラムはこの設定で次のように実行できます。
java -Djava.security.egd=file:/dev/./urandom secRandomPrb
これと同じプロパティが$JAVA_HOME/jre/lib/security/java.securityファイルのセキュリティ ファイルでも使える点に注意してください。通常、java.securityファイルへの変更は同じ効果が得られるはずですが、テストからこのファイルを変更しても、問題を解決できません ことがわかっているのが、JDK 5.0を使っている場合です。
この変更にはroot権限が必要です。システムの全プログラムについて、/dev/randomの設定を変更します。rootとしてログインすれば、次のコマンドを実行できます。
mv /dev/random /dev/random.real
ln -s /dev/./urandom /dev/random
この変更がされると、遅延ログオンの問題が回避されます。上記のテスト プログラムを実行して修正されているかどうか確認してください。