Oracle® Fusion Middleware Oracle WebLogic Server タイプ4 JDBCドライバ 11g リリース1(10.3.3) B61001-01 |
|
前 |
次 |
次の項では、WebLogic タイプ4 JDBC SQL Serverドライバの構成方法と使用方法について説明します。
注意: WebLogic タイプ4 JDBC MS SQL Serverドライバ(この章の主題)は、非推奨となったWebLogic jDriver for Microsoft SQL Serverに置き換わるものです。新しいドライバはJDBC 3.0に準拠しており、JDBC 2.0拡張機能の一部をサポートし、パフォーマンスが向上しています。WebLogic jDriver for Microsoft SQL Serverの代わりに、新しいWebLogic タイプ4 JDBC MS SQL Serverドライバを使用してください。 |
WebLogic タイプ4 JDBC MS SQL Serverのドライバ・クラスは次のとおりです。
XA: weblogic.jdbcx.sqlserver.SQLServerDataSource Non-XA: weblogic.jdbc.sqlserver.SQLServerDriver
Microsoft SQL Serverデータベースに接続するには、次の形式のURLを使用します。
jdbc:weblogic:sqlserver://hostname:port[;property=value[;...]]
説明:
hostnameは、接続するサーバーのTCP/IPアドレスまたはTCP/IPホスト名です。IPアドレスの使用については、「IPアドレスの使用」を参照してください。
注意: 信頼性のないアプレットから、そのホスト以外のマシンへのソケットを開くことはできません。 |
portは、TCP/IPポートの番号です。
property=valueは、接続プロパティを指定します。接続プロパティの一覧および各プロパティに指定できる値については、「SQL Server接続プロパティ」を参照してください。
例:
jdbc:weblogic:sqlserver://server1:1433;User=test;Password=secret
名前付きインスタンスに接続する手順については、「名前付きインスタンスへの接続」を参照してください。
Microsoft SQL ServerおよびMicrosoft SQL Server 2005では、SQL Serverデータベースの複数のインスタンスを同じサーバーで同時に実行することができます。各インスタンスはインスタンス名で識別されます。
接続URLを使用して名前付きのインスタンスに接続するには、次の形式でURLを指定します。
jdbc:weblogic:sqlserver://server_name\\instance_name
注意: \\instance_name の最初のバックスラッシュ(\)はエスケープ文字です。 |
説明:
server_nameは、サーバーのIPアドレスまたはホスト名です。
instance_nameは、サーバー上の接続先インスタンスの名前です。
たとえば次の接続URLを指定すると、server1上のinstance1に接続されます。
jdbc:weblogic:sqlserver://server1\\instance1;User=test;Pasword=secret
表6-1に、SQL ServerドライバでサポートされるJDBC接続プロパティを示し、各プロパティについて説明します。WebLogic ServerドメインのJDBCデータ・ソースの構成でこれらの接続プロパティを使用できます。プロパティを指定するには、JDBCデータ・ソースの構成で、property=value
の形式を使用します。
注意: すべての接続文字列プロパティ名で、大文字と小文字は区別されません。たとえば、Passwordはpasswordと同じです。 |
表6-1 SQL Serverの接続プロパティ
プロパティ | 説明 |
---|---|
AccountingInfo |
データベースに格納する会計情報。この値がローカルに格納され、データベースの管理/監視に使用されます。 データ型: string 有効な値: |
AlternateServers |
選択したフェイルオーバー・メソッドに基づいて、新しい接続または損失した接続をフェイルオーバーするのに使用する代替データベース・サーバーのリスト。フェイルオーバー・メソッドの選択の詳細は、 データ型: String 有効な値:
各代替サーバーのエントリについてサーバー名(
たとえば、次のURLは
デフォルト: なし データ型: String |
AlwaysReportTriggerResults |
データベース・トリガー(データベースに格納されており、表が修正されたときに実行または起動されるプロシージャ)によって生成された結果を、ドライバがどのように報告するかを指定します。Microsoft SQL Server 2005では、データ定義言語(DDL)イベントによって起動されたトリガーが含まれます。 有効な値:
この場合、実行した文によって生成された更新件数のみが結果として返されます(エラーが発生していない場合)。トリガー結果は無視されますが、トリガーによって生成されたエラーは報告されます。トリガーによって生成された警告はキューに入れられます。エラーが報告される場合は、更新件数は報告されません。 デフォルトは |
ApplicationName |
データベースに格納されるアプリケーションの名前。Microsoft SQL Server 2000以上では、この値によりデータベースのsysprocesses表にあるprogram_name値が設定されます。Microsoft SQL Server 7では、この値はローカルで格納されています。この値はデータベース監視および管理の目的のため使用します。 有効な値: 注意: データベースによって値に文字列の長さが制限される場合があります。値が制限を超えていると、ドライバによって値が切り捨てられます。 デフォルト: 空の文字列 データ型: String 別名: |
AuthenticationMethod |
ドライバが接続を確立する際に使用する認証方法を指定します。指定された認証方法がデータベース・サーバーでサポートされていない場合は、接続に失敗してドライバから例外がスローされます。 有効な値:
注意: type4、type2、およびnoneの値は、非推奨になりましたが、下位互換性のために認識されます。代わりにkerberos、ntlm、およびuserIdPasswordの使用を推奨します。 SQL Serverドライバによる認証の使用方法については、「認証」を参照してください。 デフォルト: データ型: String |
BulkLoadBatchSize |
データをバルク・ロードするときにデータベースに一度にロードする行数に関して、ドライバに提案します。少数のネットワーク・ラウンド・トリップが必要となるため、ドライバから一度にロードされる行数を増やすことでパフォーマンスが改善されます。ロードされる行数を増やすと、ドライバからクライアントのより多くのメモリーが消費される場合があります。 注意:
有効な値: デフォルト: 2048 |
BulkLoadOptions |
ドライバを利用できる一括ロード・プロトコルのオプションを有効にします。有効な値は、すべての有効にされたオプションの累積値です。次のリストには、値および有効にする対応オプションが記載されています。
0の場合、すべてのオプションは無効になります。 例: 67の値は、 デフォルト: 0 データ型: long |
ClientHostName |
データベースに格納されるクライアント・マシン上のホスト名またはワークステーションID。Microsoft SQL Server 2000以上では、この値はデータベースにあるsysprocesses表のホスト名の値を設定します。For Microsoft SQL Server 7では、この値はローカルに保存されます。この値はデータベースの監視および管理の目的で使用されます。 有効な値: 注意: データベースによって値に文字列の長さが制限される場合があります。値が制限を超えていると、ドライバによって値が切り捨てられます。 デフォルト: 空の文字列 データ型: String 別名: |
CodePageOverride |
ドライバが文字データの変換に使用するコード・ページを指定します。指定したコード・ページによって、デフォルトのデータベース・コード・ページがオーバーライドされます。データベースとやり取り(取得および書込み)するすべての文字データは、指定したコード・ページを使用して変換されます。値としては、使用しているJVMでサポートされている有効なコード・ページの名前(たとえば デフォルトでは、文字データの変換に使用するコード・ページが自動的に識別されます。このプロパティは、ドライバのデフォルト動作を変更する必要がある場合にのみ使用します。
|
ConnectionRetryCount |
ドライバがプライマリ・データベース・サーバーへ接続試行を再試行する回数です。指定した場合、接続の確立に成功するまでサーバーを入れ替えます。 注意: アプリケーションはログイン・タイムアウト値(たとえば、 有効な値: 0| 0の場合、最初の試行が失敗したら再接続は試行されません。
注意: 試行の待機間隔は、ConnectionRetryDelayプロパティで秒単位で指定します。 例: このプロパティを2に設定し、 デフォルト: 5 (秒) データ型: int |
ConnectionRetryDelay |
ConnectionRetryCountが正の整数に設定されている場合に、ドライバがそれぞれの接続の再試行の間に待機する秒数。 有効な値: 0| 0に設定すると、ドライバでは再試行の間に遅延がありません。
例: デフォルト: 1 (秒) データ型: int |
ConvertNull |
データ変換におけるnull値の処理方法を制御します。 有効な値: 0 | 1 1の場合、ドライバは、リクエストされたデータ型とデータを格納する表列のデータ型を照合します。リクエストされた型と列の型の間の変換が定義されていない場合は、列値のデータ型に関係なく、「unsupported data conversion」例外が生成されます。 0の場合、列の値がnullであると、ドライバでデータ型がチェックされません。これによって、リクエストした型および列の型間の変換が定義されていない場合も、null値が戻されます。 デフォルト: 1 データ型: int |
データベース |
DatabaseNameプロパティの別名。 |
DatabaseName |
接続先のデータベースの名前。 有効な値: デフォルト: なし 別名:
|
DescribeParameters |
ドライバが実行時にデータベースのデータ型に基づいて、Stringパラメータのサーバーへの送信方法を決定するかどうかを制御します。Stringパラメータをデータベースが予期する型で送信すると、パフォーマンスが向上し、データ型の不一致による予期しないロックの問題を防止できます。 デフォルト値:
デフォルト値: データ型: String |
EnableBulkLoad |
ドライバは、バッチ挿入のために、データベースにメカニズムではなく、ネイティブのバッチ・バルク・ロード・プロトコルを使用するかどうかを指定します。バルク・ロードは、通常、データベースが行うデータの解析処理をバイパスします。これにより、バッチ操作よりパフォーマンスが向上されます。このプロパティを使用すると、アプリケーション・コードを変更せずに、バッチ挿入がある既存のアプリケーションでバルク・ロードを利用できます。有効な値:
デフォルト: データ型: boolean |
EnableCancelTimeout |
問合せタイムアウトの結果として送信された取消しリクエストが、その取消しリクエストによって取り消された文と同じ問合せタイムアウト値で制限されるかどうかを決定します。 有効な値:
デフォルト: データ型: boolean |
EncryptionMethod |
データがドライバとデータベース・サーバー間のネットワークで送信される場合、データを暗号化および復号化するどうかを決定します。 注意: ドライバがSSL用に構成されているのにデータベース・サーバーでSSLがサポートされていないと、接続のハングが発生する可能性があります。SSLをサポートしていないサーバーに接続した場合に発生する問題を回避するには、LoginTimeoutプロパティを使用してログイン・タイムアウトを設定します。 デフォルト値:
SSLが有効の場合、次のプロパティも適用されます。
注: SSLが有効の場合、ドライバは、サーバーのデフォルトのパケット・サイズにより設定されたデータベース・プロトコル・パケットと通信します。 PacketSizeプロパティで設定された値が無視されます。 デフォルト値: データ型: String |
FailoverGranularity |
ドライバが、接続の欠落について接続の再確立を試行しているときに例外が発生する場合、プロセスを続行するか全体のフェイルオーバー・プロセスに失敗するかを指定します。 デフォルト値:
デフォルト値: データ型: String |
FailoverMode |
ドライバから使用されるフェイルオーバー・メソッドのタイプを指定します。 有効な値:
注意:
デフォルト値: データ型: String |
FailoverPreconnect |
ドライバが同時にプライマリ・サーバーと代替サーバーへの接続を試行するかどうかを指定します。
注意: デフォルト: データ型: boolean |
HostNameInCertificate |
SSL暗号化が有効( 有効な値:
注意: 複数のCN部分が存在する場合、ドライバによってホスト名がそれぞれのCN部分と照合されます。照合が1つでも一致すれば、接続が確立されます。 指定しない場合、ドライバは証明書のホスト名を検証しません。 SSL暗号化または証明書の検証が有効になっていない場合、このプロパティで指定された値は無視されます。 認証の構成の詳細は、「データの暗号化」を参照してください。 デフォルトは空の文字列です。 |
HostProcess |
|
ImportStatementPool |
文プールの内容をロードするために使用されるファイルのファイル名およびパスを指定します。このプロパティが指定されている場合、文が、指定されたファイルから文プールにインポートされます。接続を確立するとき、指定されたファイルがドライバから見つけられない場合、接続に失敗して例外がスローされます。 有効な値: デフォルト: 空の文字列 データ型: String |
InitializationString |
ドライバがデータベースへの接続を確立し、その接続のすべての初期化を実行した後に実行する1つまたは複数のSQLコマンドを指定します。SQLコマンドの実行が失敗した場合、接続試行も失敗し、どのSQLコマンドが失敗したかを示す例外が、ドライバからスローされます。 有効な値: 複数のコマンドは、セミコロンで区切る必要があります。また、このプロパティが接続URLで指定されると、複数のコマンドを指定するときは値全体をカッコで囲む必要があります。 例: 次の接続URLでは、Microsoft SQL Serverデフォルトにnull値が設定され、デリミタ付き識別子を指定できます。
Default: None データ型: String |
InsensitiveResultSetBufferSize |
ドライバがインセンシティブな結果セット・データのキャッシュに使用するメモリーの量を指定します。 有効な値:
デフォルト: 2048 データ型: int |
JavaDoubleToString |
double値やfloat値をstring値に変換する際に、ドライバによって、どのアルゴリズムが使用されるかを指定します。デフォルトでは、ドライバの内部アルゴリズムが使用されます。これにより、パフォーマンスが向上します。 有効な値: true | false
デフォルト: データ型: boolean |
JDBCBehavior |
ドライバが、 有効な値:
たとえば、完全修飾プロシージャ デフォルト: 1 データ型: int |
LoadBalancing |
ドライバでのデータベース・サーバー(プライマリおよび代替)への接続試行にクライアント・ロード・バランシングが使用されるかどうかを指定します。 有効な値:
デフォルト: データ型: boolean |
LoadLibraryPath |
NTLM認証のためのDLLのディレクトリを指定します。ドライバは指定されたディレクトリでDLLを検索します。 注: ドライバをインストールすると、NTLM認証DLLが 有効な値: 指定されていない場合、ドライバは、環境変数 デフォルト: なし データ型: String |
LoginTimeout |
接続リクエストがタイムアウトする前にドライバが接続が確立されるのを待機する時間(秒単位)。 有効な値:
デフォルト: データ型: int |
LongDataCacheSize |
ドライバが結果セット内で長いデータ(イメージ、画像、長いテキストまたはバイナリ・データ)をキャッシュするかどうかを決定します。パフォーマンスを向上するために、アプリケーションが結果セット内の定義順に列を取得する場合に長いデータ・キャッシュを無効化できます。 有効な値:
このプロパティを構成して最適なパフォーマンスを実現する方法については、「パフォーマンスに関する考慮事項」を参照してください。 デフォルト: 2048 データ型: int |
MaxPooledStatements |
この接続のプールされたプリペアド文の最大数。 有効な値:
デフォルト: データ型: int 別名: |
MaxStatements |
|
NetAddress |
Microsoft SQL Serverに接続するアプリケーションのネットワーク・インタフェース・カードのメディア・アクセス制御(MAC)アドレス。この値は最大12文字の文字列。このプロパティの値はデータベース管理に有用となります。この値は以下のnet_address列に格納されます。
デフォルトは000000000000です。 |
PacketSize |
データベース・サーバーからクライアント・マシンに転送される各データベース・プロトコル・パケットのバイト数を決定します(Microsoft SQL Serverではこのパケットのことを「ネットワーク・パケット」と呼びます)。 パケット・サイズを調整するとパフォーマンスが向上する可能性があります。最適なサイズは、アプリケーションやその実行環境によって挿入、更新、または返されるデータの一般的なサイズによって異なります。通常は、パケット・サイズを大きくするほど大量のデータを処理しやすくなります。たとえば、アプリケーションが10,000文字の長さの値を定期的に返す場合は、一般に32 (16 KB)の値を使用するとパフォーマンスが向上します。 有効な値:
x (1 - 128の整数)に設定した場合、ドライバは512バイトの倍数のパケット・サイズを使用します。たとえば、 このプロパティを構成して最適なパフォーマンスを実現する方法については、「パフォーマンスに関する考慮事項」を参照してください。 デフォルトは |
Password |
Microsoft SQL Serverデータベースに接続する場合に使用するパスワード。大文字と小文字は区別されません。パスワードは、データベースでSQL Server認証が有効化されている場合にのみ必要となります。その場合は、システム管理者に連絡してパスワードを取得します。 有効な値: デフォルト: なし データ型: String 認証の構成の詳細は、「認証」を参照してください。 |
PortNumber |
Microsoft SQL Serverデータベースへの接続をリスニングするプライマリ・データベース・サーバーのTCPポート。 このプロパティは、データ・ソース接続でのみサポートされます。 有効な値: デフォルト: 1433 データ型: int |
ProgramID |
データベースに格納されるクライアント上のドライバの製品とバージョン情報。Microsoft SQL Server 2000以上の場合、この値はhostprocessをsysprocesses表に設定します。Microsoft SQL Server 7の場合、この値は、ローカルに保存されます。この値はデータベース管理・監視の目的で使用します。 有効な値: DDJVVRRMで、詳細は次のとおりです。
例: DDJ04100 デフォルト: 空の文字列 データ型: String 別名: |
ProgramName |
|
QueryTimeout |
接続で作成されたすべてのstatementsのデフォルト問合せタイムアウト(秒単位)を設定します。 有効な値:
デフォルト: 0 データ型: int |
ReceiveStringParameterType |
ドライバがStringのストアド・プロシージャの出力パラメータをデータベースに記述する方法を指定します。 有効な値:
デフォルト: データ型: String |
ResultSetMetaDataOptions |
アプリケーションで表名情報が必要な場合は、Select文のResultSetメタデータに表名情報を含めて戻せます。 有効な値: 0 | 1 0 (デフォルト)に設定した場合は、ResultSetMetaData.getTableName()メソッドが呼び出されても、結果セットの各列の正しい表名を特定するための追加処理は実行されません。この場合、getTableName()メソッドは結果セット内の列ごとに空の文字列を返す可能性があります。 1に設定した場合は、ResultSetMetaData.getTableName()メソッドが呼び出されると、結果セットの各列の正しい表名を特定するための追加処理が実行されます。ResultSetMetaData.getSchemaName()メソッドとResultSetMetaData.getCatalogName()メソッドが呼び出された場合、スキーマ名とカタログ名の情報を返すこともできます(ドライバがこの情報を判別できる場合)。 ResultSetメタデータを返す方法の詳細は、「ResultSetメタデータのサポート」を参照してください。 デフォルト: 0 データ型: int |
SelectMethod |
ドライバが、Select文でデータベース・カーソルをリクエストするかどうかを判定するためのヒント。ドライバがリクエストされたメソッドを常に満たすとは限らないのでヒントとして定義されるこのプロパティによって、ドライバのパフォーマンスと動作は影響を受けます。 有効な値:
このプロパティを構成して最適なパフォーマンスを実現する方法については、「パフォーマンスに関する考慮事項」を参照してください。 デフォルト: データ型: String |
SendStringParametersAsUnicode |
文字列パラメータをMicrosoft SQLサーバー・データベースにデータベースのデフォルトの文字エンコーディングまたはUnicodeで送信するかどうかを決定します。 有効な値:
このプロパティを構成して最適なパフォーマンスを実現する方法については、「パフォーマンスに関する考慮事項」を参照してください。 デフォルト: データ型: boolean |
ServerName (必須) |
プライマリ・データベース・サーバーまたは名前付きのインスタンスのIPv4またはIPv6形式のIPアドレスを指定するか、ネットワークで名前付きのサーバーがサポートされている場合はサーバー名を指定します。たとえば、122.23.15.12またはSQLServerServerのように指定します。 有効な値: 名前付きインスタンスに接続するには、このプロパティに このプロパティは、データ・ソース接続でのみサポートされます。 名前付きインスタンスへの接続の詳細は、「名前付きインスタンスへの接続」を参照してください。 デフォルト: なし データ型: String |
SnapshotSerializable |
Microsoft SQL Server 2005以降でのみサポートされます。アプリケーションで接続にSnapshot分離を使用できるようにします。 このプロパティは 有効な値:
注意:
データ型: boolean |
SpyAttributes |
Spyはアプリケーションのかわりにドライバによって送信された呼出しの詳細情報を記録するようにします。Spyはデフォルトでは有効にされません。 有効な値: ( 付録D「WebLogic JDBC SpyでJDBCコールのトラッキング」を参照してください。 注意: Java文字列でファイルを記録するために、Windowsでパスをコーディングする場合、バックスラッシュ文字(\)の前にJavaエスケープ文字(バックスラッシュ)が必要です。たとえば、次のようになります。
データ型: String |
TransactionMode |
ドライバがローカル・トランザクションの開始を区切る方法を制御します。 有効な値:
デフォルト: データ型: String |
TruncateFractionalSeconds |
ドライバはタイムスタンプの値を3つの小数秒で切り捨てるかどうかを決定します。たとえば、 有効な値:
デフォルト: true データ型: boolean |
TrustStore |
SSLサーバー認証を使用している場合に、使用するトラスト・ストア・ファイルのディレクトリを指定します。トラスト・ストア・ファイルには、クライアントが信頼する認証局(CA)のリストが格納されています。 この値によって、javax.net.ssl.trustStore Javaシステム・プロパティに指定されたトラスト・ストア・ファイルのディレクトリがオーバーライドされます。このプロパティが指定されていない場合は、javax.net.ssl.trustStore Javaシステム・プロパティに指定されたトラスト・ストア・ファイルのディレクトリが使用されます。 このプロパティは、 有効な値: デフォルト: なし データ型: String |
TrustStorePassword |
SSLサーバー認証を使用している場合に、使用するトラスト・ストア・ファイルのパスワードを指定します。トラスト・ストア・ファイルには、クライアントが信頼する認証局(CA)のリストが格納されています。 この値によって、javax.net.ssl.trustStorePassword Javaシステム・プロパティに指定されたトラスト・ストア・ファイルのパスワードがオーバーライドされます。このプロパティが指定されていない場合は、javax.net.ssl.trustStorePassword Javaシステム・プロパティに指定されたトラスト・ストア・ファイルのパスワードが使用されます。 このプロパティは、 有効な値: デフォルト: なし データ型: String |
User |
Microsoft SQL Serverデータベースに接続する場合に使用するユーザー名。大文字と小文字は区別されません。ユーザー名は、データベースでSQL Server認証が有効化されている場合にのみ必要となります。その場合は、システム管理者に連絡してユーザー名を取得します。 有効な値: デフォルト: なし データ型: String |
UseServerSideUpdatableCursors |
更新可能な結果セットをリクエストされた場合、ドライバがサーバー側カーソルを使用するかどうかを決定します。 有効な値:
サーバー側で更新可能なカーソルの使用方法については、「サーバー側で更新可能なカーソル」を参照してください。 このプロパティを構成して最適なパフォーマンスを実現する方法については、「パフォーマンスに関する考慮事項」を参照してください。 デフォルト: データ型: boolean |
ValidateServerCertificate |
SSL暗号化が有効になっている場合( 有効な値:
トラスト・ストア情報は、TrustStoreおよびTrustStorePasswordプロパティ(または対応するJavaシステム・プロパティ)を使用して指定します。 認証の構成の詳細は、「データの暗号化」を参照してください。 デフォルト: データ型: boolean |
WSID |
|
XATransactionGroup |
接続によって開始された各トランザクションを特定するためのトランザクション・グループID。このIDは、分散トランザクションのクリーン・アップに使用できます。 有効な値:
分散トランザクションのクリーン・アップの詳細は、「分散トランザクションのクリーン・アップ」を参照してください。 デフォルト: なし データ型: String |
XMLDescribeType |
ドライバがXMLデータをONGVARCHARまたはLONGVARBINARYのデータ型にマップするかどうかを決定します。 有効の値:
詳細は、「返されるXMLデータとその挿入/更新」を参照してください。 デフォルト: なし データ型: String |
以下に示すようにSQL Serverドライバの接続プロパティを設定すると、アプリケーションのパフォーマンスを向上させることができます。
バッチ挿入のために、ドライバによって、バッチ・メカニズムのかわりにネイティブな一括ロード・プロトコルを使用できます。バッチ操作の追加のパフォーマンスとして、データベースから実行されたデータ解析が一括ロードでバイパスされます。このプロパティをtrueに設定すると、バッチ挿入との既存のアプリケーションに、コードを変更しないで一括ロードが使用できます。
データの暗号化と復号化により余分なオーバーヘッド(主にCPUの使用率)がかかるため、パフォーマンスが低下する場合があります。
スクロール・インセンシティブな結果セットを使用する場合のパフォーマンスを向上させるため、ドライバは結果セット・データをディスクに書き込む代わりに、メモリーにキャッシュできます。デフォルトでは、ドライバはインセンシティブな結果セット・データを2 MBまでメモリーにキャッシュし、残りの結果セット・データをディスクに書き込みます。パフォーマンスを向上させるには、ドライバがデータをディスクに書き込む前に使用するメモリーの量を増やすか、ドライバがインセンシティブな結果セット・データをディスクに書込めないようにします。最大キャッシュ・サイズの設定は2 GBです。
アプリケーションが画像、ピクチャ、長いテキスト、またはバイナリ・データを取得するときのパフォーマンスを向上させるために、アプリケーションが長いデータ列値を結果セット内での定義順に取得する場合は、クライアントで長いデータのキャッシュを無効にすることができます。アプリケーションが長いデータ列値を順不同で取得する場合は、長いデータ値をクライアントでキャッシュする必要があります。この場合は、データをディスクに書き込む前にドライバによって使用されるメモリーの容量を増やすことで、パフォーマンスを改善できます。
ドライバがアプリケーション・サーバー内部から実行されない場合、または独自のプリペアド文のプールを提供しない別のアプリケーション内部から実行されない場合は、パフォーマンスを向上させるため、ドライバ独自の内部プリペアド文のプールを有効にする必要があります。ドライバの内部プリペアド文のプールを有効にすると、ドライバは、アプリケーションによって作成された特定数のプリペアド文をキャッシュします。たとえば、MaxPooledStatements
プロパティを20に設定した場合、ドライバは、アプリケーションによって作成された最後の20個のプリペアド文をキャッシュします。このプロパティに設定された値が、アプリケーションが使用するプリペアド文の数よりも大きい場合、すべてのプリペアド文がキャッシュされます。
通常、クライアントはサーバーで許可されている最大パケット・サイズを使用するのが適しています。これにより、クライアントへデータを返すために必要な往復回数が減るため、パフォーマンスが向上します。つまり、このプロパティにデータベース・サーバーの最大パケット・サイズを設定すると、パフォーマンスを向上させることができます。
デフォルトでは、ResultSetMetaData.getTableName()
メソッドが呼び出された場合、SQL Serverドライバは、結果セット内の各列の正しい表名を返すために必要な追加の処理を省略します。このため、getTableName()
メソッドは結果セット内の列ごとに空の文字列を返す可能性があります。アプリケーションで表名情報が必要ない場合は、この設定によって最適なパフォーマンスが得られます。
ResultSetメタデータを返す方法の詳細は、「ResultSetメタデータのサポート」を参照してください。
ほとんどの場合、サーバー側のデータベース・カーソルを使用するとパフォーマンスに悪影響を与えます。ただし、アプリケーションが次のような条件に該当する場合は、このプロパティの最適な設定はcursorです。この設定は、サーバー側のデータベース・カーソルを使用することを表します。
アプリケーションに大量のデータを返す問合せが含まれています。
アプリケーションが、以前の大きな結果セットを処理する前または閉じる前にSQL文を実行し、これを複数回行います。
アプリケーションによって返される大きな結果セットが前方専用のカーソルを使用しています。
アプリケーションによってアクセスされるすべてのデータが、デフォルトのデータベースの文字エンコーディングを使用してデータベースに格納される場合、SendStringParametersAsUnicode
の設定をfalseにするとパフォーマンスを向上させることができます。
この接続プロパティを操作するには、スナップショット分離に対してMicrosoft SQL Server 2005以上のデータベースが構成されている必要があります。詳細は、「スナップショット分離レベルの使用(Microsoft SQL Server 2005以上)」を参照してください。
スナップショット分離は、データを変更するまでデータのロックを取得しないことにより、トランザクションレベルの読取り一貫性およびデータ変更に対するオプティミスティックなアプローチを提供します。他のトランザクションがデータを変更していても、同じ結果セットを戻す場合、1)アプリケーションが多くの読取り操作を実行する場合、または2)ユーザーによりデータの読取りをブロックされる可能性のある実行時間の長いトランザクションがアプリケーションにある場合、このMicrosoft SQL Server 2005以上の機能が役立ちます。この機能を使用することにより、読取り操作と更新操作間のデータ競合を排除できます。この接続プロパティをtrueに設定した場合(それによって、スナップショット分離を使用します)、高い同時実行性によりパフォーマンスが向上されます。
ほとんどの場合、サーバー側で更新可能なカーソルを使用するとパフォーマンスが向上します。ただし、このタイプのカーソルは、インセンシティブな結果セット、または主キーを含むデータベース表から生成されていないセンシティブな結果セットで使用することはできません。
サーバー側で更新可能なカーソルの使用方法については、「サーバー側で更新可能なカーソル」を参照してください。
表6-2には、SQLドライバでサポートされているデータ型とJDBCデータ型へのマッピング方法を示します。
表6-2 Microsoft SQL Serverデータ型
Microsoft SQL Server Serverデータ型 | JDBCのデータ型 |
---|---|
bigint脚注1 |
BIGINT |
bigint identity 脚注2 |
BIGINT |
binary |
BINARY |
bit |
BIT |
char |
CHAR |
date |
DATE |
datetime |
TIMESTAMP |
datetime2 |
TIMESTAMP |
datetimeoffset |
VARCHAR |
decimal |
DECIMAL |
decimal() identity |
DECIMAL |
float |
FLOAT |
image |
LONGVARBINARY |
int |
INTEGER |
int identity |
INTEGER |
money |
DECIMAL |
nchar |
CHAR 注意: |
ntext |
LONGVARCHAR 注意: |
数値 |
NUMERIC |
numeric() identity |
NUMERIC |
nvarchar |
VARCHAR 注意: |
nvarchar(max)脚注3 |
LONGVARCHAR 注意: |
real |
REAL |
smalldatetime |
TIMESTAMP |
smallint |
SMALLINT |
smallint identity |
SMALLINT |
smallmoney |
DECIMAL |
sql_variant 脚注4 |
VARCHAR |
sysname |
VARCHAR |
text |
LONGVARCHAR |
time |
TIMESTAMP |
timestamp |
BINARY |
tinyint |
TINYINT |
tinyint identity |
TINYINT |
uniqueidentifier |
CHAR |
varbinary |
VARBINARY |
varbinary(max) 脚注5 |
LONGVARBINARY |
varchar |
VARCHAR |
varchar(max) 脚注 6 |
LONGVARCHAR |
xml 脚注7 |
LONGVARCHAR 注意: |
脚注1 Microsoft SQL Server 2000以上でのみサポートされます。
脚注2 Microsoft SQL Server 2000以上でのみサポートされます。
脚注3 Microsoft SQL Server 2005でのみサポートされます。
脚注4 Microsoft SQL Server 2000以上でのみサポートされます。
脚注5 Microsoft SQL Server 2005でのみサポートされます。
脚注6 Microsoft SQL Server 2005でのみサポートされます。
脚注7 Microsoft SQL Server 2005でのみサポートされます。
データ型の詳細は、付録B「GetTypeInfo」を参照してください。
Microsoft SQL Server 2005以上の場合、SQL Serverのドライバはxmlデータ型をサポートします。xmlデータ型がどのJDBCデータ型にマップされるかは、JDBCBehaviorプロパティおよびXMLDescribeTypeプロパティが設定されているかによって決まります。
XMLDescribeType=longvarchar
またはXMLDescribeType=longvarbinary
の場合、JDBCBehaviorプロパティの設定に関係なく、ドライバはXMLデータ型をJDBC LONGVARCHAR
またはLONGVARBINARY
データ型にマップします。
JDBCBehavior=1
(デフォルト)でXMLDescribeType
プロパティが設定されていない場合、ドライバはXMLデータ型をJDBC LONGVARCHAR
データ型にマップします。
JDBCBehavior=0
でXMLDescribeType
プロパティが設定されていない場合、アプリケーションが使用するJVMに基づいて、XMLデータはSQLXML
またはLONGVARCHAR
にマップされます。アプリケーションがJava SE 6を使用している場合、ドライバはXMLデータ型をJDBC SQLXML
データ型にマップします。アプリケーションが別のJVMを使用している場合、ドライバはXMLデータ型をJDBC LONGVARCHAR
データ型にマップします。
XMLDescribeTypeプロパティを設定すると、XMLデータが文字またはバイナリ・データのどちらとして返されるかを指定できます。たとえば、次のように定義されたデータベース表について検討します。
CREATE TABLE xmlTable (id int, xmlCol xml NOT NULL)
そして、次のようにコーディングしたとします。
String sql="SELECT xmlCol FROM xmlTable"; ResultSet rs=stmt.executeQuery(sql);
アプリケーションがLONGVARBINARYデータ型にマップするXMLデータ型を指定する次の接続URLを使用している場合、ドライバはXMLデータをバイナリ・データとして戻します。
jdbc:weblogic:sqlserver://server1:1433;DatabaseName=jdbc;User=test; Password=secret;XMLDescribeType=longvarbinary
XMLDescribeType=longvarchar
に設定した場合、XMLデータは文字データとして返されます。結果セット列は、列型のLONGVARCHARで表現され、列型名はxmlとなります。
XMLDescribeType=longvarchar
に設定した場合は、アプリケーションで以下のメソッドを使用することで、XML列に文字データとして格納されているデータを返すことができます。
ResultSet.getString() ResultSet.getCharacterStream() ResultSet.getClob() CallableStatement.getString() CallableStatement.getClob()
データベース・サーバーから返されたXMLデータは、データベース・サーバーで使用するUTF-8エンコーディングから、UTF-16 Java文字列エンコーディングに変換されます。
アプリケーションで次のメソッドを使用することで、XML列にASCIIデータとして格納されているデータを返すことができます。
ResultSet.getAsciiStream()
データベース・サーバーから返されたXMLデータは、データベース・サーバーで使用するUTF-1エンコーディングから、ISO-8859-1 (latin1)エンコーディングに変換されます。
注意: getAsciiStream()メソッドを使用して変換を行う場合に、コンテンツ・エンコーディングがデフォルト・エンコーディングではなく、コンテンツ・エンティティを指定するXML宣言が含まれていないと、整形式でないXMLが作成される場合があります。アプリケーションで整形式のXMLが必要になる場合は、getAsciiStream()メソッドを使用しないようにしてください。 |
XMLDescribeType=longvarbinary
に設定した場合は、この項で説明した文字データ用のメソッドを使用しないでください。使用すると、JDBC文字からバイナリへの標準の変換がデータに適用され、文字データの16進表現が返されます。
XMLDescribeType=longvarbinary
に設定した場合、XMLデータはバイナリ・データとして返されます。結果セット列は、列型のLONGVARBINARYで表現され、列型名はxmlとなります。
アプリケーションで以下のメソッドを使用して、XMLデータをバイナリ・データとして返すことができます。
ResultSet.getBytes() ResultSet.getBinaryStream() ResultSet.getBlob() ResultSet.getObject() CallableStatement.getBytes() CallableStatement.getBlob() CallableStatement.getObject()
データベース・サーバーから返されるXMLデータにはデータ変換は適用されません。これらのメソッドは、UTF-8としてエンコードされたXMLデータを格納するバイト配列またはバイナリ・ストリームを返します。
XMLDescribeType=longvarchar
に設定した場合は、この項で説明した文字データ用のメソッドを使用しないでください。使用すると、JDBCバイナリから文字への標準の変換がデータに適用され、バイナリ・データの16進表現が返されます。
ドライバからは、XMLデータを文字データまたはバイナリ・データとして挿入または更新できます。
アプリケーションで以下のメソッドを使用することで、XMLデータを文字データとして挿入または更新できます。
PreparedStatement.setString() PreparedStatement.setCharacterStream() PreparedStatement.setClob() PreparedStatement.setObject() ResultSet.updateString() ResultSet.updateCharacterStream() ResultSet.updateClob() ReultSet.updateObject()
データの文字表現がデータベース・サーバーで使用するXML文字セットに変換され、変換後のXMLデータがサーバーに送信されます。XML処理手順が、ドライバによって解析されたり削除されたりすることはありません。
アプリケーションで以下のメソッドを使用することで、XMLデータをASCIIデータとして更新できます。
PreparedStatement.setAsciiStream() ResultSet.updateAsciiStream()
これらのメソッドに返すデータは、ISO-8859-1 (latin 1)エンコーディングで解釈されます。ISO-8859-1のデータがデータベース・サーバーで使用するXML文字セットに変換され、変換後のXMLデータがサーバーに送信されます。
アプリケーションで以下のメソッドを使用することで、XMLデータをバイナリ・データとして挿入または更新できます。
PreparedStatement.setBytes() PreparedStatement.setBinaryStream() PreparedStatement.setBlob() PreparedStatement.setObject() ResultSet.updateBytes() ResultSet.updateBinaryStream() ResultSet.updateBlob() ReultSet.updateObject()
XMLデータがデータベース・サーバーに送信される際に、データ変換が適用されることはありません。
認証では、ユーザーの識別情報を保護することで、悪意のあるハッカーが転送中のユーザー資格証明を傍受できないようになっています。概要については「認証」を参照してください。
SQL Serverドライバでは、以下の認証方法がサポートされます。
SQL Server認証、またはユーザーID/パスワード認証:アプリケーションから提示されるデータベースのユーザー名とパスワードを使用して、データベースにアクセスするユーザーを認証します。
Kerberos認証: Kerberos (信頼性のあるサード・パーティ認証サービスの1つ)を使用してユーザーの識別情報を検証します。Kerberos認証では、オペレーティング・システムに保持されているユーザー名とパスワードを利用して、データベースにアクセスするユーザーを認証できます。それ以外のユーザー資格証明セットを使用することも可能です。
この方法を指定する場合は、Kerberos環境を構成するための知識が必要になります。また、Windows Active Directory Kerberosのみがサポートされている必要があります。
NTLM認証:シングル・サインオンのWindows認証方法です。この方法ではWindowsクライアントからの認証のみを提供し、必要な構成は最小限です。
NTLM認証(Windowsクライアントの認証のみを提供)を除いて、ドライバがサポート対象のプラットフォームで実行されている場合、これらの認証方法で認証が提供されます。
AuthenticationMethod
接続プロパティは、ドライバが接続を確立する際に使用する認証メカニズムを制御するために使用します。このプロパティに設定する値の詳細は、「AuthenticationMethodプロパティの使用」を参照してください。
AuthenticationMethod
接続プロパティは、ドライバが接続を確立する際に使用する認証メカニズムを指定するために使用します。AuthenticationMethod=auto
の場合、ドライバは以下の条件に基づいて、接続を確立する際にSQL Server認証、Kerberos認証、またはNTLM認証を使用します。
IDとパスワードが指定された場合は、接続を確立する際にSQL Server認証が使用されます。User
プロパティはユーザーIDを提供します。Password
プロパティはパスワードを提供します。
ユーザーIDとパスワードが指定されず、ドライバがWindowsプラットフォーム上で実行されていない場合、ドライバは接続を確立する際にKerberos認証を使用します。
ユーザーIDとパスワードが指定されず、ドライバがWindowsプラットフォーム上で実行されている場合で、ドライバがNTLM認証に必要なDLLをロードできる場合、ドライバは接続を確立する際にNTLM認証を使用します。DLLをロードできない場合は、Kerberos認証を使用します。
AuthenticationMethod=kerberos
に設定すると、接続を確立する際にKerberos認証が使用されます。User
プロパティとPassword
プロパティに指定された値は無視されます。
AuthenticationMethod=ntlm
の場合は、ドライバがNTLM認証に必要なDLLをロードできる場合、ドライバは接続を確立する際にNTLM認証を使用します。DLLをロードできない場合は、ドライバから例外がスローされます。UserプロパティとPasswordプロパティに指定された値は無視されます。
AuthenticationMethod=userIdPassword
(デフォルト)に設定すると、接続を確立する際にSQL Server認証が使用されます。User
プロパティはユーザーIDを提供します。Password
プロパティはパスワードを提供します。ユーザーIDが指定されていない場合は、ドライバから例外がスローされます。
AuthenticationMethod
プロパティをautoまたはuserIdPassword (デフォルト)に設定します。このプロパティに設定する値の詳細は、「AuthenticationMethodプロパティの使用」を参照してください。
User
プロパティにユーザーIDを設定します。
Password
プロパティにパスワードを設定します。
この項では、Microsoft SQL ServerドライバにKerberos認証を構成する場合の要件と手順について説明します。
ドライバにKerberos認証を構成する前に、使用している環境が表6-3の要件を満たしていることを確認してください。
表6-3 SQL ServerドライバにKerberos認証を構成する場合の要件
コンポーネント | 要件 |
---|---|
Microsoft SQL Serverデータベース・サーバー |
データベース・サーバーは、クライアントの管理に使用するドメイン・コントローラで管理する必要があります。また、データベース・サーバーを以下のいずれかのデータベースで実行する必要があります。
|
Kerberosサーバー |
Kerberosサーバーは、認証に使用するユーザーIDを管理します。Kerberos KDCもKerberosサーバーで管理します。 ネットワーク認証は、以下のいずれかのオペレーティング・システム上のWindows Active Directoryから提供する必要があります。
|
クライアント |
クライアントはデータベース・サーバーを管理している同じドメイン・コントローラによって管理される必要があります。また、J2SE 1.4.2以上がインストールされている必要があります。 |
WebLogic Server JDBCドライバのインストールでは、以下のKerberos認証に必要なファイルがWL_HOME
/server/lib
フォルダにインストールします。WL_HOMEは、WebLogic Serverのインストール先ディレクトリです。
krb5.conf。KerberosレルムやそのレルムのKDC名を保持するKerberos構成ファイルです。WebLogic Serverでは汎用ファイルがインストールされるため、使用している環境に合わせて変更する必要があります。
JDBCDriverLogin.confファイル。Kerberos認証に使用するJAAS (Java Authentication and Authorization Service)ログイン・モジュールを指定する構成ファイルです。java.security.auth.login.configシステム・プロパティで別の構成ファイルをロードするように設定されていない限り、このファイルが自動的にロードされます。このファイルを変更することは可能ですが、JAASログイン・モジュールを構成するためには、このファイル内、または指定されている他のログイン構成ファイル内に、JDBC_DRIVER_01エントリが含まれていなければなりません。このファイルの構成オプションの設定については、使用しているJDKのドキュメントを参照してください。
ドライバを構成するには:
ドライバのAuthenticationMethod
プロパティをauto (デフォルト)またはkerberosに設定します。このプロパティに設定する値の詳細は、「AuthenticationMethodプロパティの使用」を参照してください。
krb5.confファイルを変更して、Kerberosレルム名とそのKerberosレルムのKDC名を指定します。テキスト・エディタで編集するか、java.security.krb5.realmおよびjava.security.krb5.kdcシステム・プロパティを指定して、krb5.confファイルを変更します。
注意: Windows Active Directoryでは、Kerberosレルム名はWindowsドメイン名、KDC名はWindowsドメイン・コントローラ名となります。 |
たとえば、Kerberosレルム名がXYZ.COM、KDC名がkdc1である場合、krb5.confファイルは次のようになります。
[libdefaults] default_realm = XYZ.COM [realms] XYZ.COM = { kdc = kdc1 }
krb5.confファイルに有効なKerberosレルム名とKDC名が指定されていない場合は、次の例外がスローされます。
Message:[OWLS][SQLServer JDBC Driver]Could not establish a connection using integrated security: No valid credentials provided
java.security.krb5.confシステム・プロパティで別のKerberos構成ファイルをロードするように設定されていないかぎり、WebLogic JDBCと一緒にインストールされたkrb5.confファイルが自動的にロードされます。
Java 2プラットフォームのセキュリティ・マネージャでKerberos認証を使用する場合は、アプリケーションとドライバにセキュリティ権限を付与する必要があります。詳細は、「Kerberos認証のための権限」を参照してください。
SQL ServerドライバでのWindows認証用に環境を構成およびテストする方法については、以下のURLを参照してください。
デフォルトでは、オペレーティング・システムに保持されているユーザーIDとパスワードを使用して、データベースにアクセスするユーザーの認証が行われます。オペレーティング・システムで使用されているユーザー名とパスワードをデータベースでも使用できるため、有効なオペレーティング・システム・アカウントにログインしているユーザーであれば、ユーザー名とパスワードを入力せずにデータベースにログインできます。
オペレーティング・システムのユーザー名とパスワード以外のユーザー資格証明セットを使用したい場合もあります。たとえば、アプリケーション・サーバーやWebサーバーの多くは、サーバー・ユーザーとしてではなく、アプリケーションが実行されているマシンにログオンしたクライアント・ユーザーの代理として処理を実行します。
オペレーティング・システムのユーザー名とパスワード以外のユーザー資格証明セットを使用する場合は、次のようなコードをアプリケーションに追加し、認証に使用するjavax.security.auth.Subjectを取得してドライバに渡します。
import javax.security.auth.Subject; import javax.security.auth.login.LoginContext; import java.sql.*; // The following code creates a javax.security.auth.Subject instance // used for authentication. Refer to the Java Authentication // and Authorization Service documentation for details on using a // LoginContext to obtain a Subject. LoginContext lc = null; Subject subject = null; try { lc = new LoginContext("JaasSample", new TextCallbackHandler()); lc.login(); subject = lc.getSubject(); } catch (Exception le) { ... // display login error } // This application passes the javax.security.auth.Subject // to the driver by executing the driver code as the subject Connection con = (Connection) Subject.doAs(subject, new PrivilegedExceptionAction() { public Object run() { Connection con = null; try { Class.forName("com.ddtek.jdbc.sqlserver.SQLServerDriver"); String url = "jdbc:weblogic:sqlserver://myServer:1433"; con = DriverManager.getConnection(url); } catch (Exception except) { ... //log the connection error return null; } return con; } }); // This application now has a connection that was authenticated with // the subject. The application can now use the connection. Statement stmt = con.createStatement(); String sql = "SELECT * FROM employee"; ResultSet rs = stmt.executeQuery(sql); ... // do something with the results
アプリケーション・ユーザーがKerberos認証を使用する場合は、まずKerberosサーバーからKerberosチケット認可チケット(TGT)を取得する必要があります。Kerberosサーバーでは、TGTに格納されている資格証明を使用して、ユーザーの識別情報を検証し、サービスへのアクセスを制御します。
アプリケーションがWindowsクライアントからKerberos認証を使用する場合は、アプリケーション・ユーザーがKerberosサーバーにログオンして明示的にTGTを取得する必要はありません。ユーザーのTGTは、Windows Active Directoryによって自動的に取得されます。
アプリケーションがUNIXまたはLinuxクライアントからKerberos認証を使用する場合、ユーザーはkinitコマンドを使用してKerberosサーバーにログオンし、明示的にTGTを取得する必要があります。たとえば、次に示すコマンドは、存続期間が10時間で5日間更新可能なTGTをサーバーにリクエストしています。
kinit -l 10h -r 5d user
ここで、userはアプリケーション・ユーザーです。
kinitコマンドの使用とユーザーのTGTの取得については、Kerberosドキュメントを参照してください。
この項では、DBドライバにNTLM認証を構成する場合の要件と手順について説明します。
NTLM認証のための環境を構成する前に、ご使用の環境が表6-4の要件を満たしていることを確認してください。
表6-4 SQL ServerドライバのNTLM認証の要件
コンポーネント | 要件 |
---|---|
データベース・サーバー |
データベース・サーバーはクライアントを管理している同じドメイン・コントローラによって管理され、以下のいずれかのデータベースを実行している必要があります。
|
ドメイン・コントローラ |
ドメイン・コントローラはデータベース・サーバーとクライアントの両方を管理している必要があります。以下のいずれかのオペレーティング・システム上のNTLMがネットワーク認証を提供する必要があります。
|
クライアント |
クライアントはデータベース・サーバーを管理している同じドメイン・コントローラによって管理され、以下のいずれかのオペレーティング・システムで実行されている必要があります。
また、J2SE 1.4以上がインストールされている必要があります。 |
WebLogic タイプ4 JDBCドライバは以下のNTLM認証DLLを提供しています。
DDJDBCAuthxx.dll (32ビット)
DDJDBC64Authxx.dll (Itanium 64ビット)
DDJDBCx64Authxx.dll (AMD64およびIntel EM64T 64ビット)
xxは2桁の数字です。
DLLは、WL_HOME
/server/lib
ディレクトリにあります(WL_HOMEはWebLogic Serverのインストール先ディレクトリ)。NTLM認証を使用するアプリケーションが32ビットJVMで実行されている場合は、自動的にDDJDBCAuthxx.dllが使用されます。同様に、アプリケーションが64ビットJVMで実行されている場合は、DDJDBC64Authxx.dllまたはDDJDBCx64Authxx.dllが使用されます。
ドライバを構成するには:
AuthenticationMethod
プロパティをauto (デフォルト)またはntlmに設定します。このプロパティに設定する値の詳細は、「AuthenticationMethodプロパティの使用」を参照してください。
デフォルトでは、ドライバはPATH環境変数で定義されているWindowsシステム・パスのディレクトリでNTLM認証DLLを検索します。Windowsシステム・パスにないディレクトリにドライバをインストールした場合は、以下のいずれかの手順を行ってドライバがDLLをロードできるようにします。
WindowsシステムのパスにWL_HOME
/server/lib
ディレクトリを追加します。WL_HOMEは、WebLogic Serverのインストール先ディレクトリ。
WL_HOME
/server/lib
から システム・パス上のディレクトリにNTLM認証DLLをコピーします。WL_HOMEは、WebLogic Serverのインストール先ディレクトリ。
<LoadLibraryPath
プロパティを設定して、NTLM認証DLLの場所を指定します。たとえば、Windowsシステム・パスにない「DataDirect」というディレクトリにドライバをインストールした場合、LoadLibraryPath
プロパティを使用してNTLM認証DLLを含むディレクトリを指定できます。
jdbc:weblogic:sqlserver://server3:1521; DatabaseName=test;LoadLibraryPath=C:\DataDirect\lib;User=test;Password=secret
Java 2プラットフォームのセキュリティ・マネージャでNTLM認証を使用する場合は、ドライバが接続を確立できるようにセキュリティ権限を付与する必要があります。例については、「接続を確立するための権限」を参照してください。
SQL Serverドライバでは、データ暗号化でSSLがサポートされます。SSLは情報の暗号化と認証を提供することにより、データの整合性を保証します。詳細は、「ネットワーク上でのデータの暗号化」を参照してください。
Microsoft SQL Serverの構成に応じて、ログイン・リクエストを含むすべてのデータを暗号化するか、ログイン・リクエストのみを暗号化するかを選択できます。データではなくログイン・リクエストを暗号化する方法は、以下のシナリオで有用です。
アプリケーションでセキュリティが必要だが、ドライバ/サーバー間で転送されるデータを暗号化する際のパフォーマンス低下に対応する余裕がない場合。
Microsoft SQL Server 2005のみ。サーバーでSSLが構成されていませんが、アプリケーションでは最低限のセキュリティが必要な場合。
注意: SSLが有効になっている場合、ドライバはサーバーのデフォルト・パケット・サイズで設定された データベース・プロトコル・パケットを使用して通信します。PacketSizeプロパティで設定された値は無視されます。 |
Microsoft SQL Serverデータベース・サーバーで信頼性のあるCAによって署名されたSSL証明書が構成されている場合、サーバーではSSL暗号化を省略可能または必須として構成できます。必須の場合、SSL暗号化をサポートしていないクライアントからの接続は失敗します。
最高水準のセキュリティには署名済みの信頼性のあるSSL証明書をお勧めしますが、Microsoft SQL Server 2005では、サーバーでSSL証明書が構成されていない場合でも、限定的なセキュリティ保護を提供できます。信頼性のある証明書がインストールされていない場合、サーバーは自己署名証明書を使用してデータではなくログイン・リクエストを暗号化します。
表6-5では、EncryptionMethod
プロパティの各値とMicrosoft SQL Server構成に応じた動作を示します。
表6-5 EncryptionMethodプロパティとMicrosoft SQL Server構成
値 | SSL証明書なし | SSL証明書(SSLは省略可能) | SSL証明書(SSLは必須) |
---|---|---|---|
noEncryption |
ログイン・リクエストとデータは暗号化されません。 |
ログイン・リクエストとデータは暗号化されません。 |
接続の試行は失敗します。 |
SSL |
接続の試行は失敗します。 |
ログイン・リクエストとデータは暗号化されます。 |
ログイン・リクエストとデータは暗号化されます。 |
requestSSL |
ログイン・リクエストとデータは暗号化されません。 |
ログイン・リクエストとデータは暗号化されます。 |
ログイン・リクエストとデータは暗号化されます。 |
loginSSL |
Microsoft SQL Server 2005 :ログイン・リクエストは暗号化されますが、データは暗号化されません。 Microsoft SQL Server 2000 :接続の試行は失敗します。 |
ログイン・リクエストは暗号化されますが、データは暗号化されません。 |
ログイン・リクエストとデータは暗号化されます。 |
アプリケーション用の暗号化のタイプを選択します。
ドライバでログイン・リクエストを含めてすべてのデータを暗号化するには、EncryptionMethod
プロパティをSSLまたはrequestSSLに設定します。
ドライバでログイン・リクエストのみを暗号化するには、EncryptionMethod
プロパティをloginSSLに設定します。
SSLサーバー認証に使用するトラスト・ストア・ファイルの場所とパスワードを指定します。TrustStoreおよびTrustStorePasswordプロパティ、またはそれぞれに対応するJavaシステム・プロパティ(javax.net.ssl.trustStoreおよびjavax.net.ssl.trustStorePassword)を設定します。
データベース・サーバーから送信された証明書を検証する場合は、ValidateServerCertificate
プロパティをtrueに設定します。
必要に応じて、証明書の検証に使用するホスト名をHostNameInCertificate
プロパティに設定します。HostNameInCertificate
プロパティは、ドライバが接続されているサーバーが実際にリクエストされたサーバーであることを保証することにより、介在者の攻撃(man-in-the-middle attack)を防ぐための追加のセキュリティを提供します。
SQL Serverドライバでは、Insert、Update、およびDelete文についてMicrosoft SQL Server 2005以上のOutput句をサポートします。たとえば、次の文で表を作成したと仮定します。
CREATE TABLE table1(id int, name varchar(30))
以下のUpdate文では、table1のid列の値を更新し、古いID (新しいIDで置換されます)、新しいID、これらのIDに関連付けられた名前を含む結果セットを返します。
UPDATE table1 SET id=id*10 OUTPUT deleted.id as oldId, inserted.id as newId, inserted.name
ドライバは別の結果セットでInsert、Update、またはDelete文の結果と更新回数を返します。出力結果セットが最初に返され、続いてInsert、Update、またはDelete文の結果が返されます。結果を返すDMLをアプリケーション内で実行するには、Statement.execute()またはPreparedStatement.execute()メソッドを使用します。その後にStatement.getMoreResults ()を使用して、出力結果セットと更新回数を取得します。例:
String sql = "UPDATE table1 SET id=id*10 OUTPUT deleted.id as oldId, inserted.id as newId, inserted.name"; boolean isResultSet = stmt.execute(sql); int updateCount = 0; while (true) { if (isResultSet) { resultSet = stmt.getResultSet(); while (resultSet.next()) { System.out.println("oldId: " + resultSet.getInt(1) + "newId: " + resultSet.getInt(2) + "name: " + resultSet.getString(3)); } resultSet.close(); } else { updateCount = stmt.getUpdateCount(); if (updateCount == -1) { break; } System.out.println("Update Count: " + updateCount); } isResultSet = stmt.getMoreResults(); }
SQL ServerドライバはMicrosoft SQL Server 2005以上の再認証をサポートします。スイッチを実行するユーザーには、データベース権限IMPERSONATE
が付与されている必要があります。注意: 再認証を実行する前に、アプリケーションは、他ユーザーへの接続に切替える前に1人のユーザーとして作成したすべての文または結果セットが閉じられていることを確認する必要があります。アプリケーションは、接続にユーザーを切替えるためにExtConnection
インタフェースにあるsetCurrentUser()
メソッドを使用できます。setCurrentUser()
メソッドは、ドライバ固有の再認証オプションを受け入れます。SQL Serverドライバでサポートされる再認証オプションは次のとおりです。
CURRENT_DATABASE
: 現在のデータベース名を指定します。値は有効なMicrosoft SQL Serverデータベース名である必要があります。setCurrentUser()
メソッドがコールされ、かつこのオプションを空の文字列として指定した場合、またはこのオプションを指定しない場合、ユーザーのみが切替えられ、データベースは切り替えられません。
REVERT_USER
: {true
またはfalse
}。すでに再認証されている接続のために新しいユーザーを現在のユーザーに設定する前に、ドライバが現在のユーザーを初期ユーザーに戻すかどうかを決定します。true
に設定し、かつsetCurrentUser()
メソッドが呼び出された場合、新しいユーザーに接続を設定する前に、ドライバは現在のユーザーを初期ユーザーに戻します。たとえば、最初にユーザーAにより作成され、後でユーザー Bに切り替えられた接続を考えてください。接続がさらにユーザーCに切り替えられる前に、ドライバは接続をユーザーAに戻してから、ユーザーCに設定します。false
に設定し、かつsetCurrentUser()
メソッドが呼び出された場合、切り替える前にドライバは現在のユーザーを初期ユーザーに戻しません。たとえば、接続がユーザーAにより最初に作成され、ユーザーBに切り替えられて、その後ユーザーCに切り替えられた場合、ドライバはユーザーCに切り替える前に現在のユーザーをユーザーAに戻しません。
SQL Serverドライバにより、アプリケーションは、特定の接続に関連付けられた次のタイプのクライアント情報を保存し、戻すことができます。
アプリケーション名
ユーザーID
クライアントのホスト名
会計IDなどの追加会計情報
SQL Serverドライバの製品名およびバージョン
この情報は、データベース監視および管理の目的のために使用できます。
SQL ServerドライバでサポートされるSQLエスケープ・シーケンスについては、付録C「JDBCのSQLエスケープ・シーケンス」を参照してください。
SQL ServerドライバはMicrosoft SQL Serverの以下の分離レベルをサポートします。
Read Committed with Locks (Microsoft SQL Server 2005のみでサポートされています)またはRead Committed
Read Committed with Snapshots (Microsoft SQL Server 2005のみでサポートされています)
Read Uncommitted
Repeatable Read
Serializable
Snapshot (Microsoft SQL Server 2005でのみサポート)
デフォルトはRead Committed with Locks (Microsoft SQL Server 2005)またはRead Committedです。
Snapshot分離レベルは以下のいずれかの方法で使用できます。
SnapshotSerializable
プロパティを設定すると、Serializable分離レベルの動作がSnapshot分離レベルを使用するように変更されます。こうすると、コードの変更を回避するか最小限に抑えながら、アプリケーションでSnapshot分離レベルを使用できるようになります。詳細は、表6-1にあるこのプロパティの説明を参照してください。
ExtConstantsクラスをインポートすると、同じアプリケーション内の個々の文に対してTRANSACTION_SNAPSHOTまたはTRANSACTION_SERIALIZABLE分離レベルを指定できます。com.ddtek.jdbc.extensionsパッケージのExtConstantsクラスではTRANSACTION_SNAPSHOT定数が定義されています。たとえば、以下のコードではExtConstantsクラスをインポートし、TRANSACTION_SNAPSHOT分離レベルを設定します。
import com.ddtek.jdbc.extensions.ExtConstants; Connection.setTransactionIsolation(ExtConstants.TRANSACTION_SNAPSHOT);
SQL Serverドライバは、スクロール・センシティブな結果セット、スクロール・インセンシティブな結果セット、および更新可能な結果セットをサポートしています。
注意: SQL Serverドライバが、リクエストされた結果セットのタイプまたは同時実行性をサポートできない場合は、カーソルを自動的にダウングレードして詳細情報の入ったSQLWarningを生成します。 |
SQL Serverドライバでは、クライアント側のカーソルまたはサーバー側のカーソルを使用して、更新可能な結果セットをサポートすることができます。デフォルトのSQL Serverドライバでは、どのタイプの結果セットでも動作するため、クライアント側のカーソルを使用します。通常、サーバー側のカーソルを使用するとパフォーマンスを向上させることができますが、サーバー側のカーソルは、スクロール・インセンシティブな結果セット、または主キーを含むデータベース表から生成されていないスクロール・センシティブな結果セットで使用することはできません。サーバー側のカーソルを使用するには、UseServerSideUpdatableCursors
プロパティをtrueに設定します。
UseServerSideUpdatableCursors
プロパティをtrueに設定している場合に、スクロール・インセンシティブで更新可能な結果セットがリクエストされると、ドライバはそのリクエストをスクロール・インセンシティブで読取り専用の結果セットにダウングレードします。同様に、スクロール・センシティブで更新可能な結果セットがリクエストされ、結果セットの生成元の表に主キーが含まれていない場合、ドライバはそのリクエストをスクロール・センシティブで読込み専用の結果セットにダウングレードします。いずれの場合も警告が生成されます。
サーバー側で更新可能なカーソルを、主キーを含むデータベースから生成されたセンシティブな結果セットで使用する場合、結果セットに対して行う以下のような変更は参照可能になります。
自身による挿入は参照可能です。他者による挿入は参照不可能です。
自身および他者による更新は参照可能です。
自身および他者による削除は参照可能です。
ドライバのデフォルトの動作を使用すると(UseServerSideUpdatableCursors=false
)、変更は参照可能になりません。
JTAでJDBC分散トランザクションを使用するには、システム管理者が次の手順に従って、Microsoft SQL Server JDBC XAプロシージャをインストールする必要があります。この手順は、分散トランザクションに関与するMS SQL Serverごとに繰り返す必要があります。
JTA用ストアド・プロシージャをインストールするには:
適切なsqljdbc.dll
およびinstjdbc.sql
ファイルをWL_HOME
\server\lib
ディレクトリからMS SQL Serverデータベース・サーバーのSQL_Server_Root
/bin
ディレクトリにコピーします。WL_HOMEはWebLogic Serverのインストール先ディレクトリ(通常はc:\Oracle\Middleware\wlserver_10.x
)です。
注意: 複数のMicrosoft SQL Serverインスタンスがあるデータベース・サーバーにストアド・プロシージャをインストールする場合、実行中の各SQLサーバー・インスタンスがsqljdbc.dll ファイルを見つけられる必要があります。そのため、sqljdbc.dll ファイルはグローバル・パスまたはアプリケーション固有のパス上に格納されている必要があります。アプリケーション固有のパスの場合は、各インスタンスの<drive>:\Program Files\Microsoft SQL Server\MSSQL$<Instance 1 Name>\Binn ディレクトリにsqljdbc.dll ファイルを配置します。 |
データベース・サーバーから、ISQLユーティリティを使用してinstjdbc.sql
スクリプトを実行します。万一に備えて、instjdbc.sql
を実行する前に、システム管理者にマスター・データベースのバックアップを依頼します。コマンド・プロンプトで、次の構文に従ってinstjdbc.sql
を実行します。
ISQL -Usa -Psa_password -Sserver_name -ilocation\instjdbc.sql
説明:
sa_passwordはシステム管理者のパスワード。
server_nameはSQL Serverが存在するサーバーの名前。
locationは、instjdbc.sql
のフルパスです。(このスクリプトは、ステップ1でSQL_Server_Root
/bin
ディレクトリにコピーしたものです。)
instjdbc.sql
スクリプトでは、多数のメッセージが生成されます。通常、これらのメッセージは無視できますが、システム管理者は実行エラーを示すメッセージがないかどうか確認する必要があります。最後のメッセージは、instjdbc.sql
が正常に実行されたことを示すメッセージになります。JDBC XAプロシージャを格納したり、既存のプロシージャの変更をログに記録したりするための容量がマスター・データベースで不足していると、スクリプトは失敗します。
トランザクションが完了する前にサーバーへの接続が失われると、分散トランザクションに関連付けられている接続が孤立する可能性があります。分散トランザクションに関連付けられた接続が孤立すると、そのトランザクションのデータベースによって保持されているロックが維持されるため、データが使用できなくなる可能性があります。分散トランザクションをクリーン・アップすると、それらのトランザクションに関連付けられている接続が解放され、データベースによって保持されているロックも解放されます。
XAResource.recoverメソッドを使用すると、準備済でコミットやロールバックはされていない分散トランザクションをクリーン・アップできます。このメソッドを呼び出すと、準備済でコミットやロールバックはされていないアクティブな分散トランザクションのリストが返されます。アプリケーションはXAResource.recoverから返されたリストを使用し、それらを明示的にコミットまたはロールバックすることでトランザクションをクリーン・アップできます。XAResource.recoverによって返されるトランザクションのリストには、アクティブなトランザクションや準備済でないトランザクションは含まれません。
また、SQL Serverドライバでは、分散トランザクションのクリーン・アップに関する以下の方法をサポートしています。
トランザクション・タイムアウト - アクティブなトランザクションの監査に使用されるタイムアウト値を設定します。指定されたタイムアウト値より有効期間が長いアクティブなトランザクションはロールバックされます。トランザクション・タイムアウトを設定すると、分散トランザクションをタイムアウト値に基づいて自動的にクリーン・アップできます。
明示的なトランザクションのクリーン・アップ - トランザクションのグループIDに基づいて、準備されていない状態のままのトランザクションを明示的にロールバックできます。明示的なトランザクションのクリーン・アップでは、トランザクション・タイムアウトの場合よりも分散トランザクションのクリーン・アップのタイミングを制御できます。
トランザクション・タイムアウトのタイムアウト値を設定するには、XAResource.setTransactionTimeoutメソッドを使用します。この値を設定すると、サーバー側のsqljdbc.dllではアクティブなトランザクションのリストを保持します。分散トランザクションは、開始されるときにアクティブなトランザクションのリストに配置され、該当するXAResourceメソッドを使用して準備、ロールバック、コミット、または無視されるときにこのリストから削除されます。
XAResource.setTransactionTimeoutメソッドを使用してトランザクション・クリーン・アップのタイムアウト値が設定されている場合、sqljdbc.dllはアクティブなトランザクションのリストを定期的に監査して、期限切れのトランザクションがないか調べます。タイムアウト値より有効期間が長いアクティブなトランザクションはロールバックされます。トランザクションのロールバック時に例外が生成された場合は、sqljdbc.dllファイルと同じディレクトリにあるsqljdbc.logファイルに例外が書き込まれます。
トランザクションのタイムアウト値を小さすぎる値に設定すると、正常に完了していない限りトランザクションがロールバックされてしまう危険性があります。一般的なガイドラインとしては、トラフィックの負荷が大きい状況でもトランザクションが十分完了できる時間にタイムアウト値を設定してください。
値を0 (デフォルト値)に設定すると、トランザクション・タイムアウトのクリーン・アップは無効になります。
SQL Serverドライバでは、XATransactionGroup
接続プロパティを使用して、IDをトランザクションのグループに関連付けることができます。トランザクションのグループIDを指定すると、その接続で開始されたすべての分散トランザクションはこのIDで識別されます。
この値を設定すると、サーバー側のsqljdbc.dllではアクティブなトランザクションのリストを保持します。分散トランザクションは、開始されるときにアクティブなトランザクションのリストに配置され、該当するXAResourceメソッドを使用して準備、ロールバック、コミット、または無視されるときにこのリストから削除されます。
XAResource.recoverメソッドを使用すると、XAResource.recoverを呼び出す際に使用された接続上に、トランザクションのグループIDが一致し、準備されていない状態のままのトランザクションがあれば、ロールバックすることができます。たとえば、XATransactionGroup=ACCT200
を指定し、同じ接続上でXAResource.recoverメソッドを呼び出した場合、トランザクション・グループIDがACCT200で、準備されていない状態のままのトランザクションはロールバックされます。
トランザクションのロールバック時に例外が生成された場合は、sqljdbc.dllファイルと同じディレクトリにあるsqljdbc.logファイルに例外が書き込まれます。
明示的なトランザクションのクリーン・アップを使用する場合、孤立した接続に関連付けられている分散トランザクションと、その接続で保持されているロックは、アプリケーションが明示的にクリーン・アップを呼び出すまで残されます。一般的なルールとして、アプリケーションは起動時と、サーバーへの接続が失われたことを通知された場合に、孤立した接続をクリーン・アップする必要があります。
Microsoft SQL ServerではBlobまたはClobデータ型は定義されていませんが、SQL Serverドライバによって、BlobおよびClob用に設計されたJDBCメソッドを使用して長いデータ(特にLONGVARBINARYデータおよびLONGVARCHARデータ)を返したり更新したりできます。これらのメソッドを使用して長いデータをBlobまたはClobとして更新すると、更新はBlobまたはClobオブジェクト内のデータのローカル・コピーに対して行われます。
BlobおよびClob用のJDBCメソッドを使用して長いデータを取得および更新すると、BlobおよびClobを操作した場合と同じメリットが得られます。たとえばBlobおよびClobを使用した場合、
データにランダム・アクセスできます。
特定の文字列から始まるデータを返すなど、データのパターン検索が可能になります。
BlobおよびClobを使用した場合のこうしたメリットを得るには、データをキャッシュする必要があります。データをキャッシュするので、特に一度にデータの逐次読出しを行う場合に、パフォーマンスが低下します。長いデータのサイズが使用可能なメモリーよりも大きいと、パフォーマンスが著しく低下することがあります。
バッチ挿入およびバッチ更新用のSQL Serverドライバ実装はJDBC 3.0に準拠しています。SQL Serverドライバは、バッチ挿入またはバッチ更新で文またはパラメータ・セットのエラーを検出すると、BatchUpdateExceptionを生成し、残りの文またはパラメータ・セットのバッチ処理を続行します。BatchUpdateException内の更新カウントの配列には、文またはパラメータごとに1つのエントリが含まれます。失敗した文またはパラメータ・セットのエントリには、Statement.EXECUTE_FAILED値が含まれます。
SQL Serverドライバでは、この項で説明するようにパラメータ・メタデータを返すことができます。
SQL Serverドライバは、以下の形式のInsert文およびUpdate文のパラメータ・メタデータを返すことができます。
INSERT INTO foo VALUES (?, ?, ?)
INSERT INTO foo (col1, col2, col3) VALUES (?, ?, ?)
UPDATE foo SET col1=?, col2=?, col3=?WHERE col1 operator?[{AND | OR} col2 operator ?]
ここで、operatorはSQL演算子(=、<、>、<=、>=、または<>)です。
SQL Serverドライバでは、ANSI SQL 92エントリ・レベルの述語(比較、BETWEEN、IN、LIKE、EXISTSなどの述語構文)にパラメータを含んでいるSelect文に対してパラメータ・メタデータを返すことができます。詳細な構文については、ANSI SQLリファレンスを参照してください。
以下のいずれかの条件に該当する場合は、Select文に対してパラメータ・メタデータを返すことができます。
文に、関連するFROM句内のソース表を対象とする、述語の値式が含まれている場合。例:
SELECT * FROM foo WHERE bar > ?
この場合、値式「bar」は表「foo」を対象として、パラメータの適切なメタデータを決定することができます。
文に、ネストされた問合せとなっている述語の値式が含まれている場合。ネストされた問合せのメタデータでは単一の列を記述する必要があります。例:
SELECT * FROM foo WHERE (SELECT x FROM y WHERE z = 1) < ?
以下のSelect文では、パラメータ・メタデータを返すことができる例をさらに示しています。
SELECT col1, col2 FROM foo WHERE col1 = ? and col2 > ? SELECT ... WHERE colname = (SELECT col2 FROM t2 WHERE col3 = ?) SELECT ... WHERE colname LIKE ? SELECT ... WHERE colname BETWEEN ? and ? SELECT ... WHERE colname IN (?, ?, ?) SELECT ... WHERE EXISTS(SELECT ... FROM T2 WHERE col1 < ?)
GROUP BY、HAVING、またはORDER BYを含むWHERE句でANSI SQL 92エントリ・レベルの述語を使用する文がサポートされます。例:
SELECT * FROM t1 WHERE col = ? ORDER BY 1
結合がサポートされます。例:
SELECT * FROM t1,t2 WHERE t1.col1 = ?
完全修飾名と別名がサポートされます。例:
SELECT a, b, c, d FROM T1 AS A, T2 AS B WHERE A.a = ? and B.b = ?"
アプリケーションで表名情報が必要な場合、SQL ServerドライバはSelect文のResultSetメタデータに含めて表名情報を返すことができます。ResultSetMetaDataOptions
プロパティを1に設定した場合、ResultSetMetaData.getTableName()
メソッドが呼び出されたとき、SQL Serverドライバは結果セット内の各列の正しい表名を決定する追加の処理を実行します。それ以外の場合、getTableName()
メソッドは結果セット内の列ごとに空の文字列を返す可能性があります。
ResultSetMetaDataOptions
プロパティが1に設定されていて、ResultSetMetaData.getTableName()
メソッドが呼び出された場合、SQL Serverドライバが戻す表名情報は、結果セット内の列がデータベース表内の列にマップされているかどうかによって異なります。結果セット内の各列がデータベース表内の列にマップされている場合、SQL Serverドライバはその列に関連付けられている表名を戻します。結果セット内の各列が表内の列にマップされていない場合(集約やリテラルなど)、SQL Serverドライバは空の文字列を戻します。
ResultSetメタデータが返されるSelect文には、別名、結合、および完全修飾名を含めることができます。以下の問合せは、ResultSetMetaData.getTableName()
メソッドによってSelectリスト内の各列の正しい表名が返される、Select文の例です。
SELECT id, name FROM Employee SELECT E.id, E.name FROM Employee E SELECT E.id, E.name AS EmployeeName FROM Employee E SELECT E.id, E.name, I.location, I.phone FROM Employee E, EmployeeInfo I WHERE E.id = I.id SELECT id, name, location, phone FROM Employee, EmployeeInfo WHERE id = empId SELECT Employee.id, Employee.name, EmployeeInfo.location, EmployeeInfo.phone FROM Employee, EmployeeInfo WHERE Employee.id = EmployeeInfo.id
生成された列の場合、ドライバによって返される表名は空の文字列です。以下の問合せは、生成された列(「upper」という名前の列)を含む結果セットを返すSelect文の例です。
SELECT E.id, E.name as EmployeeName, {fn UCASE(E.name)} AS upper FROM Employee E
SQL Serverドライバは、ResultSetMetaData.getSchemaName()
メソッドとResultSetMetaData.getCatalogName()
メソッドが呼び出された場合、スキーマ名とカタログ名の情報を返すこともできます(ドライバがこの情報を判別できる場合)。たとえば、以下の文の場合、SQL Serverドライバはカタログ名として「test」、スキーマ名として「test1」、表名として「foo」を返します。
SELECT * FROM test.test1.foo
表名、スキーマ名、およびカタログ名の情報を返すために必要な追加の処理は、ResultSetMetaData.getTableName()
、ResultSetMetaData.getSchemaName()
、またはResultSetMetaData.getCatalogName()
メソッドが呼び出された場合にのみ実行されます。
SQL Serverドライバは、以下のようなRowSetインタフェースのJSR 114実装をサポートします。
CachedRowSet
FilteredRowSet
WebRowSet
JoinRowSet
JDBCRowSet
ドライバでRowSetを使用するには、J2SE 1.4以上が必要です。
JSR 114の詳細は、http://www.jcp.org/en/jsr/detail?id=114
を参照してください。
SQL Serverドライバは自動生成キーの値の取得をサポートします。SQL Serverドライバから返される自動生成キーは、identity列の値です。
自動生成キーの値を返すことができるのは、アプリケーションでInsert文を実行するときです。値を返す方法は、パラメータを含むInsert文を使用しているかどうかによって異なります。
パラメータを含まないInsert文を使用する場合、MS SQL Serverドライバでは、ドライバに自動生成キーの値を返すよう指示するため、次の形式のStatement.execute()
およびStatement.executeUpdate()
メソッドがサポートされます。
Statement.execute(String sql, int
autoGeneratedKeys
)
Statement.execute(String sql, int[]
columnIndexes
)
Statement.execute(String sql, String[]
columnNames
)
Statement.executeUpdate(String sql, int
autoGeneratedKeys
)
Statement.executeUpdate(String sql, int[]
columnIndexes
)
Statement.executeUpdate(String sql, String[]
columnNames
)
パラメータを含むInsert文を使用する場合、MS SQL Serverドライバでは、ドライバに自動生成キーの値を返すよう通知するため、次の形式のConnection.prepareStatement()
メソッドがサポートされます。
Connection.prepareStatement(String sql, int
autoGeneratedKeys
)
Connection.prepareStatement(String sql, int[]
columnIndexes
)
Connection.prepareStatement(String sql, String[]
columnNames
)
自動生成キーの値は、Statement.getGeneratedKeys()
メソッドを使用して取得できます。このメソッドは、各自動生成キーの列とともにResultSetオブジェクトを返します。
Microsoft SQL Serverドライバは接続を確立するときに、Microsoft SQL Serverのデータベース・オプションansi_nullsをonに設定します。これでドライバがANSI SQL標準に準拠するようになり、データベース間を横断するアプリケーションの開発が容易になります。
デフォルトでは、Microsoft SQL ServerはSQLの等価比較(=)または不等価比較(<>)や集約関数におけるnull値の評価を、ANSI SQL準拠の方法では行いません。たとえば、ANSI SQL仕様では、次のSelect文のようにcol1=null
を常にfalseと評価するように定義されています。
SELECT * FROM table WHERE col1 = NULL
デフォルトのデータベース設定(ansi_nulls=off)を使用した同じ比較では、falseではなくtrueと評価されます。
ansi_nullsをonに設定すると、データベースによるnull値の処理方法が変わり、=NULL
ではなくIS NULL
の使用が強制されます。たとえば、以下のSelect文のcol1の値がnullである場合、比較の評価はtrueになります。
SELECT * FROM table WHERE col1 IS NULL
アプリケーションでは以下の方法で、接続に関するMicrosoft SQL Serverのデフォルトの動作に戻すことができます。
InitializationString
プロパティを使用してSQLコマンドset ANSI_NULLS off
を指定します。たとえば、以下のURLでは、現在の接続に関して、null値の処理がMicrosoft SQL Serverのデフォルトに戻されます。
jdbc:weblogic:sqlserver://server1:1433; InitializationString=set ANSI_NULLS off; DatabaseName=test
接続が確立された後で以下の文を明示的に実行します。
SET ANSI_NULLS OFF
次の手順に従って、フェイルオーバーを構成します。
プライマリ・サーバーと代替サーバーを指定します。
接続URLまたはデータ・ソースを使用してプライマリ・サーバーを指定します。
AlternateServersプロパティを設定して、1つまたは複数の代替サーバーを指定します。
注意: ドライバのかわりにフェイルオーバーの代替サーバーを決定するMicrosoft Cluster Server (MSCS)によるフェイルオーバーを使用する場合、指定した代替サーバーがプライマリ・サーバーと同じである必要があります。たとえば次のように構成します。
jdbc:datadirect:sqlserver://server1:1433; DatabaseName=TEST;User=test;Password=secret; AlternateServers=(server1:1433;DatabaseName=TEST)
FailoverMode
接続プロパティを設定して、フェイルオーバー・メソッドを選択します。デフォルト・メソッドは、接続フェイルオーバー(FailoverMode=connect
)です。
FailoverMode=extended
またはFailoverMode=select
の場合、FailoverGranularity
プロパティを設定して、失われた接続の再確立を試行しているときに例外が発生した場合のドライバの動作を指定します。ドライバのデフォルトの動作では、フェイルオーバー処理が続行され、例外が発生した文にその例外がポストされます(FailoverGranularity=nonAtomic
)。
オプションで、接続再試行の機能を構成します。
オプションで、ドライバによって、一度にプライマリ・サーバーおよび代替サーバーへの接続を確立する場合、FailoverPreconnect
プロパティを設定します。デフォルトの動作では、失敗した接続試行または失われた接続で発生したフェイルオーバーの場合、代替サーバーのみへ接続されます。(FailoverPreconnect=false
)。
次のいずれかのメソッドを実行して、プライマリ・サーバーと代替サーバーの接続情報を指定できます。
JDBCドライバ・マネージャを介した接続URL
JDBCデータ・ソース
たとえば、次に示すSQL Serverドライバの接続URLでは、接続URLを使用することでプライマリ・サーバーと代替サーバーの接続情報を指定しています。
jdbc:weblogic:sqlserver://server1:1433;DatabaseName=TEST;User=test; Password=secret;AlternateServers=(server2:1433;DatabaseName=TEST2, server3:1433;DatabaseName=TEST3)
この例では:
...server1:1433;DatabaseName=TEST...
これは、プライマリ・サーバー用の接続情報を指定する接続URLの一部です。代替サーバーがAlternateServers
プロパティで指定されます。例:
...;AlternateServers=(server2:1433;DatabaseName=TEST2, server3:1433;DatabaseName=TEST3
)
同様に、JDBCデータ・ソースを使用したプライマリ・サーバーと代替サーバーの同一の接続情報は、次のようになります。
SQLServerDataSource mds = new SQLServerDataSource();
mds.setDescription("My SQLServerDataSource");
mds.setServerName("server1");
mds.setPortNumber(1433);
mds.setDatabaseName("TEST");
mds.setUser("test");
mds.setPassword("secret");
mds.setAlternateServers(server2:1433;DatabaseName=TEST2,
server3:1433;DatabaseName=TEST3)
この例では、ServerName
、PortNumber
、およびDatabaseName
プロパティを使用して、プライマリ・サーバーの接続情報を指定します。AlternateServers
プロパティを使用して代替サーバーの接続情報を指定します。
SQL Serverドライバにより、同じサーバーで同時に実行されているMicrosoft SQL Serverデータベースの名前付きの複数のインスタンスへの接続も指定できます。名前付きインスタンスをプライマリ・サーバーと代替サーバーに指定する場合、接続URLは次のようになります。
jdbc:weblogic:sqlserver://server1\\instance1;User=test;Password=secret; AlternateServers=(server2\\instance2:1433;DatabaseName=TEST2, server3\\instance3:1433;DatabaseName=TEST3)
同様に、JDBCデータ・ソースを使用したプライマリ・サーバーと代替サーバーへの名前付きインスタンスの同一の接続情報は、次のようになります。
SQLServerDataSource mds = new SQLServerDataSource();
mds.setDescription("My SQLServerDataSource");
mds.setServerName("server1\\instance1");
mds.setPortNumber(1433);
mds.setDatabaseName("TEST");
mds.setUser("test");
mds.setPassword("secret");
mds.setAlternateServers(server2\\instance2:1433;
DatabaseName=TEST2,server3\\instance3:1433;
DatabaseName=TEST3)
データ・ソースを使用して名前付きインスタンスに接続するには、ServerName
プロパティを使用してプライマリ・サーバーに名前付きインスタンスを指定します。
AlternateServersプロパティの値は、次のような形式の文字列です。
(servername1[:port1][;property=value][,servername2[:port2] [;property=value]]...)
または、名前付きインスタンスに接続する場合は次のようになります。
(servername1\\instance1[;property=value][,servername2\\instance2 [;property=value
説明:
servername1
は、1番目の代替データベース・サーバーのIPアドレスまたはサーバー名、servername2は、2番目の代替データベース・サーバーのIPアドレスまたはサーバー名などというようになります。各代替サーバー・エントリにPアドレスまたはサーバー名が必要です。
instance1
は、1番目の代替データベース・サーバーの名前付きインスタンスです。servername2は、2番目の代替データベース・サーバーの名前付きインスタンスです。3番目以降も同様です。名前付きインスタンスに接続する場合、名前付きインスタンスが各代替サーバー・エントリで必要になります。
port1は、1番目の代替データベース・サーバーがリスニングするポート番号です。port2は、2番目の代替データベース・サーバーがリスニングするポート番号です。3番目以降も同様です。ポート番号は、各代替サーバー・エントリのオプションです。指定しない場合、プライマリ・サーバーに指定されているポート番号が使用されます。プライマリ・サーバーのポート番号が指定されていない場合は、デフォルトのポート番号1433が使用されます。
property=value
は、DatabaseName
接続プロパティです。このプロパティは、各サーバー・エントリのオプションです。たとえば次のようになります。
Password=secret;AlternateServers=(server2:1433;DatabaseName=TEST2, server3:1433;DatabaseName=TEST3)
または、名前付きインスタンスに接続する場合は次のようになります。
jdbc:weblogic:sqlserver://server1\\instance1:1433;DatabaseName=TEST; User=test;Password=secret;AlternateServers=(server2\\instance2:1433; DatabaseName=TEST2,server3\\instance3:1433;DatabaseName=TEST3)
代替サーバー・エントリにDatabaseName
接続プロパティを指定しない場合、その代替サーバーへの接続にはプライマリ・サーバーのURLに指定されているプロパティが使用されます。たとえば、次のURLのようにプライマリ・サーバーにDatabaseName=TEST
を指定し、代替サーバー・エントリでデータベース名を指定しない場合、ドライバは代替サーバーのTEST
データベースに接続しようとします。
jdbc:datadirect:sqlserver://server1:1433;DatabaseName=TEST;User=test; Password=secret;AlternateServers=(server2:1433,server3:1433)
接続の再試行によって、SQL Serverドライバはプライマリ・データベース・サーバーへの接続を再試行できます。また、指定している場合は、接続が確立されるまで代替サーバーへの接続を再試行します。ConnectionRetryCount
およびConnectionRetryDelay
プロパティを使用して、接続の再試行を有効にし、制御できます。たとえば、次のように設定します。
jdbc:datadirect:sqlserver://server1:1433;DatabaseName=TEST;
User=test;
Password=secret;
AlternateServers=(server2:1433;
DatabaseName=TEST2, server3:1433;DatabaseName=TEST3);
ConnectionRetryCount=2; ConnectionRetryDelay=5
この例では、データベース・サーバー(プライマリ・サーバーと代替サーバー)のリストを介してSQL Serverドライバの最初のパスで接続がまだ確立されていない場合、ドライバによってサーバーのリストが同じ順番で2回再試行されします(ConnectionRetryCount=2
)。接続の再試行の遅延が5秒に設定されているため(ConnectionRetryDelay=5
)、ドライバは、再試行パスの間に5秒まで待機します。
次の項には、SQL Serverドライバでのフェイルオーバーの機能を制御する接続プロパティが要約されています。
AlternateServers
: 1つまたは複数のデータベース・サーバー。各サーバーが必要と識別するIPアドレスまたはサーバー名。ポート番号と接続プロパティDatabaseName
はオプションです。ポート番号が指定されていない場合、プライマリ・サーバーに指定されているポート番号が使用されます。デフォルトのポート番号は1433です。
ConnectionRetryCount
: ドライバがプライマリ・データベース・サーバーを再試行する回数。指定した場合、接続に成功するまで代替サーバーを再試行する回数。デフォルトは5です。
ConnectionRetryDelay
: ConnectionRetryCount
プロパティを正の整数で指定した場合、接続の再試行の間の秒単位での待機間隔。デフォルトは1です。
DatabaseName
: 接続するデータベースの名前。
FailoverGranularity
: ドライバが全体のフェイルオーバー・プロセスに失敗するか、切断された接続の再確立を試行するときに例外が発生してもプロセスを続行するかを決定します。デフォルトはnonAtomic
です(ドライバは、フェイルオーバー・プロセスを続行し、文で発生するすべての例外をポストします)。
FailoverMode
: ドライバが使用するフェイルオーバー・メソッド。デフォルトはconnect
(接続のフェイルオーバーが使用されます)。
FailoverPreconnect
: ドライバがプライマリ・サーバーと代替サーバーに同時に接続するかどうかを指定します。デフォルトは、false
です(接続試行の失敗または接続の切断によってフェイルオーバーが発生した場合のみ、ドライバは代替サーバーに接続します)。
LoadBalancing
: データベース・サーバー(プライマリ・サーバーと代替サーバー)を接続するときにドライバがクライアント・ロード・バランシングを使用するかどうかを決定します。クライアント・ロード・バランシングを有効にすると、ドライブは、接続するときに連続パターンのかわりにランダム・パタンを使用します。デフォルトはfalse
です(クライアント・ロード・バランシングは無効になります)。
PortNumber: プライマリ・データベース・サーバーの接続用のポート・リスニング。このプロパティは、データ・ソースの接続でのみサポートされています。デフォルト・ポート番号は、1433です。
ServerName
: プライマリ・データベース・サーバーのIPアドレスまたはサーバー名。このプロパティは、データ・ソースの接続のみでサポートされます。
ドライバでは、バルク・ロード
の機能がサポートされます。この機能を使用すると、アプリケーションでは大量のデータ行を、多数の小さいデータベース・プロトコル・パケットではなく連続ストリームとしてデータベースに送信できます。バッチ操作と同様に、ネットワーク上のラウンド・トリップが少なくなるので、パフォーマンスが向上します。バルク・ロードによって、通常データベースで行われるデータの解析が省略されるので、バッチ操作よりもさらにパフォーマンスが向上します。