Microsoft PowerPoint - Oracle Database 11g Release 2 Application Development（Java）.ppt [互換モード]

Transcription

1 1

2 2

3 3

4 このチャートではOracle JDBC Driver 11g R2における主な新機能をご紹介します 以降のページでそれぞれについて説明をしていくことにします 他にも11g R2でのエンハンスメントや変更点はありますが 詳しくはJDBCの開発者ガイドをご参照ください 4

5 11g R2 から以下の String 型定数が追加されました static final java.lang.string CONNECTION_PROPERTY_EDITION_NAME これを接続取得要求時にユーザー情報やパスワードなど共にプロパティにセットすることで異なるエディションのアプリケーションに対して選択的に接続が可能になります なお 上記定数は以下のSQL 文を発行した結果と同じ値をとります SELECT sys _ context('userenv', 'CURRENT_ EDITION_ NAME') FROM dual 5

6 11g R1より前のリリースでのJDBCドライバーでは一回のデータベースラウンドトリップで LOBデータを取得するためにはVARCHAR2タイプのデータとしてフェッチをする必要がありました これは もしCHARタイプとしてフェッチを行うと データとlocatorを同時に取得することができなかったことに起因するものです 11g R2リリースのJDBCドライバーでは最初のラウンドトリップでLOBデータの開始部分と共にチャンクサイズ等のLOBのメタデータとlocatorをプリフェッチします これによってLOB 操作によって発生するラウンドトリップを減少させることを実現しました ラウンドトリップの減少によるパフォーマンス向上の効果は LOB データのサイズが小さいほど有効で 一回のラウンドトリップですべてのデータをプリフェッチすることも可能になっています ただし データサイズが大きくなるにつれてこの効果は相対的に減衰していきます 6

7 Zero-copy I/Oを使用するとOracle SecureFile 型のLOBの転送効率が向上します これは11g R2において アプリケーションがOracle Net Servicesのネットワーク セッション層における新しいパケットプロトコルをサポートしている場合 Oracle Netの層にてデータを送受信する際に自身のバッファにいったん格納していた作業が省略可能となり ネットワークに対して直接読み書きを行なうようになったためです このI/O 方式をZero-copy I/Oと呼んでいます Oracle JDBC ドライバはこの新しいプロトコルに対応しているため 11gR2 ではデフォルトでSecureFile 型のLOBに対するデータの操作にZero-copy I/Oが適用されています また お使いのBLOBもしくはCLOBのデータがOracle SecureFile ストレージを使用しているかどうかを確認するためにoracle.sql.BLOB および oracle.sql.clob クラスに以下のメソッドが追加されました trueが返された場合 そのデータはSecureFile であることを示します 7

8 これまでご紹介したLOBアクセスについての機能はそれぞれ異なるアプローチで性能向上を図っており 効果が期待できるケースが異なります LOBデータのプリフェッチ最適化はデータベースへの最初のラウンドトリップに対する最適化を行なっています そのため一連のアクセスで発生するラウンドトリップ数が比較的小さい つまりアクセスサイズが小さいようなケースで効果を発揮し トータルのラウンドトリップ数が大きくなるに連れて相対的に効果は低減します SecureFile に対する Zero-copy I/O の適用は各ラウンドトリップにおけるデータ転送の効率化を図ったものですので サイズの大小に関わらずパフォーマンスの向上が期待できます 8

9 サーバサイドでキャッシュを有効にすると そのクエリを利用するすべてのクライアントに対して有効となりますが キャッシュがサーバのSGA( 共有プール ) に格納されるためにキャッシュのアクセスで1 回のデータベースへのラウンドトリップが発生します それに対してクライアントサイドにて結果キャッシュを使用すると ドライバのキャッシュから結果セットが返されるためにネットワーク アクセスはありませんが そのクライアントでのみ有効となります 結果キャッシュはサーバ初期化パラメータ RESULT_CACHE_MODE を使って 可能なかぎりすべてのクエリで有効とする 注釈を付けたクエリのみで有効てのクリのみで有効とするかを制御することができます 9

10 TIMESTAMP WITH TIME ZONE とTIMESTAMP WITH LOCAL TIME ZONE はJava 標準のjava.sql.Timestamp 型で表現することが可能です これはTIMESTAMP WITH TIME ZONE とTIMESTAMP WITH LOCAL TIME ZONEの内部的なフォーマットがGMTであり java.sql.timestampは EPOCHからの時間経過をミリ秒で表したものであるためです 文字列 (String 型 ) で表現する場合はTimezone 情報が必要となりますが JDBC ドライバは TIMEZONE 情報をデータベースサーバから取得してキャッシュしたものを使用しています 以前にリリースされたJDBCドライバでは最初に取得したTimezoneキャッシュを複数の異なる接続オブジェクト間で共有を行っていました このため 接続先のデータベースによってはJDBCドライバがキャッシュしたクライアント側の Timezone 情報と接続先データベースのもつTimezoneファイル情報が非互換となってしまうケースが考えられました 11g R2リリースではこの問題を改善し 接続先データベースのTimezoneファイルのバージョンに基づきTimezone 情報をキャッシュするように変更されました これにより異なるバージョンのTimezone 情報の非互換性に起因する問題が解決されました 10

11 Oracle RAC Fast Application Notification はコールバック メカニズムを介して RACのFANイベントにアクセスするためのJavaのAPIを提供します このAPIを使用することにより Universal Connection Pool や暗黙的接続キャッシュを使用しない環境においてもRACからのFANイベント通知を受信することが可能になります このAPIライブラリはOracle JDBCのAPIではなく simplefan.jarという独立したアーカイブ ファイルとして提供されています そのため 利用する際には事前にダウンロードを行い jarファイルの配置先をアプリケーションを実行する Java 仮想マシンのCLASSPATH に通しておく必要があります この機能を使用する上でOracle Notification System(ONS) のメッセージ伝達機能を使用します そのためFANイベントを受信するアプリケーション側でONS を事前に構成しておく必要があります 11

12 Simple FANでサポートしているイベントは以下の4つで それぞれに対応する Eventクラスが提供されており それぞれのイベント通知を受信した際のアクションは個別に記述を行います Service up / Service down / Node down / Load balancing advisory チャートにはSimple FANを使ったFANイベント受信のためのリスナーの構成の一例を掲載しています ここではService downイベントを受信した際にイベント情報を標準出力に出力しています 12

13 11g R2 リリースから Oracle JDBC のパッケージ内に入っていた暗黙的接続キャッシュ (ICC) の使用が非推奨になりました 非推奨になっただけですので現時点では ICC を使用した開発もサポートされますが 今後は Universal Connection Pool (UCP) for JDBC の使用が推奨となります UCP についての詳細は後述します 13

14 Universal Connection Pool for JDBCはJDBC 接続オブジェクトをキャッシュして複数のJDBCアプリケーションで共用するための接続プール機能を提供しまプす 暗黙的接続キャッシュとは異なり Oracle JDBCパッケージ (ojdbc*.jar) の中には含まれておらず 接続プール機能のみが独立したjarファイルとして提供されています これにより接続プールを使用したいアプリケーションに容易に組み込むことが可能になるほか JDBC 接続オブジェクトを生成するJDBC 接続ファクトリと組み合わせることで Oracle 様々なベンダーのデータベースに対する接続プールとしても使用することも可能になっています 14

15 UCPの主要な構成要素はプール対応データソース UCP 接続プール および接続プールマネージャーです JDBCアプリケーションは接続を取得する際にプール対応のデータソースを使用します プール対応のデータソースにはXA 対応のデータソース (oracle.ucp.jdbc.xapooldatasource) とXA 非対応のデータソース (oracle.ucp.jdbc.pooldatasource) の二種類があります プール対応データソースにはひとつのUCP JDBC 接続プールが関連付けれれています 接続プールマネージャーは接続プールを細かく管理するためのツールで 要件によっては明示的に操作をする必要がない場合もあります プール対応データソースに対してアプリケーションから接続取得要求 (getconnection()) が呼び出されると プール対応データソースはUCP 接続プールからクライアントに適した接続を返します UCP 接続プールが管理する接続オブジェクトはデータベースへの物理接続を実際に確立するJDBCドライバ等の接続ファクトリ クラスを利用して生成します このファクトリ クラスもひとつのプール対応データソースにひとつ必要ですが UCP のパッケージには入っておりませんので接続先のデータベースに合わせて適当な接続ファクトリ (JDBCドライバー) を別途用意する必要があります 15

16 ここから UCP の利用シナリオを二つご紹介します 最初はスタンド アロンのJDBCアプリケーションから使用するケースです 想定される形態としてはシングルのJavaクライアントに組み込むケース および JDBCドライバとともに組み込みデータソースとしてアプリケーションにパッケージして使用するケースが考えられます このケースではアプリケーションのコードの中でアプリケーションの中ですべての動作を記述する必要があるため 接続を取得するにはまず接続先のデータベースの種類 数に合わせてデータソースを初期化する必要があります また また必要に応じて細かな接続プール およびプール内の接続のライフサイクル管理を接続プールマネージャーを経由して行います 16

17 二つ目はJava EEコンテナ ( アプリケーション サーバ ) 等の提供しているデータソースにUCPを統合して使用するケースです このケースは統合先のデータソースがUCP 接続プールを自身の接続プールに置き換えて使用できることが前提となっています UCPではこのケースのように他のデータソース インターフェースと統合するための接続ポイントとして oracle.ucp.jdbc.pooldatasourceimpl( 非 XA 接続プール用 ) およびoracle.ucp.jdbc.PoolXADataSourceImpl(XA 接続プール用 ) を提供しています このケースではUCPの機能が他の機能が統合されるため たとえばアプリケーション サーバのJNDIにUCPのプール対応データソースを登録し アプリケーションからはJNDIをルックアップする形でデータソースを取得できたり アプリケーション サーバのトランザクション マネージャーを使ってUCP 対応接続と他のリソースマネージャーの間で分散トランザクション処理を行うなどの利用ケースが考えられます 17

18 接続プールの作成 起動 停止 破棄などのライフサイクル管理や 接続プール内の接続のリフレッシュ リサイクル ( ) 失効化など 接続プールのきめ細やかな管理をアプリケーションのレベルで行うためのコンポーネントが接続プール マネージャです 接続プールマネージャーの生成は以下のように行います UniversalConnectionPoolManager mgr = UniversalConnectionPoolManagerImpl. getuniversalconnectionpoolmanager(); 接続プールマネージャには管理用の各種メソッドが提供されており すべて接続プール名を引数にして実行します 以下の例では "my_ucp_pool" という名前で作成したUCP 接続プールに対して接続のリフレッシュを行っています mgr.refreshconnectionpool("my_ucp_pool"); 接続プールのリフレッシュとはプール内の接続を新しい接続に置き換えることを言います また接続のリサイクルとは失効した接続のみを新しい接続に置き換えることを指します 18

19 UCP JDBC 接続プールは Oracle Real Application Cluster(RAC) および Oracle DataGuardの持つ機能と統合されています アプリケーションは上記データベースシステムに接続する際はサービス名を指定してUCPに対して接続要求をするだけで データベース側がその処理をするうえで最もパフォーマンスが期待できるインスタンスに透過的に接続が行われます また 接続の取得後に接続先に構成変更や障害が発生した場合も アプリケーションに対して迅速に通知が行われ アプリケーション側でその結果に応じたリアクションがとれるようになります 次のページ以降で上記機構を実現するために提供されている機能について説明を行っていきます なお これら統合のメリットをアプリケーションで使用するためにはUCPを使用するのに加えてOracle JDBCドライバ Oracle RACデータベース Oracle Clientソフトウェアに同梱されているOracle Notification Serviceライブラリ (ons.jar) を構成 使用する必要があります 19

20 このチャートでご紹介する高速接続フェイルオーバーは UCPがRACおよび DataGuardが発行するFast Application Notification(FAN) イベントによる通知をONS 経由で受け取ることで実現される機能です データベースインスタンスのサービスが停止するイベント ( 例 : インスタンス障害 ) が発生すると そのイベントをONS 経由で受け取ったUCPは自身の接続プールの中でそのインスタンスへの接続オブジェクトを即座にクリーンアップし 新たに来るクライアントからの接続要求に対しては別の利用可能なインスタンスへの接続を渡すことが可能です ( 接続のフェイルオーバー ) また既に接続を取得してしまっているアプリケーションに対してはシステム例外をスローすることで 障害によってアプリケーション処理が滞ってしまうことを回避します その後 該当するインスタンスで再びサービスが利用可能になると UCPは再びFANイベントを受信する形でそのことを認識し 再びそのインスタンスに対する接続の確立を行うようになります 通常の接続プーリング機能ではアプリケーションによるデータベースへのアクセプスの結果からしか接続先のインスタンスのステータスを判断することができないのに対して 高速接続フェイルオーバーではそれに加えてデータベースシステム側からの通知を併用することでこれまでよりも迅速な対応ができ 結果としてアプリケーション処理に与える時間的な影響を短くすることを実現します 20

21 高速接続フェイルオーバーを利用するためのコードの記述例をこのページのチャートに示します アプリケーションおよびUCP 側でおこなうアクションはPoolDataSourceの setfastconnectionfailoverenabled() メソッドにtrueを渡して実行することと ONSの構成を行うことのふたつです 接続を取得してトランザクションを実施中に 接続先でサービスが利用できなくを実施中なってしまった場合のアクションはアプリケーション側で設定を行います そこで便利なメソッドが oracle.ucp.jdbc.validconnectionインタフェースのisvalidメソッドで チャート内の記述例のように使用することでOracle RAC 停止イベントによってSQL 例外がスローされた後でも流用された接続が使用可能かどうかをチェックすることが可能です この例では障害によって接続が使用できなくなってしまった場合は再度 getconnection() からやり直すことにしています SQLException をキャッチしている時点でUCP 側では失効した接続のクリーンアップが行われているため 再び障害が発生したインスタンスへの接続を取得することなく正常稼働中のインスタンスへの接続が確立されます 21

22 FANイベントにはインスタンスやサービスの状態変化のほかにロード バランシング アドバイザ情報があります これはその時々での RACインスタンスの負荷状況を示す情報です このイベント情報を元にワークロード戦略を決定し 最適な割り振り先をクライアントに提供するのが実行時接続ロードバランシングです 要はパフォーマンスが良好なインスタンスを積極的に選択して割り振りを行い パフォーマンスの悪いインスタンスへの割り振りはあまり行わなくすることでワークロードの平準化と処理パフォーマンスの最適化を行います なお 実行時接続ロードバランシングをOFFにすると ロード バランシング アドバイザ情報は参照せずにランダムに割り振りが行われます 22

23 実行時ロードバランシングによって 複数の RAC インスタンスからその時々で最適な接続先が割り当てられるため 複数の接続要求が来ればそれぞれ異なるインスタンスにまたがって割り当てられることが考えられます しかしアプリケーション処理によっては複数の処理を同一のインスタンスにまとめて行った方が高いパフォーマンスを期待できるケースもあります たとえば分散トランザクション処理の 1 リソースマネージャーとして RAC データベースが指定されている場合 RAC そのものは分散トランザクション情報をノード間で共有するしくみがありますが それよりは単一のインスタンスで処理を固定した方が 共有のコストを省略できる分だけトランザクション処理におけるパフォーマンスが向上することが期待できます このようなケースで使用できる機能が接続アフィニティ機能です 接続アフィニティが有効な場合 最初の接続要求では ( もし有効にしてある場合 ) 実行時接続ロードバランシングにて接続先のインスタンスが決定されます その際に Affinity Context が付与されます これによって次からの接続要求が最初の接続先と同じインスタンスに固定されるようになります 23

24 ここまでご紹介したRACおよびDataGuardとの連携機能は利用できる機能がデータベース側のバージョンによって異なっています またJDBCドライバのバージョンも同じかもしくはそれ以上に合わせる必要があります 24

25 結論を言うと ICCをお使いになっているシステムですぐにUCPへの移行が必要というわけではなく また引き続きICCを使用したアプリケーションの開発も可能です ただし ICCで実現できることと同じ要件をUCPでも実現できますので 今後新規開発の場合は 可能であればUCPを利用されることをお勧めします ICCからUCPへの移行については以下のガイドが出ておりますのでご参考ください Transitioning to Oracle Universal Connection Pool (UCP) uide.pdf 25

26 このチャートではOracle JDBC Driver 11g R1における主な新機能をご紹介します 以降のページでそれぞれについて説明をしていくことにします 他にも11g R1でのエンハンスメントや変更点はありますが 詳しくは以下のガイドをご参照ください Oracle Database JDBC 開発者ガイドおよびリファレンス 11gリリース1(11.1) E

27 今回はOracle 固有の機能について取り扱っているため ここのエンハンスメントについての詳細は割愛します 詳細はJDBC 4.0 仕様をご覧ください Oracle database 11g JDBC にはJava 5 対応のojdbc5.jarとJava 6 対応の ojdbc6.jarがあります JDBC4.0 仕様はJava 6にてサポートされる機能ですので ここでご紹介する機機能はojdbc6.jarで利用が可能です 27

28 11g R1 からプリフェッチの仕組みが改良されアドホック クエリの処理が大量に発生する条件下でのパフォーマンスが向上しました これまでは SQL 文の parse と execute でデータベースとのラウンドトリップが一回発生し その後プリフェッチのために再度ラウンドトリップが発生していましたが 11g R1 からは最初のラウンドトリップにて最初のプリフェッチ データが一緒に取得できるようになりました これによってネットワーク負荷 レスポンスタイム およびサーバ側 / クライアント側双方の CPU 利用率の低減が期待できます 28

29 アプリケーションからデータベースの管理を行うための機能が追加されました まずはデータベースインスタンスの開始と停止 sqlplusでいうところのstartup とshutdownに該当する操作がOracle JDBC APIにて可能となりました oracle.jdbc.oracleconnectionのstartupおよびshutdownメソッドがそれです このメソッドを実施するための条件としてサーバーに対する専用接続が必要であり またSYSDBAまたはSYSOPERとして接続する必要があります SYSDBAまたはSYSOPERとして Oracle JDBCドライバ経由で接続するには internal_logon 接続プロパティに適切な値を設定する必要があります さらに Thinドライバを使用する場合は ログオンするためにパスワード ファイルを使用するようにサーバーを構成しておく必要があります 29

30 JDBC ドライバがデータベースの変更通知を受け取ることができるようになりました これによって 例えばクライアントとデータベースサーバの間で結果セットのデータをキャッシュして再利用するようなコンポーネントがこの機能を使用してキャッシュしているデータの変更が伴うような DML 文や DDL 文が発行された際に JDBC ドライバ経由でこのイベントを通知として受信し データを失効化したりリフレッシュしたりすることができるようになりました 30

31 繰り返し実行される可能性のある問い合わせに対して その結果セットをキャッシュとして保持しておくことで レスポンスタイムの向上とデータベースへのクエリーの低減を図るのがここでご紹介する結果セット キャッシュを導入する目的です 結果セット キャッシュにはデータをキャッシュする場所の違いで二種類あり クライアント結果キャッシュとサーバ側キャッシュの二種類があり 結果セットの内容に変更が発生するDML 文が発行されたときの挙動が異なります サーバ側キャッシュの場合はキャッシュ データの変更が発生するような DML 文が発行されると キャッシュ データを自動的に無効化します それに対してクライアント結果キャッシュではデータの変更に伴ってキャッシュデータの更新が行われます そのためクライアント結果キャッシュを有効にしている場合はクライアント側でデータ同期のために内部的にさも常時連続的にクエリーを発行しているかのような効果があります なお クライアント結果キャッシュはOracleクライアントでデータをキャッシュするため Thin ドライバでは使用できません 31

32 11g R1リリースよりOracle JDBCにおいてOracle Advanced Securityの機能がフルサポートされました まず クライアントとサーバの間の通信の暗号化のためにAES256 AES192 およびAES128 暗号化アルゴリズムをサポートします また攻撃から保護をする目的で クライアントとサーバとの間でのデータ伝送時のデータ整合性を確保するために MD5やSHA-1のハッシング アルゴリズムを使用たメッセージ ダイジェストを作成し ネットワークに送るメッセージに含めることで攻撃の脅威から保護を行うことが可能になります また 業界標準の認証手法であるKerberosやRADIUSそしてSSL 認証サポートをサポートします これらOracle Advanced Securityの機能を実装するJavaクラスがojdbc*.jarファイルに含まれています これとプロパティのセットによる設定によってThinドライバはOracle Advanced Securityの機能を使用します OCIドライバの場合は Oracleクライアントに実装されている機能を使用します 32

33 11g R1からJavaアプリケーションにおけるOracle Advanced Queueing (AQ) へのアプローチとして これまでの (Oracle)JMSベースのアプローチに加えて oracle.jdbc.aqパッケージを使用したjavaインターフェースがサポートされるようになりました この新しいインターフェースではJMSを介さずにデータベースへの接続オブジェクトを使用して直接メッセージの円キューおよびデキューを行います また 11g R1ではJMSを使用したこれまでのメッセージング アプローチにおいてもネイティブ AQプロトコルが採用されたことにより内部的に PL/SQL の使用を行わなくすることでパフォーマンスの向上とCPU 利用率の低減を図っています 33

34 34

35 35