|
|
以下の節では、BEA WebLogic Type 4 JDBC SQL Server ドライバのコンフィグレーション方法と使用方法について説明します。
| 注意 : | BEA WebLogic Type 4 JDBC MS SQL Server ドライバ (この章の主題) は、非推奨となった WebLogic jDriver for Microsoft SQL Server に置き換わるものです。新しいドライバは JDBC 3.0 に準拠しており、JDBC 2.0 拡張機能の一部をサポートし、パフォーマンスが向上しています。WebLogic jDriver for Microsoft SQL Server の代わりに、新しい BEA WebLogic Type 4 JDBC MS SQL Server ドライバを使用してください。 |
BEA WebLogic Type 4 JDBC MS SQL Server ドライバ (「SQL Server ドライバ」) は、以下のバージョンのデータベース管理システムをサポートします。
JTA を介して JDBC 分散トランザクションを使用するには、SQL Server のストアド プロシージャをインストールする必要があります。詳細については、「JTA 用ストアド プロシージャのインストール」を参照してください。
BEA WebLogic Type 4 JDBC MS SQL Server のドライバ クラスは次のとおりです。
XA : weblogic.jdbcx.sqlserver.SQLServerDataSource 非 XA : weblogic.jdbc.sqlserver.SQLServerDriver
Microsoft SQL Server データベースに接続するには、次の形式の URL を使用します。
jdbc:bea:sqlserver://dbserver:port
Microsoft SQL Server では、SQL Server データベースの複数のインスタンスを同じサーバで同時に実行することができます。各インスタンスはインスタンス名で識別されます。
接続 URL を使用して名前付きのインスタンスに接続するには、次の形式で URL を指定します。
jdbc:bea:sqlserver://server_name\\instance_name
| 注意 : | \\instance_name の最初のバックスラッシュ (\) はエスケープ文字です。 |
server_name は、サーバの IP アドレスまたはホスト名です。
instance_name は、サーバ上の接続先インスタンスの名前です。
たとえば次の接続 URL を指定すると、server1 上の instance1 に接続されます。
jdbc:bea:sqlserver://server1\\instance1;User=test;Pasword=secret
表 5-1 に、SQL Server ドライバでサポートされる JDBC 接続プロパティを示し、各プロパティについて説明します。WebLogic Server ドメインの JDBC データ ソースのコンフィグレーションでこれらの接続プロパティを使用できます。プロパティを指定するには、JDBC データ ソースのコンフィグレーションで次の形式を使用します。
property=value
| 注意 : | すべての接続文字列プロパティ名で、大文字と小文字は区別されません。たとえば、Password は password と同じです。 |
|
|
|
|
|
|
|
|
以下に示すように SQL Server ドライバの接続プロパティを設定すると、アプリケーションのパフォーマンスを向上させることができます。
スクロールインセンシティブな結果セットを使用する場合のパフォーマンスを向上させるため、ドライバは結果セット データをディスクに書き込む代わりに、メモリにキャッシュできます。デフォルトでは、ドライバはインセンシティブな結果セット データを 2 MB までメモリにキャッシュし、残りの結果セット データをディスクに書き込みます。パフォーマンスを向上させるには、ドライバがデータをディスクに書き込む前に使用するメモリの量を増やすか、ドライバがインセンシティブな結果セット データをディスクに書き込めないようにします。最大キャッシュ サイズの設定は 2 GB です。
ドライバがアプリケーション サーバの内部で実行されない場合、または独自のプリペアド ステートメント プールを提供しない別のアプリケーションの内部で実行されるのでない場合は、パフォーマンスを向上させるため、ドライバ独自の内部的なプリペアド ステートメント プールを有効にする必要があります。ドライバの内部的なプリペアド ステートメント プールを有効にすると、ドライバはアプリケーションによって作成された一定数のプリペアド ステートメントをキャッシュします。たとえば、MaxPooledStatements が 20 に設定されている場合、ドライバはアプリケーションによって作成された最近の 20 個のプリペアド ステートメントをキャッシュします。このプロパティの値に設定された値が、アプリケーションが使用するプリペアド ステートメントの数より大きい場合は、すべてのプリペアド ステートメントがキャッシュされます。
デフォルトでは、ResultSetMetaData.getTableName() メソッドが呼び出された場合、SQL Server ドライバは、結果セット内の各カラムの正しいテーブル名を返すために必要な追加の処理を省略します。このため、getTableName() メソッドは結果セット内のカラムごとに空の文字列を返す可能性があります。アプリケーションでテーブル名情報が必要ない場合は、この設定によって最適なパフォーマンスが得られます。
ResultSet メタデータを返す方法の詳細については、「ResultSet メタデータのサポート」を参照してください。
ほとんどの場合、サーバサイドのデータベース カーソルを使用するとパフォーマンスに悪影響を与えます。ただし、アプリケーションが次のような条件に該当する場合は、このプロパティの最適な設定は cursor です。この設定は、サーバサイドのデータベース カーソルを使用することを表します。
アプリケーションによってアクセスされるすべてのデータが、デフォルトのデータベースの文字エンコーディングを使用してデータベースに格納される場合、SendStringParametersAsUnicode の設定を false にするとパフォーマンスを向上させることができます。
ほとんどの場合、サーバサイドで更新可能なカーソルを使用するとパフォーマンスが向上します。ただし、このタイプのカーソルは、インセンシティブな結果セット、または主キーを含むデータベース テーブルから生成されていないセンシティブな結果セットで使用することはできません。
サーバサイドで更新可能なカーソルの使用方法については、「サーバサイドで更新可能なカーソル」を参照してください。
表 5-2 に、SQL Server ドライバでサポートされる SQL Server 7 および SQL Server 2000 のデータ型と、対応する JDBC データ型を示します。
表 5-3 に、SQL Server 2000 のみでサポートされているその他のデータ型を示します。
データ型の詳細については、「getTypeInfo」を参照してください。
SQL Server ドライバでサポートされている SQL エスケープ シーケンスについては、「JDBC の SQL エスケープ シーケンス」を参照してください。
SQL Server ドライバは、トランザクション アイソレーション レベルとして Read Committed、Read Uncommitted、Repeatable Read、および Serializable をサポートしています。デフォルトは Read Committed です。
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 ごとに繰り返す必要があります。
WL_HOME\server\lib ディレクトリにある sqljdbc.dll および instjdbc.sql ファイルを、MS SQL Server データベース サーバの SQL_Server_Root/bin ディレクトリにコピーします。WL_HOME は WebLogic Server がインストールされているディレクトリで、通常は c:\bea\wlserver_10.0 です。| 注意 : | 複数の Microsoft SQL Server インスタンスがあるデータベース サーバにストアド プロシージャをインストールする場合、実行中の各 SQL サーバ インスタンスが sqljdbc.dll ファイルを見つけられる必要があります。そのため、sqljdbc.dll ファイルはグローバル パスまたはアプリケーション固有のパス上に格納されている必要があります。アプリケーション固有のパスの場合は、各インスタンスの <drive>:\Program Files\Microsoft SQL Server\MSSQL$<Instance 1 Name>\Binn ディレクトリに sqljdbc.dll ファイルを配置します。 |
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 プロシージャを格納したり、既存のプロシージャの変更をログに記録したりするための容量がマスター データベースで不足していると、スクリプトは失敗します。
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 文のパラメータ メタデータを返すことができます。
ここで、operator は SQL 演算子 (=、<、>、<=、>=、または <>) です。
SQL Server ドライバでは、ANSI SQL 92 エントリレベルの述語 (比較、BETWEEN、IN、LIKE、EXISTS などの述語構文) にパラメータを含んでいる Select 文に対してパラメータ メタデータを返すことができます。詳細な構文については、ANSI SQL リファレンスを参照してください。
以下のいずれかの条件に該当する場合は、Select 文に対してパラメータ メタデータを返すことができます。
以下の 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 実装をサポートします。
JSR 114 の詳細については、 http://www.jcp.org/en/jsr/detail?id=114 を参照してください。
SQL Server ドライバは自動生成キーの値の取得をサポートします。SQL Server ドライバから返される自動生成キーは、identity カラムの値です。
値を返す方法は、パラメータを含む Insert 文を使用しているかどうかによって異なります。
アプリケーションでは Statement.getGeneratedKeys メソッドを使用して、生成されたキーの値をドライバから取得します。
  
|
