[Database, WLS] Active GridLink Configuration for Database Outages

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/agl_database_outages

---

この記事では、Oracle Database RAC環境でのデータベース停止時に対応するための、Active GridLink (AGL) データソースの設計・展開について説明します。

AGL Configuration for Database Outages

Active GridLinkデータソースが以下のドキュメントに従って構成されているものとします。

Oracle® Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理 12c (12.1.3)
Active GridLinkデータ・ソースの使用方法
http://docs.oracle.com/cd/E57014_01/wls/JDBCA/gridlink_datasources.htm#JDBCA373
Oracle® Fusion Middleware Administering JDBC Data Sources for Oracle WebLogic Server 12.1.3
Using Active GridLink Data Sources
http://docs.oracle.com/middleware/1213/wls/JDBCA/gridlink_datasources.htm#JDBCA373

• FANが有効化されます。FANはデータベースサービスやインスタンス、データベース自身、クラス田尾を構成するノードの状態が変化すると速やかに通知します。計画的なメンテナンスの間に、アプリケーションに対しどのような形であれエラー無しでインスタンスへの接続を返すことができます。
• 自動ONSもしくは明示的なONSの設定
• ダイナミックデータベース・サービス：データベースサービスやPDBサービスを使って接続しないでください。これらは管理用途のためであって、FACはサポートしていません。
• 接続のテスト
  停止イベントが処理される前に接続を借り受けた場合、停止に応じて、アプリケーションは古い接続を受けとることがあります。例えばこの事象は、着信接続要求と同時にソケットを閉じた際にクリーンなインスタンスが停止した場合に発生することがあります。アプリケーションがエラーを受け取らないようにするためには、接続チェックを接続プールで有効化しておく必要があります。これはtest-connections-on-reserve（予約時に接続をテスト）をtrueにした上で、test-table（テスト表）を設定する必要があります（Oracle Databaseの場合、推奨値は"SQL ISVALID"です）。
• SCANの利用の最適化
  DNSからSCANアドレス用に返されるSCANのIPアドレスの並べ替えの強制を最適化する場合、URL設定を12.1.0.2以後のデータベースドライバではADDRESSLISTのLOAD_BALANCE=TRUEを設定してURLを設定する必要があります（12.1.0.2以前では、接続プロパティoracle.jdbc.thinForceDNSLoadBalancingをtrueに設定します）。

Planned Outage Operations

計画停止において、ゴールは以下のことを達成することです。

• 透過的な計画されたメンテナンス
  データベースサーバーでの計画的なメンテナンスプロセスがアプリケーションから見えるようになります。
• セッションの排出
  データベースでインスタンスをメンテナンスのために停止すると、ノードでインスタンスを利用しているすべてのワークが完了し、アイドルセッションの削除がドレーニング（draining、排出）によって保証されます。セッションは実行中のワークに影響を与えずに排出されます。

目標は、データベース・サーバーでメンテナンスが進行中の場合にもアプリケーションを中断せずに計画されたメンテナンスを管理することです。メンテナンスの目的（例えば、ソフトウェアやハードウェアのアップグレード、修理、変更、システム内およびシステム間での移行）のため、利用されるサービスは、一度に1個もしくは複数のサービスを正常にシャットダウンします。FAN DOWNイベントの際に、AGLは、メンテナンスの対象となるインスタンスからセッションを排出します。（まだ残りの実行中のインスタンス上で利用可能であることを仮定して）メンテナンス対象のデータベース・インスタンス上で実行されている非シングルトンサービスを停止したり、シングルトンサービスをメンテナンス対象のインスタンスから別のインスタンスに再配置することが必要です。サービスがセッションを排出した後、インスタンスは、アプリケーションに対して全くエラーなしで停止します。
以下は計画停止が発生した場合の動きをまとめたものです。

• メンテナンス対象のインスタンスに対してDBAが発生させた“DOWN”イベントを検知
• 当該インスタンスからセッションを排出
• 計画メンテナンスをデータベースサーバで実行
• アップグレードされたノードで運用を再開

データベース・サーバと中間層の両方でオペレーションの調整が必要なマルチデータソースとは異なり、Active GridLinkではデータベースと協調し、これらのオペレーションすべてがデータベースから管理されるため、プロセスが簡素化されます。
下表はデータベース・サーバで実行される手順と対応する中間層での反応をまとめたものです。

データベースサーバでの操作手順	コマンド	中間層の反応
非シングルトンサービスを”-force”オプションを付けずに停止する、もしくはシングルトンサービスを別ノードに移す インスタンス上のすべてのサービスで-serverオプションを省略する	$ srvctl   stop service –db <db_name> -service <service_name> -instance   <instance_name> または $ srvctl   relocate service –db <db_name> -service <service_name> -oldinst <oldins> -newinst <newinst>	サービスのFAN Planned   Down (reason=USER) （計画停止）イベントは接続プールに対し、サービスが利用できず、接続の排出が必要であることを知らせる。 サービスのアイドル接続を即時解放する。利用中の接続はアプリケーションが返した（論理的に閉じた）際に解放される。 新規接続は他のインスタンスやサービスを提供するデータベースで予約される。 このFANアクションでは、アプリケーションを中断せずに、インスタンスからのセッションの排出を開始する。
自動的に再起動されないことを保証するため、停止したサービスを必要に応じて無効化 このステップは、メンテナンスが完了するまでサービスが再起動してはいけないメンテナンス時に推奨されるステップ	$ srvctl disable service –db <db_name> -service <service_name> -instance <instance_name>	中間層で停止・利用できないサービスと新規接続を関連付けない。
セッション排出		セッション排出に要する時間はアプリケーションによって異なる。 長時間実行中のクエリがある可能性がある。定期的に接続を返し、新しい接続を取得するようにバッチプログラムが作成されていない可能性があるため、バッチプログラムをメンテナンス前に排出することを推奨する。
長時間実行中のセッションを確認 トランザクションの切断を使用してこれらのセッションを終了させる セッションの排出を待つ セッションの残存を確認するためにクエリを再実行できる	SQL>   select count(*) from ( select 1 from v$sessionwhere service_name in   upper('<service_name>') union all select 1 from v$transaction where   status = 'ACTIVE' ) SQL> exec dbms_service.disconnect_session(   '<service_name>', DBMS_SERVICE.POST_TRANSACTION);	中間層の接続でエラーが発生する。 Application Continuityを使用している場合は、自動的に別のインスタンスの新規接続でオペレーションを再生することで、アプリケーションからのエラーを隠すことが可能。それ以外の場合、アプリケーションはSQLExceptionを取得する。
上記手順を繰り返す	計画メンテナンス対象のすべてのサービスに対し繰り返す
immediate オプションを使ってデータベースインスタンスを停止	$ srvctl stop instance –db <db_name> -instance <instance_name> -stopoption  immediate	データベースやサービスが再起動されるまで中間層に影響はない
必要に応じ、インスタンスを無効化し、メンテナンス中に自動的に再起動しないようにする これは、サービスがメンテナンス中に再開できないようにするためのステップ	$ srvctl   disable instance –db <db_name> -instance <instance_name>
計画メンテナンスを実行	計画メンテナンスの実行（パッチ適用、修復、変更など）
インスタンスの有効化および開始	$ srvctl   enable instance –db <db_name> -instance <instance_name> $ srvctl start instance –db <db_name> -instance <instance_name>
サービスを有効化し、再起動し、サービスが立ち上がり、実行中になっていることを確認	$ srvctl   enable service –db <db_name> -service <service_name> -instance   <instance_name> $ srvctl   start service –db <db_name> -service <service_name> -instance   <instance_name>	サービスのFAN UPイベントが、接続プールに新しいインスタンスが利用可能になったことを通知する 次回のリクエスト送信で、このインスタンスでのセッション作成が可能 セッションの自動リバランス開始

下図は、計画停止前後の2個のRACインスタンスにわたるサービスへの接続の分散を示しています。接続ワークロードが両インスタンスで50:50から、100:0に遷移することに着目してください。言い換えると、メンテナンスビジネスに影響しないでRAC_INST_1のメンテナンスを実行することができる、ということです。
（訳注）
原文に記載されているリンクがアクセスできないリンクのため、このエントリでも非表示にしています。

Unplanned Outages

設定は計画停止、非計画停止で同じですが、非計画停止の場合にはいくつか相違点があります。

• データベースサーバのコンポーネントが、当該ノードで実行中のインスタンス上のすべてのサービスを利用不可にすることに失敗する可能性があり、それゆえにサービスが停止、無効化されていない場合があります。
• FANの非計画DOWNイベント (reason=FAILURE) が中間層に配信されます。
• 非計画停止イベントに対応して、すべてのセッションが即座に閉じられ、アプリケーションがTCP/IPタイムアウトを待たなくてすみます。既存の他のインスタンスへの接続はそのまま利用可能で、必要に応じて他のインスタンスへの新規接続を開くことができます。
• 接続は正常に排出されません。Application Continuityを使うよう構成されているサービスを利用するアプリケーションの場合、アクティブなセッションを生存しているインスタンスに復元し、オペレーションの再生、アプリケーションに対する停止の隠蔽をした上で、セッションを回復します。Application Continuityで保護されていない場合、インスタンスとのアクティブな通信している任意のセッションがSQLExceptionを受けとります。