ヘッダーをスキップ
Oracle Fusion Middleware高可用性ガイド
11gリリース1(11.1.1)
B55898-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

4 可用性の高いOracleデータベース・アクセスの考慮事項

この章では、可用性の高いOracleデータベース・アクセスの考慮事項について説明します。

この章に含まれている項は次のとおりです。

4.1 Oracle Real Application ClustersとFusion Middleware

Fusion Middlewareコンポーネントのほとんどでは、そのデータの永続ストアとしてデータベースが使用されます。Oracleデータベース・バックエンドは、Cold Failover Clusters、Real Application Clusters、Oracle Data Guard、Oracle Streamsなど、任意の数の高可用性構成で構成できます。これらの高可用性構成の詳細は、『Oracle Database高可用性概要』を参照してください。この章では、可用性の高いOracleデータベースであるOracle Real Application Clustersで構成されたOracle Fusion Middlewareの考慮事項について説明します。

Oracle Real Application Clusters(Oracle RAC)は、相互接続された複数のコンピュータの処理能力を利用するコンピューティング環境です。クラスタと呼ばれるハードウェアの集合とともに、各コンポーネントの処理能力を結合して単一の堅牢なコンピューティング環境を構成します。クラスタは、2つ以上のコンピュータ(ノードともいう)で構成します。Oracle Real Application Clustersは同時に、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。

クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持ちます。したがって、ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスが利用可能であるか、利用可能な状態にすることができるため、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。

Oracle Real Application Clustersの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

Oracle Fusion Middlewareにより、高可用性環境でOracleデータベースとの最適な統合が実現します。Oracle Fusion Middlewareはデータベースのクライアント(javaクライアントとシステム・クライアントのいずれか)として動作する場合、データベース障害シナリオに対して高速のフェイルオーバーを提供して中間層のダウンタイムを最小に抑える、特別な通信機能および監視機能を使用します。

データベースにアクセスするOracle Fusion Middlewareコンポーネントは、次の3つに分類できます。

この項の内容は次のとおりです。

4.1.1 Oracle WebLogic ServerにデプロイされるJavaベースのOracle Fusion Middlewareコンポーネント

Oracle WebLogic ServerにデプロイされるOracle Fusion Middlewareコンポーネントはすべて、Oracle Real Application Clusters(RAC)をサポートします。接続プールを確立する場合、Oracle Fusion Middlewareは、XA JDBCドライバとXA以外のJDBCドライバ両方に対して、Oracle RACバックエンドのマルチ・データソースのみをサポートします。接続プールについては、Oracle Fusion Middlewareデプロイメントでは、Oracle RACのOracle JDBCドライバでサポートされるその他の接続フェイルオーバー機能はサポートしません。Oracle RACのマルチ・データソースは、Oracle WebLogic Serverの構成ウィザードで構成します。また、マルチ・データソースは、Oracle Fusion Middleware管理コンソールまたはWLSTコマンドを使用して構成することもできます。マルチ・データソースの構成の詳細は、各コンポーネントのマニュアルを参照してください。

Oracle RACのノードまたはインスタンスに障害が発生すると、Oracle WebLogic ServerとOracleシン・ドライバのいずれかによって、セッション・リクエストはクラスタ内の別のノードにリダイレクトされます。既存の接続のフェイルオーバーはありませんが、Oracle WebLogicプールの既存の接続を使用して管理されるアプリケーションからの新しい接続要求や、稼働中のOracle RACインスタンスへの新しい接続による新しい接続要求が発生します。データベースがトランザクション・マネージャの場合、通常、進行中のトランザクションはロールバックされます。WebLogic Serverがトランザクション・マネージャの場合、進行中のトランザクションはフェイルオーバーされます。つまり、障害発生時のトランザクションの状態に基づいて、完了するかロールバックするかが判断されます。アプリケーションにOracle RACノード全体でのロード・バランシングが必要な場合、WebLogic Serverは、ロード・バランシング用に構成されたJDBCマルチ・データソースを使用することで、この機能をサポートします。マルチ・データソースを構成する個々のデータソースには、ラウンドロビン・スキーム(Oracleが推奨する、RACデータベースに対するデプロイメントの構成)を使用してアクセスします。接続を切り替える際に、WebLogic Serverは、一覧表示されている順に次のデータソースへの接続を選択します。次の項では、Oracle RACでのマルチ・データソースの構成について簡単に説明します。

4.1.2 Oracle RACでのマルチ・データソースの使用

マルチ・データソースを使用してOracle WebLogic Serverを複数のOracle RACノードに接続するには、Oracle RACクラスタでOracleシン・ドライバを使用して、各Oracle RACインスタンスに対してJDBCデータソースを構成します。次に、ロード・バランシングとフェイルオーバーいずれかのアルゴリズムを使用してマルチ・データソースを構成し、それにデータソースを追加します。

図4-1 マルチ・データソース構成

マルチ・データソース構成
「図4-1 マルチ・データソース構成」の説明

4.1.2.1 MDSリポジトリのためのマルチ・データソースの構成

MDSデータベース・ベースのリポジトリを使用するアプリケーションは、可用性の高いOracleデータベースへのアクセス用に構成できます。この構成では、MDSおよびWebLogicインフラストラクチャによる障害検出、リカバリおよび再試行によって、アプリケーションの読取り専用のMDS操作が、Oracle RACデータベースの計画停止および計画外停止から保護されます。

MDSマルチ・データソースは、Fusion Middleware Controlのナビゲーション・ツリーに、MDSリポジトリとして公開されます。これらのマルチ・データソースは、アプリケーション・デプロイメントのデプロイメント・プランのカスタマイズ時に選択できます。また、MDS WLSTコマンドでも使用できます。

  • 読取り専用操作を再試行できるようなアプリケーションの構成

    接続を再試行できるようにアプリケーションを構成するには、アプリケーションのMDS AppConfig MBeanのRetryConnection属性を構成します。MDS構成の詳細は、Oracle Fusion Middlewareの管理者ガイドの該当する項を参照してください。

  • MDSマルチ・データソースの登録

    第4.1.3項「Oracle RACでのマルチ・データソースの構成」で指定した手順以外にも、MDSについて次の点を検討してください。

    • MDSリポジトリに使用されるマルチ・データソースを構成する子データソースは、XA以外のデータソースとして構成する必要があります。

    • マルチ・データソースの名前には、mds-という接頭辞を付ける必要があります。これは、Fusion Middleware Control、WLSTおよびJDeveloperを介してMDS管理機能に使用できるMDSリポジトリとして、マルチ・データソースを認識できるようにするために必要です。


      注意:

      MDSデータソースをマルチ・データソースの子として追加すると、このデータソースはMDSリポジトリとしては公開されなくなります。たとえば、これはFusion Middleware Controlのナビゲーション・ツリーで、「メタデータ・リポジトリ」フォルダの下に表示されなくなり、それに対してMDSリポジトリの操作は実行できなくなり、デプロイメント時には選択可能なリポジトリのリストに表示されなくなります。

  • マルチ・データソースへのデータソースの変換

    MDSデータソースをマルチ・データソースに変換してアプリケーションが正しく構成されていることを確認する場合、次の2つの考慮事項があります。

    • 新しい一意の名前を持つマルチ・データソースを新規作成する場合は、アプリケーションを再デプロイして、デプロイメント・プランのカスタマイズ時に、この新しいマルチ・データソースをMDSリポジトリとして選択します。

    • アプリケーションの再デプロイを回避する場合は、データソースを削除し、同じ名前とjndi-name属性を使用して、新しいマルチ・データソースを再作成できます。

4.1.2.2 Oracle RACの構成要件

この項では、Oracle RACの構成の要件について説明します。

  • XAの要件: 多くのOracleコンポーネントは、分散トランザクションに参加したり、コンテナで管理されるトランザクションの一部となります。それらのコンポーネントには、Oracle WebLogic トランザクション・マネージャによるXAリカバリ用に、バックエンド・データベースの設定が必要です。RCUを使用して作成されたリポジトリでは、これは自動的に実行されます。XAトランザクションに参加する他のデータベースについては、XAの前提条件が満たされていることを確認してください。

    1. 次のように入力して、システム・ユーザーとしてsqlplusにログオンします。

      sqlplus "/ as sysdba"
      
    2. sys.dba_pending_transactionsに対してselectをpublicに付与します。

    3. sys.dbms_xaに対してexecuteをpublicに付与します。

    4. 任意のトランザクションに対してforceをuserに付与します。


      注意:

      Oracleデータベースのdistributed_lock_timeoutパラメータがJTAタイムアウトより大きな値に設定されていることを確認してください(これは、中間層(WebLogic Serverのデフォルト、データソースの特定の構成、トランザクションのコンポーネントで使用される値)の最高値より大きな値にする必要があります)。

  • サーバー側のロード・バランシング: サーバー側のロード・バランシング機能が(remote_listenersを使用して)Oracle RACバックエンドで有効になっている場合、マルチ・データソース構成のデータソースで使用されるJDBC URLにINSTANCE_NAMEを含める必要があります。たとえば、このURLは次の書式で指定できます。

    jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)
    (PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)(INSTANCE_NAME=inst1)))
    

    デフォルトでは、インストールした時点では、remote_listenerが構成されていると想定されており、それに従ってマルチ・データソースのデータソースにURLが作成されます。通常のインストールおよび構成以外で作成された任意のマルチ・データソースは、この項で説明されている書式に従う必要があります。

    remote_listenersがOracle RAC側で指定できず、サーバー側のロード・バランシングが無効になっている場合は、URLのINSTANCE_NAMEを指定する必要はありません。リモート・リスナーを無効にするには、それぞれのOracle RACノードのspfile.oraファイルで、一覧表示されているリモート・リスナーをすべて削除します。次に例を示します。

    *.remote_listener="
    

    この場合、マルチ・データソース構成のデータソースで使用する際にお薦めするURLは次のとおりです。

    jdbc:oracle:thin:@host-vip:port/dbservice
    

    または

    jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=host-vip)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=dbservice)))
    
  • サービス: Oracleデータベース(特にOracle RAC)にOracle Fusion Middlewareを構成する場合、Oracleサービス機能を使用することをお薦めします。特定のアプリケーションのデータベース・サービスの場所の一部として提供するservice_nameを作成します。

4.1.3 Oracle RACでのマルチ・データソースの構成

Oracle Middleware 11gコンポーネントは、Oracle RACのマルチ・データソース構成のみをサポートします。マルチ・データソースは、次のものを使用して構成できます。

  • Oracle WebLogic Serverの構成ウィザード(WebLogic Serverドメインの作成時)

  • Oracle Universal InstallerのJava EEコンポーネント構成(Identity ManagementまたはOracle Portal、Forms、ReportsおよびDiscoverer用)

  • Oracle WebLogic Server管理コンソール

  • WLSTコマンド

マルチ・データソースは、XAデータソースとXA以外のデータソース両方のロード・バランシングをサポートします。これは、Oracle Fusion MiddlewareコンポーネントでサポートされるすべてのOracleデータベースのバージョンに適用されます。

マルチ・データソースでは、Oracle RACの特定のインスタンスへの接続をプールする個々のデータソースがカプセル化されます。手動で作成されたマルチ・データソースまたは初期構成の後に変更されたマルチ・データソースについては、可用性の高い動作を最適にするために、次のXAデータソースおよびXA以外のデータソースのプロパティ値に設定することを強くお薦めします。環境の要件によりそれらのプロパティ値を変更する場合は、検討とテストを十分に行ってから実行してください。

表4-1 推奨されるマルチ・データソース構成

プロパティ名

test-frequency-seconds

5

algorithm-type

Load-Balancing


高可用性環境では、個々のデータソースに対して次の設定をお薦めします。アプリケーションの要件に従って、その他のパラメータも設定する必要があります。

表4-2 XAデータソース構成

プロパティ名

ドライバ

oracle.jdbc.xa.client.OracleXADataSource

プロパティ・コマンド

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

TwoPhaseCommit

keep-xa-conn-till-tx-complete

true

xa-retry-duration-seconds

300

xa-retry-interval-seconds

60


表4-3 XA以外のデータソース構成

プロパティ名

ドライバ

oracle.jdbc.OracleDriver

設定するプロパティ

<property>

<name>oracle.net.CONNECT_TIMEOUT</name>

<value>10000</value>

</property>

initial-capacity

0

connection-creation-retry-frequency-seconds

10

test-frequency-seconds

300

test-connections-on-reserve

true

test-table-name

SQL SELECT 1 FROM DUAL

seconds-to-trust-an-idle-pool-connection

0

global-transactions-protocol

なし


推奨されるマルチ・データソースの例は、付録B「推奨されるマルチ・データソース」を参照してください。

XAデータソースのトランザクション・タイムアウトの増加

次の例外を含むWARNINGメッセージがサーバー・ログに表示される場合があります。

javax.transaction.SystemException: Timeout during commit processing

[ javax.transaction.SystemException: Timeout during commit processing

これは、設定したXAタイムアウト値を増加する必要があることを示している可能性があります。このような警告が表示された場合は、個々のデータソースのXAタイムアウトを増加できます。

この設定を増加するには、Oracle WebLogic Server管理コンソールを使用します。

  1. データソース構成にアクセスします。

  2. トランザクション」タブを選択します。

  3. XAトランザクション・タイムアウトを、300のように大きな値に設定します。

  4. 保存」をクリックします。

XAマルチ・データソースの個々のデータソースすべてに対してこの構成を繰り返します。

4.1.4 WebLogic ServerでのOracle RACのフェイルオーバー

Oracle RACにはJDBC接続時間フェイルオーバー機能が用意されていますが、ほとんどの構成では、フェイルオーバーの管理にWebLogic JDBCマルチ・データソースを使用することをお薦めします。接続時間フェイルオーバーには、代替のOracle RACノードへの接続を事前に作成する機能はありませんが、マルチ・データソースには、フェイルオーバーの管理に常に使用可能な接続が複数あります。詳細は、「Oracle RACでのマルチ・データソースの使用」を参照してください。

4.1.5 JDBCクライアント

Java J2SEベースのOracle Fusion Middlewareコンポーネントは、Oracle RACの高可用性機能と連携するように最適化されています。このコンポーネントは、Oracle JDBCシン・ドライバまたはOCIベースのJDBCドライバを使用するようにデプロイできます。

JDBCシン・クライアントは、Pure JavaのタイプIVドライバです。軽量でインストールが簡単です。JDBC Oracleコール・インタフェース(OCI)ドライバによって提供されるパフォーマンスに匹敵する、高パフォーマンスが提供されます。JDBCシン・ドライバは、OracleデータベースからデータにアクセスするためにOracleによって開発されたプロトコル、TTCを使用しているサーバーと通信します。このドライバは、Javaソケットの上にOracle NetとTTCを実装するTCP/IPの実装を提供することにより、データベースへの直接接続を可能とします。JDBC OCIクライアントはタイプIIのドライバであり、Oracle Netを介してJDBCクライアントへの接続を提供します。これは、Oracle Netのクライアント側インストールを使用します。デプロイメントでは、中間層のOracle Net構成を使用して動作をカスタマイズできます。


注意:

これらのJDBCクライアントは、スタンドアロンのJava J2SEプログラムの一部として使用されます。

Oracle Virtual Directory

データベース・アダプタで使用すると、Oracle Virtual Directoryはデータベースに接続し、接続はプールされません。Oracle RACのデータベース・アダプタの構成の詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のデータベース・アダプタの作成に関する項を参照してください。

データベースURL

Oracle Directory Services Managerを使用してOracle RACデータベースにOVDデータベース・アダプタを構成するには、次の手順を実行します。

  1. 接続」画面で、「URLタイプ」リストから「カスタムURLの使用」を選択します。

  2. データベースURL」フィールドで、Oracle RACデータベースに接続するためのURLを入力します。次に例を示します。

    JDBCシン

    jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_
    BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host-name-1)(PORT=1521))(ADDRESS=
    (PROTOCOL=TCP)(HOST=host-name-2)(PORT=1521)))(CONNECT_
    DATA=(SERVER=DEDICATED)(SERVICE_NAME=database-service-name)))
    

    JDBC OCI

    jdbc:oracle:oci:@(DESCRIPTION=(ADDRESS_LIST=(LOAD_
    BALANCE=ON)(ADDRESS=(PROTOCOL=TCP)(HOST=host-name-1)(PORT=1521))(ADDRESS=
    (PROTOCOL=TCP)(HOST=host-name-2)(PORT=1521)))(CONNECT_
    DATA=(SERVER=DEDICATED)(SERVICE_NAME=database-service-name)))
    

接続タイムアウトの構成

Oracle Directory Services Managerを使用してOracle RACデータベースの接続タイムアウトを構成するには、次の手順を実行します。

  1. 接続」画面の「JDBCシン」で、タイムアウトのパラメータとしてデータベース・アダプタのパラメータoracleNetConnectTimeoutを秒数で指定します。

  2. JDBC OCIの場合は、ORACLE_INSTANCE/configディレクトリのsqlnet.oraTCP.CONNECT_TIMEOUT=nと指定します。

4.1.6 システム・クライアント

Oracle Fusion Middleware 11gには、Java以外のコンポーネントがいくつか含まれています。これらのコンポーネントは主にCベースで、Oracle Internet Directory(OID)、Oracle Forms、Oracle Reports、Oracle DiscovererおよびOracle Portalが含まれます。これらのコンポーネントでは、Oracle Call Interface層を使用してOracleデータベースと対話します。Oracle RACベースのシステムの場合、一部のコンポーネントは、Oracleデータベースの高可用性イベント通知機能と統合します。

高可用性イベント通知は、データベースに障害が発生した場合に、Java以外のアプリケーションに信号を送ります。受け取ったアプリケーションは環境でコールバックを登録して、データベース接続を監視できます。Java以外のクライアントに関連したデータベースに障害が発生すると、コールバックが呼び出されます。このコールバックには、イベント・ペイロードなどのデータベース障害に関する情報、障害が原因で切断された接続(サーバー・ハンドル)のリストが含まれます。

同じデータベースの別のインスタンス(インスタンスCなど)が停止した場合、クライアントの接続には影響しないため、クライアントには通知されません。同じデータベースの別のインスタンス(インスタンスCなど)が停止した場合、クライアントの接続には影響しないため、クライアントには通知されません。

高可用性イベント通知を使用すると、データベースに障害が発生した場合に、アプリケーションのレスポンス時間が向上します。イベント通知を使用しないと、データベースの障害が発生した場合に、TCPタイムアウトの時間が経過するまで接続は切断されず、それまでに数分かかってしまいます。高可用性のイベント通知により、スタンドアロン、接続プールおよびセッション・プールの接続はOCIによって自動的に切断されてクリーンアップされ、障害が発生してから数秒以内にアプリケーション・コールバックが呼び出されます。これらのサーバー・ハンドルのいずれかがTAF対応の場合、OCIが自動的にフェイルオーバーを処理します。

次の項では、Java以外のクライアントでOracle RACデータベースに接続する際にお薦めする設定について説明します。

4.1.6.1 Oracle Internet Directory

Oracle Internet Directoryは、高可用性のイベント通知と統合します。クライアント・アプリケーションがデータベースへの接続に使用するデータベース・サービスは、Oracle Enterprise Manager Cluster Managed Services Pageを使用して作成することをお薦めします。

SQL*Plusを使用してOracle RACデータベース・サービスを構成することもできます。

Oracle RACデータベース接続で高可用性のイベント通知を有効にするには、次の手順を実行します。

  1. AQ_HA_NOTIFICATIONS属性をTRUEに設定して、サーバー側の透過的アプリケーション・フェイルオーバー(TAF)設定を有効にします。フェイルオーバーの再試行とフェイルオーバーの遅延は、デプロイメントの要件に基づいて調整できます。そのため、OIDで使用されるデータベース・サービスの場合、Oracle Oracle RACのDBMS_SERVICEプロパティの値を設定するときには、表4-4に従うことをお薦めします。

    表4-4 OIDのデータベース・サービス・プロパティ設定

    プロパティ名

    AQ_HA_NOTIFICATIONS

    TRUE

    FAILOVER_METHOD

    DBMS_SERVICE.FAILOVER_METHOD_BASIC

    FAILOVER_TYPE

    DBMS_SERVICE.FAILOVER_TYPE_SELECT

    FAILOVER_RETRIES

    5

    FAILOVER_DELAY

    5


  2. Oracle Net構成のTCP接続タイムアウトを設定することもお薦めします。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

4.1.6.2 Oracle Forms

Oracle Formsも、高可用性のイベント通知と統合します。Oracle Formsでこの機能を有効にするには、次の手順を実行します。

  1. Oracle Enterprise Manager Cluster Managed Services Pageを使用して、データベース・サービスを作成します。Oracle Formsの場合、表4-5に従ってOracle RACのDBMS_SERVICEプロパティの値を設定します。Oracleデータベースのパッケージを使用して設定する推奨値を次に示します。

    表4-5 Oracle Formsのデータベース・サービス・プロパティ設定

    プロパティ名

    AQ_HA_NOTIFICATIONS

    TRUE

    FAILOVER_METHOD

    DBMS_SERVICE.FAILOVER_METHOD_NONE

    FAILOVER_TYPE

    DBMS_SERVICE.FAILOVER_TYPE_NONE


  2. Oracle Net構成のTCP接続タイムアウトを設定することもお薦めします。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

4.1.6.3 Oracle Portal

高可用性環境でOracle Portalの動作を最適に構成するには、Oracle Net構成のTCP接続タイムアウトを設定します。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

Oracle Portalでは、mod plsqlの障害検出機能も使用します。

mod_plsqlではデータベースへの接続プールが保持され、確立されたデータベース接続が後続のリクエストに再利用されます。接続プールのデータベース接続からレスポンスがない場合には、mod_plsqlでそのことが検出され、切断された接続が廃棄されて、後続のリクエスト用に新しいデータベース接続が作成されます。

mod_plsqlの切断されたデータベース接続検出機能によって、データベース・ノードまたはインスタンスが停止したときにエラーがランダムに発生しなくなります。この機能は、Real Application Clusters(RAC)などの高可用性構成でも極めて有用です。Oracle RACクラスタのノードが停止すると、mod_plsqlでそのことが検出され、他のOracle RACノードを使用してリクエストへの対応が即座に開始されます。

デフォルトでは、Oracle RACノードまたはデータベース・インスタンスが停止し、そのノードへの接続がmod_plsqlでそれ以前にプールされていた場合、プール内の切断された接続を使用する最初のmod_plsqlリクエストには障害が発生し、HTTP-503というレスポンスがエンドユーザーに返されます。mod_plsqlは、この障害をトリガーとして、プール内の切断されている接続をすべて検出して削除します。mod_plsqlにより、ノードに障害が発生する前に作成されていた接続プールがすべてpingされます。このping操作は、プールされた接続を使用する次回リクエストの処理時に実行されます。ping操作が失敗すると、そのデータベース接続は破棄され、新しい接続が作成されて処理されます。


注意:

ノード障害の後、複数のmod_plsqlリクエストを同時に受信したときに、最初に切断された接続がmod_plsqlで検出されていないと、その時点で複数の障害が発生している可能性があります。

mod_plsqlでは、切断されたデータベース接続の検出機能をチューニングするために、次の2つの構成オプションが用意されています。

  • 切断されたデータベース接続を検出するオプションの指定

  • タイムアウト期間の指定

切断されたデータベース接続を検出するオプションの指定

mod_plsqlでは、データベース・ノードの停止が原因と考えられる障害を検出すると、接続を修正します。これは、PlsqlConnectionValidationパラメータで制御されます。PlsqlConnectionValidationパラメータの詳細は、『Oracle HTTP Server管理者ガイド』のmod_plsqlに関する項を参照してください。

PlsqlConnectionValidationパラメータをAutomaticに設定すると、mod_plsqlモジュールは、失敗したリクエストの前に作成されていたプール済データベース接続をすべてテストします。これがデフォルトの構成です。

PlsqlConnectionValidationパラメータをAlwaysValidateに設定すると、mod_plsqlは、任意のリクエストを発行する前に、プールされていたデータベース接続をすべてテストします。AlwaysValidate構成オプションを使用すると、可用性は高まりますが、パフォーマンス・オーバーヘッドも増加します。

mod_plsqlが接続プールの不完全なデータベース接続をテストするタイムアウト期間を指定できます。PlsqlConnectionTimeoutパラメータには、テスト・リクエストが完了するまでmod_plsqlが待機する最大時間を指定します。この時間を超えると、接続が使用不可とみなされます。

接続検証とタイムアウト期間の指定

PlsqlConnectionValidationパラメータをAutomaticまたはAlwaysValidateに設定すると、mod_plsqlはプールされているデータベース接続をテストしようとします。

mod_plsqlが接続プールの不完全なデータベース接続をテストするタイムアウト期間を指定できます。これは、PlsqlConnectionTimeoutパラメータで制御されます。このパラメータには、テスト・リクエストが完了するまでmod_plsqlが待機する最大時間を指定します。この時間を超えると、接続が使用不可とみなされます。

PlsqlConnectionTimeoutPlsqlConnectionValidationPlsqlConnectionTimeoutパラメータの詳細は、『Oracle HTTP Server管理者ガイド』のmod_plsqlに関する項を参照してください。

4.1.6.4 Oracle ReportsとOracle Discoverer

高可用性環境でOracle ReportsとOracle Discovererの動作を最適に構成するには、Oracle Net構成のTCP接続タイムアウトを設定します。この設定を構成するには、ORACLE_INSTANCE/configディレクトリのsqlnet.oraファイルでTCP.CONNECT_TIMEOUT=nと指定します。

Oracle Discovererでは、RACデータベースの接続に、次のようなtnsエントリも使用します。

frdisco = (DESCRIPTION = (LOAD_BALANCE = ON) (ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = stajo05-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = stajo06-vip)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = orcl.us.oracle.com)))

4.2 ファイアウォールのタイムアウトからのアイドル接続の保護

ほとんどの本番デプロイメントにはファイアウォールが関係しており、データベース接続はファイアウォールを介して行われます。このファイアウォールは、データベース接続がタイムアウトしないように構成することをお薦めします。Oracle RACの場合は具体的に、Oracle RAC VIPおよびデータベース・リスナー・ポートで接続をタイムアウトしないということになります。

そのような構成が不可能な場合は、データベース・サーバー側のORACLE_HOME/network/admin/sqlnet.oraSQLNET.EXPIRE_TIME=nと設定します。Oracle RACでは、すべてのOracleホームでこのように設定する必要があります。nの単位は分です。これは、ネットワーク・デバイス(ファイアウォール)のタイムアウトの既知の値より小さく設定する必要があります。これらの時間は通常、10分より大きな値で、場合によっては数時間に設定されていることもあるため、できるだけ大きな値に設定する必要があります。

4.3 Real Application Clustersのトラブルシューティング

Fusion Middlewareコンポーネントでは、Oracle RACデータベースへの接続時にマルチ・データソースを使用します。Oracle RACインスタンスが停止すると、WebLogic ServerはSELECT 1 FROM DUALという問合せを使用して、データベースのステータスを確認しようとします。この問合せは通常、数秒以内に完了します。ただし、データベースのレスポンスが遅い場合、WebLogic Serverはそれを断念してそのデータベースを使用不可とみなします。ログに記録される種類の例外の例を次に示します。

<Mar 30, 2009 2:14:37 PM CDT> <Error> <JDBC> <BEA-001112> <Test "SELECT 1 FROM
 DUAL" set up for pool SOADataSource-rac1" failed with exception:
 oracle.jdbc.xa.OracleXAException".> [TopLink Warning]: 2009.03.30
 14:14:37.890--UnitOfWork(14568040)--Exception [TOPLINK-4002] (Oracle TopLink -
 11g Release 1 (11.1.1.1.0) (Build 090304)):
 oracle.toplink.exceptions.DatabaseException Internal Exception:
 java.sql.SQLException: Internal error: Cannot obtain XAConnection Creation of
 XAConnection for pool SOADataSource failed after waitSecs:30 :
 weblogic.common.ResourceException: SOADataSource(SOADataSource-rac1): Pool
 SOADataSource-rac1 has been @ disabled because of hanging connection tests,
 cannot allocate resources to applications. We waited 10938 milliseconds. A
 typical test has been taking 16.

データベースからレスポンスを受信するまでWebLogic Serverが待機する時間を増加するには、WebLogic Serverパラメータの-Dweblogic.resourcepool.max_test_wait_secs=30を設定します。このパラメータは、setDomainEnv.shファイルに格納されています。このパラメータを設定すると、WebLogic Serverは、SELECT 1 FROM DUALという問合せに対してデータベースからレスポンスを受信するまで30秒待機し、この時間を超えると断念します。