Teradata JDBC Driverの使用

この章では、Javaプログラム上でTeradata JDBC Driverソフトウェアを使用する方法、およびサイトで実行されているTeradata JDBC Driverの以下の手順について説明します。

• SQLパッケージのインポートとTeradata JDBC Driverのロード
• データベース接続の作成
• COP検出
• プロキシ サーバーのサポート
• 保存されたパスワードの保護
• クライアント システムの情報
• ユーザーのSTARTUP SQLリクエスト
• Teradataセッションの再接続
• トランザクション モード
• 自動コミット
• SQLリテラルとSQLインジェクション攻撃
• JDBCエスケープ句
• クエリー バンド
• 信頼済みSQLとクエリー バンドの偽装
• 日付、時刻、タイムスタンプ値とタイムゾーン
• セッションのDateForm
• セッションのタイムゾーン
• ストアド プロシージャのTIMEとTIMESTAMP INOUTパラメータ
• 複文要求
• データベースのマクロ
• ユーザー定義関数と外部ストアド プロシージャの作成
• ユーザー定義型
• PERIODデータ タイプ
• ARRAYデータ タイプ
• XMLデータ タイプ
• NUMBERデータ タイプ
• INTERVALデータ タイプ
• JSONデータ タイプ
• DATASETデータ タイプ
• 更新可能LOB
• Integer.MAX_VALUEを超える行番号と更新件数
• マルチスレッドの問題
• DatabaseMetaDataメソッドによるデータ ディクショナリのアクセス
• Sun JDK 5.0実装のJDBC RowSetインターフェースの使用
• 暗号化、認証、許可
• 生成キー
• ParameterMetaDataとあいまいな型
• Java外部ストアド プロシージャ
• 更新可能結果セット
• ストアド プロシージャの動的結果セット
• 特殊な浮動小数点値
• PreparedStatementバッチ
• PreparedStatementのBatchUpdateException処理
• JDBC FastLoad
• JDBC FastLoad CSV
• JDBC FastExport
• JDBC Monitor
• Raw接続

SQLパッケージのインポートとTeradata JDBC Driverのロード

このセクションでは、Javaスタンドアロン アプリケーションがTeradata JDBC Driverを使用するために必要な手順をリストします。

この情報は、WebSphereやWebLogicなどのアプリケーションサーバー環境に展開されたJ2EEアプリケーションには適用されません。アプリケーション サーバーは、classpathを定義する独自のメカニズムを提供し、アプリケーション サーバーにJDBCドライバ クラスのロードの責任があります。

1. Teradata JDBC Driverのjarファイルを開発システムにダウンロードまたはコピーする必要があります。
   
   Teradata JDBC Driver 16.20.00.11以降では、下記の1つのjarファイルが必要となります。
   • terajdbc4.jar
   
   Teradata JDBC Driverの古いバージョンでは、下記の2つのjarファイルが必要となります。
   • terajdbc4.jar
   • tdgssconfig.jar
   
   
2. Teradata JDBC Driver 16.20.00.11以降では、下記の1つのjarファイルがCLASSPATHに記述されている必要があります。
   • terajdbc4.jar
   
   Teradata JDBC Driverの古いバージョンでは、下記の2つのjarファイルがCLASSPATHに記述されている必要があります。
   • terajdbc4.jar
   • tdgssconfig.jar
   
   
3. Javaプログラムの先頭付近に次の1行を挿入します。

   import java.sql.*;

4. 次の文を使用して、Teradata JDBC Driverをロードし、登録します。

   Class.forName("com.teradata.jdbc.TeraDriver");

データベース接続の作成

Javaプログラムからデータベースにアクセスする場合は、java.sql.DriverManager.getConnectionメソッドを使用して、DriverManagerから新しいjava.sql.Connectionオブジェクトを取得します。

java.sql.DriverManager.getConnectionメソッドでは、引数としてURL文字列を使用します。URL文字列によって、データベースが識別されます。DriverManagerは、URLの接頭辞"jdbc:teradata://"を使用してConnectionオブジェクトにTeradata JDBC Driverを選択します。

次に示す表は、Teradata JDBC Driverの接続URLパラメータと値の一覧です。Teradata JDBC Driver 16.00.00.28以降では、Teradata JDBC DriverはURL接続パラメータを検証して、無効なパラメータ名および無効な値にSQLExceptionをスローします。

データ ソースのインターフェース

アプリケーション サーバーを使用する場合、java.sql.Connectionを取得するためには、java.sql.DataSourceインターフェースを使用することを推奨します。

DataSourceを使用すると、論理名を持つ1つのオブジェクト内でデータベース接続の取得に関係するすべてのパラメータをカプセル化できます。パラメータのカプセル化ができると、Teradata1というような論理名への接続を要求するだけでよいので、この要求を満たすために必要な多数のパラメータを知らなくても接続ができるようになります。

DataSourceは、使用する前に作成する必要があります。DataSource作成のジョブは、通常はシステム管理者が実行します。Driver Manager URLに関連するパラメータをDataSourceオブジェクト内に設定し、この設定をファイルまたはネットワーク接続可能なリソースとして保存します。

これらのパラメータの名前は、大文字/小文字の区別を含め、URLで使用される名前と同一にする必要があります。例えば、CHARSETを使用して文字セット プロパティを設定した場合、CharSet、CHARSet、またはCHARSEtは違う設定と見なされます。さらに、dataSourceName、description、user、およびpasswordの各プロパティはDataSourceレベルでのみ利用できます。Teradata JDBC Driver 16.00.00.28以降、Teradata JDBC Driverはデータ ソースのプロパティ値を検証して、無効なパラメータ値にSQLExceptionをスローします。

詳細は、TeraDataSourceクラスを参照してください。

DataSourceには、Java Naming and Directory Interface(JNDI)を使用してアクセスします。詳細については、http://www.oracle.com/technetwork/java/jndi/を参照してください。

プール接続では、不要になった接続は閉じてください。そのままでは、接続は接続プールに戻りません。プール接続を使用する場合は、接続を確実に閉じるために、try/catchブロックの後にfinallyブロックを設けることを推奨します。

セッション属性に関する警告

データベースでは、セッションの属性をリセットする方法を提供していません。したがって、接続プールのデータ ソースを使用する場合は、セッション属性に影響を及ぼすコマンドを使用しないでください。セッション属性への変更はすべて、次にその接続を使用するユーザーに引き続き適用されます。

変更してはいけないセッション属性には、次のようなものがあります。

• データベース(DATABASEコマンドまたはSET SESSION DATABASEコマンド)
• 照合(SET SESSION COLLATIONコマンド)
• 日付フォーマット(SET SESSION DATEFORMコマンド)
• タイムゾーン(SET TIME ZONEコマンド)
• デフォルトの日付フォーマット
• セッション クエリー バンド(SET QUERY_BAND ... FOR SESSIONコマンド。Teradata Database 12.00.00で導入)

  注:  SET QUERY_BAND ...FOR SESSIONの代わりにSET QUERY_BAND … FOR TRANSACTIONコマンドを使用することを推奨します。これは、SET QUERY_BAND …FOR TRANSACTIONのスコープが現在のトランザクションに制限されるからです。

COP検出

COP=ON接続パラメータが指定されている場合、またはCOP接続パラメータが省略されている場合、Teradata JDBC DriverでCOP(通信プロセッサ)検出動作を使用できます。

データベース システムを複数のデータベース ノードで構成できます。データベースGatewayプロセスを実行するように1つまたは複数のデータベース ノードを構成できます。データベースGatewayプロセスを実行する各データベース ノードは、COP(通信プロセッサ)と呼ばれます。COP検出は、使用可能なすべてのCOPホスト名とそのIPアドレスを識別する手順のことです。COPホスト名は、DNSに定義するか、またはクライアント システムのhostsファイルに定義できます。COPホスト名をクライアント システムのhostsファイルではなくDNSに定義することを強く推奨します。COPホスト名をDNSに定義すると、一元管理を実現でき、データベースを再構成するときにCOPホスト名を一元的に変更できます。

Teradata JDBC Driver 16.00.00.28以降では、COPLAST接続パラメータを使用して、COP検出で最後のcopホスト名を特定する方法を指定します。接続パラメータCOPLAST=OFFと指定するか、COPLAST接続パラメータを省略するか、またはCOP=OFF接続パラメータでCOP検出を無効にすると、Teradata JDBC Driverはcoplastホスト名のDNS検索を実行しません。

JDBC Driver 16.00.00.28以降では、接続パラメータCOPLAST=ONと指定して、COP検出を有効にすると、Teradata JDBC Driverはまず、COP検出を実行する前に、coplastホスト名のDNS検索を実行して最後のCOPホスト名のIPアドレスを取得します。その後、COP検出中に、不明のCOPホスト名が検出されるか、IPアドレスがcoplastホスト名のIPアドレスと一致するCOPホスト名が検出されると、Teradata JDBC DriverはCOPホスト名の検索を停止します。

• COPLAST=ONとすると、DNS検索失敗の応答が遅い場合に、DNSのパフォーマンスを向上できます。
• DNS検索失敗が返されない場合は、COPLAST=ONとする必要があります。

COP検出の実行時に、Teradata JDBC Driverは、データベースのホスト名にcop1が追加されたものから開始し、cop2、cop3、...、copNの順番で進みます。Teradata JDBC Driverは、COP検出およびcoplastホスト名のドメイン名修飾をサポートしています。DNS検索接尾辞の不要なDNS検索が回避されてパフォーマンスが向上するため、ドメイン名修飾を使用することを推奨します。

次の表に、仮定の3ノード データベース システム"whomooz"で実行されるDNS検索を示します。

Teradata JDBC Driverは、COPホスト名と非COPホスト名に対して複数のIPアドレスの定義をサポートしています。Teradata JDBC Driverは、Java APIメソッドInetAddress.getAllByNameを呼び出して各ホスト名に定義されているすべてのIPアドレスを取得します。

特定のデータベース システムに初めて接続する場合、Teradata JDBC Driverは乱数を生成してCOPのリストに索引を付けます。その後の接続では、Teradata JDBC Driverは先頭に戻るまで保存した索引を増やしていきます。この動作は検出されたCOPすべてに負荷を分散します。

ダウンしたCOPへの接続失敗はTeradata JDBC Driverによってマスクされるため、ほとんどの接続失敗はクライアント アプリケーションには隠蔽されます。すべてのCOPがそのデータベースでダウンした場合にのみ、例外がアプリケーションにスローされます。COPがダウンすると、シーケンスの次のCOP(最初のCOPへのラップを含む)が、ダウンしたCOPが受けるはずだった接続を追加で受信します。COPのDNSに複数のIPアドレスが定義されている場合、Teradata JDBC DriverはCOPの各IPアドレスへの接続を試行し、COPのすべてのIPアドレスへの接続試行が失敗した場合のみ、COPはダウンしていると見なされます。

COP検出を無効にするか、COPホスト名がDNSに定義されていない場合、Teradata JDBC Driverは接続URLに指定されているデータベース ホスト名に直接接続します。これにより、COP検出以外の負荷分散スキーマが可能になります。例えば、ラウンド ロビン方式のDNSやTCP/IPの負荷分散製品を使用できます。COP検出は、単純なデータベース ホスト名検索に優先します。別の負荷分散スキーマを使用するには、COPホスト名をDNSに定義しないか、あるいはCOP=OFF接続パラメータを指定します。

InetAddressのキャッシュ

DNS検索はJVMでキャッシュされ、Teradata JDBC DriverはDNS名解決のキャッシュを管理しません。管理者は、キャッシュ制御用の標準JVMシステム プロパティをInetAddressクラスのjavadocの定義どおり使用できます。

InetAddressクラスは、成功および不成功の両方のホスト名解決をキャッシュします。ポジティブ キャッシュではDNSスプーフィング攻撃から防御され、ネガティブ キャッシュではパフォーマンスが向上します。

デフォルトでは、キャッシュのエントリを削除する安全な時期を決定する一般的なルールがないため、成功したホスト名解決の結果は永遠にキャッシュされます。ホスト名解決が失敗した場合の結果は、パフォーマンスの向上のために短時間(10秒)だけキャッシュされます。

DNSの不正アクセスによる攻撃が不可能と判定できる特定の環境では、Javaセキュリティ プロパティをポジティブ キャッシュの別の有効期間(TTL)値に設定することができます。同様に、システム管理者は必要に応じて別のネガティブ キャッシュTTL値を設定できます。2つのJavaセキュリティ プロパティにより、ポジティブおよびネガティブのホスト名解決のキャッシュに使用するTTL値を制御します。

ネーム サービスで成功したネーム参照のキャッシュ ポリシーを示します。成功した参照をキャッシュする秒数を示す整数値を指定します。

値-1は、永遠にキャッシュすることを示します。

ネーム サービスで成功しなかったネーム参照のキャッシュ ポリシーを示します。成功しなかった参照をキャッシュする秒数を示す整数値を指定します。

値0は、キャッシュしないことを示します。

値-1は、永遠にキャッシュすることを示します。

プロキシ サーバーのサポート

プロキシ サーバーのサポートは、Teradata JDBC Driver 20.00.00.12以降で使用できます。

次の表は、ドライバによって行われる各種類のネットワーク接続の一覧と、プロキシ サーバーを指定するために使用できるオプションを示しています。

最も高い優先度

接続パラメータを使用して、HTTPS接続のプロキシ サーバーを指定できます。これらの接続パラメータは、HTTPS接続のプロキシ サーバー設定を決定する際に最も優先度が高くなります。

特に、プロキシ サーバーを指定する接続パラメータは、Javaシステムのプロキシ サーバー設定よりも優先度が高くなります。

プロキシ サーバーの接続パラメータが指定され、その接続の種類に適用可能な場合、JDBCドライバは指定された接続パラメータのプロキシ サーバー設定を接続に使用します。

それ以外の場合、プロキシ サーバーの接続パラメータが指定されていないか、接続の種類に適用できない場合、JDBCドライバは接続に優先度の低いプロキシ サーバー設定を使用します。

たとえば、PROXY_BYPASS_HOSTSでは、データベースCOPホスト名ワイルドカードを指定して、データベースへのHTTPS接続にはプロキシ サーバーをバイパスし、他のHTTPS接続にはプロキシ サーバーを使用できます。

2番目に高い優先度

Javaシステムのプロキシ サーバーの設定は2番目に高い優先度であり、接続パラメータのプロキシ サーバー設定よりも優先度が低くなります。

データベースへのHTTPS接続およびアイデンティティプロバイダのエンドポイントへのHTTPS接続の場合:

• Javaシステムのプロパティ https.proxyHost ではプロキシ サーバーのホスト名を指定します。
• Javaシステムのプロパティ https.proxyPort ではプロキシ サーバーのポート番号を指定します。

アイデンティティプロバイダのエンドポイントへのHTTP接続、およびCRLおよびOCSP 証明書失効チェックのHTTP接続の場合:

• Javaシステムのプロパティ http.proxyHost ではプロキシ サーバーのホスト名を指定します。
• Javaシステムのプロパティ http.proxyPort ではプロキシ サーバーのポート番号を指定します。

HTTPSおよびHTTP Javaシステムのプロキシ サーバー設定を一緒に指定できます。

Javaシステムのプロパティhttp.nonProxyHostsは、Javaシステムのプロパティhttps.proxyHostおよびhttp.proxyHostで識別されるプロキシ サーバーをバイパスするために、ホスト名とアドレスの一致パターンをオプションで指定します。同じプロパティhttp.nonProxyHostsが HTTPSとHTTPの両方で使用されます。

• 複数のホスト名とアドレスは縦棒 | 文字で区切ります。ワイルドカード文字としてアスタリスク * を指定します。
• このパラメータを省略した場合、デフォルトのパターンはlocalhost|127.*|[::1]で、一般的なループバック アドレスのバリエーションに対して、https.proxyHostおよび/またはhttp.proxyHostで識別されるプロキシ サーバーをバイパスします。

たとえば、http.nonProxyHostsでデータベースCOPホスト名ワイルドカードを指定すると、データベースへのHTTPS接続にはプロキシ サーバーをバイパスし、他の種類の接続にはプロキシ サーバーを使用できます。

3番目に高い優先度

他のJavaシステムのプロキシ サーバー設定を指定せずに、Javaシステムのプロパティjava.net.useSystemProxies=trueが指定されている場合、オペレーティング システムのプロキシ サーバー設定が使用されます。

Javaシステムのプロパティ java.net.useSystemProxies は、WindowsとmacOSでのみ使用できます。

Javaプロキシの優先順度の動作は、OpenJDKファイルsrc/java.base/share/conf/net.propertiesに記載されています。 "プロキシを明示的に設定するシステム プロパティ(http.proxyHostなど)は、java.net.useSystemProxiesがtrueに設定されている場合でも、システム設定よりも優先されることに注意してください。"

最も低い優先度

Javaシステムのプロキシ サーバー設定が指定されていないか、接続の種類に適用できない場合は、直接接続が行われ、プロキシ サーバーは使用されません。

保存されたパスワードの保護

概要

Teradata JDBC Driver Stored Password Protectionによりアプリケーションでは、JDBC接続パスワードを暗号化形式でTeradata JDBC Driverに送信することができます。またアプリケーションでは、NEW_PASSWORD接続パラメータの値も暗号化形式で送信することができます。

Stored Password Protectionは、Teradata JDBC Driver 16.00.00.24以降で使用できます。

アプリケーションでは、以下に示すようにいくつかの方法でTeradata JDBC Driverに対してパスワードを指定することができ、それらのすべてで暗号化パスワードを使用できます。

1. DriverManager.getConnection(String,String,String)メソッドに対する3番目の引数としてログイン パスワードを指定する。
2. DriverManager.getConnection(String,Properties)メソッドに対する"password"プロパティとしてログイン パスワードを指定する。
3. DriverManager.getConnection(String)メソッドでPASSWORD接続URLパラメータとしてログイン パスワードを指定する。
4. DriverManager.getConnectionメソッドの変則形のいずれかのLOGDATA接続URLパラメータ内でログイン パスワードを指定する。
5. DataSourceまたはConnectionPoolDataSourceパスワード パラメータとしてログイン パスワードを指定する。
6. DataSourceまたはConnectionPoolDataSource LOGDATAパラメータ内でログイン パスワードを指定する。
7. DriverManager.getConnectionメソッドの変則形のいずれかでNEW_PASSWORD接続URLパラメータとして新しいパスワードを指定する。
8. DataSourceまたはConnectionPoolDataSource NEW_PASSWORDパラメータとして新しいパスワードを指定する。
9. DriverManager.getConnectionメソッドのバリアントを使用して、SSLTRUSTSTORE_PASSWORD接続のURLパラメータとして指定された新しいパスワード。
10. DataSourceまたはConnectionPoolDataSource SSLTRUSTSTORE_PASSWORDパラメータとして指定された新しいパスワード。

ただし、指定するパスワードが接頭辞"ENCRYPTED_PASSWORD("で始まる場合は、指定するパスワードの形式を次のようにする必要があります。

   ENCRYPTED_PASSWORD(PasswordEncryptionKeyResourceName,EncryptedPasswordResourceName)

PasswordEncryptionKeyResourceNameは、1つのカンマでEncryptedPasswordResourceNameと区別する必要があります。

PasswordEncryptionKeyResourceNameにより、パスワードの暗号化キーと関連情報が格納されているリソースの名前を指定します。EncryptedPasswordResourceNameにより、暗号化パスワードと関連情報が格納されているリソースの名前を指定します。その2つのリソースの説明を以下に示します。

PASSWORD、NEW_PASSWORD、SSLTRUSTSTORE_PASSWORD、LOGDATA接続のURLパラメータに暗号化されたパスワードが指定されている場合は、値を一重引用符で囲み、リソース名の"ENCRYPTED_PASSWORD("構文のコンマ区切り文字を囲む必要があります。そうしないと、そのカンマが次の接続URLパラメータの区切り文字として解釈されます。

TJEncryptPasswordプログラム

TJEncryptPassword.javaは、Teradata JDBC Driver Stored Password Protectionで使用する暗号化パスワード ファイルを作成するためのサンプル プログラムです。

このプログラムは、Teradata JDBC Driver Stored Password Protectionと連携動作します。このプログラムにより、パスワード暗号化キーと暗号化パスワードを保存したファイルが作成されます。ファイルはその後、"ENCRYPTED_PASSWORD("構文を使用してTeradata JDBC Driverに対して指定できます。

パスワード暗号化キーと暗号化パスワードを保存したファイルを作成するためにこのプログラムを使用する必要はありません。独自のファイルを開発して必要なファイルを作成することができます。唯一の要件は、ファイルの形式が、以下に示すTeradata JDBC Driverで予期される形式と一致する必要があることです。

このプログラムは、パスワードを暗号化すると、そのパスワードを正常に復号化できることを確認するため、その後すぐに復号化します。このプログラムは、Teradata JDBC Driverのパスワード復号化の実装方法を模倣しており、その動作をオープンに示し、コミュニティによってセキュリティを有効にすることを意図されています。

暗号化パスワードは、その2つのファイルがある場合にのみ安全です。ユーザーには、パスワード暗号化キーと暗号化パスワードを保存したファイルへのアクセスを制限する責任があります。攻撃者は、両方のファイルを取得すれば、パスワードを復号化できます。それら2つのファイルに対するオペレーティング システムのファイル アクセス権は、可能な限り制限して絞り込み、意図されたオペレーティング システムのユーザーIDに対してのみファイルへのアクセス権が付与されるようにします。

2つのファイルは、別々の物理ボリュームに保存して、両方のファイルを同時に失う危険性を低減することができます。ファイルの一方または両方がネットワーク ボリューム上に格納されている場合は、sshfs、暗号化NFSv4、または暗号化SMB 3.0などの暗号化ワイヤー プロトコルを使用してネットワーク ボリュームにアクセスすることができます。

• Stored Password Protectionをsshfsで使用する方法
• Stored Password Protectionを暗号化されたNFSv4で使用する方法
• Stored Password Protectionを暗号化されたSMBで使用する方法

このプログラムは、8個のコマンドライン引数を受け入れます。

TJEncryptPasswordを使用する場合の前提条件

Teradata JDBC Driverサンプル プログラムのダウンロード、コンパイル、および実行方法のすべてについてはここで説明されています。

以下の一覧に、TJEncryptPasswordプログラムを使用する場合に必要な準備操作のサマリーを示します。

• サポートされているJDKをダウンロードして開発システムにインストールします。
• Teradata JDBC Driverをダウンロードします。
• samples.jarをダウンロードします。
• すべてのファイルを抽出します: jar xvf samples.jar
• コンパイルします: javac TJEncryptPassword.java

コマンド例

以下のコマンドでは、samples.jarから抽出されたファイル、コンパイルされたクラス ファイル、およびTeradata JDBC Driverのjarファイルのすべてが現在のディレクトリに格納されていると想定しています。現在のディレクトリはclasspathで指定する必要があります。

TJEncryptPasswordプログラムでは、Teradata JDBC Driverを使用し、指定されたデータベースに暗号化パスワードでログオンするため、TJEncryptPasswordプログラムには、classpath上のTeradata JDBC Driverのjarファイルへのアクセス権が必要です。

Teradata JDBC Driver 16.20.00.11以降では、classpathに現在のディレクトリとterajdbc4.jarがリストされている必要があります。

• Windowsでは、セミコロン分離記号を使用してclasspathを指定する必要があります。java -cp .;terajdbc4.jar
• 他のすべてのプラットフォームでは、コロン分離記号を使用してclasspathを指定する必要があります。java -cp .:terajdbc4.jar

Teradata JDBC Driverの古いバージョンでは、classpathに現在のディレクトリ、 terajdbc4.jar、およびtdgssconfig.jarをリストする必要があります。

• Windowsでは、セミコロン分離記号を使用してclasspathを指定する必要があります。java -cp .;terajdbc4.jar;tdgssconfig.jar
• 他のすべてのプラットフォームでは、コロン分離記号を使用してclasspathを指定する必要があります。java -cp .:terajdbc4.jar:tdgssconfig.jar

以下のコマンド例は、JCE Unlimited Strength Jurisdiction Policy Filesで使用可能な256ビットAESキーと、JDK 5から使用可能になったHmacSHA256アルゴリズムを使用して、WindowsでTJEncryptPasswordプログラムを実行する方法を示しています。

以下のコマンド例は、JCE Unlimited Strength Jurisdiction Policy Filesが欠落している場合のデフォルトのAESキー サイズと、JDK 5から使用可能になったHmacSHA256アルゴリズムを使用して、WindowsでTJEncryptPasswordプログラムを実行する方法を示しています。

以下のコマンド例は、JDK 1.4.2で使用可能なHmacSHA1アルゴリズムを使用して、WindowsでTJEncryptPasswordプログラムを実行する方法を示しています。

パスワード暗号化キーのファイル形式

パスワード暗号化キーと暗号化パスワードを保存したファイルを作成するためにTJEncryptPasswordプログラムを使用する必要はありません。独自のファイルを開発して必要なファイルを作成することができますが、ファイル形式はTeradata JDBC Driverで予期される形式と一致する必要があります。

パスワード暗号化キー ファイルは、Java Propertiesファイル形式のテキスト ファイルで、ISO 8859-1文字エンコーディングを使用します。

ファイルには、以下の文字列プロパティが保存されている必要があります。

暗号化パスワード ファイル形式

暗号化パスワード ファイルは、Java Propertiesファイル形式のテキスト ファイルで、ISO 8859-1文字エンコーディングを使用します。

ファイルには、以下の文字列プロパティが保存されている必要があります。

変換、キー サイズ、およびMAC

変換は、指定された入力で実行され、変換された出力を生成する操作のセットを記述した文字列です。

変換には常に、DESやAESなどの暗号アルゴリズムの名称が含まれ、オプションでフィードバック モードと埋め込みスキーマが続きます。

javax.crypto.CipherのJDK 7 javadocは、すべてのJava実装で以下の変換をサポートする必要があることを示します。

Teradata JDBC Driver Stored Password Protectionでは、DESやAESなどの対称暗号化アルゴリズムを使用し、パスワードの暗号化と復号化で同じ秘密鍵が使用されます。Teradata JDBC Driver Stored Password Protectionでは、公開鍵と秘密鍵が別々にあるRSAなどの非対称暗号化アルゴリズムを使用しません。

• ECB(Elextronic Codebook)は最も単純なブロック サイファー暗号化モードです。入力がブロックに分割され、各ブロックが別々に暗号化されます。ECBは、合計バイト数がアルゴリズムのブロック サイズより大きい暗号化データの場合には不適切であり、したがってTeradata JDBC Driver Stored Password Protectionでの使用にも適していません。
• CBC(暗号ブロック連鎖)は、より複雑なブロック サイファー暗号化モードです。CBCでは、各サイファーテキスト ブロックが、その時点までに処理されたすべてのプレーンテキスト ブロックに依存します。CBCは、合計バイト数がアルゴリズムのブロック サイズより大きい暗号化データの場合に適切であるため、Teradata JDBC Driver Stored Password Protectionでの使用にも適しています。

Teradata JDBC Driver Stored Password Protectionは、末尾にNULLバイトを追加してUTF-8エンコード パスワードの長さを拡張することによって、暗号化パスワード ファイルでのパスワードの長さを隠します。この長さは、次の512バイト境界まで拡張されます。

• AES/CBC/NoPaddingなどの埋め込みなしのブロック サイファーは、拡張後のバイト数がアルゴリズムのブロック サイズの倍数になっている場合にのみ使用できます。512バイト境界は、多くのブロック サイファーに適合させることができます。例えば、AESのブロック サイズは128ビット(16バイト)であり、したがって512バイト境界に適合します。
• AES/CBC/PKCS5Paddingなどの埋め込みありのブロック サイファーは、任意の長さのデータの暗号化に使用できます。ただし、埋め込みありのCBCは「パディング オラクル攻撃」に対して脆弱なため、Teradata JDBC Driver Stored Password Protectionは、パディング オラクル攻撃から保護するためEncrypt-then-MACを実行します。MACアルゴリズムHmacSHA256はJDK 5以降で使用できます。MACアルゴリズムHmacSHA1はJDK 1.4.2で使用できます。
• ブロック サイファーでは、CFB(Cipher Feedback)やOFB(Output Feedback)などのモードを使用する場合には、サイファーの実際のブロック サイズよりも小さい単位でデータを暗号化できます。ブロック サイファーは、CFB8またはOFB8などの8ビット モードを指定することによってバイト指向サイファーとして使用することができるため、AES/CFB8/NoPaddingなどの変換を使用して任意の長さのデータを暗号化することができます。

暗号化の強度は、選択するサイファー アルゴリズムとキー サイズによって決まります。

• AESでは、128ビット(16バイト)、192ビット(24バイト)、または256ビット(32バイト)のキーを使用します。KeyGenerator.initメソッドのキーサイズ引数として、128、192、または256と指定します。192ビットまたは256ビット キーのAESを使用するには、OracleからJava Cryptography Extension(JCE) Unlimited Strength Jurisdiction Policy FilesをダウンロードしてJREにインストールする必要があります。
• DESedeでは、実質的には112ビットまたは168ビットのキーとなる192ビット(24バイト)キーを使用します。KeyGenerator.initメソッドのキーサイズ引数として、112または168と指定します。

リソース名

TJEncryptPasswordプログラムには、ファイル名を指定するためのコマンドラインPasswordEncryptionKeyFileNameおよびEncryptedPasswordFileNameがあります。

それとは対照的に、Teradata JDBC Driverの"ENCRYPTED_PASSWORD("構文では、ファイルの保存場所とアクセスの柔軟性を高めるため、ファイル名ではなくリソース名を使用します。

   ENCRYPTED_PASSWORD(PasswordEncryptionKeyResourceName,EncryptedPasswordResourceName)

TJEncryptPasswordプログラムによって作成されたファイルは、その後リソースとしてTeradata JDBC Driverからアクセスされます。リソース名には、リソースへの必要なアクセス方法を示す接頭辞が含まれています。リソース名が"classpath:"接頭辞で始まる場合、Teradata JDBC Driverはclasspathからリソースをロードします。"classpath:"接頭辞を付けてリソース名を指定する場合は、Teradata JDBC Driverのclasspathに確実にリソースを含める必要があります。

セキュリティ上の理由により、classpathリソースには特定のリソース名接頭辞を含める必要があります。PasswordEncryptionKeyResourceNameは"PassKey"で始める必要があり、EncryptedPasswordResourceNameは"EncPass"で始める必要があります。

例:

   ENCRYPTED_PASSWORD(classpath:PassKeyJohnDoe.properties,classpath:EncPassJohnDoe.properties)

リソース名が"classpath:"以外の接頭辞で始まる場合、Teradata JDBC Driverはnew URL(resourcename).openStream()メソッドを介してリソースをロードします。classpath以外のリソースの場合には、特定のリソース名接頭辞を含める必要はありません。Teradata JDBC Driverからclasspath以外のリソースに確実にアクセスできるようにしておく必要があります。

リソース名は"file:"接頭辞で始めることができ、relative-pathnameファイルからリソースをロードするにはTeradata JDBC Driverの相対パス名を指定する必要があります。

現在のディレクトリにあるファイルでの例:

   ENCRYPTED_PASSWORD(file:JohnDoeKey.properties,file:JohnDoePass.properties)

相対パスでの例:

   ENCRYPTED_PASSWORD(file:../dir1/JohnDoeKey.properties,file:../dir2/JohnDoePass.properties)

リソース名は"file:"接頭辞で始めることができ、absolute-pathnameファイルからリソースをロードするにはTeradata JDBC Driverの絶対パス名を指定する必要があります。

Windows上の絶対パスでの例:

   ENCRYPTED_PASSWORD(file:c:/dir1/JohnDoeKey.properties,file:c:/dir2/JohnDoePass.properties)

Linux上の絶対パスでの例:

   ENCRYPTED_PASSWORD(file:/dir1/JohnDoeKey.properties,file:/dir2/JohnDoePass.properties)

Teradata JDBC Driverのアクション

1つの暗号化パスワードに指定されている2つのリソース名は、Teradata JDBC Driverからアクセスすることができ、上記のプロパティのファイル形式に従っている必要があります。リソース名が"classpath:"接頭辞で始まっていても、classpathにリソースが含まれていないと、Teradata JDBC DriverはSQLExceptionをスローします。またTeradata JDBC Driverは、classpath以外のリソースにアクセスできない場合にもSQLExceptionをスローします。Teradata JDBC Driverは、リソースが必須のプロパティ ファイル形式に従っていない場合にSQLExceptionをスローします。

Teradata JDBC Driverは、2つのリソースに一致値が存在し、相互に一致することを確認します。Teradata JDBC Driverは、一致値が相互に異なる場合にSQLExceptionをスローします。一致値は2つの指定リソースが相関することを確認するために比較され、そのようにして構成エラーを防止するための"正常性チェック"が行われます。TJEncryptPasswordプログラムでは、共有一致値としてタイムスタンプを使用しますが、タイムスタンプは不要です。すべての共有文字列を一致値として使用することができます。タイムスタンプはどのような点でもパスワードの暗号化との関連がなく、タイムスタンプを使用してパスワードを復号化することはできません。

復号化後、Teradata JDBC Driverは、サイファーテキスト、変換名、およびアルゴリズム パラメータがある場合にはそのパラメータを使用してMACを計算し、計算されたMACが予期されるMACと一致するかどうか確認します。Teradata JDBC Driverは、計算されたMACが予期されるMACと異なる場合にはSQLExceptionをスローし、リソースの一方または両方が改ざんされた可能性があることを示します。

ログオン パスワードの場合、Teradata JDBC Driverは復号化パスワード文字列を使用してデータベースにログオンします。新しいパスワードの場合、Teradata JDBC DriverはMODIFY USERコマンドで復号化パスワード文字列を使用して期限切れパスワードを更新します

クライアント システムの情報

Teradata JDBC Driverがデータベースとの接続を確立すると、Teradata JDBC Driverはクライアント システムとクライアント ソフトウェアについての情報をデータベースに送信します。データベースはこの情報をデータ ディクショナリのシステム表に記録し、データベース管理者によるクライアント システムのデモグラフィック分析を可能にします。次のセクションでは、クライアント属性機能とLogonSource列について説明します。

クライアント属性

Teradata Database 14.0およびTeradata JDBC Driver 13.10.00.21から、クライアント属性機能によってクライアント システムやクライアント ソフトウェアについての情報をシステム表、DBC.SessionTblおよびDBC.EventLogに記録できます。このクライアント属性機能は、システム表、DBC.SessionTblとDBC.EventLogのLogonSource列に記録される情報に代わるものです。

クライアント属性は、セッションのログオン時に記録されます。次に、システム ビューDBC.SessionInfoVとDBC.LogOnOffVのクエリーを実行し、クライアント システムおよびクライアント ソフトウェアについての情報をセッションごとに取得できます。クライアント属性の値は、セッションの文字セットなどの要素に応じて、大小文字の混合または大文字でデータベースに記録できます。記録されたクライアント属性の分析は、大小文字の混合または大文字の値に柔軟に対応する必要があります。

LogonSource列

Teradata Database 14.0からは、LogonSource列は過去のものと見なされ、クライアント属性機能が優先的に扱われます。LogonSource列は使用されなくなり、データベースの今後のリリースでは削除される方針です。

Teradata JDBC Driverがデータベースへの接続を確立すると、Teradata JDBC DriverはString値を作成し、その値はシステム表、DBC.SessionTblおよびDBC.EventLogのLogonSource列に保存されます。LogonSource列は、DBC.SessionInfoVやDBC.LogOnOffVなどのシステム ビューに含まれています。Teradata JDBC Driverや他のクライアントによって提供されるすべてのLogonSource値は、データベースに大文字で記録されます。

Teradata JDBC Driverは、『Teradata データ ディクショナリ』のセクション「システム ビュー列の一覧表」に記載されているネットワーク接続のLogonSource値のフォーマットに準拠しています。ネットワーク接続のLogonSource値には、8つのフィールドがあり、各フィールドは空白で区切られています。フィールド 1～3はデータベースにより作成され、フィールド 4～8はTeradata JDBC Driverにより作成されます。

1. リテラル"(TCP/IP)"。接続タイプを示す。
2. クライアント システム上のTCPポート番号。16進数形式。
3. クライアント システムのIPアドレス。
4. データベース ホスト名。Teradata Directory Program Identifier"TDPID"と呼ばれる。
5. クライアントのプロセス/スレッドID。
6. クライアント システムのユーザーID。
7. クライアント システム上で使用されているプログラム。
8. リテラル"01 LSS"。LogonSource文字列のバージョン 01を示す。

フィールド4～8の詳細については、以降のセクションを参照してください。 

クライアント情報とはすべて、Teradata JDBC Driverを含むJVMを実行しているシステムを指します。通常、これはアプリケーション サーバーです。クライアント情報は、Webブラウザなど、アプリケーション サーバーと通信しているほかのクライアントは指しません。

例 - LogonSource値

                                                                                                   1         1         1

         1         2         3         4         5         6         7         8         9         0         1         2

12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678

<--set by Teradata Database--><-------------------------------------------set by client---------------------------------------->

(TCP/IP) 11AB 153.64.135.140  CHARON;CHARONCOP1/192.168.16.144:1025     CID=C2A132   ROOTUSER JDBC03.02.00.00;1.4.2_01   01 LSS

(TCP/IP) 11AB 153.64.135.140  CHARON.SD.TERADATA.COM;CHARONCOP1.SD.TERA CID=C2A132   ROOTUSER JDBC03.02.00.00;1.4.2_01   01 LSS

----------------------------- ----------------------------------------- ------------ -------- -------------------------- ------

                                       1         2         3         4           1                     1         2

                              12345678901234567890123456789012345678901 123456789012 12345678 12345678901234567890123456 123456

                                       Truncated to the space            Will be     Trunc'ed    Trunc'ed to 26 chars    Always

                                  remaining in the 97 chars, after       12 chars   to 20 chars      (may be less)       6 chars

                                 the subsequent fields are composed      or less   (may be less)

各フィールドは、厳密に1つの空白文字で互いに区切られます。

フィールド4 - TDPID (ターゲットのデータベース ホスト名)フィールド

TDPIDフィールドの構成は、次のとおりです。

• 元のデータベース ホスト名。アプリケーションにより指定されます(COPnnn接尾辞なし)。例: CHARON
• その後に、セミコロン「;」が続きます。
• その後に、COP接尾辞付きホスト名および/またはデータベース ノードのIPアドレスが続きます。例: CHARONCOP1/192.168.16.144
• その後に、コロン「:」が続きます。
• その後に、データベース ノードへのTCP接続の宛先ポート番号が続きます。例: 1025。

このTDPIDフィールドは、他のフィールドがすべて作成された後に、97文字のうちの残りのスペースに切り捨てられます。 

アプリケーションがデータベース ホスト名"CHARON"を指定する場合のこのフィールドの値の例: CHARON;CHARONCOP1/192.168.16.144:1025

アプリケーションが完全修飾データベース ホスト名"CHARON.SD.TERADATA.COM"を指定する場合のこのフィールドの切り捨て済み値の例: CHARON.SD.TERADATA.COM;CHARONCOP1.SD.TERA

フィールド5 - クライアント プロセスID/スレッドIDフィールド

注:  Teradata JDBC Driverは、このフィールドにJavaスレッドIDを指定しません。

アプリケーション サーバー環境では、スレッドは、特定のデータベース接続に結び付けられていません。この結果、特定のスレッドが、元々は別のスレッドで作成された接続上で要求を実行できます。

混乱を避けるため、Teradata JDBC DriverはLogonSource値のフィールド5に接続IDを指定します。この接続IDは、例外メッセージとログ メッセージでも表示されます。このため、LogonSource値と例外メッセージおよびログ メッセージ間で各接続ID値を関連付けることができます。Teradata JDBC Driverは必ず、接続ID値に接頭辞"cid="を付けて、接続ID値とその他の値を区別しやすくします。

接続IDは、接続で使用されるプライベート オブジェクトのハッシュ コードです。これは、データベースとの特定の接続に対応した簡単な一意の識別子を提供します。

クライアント プロセス/スレッドIDフィールドの構成は、次のとおりです。

• CID=
• その後に、接続IDが続きます。

このフィールドの値は、例えば、次のようになります。CID=1E51060

フィールド6 - クライアント プロセス ユーザー フィールド

クライアント プロセス ユーザー フィールドの構成は、System.getProperty("user.name")です。

このフィールドは20文字に切り捨てられます。ただし、20文字より短くてもかまいません。 

このフィールドの値は、例えば、次のようになります。ROOTUSER

フィールド7 - クライアント プログラム名フィールド

クライアント プログラム名フィールドの構成は、次のとおりです。

• JDBC
• その後に、JDBCドライバ バージョンが続きます。例: 03.02.00.00
• その後に、セミコロン「;」が続きます。
• その後に、System.getProperty("java.version")が続きます。例: 1.4.2_04

このフィールドは26文字に切り捨てられます。ただし、26文字より短くてもかまいません。

このフィールドの値は、例えば、次のようになります。JDBC03.02.00.00;1.4.2_04

フィールド8 -  LogonSource文字列バージョン1

このフィールドの構成は、01 LSSです。

ユーザーのSTARTUP SQLリクエスト

CREATE USERコマンドと、MODIFY USERコマンドには、特定の初期セッション設定値を指定するためのSTARTUP句が用意されています。さらに、Teradata JDBC Driverにも、特定の初期セッション設定値を指定するための接続パラメータと、それに対応するDataSourceプロパティが用意されています。

セッション設定値のいくつかは、SQL DDLセッション コマンドを実行することでのみ指定できます。次のテーブルに、セッション設定値の多くをリストし、CREATE/MODIFY USER句またはJDBCの接続パラメータで指定する初期設定値を示します。SET SESSIONコマンドの全一覧は、リファレンス/「Teradata Vantage™ SQLデータ定義言語 構文規則および例」セクションに掲載されています。

Unicodeパス スルーのサポートは、Teradata Database 16.0およびTeradata JDBC Driver 15.10.00.08以降で使用できます。

ユーザーのSTARTUP SQLリクエストは、CREATE/MODIFY USER句やJDBC接続パラメータでは設定できない初期セッション設定値を確立するために使用できます。例えば、次に示すコマンドでは、ユーザー"susan"に対してトランザクション分離を非コミット読み取りに変更するSTARTUP SQLリクエストを設定しています。

ログオン後にユーザーのSTARTUP SQLリクエストを実行するには、Teradata JDBC DriverのRUNSTARTUP=ON接続パラメータを指定する必要があります。デフォルトの動作はRUNSTARTUP=OFFです。RUNSTARTUP接続パラメータが省略されている場合は、ユーザーのSTARTUP SQLリクエストは実行されません。

Teradataセッションの再接続

Javaアプリケーションは、JDBC java.sql.Connectionオブジェクトを使用してデータベース セッションと対話します。JDBC接続は、Teradata JDBC Driverの制御の範囲外で、以下に示すさまざまな理由でデータベース セッションから切断されることがあります。

• ネットワーク ケーブルが外れた
• ネットワーク通信エラー
• 管理者がモニター パーティション コマンドAbort Sessionを使用してセッションを終了した
• 管理者がGatewayコマンドKill Sessionを使用してセッションを終了した
• データベースの再始動

Teradataセッションの再接続は、Teradata JDBC Driver 13.10.00.24から使用できます。Teradataセッションの再接続が有効になっている場合、Teradata JDBC Driverは、通信エラー後にデータベース セッションへのJDBC接続の再接続を試行します。Teradataセッションの再接続は、以下の1つ以上の条件が満たされる場合に有効になります。

• Recoverable Network Protocolが有効
• および/または、接続パラメータRECONNECT_COUNT=numberが指定されている(省略の場合、デフォルトは11回の試行)
• および/または、接続パラメータRECONNECT_INTERVAL=秒が指定されている(省略の場合、デフォルトは30秒間)

再接続を試行する指定可能な最大経過時間:

    (ReconnectCount - 1) * ReconnectInterval

Teradata Database 14.10およびTeradata JDBC Driver 15.00.00.12からは、Teradataセッションの再接続はRecoverable Network Protocolによって拡張されるので、再接続は一時的なネットワーク エラーなど幅広いエラー イベントでサポートされます。Teradata Database 14.10およびTeradata JDBC Driver 15.00.00.12より以前では、Teradataセッションの再接続はデータベースの再始動後のみにサポートされ、一時的なネットワーク エラーなど他のイベント後の再接続はサポートされません。

Recoverable Network Protocolは、データベースとTeradata JDBC Driverの構成パラメータの組み合わせ、特にデータベースdbscontrolフィールドのRedriveProtection (67)、RedriveDefaultParticipation (68)、DisableRecoverableNetProtocol (77)、およびレベル2以上のTeradata JDBC Driver接続パラメータREDRIVEによって、有効または無効になります。

Teradataセッションの再接続が無効で、通信エラーが発生した場合、進行中の操作が失敗し、Teradata JDBC DriverがJDBC接続を終了してSQLState 08S01でSQLExceptionをスローします。

Teradataセッションの再接続が有効でありながら、Recoverable Network Protocolが有効でなく、通信エラーが発生した場合、進行中の操作が失敗し、Teradata JDBC Driverが再接続を試行し、以下のエラー コードのいずれかでSQLExceptionをスローして再接続試行の結果を示します。

• 1278 - 通信エラーのためTeradata Databaseへ再接続しました。
• 1279 - 通信エラーのためTeradata Databaseへ再接続しました。Teradata Databaseへの再接続後にエラーが発生しました。
• 1280 - Teradata Databaseへ再接続できません。

JDBC接続が閉じられている間は、通信エラーが発生しても再接続は試行されません。

データベースは再始動後に、限られた時間だけセッションへの再接続を実行します。この時間は、データベース ユーティリティ プログラム"gtwcontrol"を使用して設定されます。標準値は20分です。この時間が過ぎると、データベースはすべての再接続試行を拒否します。

Teradataセッションの再接続が有効でありながら、Recoverable Network Protocolが有効でない場合、データベースが再始動されると各セッションの状態の重要な部分は破棄されます。

• 現在のトランザクションはロールバックされます。
• オープンな結果セットはすべて廃棄されます。
• オープンなBLOB値およびCLOB値はすべて廃棄されます。
• すべての揮発表は廃棄されます。
• 実体化されたすべてのグローバル一時表は廃棄されます。

Recoverable Network ProtocolなしにTeradataセッションの再接続を使用するアプリケーションは、どの時点でも起き得るセッション状態の喪失に対応できるように設計する必要があります。Recoverable Network ProtocolなしのTeradataセッションの再接続は、JDBC接続プールでの使用には推奨されません。

Teradataセッションの再接続、Recoverable Network Protocol、SQLリクエストの自動リドライブがすべて有効で、通信エラーが発生した場合、進行中の操作は失敗しますが、自動で再始動され、セッションの状態は保持され、Teradata JDBC Driverは再接続を試行し、再接続に成功すれば例外をスローしません。

トランザクション モード

TMODE接続パラメータを使用すると、アプリケーションで接続用のトランザクション モードを指定できます。

• TMODE=ANSIとすると、ANSI(米国規格協会)トランザクション セマンティクスが使用されます。このモードが推奨されます。
• TMODE=TERAとすると、旧来のTeradataトランザクション セマンティクスが使用されます。このモードは、Teradataトランザクション セマンティクスが必要な旧来のアプリケーションに対してのみ推奨されます。
• TMODE=DEFAULTとすると、データベース用に構成されたデフォルトのトランザクション セマンティクス(ANSIモードとTERAモードのいずれか)が使用されます。TMODE=DEFAULTは、TMODE接続パラメータを省略する場合のデフォルトの設定です。

一般にはANSIモードが推奨されますが、アプリケーションはそれぞれ異なっており、一部のアプリケーションではTERAモードを使用する必要があります。ANSIモードとTERAモードにおける以下の相違が標準的なユーザーまたはアプリケーションに影響する可能性があります。

1. TERAモードでは挿入されたデータのサイレント切り捨てが発生しますが、ANSIモードでは発生しません。ANSIモードの場合、データベースは、切り捨てデータの代わりにエラーを返します。
2. ANSIモードで作成されるテーブルは、デフォルトでMULTISETです。TERAモードで作成されるテーブルは、デフォルトでSETです。
3. ANSIモードで作成されるテーブルの場合、文字の列はデフォルトでCASESPECIFICです。TERAモードで作成されるテーブルの場合、文字の列はデフォルトでNOT CASESPECIFICです。
4. ANSIモードでの文字リテラルはCASESPECIFICです。TERAモードでの文字リテラルはNOT CASESPECIFICです。

最後の2つの動作の相違が合わさって、TERAモードでは文字データ比較(WHERE句の条件など)では大文字と小文字が区別されませんが、ANSIモードでは大文字と小文字が区別されます。このため、ANSIモードとTERAモードでは異なる問合せ結果が返されることがあります。2つのNOT CASESPECIFIC式の比較はモードに関係なく大文字と小文字を区別せずに行われ、CASESPECIFIC式と任意の種類の別の式の比較はモードに関係なく大文字と小文字を区別して行われます。式をCASESPECIFICまたはNOT CASESPECIFICとして明示的にCASTし、アプリケーションで必要とされる文字データ比較を取得することができます。

リファレンス/「Teradata Vantage™ SQLリクエストおよびトランザクション処理」セクションでは、すべての新しいアプリケーションでANSIモードを使用することが推奨されています。ANSIモードを使用することの主要な利点は、不注意によるデータ切り捨てを防止することです。それとは対照的に、TERAモードを使用する場合には、データが挿入されるときにサイレント データ切り捨てが発生する可能性があります。これは、サイレント データ切り捨てがTERAモードの機能だからです。

ANSIモードを使用する場合の欠点は、ANSIモードを使用して作成されたストアド プロシージャしか呼び出すことができず、TERAモードを使用して作成されたストアド プロシージャは呼び出すことができないことです。正常に動作するためにTERAモードが必要なレガシー アプリケーションを使用している可能性があるので、ANSIモード専用に切り替えることは不可能です。この欠点は、2つの異なるユーザー/データベースで、1つはANSIモードを使用して、もう1つはTERAモードを使用して、ストアド プロシージャを2回作成することによって回避できます。

ANSIとTERAのトランザクション モードの相違に関する詳細は、「Teradata Vantage™ SQLリクエストおよびトランザクション処理」を参照してください。

自動コミット

自動コミットはJDBC API仕様の基本機能であり、Teradata JDBC Driverには、ANSIとTERAの両方のモードの場合に、自動コミットのオンおよびオフ機能が適切に実装されています。

接続が初めて確立されると、デフォルトのJDBC自動コミット設定(オン、true)が開始されます。自動コミットがオンの場合は、JDBC Driverがトランザクションを管理する全責任を負い、JDBC Driverによって各SQLリクエストがコミットされて正常に実行されます。自動コミットがオンの場合、アプリケーションでは、トランザクション管理のSQLコマンドを何も実行しないようにする必要があります。自動コミットがオンの場合、アプリケーションでは、Connection.commitメソッドまたはConnection.rollbackメソッドを呼び出さないようにする必要があります。

アプリケーションでは、自動コミットをオフに切り替えるfalseの引数を指定してConnection.setAutoCommitメソッドを呼び出すことによって管理できます。自動コミットがオフの場合、JDBC Driverは各SQLリクエストが実行された後に現在のトランザクションを開いたままにします。アプリケーションには、Connection.commitまたはConnection.rollbacメソッドを呼び出すことによって、それぞれトランザクションをコミットまたはロールバックする役割があります。

ベスト プラクティスでは、BT、ET、ABORT、COMMIT、またはROLLBACKなどのデータベース ベンダー固有のトランザクション管理コマンドをアプリケーションで実行することを回避するよう推奨されています。これは、そのようなコマンドがベンダーごとに異なるためです(それらは、Teradataの2つのモードANSIとTERAの間でも異なっています)。代わりにベスト プラクティスでは、トランザクション管理のために、アプリケーションで標準のJDBC APIメソッド(Connection.setAutoCommit、Connection.commit、およびConnection.rollback)のみを呼び出すことが推奨されています。

1. ANSIモードで自動コミットがオンの場合、Teradata JDBC Driverは、すべてのSQLリクエストが正常に実行されるごとにCOMMIT WORKを自動的に実行します。
2. ANSIモードで自動コミットがオフの場合、Teradata JDBC DriverはCOMMIT WORKを自動的に実行しません。アプリケーションがConnection.commitメソッドを呼び出すと、Teradata JDBC DriverはCOMMIT WORKを実行します。
3. TERAモードで自動コミットがオンの場合、Teradata JDBC Driverは、アプリケーションでBTまたはETコマンド自体が明示的に実行されない限り(実行することは推奨されていません)、BTまたはETを実行しません。
4. TERAモードで自動コミットがオフの場合、Teradata JDBC Driverは、新しいトランザクションについてのアプリケーションの最初のSQLリクエストを実行依頼する前にBTを実行します。アプリケーションがConnection.commitメソッドを呼び出すと、Teradata JDBC Driverはトランザクションが完了するまでETを実行します。

データベースとTeradataクライアント インターフェース ソフトウェア(Teradata JDBC Driverなど)の間のワイヤー プロトコルの一部として、データベースからクライアントに送信される各メッセージには、セッションに進行中のトランザクションがあるかどうかを示すための1ビットが指定されています。したがって、クライアント インターフェース ソフトウェアには、セッションに進行中のトランザクションがあるかどうかに関して通知され続けます。

自動コミットがオフのTERAモードでは、アプリケーションがTeradata JDBC Driverを使用してSQLリクエストを実行すると、セッションに進行中のトランザクションがない場合、Teradata JDBC DriverはアプリケーションのSQLリクエストを実行する前にBTを自動的に実行します。その後、自動コミットがオフのTERAモードでは、アプリケーションがTeradata JDBC Driverを使用して別のSQLリクエストを実行し、セッションに進行中のトランザクションがすでに存在する場合、Teradata JDBC Driverでは、アプリケーションのSQLリクエストを実行する前にBTを実行する必要がありません。

TERAモードでは、BTとETのペアを入れ子にすることができ、データベースは入れ子レベルを追跡します。最も外側のBT/ETペアによりトランザクション スコープが定義されます。データベースには実際のトランザクション入れ子がないため、内側のBT/ETペアによるトランザクションへの影響はありません。トランザクションをコミットするには、入れ子がアンワインドされるまでETコマンドを繰り返し実行する必要があります。Teradataワイヤー プロトコル ビット(上述)は、入れ子がアンワインドされ、トランザクションが完了していることを示します。アプリケーションがTERAモードでConnection.commitメソッドを呼び出すと、Teradata JDBC Driverは、入れ子がアンワインドされてトランザクションが完了するまでETコマンドを繰り返し実行します。

まれな場合ですが、アプリケーションがベスト プラクティスに従わず、トランザクション管理コマンドを明示的に実行することがあります。そのようなアプリケーションでは、BT、ET、ABORT、COMMIT、またはROLLBACKなどのトランザクション管理コマンドを実行する前に、自動コミットをオフにする必要があります。アプリケーションには、有効なトランザクション モードで適切なコマンドを実行する役割があります。TERAモードのコマンドは、BT、ET、およびABORTです。ANSIモードのコマンドは、COMMITとROLLBACKです。アプリケーションでは、自動コミットがオフのTERAモードでトランザクションを開く場合には特に注意する必要があります。自動コミットがオフのTERAモードでアプリケーションがSQLリクエストを実行する場合、セッションに進行中のトランザクションがないと、Teradata JDBC DriverはアプリケーションのSQLリクエストを実行する前にBTを自動的に実行します。したがってアプリケーションでは、BTを実行してトランザクションを開始することのないようにする必要があります。

// 望ましくないBT/ETネスティングを示すTERAモードの例

con.setAutoCommit(false);

stmt.execute("BT"); // BTは、この前にJDBCドライバによって自動的に実行され、ネストされたBTを生成する

stmt.execute("insert into mytable1 values(1, 2)");

stmt.execute("insert into mytable2 values(3, 4)");

sstmt.execute("ET"); // ネスティングを巻き戻す

stmt.execute("ET"); // トランザクションを完了する

// BT/ETネストを回避する方法を示すTERAモードの例

con.setAutoCommit(false);

stmt.execute("insert into mytable1 values(1, 2)"); // この前にJDBCドライバによってBTが自動的に実行されます

stmt.execute("insert into mytable2 values(3, 4)");

stmt.execute("ET"); // トランザクションの完了

上記の例はどれもベスト プラクティスを示していません。ベスト プラクティスとしては、トランザクション管理のために、アプリケーションで標準のJDBC APIメソッド(Connection.setAutoCommit、 Connection.commit、およびConnection.rollback)のみを呼び出すことが推奨されています。

// ベスト プラクティスを示す例

con.setAutoCommit(false);

stmt.execute("insert into mytable1 values(1, 2)");

stmt.execute("insert into mytable2 values(3, 4)");

con.commit();

SQLリテラルとSQLインジェクション攻撃

SQL文字列リテラルを含むSQLリクエストを作成する場合、アプリケーションは、単一引用符を適切にエスケープする必要があります。SQL文字列リテラルは単一引用符で囲みます(例:'New York')。SQL文字列リテラル内で単一引用符を使用するには、単一引用符を繰り返す必要があります(例: 'Joe"s Diner')。

ユーザー入力が直接SQLテキスト文字列内に代入されるような、ユーザー入力に基づくSQLリクエストを作成するアプリケーションは、SQLインジェクション攻撃に対して弱いことがあります。

例えば、アプリケーションが、ユーザーの姓を入力するように指示し、その姓の人間を全員探す問合わせを作成するとします。

この例では、SQLテキストのハードコード部分に、SQL文字列リテラルの両側で使用する単一引用符が指定されていることに注意してください。この手法が有効なのは、ユーザーの入力値に単一引用符が指定されていない場合に限ります。

しかし、ユーザーが姓として"O'Malley"と指定すると、アプリケーションは間違って次の問合わせを作成します。この問合わせは、構文エラーとしてデータベースに拒否されます。

SQLインジェクション攻撃は、アプリケーション コード内のこの種の不備を利用して、不正を実行します。例えば、悪意ある入力値には、次のようなものがあります。

この結果、アプリケーションは、次のSQLテキスト文字列を作成します。

この例で、悪意あるユーザーは、入力値として、その両側に、ハードコードされた単一引用符と対となって動作する値が来るような入力値を注意深く選択しています。データベースは、このSQL文字列の実行に成功します。悪意あるユーザーが、重要な表への書き込みアクセスを実行できたら、この重要な表から行がすべて削除され、サービス妨害が実行されてしまいます。

アプリケーションは、単一引用符を処理し、SQLリクエストを適切に作成するように、コーディングされる必要があります。

インジェクション攻撃に対する最も一般的な保護方法としては、ユーザーがSQLテキストを変更しないように、プリペアード文を使用することを推奨します。この結果、ユーザーの入力値は、あくまで、プリペアード文のバインド パラメータとして使用されます。

アプリケーションがプリペアード文を使用できない場合、例えば、データ定義言語(DDL)コマンドの作成などの場合、ユーザーの入力値を妥当性検査してエスケープすることを推奨します。例：

• ユーザーの入力値が数である場合、アプリケーションは、ユーザーの入力値が数値だけで構成されていることを確認してから、ユーザーの入力値をSQLテキスト文字列内に連結する必要があります。
• SQL文字列リテラル内でユーザーの入力値を使用する場合、ユーザーの入力値を走査して単一引用符がないかどうかを調べる必要があります。その後、各単一引用符を繰り返してから、ユーザーの入力値をSQLテキスト文字列内に連結する必要があります。データベース側では、データベースは、SQL文字列リテラル内の単一引用符の各ペアをアンエスケープするため、1つの単一引用符1文字になります。

JDBCエスケープ句

JDBCエスケープ句処理が有効になっている場合、Teradata JDBC Driverは、エスケープ構文を探し、この構文を、データベースのネイティブSQL構文に変換します。この結果、どのデータベースからも独立したエスケープ構文が作成されます。

JDBCエスケープ句処理のデフォルトはENABLEDです。次の各メソッドを呼び出せば、クラスStatementおよびRowSetで、エスケープ句処理を無効にできます。

• Statement.setEscapeProcessing(false)
• RowSet.setEscapeProcessing(false)

次に、エスケープ句の一般構文を記載します。

Teradata JDBC Driverでは、次のタイプのエスケープ句がサポートされています。

• 日付、時刻、タイムスタンプの各リテラル
• スカラー関数
• LIKE述部エスケープ文字
• 外部結合
• ストアド プロシージャの呼び出し

日付と時刻のリテラル

スカラー関数

次の表は、Teradata JDBC DriverによりサポートされるJDBCエスケープ構文スカラー関数のリストです。

変換関数

データ タイプ変換のエスケープ句では、次に示す構文を使用します。

SQLtypeは、次の表に示したデータ タイプのいずれかになります。

LIKE述部エスケープ文字

Teradata JDBC Driverは、次の構文を使用して、LIKE SQL文のエスケープ文字をサポートします。

このエスケープ句は、エスケープ文字を指定します。この結果、SQL LIKE文でワイルドカード(%_等)を文字どおりに解釈できます。

外部結合

Teradata JDBC Driverは、外部結合に対応したエスケープ句をサポートしています。次に、外部結合の構文を記載します。

この言語ルールでは、外部結合の構造は次のとおりです。

table {LEFT|RIGHT|FULL} OUTER JOIN {table | outer-join}

ON search-condition

ストアド プロシージャの呼び出し

ストアド プロシージャの呼び出しに対応したエスケープ句構文は、次のとおりです。

エスケープ句では、次のことが真になります。

• 括弧()が欠落している場合、欠落した括弧が追加されるのは、JDBCエスケープ句内部でストアド プロシージャを呼び出す場合に限ります。
• JDBCエスケープ句内部でマクロを実行するのは無効です。

Teradata Tools and Utilities 08.01.00およびTeradata JDBC Driver Release 03.03.00では、JDBCエスケープ構文を使用しないSQL CALL文に括弧を追加しないことになりました。この動作変更により、JDBCエスケープ構文を使用しない場合、アプリケーションのSQL文を変更しないままデータベースに渡せるようになりました。

推奨は、アプリケーションが必ず、標準のベンダー独立JDBCエスケープ構文を使用して、ストアド プロシージャを呼び出すことです。JDBCエスケープ構文を使用してストアド プロシージャを呼び出す場合、例えば、次のような場合、

Teradata JDBC Driverは、必要に応じてSQL文を変更して、データベースの正確な構文要件を満たします。このリリースのTeradata JDBC Driverでは、ストアド プロシージャの呼び出しに対応したJDBCエスケープ構文機能は変更されません。

アプリケーションが、不注意により旧リリースのTeradata JDBC Driverの動作に依存しており、JDBCエスケープ構文を使用しないSQL CALL文の変更を期待していた場合、次のどちらかにアプリケーションを変更する必要があります。

• ストアド プロシージャの呼び出しに対応した標準JDBCエスケープ構文を使用する(推奨)。
• ストアド プロシージャ名の後に空の括弧を指定する。

接続関数

次に示す表は、Connection.nativeSQLメソッドで使用するためのJDBCエスケープ構文関数の一覧です。この関数を使用して、接続に関する情報を取得したり接続の動作を制御したりします。情報を提供する関数により、ローカルにキャッシュされた情報を返したり、データベースとのラウンド トリップを回避したりします。

要求スコープ関数

次に示す表は、Connection.createStatement、Connection.prepareStatement、またはConnection.prepareCallメソッドで使用するためのJDBCエスケープ構文関数の一覧です。これらの関数を使用して、対応するStatement、PreparedStatement、またはCallableStatementを制御します。これらの関数は、これらの関数が指定されている特定のSQLリクエストに限定されます。

クエリー バンド

Teradata Database 12.0では、クエリー バンドが導入されています。クエリー バンドは、SQLリクエストの発行元を識別する目的でセッションまたはトランザクションに対して設定できる、名前/値のペアのセットです。

クエリー バンドが必要な理由

• データベースにアクセスするJ2EEアプリケーションの多くは、複数のエンドユーザーのアクティビティを同じデータベース ユーザーIDを使用するデータベース接続に統合する、接続プーリング メカニズムを利用しています。特に複数階層のアプリケーションにおいては、SQLの発行元であるエンドユーザーやアプリケーションなどをデータベース層で識別するための単純な方法が存在しないことがあります。
• J2EEアプリケーションでは、Webページのレンダリングを目的とした特定のHTTP要求のために実行依頼されたすべてのSQLリクエストを、識別したりまとめたりすることが必要になる場合があります。
• チャージ バック、アカウント処理、トラブルシューティング、その他の種類のシステム管理の目的で、管理者は、どのエンドユーザー、アプリケーション、レポート、またはアプリケーションの一部が要求を発行したのかを認識する必要があります。

使用状況のシナリオ

あるWebベースのJavaアプリケーションでは、接続プールがWebサーバー上に存在しています。プール内のすべての接続は、同じTeradataユーザー(例:appuser)向けのものです。このようなユーザーは、一般にロボット ユーザーと呼ばれています。このアプリケーションは、ブラウザのCookieを使用して、Webブラウザを使用しているエンドユーザーを識別します。

ユーザーがWebページ上のリンクをクリックするたびに、ユーザーのWebブラウザは、Webサーバーに要求を送信し、要求の一部としてブラウザのCookieを送信します。Webサーバーは、要求を処理するためにアプリケーションを呼び出します。アプリケーションは、Teradataへの問合わせの実行依頼などの、何らかの処理を行ないます。Teradataに問合わせを実行依頼する直前に、アプリケーションは、まず以下の文を実行依頼します。

PreparedStatement pstmt = conn.prepareStatement("Set QUERY_BAND=? FOR TRANSACTION");

pstmt.setString (1, "custIdFromCookie=46734832");

pstmt.executeUpdate ();

次に、アプリケーションは以下のような問合わせを実行依頼できるようになります。

問合わせによって結果セットが返された後、アプリケーションはHTMLページをWebブラウザに出力します。

使用状況のシナリオ

• Webサービスは、Java内にインプリメントされており、HTTP/SOAP要求に応答します。
• Webサービスは、Java Transaction API(JTA)を使用してユーザー管理トランザクションを開始します。
• Webサービスは、アプリケーション サーバーによって管理される接続プールからJDBC接続を取得します。
• Webサービスは、複数のEnterprise Java Beans(EJB)を呼び出して何らかの有用な作業を実行します。例えば、最初のEJBはTable Aに1行を挿入し、2番目のEJBはTable B内にあるいくつかの行を更新します。  EJBの呼び出しはすべて同じトランザクションに参加するため、同じクエリー バンドによって識別されます。
• Webサービスは、トランザクションをコミットします。トランザクションのクエリー バンドの値は、自動的にクリアされます。したがって、プール接続で実行依頼される後続のSQLリクエストには、別のクエリー バンドの値が割り当てられます。

構文

クエリー バンドは、文字列内で名前=値のペアとしてデータベースに渡されます。アプリケーションでは、名前と値の両方を定義します。クエリー バンドは、トランザクションやセッションに対して設定できます。Teradata Database 15.10から、デフォルトのクエリー バンドをプロファイルに設定できます。

• SET QUERY_BAND FOR TRANSACTIONはDMLコマンドです。クエリー バンドは、単一引用符または疑問符パラメータ マーカーで囲まれたSQL文字列リテラルで指定できます。クエリー バンドは疑問符パラメータ マーカーとPreparedStatement.setStringメソッドを使用して指定することを強く推奨します。
• SET QUERY_BAND FOR SESSIONはDDLコマンドです。クエリー バンドは、単一引用符で囲まれたSQL文字列リテラルで指定する必要があります。疑問符パラメータ マーカーは使用できません。
• CREATE PROFILE AS QUERY_BANDおよびMODIFY PROFILE AS QUERY_BANDはDDLコマンドです。クエリー バンドは、単一引用符で囲まれたSQL文字列リテラルで指定する必要があります。疑問符パラメータ マーカーは使用できません。これらのコマンドは、Teradata Database 15.10から利用できます。

上記のSQLコマンドの詳細は、「Teradata Vantage™ SQLデータ定義言語」の説明を参照してください。

クエリー バンドの構文規則は以下のとおりです。

• 名前/値の各ペアは、最後のものも含めて、セミコロンで終了させる必要があります。
• クエリー バンドの名前の長さは、それぞれ1～128文字にする必要があります。
• クエリー バンドの値の長さは、それぞれ0～256文字にする必要があります。
• クエリー バンドの名前と値には、等号、セミコロン、Null文字(\u0000)を含めることはできません。
• クエリー バンドの名前は、クエリー バンド文字列内でそれぞれ1回だけ指定する必要があります。(クエリー バンドの名前が1つのクエリー バンド文字列内に複数回指定されていると、データベースはエラーを返します)
• クエリー バンド文字列全体の最大長は、2048文字に制限されています。空白文字を含むすべての文字が、長さの判定時にカウントされます。空白文字は、クエリー バンド文字列の先頭と末尾、等号の前後、およびセミコロンの前後に使用できますが、削除されます。

例

PreparedStatementを使用せずSQL文字列リテラルを使用してトランザクションにクエリー バンドの値を設定する手順:

stmt = conn.createStatement();

stmt.executeUpdate("SET QUERY_BAND='Org=Finance; report=EndOfYear; universe=west;' FOR TRANSACTION");

例

PreparedStatementを使用してトランザクションにクエリー バンドの値を設定する手順:

pstmt=conn.prepareStatement("SET QUERY_BAND=? FOR TRANSACTION");

pstmt.setString (1, "Org = Finance; report = EndOfYear; universe=west;);

pstmt.executeUpdate ();

例

トランザクションのクエリー バンドの値をクリアする手順:

stmt = conn.CreateStatement();

stmt.executeUpdate("SET QUERY_BAND = NONE for TRANSACTION");

クエリー バンド値の取得

Teradata JDBC Driver 14.00.00.33から、JDK 6.0以降の環境で実行されているアプリケーションは次のメソッドを使用してクエリー バンド値を取得できます。

• Properties java.sql.Connection.getClientInfo()
• String java.sql.Connection.getClientInfo(String name)

最初のメソッドは、すべてのアクティブなクエリー バンドの名前/値ペアを含むPropertiesオブジェクトを返します。2番目のメソッドは、指定した名前のクエリー バンド値を返します。

複数のコンテキストで同じクエリー バンド名がアクティブな場合は、該当するクエリー バンドの値の1つのみがこれらのメソッドにより返されます。トランザクション クエリー バンドの値はセッション クエリー バンドの値よりも優先し、後者の値はプロファイル クエリー バンドの値よりも優先します。プロファイル クエリー バンドの値は、Teradata Database 15.10およびTeradata JDBC Driver 15.00.00.23からサポートされます。

推奨されるクエリー バンドの名前

JDBC 4.0の仕様で定義されている標準のクライアント情報プロパティ名は、以下のとおりです。

• ApplicationName – 接続を現在利用中のアプリケーションの名前
• ClientUser – 接続を使用中のアプリケーションに作業を実行させているユーザーの名前(接続を確立する際に使用されたユーザー名と同じ名前ではない可能性があります)
• ClientHostname – 接続を使用中のアプリケーションが実行されているコンピュータのホスト名

標準のクライアント情報プロパティに対応する情報をクエリー バンドの名前/値のペアとして使用する必要のあるアプリケーションの場合は、標準のクライアント情報プロパティの名前をクエリー バンドの名前として使用することを推奨します。

アプリケーションで使用できる名前は、標準のクライアント情報プロパティ名だけに限られているわけではありません。標準のクライアント情報プロパティに対応しないクエリー バンドの名前/値のペアを使用するアプリケーションの場合は、データベースでサポートされている範囲のクエリー バンド名であれば、自由に使用することが可能です。

クエリー バンドの使用

• クエリー バンドは、Database Query Log (DBQL)の詳細ロギング表内に1つのフィールドとして記録されます。DBQLレポートは、クエリー バンドの名前/値のペアを使用して、アカウント処理の改良やリソース割り当ての目的で作成することができます。 DBQLの詳細については、「Teradata Vantage™ - データベースの管理」を参照してください。
• クエリー バンドの名前/値のペアには、Teradataワークロード管理のフィルタ ルールとスロットル ルールを関連付けることができます。ディレクトリ ベースの接続と、単一のログオンですべてがTeradataに接続するWebベースのアプリケーション サーバーを利用するアプリケーションでは、クエリー バンドを使用して要求の発行元を識別し、ワークロード管理のルールを使用してリソースを制御することが可能です。
• クエリー バンドの名前/値のペアは、ワークロード分類基準内に定義できます。そうすることにより、すべて単一のログオンから発行されている要求を、発行元のアプリケーションで設定されたクエリー バンドに基づいて、異なるワークロードに分類できるようになります。また、さまざまな要求に対して異なる優先度をアプリケーションで設定することも可能になります。例えば、あるアプリケーションのGUIには、素早い応答を必要とするダイアログと、バックグラウンドで長時間実行されるレポートを実行依頼するダイアログの両方が存在することがあります。そのようなアプリケーションでは、ジョブの種類ごとに異なるクエリー バンドを設定して、各要求が異なるワークロードに分類されて異なる優先度で実行されるようにすることが可能です。

信頼済みSQLとクエリー バンドの偽装

Teradata Database 13.10から、信頼済みセッションの拡張セキュリティによって、現在のプロキシ ユーザーの設定や削除にSET QUERY_BAND SQLが使用されないようにしています。これは、すべてのSQLリクエストをTrusted (信頼済み)、またはUntrusted (未信頼)として分類することで実現しています。

すべてのSQLリクエストを独自に作成し、その要求をすべて信頼するアプリケーションでは、この機能を使用しません。この機能は、信頼済みのSQLリクエストと未信頼のSQLリクエストの両方を利用して作業するアプリケーションに使用します。未信頼のSQLリクエストの一例として、ユーザーから取得したSQLリクエストが挙げられます。未信頼のSQLリクエストには、悪意のあるユーザーからのSQLインジェクション攻撃が含まれている可能性があります。

信頼済みのSQLリクエストと未信頼のSQLリクエストを利用して作業するアプリケーションは、次に示すプロセスに従って、この機能を使用します。

• DBAは、アプリケーションに実施するGRANT CONNECT THROUGH権限付与のすべてに、WITH TRUST_ONLYオプションを使用する。
• アプリケーションは、TRUSTED_SQL=ON接続パラメータ指定したTeradata JDBC Driverの接続を使用する。
• ユーザーが入力したSQLを処理するアプリケーション コードのすべての部分を特定する。
• アプリケーションに変更を加えて、ユーザーが入力したすべてのSQLテキストの先頭に{fn teradata_untrusted}エスケープ関数を追加してから、そのSQLリクエストをTeradata JDBC Driverに渡すようにする。

このエスケープ関数は、SQLリクエストを信頼済みから未信頼にダウングレードします。SQLリクエストを未信頼から信頼済みにアップグレードするメカニズムは、SQLインジェクション攻撃に利用される可能性があるために用意されていません。

日付、時刻、タイムスタンプ値とタイムゾーン

java.sql.Date、Time、およびTimestampオブジェクト

次に示す表では、java.sql.Date、TimeおよびTimestampクラスのvalueOfメソッドと、toStringメソッドの動作を説明しています。

Teradata JDBC DriverのPreparedStatementおよびCallableStatement setterメソッドのsetDate、setTime、およびsetTimestampはそれぞれ、Teradata Databaseにjava.sql.Date、Time、またはTimestamp値を送信します。各値は、java.sql.Date、Time、またはTimestampオブジェクトのtoStringメソッドが、setterメソッドの呼び出し時点に出力する内容と一致します。つまり、値はsetterメソッドの呼び出し時点のJVMデフォルト タイムゾーンに相対的なものになります。

そのため、アプリケーションはjava.sql.Date、TimeまたはTimestampオブジェクトの作成時や、setDate、setTimeまたはsetTimestampの呼び出し時に、JVMデフォルト タイムゾーンが有効であることを確認する必要があります。

Date値の送信

Teradata DatabaseにはDATE WITH TIME ZONEデータ タイプが用意されていないため、アプリケーションからはCalendarを使用しないsetDateのみを呼び出して、Calendarを使用するsetDateを呼び出さないことが推奨されます。

Time値の送信

Time値には付随する日付がないため、夏時間がTime値に適用されることはありません。また、カレンダー引数のタイムゾーンの夏時間は無視されます。TIME ZONEフィールドは、UTCから直接計算したタイムゾーンのオフセットとしてデータベースに送信されます(夏時間の影響は受けません)。

Timestamp値の送信

夏時間は、Timestamp値には使用されません。データベースは、TIMESTAMP WITH TIME ZONE値を、UTCから直接計算したオフセットとして格納します。データベースとの一貫性を保つために、Teradata JDBC DriverではCalendar引数のタイムゾーンの夏時間を無視します。TIME ZONEフィールドは、UTCから直接計算したタイムゾーンのオフセットとしてデータベースに送信されます(夏時間の影響は受けません)。

TIMESTAMP WITH TIME ZONE値が夏時間を反映する必要があるアプリケーションでは、カスタム タイムゾーンを使用したCalendar引数を指定する必要があります。

例えば、東部標準時間を示すために、アプリケーションでは次に示すようにCalendar引数を指定します。

prepstmt.setTimestamp(index, timestamp,
  Calendar.getInstance(TimeZone.getTimeZone("GMT-05:00")));

東部夏時間を示すには、アプリケーションでは次に示すようにCalendar引数を指定します。

prepstmt.setTimestamp(index, timestamp,
  Calendar.getInstance(TimeZone.getTimeZone("GMT-04:00")));

TIME WITH TIME ZONEおよびTIMESTAMP WITH TIME ZONE値を送信するためのsetObjectの使用

Teradata JDBC Driver 14.10.00.26以降、アプリケーションはPreparedStatementまたはCallableStatement setObjectメソッドを使用して、Struct値をTIME WITH TIME ZONEまたはTIMESTAMP WITH TIME ZONEデータ タイプとして疑問符パラメータ マーカーにバインドできます。Teradata JDBC Driver 14.10.00.26より前のバージョンでは、TIME WITH TIME ZONE値をバインドするにはsetTime(Time, Calendar)メソッドが必要でした。TIMESTAMP WITH TIME ZONE値をバインドするにはsetTimestamp(Timestamp, Calendar)メソッドが必要でした。これらのメソッドは引き続き以前と同様に機能します。アプリケーションが新しい機能を使用する必要があるのは、setTime/setTimestampメソッドがサポートしていない場合、特にUDTのTIME WITH TIME ZONEおよびTIMESTAMP WITH TIME ZONEの属性値とPeriodデータ タイプをバインドする場合のみです。

アプリケーションは各データ値を、2つの属性を持つjava.sql.Struct値として作成する必要があります。Structの最初の属性にはjava.sql.Timeまたはjava.sql.Timestamp値を指定する必要があります。Structの2番目の属性にはTimeZone属性で目的のタイム ゾーンを指定するCalendar値を指定する必要があります。この方法で作成したStructは、Calendar引数を持つsetTime/setTimestampメソッドと同じように処理されます。Calendar引数を持つsetTime/setTimestampメソッドの動作の説明については、上記の文を参照してください。

java.sql.Structインターフェースを実装するクラスは、アプリケーションが提供する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

アプリケーションはこのクラスのインスタンスを使用して、TIME WITH TIME ZONEおよびTIMESTAMP WITH TIME ZONE値を作成します。

Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT+08:00")) ;

Time time = Time.valueOf( ...

Timestamp ts = Timestamp.valueOf( ...

// 2つの列を持つテーブルを想定する。TIME WITH TIME ZONEとTIMESTAMP WITH TIME ZONE

PreparedStatement ps = con.prepareStatement ("INSERT INTO MyTable VALUES(?,?)") ;

ps.setObject(1, new MyStruct("TIME WITH TIME ZONE", new Object [] {time, cal})) ;

ps.setObject(2, new MyStruct("TIMESTAMP WITH TIME ZONE", new Object [] {ts, cal})) ;

DATE、TIMEおよびTIMESTAMP値の受信

Teradata JDBC Driver 13.00.00.09以降では、ResultSetインターフェースとCallableStatementインターフェースのCalendar引数を使用したgetDate、getTime、およびgetTimestampメソッドによってCalendar引数のTimeZone属性が変更され、データベースから受信したTIME WITH TIME ZONEとTIMESTAMP WITH TIME ZONEのデータ値のタイムゾーン部分が提供されます。

さらに、Teradata JDBC Driverバージョン13.00.00.09以降では、ResultSetインターフェースとCallableStatementインターフェースのgetDate、getTime、およびgetTimestampメソッドにより、データベースから受信するDATE、TIME、およびTIMESTAMPのデータ値の暗黙的なデータ タイプ変換も提供されます。

データベースのTIME値には最大6桁の小数秒が格納されていることがありますが、java.sql.Time値はミリ秒まで(3桁の小数秒)の制限があります。アプリケーションはgetTimestampメソッドを使用してデータベースのTIME値を取得することで、java.sql.Time値の制限を回避できます。getTimestampメソッドは、TIMEからjava.sql.Timestampへの暗黙的なデータ タイプの変換を提供します。また、TIME値の小数秒のすべての桁数が維持されます。

次の表では、ResultSetおよびCallableStatementインタフェースのgetDate、getTime、およびgetTimestampメソッドの動作を説明しています。 データベースとのデータ値の適切なラウンドトリップ交換を確実にするために、（意図していない使用）と指定されている組み合わせは避けてください。

セッションのDateForm

セッションの現在のDateFormでは、主に、DATE値をデータベースからTeradata JDBC Driverに転送する方法を指示します。また、セッションの現在のDateFormは、データベースがPreparedStatement/CallableStatement setString値から宛先のDATE列またはパラメータへの暗黙の変換を実行する方法を指示します。

推奨されるDateFormは、ANSIDateです。セッションの現在のDateFormがANSIDateの場合、データベースはDATE値を10文字の値("YYYY-MM-DD"の形式)でTeradata JDBC Driverに送信します。データベースはPreparedStatement setString値から宛先のDATE列またはパラメータへのY2Kに準拠していない暗黙の変換を拒否します。(この場合、Teradata Databaseエラー2666が返されます。)

レガシー アプリケーションには、IntegerDate DateFormが用意されています。セッションの現在のDateFormがIntegerDateの場合、データベースはDATE値を4バイトのバイナリ値でTeradata JDBC Driverに送信します。データベースはPreparedStatement setString値から宛先のDATE列またはパラメータへのY2Kに準拠していない暗黙の変換を許可します。(この場合、データベースは年の世紀の桁に19を使用します。)

Teradata Databaseユーザーの場合、CREATE USERコマンド、またはMODIFY USERコマンドを使って、DateForm属性を指定できます。セッションが初めて確立されると、セッションの現在のDateFormは、あればユーザーのDateFormに、またはDBSControlレコードにDATEFORMパラメータで定義されているシステム デフォルトに設定されます。

HELP SESSIONコマンドは、セッションの現在のDateFormを表示します。

セッションの現在のDateFormは、SQLコマンドのSET SESSION DATEFORM=ANSIDATEまたはSET SESSION DATEFORM=INTEGERDATEを実行して変更できます。Javaアプリケーションの場合、アプリケーション サーバー内のプール接続を使ってSET SESSION DATEFORMコマンドを実行することは推奨されません。

Teradata DatabaseからのDATE値の受信

Teradata JDBC DriverのTTU 8.1以前のリリースでは、セッションの現在のDateFormがANSIDateの場合、DATE値として正確さに欠ける情報が渡されていました。データベースから受信したDATA値については、ResultSetMetadata getColumnTypeメソッドはjava.sql.Types.CHAR、ResultSetMetadata getColumn ClassNameメソッドはjava.lang.String、ResultSet getObjectメソッドはString値を返していました。

TTU 8.2 Teradata JDBC Driver 3.4から、セッションの現在のDateFormがANSIDateの場合でも、DATE値としてより正確な情報が渡されるようになりました。データベースから受信したDATA値については、ResultSetMetadata getColumnTypeメソッドはjava.sql.Types.DATE、ResultSetMetadata getColumnClassNameメソッドはjava.sql.Date、ResultSet getObjectメソッドはjava.sql.Date値を返します。

Teradata DatabaseへのDATE値の送信

Teradata JDBC Driver 12.0およびTeradata Database 12.0以降、Teradata JDBC Driverはjava.sql.Date値を、ANSIDate DateFormを使用したDATE値として、データベースに送信するようになりました。これは、PreparedStatement/CallableStatement setDateまたはsetObjectメソッドで指定されたjava.sql.Date値にY2K準拠の暗黙の変換を実行し、宛先のCHAR/VARCHAR列およびパラメータに送信します。

Y2Kに準拠していない動作を必要とするレガシー アプリケーションは、Teradata JDBC Driver 12.0に導入されている、Teradata固有のエスケープ構文を使用できます。アプリケーションがPreparedStatement/CallableStatement setDateまたはsetObjectメソッドを呼び出した時点に有効であったDateFormは、データベースに送信される対応するDATA値に使用されるDateFormです。

// DateForm=IntegerDateは、java.sql.DateからCHAR/VARCHARへの

// 非Y2K準拠の暗黙的な変換を提供する

connection.nativeSQL("{fn teradata_useintegerdate}");

// DateForm=ANSIDateは、java.sql.DateからCHAR/VARCHARへの

// Y2K準拠の暗黙的な変換を提供する(デフォルトの動作)

connection.nativeSQL("{fn teradata_useansidate}");

DateFormがセッションの現在のDateFormと一致するDATE値を受け取るのは、Teradata Databaseのリリース12.0から12.0.1.1のみです。セッションの現在のDateFormによって次のようになります。

• IntegerDateの場合、ANSIDate DateFormのDATE値がデータベースに送信されると、データベースはエラー2665 ("Invalid date")を返します
• ANSIDateの場合、IntegerDate DateFormのDATE値がデータベースに送信されると、データベースはエラー3610 ("Internal error:Please do not resubmit the last request.SubCode, CrashCode")を返します。

この制限は、Teradata Database 12.0.1.2からなくなりました。

Session Time Zone

すべてのTIMEおよびTIMESTAMPデータは、明示的または暗黙的にタイムゾーンに関連付けられています。ユーザーのデフォルトのタイムゾーンは、データベースとの接続(セッション)が確立された当初有効になります。ユーザーにデフォルトのタイムゾーンが定義されていない場合、接続の当初有効になるのはシステムのデフォルトのタイムゾーンです。接続のタイムゾーンは、SET TIME ZONE文で変更できます。詳細は、『Teradata Database SQLデータ定義言語』の「SET TIME ZONE」を参照してください。

PreparedStatementインターフェースは、setTimeおよびsetTimestampメソッドをCalendar引数のある場合とない場合の両方を定義します。

• アプリケーションがCalendar引数なし でPreparedStatement setTimeおよびsetTimestampメソッドを使用すると、データベースは接続のタイムゾーンをTIMEまたはTIMESTAMP値に暗黙的に関連付けます。
• アプリケーションがCalendar引数あり でPreparedStatement setTimeおよびsetTimestampメソッドを使用すると、データベースは指定されているCalendarのタイムゾーンをTIMEまたはTIMESTAMP値に明示的に関連付けます。

TIMEテーブルとTIMESTAMPテーブルの列およびストアド プロシージャ パラメータは、タイムゾーン フィールド(TIME、TIME WITH TIME ZONE、TIMESTAMP、およびTIMESTAMP WITH TIME ZONE)を付けて、または付けずに宣言できます。

• タイムゾーン フィールドなし で宣言された、TIMEおよびTIMESTAMPテーブルの列とストアド プロシージャ パラメータにはUTCに相対的な値が含まれます。
• タイムゾーン フィールドあり で宣言された、TIMEおよびTIMESTAMPテーブルの列とストアド プロシージャ パラメータには値のタイムゾーンに相対的な値が含まれます。

表12 は、データベースで入力データ値とその暗黙的、または明示的に関連付けられているタイムゾーンを組み合わせて使われる方法について示すほか、TIMEまたはTIMESTAMPの宛先に保存される結果データ値を判断するために、宛先がタイムゾーン フィールドありとなしのどちらで宣言されているかを示します。

ストアド プロシージャTIMEとTIMESTAMP INOUTパラメータ

データベースは、INOUTパラメータのバインド入力値と同じデータ型属性に正確に従うように、ストアド プロシージャで設定された出力値をINOUTパラメータに強制します。

TIME WITH TIME ZONEおよび/またはTIMESTAMP WITH TIME ZONE型のINOUTパラメータを持つストアド プロシージャを呼び出す際、アプリケーションはCalendar引数を付けた、CallableStatementメソッドのsetTimeまたはsetTimestampをそれぞれ使って値をバインドする必要があります。Calendar引数を使用しない場合、データベースはエラー3996 (文字列データの右を切り捨て)を返します。また、setNullメソッドを使用して、TIME WITH TIME ZONEまたはTIMESTAMP WITH TIME ZONE型のINOUTパラメータにNULL値をバインドすることはできません。代わりに、setTimeまたはsetTimestampメソッドにCalendar引数を付けて、NULLデータ値を指定する必要があります。

現在のところ、データベースは値の小数部の桁数を減らす、TIMEおよびTIMESTAMP値の暗黙的、または明示的なデータ型変換機能を提供していませんし、許可していません。

Teradata JDBC Driver接続パラメータのTNANOとTSNANOは、このデータベースの制限に対応するために用意されています。TNANOおよびTSNANO接続パラメータは、すべてのTIMEデータ値に同じ小数桁数(TNANOで指定)を強制するほか、すべてのTIMESTAMPデータ値にINOUTパラメータのバインド入力値と同じデータ型属性を強制するため、使いづらいパラメータです。

この制約は、特にストアド プロシージャのTIMEとTIMESTAMPのINOUTパラメータに影響します。その理由は、INOUTパラメータの出力値をストアド プロシージャで設定するときに、その出力値がINOUTパラメータのバインド入力値と完全に同じデータ型属性になるように、データベースが強制する方法にあります。

• 入力値の小数桁数が、INOUTパラメータを宣言した際の桁数よりも多い場合、入力のTIMEまたはTIMESTAMP値をストアド プロシージャのINOUTパラメータにバインドすることはできません。この場合、Teradata Databaseはエラー5404 (Datetimeフィールドのオーバーフロー)を返します。
• 入力値の小数桁数が、INOUTパラメータを宣言した際の桁数よりも少ない場合は、入力のTIMEまたはTIMESTAMP値をストアド プロシージャのINOUTパラメータにバインドすることができます。ただし、残念ながら、データベースがエラー5404 (Datetimeフィールドのオーバーフロー)を返すため、ストアド プロシージャは入力値よりも小数桁数が多い出力値を返さないように制限されています。ストアド プロシージャは、INOUTパラメータの宣言に使用した小数桁数をすべて持つ出力値を返すことができない場合があります。
• 最終的な影響は、ストアド プロシージャのINOUTパラメータの入力のTIMEおよびTIMESTAMP値を、INOUTパラメータの宣言に使用したのとまったく同じ小数桁数でバインドする必要がある点です。TNANOとTSNANO接続パラメータは、すべてのデータ値に同じ小数桁数を持つように強制するため、アプリケーションは異なる小数桁数を持つようにINOUTパラメータで宣言されているストアド プロシージャを呼び出すことはできません。

例えば、このような問題は、次のストアド プロシージャに生じます。

PreparedStatementまたはCallableStatementパラメータにバインドされているNULL TIMEとTIMESTAMP値について、TNANOまたはTSNANO接続パラメータが指定されていない場合、Teradata JDBC Driverのデフォルト動作では、NULL TIMEまたはTIMESTAMP値の小数桁数はそれぞれ0と見なされます。このデフォルト動作は、宣言で小数桁数が使われているかどうかに関係なく、すべての考えられるINSERTおよびUPDATEの宛先TIME列とTIMESTAMP列に適用されます。このデフォルトの動作は、1以上の小数桁数で宣言されているストアド プロシージャのINOUTパラメータには適用されません。

データベースの機能が強化されるまで、TIMEおよびTIMESTAMP INOUTパラメータを伴うストアド プロシージャを呼び出すアプリケーションは、次のガイドラインに従う必要があります。

1. TNANOおよびTSNANO接続パラメータを指定する必要がある
2. ストアド プロシージャのTIMEおよびTIMESTAMP INOUTパラメータの小数桁数は、すべて同じに宣言し、それぞれTNANOおよびTSNANO接続パラメータと一致するように宣言する必要があります。

複文要求

複文要求は、複数のSQLコマンドをセミコロンで区切って入力した1つのSQL文で実行できます。複文要求は、Statement.execute()メソッドで実行できます。アプリケーションは、Statement.getResultSet()またはStatement.getUpdateCount()メソッドを使って結果を取得できるほか、複数の結果が返される場合は、Statement.getMoreResults()メソッドを使ってこれらの結果を繰り返し取得する必要があります。

データベースのマクロ

データベースのマクロは、1つまたは複数のSQL文で構成されます。マクロは、Statement.execute()メソッドで実行できます。アプリケーションは、Statement.getResultSet()またはStatement.getUpdateCount()メソッドを使って結果を取得できるほか、複数の結果が返される場合は、Statement.getMoreResults()メソッドを使ってこれらの結果を繰り返し取得する必要があります。

ユーザー定義関数と外部ストアド プロシージャの作成

ユーザー定義関数

CREATE/REPLACE FUNCTION文を使用して、ユーザー定義関数(UDF)を作成します。この文は、常に結果セットを返します。この文の実行には、Statement.executeQuery()メソッドやStatement.execute()メソッドを使用します。

UDFの詳細は、『Teradata Database SQL外部ルーチン プログラミング』の、ユーザー定義関数の説明を参照してください。

外部ストアド プロシージャ

CREATE/REPLACE PROCEDURE文を使用して、外部ストアド プロシージャ(XSP)を作成します。これは、Statement.execute()やStatement.executeUpdate()メソッドを使って実行できます。Statement.getWarnings()メソッドは、Statementオブジェクトで返されたSQLWarningの取得に使用できます。

XSPの詳細は、『Teradata Database SQL外部ルーチン プログラミング』の、外部ストアド プロシージャの説明を参照してください。

Java XSPの詳細は、この章の「Java外部ストアド プロシージャ」セクションを参照してください。

JDBCでのソース ファイルの場所

Teradata JDBC Driverは、サーバーまたはクライアント上に格納されているソース ファイルからUDF、UDM、またはXSPを作成できます。クライアント上に格納されているソース ファイルは、クライアント ノードからサーバー ノードに転送する必要があります。

セキュリティの目的で、Teradata JDBC Driverでは、すべてのリソースをロードするためにclasspathが使用されます。そのため、クライアント上のソース ファイルをclasspathに指定する必要があります。classpathを設定した後、Teradata JDBC Driverはソース ファイルをサーバー ノードに転送できるようになります。

ユーザー定義型

ユーザー定義型(UDT)の作成

Teradata JDBC Driverを使用したUDTの作成は、その他の種類のデータベース オブジェクトの作成方法と同じように実行します。Javaアプリケーションでは、StatementのexecuteメソッドやexecuteUpdateメソッドを呼び出すことで、目的に適ったCREATEコマンドを発行できます。

CREATE/REPLACE TYPEコマンドは、UDTを作成するために使用します。データベースによってCREATE/REPLACE TYPEコマンドが実行されると、アプリケーションはStatementのgetWarningsメソッドから得られる一連のSQLWarningオブジェクトとして、コマンドからの出力メッセージを取得できます。

CREATE TYPEコマンドの後には、目的に合わせてCREATE METHOD、CREATE FUNCTION、CREATE TRANSFORMおよびCREATE ORDERINGコマンドを実行して型を完全に作成します。

UDMとUDFの作成時、メソッド定義を含むソース ファイルがクライアント側にあることを"CREATE METHOD"文や"CREATE FUNCTION"文で示している場合、そのソース ファイルはclasspath上のリソースとして使用可能にしておく必要があります。Teradata JDBC Driverは、classpathから自動的にリソースをロードして、データベースに転送します。

上記のSQLコマンドの詳細は、「Teradata Vantage™ SQLデータ定義言語」の説明を参照してください。

データベースとのUDT値の転送

Teradata JDBC Driverでは、次に示すUDTの機能をサポートしています。

• UDT値はUDTコンストラクタとUDTミューテーター メソッドを使って構成できます。
• PreparedStatementパラメータ マーカーは、UDTコンストラクタとUDTミューテーター メソッドに引数を提示する各UDT属性値に対応させることができます。
• Teradata Database 13.10とTeradata JDBC Driver 13.00.00.18からは、PreparedStatementのパラメータ マーカーで、java.sql.Struct値を使用してすべてのUDT値を対応付けできるようになりました。(以前のソフトウェア バージョンでは、PreparedStatementのパラメータ マーカーで、java.sql.Struct値を使用してすべてのUDTを対応付けすることはできません)
• Teradata Database 13.10とTeradata JDBC Driver 13.10.00.07からは、JDBCカスタム タイプのマッピングがサポートされるようになったため、PreparedStatementパラメータ マーカーはjava.sql.SQLDataをインプリメントしたアプリケーション クラスのインスタンスに対応できます。(以前のソフトウェア バージョンでは、カスタム タイプのマッピングはサポートされていません。)
• UDT属性値は、SELECT文の".ALL"構文を使ってResultSet列値として取得できます。
• Teradata Database 13.10とTeradata JDBC Driver 13.00.00.18からは、UDT値をjava.sql.Struct値としてResultSetの列から取得できるようになりました。(以前のソフトウェア バージョンでは、ResultSetの列からのUDT値の取得はサポートされていません)
• Teradata Database 13.10とTeradata JDBC Driver 13.10.00.07からは、JDBCカスタム タイプのマッピングがサポートされるようになったため、UDTに関連付けられているカスタム タイプのマッピングに応じて、UDT値をResultSet列からアプリケーション クラスのインスタンスとして取得することができます。(以前のソフトウェア バージョンでは、カスタム タイプのマッピングはサポートされていません。)
• Teradata Database 13.10とTeradata JDBC Driver 13.00.00.18からは、ストアド プロシージャのINOUTまたはOUTパラメータからの出力UDT値を、java.sql.Struct値として取得できるようになりました。(以前のソフトウェア バージョンでは、ストアド プロシージャのINOUTまたはOUTパラメータからの出力UDT値の取得はサポートされていません)
• Teradata Database 13.10とTeradata JDBC Driver 13.10.00.07からは、ストアド プロシージャのINOUTまたはOUTパラメータからの出力UDT値を、UDTに関連付けられているカスタム マッピングに応じて、アプリケーション クラスのインスタンスとして取得できるようになりました。(以前のソフトウェア バージョンでは、カスタム タイプのマッピングはサポートされていません。)
• ユーザー定義メソッド(UDM)は、classpathで使用できるクライアント リソースのソース ファイルを使用するか、データベース サーバーにあるソース ファイルを使用して作成できます。

UDTメタデータ

UDTメタデータは、DatabaseMetaData、ResultSetMetaData、およびParameterMetaDataメソッドから使用できます。

UDTの制約

Geospatial (地理空間)データ タイプを、java.sql.Structで使用することはできません。

ResultSetMetaDataのgetColumnDisplaySizeメソッドは、STRUCTURED型UDTの列値にゼロを返します。

UDTの属性がLOBデータ タイプの場合、アプリケーションはInputStreamを使用してLOB属性の値を設定することはできません。アプリケーションでは、Blob値またはClob値(それぞれ、getBlobメソッドまたはgetClobメソッドで取得する)を使用してLOB属性の値を設定する必要があります。

Connection createStructメソッドで作成されたStructオブジェクトは、JDBCカスタム タイプのマッピングの対象とはなりません。そのgetAttributesメソッドは、作成時に指定された属性値を返します。

DISTINCTのUDTであるストアド プロシージャINOUTパラメータでは、カスタム タイプのマッピングはサポートされません。

PERIODデータ タイプ

Teradata Database 13.10とTeradata JDBC Driver 13.00.00.18からは、java.sql.StructでPERIODデータ タイプが使用できるようになりました。

• PERIOD(DATE)
• PERIOD(TIME)
• PERIOD(TIME WITH TIME ZONE)
• PERIOD(TIMESTAMP)
• PERIOD(TIMESTAMP WITH TIME ZONE)

アプリケーションは各Periodデータ値を、2つの属性を持つjava.sql.Struct値として作成する必要があります。最初の属性は期間の開始に、2番目の属性は期間の終了に対応します。PERIODデータ タイプについての詳細は、「Teradata Vantage™ データ タイプおよびリテラル」のPERIODデータ タイプについての説明を参照してください。

• アプリケーションは各PERIOD(DATE)値を、2つのjava.sql.Date属性を持つjava.sql.Struct値として作成する必要があります。
• アプリケーションは各PERIOD(TIME)値を、2つのjava.sql.Time属性を持つjava.sql.Struct値として作成する必要があります。
• Teradata JDBC Driver 14.10.00.26以降、アプリケーションは各PERIOD(TIME WITH TIME ZONE)値を2つのjava.sql.Struct属性を持つjava.sql.Struct値として作成できます。2つの入れ子java.sql.Struct値にはそれぞれ2つの属性が必要です。java.sql.Time値、およびTimeZone属性が目的のタイムゾーンを指定するCalendar値です。Teradata JDBC Driver 14.10.00.26より前のバージョンでは、PERIOD値内でタイムゾーン コンポーネントがサポートされておらず、アプリケーションは各PERIOD(TIME WITH TIME ZONE)値を2つのjava.sql.Time属性を持つjava.sql.Struct値として作成する必要があります。
• アプリケーションは各PERIOD(TIMESTAMP)値を、2つのjava.sql.Timestamp属性を持つjava.sql.Struct値として作成する必要があります。
• Teradata JDBC Driver 14.10.00.26以降、アプリケーションは各PERIOD(TIMESTAMP WITH TIME ZONE)値を2つのjava.sql.Struct属性を持つjava.sql.Struct値として作成できます。2つの入れ子java.sql.Struct値にはそれぞれ2つの属性が必要です。java.sql.Timestamp値、およびTimeZone属性が目的のタイムゾーンを指定するCalendar値です。Teradata JDBC Driver 14.10.00.26より前のバージョンでは、PERIOD値内でタイムゾーン コンポーネントがサポートされておらず、アプリケーションは各PERIOD(TIMESTAMP WITH TIME ZONE)値を2つのjava.sql.Timestamp属性を持つjava.sql.Struct値として作成する必要があります。

PERIOD(TIME WITH TIME ZONE)値を送信する例

java.sql.Structインターフェースを実装するクラスは、アプリケーションが提供する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

アプリケーションはこのクラスのインスタンスを使用して、PERIOD(TIME WITH TIME ZONE)値を作成します。

Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("GMT+08:00")) ;

Time time1 = Time.valueOf( ...

Time time2 = Time.valueOf( ...

// Teradata JDBC Driver 14.10.00.26 以降で使用可能

Struct timetz1 = new MyStruct("TIME WITH TIME ZONE", new Object [] {time1, cal}) ;

Struct timetz2 = new MyStruct("TIME WITH TIME ZONE", new Object [] {time2, cal}) ;

// 2つの列を持つテーブルを想定する。INTEGERとPERIOD(TIME WITH TIME ZONE)

PreparedStatement ps = con.prepareStatement ("INSERT INTO MyTable VALUES(?,?)") ;

ps.setInt(1, id) ;

ps.setObject(2, new MyStruct("PERIOD(TIME WITH TIME ZONE)", new Object [] {timetz1, timetz2})) ;

ARRAYデータ タイプ

Teradata Database 14.0とTeradata JDBC Driver 14.00.00.04からは、java.sql.ArrayインターフェースおよびSQL ARRAYデータ タイプがサポートされています。Teradata SQL ARRAYは、1つ以上の次元で定義されており、同じデータ タイプの多くの値をシーケンシャルに、あるいはマトリックスのようなフォーマットで保管する場合に使用されます。

配列の規則および制限

アプリケーションは、データベースに送信するjava.sql.Array値を作成するためにConnection createArrayOfメソッドを使用できます。createArrayOfメソッドのObject[]引数は、1次元のObject[]配列または多次元のObject[][][]...配列にできますが、配列は以下の規則に従う必要があります。

• nullを指定できるのは最も内側の配列のみです。
• 最も内側の配列内の非nullデータ値は、同じデータ タイプでなければなりません。
• 多次元配列の最も内側以外のすべての配列には、非nullのObject[]値のみが含まれている必要があります。
• 最も外側の配列の長さは、ゼロから最も外側の次元に定義されている最大値までの範囲になります。
• 1次元配列は、最も外側の配列(長さの範囲はゼロから配列に定義された最大値に指定できる)と最も内側の配列(nullを含めることができる)の両方であると見なされます。
• 多次元配列の場合、最も外側以外の次元の最後以外の配列では、その次元に定義された最大値と同じ長さを持っている必要があります。
• 多次元配列の場合、最も外側以外の次元の最後の配列の長さは、1からその次元に定義された最大値までの範囲にできます。
• Connection createArrayOfメソッドで作成されたArrayオブジェクトは、ArrayメソッドgetArrayおよびgetResultSetのUDTエレメントのJDBCカスタム タイプのマッピングの対象とはなりません。
• 多次元配列では、ArrayメソッドgetArray(long index, int count)およびgetArray(long index, int count, Map map)はサポートされていません。
• 多次元配列では、Array getResultSetメソッドのいずれもサポートされません。

SQL ARRAYデータ タイプについての詳細は、「Teradata Vantage™ データ タイプおよびリテラル」のARRAY/VARRAYデータ タイプについての説明を参照してください。

XMLデータ タイプ

Teradata Database 14.10とTeradata JDBC Driver 14.00.00.19からは、java.sql.SQLXMLインターフェースおよびSQL XMLデータ タイプがサポートされています。アプリケーションはTeradata JDBC Driverを使用して、データベースへのXMLデータ送信や、データベースからのXMLデータ受信を実行できます。java.sql.SQLXMLインターフェースはJDK 6.0以降で使用できます。SQLXMLはJDK 5.0以前では使用できません。

• アプリケーションはConnection createSQLXMLメソッドを使用して空のSQLXMLオブジェクトを作成し、いずれかのSQLXMLメソッド(setBinaryStream、setCharacterStream、setResult、またはsetString)を使用して、SQLXMLオブジェクトのデータを指定することができます。アプリケーションは後でSQLXMLオブジェクトをPreparedStatementまたはCallableStatementパラメータ マーカーにバインドできます。
• アプリケーションはデータベース内のXML値をSQLXMLオブジェクトとして受け取ります。アプリケーションはSQLXMLメソッド(getBinaryStream、getCharacterStream、getSource、またはgetString)のいずれかを使用して、SQLXMLオブジェクトからXMLデータを取得します。

SQLXMLの機能および制限

• SQLXMLの機能を使用するには、JDK 6.0以降が必要です。
• SQLXML getSourceメソッドを呼び出すと、sourceClassパラメータがNullの場合、SQLExceptionがスローされます。
• SQLXML setResultメソッドを呼び出すと、resultClassパラメータがNullの場合、SQLExceptionがスローされます。
• SQLXMLオブジェクトのsetまたはgetメソッドのいずれかが呼び出されると、SQLXMLオブジェクトが書き込み不可および読み取り不可になります。
• SQLXML setBinaryStreamメソッドには、UTF8でエンコードされた文字を含むOutputStream引数が必要です。
• SQLXML getCharacterStreamメソッドはUTF8でエンコードされた文字ストリームを返します。

XML External Entity (XXE)対策

XMLライブラリーを使用するJavaアプリケーションは、ほとんどのJava XMLパーサーのデフォルト設定がプロセスXML外部エンティティーであるため、XXE攻撃に対して脆弱です。Teradata JDBC Driverは、DocumentBuilderFactoryを使用してデータベースから返されたXML値を解析します。 Teradata JDBC Driver 16.20.00.10から、DocumentBuilderFactoryにおけるDocument Type Definition（DTD）処理が無効になり、ほとんどのXMLエンティティ攻撃が阻止されます。アプリケーションでこの機能が必要な場合は、XXE_PROCESSING = ONの接続パラメータを指定してください。

JDK6およびJDK7の初期のビルドでは、DTD処理が無効になっているとNullPointerExceptionが発生するJava Bug(JDK-7157610)の影響を受けます。最善の解決策は、Java Bug(JDK-7157610)の修正が含まれるJDKのバージョンにアップグレードすることです。Java Bug(JDK-7157610)の回避策としては、XXE_PROCESSING=ONの接続パラメータを指定してください。

SQL XMLデータ タイプについての詳細は、「Teradata Vantage™ データ タイプおよびリテラル」のSQL XMLデータ タイプについての説明を参照してください。

NUMBERデータ タイプ

Teradata Database 14.0とTeradata JDBC Driver 14.00.00.09からは、SQL NUMBERデータ タイプがサポートされています。JDBCデータ タイプの識別子Types.NUMERICはSQL NUMBERデータ タイプに対応しています。

Teradata Database 14.0とTeradata JDBC Driver 14.00.00.09からは、アプリケーションがBigDecimal値をPreparedStatementパラメータ マーカーにバインドした場合、Teradata JDBC Driverはデフォルトの動作として、BigDecimal値をSQL NUMBERデータ タイプとしてデータベースに送信します。アプリケーションはこの動作を上書きして、BigDecimal値をSQL DECIMALデータ タイプとしてデータベースに送信するようTeradata JDBC Driverに強制できます。さらに、データベースから受信したSQL NUMBER値は、Types.NUMERIC、およびBigDecimal値としてアプリケーションに提供されます。

以前のソフトウェア バージョンでは、Teradata JDBC DriverはBigDecimal値をSQL DECIMALデータ タイプとしてデータベースに送信します。SQL NUMBERデータ タイプはサポートされていません。

データベースでは、特定のパラメータ マーカーにバインドされたPreparedStatementバッチのすべてのデータ値を同じデータ タイプにする必要があります。アプリケーションは、パラメータ マーカーにバインドされたすべての値がNUMBERとDECIMALの組み合わせではなくいずれかになるように、null値と非null値を適切にバインドする必要があります。

SQL NUMBERデータ タイプについての詳細は、「Teradata Vantage™ データ タイプおよびリテラル」の数値データ タイプについての説明を参照してください。

INTERVALデータ タイプ

Teradata JDBC Driver 14.10.00.26以降、アプリケーションはPreparedStatementまたはCallableStatement setObjectメソッドを使用して、Struct値を疑問符パラメータ マークにINTERVALデータ タイプとしてバインドできます。Teradata JDBC Driver 14.10.00.26より前のバージョンでは、INTERVAL値をバインドするためにsetStringメソッド必要でした。setStringメソッドはINTERVAL値に対して引き続き以前と同じように機能します。アプリケーションが新しい機能を使用する必要があるのは、setStringメソッドが対応できない場合のみです。このような場合の例を次に示します。

アプリケーションは各INTERVALデータ値を、1つの属性を持つjava.sql.Struct値として作成する必要があります。Structの唯一の属性は、INTERVAL値の文字表現を含むString値にする必要があります。

アプリケーションは、String内のINTERVAの桁数がINTERVALデータ タイプのINTERVALのデフォルト桁数と一致するかを確認します。INTERVAL...SECONDデータ タイプの場合、アプリケーションはString内の小数点以下桁数がINTERVALデータ タイプのデフォルトの小数点以下桁数と一致するかも確認します。次の表に、SQLタイプの名前、および各INTERVAL データ タイプに必要な桁数を示します。

java.sql.Structインターフェースを実装するクラスは、アプリケーションが提供する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

アプリケーションはこのクラスのインスタンスを使用して、INTERVAL値を作成します。

データベースの組み込み型EXTRACT関数の呼び出し例

この例では、INTERVAL YEAR TO MONTHとして56年3か月を送信します。EXTRACT YEAR FROM式によって値56が抽出されます。WHERE句の条件によって、年数が50を超えているかどうかがテストされます。この場合、単一行のResultSetが返され、そこに値'Y'が格納されています。

  PreparedStatement ps = con.prepareStatement("SELECT 'Y' WHERE EXTRACT(YEAR FROM ?) > 50") ;

  ps.setObject(1, new MyStruct("INTERVAL YEAR TO MONTH", new Object [] {"56-03"})) ;

  ResultSet rs = ps.executeQuery() ;

INTERVAL値の暗黙的なタイプ変換の例

この例では、INTERVAL YEAR TO MONTH宛先列にINTERVAL YEAR値を挿入し、データベースを利用してINTERVAL YEARからINTERVAL YEAR TO MONTHへの暗黙的なタイプ変換を実行します。

  // 単一のINTERVAL YEAR TO MONTH列を持つテーブルを想定する

  PreparedStatement ps = con.prepareStatement("INSERT INTO MyTable VALUES(?)") ;

  ps.setObject(1, new MyStruct("INTERVAL YEAR", new Object [] {"56"})) ;

  ps.executeUpdate() ;

PreparedStatementバッチにNULLと非NULL両方の間隔値を挿入する例

以下に、PreparedStatementバッチによってNULLおよび非NULLのINTERVAL YEAR値をINTERVAL YEAR宛先列に挿入する例を示します。

  // 単一のINTERVAL YEAR列を持つテーブルを想定する

  PreparedStatement ps = con.prepareStatement("INSERT INTO MyTable VALUES(?)") ;

  ps.setObject(1, new MyStruct("INTERVAL YEAR", new Object [] {"56"})) ;

  ps.addBatch() ;

  ps.setObject(1, new MyStruct("INTERVAL YEAR", new Object [] {null})) ;

  ps.addBatch() ;

  ps.executeBatch() ;

JSONデータ タイプ

Teradata Database 15.0およびTeradata JDBC Driver 15.00.00.11から、JSONデータ タイプがサポートされます。JDBC APIはまだ標準JSONデータ タイプを定義しないので、Teradata JDBC Driverは、アプリケーションがPreparedStatementまたはCallableStatement setObjectメソッドを使用してStruct値を疑問符パラメータ マーカーにJSONデータ タイプとしてバインドできるように、Teradata固有の機能を提供します。アプリケーションはVARCHAR値およびCLOB値をJSON宛先列に挿入することもできます。アプリケーションがJSONデータ タイプの組み込み関数を十分活用できるように、Struct値を使用してJSON疑問符パラメータ マーカーを設定する必要があります。(下記例を参照)

データベースはJSON値をCLOB値として返します。アプリケーションは以下のメタデータ メソッドを使用してJSON値と実際のCLOB値を区別できます。これらのメソッドは"JSON"を返してJSON値を示し、"CLOB"を返してCLOB値を示します。

• ResultSetMetaData getColumnTypeName
• ParameterMetaData getParameterTypeName

アプリケーションが、JSON値をStruct値として指定するTeradata固有の機能を使用する場合、Struct値には以下のいずれかの属性が含まれている必要があります。

• String
• java.io.Reader
• java.sql.Clob
• NULL

また、StructにReader属性が含まれる場合、Structには、ストリームの文字数を指定する整数タイプとなる第2の属性が含まれる必要があります。

アプリケーションが、JSON値をStruct値として指定するTeradata固有の機能を使用する場合、java.sql.Structインターフェースを実装するクラスは、アプリケーションが提供する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

アプリケーションは、そのクラスのインスタンスを使用してJSON値を作成します。

JSONデータ タイプ結合メソッドの呼び出し例

この例では2つのJSON値を結合して単一のJSONオブジェクトを生成します。この場合、単一行のResultSetが返され、そこに値{"name" :"Jim","name" :"Joe"}が格納されています。

  PreparedStatement ps = con.prepareStatement("SELECT CAST(?AS JSON).combine(?)") ;

  ps.setObject(1, new MyStruct("JSON", new Object [] {"{\"name\" : \"Jim\"}"})) ;

  ps.setObject(2, new MyStruct("JSON", new Object [] {"{\"name\" : \"Joe\"}"})) ;

  ResultSet rs = ps.executeQuery() ;

PreparedStatementバッチにNULLおよび非NULLのJSON値を挿入する例

次に、PreparedStatementバッチによってNULLおよび非NULLのJSON値をJSON宛先列に挿入する例を示します。

  // INTEGERカラムとJSONカラムを持つテーブルを想定する

  PreparedStatement ps = con.prepareStatement("INSERT INTO MyTable VALUES(?, ?)") ;

  ps.setInt(1, 123) ;

  ps.setObject(2, new MyStruct("JSON", new Object [] {"{\"name\" : \"Kimberly\"})) ;

  ps.addBatch() ;

  ps.setInt(1, 456) ;

  ps.setObject(2, new MyStruct("JSON", new Object [] {null})) ;

  ps.addBatch() ;

  ps.executeBatch() ;

JSONデータ タイプ非互換エラー

アプリケーションが、Teradata Database 15.0以降でJSONデータ タイプをサポートしない古いバージョンのTeradata JDBC Driverと連携し、JSON値をStruct値として指定するTeradata固有の機能を使用しようとすると、以下の例外がスローされる場合があります。この解決策としては、JSONデータ タイプをサポートする、より新しいバージョンのTeradata JDBC Driverにアップグレードします。

アプリケーションが、Teradata Database 14.10以前のバージョンでJSONデータ タイプをサポートするバージョンのTeradata JDBC Driverと連携し、JSON値をStruct値として指定するTeradata固有の機能を使用しようとすると、以下の例外がスローされる場合があります。この解決策としては、Teradata Database 15.0以降にアップグレードします。

アプリケーションが、JSONデータ タイプをサポートしないTeradata JDBC Driverの古いバージョンを使用しながら、データベースからJSONデータ値を返すクエリーを実行する場合、以下の例外がスローされる場合があります。この解決策としては、JSONデータ タイプをサポートする、より新しいバージョンのTeradata JDBC Driverにアップグレードします。

DATASETデータ タイプ

データベースのDATASETデータ型は、各データ値がファイル全体またはドキュメント全体に対応する複雑なデータ型です。保存できるファイルまたはドキュメントのタイプは、DATASETデータ型の関連する「ストレージ フォーマット」で指定できます。

DATASETストレージ形式のAvro

Teradata Database 16.0およびTeradata JDBC Driver 15.10.00.23以降では、DATASETデータ型でAvroストレージ フォーマットが提供されます。JDBC APIはまだ標準DATASETデータ型を定義しないので、Teradata JDBC Driverは、アプリケーションがPreparedStatementまたはCallableStatement setObjectメソッドを使用してStruct値を疑問符パラメータ マーカーにAvroフォーマットDATASETデータ型としてバインドできるように、Teradata固有の機能を提供します。アプリケーションでは、VARBYTE値とBLOB値をAvroフォーマットDATASET宛先列に挿入することもできます。アプリケーションがDATASETデータ型の組み込み関数を十分活用できるようにするには、Struct値を使用してDATASET疑問符パラメータ マーカーを設定する必要があります(下記例を参照)。

データベースは、AvroフォーマットDATASET値をBLOB値として返します。アプリケーションでは、以下のメタデータ メソッドを使用してAvroフォーマットDATASET値と実際のBLOB値を区別できます。これらのメソッドでは、AvroフォーマットDATASET値を示す"DATASET STORAGE FORMAT AVRO"を返し、BLOB値を示す”BLOB"を返します。

• ResultSetMetaData getColumnTypeName
• ParameterMetaData getParameterTypeName

アプリケーションがAvroフォーマット値をStruct値として指定するTeradata固有の機能を使用する場合、Struct値には以下のいずれかの属性が含まれている必要があります。

• byte array
• java.io.InputStream
• java.sql.Blob
• NULL

また、StructにInputStream属性が含まれる場合、Structには、ストリームのバイト数を指定する整数タイプとなる第2の属性が含まれる必要があります。

AvroフォーマットDATASET値をStruct値として指定するTeradata固有の機能を使用するため、アプリケーションでは、java.sql.Structインターフェースを実装するクラスを用意する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

次にアプリケーションでは、そのクラスのインスタンスを使用してAvroフォーマットDATASET値を作成します。

AVRO_CHECK関数の呼び出し例

この例では、AvroフォーマットDATASET値を検証します。この場合は、値"OK"を含む単一行のResultSetが返されます。

  PreparedStatement ps = con.prepareStatement("SELECT AVRO_CHECK(?)") ;

  ps.setObject(1, new MyStruct("DATASET STORAGE FORMAT AVRO", new Object [] {avroInputStream, nLength})) ;

  ResultSet rs = ps.executeQuery() ;

PreparedStatementバッチへのNULLおよび非NULL AvroフォーマットDATASET値の挿入例

以下に、PreparedStatementバッチによってNULLおよび非NULLのAvroフォーマットDATASET値をAvroフォーマットDATASET宛先列に挿入する例を示します。

  // INTEGERカラムとDATASET STORAGE FROMAT AVROカラムを持つテーブルを想定する

  PreparedStatement ps = con.prepareStatement("INSERT INTO MyTable VALUES(?, ?)") ;

  ps.setInt(1, 123) ;

  ps.setObject(2, new MyStruct("DATASET STORAGE FORMAT AVRO", new Object [] {avroInputStream, nAvroLength})) ;

  ps.addBatch() ;

  ps.setInt(1, 456) ;

  ps.setObject(2, new MyStruct("DATASET STORAGE FORMAT AVRO", new Object [] {null})) ;

  ps.addBatch() ;

  ps.executeBatch() ;

DATASETストレージ形式のCSV

Teradata Advanced SQL Engine 16.20およびTeradata JDBC Driver 16.20.00.01以降では、DATASETデータ型でカンマ区切り値(CSV)のストレージ フォーマットが提供されます。JDBC APIはまだ標準DATASETデータ型を定義しないので、Teradata JDBC Driverは、アプリケーションがPreparedStatementまたはCallableStatement setObjectメソッドを使用してStruct値を疑問符パラメータ マーカーにCSVフォーマットDATASETデータ型としてバインドできるように、Teradata固有の機能を提供します。アプリケーションでは、VARBYTE値とCLOB値をCSVフォーマットDATASET宛先列に挿入することもできます。アプリケーションがDATASETデータ型の組み込み関数を十分活用できるようにするには、Struct値を使用してDATASET疑問符パラメータ マーカーを設定する必要があります(下記例を参照)。

データベースは、CSVフォーマットDATASET値をCLOB値として返します。アプリケーションでは、以下のメタデータ メソッドを使用してCSVフォーマットDATASET値と実際のCLOB値を区別できます。これらのメソッドは、CSVフォーマットDATASET値を示す"DATASET STORAGE FORMAT CSV"を返し、CLOB値を示す"CLOB"を返します。

• ResultSetMetaData getColumnTypeName
• ParameterMetaData getParameterTypeName

アプリケーションがCSVフォーマット値をStruct値として指定するTeradata固有の機能を使用する場合、Struct値には以下のいずれかの属性が含まれている必要があります。

• String
• java.io.Reader
• java.sql.Clob
• NULL

また、StructにReader属性が含まれる場合、Structには、Readerの文字数を指定する整数型となる第2の属性が含まれる必要があります。

CSVフォーマットDATASET値をStruct値として指定するTeradata固有の機能を使用するため、アプリケーションでは、java.sql.Structインターフェースを実装するクラスを用意する必要があります。

public class MyStruct implements java.sql.Struct

{

  private String m_typeName ;

  private Object [] m_attributes ;

  public MyStruct(String typeName, Object [] attributes) { m_typeName = typeName ; m_attributes = attributes ; }

  public String getSQLTypeName() { return m_typeName ; }

  public Object [] getAttributes() { return m_attributes ; }

  public Object [] getAttributes(java.util.Map map) { return m_attributes ; }

}

次にアプリケーションでは、そのクラスのインスタンスを使用してCSVフォーマットDATASET値を作成します。

validateメソッドの呼び出し例

この例では、CSVフォーマットDATASET値を検証します。このケースでは、当てはまる場合は整数値1を格納した単一行のResultSetが返され、当てはまらない場合は0を格納した単一行のResultSetが返されます。

  PreparedStatement ps = con.prepareStatement("SELECT CAST (? as DATASET STORAGE FORMAT CSV).validate ()") ;

  ps.setObject(1, new MyStruct("DATASET STORAGE FORMAT CSV", new Object [] {csvReader, nLength})) ;

  ResultSet rs = ps.executeQuery() ;

PreparedStatementバッチへのNULLおよび非NULL CSVフォーマットDATASET値の挿入例

以下に、PreparedStatementバッチによってNULLおよび非NULLのCSVフォーマットDATASET値をCSVフォーマットDATASET宛先列に挿入する例を示します。

  // INTEGERカラムとDATASET STORAGE FROMAT CSVカラムを持つテーブルを想定する

  PreparedStatement ps = con.prepareStatement("INSERT INTO MyTable VALUES(?, ?)") ;

  ps.setInt(1, 123) ;

  ps.setObject(2, new MyStruct("DATASET STORAGE FORMAT CSV", new Object [] {csvReader, nCSVLength})) ;

  ps.addBatch() ;

  ps.setInt(1, 456) ;

  ps.setObject(2, new MyStruct("DATASET STORAGE FORMAT CSV", new Object [] {null})) ;

  ps.addBatch() ;

  ps.executeBatch() ;

DATASETデータ タイプ非互換エラー

DATASETデータ タイプをサポートしないTeradata JDBC Driverの古いバージョンを使用しながら、データベースからAvroフォーマットDATASETデータ値を返す問合わせをアプリケーションで実行する場合、以下の例外がスローされる場合があります。

DATASETデータ タイプをサポートしない古いバージョンのTeradata JDBC Driverと連携し、アプリケーションがTeradata Database 16.0以降でAvroフォーマットDATASET値をStruct値としてバインドするTeradata固有の機能を使用しようとすると、以下の例外がスローされます。この解決策は、DATASETデータ タイプをサポートする、より新しいバージョンのTeradata JDBC Driverにアップグレードすることです。

AvroフォーマットDATASETデータ タイプをサポートするバージョンのTeradata JDBC Driverと連携し、アプリケーションがTeradata Database 15.10以前のバージョンでAvroフォーマットDATASET値をStruct値としてバインドするTeradata固有の機能を使用しようとすると、以下の例外がスローされます。この解決策は、Teradata Database 16.0以降にアップグレードすることです。

DATASETデータ型をサポートしない古いバージョンのTeradata JDBC Driverを使用しながら、データベースからCSVフォーマットDATASETデータ型を返すクエリーをアプリケーションで実行する場合、データ型がCLOBとして返されます。

DATASETデータ型をサポートしない古いバージョンのTeradata JDBC Driverと連携し、アプリケーションがTeradata Advanced SQL Engine 16.20以降でCSVフォーマットDATASET値をStruct値としてバインドするTeradata固有の機能を使用しようとすると、以下の例外がスローされます。この解決策は、DATASETデータ型をサポートする、より新しいバージョンのTeradata JDBC Driverにアップグレードすることです。

CSVフォーマットDATASETデータ型をサポートするバージョンのTeradata JDBC Driverと連携し、アプリケーションがTeradata Database 16.10以前のバージョンでCSVフォーマットDATASET値をStruct値としてバインドするTeradata固有の機能を使用しようとすると、以下の例外がスローされます。この解決策は、Teradata Advanced SQL Engine 16.20以降にアップグレードすることです。

更新可能LOB

一時表

LOB更新をTeradata JDBC Driverで使用できるようにするためには、以下の列が入った表を作成しておく必要があります。

• id INTEGER
• bval BLOB
• cval CLOB

通常のアプリケーションの使用においては、データベース管理者がグローバル一時表(GTT)として表を作成します。ただし、通常の表を作成して、その表をデバッグなどの特殊な用途のケースで使用することもできます。

id integer列は、基本索引として使用します。必要であれば、固有基本索引に指定することが可能です。

CREATE TABLEによってGTTを作成する場合は、ON COMMIT PRESERVE ROWS句を指定して、Teradata JDBC DriverがトランザクションすべてでLOBを操作できるようにする必要があります。

下記の例に示されているテーブル名JdbcLobUpdateは、一例でしかありません。表には任意の名前を選択できます。

create global temporary table JdbcLobUpdate(

    id integer not null,

    bval blob,

    cval clob character set unicode)

  unique primary index upi_JdbcLobUpdate(id)

  on commit preserve rows

接続パラメータ

一時表として選択した名前は、接続パラメータLOB_TEMP_TABLEに設定する必要があります。

LOB_TEMP_TABLE=tableName

データベース名は、必要に応じて指定できます。

LOB_TEMP_TABLE=databaseName.tableName

LOBの更新

アプリケーションで表内の既存のLOB値を更新する必要がある場合は、いずれかのLOB更新メソッドを呼び出した後でUPDATE文も実行して、変更後のLOB値を元の行に戻さなければなりません。

Teradata JDBC Driverは、実装によってLOBのコピーが更新されたことを示すために、DatabaseMetaData locatorsUpdateCopyからtrueを返します。

ResultSet rs = stmt.executeQuery("SELECT id,data FROM datatab");

rs.next();

int id = rs.getInt(1);

Blob data = rs.getBlob(2);

int numWritten = data.setBytes(1, val);

if (dbmd.locatorsUpdateCopy() == true){

  PreparedStatement ps = conn.prepareStatement(

   "UPDATE datatab SET data = ? WHERE id = ?");

  try {

    ps.setBlob(1, data);

    ps.setInt(2, id);

    ps.executeUpdate();

  } finally {

    ps.close();

  }

}

freeの呼び出し

freeメソッドはBlobまたはClobオブジェクトが保持しているリソースを解放します。freeが呼び出された後は、そのオブジェクトを使用することはできません。

freeメソッドは、Teradata JDBC Driver 14.00.00.08から使用できるようになりました。BlobまたはClobオブジェクトを更新した場合、アプリケーションは、そのオブジェクトの使用が終わったときにfreeを呼び出す必要があります。そうしないと、データベース エラー3130 (応答制限超過)が発生する場合があります。

JDK 6.0以降では、freeメソッドはjava.sql.Blobおよびjava.sql.Clobインターフェースで定義されており、アプリケーションによって直接呼び出すことができます。JDK 5.0以前では、リフレクションを使用してfreeメソッドを呼び出す必要があります。

Integer.MAX_VALUEを超える行番号と更新件数

データベースは数10億の行を含む表に対応できますが、行番号や更新件数を使用するJDBC APIメソッドは符号付きの32ビット整数(Java int)を使用して行数または更新件数を表わします。符号付き32ビット整数で保持できる最大の正数は、約20億です。これは定数Integer.MAX_VALUEで示されます。

行番号

ResultSetメソッドの中には、行番号を引数として取るものや、行番号を返すものがあります。大きな結果セットには20億を超える行が含まれている可能性がありますが、ResultSetメソッドは当初の行数のみを利用できるように制限されていて、行番号はInteger.MAX_VALUE未満になります。

更新件数

Teradata Database 14.10およびTeradata JDBC Driver 14.00.00.25以降、データベースから受け取った行数の値が大きすぎて、符号付き32ビット正数に収まらない場合、Teradata JDBC DriverはInteger.MAX_VALUEの更新件数をアプリケーションに返して、エラー コード1474のSQLWarningを送り、メッセージ テキスト内に実際の行数を示します。

この動作は、次のJDBC APIメソッドで行なわれます。

マルチスレッドの問題

マルチスレッドを使用すると、アプリケーションのパフォーマンスを向上させることができます。複数の同時セッションによって同時に実行できる要求を判別し、各セッションで要求の実行を依頼します。ただし、同時要求を１セッションに複数、実行依頼することは避けてください。

注:  データベースは、1つのセッションに対する複数のアクティブ要求をサポートしていません。アプリケーションが同時要求を1セッションに複数、実行依頼すると、前の要求が戻るまでTeradata JDBC Driverはブロックします。したがって、アプリケーションのパフォーマンスを低下させる可能性があります。

表13 に、JDBCオブジェクト スレッド セーフの情報を示します。

DatabaseMetaDataメソッドによるデータ ディクショナリのアクセス

Teradata JDBC DriverのDatabaseMetaDataメソッドのいくつかは、DatabaseMetaDataのメソッドを呼び出すアプリケーションの代わりに、データベースに対して問合わせの実行を依頼します。アプリケーションの設計者は、必要なデータ ディクショナリの表とビューアクセスするために、そのアプリケーションに十分な権限を与えていることを確認する必要があります。

次の表は、データ ディクショナリの表やビューに問合わせを行う各DatabaseMetaDataメソッドと、それら各メソッドに必要なアクセス権限のリストです。

Teradata JDBC Driver13.00.00.25からは、Teradata Database 12.0以降に接続したときにデータ ディクショナリVビューが使用されます。次の表に記された[V]という接尾辞は、データベース バージョンによる条件でVビューが使用されるかどうかを示します。

USEXVIEWS接続パラメータでは、通常のビューとXビューのどちらを使用するかを制御します。次の表に記された[X]という接尾辞は、USEXVIEWS接続パラメータの設定による条件でXビューが使用されるかどうかを示します。

Sun JDK 5.0実装のJDBC RowSetインターフェースの使用

Teradata JDBC Driverは、Sun JDK 5.0実装のJDBC RowSetインターフェースが動作します。

com.sun.rowset.JdbcRowSetImpl(java.sql.Connection connection)とcom.sun.rowset.JdbcRowSetImpl(String url, String user, String password)の使用時には、Connection.prepareStatement(String sql, ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE)が呼び出されます。ただし、12.0より前のデータベース バージョンについては、CONCUR_UPDATABLEはサポートされていません。

Teradata JDBC Driverは、データベース バージョンが12.0より前の場合や、取り出した結果セットをTeradata Database 12.0以降用に更新できない場合に、サポートされていないResultSet並列性(CONCUR_UPDATABLE)を、サポートされている並列性(CONCUR_READ_ONLY)にダウングレードします。更新可能結果セットの使用法の詳細については、「結果セットの更新可能化」を参照してください。

暗号化、認証、許可

Teradata JDBC Driverには、ログオンメカニズムを選択するためのLOGMECH接続パラメータがあります。 使用可能なログオ ンメカニズムは下記のとおりです。

• TD2 — Teradata Method 2
• BROWSER — ブラウザ認証、Teradata Advanced SQL Engine17.10およびTeradataJDBC Driver17.10.00.01以降で使用できます。
• JWT — JSON Web Token、Teradata Advanced SQL Engine 16.20およびTeradata JDBC Driver 16.20.00.07以降で使用できます。
• KRB5 — Kerberos V5
• LDAP — Lightweight Directory Access Protocol
• TDNEGO — Teradata Database 15.10およびTeradata JDBC Driver 15.10.00.31以降で使用可能な適切なログオンメカニズムを自動的に選択します。

BROWSERおよびJWTメカニズムは、パスワードなしで使用されます。KRB5およびLDAPメカニズムは、パスワードなしで使用できます。パスワードなしでログオンメカニズムを使用するには、ユーザーは「logon with null password」権限を持っている必要があります。

シングルサインオン(SSO)は、BrowserおよびKerberosログオン メカニズムのみでサポートされます。これらのメカニズムについての詳細は、『Teradata Vantage™ セキュリティ管理』を参照してください。

Teradata JDBC Driverでは常に暗号化ログオンを使用します。これは、ネットワークを介してデータベースに送信されるときに、ログオン パスワードが暗号化されることを意味します。

Teradata JDBC Driverには、接続に対してデータ暗号化をオンまたはオフにするためのENCRYPTDATA接続パラメータがあります。ここでの「データ暗号化」とは、非ログオンメッセージ トラフィックの暗号化を意味します。デフォルトでは、Teradata JDBC Driverはログオンのみを暗号化し、ログオン以外のメッセージ トラフィックは暗号化しません。Teradata JDBC Driverがログオン以外のメッセージ トラフィックを暗号化するには、JDBC接続パラメータENCRYPTDATA=ONを指定してください。

URLおよびDataSourceパラメータ

表 14では、認証と暗号化のためのURLとデータソースのパラメータを説明しています。パラメータの取得と設定が可能なメソッドについての説明は、TeraDataSourceクラスに記載されています。

暗号化の場合の「集中管理」は、Teradataクライアント ソフトウェアとデータベースの間でメッセージ トラフィックが確実に暗号化されるようにLDAPディレクトリおよび/またはデータベースを構成することを意味します。

特定のユーザーのメッセージ トラフィック暗号化を必要とするようにLDAPディレクトリを構成する方法については、『Teradata Vantage™ セキュリティ管理』の章「ネットワーク セキュリティ ポリシーの管理」の「機密性QOPポリシーの構成」セクションを参照してください。

gtwcontrolコマンドを使用し、すべてのデータベース ユーザーでメッセージ トラフィック暗号化が必要とされるようにする方法については、『Teradata Vantage™ セキュリティ管理』の章「ネットワーク セキュリティ ポリシーの管理」の「機密性の必要」セクションを参照してください。

前提条件

以下のテーブルに、各メソッドの前提条件を示します。

Kerberos前提条件の合致

Kerberosの操作をする前に、システム管理者は次の前提条件に合致させる必要があります。

• Kerberosのドメインとレルムを設定する
• ユーザーをアクティブ ディレクトリ内に定義する
• Kerberosクライアント サポートを検証する
• 各システムにkrb5.iniまたはkrb5.confファイルが含まれていることを確認する
• 各ユーザーがkinitプログラムを実行できることを確認する
• ログイン設定ファイルが正しいことを検証する
• Windowsのレジストリを設定する
• Java VMオプションを指定する
• Kerberos SSOを有効にする

Kerberosのドメインとレルムを設定する

Kerberosのドメインとレルムは、ドメインにあるマシン用に設定します。システム管理者はこの作業を実行する必要があります。『セキュリティ管理ガイド』を参照してください。

ユーザーをアクティブ ディレクトリ内に定義する

Kerberosのユーザーをすべて、Windowsドメインのアクティブ ディレクトリ内に定義する必要があります。Kerverosのユーザー名では、大文字と小文字が区別されます。ユーザーは、アクティブ ディレクトリ内で定義されたとおりにマシンにログオンすることが重要です。DR818999としてアクティブ ディレクトリに定義されたユーザーは、dr818999(大文字と小文字の変更)としてドメインにログオンできますが、Kerberosが動作するためには、ユーザーはDR818999としてドメインにログインする必要があります。

注:  アクティブ ディレクトリ内のユーザーの定義で[Kerberos事前認証を必要としない]がチェックされていることを確認します。

Kerberosクライアント サポートを検証する

Kerberos認証は次のクライアント システムでサポートされています。

• Windowsクライアント システム
• Teradata Database 14.10およびTeradata JDBC Driver 14.0以降でのLinuxクライアント システム
• Teradata Database 16.10およびTeradata JDBC Driver 16.0以降でのAIX、HP-UX、およびMacOSクライアント システム

Active DirectoryまたはLinux Kerberos Key Distribution Center（KDC）を使用するようにサポートされているクライアント システムを構成する方法については、「Teradata Vantage™ セキュリティ管理」を参照してください。

各システムにkrb5.iniまたはkrb5.confファイルが含まれていることを確認する

重要なKerberos構成情報は、Windows上ではkrb5.iniファイルに、それ以外のプラットフォームではkrb5.confファイルに指定します。Javaは、次の順序でkrb5.iniまたはkrb5.confを検索します。

• Javaシステム プロパティjava.security.krb5.confが設定されている場合、このプロパティ値がパスとファイル名を示します。
• Javaシステム プロパティjava.security.krb5.confが設定されていない場合、JavaはJREのlib/securityディレクトリ内でkrb5.iniまたはkrb5.confを検索します。
• 最後にJavaは、Windows上のc:\winnt\krb5.iniまたはそれ以外のプラットフォーム上の/etc/krb5.confを検索します。

Windows上のkrb5.iniファイルは、MIT KerberosとHeimdal Kerberosの両方の標準であるkrb5.confファイルと同じです。各種設定の詳細については、MIT Kerberosのドキュメントを参照してください。

次のファイルは例です。修正し、実際のドメイン、レルム、キー配布センター(KDC)を反映する必要があります。

[libdefaults]
ticket_lifetime = 6000
default_realm = ESROOTDOM.ESDEV.TDAT
clockskew = 13000
checksum_type=2
[realms]
ESROOTDOM.ESDEV.TDAT = {
    kdc = esroot.esrootdom.esdev.tdat:88
    default_domain = esrootdom
}
[domain_realm]
esrootdom = {
    .esrootdom = ESROOTDOM.ESDEV.TDAT
    esrootdom = ESROOTDOM.ESDEV.TDAT
}

Linuxクライアントの場合は、krb5.confファイルの[libdefaults]エントリの下に次の行を追加します。

    default_tkt_enctypes = arcfour-hmac rc4-hmac
    default_tgs_enctypes = arcfour-hmac rc4-hmac

レルム名とホスト名の命名規則

DNSドメイン名とホスト名では、大文字と小文字が区別され、規則により小文字で表記されます。

対照的に、Kerberosレルム名は大文字で表記され、大文字と小文字が区別されます。Kerberosレルム名はドメイン名の大文字版です。

Kerberos認証は、krb5.iniまたはkrb5.confファイルでKerberosレルム名が大文字で指定されない限り機能しません。

kinitを実行する

SSOを実行するためには、ユーザーはkinitプログラムを実行できなければなりません。このプログラムは、Kerberosチケット保証チケット(TGT)を取得し、キャッシュします。このプログラムは、Java JDKのjre/binディレクトリにあります。例は以下のとおりです。

C:\j2sdk1.4.2_04\jre\bin>kinit
Password for DR818999@ESROOTDOM.ESDEV.TDAT:Mypassword
New ticket is stored in cache file C:\Documents and Settings\DR818999\krb5cc_DR818999

Credential Delegation(クレデンシャルの委譲)とTeradata Unity Director

KerberosとTeradata Unity Directorを使用している場合、Credential Delegation(クレデンシャルの委譲)を有効にする必要があります。Credential Delegation(クレデンシャルの委譲)を使用するためには、転送可能なチケット保証チケット(TGT)を取得します。この操作を実行するためには、kinitのforwardableオプションを使用します。例えば、次のようにします。

kinit -f

このオプションは、Teradata Unity Directorが認証リクエストをデータベースにルーティングするために使用する必要があります。

krb5.ini(Windows)またはkrb5.conf(Linux)ファイルの[libdefaults]セクション下でforwardable=trueオプションを設定します。Credential Delegation(クレデンシャルの委譲)を使用するために変更された前述のkrb5.iniまたはkrb5.confファイルは、次のようになります。

[libdefaults]
forwardable = true
ticket_lifetime = 6000
default_realm = ESROOTDOM.ESDEV.TDAT
clockskew = 13000
checksum_type=2
[realms]
ESROOTDOM.ESDEV.TDAT = {
    kdc = esroot.esrootdom.esdev.tdat:88
    default_domain = esrootdom
}
[domain_realm]
esrootdom = {
    .esrootdom = ESROOTDOM.ESDEV.TDAT
    esrootdom = ESROOTDOM.ESDEV.TDAT
}

ログイン設定情報の検証

Kerberos認証には、以下のログイン構成ファイルが必要です。このファイルは、選択したディレクトリに格納できます。

com.sun.security.jgss.initiate
{
  com.sun.security.auth.module.Krb5LoginModule sufficient useTicketCache=true;
};
other
{
  com.sun.security.auth.module.Krb5LoginModule required;
};

java.security.auth.login.config Javaシステム プロパティでログイン構成ファイル名を指定できます。

例えば、ログイン構成ファイルに名前TeraJDBC.configを指定し、このファイルを現在のディレクトリに格納する場合、次のJVMコマンド ライン オプションを指定します。

-Djava.security.auth.login.config=TeraJDBC.config

または、ログイン構成ファイルをシステム全体の設定として指定することもできます。JREのjava.securityディレクトリ内にあるlib/securityファイルを編集して、login.config.url.Nプロパティを追加します。

java.securityファイルを確認して、既存のlogin.config.url.Nプロパティがあるかどうかを特定します。既存のプロパティと競合しないように、Nの値を選択する必要があります。また、Nの値は連続した番号である必要があります。

login.config.url.という名前の、Nlogin.config.url.1値が1つだけある例を以下に示します。この例では、構成ファイルはC:\dmr\TeraJDBC.configにあります。

login.config.url.1=file:C:/dmr/TeraJDBC.config

プロパティ値のURLは、フォワード スラッシュで指定する必要があります。Windowsでは、フォワード スラッシュの代わりにバックスラッシュを使用します。

Windowsのレジストリを設定する

Microsoft Windowsの通常の構成では、Kerberos Ticket-Granting Ticket(TGT)のセッション キーのエクスポートは許可されません。Kerberos SSOを使用するためには、Windowsのレジストリ設定を変更してKerberos TGTのセッション キーのエクスポートを有効にする必要があります。

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
  Value Name:AllowTgtSessionKey
  Value Type:REG_DWORD
  Value:      0x01  (default is 0)


Active DirectoryアカウントがクライアントPC上のローカル管理者グループに属する場合、Windowsでは、AllowTgtSessionKeyレジストリ値が0x1に設定されていても、Kerberos TGTのセッション キーをエクスポートしません。したがって、クライアントPC上のローカル管理者グループに属するアカウントでKerberos SSOを使用することはできません。

JVMオプションを指定する

SSOを有効にするためには、JVMオプションを指定する必要があります。

-Djavax.security.auth.useSubjectCredsOnly=false

Kerberos SSOを有効にする

Kerberos SSOログオンを有効にするには、データベースで定義されているユーザーが、ユーザーのログオンパスワードと同じパスワードを持ち、SSOをサポートしている必要があります。 SSOをサポートするには、DDLステートメント

grant logon with null password

が必要です。

例えば、ユーザーdr818999に必要な権限を付与するためには、以下のログオン付与を使用します。

grant logon on all to dr818999 with null password;

このステートメントの詳細については、Teradata Vantage™ Teradata Database SQLデータ定義言語リファレンスを参照してください。

サーバー サイド デフォルト認証メカニズム

Teradataセキュリティ管理者は、デフォルト認証メカニズムをTD2からサーバー サイド(Teradata Database)の別のメカニズムへ変更できます。ただし、管理者は、あるメカニズムは特定のプラットフォームでしかサポートされないことを認識する必要があります。例えば、Teradata Database 14.0以前では、KerberosサポートはWindowsクライアントにのみ制限されます。

サーバー サイドのデフォルト メカニズムを、サイトで使用しているすべてのクライアント プラットフォーム上でサポートされているわけではないメカニズムへ変更する場合は、余分の準備が必要です。サーバー サイドのデフォルト メカニズムを変更する前に、計画されたサーバー サイドのデフォルト メカニズムをサポートしていないクライアント プラットフォーム上のすべてのJavaアプリケーションを、LOGMECH=接続パラメータを使用して、サポートされる認証メカニズムを明示的に指定するように構成する必要があります。

例えば、Teradata Database 14.0以前を使用して、WindowsとLinuxの両方のプラットフォームに展開されるJavaアプリケーションを使用するサイトがあるとします。管理者がサーバー サイドのデフォルト メカニズムをTD2からKerberosへ変更することを決定した場合、管理者は、Linuxに展開されたJavaアプリケーションがLOGMECH=TD2接続パラメータを指定していることを検証する必要があります。

生成キー

Teradata JDBC Driver,のバージョン3.4では、次の各メソッドが追加されるか、次の各メソッドで生成キーをサポートできるようになりました。

• Statement.getGeneratedKeys()
• Statement.executeUpdate(String sql, int autoGeneratedKeys)
• Statement.executeUpdate(String sql, int[] columnIndexes)
• Statement.executeUpdate(String sql, String[] columnNames)
• Statement.execute(String sql, int autoGeneratedKeys)
• Statement.execute(String sql, int[] columnIndexes)
• Statement.execute(String sql, String[] columnNames)
• Connection.prepareStatement(String sql, int autoGeneratedKeys)
• Connection.prepareStatement(String sql, int[] columnIndexes)
• Connection.prepareStatement(String sql, String[] columnNames)

複文要求

複文要求に生成キーが要求されている場合、アプリケーションは、getGeneratedKeys()を呼び出して最初の文の生成キーを取得できます。その後、getGeneratedKeys()を追加呼び出しするたびに、その前に、getMoreResults()を呼び出す必要があります。INSERT文でない場合、空の結果セットが返されます。

JDBCの仕様には、アプリケーションが複文要求から複数の生成キー結果セットを取得する方法は規定されていません。JDBCの仕様では、次の生成キー結果セットに進むためにgetMoreResults()を使用することを要求したり禁止したりしていません。これは、最も明確で直感的な選択のように思われるゆえのTeradata JDBC Driverの設計です。

PreparedStatementバッチ要求

PreparedStatementバッチ要求に生成キーが取得される場合、各行は結合して単一の自動生成キー結果セットになり、getGeneratedKeys()から返されます。バッチ要求内への最大挿入数は1024個に制限されます。 

INSERT …SELECT文

要求がINSERT ... SELECT文である場合、結果セットに複数の行が返されます。各行の順序は決まっていません。

例外

エラー1125

次の場合、One or more of the generated keys specified do not match a column name in the table.(指定された生成キーが1つ以上、テーブル内の列名と一致しません。)Change the list of column names to match the column names in the table where the row is being inserted.(列名のリストを変更して、行が挿入されるテーブル内の列名と一致させてください。)というメッセージが返されることがあります。

• Statement.executeUpdate(String sql, String[] columnNames)
• Statement.execute(String sql, String[] columnNames)
• Connection.prepareStatement(String sql, String[] columnNames)

エラー1126

次の場合、One or more of the generated key indexes are invalid.(1つ以上の生成キー インデックスが無効です。)Change the indexes so that they are greater than 0 and less than or equal to the number of columns in the table where the row is being inserted.(インデックスの数が0より多く、行が挿入されるテーブル内の列数以下になるように、インデックスを変更してください。)というメッセージが返されることがあります。

• Statement.executeUpdate(String sql, int[] columnIndexes)
• Statement.execute(String sql, int[] columnIndexes)
• Connection.prepareStatement(String sql, int[] columnIndexes)

エラー1127

列名配列または列インデックス配列に対応するNULL値が含まれているメソッドが呼び出された場合、Column names array or column index array cannot be null.(列名配列または列インデックス配列はNullになれません。)というメッセージが返されることがあります。

エラー1128

自動生成キーを要求するメソッドが呼び出された場合、AutoGenerated Keys are not supported with this release of database software.(このリリースのデータベース ソフトウェアでは自動生成キーはサポートされていません。)The database must be running V2R6.2 or higher.(V2R6.2以上のTeradata Databaseを実行する必要があります。)というメッセージが返されることがあります。

Statement.executeUpdate()

次の各例外は、現在、PreparedStatement.executeUpdate()に使用されていますが、自動生成キーが要求されているStatement.executeUpdate()に使用されるようになります。

• executeUpdate() cannot be used when a result set is expected; use executeQuery() or execute()(結果セットが期待される場合、executeUpdate()は使用できません。executeQuery()またはexecute()を使用してください)
• executeUpdate() cannot be used when the request contains multiple statements; use execute()(要求で複数の文が指定されている場合、executeUpdate()は使用できません。execute()を使用してください)

Upsert文の未サポート

getGeneratedKeysでは、Upsert文はサポートされていません。Upsert文の後にgeneratedKeysが要求されると、空の結果セットが返されます。

ParameterMetaDataとあいまいな型

ParameterMetaDataを使用する場合、パラメータのデータ型があいまいになることがあります。この状態が発生するのは、?パラメータが特定の式で使用される場合、または?パラメータが、オーバーロードされたUDF/UDMの呼び出しで使用される場合です。次に例を挙げます。

        単純なINSERT操作:

これは、(?, ?, ?)で示される3つのパラメータをテーブルT1に挿入する単純な操作です。この例では、表内の列/フィールドに各パラメータが単純に割り当てられます。返されるパラメータ メタデータは明確です。このパラメータ メタデータは、パラメータ データにより入力される各列を表わします。

        式を使用したINSERT操作:

この例では、ターゲットテーブルの各列には、? * 3, ? + 1、および?MOD 3の各式の結果が割り当てられます。この3つのパラメータと関連付けられているメタデータがあいまいになります。これは、このメタデータを、複数のSQLタイプにマップできるからです。この場合、このパラメータのデータ型は不明とみなされます。また、メソッドjava.sql.ParameterMetaData.getParameterType()は、java.sql.Types.NULLを返します。

表16 では、パラメータのデータ型があいまいな場合に返され、不明なデータ型とみなされるものについて概説します。

SELECT文のSELECTリストに?パラメータが指定されていると、ParameterMetaDataに加えて、ResultSetMetaDataがあいまいになることがあります。

例

注:   Teradata Database V2R6.2.0.19からは、SELECT文内のSELECTリストで疑問符パラメータ マーカーを使用できます。

表17 では、パラメータのデータ型があいまいな場合に返され、不明なデータ型とみなされるものについて概説します。

Java外部ストアド プロシージャ

ANSI SQL規格のJava外部ストアド プロシージャ(XSP)部分は、Teradata Database 12.0以降をTeradata JDBC Driver 12.0以降と連携して使用することで提供されます。これには、SQLJデータベースおよび表、jarファイルのインストール、Java XSP定義、およびJDBCデフォルト接続へのJava XSPアクセスが含まれます。

詳細は、『Teradata Database SQL外部ルーチン プログラミング』を参照してください。

Java XSPは、次のように使用します。

• データベースの外部でJavaソースをコンパイルし、結果のクラス(バイト コード)をjarファイル内に配置します。

  注:  Teradata Database 12.0および13.0はJDK 6.0でコンパイルしたJavaストアド プロシージャをサポートしていません。JDK 1.4.2またはJDK 5.0でコンパイルしたJavaストアド プロシージャのみがサポートされています。

• SQLJ.INSTALL_JARという名前のXSPを呼び出して、結果のjarファイルをデータベースに登録します。
• jarファイルおよび関連するJavaクラスをEXTERNAL NAME句に指定して、Java XSPを作成します。

作成したら、他のXSPと同じ方法でJavaルーチンにアクセスします。Java XSPは、標準のJDBCドライバ インターフェースを使用してSQLコードを実行できます。ストアド プロシージャはデータベース上で実行され、ログオンしたセッション内から呼び出されるため、接続URL jdbc:default:connectionを使用する必要があります。

JARファイル

jarファイルには、Javaクラスの集合体が格納されます。クラス(コンパイルされたJavaバイト コード)は、EXTERNAL NAME句を使用して外部Javaルーチンが作成されたときに参照されます。jarファイルは、データベースの外部で作成されます。クラスを参照できるようにするためには、先に登録してSQL環境にコピーする必要があります。jarファイルをデータベースにインストールした後は、ファイルの内容を変更することはできません。ファイル全体を削除または置換することのみが可能になります。

jarファイルは、グローバルではなく、SQLJ.INSTALL_JAR()を呼び出してjarファイルをインストールしたユーザーのみが使用できます。C/C++のUDFおよびXSPのインフラストラクチャと同様に、jarが格納されているデータベースごとに1つのディレクトリがサーバー上に作成されます。特定のデータベース内の1つまたは複数のUDFまたはXSPに対して作成されたC/C++のDLLには、他のユーザーやデータベースからはアクセスできません。jarファイルの場合も同様です。このことと関連して、jarファイルに対して新しいアクセス権は作成されません。したがって、ユーザー データベースAは、ユーザー データベースBにインストールされたjarを参照するXSPを作成できません。ただし、C/C++のUDF/XSP用に設計された同じアクセス権を使用することにより、ユーザー データベースBで作成されたJava XSPへのアクセス権をユーザー データベースAに付与することは可能です。 Java XSPに関して適用できるモデルは、同じデータベース内にすべてのjarをインストールし、すべてのJava XSPを作成してから、それらのJava XSPの実行を必要とするすべてのユーザーに、Java XSPへのアクセス権を付与することです。

jarファイルは、次のXSPによってインストール、置換、削除、またはパス指定されます。

• SQLJ.INSTALL_JAR
• SQLJ.REPLACE_JAR
• SQLJ.REMOVE_JAR
• SQLJ.ALTER_JAVA_PATH

クライアントからDBSサーバーへのJava XSPの転送

JDBCを使用する場合は、サーバーまたはクライアント上に格納されているXSP用のjarファイルを使用します。クライアント上にあるJava XSP用のjarファイルは、クライアント ノードからサーバー ノードに転送する必要があります。セキュリティの目的で、Teradata JDBC Driverでは、すべてのリソースをロードするためにclasspathが使用されます。Java XSPが格納されているjarファイルをclasspath自体に指定することはできません。その代わりに、jarファイルのコンテナをclasspathに指定する必要があります。例えば、ファイル システム上のディレクトリにjarファイルがある場合は、そのディレクトリの名前がclasspath内になければなりません。別の例として、warファイルまたはearファイルの内部にjarファイルを配置することも可能です。アプリケーション サーバーは、warファイルやearファイルの内容を自動的にclasspathで使用可能にするためです。classpathを設定した後、Teradata JDBC Driverはソース ファイルをサーバー ノードに転送できるようになります。

SQLJを使用してjarファイルのインストールとクライアントからDBSサーバーへの転送を行うコードをJDBCのサンプル クラス抜粋して以下に示します。

stmt.executeUpdate("{call sqlj.install_jar('cj!SampleXJSP.jar', 'SampleXJSP',0)}");

この例では、locspecパラメータを使用してjarファイルの場所を指定しています。<locspec>は、元のjarファイルがある場所を指定します。<location designator>に'CJ!'が指定されている 場合、jarの場所は、クライアント上の、Teradata JDBC Driverのclasspathによって指定されたクライアント解釈の場所になります。<location designator>に'SJ!'が指定されている場合、jarの場所は、データベース サーバー上の、<server jar path>によって指定された場所になります。

SQLルーチンの定義

jarファイルをインストールした後の次の手順は、Javaクラス プロシージャDeptJobInfoを作成することです。例：

REPLACE PROCEDURE getDeptJobInfo

(IN name VARCHAR(30), OUT dept VARCHAR(50), OUT job VARCHAR(300))

LANGUAGE JAVA MODIFIES SQL DATA

PARAMETER STYLE JAVA

EXTERNAL NAME 'SampleXJSP:DeptJobInfo.getDeptJobInfo';

パラメータの使用例

次の例は、さまざまなパラメータのタイプに対するプロシージャ定義を示したものです。SQL文:

REPLACE PROCEDURE getEmpInfo

(IN name VARCHAR(30), OUT id INTEGER, OUT dept VARCHAR(50),

OUT job VARCHAR(300), OUT res CLOB)

LANGUAGE JAVA MODIFIES SQL DATA

PARAMETER STYLE JAVA

EXTERNAL NAME 'SampleXJSP:EmpInfo.getEmpInfo(

java.lang.String,

java.lang.Integer[],

java.lang.String[],

java.lang.String[],

java.sql.Clob[])';

上記で定義されたJavaストアド プロシージャのソース コード:

public class EmpInfo

{

  public static void getEmpInfo(String name,

                        java.lang.Integer[] id,

                        String[] dept,

                        String[] job,

                        java.sql.Clob[] res) throws SQLException

  {

    /* Establish default connection.*/

    Connection con =     DriverManager.getConnection("jdbc:default:connection");

    String query = "SELECT empID, empDept, empJob, empResume" +

             "FROM employee 2" +

             "WHERE empName = ?;";

    /* Executing the command */

    PreparedStatement pStmt = con.prepareStatement(query);

    try

    {

      pStmt.setString(1, name);

      ResultSet rs = pStmt.executeQuery();

      boolean more = rs.next();

      if(more)

      {

        id[0] = new java.lang.Integer(rs.getInt(1));

        dept[0] = rs.getString(2);

        job[0] = rs.getString(3);

        res[0] = rs.getClob(4);

      }

    }

    finally

    {

      pStmt.close();

    }

}

ここに提示されているJava XSP内のパラメータは、SQLタイプからJavaタイプに明示的にマップされます。このようなマッピングは、暗黙的にすることもできます。外部Java XSPパラメータのSQLタイプからJavaタイプへのマッピングについては、「SQLデータ タイプ マッピング」で定義されています。

デフォルト接続

前述の例のJava XSPは、データベース上で実行され、ログオンしたセッション内から呼び出されています。結果として、使用されている接続URLはjdbc:default:connectionになっています。これにより、呼び出し側のセッションおよび現在のトランザクションに参加するデフォルト接続が作成されます。接続のcloseメソッドが呼び出されても、ログオフは行なわれません。デフォルト接続は、呼び出し側と同じセッションを使用するためです。デフォルト接続は、1つのスレッド(特にJava XSPを呼び出したスレッド)からのみアクセスできます。

JDBCからのJava XSPの呼び出し

JDBCクライアントからのJava XSPの呼び出しは、他のストアド プロシージャの呼び出しと同じです。次の例では、CallableStatementを使用しています。

String sCall = "{call getEmpInfo(?,?,?,?,?)}";

String sName = "Brian Lee";

// プリコンパイルされたSQLステートメントを表す

// CallableStatementオブジェクトを作成し、呼び出し可能な

// ステートメントの実行を準備する

CallableStatement cStmt = con.prepareCall(sCall);

// 入力パラメータ値を設定する

cStmt.setString(1, sName);

// パラメータの型を宣言して、データ取得用の

// 出力パラメータを設定する

cStmt.registerOutParameter(2, Types.INTEGER);

cStmt.registerOutParameter(3, Types.VARCHAR);

cStmt.registerOutParameter(4, Types.VARCHAR);

cStmt.registerOutParameter(5, Types.CLOB);

System.out.printIn("\n Calling the procedure with '"

           + sName + '"...");

// プロシージャ呼び出しを実行する

cStmt.executeUpdate();

// プロシージャ呼び出しの結果を表示する

System.out.printIn(" Call successful.");

System.out.printIn("\n Displaying output of the call to"

           + "getEmpInfo(...):");

System.outprintIn("\n" + sName);

System.out.printIn("---------------");

int id = cStmt.getInt(2);

System.out.printIn(" Employee ID : " + id);

System.out.printIn(" Department : " + cStmt.getString(3));

System.out.printIn(" Job Description : " + cStmt.getString(4));

System.out.print(" Resume: ");

// レビューのためにCLOBデータをファイルに書き出す

createClobFile(cStmt.getClob(5),(id + "resumeT20604.txt"));

トランザクション セマンティックスとJava XSP

トランザクション セマンティックス(ANSIまたはTeradata)は、セッションがログオンされた時点で設定され、後で変更することはできません。Teradata JDBC Driverの使用時には、トランザクション セマンティックスはTMODE接続パラメータを使用して指定されます。Java XSPが使用するデフォルト接続は、常に、呼び出し側のセッションを確立するために使用されたトランザクション セマンティックスを継承します。

• 呼び出し側のセッションでANSIトランザクション セマンティックスが使用されている場合、Java XSPのデフォルト接続のAuto-Commit(自動コミット)の設定はfalseになります。
• 呼び出し側のセッションでTeradataトランザクション セマンティックスが使用されている場合、Java XSPのデフォルト接続のAuto-Commit(自動コミット)の設定は、呼び出し側のセッションが既存のトランザクション内にあるかどうか(例えば、BTが実行されたかどうか)によって変わります。このケースでは、BTが実行されていればAuto-Commit(自動コミット)の設定はfalseに、BTが実行されていなければAuto-Commit(自動コミット)の設定はtrueになります。

制限

次のSQL文は、動的結果セットの生成に使われている場合、Javaストアド プロシージャでサポートされません 。つまり、複文要求で動的結果セットを生成するSQL文が他に使われている場合に、それらの文と混在させることができないことを意味します。

• HELP CONSTRAINT
• HELP [TEMPORARY] INDEX
• HELP REPLICATION GROUP
• HELP SESSION
• HELP STATISTICS
• HELP TRANSFORM
• HELP TRIGGER
• HELP VOLATILE TABLE
• SHOW FUNCTION
• SHOW PROCEDURE
• SHOW REPLICATION GROUP
• SHOW SPECIFIC METHOD
• SHOW TYPE

次の制限は、自動生成キー結果セットがJavaストアド プロシージャから返される場合に適用されます。

• Javaストアド プロシージャでRETURN_GENERATED_KEYSが指定されており、クライアント アプリケーションが識別列値を含む1列のResultSetを受け取る場合
• Javaストアド プロシージャで列の配列が指定されており、クライアント アプリケーションが宛先のテーブルのすべての列を含むResultSetを受け取る場合
• PreparedStatementバッチの生成キー結果セットをJavaストアド プロシージャから返すことがサポートされていない場合

Javaストアド プロシージャは直接的でも間接的でも、別のJavaストアド プロシージャを呼び出すことはできません。

Javaストアド プロシージャではINまたはINPUT LOBパラメータを更新できません。

Javaストアド プロシージャで使用されるLOB_TEMP_TABLEは、Javaストアド プロシージャを呼び出すJDBC接続によって使用されるLOB_TEMP_TABLEから分離する必要があります。

Teradata Database 12.0および13.0は、JDK 1.4.2またはJDK 5.0によってのみコンパイルされたJavaストアド プロシージャをサポートします。

JDK 6.0でコンパイルされたJavaストアド プロシージャは、Teradata Database 13.10以降でサポートされます。

更新可能結果セット

結果セットの更新可能化

以下のメソッドの呼び出し時には、デフォルトのResultSetオブジェクトが返されます。

• Connection.createStatement()
• Connection.prepareStatement(String query)
• Connection.prepareCall(String query)

このデフォルトのResultSetオブジェクトは更新可能ではなく、カーソルは順方向にのみ移動します。

以下のメソッドを呼び出すことにより、スクロール可能で更新可能なResultSetオブジェクトを作成できます。

• Connection.createStatement(int type, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareStatement(String sql, int type, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareCall(String sql, int type, ResultSet.CONCUR_UPDATABLE)

上記のメソッドからのResultSetオブジェクトを更新可能にするためには、以下の要件が満たされている必要があります。

• データベースのバージョン要件：Teradata Database V2R6.2以降
• 接続パラメータLOB_SUPPORTが、ONになっているか省略されていること(デフォルトはON)
• 固有索引の要件:取り出された結果セットには、1つの固有インデックスの唯一のメンバーである列か、テーブルの1つまたは複数の固有インデックスのメンバーである列が含まれていなければなりません。最低1つの固有インデックスのすべての列が、結果セット内で選択されている必要があります。

更新不能結果セット

Teradata JDBC Driverは、単一の表または複数の結合表から取り出された結果セットからの、更新要求、挿入要求、削除要求を満たそうとします。しかし、データベースから返された結果セットが更新可能ではない場合があります。例えば、次のような場合などです。

• 結果セットが自己結合表から取り出された場合、自己結合表から取り出された結果セット内の列が元のテーブル名および列名と同じになり、その結果セットに適用されるUPDATE、INSERT、DELETEの各問合わせがあいまいになる可能性があります。
• 単一の表または複数の結合表から取り出された結果セットでResultSet.insertRow()が使用される場合には、単一の表またはすべての結合テーブルの、NOT NULL制約のあるすべての列が、取り出された結果セット内に含まれている必要があります。そうでないと、メソッドinsertRowは失敗し、データベースからエラー メッセージが返されます。

内部結合

内部結合の表に対して更新可能結果セットを使用することには、何の問題もありません。内部結合表からは、一致した行のみが選択され、不一致の行にNULL値が埋め込まれることはないためです。

ただし、複数の内部結合テーブルから取り出された結果セットにおいて、結果セットに列が含まれているすべてのテーブルに対して下記の固有インデックスの要件が満たされていない場合には、メソッドupdateRowとdeleteRowは失敗し、Teradata JDBC DriverはSQLExceptionをスローし、メソッドinsertRowではデータベースからエラー メッセージが返されます。

取り出された結果セットには、1つの固有索引の唯一のメンバーである列か、テーブルの1つまたは複数の固有索引のメンバーである列が含まれていなければなりません。最低1つの固有索引のすべての列が、結果セット内で選択されている必要があります。

外部結合

複数の外部結合テーブルから取り出された結果セットにおいて、結果セットに列が含まれているすべてのテーブルに対して下記の固有インデックスの要件が満たされていない場合には、メソッドupdateRowとdeleteRowは失敗し、Teradata JDBC DriverはSQLExceptionをスローし、メソッドinsertRowではデータベースからエラー メッセージが返されます。

取り出された結果セットには、1つの固有インデックスの唯一のメンバーである列か、テーブルの1つまたは複数の固有インデックスのメンバーである列が含まれていなければなりません。最低1つの固有インデックスのすべての列が、結果セット内で選択されている必要があります。

また、上記の固有索引要件から選択された固有索引列がNULLでない場合のみ、Teradata JDBC Driverは、1つの結合からの1つの結果セット行を更新可能にできます。ただし、外部結合では、1つまたは複数の結合テーブルの、このような固有索引列に対してNULL値を含めることができます。この場合、updateRow()操作とdeleteRow()操作は失敗し、Teradata JDBC DriverはSQLExceptionをスローします。

更新可能結果セットの使用

Teradata JDBC Driverで更新可能結果セットを使用する際の一般的なシナリオを以下に示します。

• データベース内で現在の行の列値を更新する

  下記のコード断片では、ResultSetオブジェクトrs の3行目にあるSTATE列を更新してから、メソッドupdateRowを使用して、rs の派生元のデータ ソース表を更新しています。

  rs.absolute(3); // moves the cursor to the third row of rs

  rs.updateString("STATE", "CALIFORNIA"); // updates the

     // STATE column of row 3 to be CALIFORNIA

  rs.updateRow(); // updates the row in the data source

• データベースに新しい行を挿入する

  更新可能なResultSetオブジェクトには、挿入される行を構築するための中間準備領域として機能する、特殊な行が関連付けられます。下記のコード断片では、カーソルを挿入行に移動し、3列の行を構築し、メソッドinsertRowを使用して、その行をrs とデータ ソース表に挿入しています。

  rs.moveToInsertRow(); // moves cursor to the insert row

  rs.updateString(1, "Michael"); // updates the

     // first column of the insert row to be Michael

  rs.updateInt(2, 35); // updates the second column to be 35

  rs.updateBoolean(3, true); // updates the third column to true

  rs.insertRow(); // inserts the row in the data source

  rs.moveToCurrentRow(); // moves back to current row

• データベースからカレント行を削除する

  rs.absolute(3); // moves the cursor to the third row of rs

  rs.deleteRow(); // deletes the current row 3 in the data source

• 現在の行を最新の情報に更新する

  Teradata JDBC Driverは、結果セット内のカレント行について一連のupdaterメソッドによって更新された列の値をクリアするために、メソッドrefreshRowを実装しています。更新メソッドの呼び出し後であっても、メソッドupdateRowの呼び出し前にrefreshRowが呼び出されると、行に対する更新は失われます。しかし、Teradata JDBC Driverが現在の行の最新の値をデータベースから取り出し直して現在の行を最新の情報に更新することはありません。

  下記のコード断片では、ResultSetオブジェクトrs の3番目の行のSTATE列とAMOUNT列を更新してから、メソッドrefreshRowを使用して、結果セット内のカレント行に対して更新メソッドによって更新された列の値を整理しています。メソッドupdateRowでは、rs の派生元のデータ ソース表は更新されません。更新列の値が失われているためです。

  rs.absolute(3); // moves the cursor to the third row of rs

  rs.updateString("STATE", "CALIFORNIA"); // updates the

     // STATE column of row 3 to be CALIFORNIA

  rs.updateInt("AMOUNT", 58); // updates the second column to be 35

  rs.refreshRow(); // clears up the update column

     // values for the current row

  rs.updateRow(); // no UPDATE in the data source since

     // update values are lost

結果セットの型と並列性のアップグレードおよびダウングレード

結果セットの型と並列性のアップグレードまたはダウングレードが必要になるシナリオがいくつかあります。

シナリオ1: 型のアップグレード

Teradata JDBC Driverでは、更新可能結果セットを、結果セット型ResultSet.TYPE_SCROLL_INSENSITIVEとして実装します。

ユーザーが以下の結果セット型を使用しようとした場合、

ResultSet.TYPE_FORWARD_ONLYおよび並行モード

以下のメソッドでのResultSet.CONCUR_UPDATABLE:

• Connection.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareStatement(String sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareCall(String sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE)

さらに、以下の要件が満たされている場合、

• Teradata Database V2R6.2以降
• 接続パラメータLOB_SUPPORTが、ONになっているか省略されている(デフォルトはON)

取り出された結果セットの型はResultSet.TYPE_SCROLL_INSENSITIVEにアップグレードされ、ConnectionオブジェクトにSQLWarningが追加されます。

シナリオ2: 並列性のダウングレード

ユーザーが以下の結果セット並列性を使用しようとした場合、

以下のメソッドでのResultSet.CONCUR_UPDATABLE:

• Connection.createStatement(int type, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareStatement(String sql, int type, ResultSet.CONCUR_UPDATABLE)
• Connection.prepareCall(String sql, int type, ResultSet.CONCUR_UPDATABLE)

さらに、以下の要件が満たされていません 場合、

• データベースのバージョン要件：Teradata Database V2R6.2以降
• 接続パラメータLOB_SUPPORTが、ONになっているか省略されている(デフォルトはON)
• 固有索引の要件: 取り出された結果セットには、1つの固有索引の唯一のメンバーである列か、テーブルの1つまたは複数の固有索引のメンバーである列が含まれていなければなりません。最低1つの固有索引のすべての列が、結果セット内で選択されている必要があります。

取り出された結果セットの並行モードはResultSet.READ_ONLYにダウングレードされ、ConnectionオブジェクトにSQLWarningが追加されます。

例外

更新可能結果セットを使用する際のTeradata JDBC Driverの例外シナリオを以下に示します。

• 自己結合表から取り出された結果セットにメソッドupdateRow、insertRow、deleteRowを適用することは、あいまいで予測不能になります。
• 単一または複数の結合テーブルから取り出された結果セットで、結果セットに列が含まれているテーブルに対して上記の固有インデックスの要件が満たされていない場合、
  • メソッドupdateRowおよびdeleteRow:Teradata JDBC Driverは、SQLExceptionをスローします。

    エラー 1197: No unique primary index (UPI) or key columns are fetched in this result set from the table (この結果セット内には、表からの固有基本索引(UPI)またはキー列は取り出されていません)

  • メソッドinsertRow: Teradata JDBC Driverは次の条件ではSQLExceptionをスローします。

    エラー 1198: Not all of non-nullable columns in the insert row have been given a value for the table (テーブルの挿入行内のNull受け入れ不可能列のすべてに値が指定されているとは限りません)

    エラー 1199: Not all of non-nullable columns in the insert row have been given a non-null value for the table (テーブルの挿入行内のNull受け入れ不可能列のすべてに非NULL値が指定されているとは限りません)

• メソッドupdateRowおよびdeleteRowの呼び出し時に、上記の固有索引要件から選択された固有索引列に外部結合表からのNULL値が含まれている場合には、Teradata JDBC DriverはSQLExceptionをスローします。

  エラー 1195: Unique Primary Index (UPI) columns are NULL for the table (テーブルの固有基本索引(UPI)列がNULLです)

  エラー 1196: Primary key columns are NULL for the table (テーブルの基本キー列がNULLです)

• サポートされないデータ タイプで更新メソッドが呼び出されると、Teradata JDBC Driverはエラー 1190でSQLExceptionをスローします。
• カーソルが挿入行にあるときにメソッドcancelRowUpdates、updateRow、deleteRow、refreshRowが呼び出された場合、Teradata JDBC DriverはSQLExceptionをスローします。

  エラー 1191: Function should not be called since the cursor is on the insert row (カーソルが挿入行にあるので関数を呼び出せません)

ストアド プロシージャの動的結果セット

動的結果セットを返すストアド プロシージャは、複文要求に類似しています。

• CallableStatement.execute() – 複数の結果セットが予測される場合や、ストアド プロシージャによって動的結果セットが返されるかどうかが不明の場合に使用します。
• CallableStatement.executeQuery() – 単一の結果セットが予測される場合に使用します。

結果セットが動的であるということは、文の実行が終了するまでは結果のメタデータを参照できないことを意味します。

特殊な浮動小数点値

データベースは、正の無限大、負の無限大、非数(NaN)などの特殊な浮動小数点値について完全にはサポートしていません。Javaアプリケーションでは、PreparedStatementを使用して、特殊な浮動小数点値をデータベースのFLOAT列にバインドして挿入することは可能です。ただし、特殊な浮動小数点値はデータベースでは完全サポートではないため、特殊な浮動小数点値を参照するWHERE句条件を持つSELECT文では、不正な結果やデータベース エラーが発生することがあります。

PreparedStatementバッチ

PreparedStatementバッチは、実行依頼ごとに、SQL文は同じでデータ値のみが異なる場合に、データの挿入、更新、削除を、効率的に実行できます。

挿入のパフォーマンスは多くの要因に左右されます。例えば、列の数、列のデータ型、データ値のサイズなどです。表18 に、各挿入方法を遅いものから速いものの順に比較して示します。

JDBCのPreparedStatementおよびCallableStatementバッチ機能は、Teradata Databaseの"iterated request(反復要求)"機能を使用してTeradata JDBC Driverによって実装されます。PreparedStatementバッチを、反復要求(INSERT、UPDATE、DELETE など)と互換性のあるSQLリクエストで使用すると、パフォーマンスの向上が期待できます。

複数ステートメントの要求、およびストアド プロシージャへのCALLは、Teradata Databaseの制限により、反復要求と互換性がありません。複数ステートメントの要求は、PreparedStatementバッチでは使用できません。

Teradata JDBC Driverは、PreparedStatement(または CallableStatement)バッチを使用したストアド プロシージャへのCALLの特殊なケースをサポートします。Teradata Databaseは、ストアド プロシージャへのCALLの反復要求をサポートしていないため、Teradata JDBC Driverは、SQLリクエストがストアード・プロシージャーへのCALLである場合、反復要求としてバッチを送信できません。代わりに、Teradata JDBC Driverは、バインドされたパラメータ値のセットごとに1回、ストアード プロシージャへのCALLを繰り返し実行します。ストアード プロシージャへのCALLにバッチが使用される場合、パフォーマンスの向上は期待できません。

PreparedStatementのBatchUpdateException処理

Teradata Database 13.10とTeradata JDBC Driver 13.00.00.16からは、PreparedStatementのバッチ実行でパラメータ セットごとの成功状態およびエラー状態が個別に返されるようになりました。

PreparedStatementのexecuteBatchメソッドを使用するアプリケーションには、BatchUpdateException用のcatchブロックを用意して、BatchUpdateExceptionのgetErrorCodeメソッドから返されたエラー コードをアプリケーションで検査する必要があります。

アプリケーションがBatchUpdateExceptionを検出した場合、そのアプリケーションはBatchUpdateExceptionのgetUpdateCountsメソッドが返す整数値のupdateCount配列を反復します。updateCount配列内の各整数値は、PreparedStatementのバッチで設定したパラメータ セットと同じ順序で対応します。

この整数値が0以上、またはSuccess.SUCCESS_NO_INFOと等しい場合、パラメータ セットは正常に実行されています。アプリケーションが、それ以上の対処を取る必要はありません。

配列内の整数値がStatement.EXECUTE_FAILEDと等しい場合、そのパラメータ セットの処理は失敗しています。アプリケーションは、整数値がStatement.EXECUTE_FAILEDと等しくなった各パラメータ セットを処理する必要があります。

JDBC FastLoad

JDBC FastLoadは、データベース内の空の宛先表に大量のデータを迅速にロードするメソッドを提供します。JDBC FastLoadの実際のパフォーマンスは、アプリケーションとデータベースの構成に応じて変わります。

例えば、制約のないネットワークの場合、JDBC FastLoadは対応するSQL PreparedStatementバッチ挿入よりも3～10倍高速になります。つまり、JDBC FastLoadは同等の機能を実行するSQL PreparedStatementバッチ挿入にかかる時間の10%～33%で済みます。

JDBC FastLoadの有効化

JDBC FastLoadは、URL接続文字列にTYPE=FASTLOADを指定して有効にします。有効になると、FastLoad対応のSQL INSERT文に対して、FastLoadプロトコルがデータベースで使用されます。他のすべてのSQL文と、FastLoad非対応のSQL INSERT文に対しては、標準のプロトコルがデータベースで使用されます。

JDBC FastLoadを実行できるようにするためには、SQL INSERT文で以下の基準が満たされていなければなりません。

• JDBC FastLoadは、PreparedStatement で使用する必要があります。
• PreparedStatement は、単一のSQL INSERT文である必要があります。
• PreparedStatement は、自動生成キーを返さずに使用する必要があります。
• Teradataのセッション文字セットは、ASCII、UTF8、またはUTF16である必要があります。Teradata JDBC Driver 13.00.00.20から、Teradataのセッション文字セットKANJISJIS_0SおよびKANJIEUC_0Uもサポートされています。
• 宛先表で宣言されているすべてのTeradataデータ型は、JDBC FastLoadによってサポートされている必要があります。

JDBC FastLoad使用時の考慮事項

JDBC FastLoadはパフォーマンスを向上させますが、すべてのアプリケーションで適切な選択肢であるわけではありません。アプリケーションでのJDBC FastLoadの使用可能性を評価する場合、以下の要因を考慮する必要があります。

• JDBC FastLoadでは、データベース内の宛先表が空になっていないと、データ行を挿入するために使用できません。
• JDBC FastLoadでは、StatementInfoパーセル サポートを有効にする必要があります。
• JDBC FastLoadはデータベースの宛先表をロックします。したがって、JDBC FastLoadがアクティブである間、Javaアプリケーションには宛先表へのアクセス権がなくなります。ロックは、トランザクションがコミットまたはロールバックされた時点で解放されます。
• JDBC FastLoadで推奨されるのは、大容量のデータのロード(少なくとも全部で100,000行)のみです。JDBC FastLoadは、FastLoad操作を開始するオーバーヘッドのため、挿入行が少ないと通常のSQL INSERTよりもかえって遅くなります。
• JDBC FastLoadはバッチ挿入のみをサポートします。
• JDBC FastLoadによりSQLWarningが設定される可能性があります。トランザクションのコミットまたはロールバックの前後に、SQLWarningが設定されていないことを必ずチェックすることを推奨します。
• JDBC FastLoadは、命名規則DatabaseName.TableName_ERR_1およびDatabaseName.TableName_ERR_2に基づいて2つのエラー テーブルを作成します例えば、宛先のDatabaseNameがguestで、宛先のTableNameがFastLoadExampleの場合、2つのエラー テーブルはguest.FastLoadExample_ERR_1およびguest.FastLoadExample_ERR_2になります。デフォルトの動作では、ロードされる宛先テーブルと同じデータベースにFastLoadエラー テーブルが作成されます。Teradata JDBC Driver 16.00.00.31以降では、接続パラメータERROR_TABLE_1_SUFFIX、ERROR_TABLE_2_SUFFIX、およびERROR_TABLE_DATABASEを使用してエラー テーブルの格納場所と接尾辞を指定できます。ロード操作が完了すると、エラー テーブルはJDBC FastLoadによって自動的にクエリーが実行されて削除されます。エラー テーブルにアプリケーションがアクセスしないようにします。JDBC FastLoadがアクティブになっている間は、アクセスするとデッドロックが発生する可能性があります。エラー テーブルの目的の詳細については、『Teradata FastLoadリファレンス』のエラーの記録を参照してください。
• JDBC FastLoadで使用するデータベース内の宛先テーブルの名前は、24文字を超えてはなりません。JDBC FastLoadによって作成される2つの一時エラーテーブルの名前(前述)に影響するためです。Teradata Database 14.10以降、宛先テーブルの名前は122文字以下にする必要があります。
• 宛先テーブルの列名は28文字以下にする必要があります。Teradata Database 14.10以降、列名は126文字以下にする必要があります。
• JDBC FastLoadでのプリペアド ステートメントオブジェクトの同時使用は許可されていますが、データベースによって課せられる制限を受けます。課される制限の詳細は、『Teradata FastLoadリファレンス』の同時実行ロード ユーティリティ タスクについてのセクションを参照してください。
• JDBC FastLoadを使用してロードされている表をオンライン アーカイブが検出すると、そのテーブルのオンライン アーカイブ処理はバイパスされます。

JDBC FastLoadによってサポートされるJDBCのデータ型

Teradata JDBC DriverによってサポートされるJDBCのデータ型のすべてがJDBC FastLoadによってサポートされるとは限りません。例えば、BLOBやCLOBなどです。同様に、Teradata JDBC DriverによってサポートされるJDBCのデータ型変換のすべてがJDBC FastLoadによってサポートされるとは限りません。

JDBC FastLoadを支援するJDBCエスケープ関数

これは、データベース用に設定されたAMPの数を返します。この情報は、作成可能なJDBC FastLoad接続の最大数を判定する際に役立ちます。

これは、このPreparedStatement によって作成されたJDBC FastLoadのConnection(接続)の、JDBC FastLoad対応のPreparedStatement.hashCode()と関連ログオン シーケンス番号(LSN)との、カンマで区切られたペアを返します。

例えば、文字列"6166383,1850,22323092,1851"は、6166383と22323092がJDBC FastLoad PreparedStatementのハッシュ コードであることを示し、1850と1851がそれぞれのLSNであることを示します。

この情報は、プログラム例に示されているような、JDBC FastLoad接続のDBC.SessionInfo.SessionNoを探す際に役立ちます。ただし、LSNを取得できるのは、auto-commit (自動コミット)モードがfalseに設定されていて、最低1つの列値がJDBC FastLoad対応のPreparedStatement を使用して事前にバインドされている場合に限ります。

JDBC FastLoad CSV

JDBC FastLoad CSVは、データベース内の空の宛先表に大量のデータを迅速にロードするメソッドを提供します。アプリケーションは、データをカンマ区切り値(CSV) フォーマットの可変長テキストを含むInputStreamとして提供する必要があります。デフォルトの分離(区切り)文字は',' (カンマ)です。『JDBC FastLoad CSVによってサポートされるフィールド分離記号』に示されているように、他の分離文字もサポートされています。この機能は、Teradata JDBC Driver 13.00.00.26以降で使用できます。

JDBC FastLoad CSVの有効化

JDBC FastLoad CSVは、URL接続文字列にTYPE=FASTLOADCSVを指定して有効にします。有効になると、FastLoadCSV対応のSQL INSERT文に対して、FastLoadプロトコルがデータベースで使用されます。他の種類のSQL文は、JDBC FastLoad CSV接続ではサポートされていません。

JDBC FastLoad CSVを実行できるようにするためには、SQL INSERT文で以下の基準が満たされていなければなりません。

• JDBC FastLoad CSVは、PreparedStatement で使用する必要があります。
• PreparedStatement は、単一のSQL INSERT文である必要があります。
• PreparedStatement は、自動生成キーを返さずに使用する必要があります。
• Teradataのセッション文字セットは、ASCIIまたはUTF8である必要があります。UTF8は、Teradata JDBC Driver 13.10.00.04からサポートされています。
• 宛先表で宣言されているすべてのTeradataデータ型は、JDBC FastLoad CSVによってサポートされている必要があります。

JDBC FastLoad CSV使用時の考慮事項

JDBC FastLoad CSVはパフォーマンスを向上させますが、すべてのアプリケーションで適切な選択肢であるわけではありません。アプリケーションでのJDBC FastLoad CSVの使用可能性を評価する場合、以下の要因を考慮する必要があります。

• JDBC FastLoad CSVでは、データベース内の宛先表が空になっていないと、データ行を挿入するために使用できません。
• JDBC FastLoad CSVはデータベースの宛先表をロックします。JDBC FastLoad CSVがアクティブである間、宛先表に対するその他のアクセスは許可されていません。Teradata JDBC Driver 14.00.00.31以降、アプリケーションがConnection commitまたはrollbackメソッドを呼び出すと、ロックが解放されます。Teradata JDBC Driver 14.00.00.31より前のバージョンでは、PreparedStatementを閉じるとロックが解放されます。
• JDBC FastLoad CSVで推奨されるのは、大容量のデータのロード(少なくとも全部で100,000行)のみです。JDBC FastLoad CSVは、FastLoad操作を開始するオーバーヘッドのため、挿入行が少ないと通常のSQL INSERTよりもかえって遅くなります。
• データ セットは、可変長テキストのInputStreamオブジェクトで1ラインに1行を含んでいる必要があります。ここで、各フィールドは区切り文字で区切られます。これには、宛先表に挿入されない列タイトルを先頭行に含んでいる必要があります。2つの連続する区切り文字が現れた場合、最初の区切り文字の直後のフィールドにnullを挿入します。
• JDBC FastLoad CSVはConnectionまたはPreparedStatementに対してSQLWarningを設定することがあります。PreparedStatementが作成されるか、実行された後、およびConnection commitまたはrollbackメソッドが呼び出された後に、アプリケーションはConnection getWarningsメソッドを呼び出す必要があります。PreparedStatementを実行した後に、アプリケーションはPreparedStatement getWarningsメソッドを呼び出す必要があります。

                 InputStream inStream = ...PreparedStatement pstmt = con.prepareStatement("INSERT INTO ..."); try { if(con.getWarnings() != null) ... pstmt.setAsciiStream(1, inStream, -1); pstmt.executeUpdate(); // assuming auto-commit is turned on if(con.getWarnings() != null || pstmt.getWarnings() != null) ... } finally { pstmt.close(); }

• JDBC FastLoad CSVは、命名規則DatabaseName.TableName_ERR_1およびDatabaseName.TableName_ERR_2に基づいて2つのエラー テーブルを作成します。例えば、宛先のDatabaseNameがguestで、宛先のTableNameがFastLoadExampleの場合、2つのエラー テーブルはguest.FastLoadExample_ERR_1およびguest.FastLoadExample_ERR_2になります。デフォルトの動作では、ロードされる宛先テーブルと同じデータベースにFastLoadエラー テーブルが作成されます。Teradata JDBC Driver 16.00.00.31以降では、接続パラメータERROR_TABLE_1_SUFFIX、ERROR_TABLE_2_SUFFIX、およびERROR_TABLE_DATABASEを使用してエラー テーブルの格納場所と接尾辞を指定できます。JDBC FastLoad CSVの開始前にエラー テーブルが存在してはいけません。Teradata JDBC Driver 14.00.00.31以降では、アプリケーションは接続のcommitメソッドまたはrollbackメソッドを呼び出した後で、エラー テーブルのクエリーと削除を実行する必要があります。Teradata JDBC Driver 14.00.00.31より前では、PreparedStatementがクローズされた後で、アプリケーションがエラー テーブルのクエリーと削除を実行する必要があります。2つのエラー テーブルの目的の詳細については、『Teradata FastLoadリファレンス』のエラーの記録を参照してください。
• JDBC FastLoadによって作成される2つのエラーテーブルの名前（前述）のため、JDBC FastLoadによって使用されるデータベース内の宛先テーブルの名前は24文字以下にする必要があります。Teradata Database 14.10以降、宛先テーブル名は122文字以下にする必要があります。
• 宛先テーブルの列名は28文字以下にする必要があります。Teradata Database 14.10以降、列名は126文字以下にする必要があります。
• JDBC FastLoad CSVのプリペアド ステートメントオブジェクトの同時使用は許可されていますが、データベースによって課せられる制限を受けます。課される制限の詳細は、『Teradata FastLoadリファレンス』の同時実行ロード ユーティリティ タスクについてのセクションを参照してください。
• JDBC FastLoad CSVを使用してロードされている表をオンライン アーカイブが検出すると、そのテーブルのオンライン アーカイブ処理はバイパスされます。

JDBC FastLoad CSVによってサポートされるJDBCのデータ型

Teradata JDBC DriverによってサポートされるJDBCのデータ型のすべてがJDBC FastLoad CSVによってサポートされるとは限りません。例えば、BLOB、CLOB、およびBINARYなどです。同様に、Teradata JDBC DriverによってサポートされるJDBCのデータ タイプ変換のすべてがJDBC FastLoad CSVによってサポートされるとは限りません。

JDBC FastLoad CSVによってサポートされるフィールド分離記号

JDBC FastLoad CSVは、可変長テキストのInputStreamデータ セットでデータの列を分離するために、フィールド分離文字を使用します。デフォルトの分離文字は',' (カンマ)ですが、以下の文字を除く、Unicodeの基本多言語面文字セットの'\u0000'から'\u007f'までのその他の文字に変更できます。

• '\u000a' ('\n'改行)
• '\u000d' ('\r'復帰)
• '\u0022' ('"'二重引用符)

カンマ以外の、一般的に使用される分離文字は、'\u003b' (';'セミコロン)、'\u007c' ('|'縦線)、および'\u0009' ('\t'タブ)です。

セミコロンまたは縦線など、ほとんどの印刷可能な分離文字はTeradata JDBC Driverの接続URLで指定できます。エスケープまたは引用符は不要です。たとえば、縦線のフィールド分離文字はTeradata JDBC Driverの接続URL内で以下のように指定されます。

            Connection con = DriverManager.getConnection( "jdbc:teradata://MySystem/FIELD_SEP=|,TYPE=FASTLOADCSV", user, password);

印刷不能文字または特殊文字をフィールド分離文字として使用する場合、Unicodeエスケープ シーケンスを使用する必要があります。たとえば、タブのフィールド分離文字はTeradata JDBC Driverの接続URL内で以下のように指定されます。バックスラッシュ('\')がJavaストリング リテラルに含まれる場合、バックスラッシュ文字を前に付けてそのバックスラッシュをエスケープする必要があることに注意してください。

            Connection con = DriverManager.getConnection( "jdbc:teradata://MySystem/FIELD_SEP=\\u0009,TYPE=FASTLOADCSV", user, password);

一部の印刷可能な文字はTeradata JDBC Driverの接続URL自体にとって重要です。Unicodeエスケープ シーケンスを使用するか、あるいはフィールド分離文字を単一引用符で囲むことができます。たとえば、カンマがフィールド分離文字として明示的に指定されている場合、Teradata JDBC Driverの接続URL内でカンマを単一引用符で囲む必要があります。

            Connection con = DriverManager.getConnection( "jdbc:teradata://MySystem/FIELD_SEP=',',TYPE=FASTLOADCSV", user, password);

データ セットのデータ値に一般的なフィールド分離文字および引用符がすべて含まれる場合は、ASCIIユニット分離文字(US)制御文字('\u001f')をフィールド分離文字として使用できます。これは、'\u001c'がこの目的に指定された制御文字であるためです。

JDBC FastExport

JDBC FastExportは、データベースの表やビューから大量のデータを簡単に取得する方法を提供します。JDBC FastExportの実際のパフォーマンスは、アプリケーションとデータベースの構成に応じて変わります。

例えば、制約のないネットワークの場合、JDBC FastExportは対応するSQL PreparedStatement selectよりも2～3倍高速になります。つまり、JDBC FastExportは同等の機能を実行するSQL PreparedStatement selectにかかる時間の33%～50%で済みます。

JDBC FastExportの有効化

JDBC FastExportは、URL接続文字列にTYPE=FASTEXPORTを指定して有効にします。有効になると、FastExport対応のSQL SELECT文に対して、FastExportプロトコルがデータベースで使用されます。他のすべてのSQL文と、FastExport非対応のSQL SELECT文に対しては、標準のプロトコルがデータベースで使用されます。

JDBC FastExportを実行できるようにするためには、SQL SELECT文で以下の基準が満たされていなければなりません。

• JDBC FastExportは、PreparedStatement で使用する必要があります。
• Teradataのセッション文字セットは、ASCII、UTF8、またはUTF16である必要があります。Teradata JDBC Driver 13.00.00.20からは、Teradata JDBC DriverでサポートされるTeradataのセッション文字セットを使用できるようになりました。
• ソース表やビューで宣言されているすべてのTeradataデータ型は、JDBC FastExportによってサポートされている必要があります。

JDBC FastExport使用時の考慮事項

• JDBC FastExportは、単文のSQL SELECTをサポートしているほか、複数のSQL SELECT文のみで構成されている複文要求をサポートしています。
• JDBC FastExportは、WHERE句条件の?パラメータ マーカーをサポートしています。ただし、データベースは基本索引、または固有副次索引に=演算子を許可していません。このため、データベース エラー3695 "A Single AMP Select statement has been issued in FastExport"のためにSQLExceptionがスローされます。
• 効率を最大限に高めるために、JDBC FastExportでは、GROUP BY句およびORDER BY句を使用しないでください。
• SQLWarningはJDBC FastExportで設定できます。アプリケーションは、単文または複文のSQL SELECTを準備、または実行する前後に、SQLWarningの連鎖を調べる必要があります。
• 複数のJDBC FastExport PreparedStatementsを同時に使用できますが、データベースによる制限が課せられることがあります。課される制限の詳細は、『Teradata FastExportリファレンス』の制約や制限に関するセクションを参照してください。
• JDBC FastExportの直接モードは、Teradata Database 13.10以降で使用可能です。JDBC FastExportの直接モードにより、GROUP BY句とORDER BY句を含まない単一文のSQL SELECTに最適なパフォーマンスが提供されます。通常、データベースは、文字セットのコード変換とデータ タイプ変換のエラー検査を、問合わせが実行される時点で行います。対称的に、JDBC FastExportの直接モードを使用すると、データベースはそれらの検査をアプリケーションが行を取り出すまで延期します。これにより、パフォーマンスは向上しますが、行を取り出しているときの文字セットのコード変換とデータ タイプ変換のエラーの処理を、アプリケーション側で用意することが必要になります。Teradata JDBC Driverは、JDBC FastExportの直接モードが使用されると、SQLWarning (警告コード 1298)をPreparedStatementの警告の連鎖に追加してアプリケーションに通知します。
• FastExportの結果セットの順序付け動作は、通常のSQL接続の場合と異なる可能性があります。特に、順序付けされた分析関数が含まれる問合わせでは順序付けされた結果セットが生成されない可能性があります。ORDER BY句を使用して結果セットの順序を保証してください。

JDBC FastExportによってサポートされるJDBCのデータ型

Teradata JDBC DriverによってサポートされるJDBCのデータ型のすべてがJDBC FastExportによってサポートされるとは限りません。例えば、BLOBやCLOBなどです。

JDBC FastExportを支援するJDBCエスケープ関数

• Connection.nativeSQL("{fn teradata_amp_count()}")

  これは、データベース用に設定されたAMPの数を返します。この情報は、作成可能なJDBC FastExport接続の最大数を判定する際に役立ちます。

• Connection.nativeSQL("{fn teradata_logon_sequence_number()}")

  これは、このConnectionによって作成されたJDBC FastExportのPreparedStatementの、JDBC FastExport対応のPreparedStatement.hashCode()と関連ログオン シーケンス番号(LSN)との、カンマで区切られたペアを返します。

  たとえば、文字列"6166383,1850,22323092,1851"は、2つのJDBC FastExportのPreparedStatementsがアクティブなことを示しています。最初のJDBC FastExport PreparedStatement のハッシュ コードは61663483で、LSN 1850を使用します。2つ目のハッシュ コードは22323092でLSN 1851を使用します。

  この情報は、プログラム例に示されているような、JDBC FastExport接続のDBC.SessionInfo.SessionNoを探す際に役立ちます。LSNは、JDBC FastExportがアクティブになるまで割り当てられません。パラメータ マーカーがWHERE句の条件で使われており、少なくとも1列の値がJDBC FastExport PreparedStatement を使ってバインドされている場合、JDBC FastExportはアクティブになります。そうでない場合は、JDBC FastExportは、JDBC FastExport PreparedStatement が実行されるとアクティブになります。

JDBC Monitor

JDBC Monitorは、データベース内の標準の性能モニターおよびプロダクト制御機能にアクセスし、使用するメソッドを提供します。

JDBC Monitorの有効化

JDBC Monitorは、PARTITION=MONITOR接続パラメータを指定して有効にします。有効にすると、データベースとの通信でMonitorプロトコルが専用に使用されます。データベースPM/API Monitorのコマンドのみ、Monitorプロトコルに従って実行できます。SQL DMLとSQL DDL文は、Monitorプロトコルを使用して実行できません。

JDBC Monitor使用時の考慮事項

• JDBC Monitorで接続する前に、Monitor文を実行するためのアクセス権をユーザーに付与しておく必要があります。例えば、ユーザー"guest"として接続し、任意のMonitor文を実行する前に、"GRANT MONITOR TO guest"を実行します。
• Monitorバージョン8以前では、Teradataセッション文字セットは、ASCII、KANJISJIS_0S、KANJIEUC_0U、またはLATIN1252_0Aのいずれかになります。
• Monitorバージョン9およびTeradata JDBC Driver 13.10.00.19からは、Teradataのセッション文字セットUTF8およびUTF16がサポートされています。
• JDBC Monitorは、PreparedStatement で使用する必要があります。
• PreparedStatement は、単一のPM/API Monitorコマンドである必要があります。複文要求はサポートされていません。
• PrepareStatement値をバインドする場合、JDBC Monitorでは、SQL接続でサポートされるよりも少ない数のJDBCデータ型をサポートしています。例えば、JDBC MonitorではBLOBまたはCLOBをサポートしません。SQL接続では、Teradata JDBC Driverによって提供されるJDBCのデータ型変換のすべてがJDBC Monitorによって提供されるとは限りません。
• Monitorバージョン8以前のコマンドでは、すべてのString値が固定長のCHARデータ型である必要があります。したがって、Teradata JDBC DriverではMonitorバージョン8以前のコマンドに対して以下のルールが課されています。
  • LONGVARCHARデータ型とVARCHARデータ型は自動的にCHARデータ型に変換されます。
  • NullのString値をバインドするときは、PreparedStatement.setObject にscaleを指定したものを呼び出します。scaleは、実行されるMonitor文で予測されるCHAR列のサイズをTeradata JDBC Driverに通知します。
  • PreparedStatement.setObject にscaleを指定すると、指定したscaleよりも短いStringには、その末尾までスペースが埋め込まれます。
  • String値がPreparedStatement.setStringまたはscaleなしのPreparedStatement.setObject にバインドされている場合、Stringの長さがMonitor文の予測の長さと正確に一致していることを確認するのは、アプリケーション側での責務と想定されます。
  • メソッドPreparedStatement.setStringは、NullのString値では呼び出せません。
  • メソッドPreparedStatement.setNullは、CHAR、LONGVARCHAR、またはVARCHARのデータ型では呼び出せません。
  • scaleなしのメソッドPreparedStatement.setObject を呼び出してNullのString値をバインドすることはできません。
• Monitorバージョン9以降のコマンドでは、すべてのString値がタイプVARCHARである必要があります。したがって、Teradata JDBC DriverではMonitorバージョン9以降のコマンドに対して以下のルールが課されています。
  • アプリケーションは、他のデータ値をバインドする前にMonitorバージョン番号をバインドする必要があります。
  • CHARデータ型とLONGVARCHARデータ型は自動的にVARCHARデータ型に変換されます。
  • メソッドPreparedStatement.setStringは、NullのString値で呼び出すことができます。
  • メソッドPreparedStatement.setNullは、CHAR、LONGVARCHAR、またはVARCHARのデータ型で呼び出すことができます。
  • scaleなしのメソッドPreparedStatement.setObject を呼び出してNullのString値をバインドできます。
• Monitor文を実行するためには、PreparedStatement.executeのみを使用します。
• JDBC Monitorは、SQLWarningを設定することがあります。したがって、文が実行された後は、SQLWarningが設定されていないことを必ずチェックすることを推奨します。
• JDBC MonitorでのPreparedStatement オブジェクトの同時使用は許可されていますが、データベースによって課せられる制限を受けます。課せられる制限についての詳細は、「ワークロード管理API:PM/APIおよびオープンAPI」を参照してください。