Oracle® Fusion Middleware Oracle Identity and Access Management高可用性ガイド 11g リリース2 (11.1.2.3) E61957-01 |
|
前 |
次 |
この章では、可用性の高いOracle Databaseアクセスの考慮事項について説明します。
この章に含まれている項は次のとおりです。
Fusion Middlewareコンポーネントのほとんどでは、そのデータの永続ストアとしてデータベースが使用されます。Oracle Databaseバックエンドは、Cold Failover Clusters、Oracle Real Application Clusters、Oracle Data Guard、Oracle Streamsなど、任意の数の高可用性構成で構成できます。詳細は、Oracle Database高可用性概要を参照してください。この章では、可用性の高いOracle DatabaseであるOracle Real Application Clustersで構成されたOracle Fusion Middlewareの考慮事項について説明します。
Oracle Real Application Clusters (Oracle RAC)とは、複数の相互接続されたコンピュータの処理能力を利用したコンピューティング環境です。ハードウェアの集合(クラスタ)とともに、各コンポーネントの処理能力を結合して1つの堅牢なコンピューティング環境を構成します。Oracle RACは同時に、Oracle Fusion Middlewareに対して、スケーラビリティおよび可用性の高いデータベースを提供します。
クラスタ内のすべてのOracle RACインスタンスは、同じアクセス権および認可レベルを持つため、ノードおよびインスタンスに障害が発生しても、障害が発生していないサーバー・インスタンスでデータベース・サービスを利用したり、利用可能な状態にすることができ、これにより、パフォーマンスに影響を及ぼす場合はありますが、停止することはありません。
Oracle RACの詳細は、Oracle Real Application Clusters管理およびデプロイメント・ガイドを参照してください。
Oracle Fusion Middlewareにより、高可用性環境でOracle Databaseとの最適な統合が実現します。Oracle Fusion Middlewareはデータベースのクライアント(javaクライアントとシステム・クライアントのいずれか)として動作する場合、データベース障害シナリオに対して高速のフェイルオーバーを提供して中間層のダウンタイムを最小に抑える、特別な通信機能および監視機能を使用します。
データベースにアクセスするOracle Fusion Middlewareコンポーネントは、次のように分類できます。
Oracle WebLogic ServerにデプロイされるJavaベースのコンポーネント
スタンドアロンのJavaクライアントとなるJavaベースのコンポーネント
Java以外のコンポーネント
この章の内容は次のとおりです。
Oracle WebLogic ServerにデプロイされるOracle Fusion Middlewareコンポーネントはすべて、Oracle RACをサポートします。接続プールを確立する場合、Oracle Fusion Middlewareでは、XA JDBCドライバとXA以外のJDBCドライバ両方に対して、Oracle RACバックエンドのGridLinkデータ・ソースおよびマルチ・データ・ソースがサポートされます。Oracle Fusion Middlewareデプロイメントでは、Oracle RACのOracle JDBCドライバでサポートされるその他の接続フェイルオーバー機能はサポートされません。マルチ・データ・ソースの構成の詳細は、各コンポーネントのガイドを参照してください。
Oracle RACのノードまたはインスタンスに障害が発生すると、WebLogic ServerまたはOracle Thinドライバによって、セッション・リクエストがクラスタ内の別のノードにリダイレクトされます。既存の接続のフェイルオーバーはありませんが、アプリケーションからの新しい接続要求は、Oracle WebLogicプールの既存の接続を使用して管理されるか、稼働中のOracle RACインスタンスへの新しい接続によって管理されます。データベースがトランザクション・マネージャの場合、通常、進行中のトランザクションはロールバックされます。WebLogic Serverがトランザクション・マネージャの場合、進行中のトランザクションはフェイルオーバーされ、障害発生時のトランザクションの状態に基づいて、完了するかロールバックするかが判断されます。アプリケーションにOracle RACノード全体でのロード・バランシングが必要な場合、WebLogic Serverでは、ロード・バランシング用に構成されたJDBC GridLinkデータ・ソースまたはJDBCマルチ・データ・ソースを使用することにより、この機能がサポートされます。GridLinkロード・バランシングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのランタイム接続ロード・バランシングに関する説明を参照してください。
GridLinkデータ・ソースには、汎用データ・ソースの機能に加え、Oracle RACに対する次のサポートが含まれています。
高速接続フェイルオーバー
ランタイム接続ロード・バランシング
Oracle RACの停止に対する適切な処理
XAアフィニティ
単一クライアント・アクセス名(SCAN)アドレス
Oracleウォレットを使用したセキュアな通信
データベース接続の高可用性、ロード・バランシング、フェイルオーバーをサポートするために、GridLinkデータ・ソースとマルチ・データ・ソースが用意されています。ご使用のOracle RAC Databaseバージョンに応じて、次のデータ・ソース・タイプをお薦めします。
Oracle RACデータベースのバージョンが11gリリース2以降の場合は、GridLinkデータ・ソースを使用します。
Oracle RACデータベースのバージョンが11gリリース2より前の場合や、Oracle Database以外のデータベースを使用している場合は、マルチ・データ・ソースを使用します。
注意: Oracle RACデータベースの可用性を最大限に高めるために、GridLinkデータ・ソースの使用をお薦めします。GridLinkデータ・ソースがサポートされていないOracle RACデータベースのバージョンの場合は、マルチ・データ・ソースを使用して可用性を高めることをお薦めします。 |
次のトピックの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの使用に関する説明を参照してください。
GridLinkデータ・ソースとは
GridLinkデータ・ソースのソケット・ダイレクト・プロトコルの使用
接続プール機能の構成
Oracleパラメータの構成
ONSクライアントの構成
GridLinkデータ・ソース接続プールのチューニング
データベースのセキュリティ資格証明の設定
GridLink JDBCリソースの監視
Oracle RACバックエンドに対してOracle Fusion Middlewareをデプロイする場合、マルチ・データ・ソースはすぐに使用可能な状態に構成されています。マルチ・データ・ソースには、データベース・サービスを提供するRACインスタンスごとの構成データ・ソースが存在します。データベース・サービスを提供するRACインスタンスを追加で構成する場合、Fusion Middleware層でマルチ・データ・ソースにデータ・ソースを追加することをお薦めします。マルチ・データ・ソースに作成する各構成データ・ソースが、第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」のプロパティとまったく同じように構成されていることを確認します。
非RACのデータベースをRACデータベースに移行する場合、影響を受けるデータ・ソースごとに同等のマルチ・データ・ソースを新しく作成する必要があります。作成するマルチ・データ・ソースには、各RACインスタンスと整合性のあるデータ・ソースが必要です。第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」のプロパティでは、データ・ソース値は元の単一インスタンスのデータ・ソースと同一である必要があります。たとえば、単一インスタンスのデータ・ソース・ドライバがoracle.jdbc.xa.client.OracleXADataSource
である場合、新しいマルチ・データ・ソースの各構成データ・ソースのドライバはoracle.jdbc.xa.client.OracleXADataSource
である必要があります。
MDSデータベース・ベースのリポジトリを使用するアプリケーションは、可用性の高いOracle Databaseへのアクセス用に構成できます。この構成では、MDSおよびWebLogicインフラストラクチャによる障害検出、リカバリおよび再試行によって、アプリケーションの読取り専用のMDS操作が、Oracle RACデータベースの計画停止および計画外停止から保護されます。
マルチ・データ・ソースは、Fusion Middleware Controlのナビゲーション・ツリーに、MDSリポジトリとして公開されます。これらのマルチ・データ・ソースは、アプリケーション・デプロイメントのデプロイメント・プランのカスタマイズ時に選択できます。また、MDS WLSTコマンドでも使用できます。
読取り専用操作を再試行できるようなアプリケーションの構成
接続を再試行できるようにアプリケーションを構成するには、アプリケーションのMDS AppConfig MBeanのRetryConnection属性を構成します。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
MDSマルチ・データ・ソースの登録
第4.1.5項「Oracle RACでのマルチ・データ・ソースの構成」で指定した手順以外にも、次の点を検討してください。
MDSリポジトリに使用されるマルチ・データ・ソースを構成する子データ・ソースは、XA以外のデータ・ソースとして構成する必要があります。
マルチ・データ・ソースの名前には、mds-
という接頭辞を付ける必要があります。これにより、Fusion Middleware Control、WLSTおよびJDeveloperを介してMDS管理機能に使用できるMDSリポジトリとして、マルチ・データ・ソースを認識できるようになります。
注意: MDSデータ・ソースをマルチ・データ・ソースの子として追加すると、このデータ・ソースはMDSリポジトリとしては公開されなくなります。たとえば、これはFusion Middleware Controlのナビゲーション・ツリーで、「メタデータ・リポジトリ」フォルダの下に表示されなくなり、それに対してMDSリポジトリの操作を実行できなくなって、デプロイメント時には選択可能なリポジトリのリストに表示されなくなります。 |
マルチ・データ・ソースへのデータ・ソースの変換
データ・ソースをマルチ・データ・ソースに変換してアプリケーションが正しく構成されていることを確認する場合、次の2つの考慮事項があります。
新しい一意の名前を持つマルチ・データ・ソースを新規作成するには、アプリケーションを再デプロイして、デプロイメント・プランのカスタマイズ時に、この新しいマルチ・データ・ソースをMDSリポジトリとして選択します。
アプリケーションの再デプロイを回避するには、データ・ソースを削除し、同じ名前とjndi-name属性を使用して、新しいマルチ・データ・ソースを再作成できます。
この項では、Oracle RACの構成の要件について説明します。
XAの要件: 多くのOracleコンポーネントは、分散トランザクションに参加したり、コンテナで管理されるトランザクションの一部となります。それらのコンポーネントには、 Oracle WebLogic トランザクション・マネージャによるXAリカバリ用に、バックエンド・データベースの設定が必要です。RCUを使用して作成されたリポジトリでは、これは自動的に実行されます。XAトランザクションに参加する他のデータベースについては、XAの前提条件が満たされていることを確認してください。
次のように入力して、システム・ユーザーとしてSQL*Plusにログオンします。
sqlplus "/ as sysdba"
sys.dba_pending_transactions
に対してselectをpublic
に付与します。
sys.dbms_xa
に対してrunをpublic
に付与します。
任意のトランザクションに対してforceをuser
に付与します。
注意: Oracle Databaseの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 Database(特にOracle RAC)にOracle Fusion Middlewareを構成する場合、Oracleサービス機能を使用することをお薦めします。特定のアプリケーションのデータベース・サービスの場所の一部として提供するservice_name
を作成します。
Oracle WebLogic Serverトランザクション・マネージャがトランザクションの状態情報を問い合せて、WebLogic Serverコンテナで障害が発生した後の処理中トランザクションのリカバリ時に、commitやrollbackなどの適切なコマンドを発行できるようにするには、適切なデータベース権限が必要です。
トランザクション・リカバリ権限のスキーマを構成する手順は次のとおりです。
sysdba権限を持つユーザーとしてSQL*Plusにログオンします。例:
sqlplus "/ as sysdba"
sys.dba_pending_transactionsに対してselectをappropriate_userに付与します。
任意のトランザクションに対してforceをappropriate_userに付与します。
注意: これらの権限は、RCUの操作によって決定されるsoainfraスキーマの所有者に付与します。 |
GridLinkデータ・ソースの構成方法は、使用しているOracleコンポーネントおよび作成するドメインによって異なります。手順の詳細は、使用しているコンポーネントについて説明している項を参照してください。
注意: WebLogicコンソールでTNSリスナーとONSリスナーの両方にホストおよびポートを指定するには、Oracle単一クライアント・アクセス名(SCAN)アドレスを使用することをお薦めします。Oracle RACノードを追加または削除する場合、SCANアドレスを含むGridLinkデータ・ソースを更新する必要はありません。ご使用の環境に対して適切に構成されたSCAN URLについては、ネットワーク管理者に問い合せてください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのSCANアドレスに関する説明を参照してください。 |
GridLinkデータ・ソースの構成方法の包括的な概要は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』ガイドのGridLinkデータ・ソースの作成に関する説明を参照してください。
マルチ・データ・ソースは、次のものを使用して構成できます。
Oracle Fusion Middlewareの構成ウィザード(WebLogic Serverドメインの作成時)
Oracle Universal InstallerのJava EEコンポーネント構成(Identity Management用)。
Oracle WebLogic Server管理コンソール
WLSTコマンド
マルチ・データ・ソースでは、XAデータ・ソースとXA以外のデータ・ソースの両方のロード・バランシングがサポートされます(これは、Oracle Fusion MiddlewareコンポーネントでサポートされるすべてのOracle Databaseのバージョンに適用されます)。
マルチ・データ・ソースでは、Oracle RACの特定のインスタンスへの接続をプールする個々のデータ・ソースがカプセル化されます。手動で作成されたマルチ・データ・ソースまたは初期構成の後に変更されたマルチ・データ・ソースについては、可用性の高い動作を最適にするために、次のXAデータ・ソースおよびXA以外のデータ・ソースのプロパティ値に設定することを強くお薦めします。環境の要件により変更が必要な場合は、検討とテストを十分に行ってから変更してください。
高可用性環境では、個々のデータ・ソースに対して次の設定をお薦めします。その他のパラメータについても、アプリケーション要件に従って設定することをお薦めします。
表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タイムアウトを増加できます。
管理コンソールを使用してこの設定を増加する手順は次のとおりです。
データ・ソース構成にアクセスします。
「トランザクション」タブを選択します。
XAトランザクション・タイムアウトを、300のように大きな値に設定します。
「XAトランザクション・タイムアウトの設定」チェック・ボックスを選択します。このチェック・ボックスは、新しいXAトランザクション・タイムアウト値を有効にするために選択する必要があります。
「保存」をクリックします。
XAマルチ・データ・ソースの個々のデータ・ソースすべてに対してこの構成を繰り返します。
Java J2SEベースのOracle Fusion Middlewareコンポーネントは、Oracle RACの高可用性機能と連携するように最適化されています。このコンポーネントは、Oracle JDBCシン・ドライバまたはOCIベースのJDBCドライバの両方を使用するようにデプロイできます。
JDBCシン・クライアントは、Pure JavaのタイプIVドライバです。これは軽量でインストールが簡単であり、JDBC Oracle Call Interface (OCI)ドライバのパフォーマンスに匹敵する高いパフォーマンスを提供します。JDBCシン・ドライバは、Oracle Databaseからデータにアクセスするために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データベースにOracle Virtual Directoryデータベース・アダプタを構成するには、次の手順を実行します。
「接続」画面で、「URLタイプ」リストから「カスタムURLの使用」を選択します。
「データベース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データベースの接続タイムアウトを構成するには、次の手順を実行します。
「接続」画面のJDBCシンで、タイムアウトのパラメータとしてデータベース・アダプタのパラメータoracleNetConnectTimeoutを秒数で指定します。
JDBC OCIの場合は、ディレクトリORACLE_INSTANCE/configのsqlnet.ora
でTCP.CONNECT_TIMEOUT=n
と指定します。
Oracle Fusion Middleware 11gには、Oracle Internet Directoryなど、Java以外のコンポーネントがいくつか含まれています。これらのコンポーネントでは、Oracle Call Interface層を使用してOracle Databaseと対話します。Oracle RACベースのシステムの場合、一部のコンポーネントは、Oracle Databaseの高可用性イベント通知機能と統合します。
高可用性イベント通知は、データベースに障害が発生した場合に、Java以外のアプリケーションに信号を送ります。受け取ったアプリケーションは環境でコールバックを登録して、データベース接続を監視できます。Java以外のクライアントに関連したデータベースに障害が発生すると、コールバックが呼び出されます。このコールバックには、イベント・ペイロードなどのデータベース障害に関する情報、障害が原因で切断された接続(サーバー・ハンドル)のリストが含まれます。
同じデータベースの別のインスタンス(インスタンスCなど)が停止した場合、クライアントの接続には影響しないため、クライアントには通知されません。
高可用性イベント通知を使用すると、データベースに障害が発生した場合のアプリケーションのレスポンス時間が向上します。イベント通知を使用しないと、データベースの障害が発生した場合に、TCPタイムアウトの時間が経過するまで接続は切断されず、それまでに数分かかってしまいます。高可用性のイベント通知により、スタンドアロン、接続プールおよびセッション・プールの接続はOCIによって自動的に切断されてクリーンアップされ、障害が発生してから数秒以内にアプリケーション・コールバックが呼び出されます。サーバー・ハンドルのいずれかがTAF対応の場合、OCIによって自動的にフェイルオーバーが処理されます。
次の項では、Java以外のクライアントでOracle RACデータベースに接続する際にお薦めする設定について説明します。
ほとんどの本番デプロイメントにはファイアウォールが関係しており、データベース接続はファイアウォールを介して行われます。そのため、このファイアウォールは、データベース接続がタイムアウトしないように構成することをお薦めします。Oracle RACの場合は具体的に、Oracle RAC VIPおよびデータベース・リスナー・ポートで接続をタイムアウトしないということになります。
そのような構成が不可能な場合は、データベース・サーバー側のORACLE_HOME/network/admin/sqlnet.ora
で SQLNET.EXPIRE_TIME=n
と設定します。Oracle RACでは、すべてのOracleホームでこのように設定する必要があります。n
の単位は分です。これは、ネットワーク・デバイス(ファイアウォール)のタイムアウトの既知の値より小さく設定する必要があります。これらの時間は通常、10分より大きな値で、場合によっては数時間に設定されていることもあるため、できるだけ大きな値に設定する必要があります。
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秒待機し、この時間を超えると断念します。
11.2 RDBMS Oracle RACデータベースが単一クライアント・アクセス名(SCAN)を使用して構成されていない場合、構成ウィザードおよびOracle Universal Installerで、Oracle RACインスタンスの詳細を、以前のデータベース・リリースで入力したとおりに指定できます。インスタンス・アドレスの形式はhost:port
です。
11.2 RDBMS Oracle RACデータベースがSCANを使用して構成されている場合は、Oracle RACインスタンスの詳細をSCANアドレスで指定します。Oracle RACインスタンスへのFusion Middlewareの接続では、各Oracle RACインスタンスは、サービス名、インスタンス名、ホストおよびポートを使用して一意に識別されます。そのようなすべてのインスタンスのhost:port
アドレスはSCAN host:port
であるため、この同じ共通アドレスをすべてのインスタンスに使用することをお薦めします。
インストール・タイプに基づいて、次のガイドラインに従います。
RCUインストールでは、Oracle RACデータベースに対して、ホスト名はscan-hostname-address
として指定します。
Oracle Universal Installerのインストールでは、Oracle Universal Installerで必要な入力形式に応じて、Oracle RACデータベースに対して次のように指定します。
scan-address-hostname:port:instance1^scan-address-hostname:port:instance2@servicename
または
scan-address-hostname:port^scan-address-hostname:port@servicename
マルチ・データ・ソースを使用する構成ウィザードのインストールでは、scan-address-hostname,port,service-name
は各構成データ・ソースで同じである必要があります。インスタンス名は各構成データ・ソース固有のものであり、Oracle RACエンド・インスタンスにターゲット指定されている必要があります。
SCANを使用したGridLinkでは、インスタンス名は使用されません。次の例では、RACインスタンスを使用しないGridLink接続文字列を示しています。
jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<scan-host-name>)(PORT=<scan-port>)))(CONNECT_DATA=(SERVICE_NAME=rac-service-name)))
接続文字列が明示的に指定される場合は、次のベース・フォーマットを使用します。
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-hostname-address) (PORT=port)))(CONNECT_DATA=(SERVICE_NAME=service-name))) when the whole Oracle RAC database needs to be specified (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=scan-hostname-address) (PORT=port)))(CONNECT_DATA=(SERVICE_NAME=service-name)(INSTANCE_NAME=inst1))) when a specific Oracle RAC instance needs to be specified
注意: SCANの詳細は、Oracle Grid Infrastructureに関するインストレーション・ガイドのクラスタに関する単一クライアント・アクセス名(SCAN)についての説明や、『Oracle Real Application Clustersインストレーション・ガイド』の簡略化されたクライアント・アクセスに関するSCANアドレスについての説明を参照してください。 |
SCANの実行時の内容と制限
表4-4に、RACに対して構成する際にサポートされるシナリオを示します。
表4-4 SCANの実行時の内容と制限
シナリオ | 説明 | 高可用性実行時の成果と制限 |
---|---|---|
1. SCANなし |
別のRACインスタンスを指している各下位マルチ・データ・ソースを含むマルチ・データ・ソース |
WLSマルチ・データ・ソースを実装することによって管理されるデータベース接続について、実行時の高可用性が得られます。 |
2. SCAN |
SCANアドレスを指している各下位データ・ソースを含むマルチ・データ・ソース |
WLSマルチ・データ・ソースを実装することによって管理されるデータベース接続について、実行時の高可用性が得られます。 制限: SCANアドレスを参照した場合でも、WLSマルチ・データ・ソースの高可用性機能を制限付きで使用することになります。 |
3. SCAN |
SCANアドレスを指している単一のデータ・ソース |
データベース接続について実行時の高可用性は得られません。 制限: SCANアドレスはRACインスタンスへのエントリ・ポイントを仮想化しますが、WLS上の単一データ・ソースを指定したとしても、それによって高可用性が提供されることはありません。これは、各サーバーが実際には単一のRACインスタンスにバインドされているためです。 |
4. SCAN |
SCANアドレスを指しているGridLinkデータ・ソース |
SCANをサポートする適切なデータベース・バージョンを使用してONSを正しく設定する必要があり、これにより、FANが有効な設定を使用して、データベースから送信されるONSステータス・メッセージを受信します。 |