対応バージョン

Oracle Database 12.1

更新履歴

日付更新概要
2015/01/05記事公開

Oracle Database 12cR1からアプリケーション・コンティニュイティ(Application Continuity（AC）)という機能が実装されました。
TAF(Transparent Application Failover/透過的アプリケーションフェイルオーバー)という機能の拡張版のようなものです。
TAFではRAC(Real Application Cluster)環境にて、SELECT文を実行中のサーバにて障害が発生した場合、SELECT文を他のサーバへフェイルオーバー（リカバリ）する機能ですが、こちらの機能では更新系(UPDATE/INSERT/DELETE)についてもセッションのリカバリを行います。

詳細な設定については以下に記載されています。必ず熟読したのち使用してください。

Oracle Database開発ガイド
12c リリース1 (12.1)
B71295-06
https://docs.oracle.com/cd/E57425_01/121/ADFNS/adfns_app_continuity.htm

本記事を書くにあたり、メリット部分の強調される記事を散見しましたが、制限やデメリット部分、設定についての記事が殆ど見当たらなかったため記載しております。考慮点もありますので、しっかり内容を把握してから実装するようにしてください。

AC概要

AC(アプリケーション・コンティニュイティ)は、データベース・セッションが使用不可となり、リカバリ可能なエラーが発生した場合に利用されます。データベース全体が落ちる、ハングするなどのエラーには対応できません。
リカバリ可能なエラー発生後、データベースに対するリクエストを中断せず、迅速な方法でリプレイできるようにします。
リクエストには、トランザクション処理や非トランザクション処理が含まれる場合があります。ACではセッションが中断された地点から処理を続行します。

注意点

構成の前提条件

以下の条件を満たす必要があります。

  • Oracle Realtime Application Cluster(RAC)又はActive DataGuard
  • Universal Connection Pool(UCP) 12.1以上 または WebLogic Active GridLink 12.1.2 以上、またはサード・パーティ・アプリケーション(サード・パーティJDBCプールなど)の場合はJDBCリプレイ・ドライバ
  • beginRequestおよびendRequestの指定
    • UCP又はWebLogic Server Active GridLinkを利用したコネクションプールの場合は自動的に実行されます
    • カスタムJavaプール（カスタムJDBCプール、WebSphere、TomCat、JBOSSまたは他のプール）およびスタンドアロン・アプリケーションを使用する場合、beginRequestおよびendRequestコールを追加します
  • WebLogicデータソースまたはUCPまたはサード・パーティ・プールからFAN/FCFを使用した単一プールを使用します
  • データベース・サービスを使用して接続します。SIDまたはインスタンス名は使用しません
  • 接続文字列にRETRY_COUNT、CONNECT_TIMEOUTおよびTRANSPORT_CONNECT_TIMEOUTパラメータを設定します
  • サービスのプロパティをリプレイ用に構成します
    • FAILOVER_TYPE = TRANSACTION: アプリケーション・コンティニュイティを使用します
    • REPLAY_INITIATION_TIMEOUT = n: リプレイを開始できる期間(秒)を設定します(nには、必要に応じて60、300、900、1800などを指定できます)
    • FAILOVER_RETRIES = 30: リプレイごとに接続の再試行回数を指定します
    • FAILOVER_DELAY = 10: 接続の再試行間の遅延時間を秒単位で設定します
    • GOAL = SERVICE_TIME: Oracle RACまたはOracle GDS (Global Data Services)を使用している場合、これが推奨設定です
    • CLB_GOAL = SHORT: Oracle RACまたはOracle GDSを使用している場合、これが推奨設定です
  • REMOTE_LISTENERはクライアントのADDRESS_LISTと一致する必要があります
    • REMOTE_LISTENERがSCAN名に設定されている場合、ADDRESS_LISTはSCAN VIPを使用する必要があります
    • 接続文字列がSCAN名を使用する場合、REMOTE_LISTENERSにSCAN名を設定する必要があります
    • 接続文字列がホストVIPのADDRESS_LISTを使用する場合、REMOTE_LISTENERSにすべてのSCAN VIPとすべてのホストVIPを含むアドレス・リストを設定する必要があります
  • リプレイを有効化するアプリケーションを実行するデータベース・ユーザーには、DBA権限を付与しないでください

可変オブジェクトについて

可変オブジェクトとは、コールされる度に新しい値を取得するオブジェクトのことを指しています。例えばシーケンスのcurrval/nextval等です。
可変オブジェクト値を保持するためのサポートは現在以下のような状況です。

・SYSDATE、SYSTIMESTAMP（スキーマ単位。） 

SQL> grant KEEP DATE TIME to [スキーマ];

・SYS_GUID（スキーマ単位。パラレル問い合わせ未対応。）

SQL> grant KEEP SYSGUID to [スキーマ];

・sequence.NEXTVAL/CURRVAL(オブジェクトにKEEP属性を付与後、grantによるスキーマ単位の付与。)

SQL> ALTER SEQUENCE sales.my_seq KEEP;
SQL> grant KEEP SEQUENCE on sales.my_seq to [スキーマ];

・LOBに関しては上記のようなKEEP属性が存在しません。

リソースについて

以下のようなリソース使用状況の変化が想定されます。

  • サーバ及びクライアント側でCPUオーバヘッドが発生する
  • クライアント側でベース・ドライバに比較して、メモリを使用する（十分なメモリがある場合は、4～8GB以上を-Xmxおよび-Xmsに割り当てます。）

リカバリ出来ないトランザクションについて

以下のようなトランザクションについてはリカバリが出来ません。

  • ユーザによるリカバリ不可能なエラー（例えばNOT NULL制約のカラムにNULLを投入する）
  • 機能による制限事項（マニュアルに飛びます）
  • disableReplayを使用してアプリケーション・コンティニュイティを明示的に無効化する
  • サービス・パラメータsession_state_consistencyがDynamic (デフォルト)に設定されているときにCOMMIT文を発行した場合の、後続のトランザクション
  • endRequest文を発行した場合
  • NOREPLAYキーワードを使用したセッションの中断または切断
  • リクエストがALTER SYSTEM文またはALTER DATABASE文を発行した場合

リトライをすべきかの判断について

リトライ不要か考慮が必要なトランザクションがあります。
繰り返す必要のないコールが含まれるリクエストに対してdisableReplay APIの使用を選択します。例えばメール通知等のパッケージを使用し、リトライすることでメールが複数発行されてしまう場合などに、実行の判断をユーザによって行いたい場合等です。

  • アプリケーション・コンティニュイティによる潜在的な副作用（マニュアルに飛びます）
  • 揮発エンティティ（テンポラリテーブル等）を使用したトランザクション（例えば、1つの成功するトランザクションを見込んでおり、他は排他制御によりエラー終了されるような相互依存のSQLの場合、リプレイ時に相互依存が崩れることがあります。）
  • アプリケーションが実行ロジックで中間層の時刻を使用する場合
  • ROWIDが変更されないことをアプリケーションが前提として使用している場合
  • sys_context(‘USERENV’,’IP_ADDRESS’)のようにロケーション値が変更されないことを前提としている場合

セッション中断(KILL)時の注意点について

リプレイが有効になっているセッションの中断にはNOREPLAYを使用してください。
以下のSQL文のようにnoreplayを付与しない場合、ACの機能によりセッションをリプレイしようとしてしまいます。

SQL> alter system kill session 'sid, serial#, @inst' noreplay;
SQL> alter system disconnect session 'sid, serial#, @inst' noreplay;

コメント

他の機能と同様かと思いますが、制限事項をよく読み、過信しないことが重要です。
アプリケーションの受け取るエラーや対処が減るというのは、運用負荷を下げ、コスト削減や安定稼働につながる為、大変導入価値のある機能です。
但し、アプリケーションのリプレイを考えなくてよくなるというわけではありませんので、大きな補助機能として実装を考えるようにすべきかと思われます。

また、実装や制限が複雑なため、システムに合わせて実装するためには日本オラクル社コンサルタントによる支援をうけることを推奨いたします。