1. Real Application Clusters管理およびデプロイメント・ガイド
  2. アプリケーション・コンティニュイティの確保

6 アプリケーション・コンティニュイティの確保

リクエスト実行の遅延にすぎないものとしてユーザーに停止を示すには、アプリケーション・コンティニュイティを使用するようにOracle Real Application Clusters (Oracle RAC)データベースを構成します。

アプリケーション・コンティニュイティは、データベース・セッションを使用不可にするリカバリ可能なエラーの後に、データベースに対するリクエストを中断することなく、迅速な方法でリプレイできるようにする機能です。そのため、ユーザーにとって停止は、単なるリクエストの実行の遅延にしか見えなくなります。この章を使用するには、Oracle WebLogic Server、Oracle RAC、Oracle Active Data Guard (Oracle ADG)など、アプリケーション・コンティニュイティを使用するテクノロジまたは製品環境の主要な関連概念および技術をよく理解している必要があります。

注意:

マルチテナント・コンテナ・データベースは、Oracle Database 20cで唯一サポートされているアーキテクチャです。ドキュメントが改訂されている間は、従来の用語が残っている可能性があります。ほとんどの場合、"データベース"と"非CDB"は、文脈に応じてCDBまたはPDBを指しています。アップグレードなどでは、"非CDB"が以前のリリースの非CDBを指している場合もあります。

6.1 アプリケーション・コンティニュイティの理解

アプリケーション・コンティニュイティは、クライアントから認識されないように停止をマスクして、その他の方法では消失してしまう進行中のトランザクションをリカバリするために使用できます。

親トピック: アプリケーション・コンティニュイティの確保

6.1.1 アプリケーション・コンティニュイティについて

Oracle Databaseに付属するアプリケーション・コンティニュイティ機能により、データベースを使用するシステムおよびアプリケーションのフォルト・トレランスが向上します。

クライアント要求には、トランザクション処理や非トランザクション処理が含まれる場合があります。Oracle Databaseでリプレイが成功すると、アプリケーションはデータベース・セッションが中断された時点から処理を続行できるため、ユーザーは資金の振替や航空券の予約などの進行状況がわからない不安な状態に放置されることがなくなります。こうしたクライアント要求をリカバリすることで、アプリケーションがオンラインに戻ったときに、ログインのオーバーロードからのリカバリのために中間層サーバーを再起動する必要がなくなります。アプリケーション・コンティニュイティを使用すると、計画的な停止または計画外の停止の多くをマスクすることでエンド・ユーザーの使用感が向上します。アプリケーション開発者がリクエストをリカバリする必要はありません。

アプリケーション・コンティニュイティは、データベース・セッション(すべての状態、カーソル、変数、および存在する場合は最後のトランザクションを含むフル・セッション)をリストアすることで、アプリケーションとユーザーからリカバリ可能なOracle Databaseの停止の多くをマスクします(リプレイが成功した場合)。アプリケーション・コンティニュイティは、計画外停止または計画済停止(タイムアウト、ネットワーク停止、インスタンス障害、修復、構成変更、パッチ適用など)が原因で使用不可になったデータベースおよびデータベース・インスタンスにアプリケーションがアクセスしようとする際に発生する問題に対処します。アプリケーション・コンティニュイティが使用されていない場合、データベースのリカバリによってアプリケーションおよびエンドユーザーに対して停止がマスクされません。このような場合、開発者およびユーザーは例外条件に対処する必要が生じ、ユーザーは資金の振替、タイムシート、注文、請求書の支払などに何が起こったかわからないままになる可能性があります。コミットされていないデータの画面が消失し、ログインしなおしてデータの再入力が必要な場合もあります。最悪の場合、管理者は、大量のログインからリカバリするために中間層の再起動を迫られることになります。

アプリケーション・コンティニュイティを使用すると、データベース・インスタンスが使用不可になった場合、アプリケーション・コンティニュイティは正しい状態を使用してセッションおよび任意のオープン・トランザクションを再構築しようとします。トランザクションがコミットされていて、再送信する必要がない場合は、正常な戻りステータスがアプリケーションに戻されます。リプレイが成功した場合、重複のリスクなしにリクエストを安全に続行できます。アプリケーションですでに処理しており、決定したと思われるデータをリプレイによってリストアできない場合、データベースはリプレイを拒否し、アプリケーションは元のエラーを受け取ります。

アプリケーション・コンティニュイティは、進行中のトランザクションおよびデータベース・セッション状態のリカバリを実行しながら、トランザクション・ガードによって実現されるトランザクションの冪等性を確保します。各データベース・セッションには論理トランザクションID (LTXID)がタグ付けられているため、データベースは、リプレイごとにトランザクションがコミットされたかどうかのみでなく、トランザクションがコミットされた場合は処理が完了まで実行されたかどうかも識別します。アプリケーション・コンティニュイティがリプレイしようとしている間、アプリケーションはリプレイを遅延実行として認識するか、元のトランザクションに対するコミット・レスポンスを受け取ります(最後のトランザクションが停止前に完了していた場合)。

アプリケーション・コンティニュイティは、Oracle RACとOracle Active Data Guardでサポートされています。これは、マルチテナント・アーキテクチャを使用しているOracle Databaseで(プラガブル・データベース・レベルでのフェイルオーバーによって)サポートされます。現在、Oracle GoldenGate、ロジカル・スタンバイ、サード・パーティのレプリケーション・ソリューション、またはDMLリダイレクト(Oracle Active Data Guardを使用する場合)ではサポートされません。

関連項目

親トピック: アプリケーション・コンティニュイティの理解

6.1.2 アプリケーション・コンティニュイティの主な概念

この項では、アプリケーション・コンティニュイティを使用するために理解する必要があるいくつかの用語や概念について説明します。

次の用語は、この章全体を通じて使用されています。

データベース・リクエスト

データベース・リクエストとは、アプリケーションからデータベースに送信された作業のユニット(トランザクションなど)です。通常、リクエストは、1つのデータベース接続における1つのWebリクエストのSQLやPL/SQLなどのデータベース・コールに対応しています。リクエストは一般に、接続プールからデータベース接続をチェックアウトおよびチェックインするために実行されるコールによって区別されます。

リクエスト境界

リクエスト境界は、アプリケーションおよびアプリケーション・サーバーが接続プールからの接続を流用および返却する場所を示します。リクエスト境界はセッションが使用されていないことを示します。リクエスト境界がデータベースから認識できる場合、計画メンテナンスのための排出、ロード・バランシングおよび多重化などの機能をデータベース・レイヤーで分離できます。セッションは、上位のアプリケーション・レイヤーに中断が認識できない状態で再確立できます。

リカバリ可能なエラー

リカバリ可能なエラーとは、実行中のアプリケーション・セッション・ロジックとは関係なく、外部システムの障害が原因で発生するエラー(切断された接続や無効な接続など)です。リカバリ可能なエラーは、フォアグラウンド、ネットワーク、ノード、記憶域、データベースの計画済停止および計画外停止に続いて発生するエラーです。アプリケーションは、最後に発行された操作のステータスを把握しないままの状態で残される可能性があるエラー・コードを受信します。アプリケーション・コンティニュイティは、データベース・セッションを再確立し、リカバリ可能なエラーのクラスに対して保留されている作業を再発行します。

アプリケーション・コンティニュイティは、リカバリ不能なエラーが原因であるコール障害に続く作業は再発行しません。リプレイされないリカバリ不能なエラーの例には、無効なデータ値の発行があります。

コミット結果

トランザクションは、トランザクション表内のエントリを更新することによってコミットされます。Oracle Databaseは、この更新に対応するREDOログ・レコードを生成し、このREDOログ・レコードを書き出します。このREDOログ・レコードがディスク上のREDOログに書き出されると、トランザクションはデータベースでコミットされたとみなされます。クライアントの観点からは、REDOが書き込まれた後に生成されたOracleメッセージ(コミット結果と呼ばれます)をクライアントが受信した時点でトランザクションはコミットされたとみなされます。ただし、COMMITが発行されていた場合、クライアントまたはアプリケーションで受信されていないCOMMIT失敗のメッセージは取得できなくなります。

可変関数

可変関数とは、コールされるたびに新しい値を取得できる非DETERMINISTIC関数です。このため結果は頻繁に変化します。可変関数を使用すると、結果がリプレイ時に変化することがあるため、リプレイの問題が発生します。キー値でしばしば使用されるsequence.NEXTVALおよびSYSDATEについて検討してください。主キーがこれらのファンクション・コールの値を使用して構築され、後で外部キーまたは他のバインドで使用される場合、リプレイ時に同じファンクション結果が戻される必要があります。

アプリケーション・コンティニュイティは、付与されているOracleファンクション・コールに対してリプレイ時に可変オブジェクト値の置換を提供することにより、不透明バインド変数の一貫性を実現します。不変のデータベース・ファンクション( sequence.NEXTVAL、SYSDATE、SYSTIMESTAMPおよびSYSGUIDを含む)がコールに使用される場合、ファンクションの実行から戻される元の値が保存され、リプレイ時に再適用されます。

セッション状態の一貫性

COMMIT文が実行された後、このトランザクションで状態が変更された場合、セッションが失われたときにトランザクションをリプレイしてこの状態を再確立することはできません。アプリケーション・コンティニュイティに構成時には、AUTOに設定したセッション状態一貫性を使用すると、セッション状態が静的か動的かを判断する必要がなくなります。

  • 透過的アプリケーション・コンティニュイティでは、セッション状態一貫性のサービス属性をAUTOに設定すると、状態が管理されます。透過的アプリケーション・コンティニュイティには、この設定が必須です。セッション状態は、フェイルオーバー時に追跡および検証されます。無効化の後、セッション状態一貫性のサービス属性がAUTOに設定されると、可能なときにフェイルオーバーが自動的に再度有効になります。

  • セッション状態の変更が初期化によって不完全にカプセル化されていて、フェイルオーバー時にFAILOVER_RESTOREまたはコールバックで完全にはキャプチャできない場合、セッションの状態は動的です。最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。セッション状態は、リクエストの過程で変化することがあります。

  • セッション状態の変更(NLS設定やPL/SQLパッケージ状態など)がすべて初期化の一環として行われ、フェイルオーバー時にFAILOVER_RESTOREまたはコールバックでカプセル化できる場合、セッションの状態は静的です。静的アプリケーションとは、アプリケーション・コンティニュイティの前に透過アプリケーション・フェイルオーバー(TAF)を使用できるアプリケーションのことです。セッション状態は、リクエストの過程で変化しません。セッション状態の一貫性には、STATICではなくAUTOを使用することをお薦めします。自動モードでは、事前アプリケーション・コンティニュイティTAFモードよりもパージとクリーン・アップが効率的になります。

ステートレス・アプリケーション

ステートレス・アプリケーションとは、あるリクエストでセッション状態(別のWebリクエストや同様の使用によるそのセッションの以前の使用で設定されたコンテキストやPL/SQL状態など)を使用しないアプリケーション・プログラムです。リクエストの処理に必要な状態は、URL、問合せ文字列パラメータ、本文またはヘッダーの一部としてであろうとなかろうと、リクエスト自体に含まれています。クラウド環境では、スケーラビリティおよび移植性のためにアプリケーションはステートレスであることが望ましいです。サーバーはセッション状態を維持、更新または通信する必要がないため、ステートレスであることによりスケーラビリティを向上させることができます。また、ロード・バランサでは、ステートレス・システムのセッション・アフィニティを気にする必要がありません。現在、Java Webアプリケーションのほとんどはステートレスです。

親トピック: アプリケーション・コンティニュイティの理解

6.1.3 アプリケーション・コンティニュイティがアプリケーションで機能する仕組み

リカバリ可能なエラーが発生したときに、リプレイが有効化されていると、アプリケーション・コンティニュイティによってデータベース・セッションのリカバリが試行されます。

次に、アプリケーション・コンティニュイティの動作のしくみを図で示します。

図6-1 アプリケーション・コンティニュイティ

図6-1の説明が続きます
「図6-1 アプリケーション・コンティニュイティ」の説明
回復可能なエラーの後にデータベース・セッションのリカバリを試行するために、アプリケーション・コンティニュイティは次のステップを実行します。

注意:

データベース・セッションのリカバリ・ステップは、計画外の停止と計画的な停止の両方に適用されますが、特定のステップは停止のタイプに応じて変化します。

  1. クライアント・アプリケーションが要求を発行します。この要求は、中間層(ユニバーサル接続プール(UCP)、ODP.NET、WebLogic Server、OCIセッション・プール、Tuxedo、またはUCPを使用するサード・パーティ・プールなど)に渡されてデータベースに転送されます。アプリケーションは、JDBCリプレイ・ドライバまたはOCIドライバを使用して直接データベースに要求を発行することもあります。

  2. 中間層またはJDBCリプレイ・ドライバやOCIドライバが要求内の各コールを発行します。

  3. 計画済または計画外のDOWN高速アプリケーション通知(FAN)イベントまたはリカバリ可能なエラーが発生します。FANまたは高速接続フェイルオーバー(FCF)により、デッド状態の物理セッションが中断されます。

  4. アプリケーション・コンティニュイティがリプレイを開始し、次を実行します。

    1. デッド状態の物理セッションを新しいクリーンなセッションに置き換えます。

    2. 進行中のトランザクションがオープンであった場合、その結果を確認するためにトランザクション・ガードを使用してリプレイを準備します。

    3. FAILOVER_RESTORE=LEVEL1またはFAILOVER_TYPE=AUTOの場合、アプリケーション・コンティニュイティでは共通の初期セッション状態をリストアします。アプリケーション・コンティニュイティは、アプリケーションがコールバック時にFAILOVER_RESTOREで指定されていない初期セッション状態も設定している場合、ラベル・コールバックまたは初期コールバックを使用します

    4. トランザクション状態および非トランザクション状態をリカバリし、クライアント・ドライバによって確認されたデータおよびメッセージが、クライアントが確認して決定した可能性があったものと同じであることをステップごとに検証し、データベース・セッションを再構築します。

    5. リプレイが終了し、ランタイム・モードに戻ります。

    6. 最後にキューに入れられたコールを発行します。

      これは、停止が検出されたときに実行された最後のコールです。リプレイ時には、このコールのみがCOMMITを実行できます。セッションの再構築の途中でCOMMITが行われると、リプレイは中断されます(自律型トランザクションは除く)。

  5. レスポンスがアプリケーションに戻されます。

    リプレイが成功した場合、アプリケーションは問題をマスクした状態で続行できます。失敗した場合、アプリケーションは元のエラーを処理する必要があります。

通信障害後のアプリケーション・コンティニュイティの動作は、関連するOracle製品およびテクノロジによって異なります。次に例を示します。

  • Oracle RACまたはOracle Active Data Guardファームを使用している場合、実行中の別のインスタンスで接続が再確立された後、アプリケーション・コンティニュイティはセッションを再構築し、最後のトランザクション(進行中のものがある場合)をリプレイしようとします。

  • Oracle Active Data Guardを使用し、スタンバイ・サイトにフェイルオーバーする場合、アプリケーション・コンティニュイティはフェイルオーバー・インスタンスに接続し、セッションを再構築し、最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。(Oracle Active Data Guardスイッチオーバーおよびフェイルオーバーによってデータが失われ、これがラグが承認されたOracle Active Data Guardリーダー・ファームでない場合、アプリケーション・コンティニュイティはリプレイしません)。

  • Oracle RACまたはOracle RAC One Nodeを使用していて、Oracle Active Data Guardは使用していない場合、停止が原因ですべてのパブリック・ネットワークが中断されるか、データベースまたはデータベース・セッションがしばらくの間停止すると、アプリケーション・コンティニュイティは、セッションを再構築し、接続がリストアされた後にデータベースに対して最後のトランザクション(トランザクションが進行中であった場合)をリプレイしようとします。

  • 個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。

関連項目

親トピック: アプリケーション・コンティニュイティの理解

6.1.4 アプリケーション・コンティニュイティの潜在的な副作用

サービス属性FAILOVER_TYPEをTRANSACTIONに設定してアプリケーション・コンティニュイティを使用する場合、副作用を残す文がリプレイされます。

注意:

アプリケーション所有者として、繰り返す必要のない副作用が含まれるリクエストのリプレイを無効にすることを選択できます。副作用を無効にする最も簡単な方法は、透過的アプリケーション・コンティニュイティ(サービス属性FAILOVER_TYPEをAUTOに設定)を使用することです。これにより、副作用が無効になります。

アプリケーション・コンティニュイティは、データベース状態をリストアするためにPL/SQLを時間の経過順にリプレイします。これは、ユーザーによる発行が遅延されたものとしてセッションを再構築する上で役立ちます。ほとんどのアプリケーションは、レポートの作成や監査の完了など、発行が繰り返されたものとして完全な状態を再構築することを必要とします。ただし、状態を構築するためにリプレイされるアクションには、リプレイの影響に対応したりこの影響を軽減するためのアクションが必要なものもあります。一部のアプリケーションでは、繰り返す必要のないコールが含まれるリクエストのリプレイを無効化することを選択します。

副作用があるアクションの例は、次のとおりです。

  • DBMS_ALERTコール(電子メールまたは他の通知)

  • DBMS_FILE_TRANSFERコール(ファイルのコピー)

  • DBMS_PIPEおよびRPCコール(外部ソース向け)

  • UTL_FILEコール(テキスト・ファイルの作成)

  • UTL_HTTPコール(HTTPコールアウトの実行)

  • UTL_MAILコール(電子メールの送信)

  • UTL_SMTPコール(SMTPメッセージの送信)

  • UTL_TCPコール(TCPメッセージの送信)

  • UTL_URLコール(URLへのアクセス)

外部アクション(自律型トランザクションやUTL_HTTPによるサービス指向アプリケーション(SOA)のコールの発行など)を伴うアプリケーションの場合、アプリケーションが外部アクションのリプレイ(電子メールの再送信、監査、およびファイルの転送など)によって満たされるときに、アプリケーション・コンティニュイティは透過的になります。

関連項目

親トピック: アプリケーション・コンティニュイティの理解

6.1.5 Oracle Application Continuityおよび透過的アプリケーション・コンティニュイティのサポート

アプリケーション・コンティニュイティのサポートは、多くのOracleアプリケーションに統合されています。

アプリケーション・コンティニュイティは、次のOracleテクノロジを使用した一般的な用途で使用できます。

  • ODP.NET、管理対象外ドライバ12.2以降
  • OCIセッション・プール12.2以降
  • ユニバーサル接続プール12.1以降
  • Oracle WebLogic Server 12c
  • JDBC Thin Oracleリプレイ・ドライバ12.1以降
  • Java接続プールまたはスタンドアロンJavaアプリケーション(Oracle JDBC - Replay Driver 12c以降をリクエスト境界で使用)
  • SQL*Plus 19.3以降
  • ユニバーサル接続プールを使用したサード・パーティのJDBCアプリケーション・サーバー

透過的アプリケーション・コンティニュイティは、次のOracleテクノロジとともに一般的な用途で使用できます。

  • Oracle Call Interface (OCI)およびOracle C++ Call Interface (OCCI)
  • ODP.NET、管理対象外ドライバ12.2以降
  • Oracle Tuxedo 19.3以降
  • OCIセッション・プール12.2以降
  • SQL*Plus 19.3以降
  • Oracle JDBC OCIドライバ(Thickドライバは一般に非推奨)

Javaのアプリケーション・コンティニュイティは、ユニバーサル接続プール、WebLogicデータ・ソース(非XAおよびXAデータ・ソースを含む)に埋め込まれています。また、JDBC Thinリプレイ・ドライバ単独(Apache TomcatやカスタムのJava接続プールなど、Oracle接続プールなしのJDBCリプレイ・ドライバ)で使用できます。OCIのアプリケーション・コンティニュイティは、SQL*Plus、OCIセッション・プール12.2以降およびODP.NET Unmanaged Providerに埋め込まれています。透過的アプリケーション・コンティニュイティを使用すると、Oracle Database 18c以降ではJDBCアプリケーション、およびOracle Database 19c (19.3)以降ではOCIアプリケーションが自動的に有効になります。

接続プールまたはコンテナがOracle接続プールを使用しない場合、多くのサード・パーティのJavaアプリケーションは、ユニバーサル接続プールによる接続プールの置換を完全にサポートしています。これには、IBM WebSphereとApache Tomcatが含まれます。また、アプリケーションは独自のリクエスト境界を追加できます(Javaの場合のみ)。

リクエスト境界

Oracle Databaseリリース12.1.以降、リクエスト境界はOracle接続プールに埋め込まれています。リクエスト境界は、JDK9以降の標準であるサード・パーティJavaアプリケーション・サーバーにも埋め込まれています。Oracle接続プールを使用すると、各リプレイのサイズを定めるリクエスト境界がチェックアウト時およびチェックイン時に暗黙的にマークされます。サード・パーティ接続プールを使用する際は、UCPを使用する(Javaの場合)か、透過的アプリケーション・コンティニュイティを使用するか、リクエスト境界を追加するか、JDK9以降の標準であるサード・パーティのJavaアプリケーション・サーバーを使用します。リクエスト境界は、透過的アプリケーション・コンティニュイティの使用時に状態追跡を使用して検出されます。この機能は、Oracle Database 18c Javaリプレイ・ドライバおよびOracle Database 19c OCIドライバ(オープン・ソースとODBCを含む)以降で使用できます。

注意:

Oracle Database 18cのみ: Javaには初期beginRequestが必要になります。これは、最新バージョンのJavaリプレイ・ドライバを使用しているときには不要です。

関連項目

親トピック: アプリケーション・コンティニュイティの理解

6.1.6 アプリケーション・コンティニュイティに関する制限および他の考慮事項

アプリケーション・コンティニュイティを使用するときには、次の制限事項と考慮事項に注意してください。

アプリケーション・コンティニュイティは次のものを除外します。
  • JDBC OCIドライバ(タイプ2)
  • ODP.NET管理対象ドライバ
  • OLE DB
  • ODBC

Oracle Database 12cリリース2 (12.2.0.1)のOCIおよびODP.NETの場合、OCIドライバのアプリケーション・コンティニュイティは、ADT、拡張キューおよび一部のLOB APIを除外します。このような除外は、Javaには適用されません。

JDBCを使用するアプリケーションの場合、oracle.sqlの非推奨具象クラスOPAQUE、ANYDATAまたはSTRUCTはサポートされません。

アプリケーション・サーバー・レベルの文キャッシュが有効な場合(WebLogicやサードパーティのアプリケーション・サーバーの文キャッシュなど)、このキャッシュはリプレイの使用時に無効にする必要があります。かわりに、JDBC文キャッシュを構成します。このキャッシュはアプリケーション・コンティニュイティをサポートしていて、JDBCおよびOracle Databaseに向けて最適化されています(oracle.jdbc.implicitstatementcachesize=nnn)。

トランザクションのリプレイが発生する可能性があるときに、次の制限事項が関連する点に注意してください。

  • Oracle Database 12リリース2 (12.2)以降、JavaおよびODP.NET管理対象外ドライバのXAデータ・ソースでリプレイがサポートされています。リプレイは、ローカル・トランザクションをサポートします。2フェーズを使用すると、リプレイはサイレントに無効化されます。これにより、アプリケーション・コンティニュイティは、昇格可能なXAおよびXAデータ・ソースを使用するアプリケーションと、XAを使用しないほとんどのアプリケーションをサポートできるようになります。

    リクエストで2フェーズ・コミットXAを使用する場合、Oracle Database 12cリリース2 (12.2)以降では、アプリケーション・コンティニュイティは昇格可能なXAでサポートされ、XAが使用されていないときにXAデータ・ソースを使用します。

  • リクエストがALTER SYSTEM文またはALTER DATABASE文を発行すると、リプレイは無効になります。

  • リプレイは、セッションを再構築するのに安全でないとみなされているALTER SESSION文のリクエスト・レベルでは無効化されています。これには、サポート・レベルのイベントを設定する文が含まれ、COMMIT IN PROCEDUREおよびGUARDを有効化および無効化します。

    ただし、アプリケーション・レベルでのALTER SESSION文がリプレイでサポートされています。これらには、グローバリゼーション・サポート(NLS)設定の文、格納されているプライベートの概要、コンテナ(CDB/PDB)の設定、SQLトレースおよびPL/SQL警告が含まれます。

  • リプレイのターゲット・データベースは、ソース・データベースと同じデータベース・クラスタ(Oracle RAC、Oracle Data Guard、Oracle Active Data Guard、またはOracle Multitenant)に存在している必要があります。ビジネス・トランザクションの整合性を保護するため、ターゲットが別のデータベースになる場合、アプリケーション・コンティニュイティはリプレイを実行しません。ターゲット・データベースがソース・データベース(またはプラガブル・データベース)と同じであっても、データベースがフラッシュ・バックされていたり、メディア・リカバリによって不完全にリカバリされていたり、Oracle Data Guardによって以前の時点でオープンされていたりするなどでデータが失われている場合、アプリケーション・コンティニュイティはリプレイを実行しません。

  • ストリーム引数の場合、リプレイはベスト・エフォート・ベースです。たとえば、アプリケーションが物理アドレスを使用している場合、アドレスは停止によって失われると、再配置できなくなります。たとえば、JDBCストリーム・セッター(setBinaryStreamなど)によってリプレイが無効になります。

  • プライマリ・データベースに戻る読取り/書込みデータベース・リンクを使用してOracle Active Data Guardを使用している場合、リプレイはサポートされません。これはトランザクション・ガードのセキュリティ制限です。

  • パラレル問合せコールの失敗の場合、これが文レベルの失敗であるときにはリプレイは開始されません。たとえば、インスタンスやノードの障害またはメモリーの問題で発生したコール失敗に対するORA-12805:parallel query server died unexpectedlyの後には、リプレイは行われません。

  • リプレイはJavaのDRCPをサポートしません。専用サーバーと共有サーバーはサポートされます。

注意:

データベースのクローンを作成するために、ディスク・イメージ(BCVなど)を分割する場合や、物理またはOracle Active Data Guardデータベースではないロジカル・スタンバイまたはロジカル・コピーを作成するために別のデータベースになるようにデータベースをクローニングする場合は、データベースを区別するためにnidユーティリティを使用してDBIDを変更する必要があります。

関連項目

親トピック: アプリケーション・コンティニュイティの理解

6.2 透過的アプリケーション・コンティニュイティ

データベースの計画メンテナンスおよび計画外停止が透過的な場合、アプリケーションでは継続的な可用性を実現します。

親トピック: アプリケーション・コンティニュイティの確保

6.2.1 透過的アプリケーション・コンティニュイティについて

透過的アプリケーション・コンティニュイティは、Oracle Databaseリリース18cのOracle Real Application Clusters (Oracle RAC)に導入されたアプリケーション・コンティニュイティの機能モードであり、セッションおよびトランザクションの状態を透過的に追跡および記録して、リカバリ可能な停止後にデータベース・セッションをリカバリできるようにします。

ユーザー・データベース・セッションのリカバリは安全に実行され、DBAはアプリケーションについて理解したり、アプリケーション・コードを変更したりする必要がありません。アプリケーションがユーザー・コールを発行したときに、セッション状態の使用を分類する状態追跡インフラストラクチャを使用することにより、透過性を実現します。

FAILOVER_TYPE=AUTOの場合、透過的アプリケーション・コンティニュイティは有効になります。

透過的アプリケーション・コンティニュイティを有効にすると、計画メンテナンス時および計画外停止が発生したときにアプリケーションを保護できます。計画メンテナンスの場合、安全な場所(接続テストまたは既知のリカバリ可能ポイントなど)に到達するデータベース・セッションは、データベースで排出されます。排出されないデータベース・セッションの場合、データベースではデータベース・セッションをフェイルオーバーする場所を決定し、アプリケーション・コンティニュイティを起動してこれを実行します。アプリケーション・コンティニュイティは、ユニバーサル接続プールを使用して、Javaベースのアプリケーション、OCIおよびODP.NETアプリケーション(SQL*Plus、すべてのOracle接続プール、Tuxedo、WebLogic Serverおよびサード・パーティのアプリケーション・サーバーを含む)の計画外停止が認識されないようにします。

計画外停止の場合、透過的アプリケーション・コンティニュイティはリカバリ可能なエラー(通常、基盤となるソフトウェア、フォアグラウンド、ハードウェア、通信、ネットワークまたはストレージ・レイヤーに関連)が発生する停止に対して起動され、アプリケーションおよびユーザーにはほとんどの障害が認識されません。

透過的アプリケーション・コンティニュイティを使用すると、DBAはアプリケーションの知識がなくても次のことを実現できます。

  • 事前設定された状態のリストア: 実行時に、透過的アプリケーション・コンティニュイティは、初期の事前設定されたセッション状態を記録し、さらに状態を監視し、監視対象の状態がフェイルオーバー時にセッション状態を逸脱したことを検出できるセッションの痕跡を記録します。フェイルオーバー時に、透過的アプリケーション・コンティニュイティは事前設定されたセッション状態をリプレイの開始前にリストアし、これらのセッション状態がリプレイの開始前の元の状態と完全に一致することを検証します。これは、アプリケーション・コンティニュイティおよびその他のメカニズム(ログオン・トリガー、ラベル、接続コールバックなど)の両方を使用してリストアされたセッション状態も対象となります。状態が事前設定された状態の外側にある場合は、ログオン・トリガー、コールバックまたはラベルを引き続き追加します。

  • セッションのリカバリ時にアプリケーション・レベルの副作用を認識して無効にします。透過的アプリケーション・コンティニュイティでは、クライアントからのトランザクションおよびセッションの状態を記録して(これをキャプチャと呼びます)、リプレイを有効にします。通常の実行時に、透過的アプリケーション・コンティニュイティでは、副作用、またはトランザクションの結果として発生するがトランザクション自体の一部ではない変更を検出します。副作用のタイプは、アプリケーションのロジックに関するものとデータベース・ハウスキーピングに関する内部的なもので区別されています。副作用を含む文を使用するアプリケーションの場合、文を実行しているときの取得は無効になっています。新しいリクエストが開始されると、取得は自動的に再度有効になります。

  • 所有関数の可変値を保持する: 可変関数は実行のたびに新しい値を返す関数です。可変関数SYSDATE、SYSTIMESTAMP、SYS_GUID、sequence.NEXTVALの元の結果を保持するためのサポートが提供されています。元の値が保持されていない場合、および異なる値がリプレイ時にアプリケーションに返された場合、透過的アプリケーション・コンティニュイティはリプレイを拒否します。権限を使用して順序、日付および時間を保持します。アプリケーションが独自のスキーマを使用している場合、保持するための権限をロールに割り当てると、このロールをユーザーに付与できます。

  • リクエスト境界について理解する: リクエスト境界は、アプリケーションとアプリケーション・サーバーが接続プールから接続を流用して返却する場所を決定します。JDBC Thinドライバ(Oracle Database 18c以降)、OCIおよびODP.NET Unmanaged Provider (Oracle Database 19cリリース19.3以降)でアプリケーション・コンティニュイティを使用するアプリケーションの場合、DBAはリクエスト境界について知る必要はありませんが、リクエスト境界の使用時には透過的アプリケーション・コンティニュイティによってリクエスト境界が利用されます。ベスト・プラクティスとして、データベースでリクエスト境界を挿入できるチェックポイントを識別できるとは限らないため、アプリケーションでは明確に線引きされたリクエスト境界を使用します。

    透過的アプリケーション・コンティニュイティにより、サーバーおよびドライバはトランザクションとセッションの状態の使用状況を追跡しています。これにより、ドライバは暗黙的なリクエスト境界を検出できます。暗黙的な境界の場合、オブジェクトはオープンされておらず、カーソルは文キャッシュに戻されている必要があり、トランザクションがアクティブでなく、セッションの状態は完全にリストア可能と認識されている必要があります。ドライバは、現在追跡されている情報を破棄してこの時点から再度追跡を開始するか、無効化イベントが発生している場合は追跡を再度有効にします。サーバーへの次回コール時にサーバーが検証され、必要に応じて、以前に明示的な境界が存在しなかったリクエスト境界が作成されます。

親トピック: 透過的アプリケーション・コンティニュイティ

6.2.2 Oracle Cloud環境での透過的アプリケーション・コンティニュイティの使用

Oracle Autonomous Database (専用)のOracle Database 19c以降のOracle Cloud環境では、透過的アプリケーション・コンティニュイティがデフォルトで有効化されていて、Oracle Autonomous Database (サーバーレス) 19cで使用できます。

Oracle Cloud環境では、FAILOVER_RESTOREとウォレットを使用すると、初期状態を設定するためのコールバックの追加が必要になります。これは、12.2より前のOracle Databaseリリースの透過的アプリケーション・フェイルオーバー(TAF)とアプリケーション・コンティニュイティに必要なことでした。

自動的に透過的アプリケーション・コンティニュイティを有効化するために、2つの機能が連携します。

  • 計画済の停止の場合、トランザクションにとって安全な場所に到達したセッションはインスタンスから排出され、自動的に別のインスタンスにフェイルオーバーされます。排出しないセッションの場合、Oracle Databaseはセッションのフェイルオーバー先を決定し、セッションをフェイルオーバーするためにアプリケーション・コンティニュイティを起動します。
  • 計画外停止の場合、ユーザー・セッションは透過的アプリケーション・コンティニュイティによって自動的に正常に稼働しているインスタンスに転送されます。ユーザーが停止を認識することはありません。そのためのアプリケーションの知識や変更は不要です。

親トピック: 透過的アプリケーション・コンティニュイティ

6.2.3 様々なアプリケーションの場合の透過的アプリケーション・コンティニュイティ

透過的アプリケーション・コンティニュイティは、自動的に状態追跡システムによって追跡される3つの異なるグループに属するアプリケーションに対応しています。

親トピック: 透過的アプリケーション・コンティニュイティ

6.2.3.1 リクエスト境界があるコンテナを使用するアプリケーション

リクエスト境界があるコンテナを使用するアプリケーションでは、アプリケーション・コンティニュイティで明示的な境界間のリプレイを管理できます。

リクエスト境界はデータベース・リクエストの開始と終了をマークするタグです。Oracle Database 12cリリース2 (12.2.0.1)以降、リクエスト境界を埋め込んだ接続プールには、Oracle Universal Connection Pool、すべてのWebLogic Serverデータ・ソース、Tuxedo、Oracle Call Interface、ODP.NET Unmanaged Providerおよび標準のサード・パーティのアプリケーション・サーバーとスタンドアロンのJavaプールがあり、これらはJDBCドライバのPooledConnectionインタフェースおよびSQL*Plusを使用します。

Oracle Databaseがリクエスト境界を認識した場合、次のようになります。

  • データベースは、接続をアタッチおよび解放する際など、パフォーマンス・オーバーヘッドがなく、効率的にWebリクエストを処理できます。リクエスト内の複雑な状態を多重化、排出、リバランス、削減および許可できます。リクエスト境界を使用しない場合、データベースの下位のレイヤーは、Webリクエストを認識しません。そのため、データベースはOracleクライアントのアクション、高速接続フェイルオーバーなどのアドバイザ・メソッドとヒューリスティック、接続検証および状態のアドバイスに依存します。

  • リプレイの長さは初期状態に制限された後、リクエスト内のユーザー・コールはアプリケーション・コンティニュイティによってパージされるものより短くなります。リクエスト境界を使用すると、リプレイの長さを制御できます。また、計画メンテナンスでの排出場所(リクエストの終了時)および計画メンテナンスでのフェイルオーバーの場所(リクエストの開始時)を決定できます。

  • JavaおよびOracle Database 18cのみで透過的アプリケーション・コンティニュイティを使用する場合: Javaでは初期のbeginRequest (最初のリクエスト境界についてのみ)が必要です。これは、最新のバージョンでは不要です。

  • アプリケーション・コンティニュイティをJavaで使用する場合は、リプレイ・ドライバが安全な場所を検出して自動的にリクエスト境界を移動します。この機能は、session_state_consistencyをAUTOに設定した場合にのみ使用できます。

  • リクエスト境界を設定する中間層コンテナを使用してデプロイされたアプリケーションは、データベース・サーバーが提供する透過性機能の完全なセットにアクセスできます。データベースはクライアントがリクエスト境界を設定するタイミングを検出し、境界を使用して排出、フェイルオーバー、集中およびスループットの測定のための安全な場所をマークします。

リクエスト境界により、アプリケーションはすべての複雑な非トランザクション・セッション状態をリクエスト内で使用できます。リクエスト境界の仕様では、これらの状態が境界を超えて依存しないことが必要です。

6.2.3.2 データベースに依存しないアプリケーション

データベースに依存しないアプリケーションでは、接続の確立時に状態を設定し、非トランザクション・セッションの状態を再度変更することはありません(ごくまれに変更します)。

データベースに依存しないアプリケーション(リクエスト境界のないアプリケーション)では、単純な非トランザクション状態を設定します。このようなアプリケーションは、Oracle Database固有の機能や順序を使用しません。これらのアプリケーションの場合、アプリケーション・コンティニュイティは暗黙的な境界を指定します。これらのアプリケーションは通常、接続が作成されたときに一度状態を設定し、その後、状態を再度変更することはありません(ごくまれに変更します)。このカテゴリのアプリケーションには、サーバー側のセッション状態を作成しない匿名のPL/SQLを使用するアプリケーションが含まれます。

Oracle Database 19.3以降で透過的アプリケーション・コンティニュイティを使用する場合は、明示的なリクエスト境界は必要ありません。(Oracle Database 18cのみ: Javaには初期のbeginRequestが必要になります。)これにより、SQL*Plusとサード・パーティの接続プールのサポートが可能になります。明示的なリクエスト境界がある場合は、そのリクエスト境界が使用されます。アプリケーション・コンティニュイティには、明示的なリクエスト境界が引き続き必要です。

6.2.3.3 ブラック・ボックス・アプリケーション

ブラック・ボックス・アプリケーションとは、実行時にOracle Database固有の状態を使用するか、状態を変更する(あるいはその両方を実行する)アプリケーションです。

ブラック・ボックス・アプリケーションには次の2種類があります。

  • 表示可能な境界のないOLTPなどの短いユーザー・コールが含まれたアプリケーション
  • DSS、レポートやウェアハウスなどの長いユーザー・コールが含まれたアプリケーション

6.3 高速アプリケーション通知(FAN)

Oracle RAC高可用性フレームワークは、データベースとそのサービスを監視し、高速アプリケーション通知(FAN)を使用してイベント通知を送信します。

Oracle Databaseでは、最も高いサービス可用性の保持に焦点を当てています。Oracle Real Application Clusters (Oracle RAC)のサービスは、1つ以上のインスタンス間でロードを共有しながら、継続的に使用できるように設計されています。Oracle RACの高可用性フレームワークでは、Oracle Clusterwareとリソース・プロファイルを使用して、サービスの可用性を維持します。Oracle Clusterwareは、ビジネス・ルールとサービス属性に従って、サービスをリカバリするか、サービスを均等に分散します。

  • 高速アプリケーション通知(FAN)の概要
    FANは、データベース、ノードおよびネットワークに関連する停止後に、クライアントの即時割込みを実現します。
  • 高速アプリケーション通知の使用の重要性
    高速アプリケーション通知(FAN)イベントを使用すると、TCPタイムアウトを待機しているアプリケーション、障害の発生後にクライアントで最後の結果を処理するという時間の浪費、および低速なノード、停止したノードまたは使用不能なノードで作業を実行するという無駄な時間が排除されます。
  • Oracle DatabaseおよびApplicationsでのFANの使用方法
    高速アプリケーション通知(FAN)は、TCP/IPタイムアウトでアプリケーションがハングしないようにするために不可欠です。
  • FANを使用するための要件
    Oracle Real Application Clusters (Oracle RAC)データベースに接続するクライアント・ドライバで、FAN対応機能を利用するために実行が必要なことについて説明します。
  • FANコールアウト
    高速アプリケーション通知(FAN)コールアウトは、サーバー側スクリプトであるか、またはFANイベントが生成されると必ず実行される実行可能ファイルです。
  • 高速アプリケーション通知の高可用性イベント
    高速アプリケーション通知(FAN)イベントがコールアウト・プログラムに情報を配信する方法について説明します。
  • 高可用性イベントのサブスクリプション
    サービスに関するアプリケーションを監視および通知するために、Oracle Real Application Clusters (Oracle RAC)ではOracle RAC Fast Application Notification (FAN)を使用します。
  • 高速アプリケーション通知のコールアウトの使用方法
    高速アプリケーション通知(FAN)コールアウトは、高可用性イベントが発生したときにOracle RACで即座に実行されるサーバー側の実行可能ファイルです。

親トピック: アプリケーション・コンティニュイティの確保

6.3.1 高速アプリケーション通知(FAN)の概要

FANは、データベース、ノードおよびネットワークに関連する停止後に、クライアントの即時割込みを実現します。

FANは、障害直後のTCP/IPタイムアウトからクライアントを解放するために欠かせないものです。FANは、リソースが使用可能になると即座にクライアントに通知して、クライアントが計画メンテナンス中の停止を認識しないようにデータベース・セッションの排出を開始します。また、FANには構成レベルの情報とサービス・レベルの情報の通知も含まれています。この情報には、サービス・ステータスの変化が含まれます。

Oracleクライアント・ドライバおよびOracle Real Application Clusters (Oracle RAC)接続プールは、FANイベントに応答し、ただちに処理します。FANのUPイベントとDOWNイベントは、サービス、データベース、インスタンス、ネットワークおよびノードに適用されます。

関連項目

親トピック: 高速アプリケーション通知(FAN)

6.3.2 高速アプリケーション通知の使用の重要性

高速アプリケーション通知(FAN)イベントを使用すると、TCPタイムアウトを待機しているアプリケーション、障害の発生後にクライアントで最後の結果を処理するという時間の浪費、および低速なノード、停止したノードまたは使用不能なノードで作業を実行するという無駄な時間が排除されます。

アプリケーションは、次のような重要な局面で時間を浪費する可能性があります。

  • ソケットをクローズしないでノードが失敗した場合のTCP/IPタイムアウトの待機、およびそのIPアドレスが停止している間の後続のすべての接続の待機。
  • サービスが停止した場合の接続の試行。
  • サービス再開時に接続しない。
  • サーバーが停止したときのクライアントでの最後の結果の処理。
  • 最適でないノードで作業を実行しようとする。

ソケットをクローズしないでノードが失敗した場合、I/O待機(読取りまたは書込み)でブロックされたすべてのセッションはtcp_keepaliveを待機します。この待機ステータスは、ソケットで接続されているアプリケーションの場合の典型的な状況です。最後の結果を処理するセッションの状況はさらに悪く、次のデータが要求されるまで割り込みを受信しません。

親トピック: 高速アプリケーション通知(FAN)

6.3.3 Oracle DatabaseおよびApplicationsでのFANの使用方法

高速アプリケーション通知(FAN)は、TCP/IPタイムアウトでアプリケーションがハングしないようにするために不可欠です。

FANイベントは、Oracle Database 12.2以降のOracle通知サービスを使用して発行されます。アドバンスト・キューイングは、古いOracle Call Interface (OCI)アプリケーション(12.2より前のOCIドライバ)の場合にのみFANイベントに使用されます。発行メカニズムは、Oracle RACのインストール時に自動的に構成されます。クライアントがFANイベントを受信できるようにするには、それぞれのクライアントに特定の設定が必要です。

  • OCIクライアントの場合は、サーバーでサービス属性notificationを設定する必要があります。たとえば、srvctl modify service -db EMEA -service GOLD -notification TRUEのようにします。また、OCIクライアントの場合は、oraaccess.xml構成ファイルでeventsをTRUEに設定する必要もあります。
  • ODP .Netクライアントの場合は、接続文字列のoraaccess.xmlでHA eventsをTRUEに設定する必要があります。
  • ユニバーサル接続プール・クライアントの場合、プール・プロパティの高速接続フェイルオーバーをtrueに設定します(setFastConnectionFailoverEnabled(true))。

すべてのクライアントはONSの自動構成を使用してイベントを受信できるようになりますが、そうしたイベントに反応するようにクライアントを設定する必要はあります。

Oracle Net Servicesリスナーおよびグローバル・データ・サービス(GDS)は、FANイベントと統合されていることによって、リスナーおよびGDSは、障害が発生したインスタンスによって提供されているサービスを即座に登録解除でき、また、障害が発生したインスタンスに対する誤った接続リクエストの送信を回避できます。

Oracle接続プールは、FANを使用して、障害についての非常に高速な通知を受信し、障害後の接続を均等に分散します。障害が発生したコンポーネントが修復されると、接続を再度均等に分散します。そのために、Oracle Databaseインスタンスに接続するサービスが開始されると、接続プールはFANイベントを使用してそのリソースに作業を即座にルーティングします。データベース・インスタンスまたはノードのサービスが失敗すると、接続プールはFANイベントを使用して、リカバリのためにアプリケーションを即座に中断します。

クラスタの構成が変更されて、クラスタ内で状態の変更が発生した場合、Oracle Real Application Clusters (Oracle RAC)の高可用性フレームワークは、ただちにFANイベントを発行します。アプリケーションは、データベースに対するタイムアウトおよび問題の検出を待たずに、FANイベントを受信して即時に対応できます。FANを使用すると、インフライト・トランザクションがただちに終了し、インスタンスの失敗時にクライアントに通知されます。

また、FANは、 ロード・バランシング・アドバイザ・イベントも発行します。アプリケーションでFANのロード・バランシング・アドバイザ・イベントを使用して、現在、クラスタ内で最適なサービス品質を提供しているインスタンスに作業要求を割り当てることができます。

データベース・サービスの接続ロード・バランシングの目標にCLB_GOAL_SHORTを指定している場合、リスナーは接続ロードを均等に分散するときにロード・バランシング・アドバイザを使用します。ロード・バランシング・アドバイザが使用可能であった場合、リスナーで使用されるメトリックはさらに詳細に制御できます。

FANイベントは、次の方法で利用できます。

  • Oracle統合クライアントを使用すると、プログラムを変更することなくアプリケーションでFANを使用できます。FANイベント用の統合クライアントには、Oracle JDBC Universal Connection Pool、ODP.NET接続プール、OCIセッション・プール、Oracle WebLogic Server Active Gridlink for Oracle RAC、OCIおよびODP.NETクライアントがあります。FANの高可用性イベントを活用するには、統合OracleクライアントがOracle Database 10gリリース2 (10.2)以上である必要があります。プール・クライアントは、ロード・バランシング・アドバイザFANイベントを活用することもできます。

  • サード・パーティ製アプリケーション・コンテナ(Apache TomcatやWebSphereなどのコンテナ)は、デフォルトのプールのかわりにユニバーサル接続プール使用することで提供される組込みのFANサポートを使用するように構成できます。ユニバーサル接続プールは、Apache TomcatやWebSphereなどのサード・パーティ製Javaアプリケーション・サーバーの接続プールとして動作保証されています。

  • サード・パーティ製アプリケーション・サーバーまたはカスタム・アプリケーションで使用中のサード・パーティ製接続プールからのgetまたはreleaseの接続を標準インタフェースを使用してテストするために、OracleドライバのFAN対応機能を使用します。

    • このソリューションは、標準のTNS接続文字列の使用と、アプリケーションのCLASSPATHでons.jarファイルとsimpleFAN.jarファイルが使用できるようにすることで、標準のJavaアプリケーションに適用されます。

    • OCI/OCCIドライバの場合、OCI_ATTR_SERVER_STATUSサーバー・コンテキスト・ハンドル属性はFANイベントに依存し、接続がFANイベントの影響を受けている場合には、OCI_SERVER_NOT_CONNECTEDを返します。

  • サーバー側のコールアウトを使用して、データベース層にFANを実装できます。

  • JDBCおよびOracle RAC FANアプリケーション・プログラミング・インタフェース(API)を使用するか、OCIおよびODP.NETとともにコールバックを使用してFANイベントをサブスクライブし、イベントの受信時にイベント処理アクションを実行することで、アプリケーションはFANをプログラムで使用できます。

計画メンテナンスの際にアプリケーションがOCIまたはPro*プリコンパイラを使用している(OCIセッション・プールまたはTuxedoを使用していない)場合、アプリケーションはOCI_ATTR_SERVER_STATUSをチェックする必要があります。このチェックは、独自の接続プールにセッションが返されたときに追加します。また、アイドル接続に対しては定期的に、このチェックを追加します。計画メンテナンスによるFANのDOWNイベント後、この属性はOCI_SERVER_NOT_CONNECTEDに設定されます。アプリケーションは、この切断ステータスを読み取ると接続を閉じます。セッションは、アクティブな作業の排出のために、アプリケーションが閉じるまで開かれたままになります。これにより、エラーの発生しないフェールオーバーを実現します。

前述のリストの最初の項目に示されている統合クライアントのいずれかを使用すると、DOWNイベントの場合、FAN対応クライアントが失敗したインスタンスまたはノードへの接続をそれらが再使用される前に終了するため、アプリケーションの停止が最小限になります。アクティブな作業は、完了できるようになり、稼働を続けるインスタンスがある場合は、進行中の作業のためにサービスの継続が維持されます。インスタンスまたはサービスの停止時にアクティブなセッションは停止され、アプリケーション・ユーザーに即座に通知されます。未完了のトランザクションは、アプリケーション・コンティニュイティによって保護されます(有効化されている場合)。接続を要求しているアプリケーション・ユーザーは、使用可能インスタンスにのみ割り当てられます。

UPイベントでは、データベース・サービスおよびインスタンスが起動されている場合、アプリケーションが追加のハードウェア・リソースまたは追加容量を即時に利用できるように、新しい接続が作成されます。

親トピック: 高速アプリケーション通知(FAN)

6.3.4 FANを使用するための要件

Oracle Real Application Clusters (Oracle RAC)データベースに接続するクライアント・ドライバで、FAN対応機能を利用するために実行が必要なことについて説明します。

Oracle Database 12cリリース2 (12.2)以降のリリースのクライアント・ドライバはFAN対応であり、FANはデフォルトで有効になっています。これは、JDBC Thinドライバ(12.2.0.1以降)およびOracle Data Provider for Net (ODP.NET)ドライバについても当てはまります。クライアント・ドライバは、計画および計画外のFANイベントを検出して、アプリケーションの下でアクションを実行できます。

ドライバでFAN対応機能を利用するには、次が必要になります。

  • Java Thinドライバの場合、リリース12.2以降のFANは、CLASSPATHにons.jarファイルとsimpleFAN.jarファイルを配置して、推奨されるTNSフォーマットを使用すると自動的に有効になります。推奨されるTNSフォーマットを使用して、自動的にONSを構成します。また、Java Thinドライバでは、計画イベントと計画外イベントの両方でFANがサポートされます。計画外停止の場合、FAN割込みが即時に発生します。計画メンテナンスの場合、Javaアプリケーション・サーバーまたはカスタム・プールを構成して、サード・パーティ製接続プールからのgetまたはreleaseの接続をテストするために標準インタフェースを使用します。たとえば、アプリケーション・サーバーに応じて、TestConnectionsOnReserve、TestOnBorrowまたはPreTest接続をテストします。

    このアプローチでは、計画メンテナンス中にFANイベントが受信されると、この時点ではアプリケーションにデータベースへの接続がないため、高速接続フェイルオーバー(FCF)がセッションを閉じて(セッションがテストされている場合)、新しい接続の再試行が可能になります。接続テストには、isValid、isClosed、isUsableまたはPingDatabaseが使用できます。

  • SQLコマンドの実行時、データベースは接続を排出します(次回の計画メンテナンスで影響を受ける場合)。接続プール、データソース、およびカスタマ・アプリケーション(プログラムの場合)のすべては、SQLコマンドの実行時に発生する回復可能なエラー(多くの場合、物理接続を閉じるエラー)を管理できるようにしておく必要があります。

  • サード・パーティのJavaアプリケーション・サーバーとJavaアプリケーションは、接続プールの開発時にPooledConnection標準インタフェースを使用できます。

  • Oracle Call Interface OCI/OCCIドライバの11.2.0.3リリース以降、OCI_ATTR_SERVER_STATUSサーバー・コンテキスト・ハンドル属性がOCI_SERVER_NOT_CONNECTEDを返すときには、アプリケーションは接続を終了する必要があります。計画メンテナンスの場合は作業が排出されます。ドライバの12.2.0.1以降のリリースでは、計画DOWNイベントを受信したときに、OCISessionReleaseおよびOCIRequestEndを検出することもできます。

親トピック: 高速アプリケーション通知(FAN)

6.3.5 FANコールアウト

高速アプリケーション通知(FAN)コールアウトは、サーバー側スクリプトであるか、またはFANイベントが生成されると必ず実行される実行可能ファイルです。

次に示すように、様々な目的のコールアウトを設計して作成できます。

  • ステータス情報のログへの記録
  • リソースの起動に失敗した場合に、DBAへの通知またはサポート・チケットの発行を行います。
  • サービスと同じ場所に配置する必要がある外部依存アプリケーションの自動的な起動
  • ノードの障害などによって、データベースに使用できるインスタンスの数が減少した場合、サービスを停止
  • -failbackパラメータが十分でない場合、優先インスタンスへのサービスのフェイルバックを自動化

親トピック: 高速アプリケーション通知(FAN)

6.3.6 高速アプリケーション通知の高可用性イベント

高速アプリケーション通知(FAN)イベントがコールアウト・プログラムに情報を配信する方法について説明します。

次の例に示すように、コールアウトを介してFAN情報を受信した場合は、FANイベント・タイプが常に最初のエントリとして表示されます。

#service UP when CRS stack UP
SERVICEMEMBER VERSION=1.0 
   service=HRPDB1.example.com database=ractest 
   instance=ractest2 host=prod_host01_1 status=up reason=BOOT 
   card=1 timestamp=2019-10-24 09:11:51 timezone=+00:00 
   db_domain=example.com 
SERVICE VERSION=1.0
   service=HRPDB1.example.com database=ractest instance=ractest2 
   host=prod_host01_1 status=up reason=BOOT 
   timestamp=2019-10-24 09:11:51 timezone=+00:00 
   db_domain=example.com

#service DOWN 
SERVICEMEMBER VERSION=1.0 service=HRPDB1.example.com database=ractest
   instance=ractest2 host=prod_host01_1 status=down reason=USER 
   timestamp=2019-10-25 17:59:43 timezone=+00:00 db_domain=example.com 
   drain_timeout=120  
SERVICE VERSION=1.0 service=HRPDB1.example.com database=ractest 
   instance=ractest2 host=prod_host01_1 status=down reason=FAILURE 
   timestamp=2019-10-24 21:25:57 timezone=+00:00 db_domain=example.com

通常、前述の例は1行として表示される点に注意してください。

FANイベントのタイプは、次のとおりです。

  • DATABASE
  • INSTANCE
  • NODE
  • SERVICE
  • SERVICEMEMBER
  • SERVICEMETRICS

DATABASEとINSTANCEタイプは、デフォルト・データベース・サービスをDB_UNIQUE_NAMEとしてリストします。

NODEイベントを除くすべてのイベントにdb_domainフィールドが含まれています。

SERVICEMETRICSタイプのイベントは、ロード・バランシング・アドバイザのイベントです。

次の表では、イベント・パラメータの名前/値ペアについて説明し、ロード・バランシング・イベントに関する詳細を示します。

表6-1 イベント・パラメータの名前/値のペアと説明

パラメータ 説明
VERSION

イベント・レコードのバージョン。リリースの変更を識別するために使用されます。
database

サービスをサポートする一意のデータベース名。DB_UNIQUE_NAMEの初期化パラメータ値に該当し、これにより、DB_NAME初期化パラメータの値がデフォルトに設定されます。

instance

サービスをサポートするインスタンスの名前。
host

サービスをサポートしているノードまたは停止したノードの名前であり、Cluster Synchronization Services(CSS)で認識されるノード名と一致します。
service

サービス名。DBA_SERVICESでリストされているサービスの名前に一致し、適宜修飾されたドメインです。次の例を参照してください。 

SERVICEMEMBER VERSION=1.0 service=swingbench
 database=orcl instance=orcl_2 host=dev_host1 status=up
 reason=USER card=1 timestamp=2018-05-29 17:26:37
 timezone=-07:00 db_domain=

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
 database=orcl instance=orcl1 host=dev_host1 status=up
 reason=USER card=2 timestamp=2018-05-03 17:29:28
 timezone=-07:00 db_domain=example.com

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
 database=orcl instance=orcl2 host=dev_host1 status=up
 reason=USER card=1 timestamp=2018-07-03 17:29:18
 timezone=-07:00 db_domain=example.com
status

値は、UP、DOWN、NODEDOWN(これはNODEイベント・タイプにのみ適用される)、NOT_RESTARTINGおよびUNKNOWNです。

注意:

  • ノードが停止している場合、ステータスはNODEDOWNです。他のイベント・タイプの場合はDOWNです。

  • STATUS=NODEDOWNおよびREASON=MEMBER_LEAVEの場合、ノードに障害が発生しており、ノードはクラスタの一部ではないか、ユーザーがノードを停止しています。

  • STATUS=NODEDOWNおよびREASON=PUBLIC_NW_DOWNの場合、ノードは起動していますが、障害またはユーザー・アクションによりパブリック・ネットワークが停止しているため、ノードは使用不可です。

  • 複数のパブリック・ネットワークがOracle Clusterwareでサポートされています。FANイベントでは、この事実が反映されています。
reason

AUTOSTART、BOOT、DEPENDENCY、FAILURE、MEMBER_LEAVE、PUBLIC_NW_DOWN、USER。

注意:

  • DATABASEおよびSERVICEイベント・タイプの場合のREASON=AUTOSTARTは、ノードの起動時に、AUTO_STARTリソース属性がリストアに設定されており、ノードの起動前にリソースがオフラインであったことを示します。

  • DATABASEおよびSERVICEイベント・タイプの場合のREASON=BOOTは、ノードの起動時に、リソースがノードの起動前からオンラインであったためリソースが起動したことを示します。

  • SRVCTLおよびOracle Enterprise Manager操作の場合、REASON=USERはそのような操作の計画済アクションを作業の排出として記述します。

card (カーディナリティ)

現在アクティブなサービス・メンバーの数。すべてのSERVICEMEMBER UPイベントに含まれます。

SERVICEMEMBER UPイベントの例を次に示します。 

SERVICEMEMBER VERSION=1.0 service=swingbench.example.com
database=orcl instance=orcl_2 host=dev_host3 status=up reason=USER card=1
timestamp=2018-07-12 14:46:46  timezone=-07:00 db_domain=example.com
incarn (インカーネーション)

NODEDOWNイベント用の新しいクラスタ・インカネーション。この値は、メンバーがクラスタに参加したり、クラスタから離脱するたびに変更されます。

NODEDOWNイベントの例を次に示します。 

VERSION=1.0 event_type=NODE host=dev_host2 incarn=175615351 status=nodedown
reason=member_leave timestamp=2019-10-24 05:55:06 timezone=+00:00
timestamp

Oracle Clusterwareに基づく、イベントが発生した時間。
timezone

GMT +/-hh:mmとして指定され、イベントが発生した、Oracle Clusterwareのタイム・ゾーン。
drain_timeout

サービスが排出される秒単位の時間。SERVICEMEMBERイベントで表示されます

vip_ips

停止したパブリック・ネットワーク上のVIP。NODEイベントの一部。

NODEDOWNイベントの例を次に示します。 

NODE VERSION=2.0 host=my-exa status=nodedown reason=public_nw_down 
incarn=0 timestamp=2019-10-24 09:02:35 timezone=+00:00 vip_ips=10.1.1.94

次の表に示すように、FANイベント・レコード・パラメータのいくつかには、デフォルトのネームスペースUSERENVを使用しているSYS_CONTEXT関数によって戻される値に対応する値があります。

表6-2 FANパラメータおよび該当するセッション情報

FANパラメータ 該当するセッション情報
SERVICE sys_context('userenv', 'service_name')
DATABASE_UNIQUE_NAME sys_context('userenv', 'db_unique_name')
INSTANCE sys_context('userenv', 'instance_name')
CLUSTER_NODE_NAME sys_context('userenv', 'server_host')

親トピック: 高速アプリケーション通知(FAN)

6.3.7 高可用性イベントのサブスクリプション

サービスに関するアプリケーションを監視および通知するために、Oracle Real Application Clusters (Oracle RAC)ではOracle RAC Fast Application Notification (FAN)を使用します。

Oracle RACは、FANを使用して、構成の変更や、サービスで使用可能な各インスタンスが提供している現在のサービス・レベルをアプリケーションに通知します。Oracle Call Interface (OCI)クライアントまたはODP.NETクライアントを使用してFANイベントを受信している場合は、-notificationパラメータを指定してSRVCTLを使用して、そのクライアントが使用するサービスを有効にして、アラート通知キューにアクセスする必要があります。

親トピック: 高速アプリケーション通知(FAN)

6.3.8 高速アプリケーション通知のコールアウトの使用方法

高速アプリケーション通知(FAN)コールアウトは、高可用性イベントが発生したときにOracle RACで即座に実行されるサーバー側の実行可能ファイルです。

FANコールアウトを使用すると、クラスタ構成でイベントが発生した場合に、次のようなアクティビティを自動的に実行できます。

  • 障害追跡チケットのオープン
  • ページャへのメッセージの送信
  • 電子メールの送信
  • サーバー側のアプリケーションの起動および停止
  • 発生時の各イベントのロギングによるアップタイム・ログのメンテナンス
  • 優先度の高いサービスがオンラインになった場合の優先度の低いサービスの再配置

FANコールアウトを使用するには、Oracle Clusterwareを実行しているすべてのノードのGrid_home/racg/usrcoディレクトリに実行可能ファイルを配置します。実行可能ファイルは、別のプログラムからオプションの引数でコールされた場合、スタンドアロンで実行可能である必要があります。次に、Grid_home/racg/usrcoディレクトリに配置されている、callout.shという名前の実行可能ファイルのシェル・スクリプトの例を示します。 

#! /bin/bash
FAN_LOGFILE= [your_path_name]/admin/log/'hostname'_uptime'.log
echo $* "reported="'date' >> $FAN_LOGFILE &

前述の例では、FANイベントが生成されるたびに、シェル・スクリプトの$FAN_LOGFILEによって示されるログ・ファイルに次のようなエントリを追加します。 

NODE VERSION=2.0 host=my-exa status=nodedown reason=public_nw_down 
incarn=0 timestamp=2019-10-24  09:02:35 timezone=+00:00 vip_ips=10.1.1.94

FANイベント・レコードの内容は、データベースにログオンしているユーザーの現行のセッションに一致します。また、Oracle Call Interface (OCI)接続ハンドルと記述子属性(OCIAttrGet()を使用)を使用すると、ユーザー環境(USERENV)情報も使用できます。この情報を使用すると、FANイベントのデータに該当するセッションでアクションを実行できます。

通常、イベントはそれが発生したノード上のユーザー・コールアウトにポストされるだけです。たとえば、node1のデータベースが停止した場合、コールアウトはnode1のみにポストされます。唯一の例外は、ノード停止とVIP停止イベントで、これらのイベントは、発生した場所にかかわらず、すべてのノードにポストされます。

関連項目

親トピック: 高速アプリケーション通知(FAN)

6.4 計画外停止の管理

サービスは、管理者管理Oracle RACデータベースの1つ以上のインスタンスに割り当てるか、またはポリシー管理データベースのサーバー・プールに割り当てることができます。

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

Oracle Real Application Clusters (Oracle RAC)で停止が検出されると、Oracle Clusterwareは、障害が発生したコンポーネントを隔離して、依存コンポーネントをリカバリします。サービスの場合、障害が発生したコンポーネントがインスタンスであった場合、Oracle Clusterwareはサービスのカーディナリティを維持しようとします。サービス定義によりフェイルオーバーが許可され、カーディナリティを維持するためにフェイルオーバーが必要な場合は、フェイルオーバーが発生します。

高速アプリケーション通知(FAN)イベントは、Oracle Databaseアーキテクチャ内の様々なレベルで発生する可能性があります。旧リリースのOracle Call Interface (OCI)クライアントとの下位互換性を提供するために、Oracle Notification ServiceやOracle Advanced Queuingを使用して発行されます。FANコールアウトは、FANイベントに応答してデータベース・サーバーで実行されるように記述することもできます。

注意:

Oracle RACのコールアウトの実行では、順序は保証されません。コールアウトは非同期で実行され、スケジュールは変動します。

障害ノードのサービスが停止すると、稼働を続けるノードからFANが発行されます。Oracle RAC環境内でサービスを提供するインスタンスの位置および数は、アプリケーションに対して透過的です。再起動およびリカバリは自動的に実行され、データベースのみでなく、リスナーやOracle Automatic Storage Management(Oracle ASM)プロセスなどのサブシステムも再起動されます。FANコールアウトを使用して、障害管理システムに障害を報告して、修復ジョブを起動できます。

アプリケーション開発者にとってデータベース・セッション(インスタンス、ノード、ストレージやネットワークなどに関連するコンポーネント)の停止をマスキングすることは複雑なタスクです。その結果として、エラーやタイムアウトはエンド・ユーザーにさらされることが多く、ユーザーの不満、生産性や機会の喪失につながります。FANとアプリケーション・コンティニュイティは連携して、停止後に影響を受けるデータベース・セッションの進行中の作業をリカバリすることで、ユーザーとアプリケーションから停止をマスクします。アプリケーション・コンティニュイティは、このリカバリをアプリケーションの下で実行するため、アプリケーションは停止をリクエストの実行のわずかな遅延として認識するようになります。

関連項目

親トピック: アプリケーション・コンティニュイティの確保

6.5 計画メンテナンスの管理

アプリケーション・ユーザーに対するサービス中断を最小限に抑えるために、Oracle Real Application Clusters (Oracle RAC)には、サービスを再配置、無効および有効にするインタフェースが用意されています。

  • 計画メンテナンスの管理について
    1つ以上のインスタンスまたはノードを隔離する必要がある修復、アップグレードおよび変更のために、サービス・リクエストを排出してサービスを使用可能なノードに再配置できます。
  • ユーザーを妨害しない計画メンテナンスの管理
    FAN対応のOracleまたはOracle以外の接続プールにより制御された期間中のインスタンスから、またはOracle Database18c以降はデータベース自体で、データベース・セッションを排出することをお薦めします。
  • メンテナンスのためのサービスのグループの管理
    Oracle Real Application Clusters (Oracle RAC)では、SRVCTLを使用してクラスタ内のサービスのグループを管理できます。
  • 計画メンテナンスの前のサーバーの排出
    計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出するかフェイルオーバーします。Oracle Database 18c以降、データベース自体がセッションを排出します。
  • 計画フェイルオーバー
    計画フェイルオーバーは、Oracle Databaseによってセッションのフェイルオーバーが可能と判断されたポイントでデータベースにより強制的に実行されるフェイルオーバーです。

親トピック: アプリケーション・コンティニュイティの確保

6.5.1 計画メンテナンスの管理について

1つ以上のインスタンスまたはノードを隔離する必要がある修復、アップグレードおよび変更のために、サービス・リクエストを排出してサービスを使用可能なノードに再配置できます。

サービスを再配置する場合は、サービスが一時的に別のインスタンスで実行されるようにする必要があります。サービスが停止または再配置された場合、計画済理由コード(通常はreason=user)でFANが発行されます。操作を完了したら、サービスを通常の操作に戻すか、またはサービスを有効にしてから、再起動することができます。サービスが再起動されると、FANはUPステータス・コードで発行されます。

データベースを手動で停止すると、依存性のために、そのデータベースのすべてのサービスも自動的に停止されます。データベースを手動で再起したときにサービスが自動的に起動するようにする場合は、サービスの管理ポリシーをautomaticに設定する必要があります。データベースの1つのインスタンスのみをシャットダウンして、サービスの提供が継続されるようにするには、srvctl relocate serviceを使用してサービスを再配置するか、-failoverオプションを指定したsrvctl stop instanceを使用してインスタンスを停止します。これにより、サービスはフェイルオーバー・ポリシーに従って自動的にフェイルオーバーできるようになります。

どちらの場合も、サービスの下で実行している作業をリクエスト境界で排出することをお薦めします。排出間隔は、サービスの属性として指定されています。また、SRVCTLコマンドラインで排出間隔を指定することもできます。

関連項目

親トピック: 計画メンテナンスの管理

6.5.2 ユーザーを妨害しない計画メンテナンスの管理

FAN対応のOracleまたはOracle以外の接続プールにより制御された期間中のインスタンスから、またはOracle Database18c以降はデータベース自体で、データベース・セッションを排出することをお薦めします。

データベース・セッションの排出は、アプリケーションを中断せずに作業を移行する最も安全な方法です。排出が接続テスト時およびリクエスト境界の外で発生した場合、これは100%適切です。既存の作業が完了すると、アプリケーションは中断せずに続行し、新しい作業が別のインスタンスで同じサービス機能のセッションを取得します。その結果、アプリケーションにはエラーが返されず、データベース・セッションの状態が不正になるリスクがありません。接続テストの場合、コール元は受信するリターン・コードが正しくても正しくなくても、結果を処理する準備ができているので、接続テストの検査が広範囲に適用可能で非常に強力なソリューションになります。

サービス属性の-drain_timeoutと-stopoptionでは排出期間を制御し、この期間の経過後に完了していないセッションをサービスで管理する方法を制御します。完了後にプールにチェックインするリクエストまたは完了後に閉じるリクエストは、計画メンテナンスの影響を受けない新しい場所に転送できます。

アプリケーション・コンティニュイティでは、割り当てられた排出時間内に完了しないリクエストにサービスを継続することで追加の対策を提供します。FAN対応のプールを使用すると、FANが計画したDOWNイベントの受信後に、セッションはリクエスト境界で排出できるようになります。

Oracle Database 18c以降、一部のアプリケーションがOracle接続プールを使用し、一部のアプリケーションがFAN対応であるため、データベースでは計画メンテナンス中にセッションを検査し、アプリケーションが中断されないようにセッションを停止する安全な場所を探します。サービスを停止した後、データベースは接続を閉じることができる安全な場所を検索します。接続が閉じると、データベースではセッションをクリーンアップします。

安全な場所でセッションを停止すると、アプリケーションは必要な状態で新規接続を開くことができます。セッションの排出では、各セッションに関係する作業が発生する場合があります。セッションを即座に閉じる必要はありませんが、可能であれば、排出のタイムアウト期間が経過する前にアプリケーションにエラーが表示されない安全な場所で閉じる必要があります。

発行済の作業はリクエストによって完了できるため、リクエストはトランザクションよりもはるかに重要です。Oracle Universal Connection Poolは、リクエストの排出の際に排出タイムアウトを使用して段階的な排出を実行します。元のセッションを一度に解放するのではなく、期間全体で徐々に解放することで、排出されるインスタンスのログインのオーバーロードを回避します。段階的な排出には、ターゲット・インスタンスで実行中の別の作業を妨害しないという利点があります。

DRAIN_TIMEOUTとSTOP_OPTIONは、サービスを追加するとき、または作成後のサービスを変更するときに定義できるサービスの属性です。これらの属性は、SRVCTLを使用して指定することもできます。このようにすると、サーバーで定義されているものよりも優先されます。次に示すSRVCTLコマンドを使用すると、-drain_timeoutパラメータと-stopoptionパラメータを指定できます。

  • srvctl add service

  • srvctl modify service

  • srvctl relocate service

  • srvctl stop service

  • srvctl stop database

  • srvctl stop instance

ユーザーを妨害することなく計画メンテナンスを管理するには:

  1. SRVCTLを使用してシングルトン・サービス、またはすべてのノードで実行中でないサービスを再配置します。前述の各SRVCTLコマンド(addとmodifyを除く)に、-forceフラグを使用します。-forceフラグは、srvctl relocate serviceまたはsrvctl stop serviceのどちらかを実行するときに、コマンドラインで-stopoptionパラメータを指定した場合に使用する必要があります。次に例を示します。
    $ srvctl relocate service –db mycdb01 –service myservice –drain_timeout 120
  –stopoption IMMEDIATE –oldinst mycdb01_01 -force
    前述のコマンドは、mycdb01_01というインスタンスのmyservice01というサービスを、そのサービスを実行するように構成されたインスタンスに再配置します。Oracle Clusterwareは、このインスタンスを選択して(コマンドラインでターゲットを指定していない場合)、アクティブなセッションを排出するために2分間待機し(この例の場合)、その後でmycdb01_01に残っているセッションが強制的に切断されます。接続プールにより、要求境界で接続が自動的に解放されます。

    注意:

    再配置するサービスが現在すべてのノードで実行中の均一サービスである場合、前述のコマンドはエラーを返し、サービスがすべてのインスタンスで起動していなければ、均一サービスの場合に前述のコマンド例は成功します。
  2. FAN計画済DOWNイベントにより、アイドル・セッションが接続プールからただちにクリアされ、次のチェックインで解放されるアクティブ・セッションがマークされます。これらのFANアクションにより、ユーザーの作業を妨げずにセッションがインスタンスから排出されます。

    他のインスタンスの既存の接続は使用可能なままで、必要な場合はこれらのインスタンスに新しい接続をオープンできます。排出するセッションには、データベースによってマークも付けられます。データベースは、接続テストと安全なフェイルオーバー先(Oracle Database 19c以降の場合)を探します。透過的アプリケーション・コンティニュイティでの暗黙的な接続境界は、このような場所です。

  3. どの場合でも、すべてのセッションが接続をプールにチェックインするわけではありません。ベスト・プラクティスとして、タイムアウト期間を設定して(-drain_timeoutパラメータで設定)、その後で、残っているクライアント接続を削除するためにインスタンスがシャットダウンされるようにするか、サービスが停止されるようにすることをお薦めします。
    排出間隔の経過後、-stopoptionパラメータが実施されます。このパラメータは、サービスまたはデータベースに対して次のように定義できます。

    • サービスを停止する場合(srvctl stop service)、-stopoptionパラメータを使用すると停止オプションのTRANSACTIONALまたはIMMEDIATEのいずれかを指定できます

    • データベースを停止する場合(srvctl stop database)、-stopoptionパラメータを使用すると停止オプションのNORMAL、TRANSACTIONAL、IMMEDIATE、ABORTのいずれかを指定できます

    データベースの停止オプションとサーバーの停止オプションの相関は次のとおりです。
    • NORMAL=NONE
    • TRANSACTIONAL/TRANSACTIONAL LOCAL=TRANSACTIONAL
    • IMMEDIATE/ABORT=IMMEDIATE

    アプリケーション・コンティニュイティを使用するように構成されたサービスの場合、ユーザーとアプリケーションから停止をマスクするために、終了された後で残っているセッションのリカバリが試行されます。

  4. メンテナンスが完了後に、元のノードでインスタンスとサービスを再起動します。
  5. サービスのFAN UPイベントにより、新しいインスタンスが使用可能で、次の要求境界でこのインスタンス上にセッションを作成できることが接続プールに通知されます。

関連項目

親トピック: 計画メンテナンスの管理

6.5.3 メンテナンスのためのサービスのグループの管理

Oracle Real Application Clusters (Oracle RAC)では、SRVCTLを使用してクラスタ内のサービスのグループを管理できます。

  • サービスのグループの停止例
    SRVCTLを使用して、ノード名、データベース名、プラガブル・データベース名またはインスタンス名でサービスを停止する方法を示します。
  • サービスの開始
    srvctl start serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを開始できます。
  • プラガブル・データベース・レベルの操作
    SRVCTLを使用すると、プラガブル・データベースのサービスを管理できます。
  • サービスの再配置
    srvctl relocate serviceコマンドを使用すると、ターゲット宛先にサービスを再配置できます。インスタンス、ノードまたはデータベースが再配置の宛先になります。
  • サービスの停止
    srvctl stop serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを停止できます。

親トピック: 計画メンテナンスの管理

6.5.3.1 サービスのグループの停止例

SRVCTLを使用して、ノード名、データベース名、プラガブル・データベース名またはインスタンス名でサービスを停止する方法を示します。

多くの企業が多数のサービスを実行しています。多数のサービスが単一のデータベースまたはインスタンスで提供されることも、多数のデータベースが同じノード上で実行する少数のサービスを提供することもあります。個別のサービスごとにSRVCTLコマンドを実行する必要はなくなり、影響を受けるすべてのサービスのノード名、データベース名、プラガブル・データベース名、またはインスタンス名を指定することのみが必要になります。

たとえば、racnode01というノードで実行しているすべてのサービスを停止する場合は、次にコマンドを使用できます。 

$ srvctl stop service –node racnode01 –drain_timeout 60 –stopoption IMMEDIATE

このコマンドでは、60秒の排出間隔を割り当てて、racnode01で実行しているすべてのサービスを停止します。60秒後に、残っているセッションは即座に停止されます。この60秒の排出タイムアウト間隔は、あらゆるサービスの属性設定をオーバーライドします。

このコマンドは、次の例に示すように、ノード上のデータベースを停止する場合にも適しています。
$ srvctl stop instance 	-node racnode01 -drain_timeout 60 –stopoption TRANSACTIONAL
  LOCAL -failover –force
-failoverパラメータを指定すると、次のようになります。

  • すべてのサービスは、指定した排出タイムアウト間隔と停止オプションを考慮して再配置されます(可能な場合)。

  • フェイルオーバーできないサービスは、指定された停止オプションを使用して停止されます。

  • 排出タイムアウト間隔の経過まで待機するか、ターゲットのサービスのセッションがすべて削除されるまで待機します(どちらか早いほう)。

  • すべてのインスタンスは、停止オプションの指定に従って停止します。

–stopoption TRANSACTIONAL LOCALパラメータを指定すると、次のようになります。

  • 残っているサービスは、指定された排出タイムアウト間隔と停止オプションに従って停止します。

  • 排出タイムアウト間隔の経過まで待機するか、ターゲットのサービスのセッションがすべて削除されるまで待機します(どちらか早いほう)。

  • インスタンスは、TRANSACTIONAL LOCAL停止オプションを使用して停止します。

6.5.3.2 サービスの開始

srvctl start serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを開始できます。

サービスを開始するには、srvctl start serviceコマンドに、開始するサービスのリスト(すべてのサービスのサブセット)を指定することもできます。さらに、特定のノードで開始できるすべてのサービスに対して、データベース・オプションとともにノード制限を指定することもできます。srvctl start serviceコマンドは、-pqパラメータを指定することで、パラレル問合せサービスのみを開始するように制限できます。
次の各例では、サービスの開始方法を説明します。

次の各例では、サービスの開始方法を説明します。

単一のプラガブル・データベースが提供するサービスをすべて開始するには:

$ srvctl start service –db myRACCDB01 –pdb myPDB01 –startoption OPEN

特定のデータベースと、そのプラガブル・データベースのサービスをすべて開始するには:

$ srvctl start service –db myRACDB

関連付けられたプラガブル・データベースの有無にかかわらず、特定のデータベースのサービスのリストを開始するには:

$ srvctl start service –db myRACDB –service "myFirstService,mySecondService,myThirdService"

特定のノードで実行可能なデータベースのサービスをすべて開始するには:

$ srvctl start service –d myRACDB –node racnode01
6.5.3.3 プラガブル・データベース・レベルの操作

SRVCTLを使用すると、プラガブル・データベースのサービスを管理できます。

すべてのインスタンスまたは単一のインスタンスに対して、プラガブル・データベースのサービスをすべて開始するには:
$ srvctl start service -db db_name -pdb pdb_name [-instance instance_name]

すべてのインスタンスまたは単一のインスタンスに対して、プラガブル・データベースのサービスをすべて停止するには:

$ srvctl stop service -db db_name -pdb pdb_name [-node node_name | -instance 
   inst_name | -serverpool pool_name] [-stopoption stop_option] [-drain_timeout timeout]
   [-force [-noreplay]]

注意:

-pdb pdb_nameパラメータはオプションです。プラガブル・データベース名を省略すると、コンテナ・データベース全体(このコンテナ内のすべてのプラガブル・データベース)が操作の対象になります。
6.5.3.4 サービスの再配置

srvctl relocate serviceコマンドを使用すると、ターゲット宛先にサービスを再配置できます。インスタンス、ノードまたはデータベースが再配置の宛先になります。

次のコマンド例では、すべてのサービスが、名前付きデータベース、プラガブル・データベース、インスタンス、またはノードから再配置されます。サービスは、サービス構成で定義されているとおりに、そのサービスをターゲットがサポートできる場合にのみ再配置されます。再配置できないサービスは、元の場所に残されます。再配置されていないサービスに対する配置エラーが記録されます。それ以外は、すでに新しいターゲットで実行されています。再配置に失敗したサービスは、そのサービスの元の場所で実行を続け、セッションはアクティブのままになります。

$ srvctl relocate service –db myRACCDB –oldinst RACCDB_01 –newinst RACCDB_03
  -drain_timeout 30 -stopoption immediate

または

$ srvctl relocate service –db myRACCDB –pdb myPDB01 –currentnode racnode01
  –targetnode racnode02 -drain_timeout 30 -stopoption immediate

再配置操作は、新しい場所でサービスを開始してから、既存の場所でサービスを停止します。

ターゲット宛先を指定していない場合、Oracle Clusterwareは、指定されたデータベース、プラガブル・データベース、インスタンス、またはノードから、すべてのサービスまたは特定のサービスを再配置します。次に、例を示します。

$ srvctl relocate service –db myRACCDB –service "myService01,myService02"
  -drain_timeout 30 -stopoption immediate

または

$ srvctl relocate service –db myRACCDB –pdb myPDB01 -drain_timeout 30
  -stopoption transactional

有効なターゲットが存在しない場合、サービスは元の場所に残され、セッションはアクティブのままになります。サービスを調べて、必要な場合はサービスを停止してください。

サービスを再配置すると、サービスは新しい場所で開始されてから、元の場所で停止されます。Oracle Clusterwareは、新しいインスタンスまたはプラガブル・データベースを依存性として開始できます。-drain_timeoutパラメータと-stopoptionパラメータが指定されていると、サービスの属性がオーバーライドされます。

6.5.3.5 サービスの停止

srvctl stop serviceコマンドを使用すると、ノード上のすべてのサービス、データベースが提供するすべてのサービス、プラガブル・データベースが提供するすべてのサービス、またはインスタンス上や特定のサーバー・プール内で提供されるすべてのサービスを停止できます。

サービスのサブセットを停止する際は、srvctl stop serviceコマンドに停止するサービスのリスト(すべてのサービスのサブセット)を指定することもできます。また、srvctl stop serviceコマンドは、-pqパラメータを指定することで、パラレル問合せサービスのみを停止するように制限できます。

単一のプラガブル・データベースが提供するサービスをすべて停止するには:

$ srvctl stop service –db myRACCDB01 –pdb myPDB01 –drain_timeout 15 –stopoption TRANSACTIONAL

特定のデータベースと、そのプラガブル・データベースのサービスをすべて停止するには:

$ srvctl stop service –db myRACDB –drain_timeout 15 –stopoption IMMEDIATE

データベースが提供する一部のサービスのみを停止するには:

$ srvctl stop service –db myRACDB –service "myFirstService,mySecondService,
  myThirdService" –drain_timeout 60 –stopoption IMMEDIATE

注意:

–wait YES SRVCTLコマンドライン・パラメータを使用すると、–stopoptionパラメータは排出タイムアウト間隔を経過するまで、この間隔の完了前にすべてのセッションが終了していても、実施されません。

6.5.4 計画メンテナンスの前のサーバーの排出

計画メンテナンスの前に、アプリケーションの動作が中断されないように、データベース・インスタンスでデータベースのセッションを排出するかフェイルオーバーします。Oracle Database 18c以降、データベース自体がセッションを排出します。

計画メンテナンスの準備を行う場合は、サーバー・インフラストラクチャを使用しているサービスを停止または再配置する必要があります。サービスの再配置は計画済停止の前に一定期間にわたって行われ、各サービスに関連する作業の性質に基づいています。

計画メンテナンスのローリングの手順では、メンテナンスの前にサービスを別のデータベース・インスタンスに移動し、クライアント側ドライバ、接続プール、データベース・インスタンス自体および他のサブスクライバにメンテナンスが保留中であることと、排出する必要のあるもの(このサービスを使用する接続またはセッション)を通知します。排出が通知されると、高速アプリケーション通知(FAN)イベントが送信され、クライアント・プールは他の場所で説明されているように動作し、さらにデータベースでは接続を解放する安全な場所を検索し、必要に応じて接続を移行します。

サービスを移動または停止すると、FAN通知がトリガーされ、サブスクライブしているOracleドライバおよびOracle接続プールで受信されます。Oracle Database 18c以降では、FAN通知によってもサーバーでのセッションの排出がトリガーされます。そのサービスに対する新規の作業が、ただちにサービスの機能している別のインスタンスに送信されます。既存のセッションは、その作業の完了後に解放用にマークされます。作業が完了して接続が接続プールに戻されると、Oracleドライバまたは接続プールのいずれかがこれらのセッションを終了します。

データベースでのセッションの排出

OLTPアプリケーション、アプリケーション・サーバーおよびカスタム・アプリケーションがデータベース・セッションを流用および返却する専用の接続プールを持っている場合、データベース・セッションが流用されなければ、そのセッションの排出は安全です。Oracleサーバー・インフラストラクチャがセッションを閉じるのに最適なのは、アプリケーション・サーバーがその接続の妥当性をテストした時点です。流用および解放時に接続プール・マネージャが接続の妥当性をテストして、接続が有効はでないことが検出した場合、エラーはアプリケーションに返されません。

安全な場所とは、アプリケーションが中断されない場所です。接続プールの場合、これは流用(チェックイン)されていない接続を意味し、アプリケーションの場合、接続を流用または返却する時点において同様のことが当てはまります。この時点では、すべての作業が完了しているか、起動していないかのいずれかです。データベースでは、すべての状態がアプリケーションに対して透過的にリストアできる場合、接続をフェイルオーバーすることもできます。

Oracle Database 18c以降では、データベースはルールとヒューリスティックの拡張可能なセットを使用して、データベース・セッションを取り除くタイミングを検出します。排出が開始すると、データベース・セッションはルールが満たされるまでデータベースで継続します。ルールには次の内容が含まれています。
  • 標準アプリケーション・サーバーが妥当性をテストします
  • カスタムSQLが妥当性をテストします
  • リクエスト境界は有効になっており、アクティブなリクエストはありません
  • リクエスト境界は有効になっており、現在のリクエストは終了しています
  • セッションにはリカバリ可能なセッション状態が1つ以上あり、フェイルオーバー時にセッションを再作成できます

注意:

Oracle Database 18c以降、接続を排出するには、「サーバーで排出するための接続テストの追加、無効化、有効化および削除」を参照してください。

たとえば、接続テストの場合、標準的な手順として、接続プールからの流用時、プールへの返却時およびバッチ・コミット時に、アプリケーション・サーバー、プールされたアプリケーション、ジョブ・スケジューラなどが接続をテストします。排出時に、データベースは接続テストを中断して接続を閉じ、テストの失敗ステータスを返します。接続テストを発行しているアプリケーション・レイヤーは、失敗の戻りステータスを処理する準備ができています。通常、さらにリクエストを発行して、別の接続を取得します。アプリケーションは中断されません。

すべてのセッションを排出できるわけではありません。接続がプールに戻っていないときや、FANが使用されていないときには排出できません。透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティが有効化されている場合、サーバーは、アプリケーション・コンティニュイティがセッションをすばやくリカバリできるリクエスト境界を検出します。サーバーはセッションを中断する可能性がありますが、アプリケーション・コンティニュイティはこれを中断せずにリカバリします(Oracle RACクラスタの別のサーバーに対してなど)。

排出しないデータベース・セッションの場合、データベースはセッションの置き換えが可能なブレーク・ポイントを見つける必要があります。ブレーク・ポイントでは、状態が既知およびリカバリ可能である場合に、接続は透過的にフェイルオーバーできます。ブレーク・ポイントは、トランザクション境界、コールがリクエスト内で実行される前のリクエストの先頭(beginRequest)、およびリクエストが開始または終了していることを通知する監査コールなど、パターンである場合があります。ブレーク・ポイントは、状態がリストア可能であると認識されている場合にのみ適用されます。Oracle Database 20c以降、データベース・ソフトウェアによってセッションのフェイルオーバー先が決定され、セッションをフェイルオーバーするためにアプリケーション・コンティニュイティが起動されます。

接続をフェイルオーバーすると、アプリケーションによっては、アプリケーション・コンティニュイティ、透過的アプリケーション・コンティニュイティまたは透過的アプリケーション・フェイルオーバー(TAF)を有効にする必要があります。

注意:

UCPまたはOCIセッション・プールなど、Oracle接続プールは継続的な可用性を実現し、ロード・バランシングなどを提供することで大きな利点を提供するため、これらの接続プールを使用することをお薦めします。

サーバーで排出するための接続テストの追加、無効化、有効化および削除

サービス、プラガブル・データベースまたは非コンテナ・データベースにSQL接続テストを追加できます。

デフォルトでは、すべてのデータベース・サービスおよびプラガブル・データベース・サービスに4つのSQL接続テストが追加されています。したがって、アプリケーションが接続で次のSQL接続テストを使用している場合、これらを追加する必要はありません。
SELECT 1 FROM DUAL;
SELECT COUNT(*) FROM DUAL;
SELECT 1;
BEGIN NULL;END;
  • サービスにサーバー側SQL接続テストを追加するには、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.add_sql_connection_test('select dummy from dual','sw_orcl');
    プラガブル・データベースまたは非コンテナ・データベースにサーバー側SQL接続テストを追加するには、非コンテナ・データベースにログオンし、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.add_sql_connection_test('begin null;end;');

    SQL接続テストを追加すると、デフォルトでこれが有効になります。

  • SQL接続テストが不要な場合またはこれを使用していない場合、プラガブル・データベースまたは非コンテナ・データベースにログオンして、次のようなSQL文を使用することにより、SQL接続テストを無効にできます。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.sql_test,'select dummy from dual');

    デフォルトではpingテストおよび終了リクエスト・テストは無効になっていますが、これらを有効にした後に無効にする場合、次のSQL文のいずれかを使用できます。

    pingテストを無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.ping_test);
    終了リクエスト・テストを無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.endrequest_test);
  • プラガブル・データベースまたは非コンテナ・データベースにログオンして次のようなSQL文を使用することにより、SQL接続テストを無効にした後これを有効にできます。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select dummy from dual');

    無効になっている場合、次のSQL文のいずれかを使用してpingテストおよび終了リクエスト・テストを有効にすることもできます。

    isValid、isUsable、OCIpingまたはconnection.statusなどのpingを使用するすべてのテストを実行する場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.ping_test);
    リクエストの終了時に排出を有効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.endrequest_test);
    リクエストの終了時に排出を無効にする場合、次のようなSQL文を使用します。
    SQL> execute dbms_app_cont_admin.disable_connection_test(dbms_app_cont_admin.endrequest_test);
  • SQL接続テストが不要な場合、プラガブル・データベースまたは非コンテナ・データベースにログオンして、次のようなSQL文を実行すると、SQL接続テストを削除できます。
    SQL> execute dbms_app_cont_admin.delete_sql_connection_test('select dummy from dual','sw_orcl');
SQL> execute dbms_app_cont_admin.delete_sql_connection_test('begin null;end;');

すべてのアプリケーション・サーバーには各接続プールで接続の妥当性をテストする機能があり、これは構成プロパティまたは管理コンソールで設定されています。テストの目的は、使用できない接続をアプリケーションに渡さないようにすることと、使用できない接続を検出した場合に、プールへの解放時にこれを削除することです。

様々なアプリケーション・サーバーでテストの名前が類似しています。提供されているテストでは様々なアプローチを使用しており、最も一般的なものはSQL文です。Javaアプリケーション・サーバーで標準のJavaコールconnection.isValidを使用することをお薦めします。Oracle Database 18c以降、これらのテストを使用してデータベースを排出します。また、Oracle Database 18c以降、データベースは安全な排出ポイントのためにセッションを調査することにより、FANを使用しないでセッションを排出します。

次の表は、より一般的ないくつかのアプリケーション・サーバーに利用可能な標準接続テストを示しています。

表6-3 一般的なアプリケーション・サーバーの標準接続テスト

アプリケーション・サーバー データベースへの接続テスト

Oracle WebLogicサーバー
用意されているテストは次のとおりです。 
  • dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test,'select 1 from dual');

  • TestConnectionsonReserve:

    isUsable、isValid、またはPingDatabase

  • サーバーの排出場合、TestConnectionsOnCreate (SQL構文) : 

    Select 1 from dual;

Oracle WebLogic Server Active Gridlink
次のテストが埋め込まれています。
isUsable

IBM WebSphere

 
dbms_app_cont_admin.enable_connection_test(dbms_app_cont.sql_test,'select 1 from dual');

サーバーの排出のために接続を事前テストします(SQL構文)。

Select 1 from dual;

RedHat JBoss
check-valid-connection-sql (SQL構文):
dbms_session.enable_connection_test(dbms_session.sql_test,'select 1 from dual');

Apache Tomcat
2つのテストtestOnBorrowおよびtestOnReturnを利用できます。どちらも、データベースへの接続テストにSQL構文を使用します。
dbms_app_cont.enable_connection_test(dbms_app_cont.sql_test,'select 1 from dual');
アプリケーション・サーバーでは次を使用します。
Select 1 from dual;

Oracle Notification Services (ONS)の自動構成をサポートするために次に示すフォーマットの使用をお薦めします。これにより、FANイベントを受信できます(ONS経由)。

例6-1 FANの自動構成

alias =(DESCRIPTION =
 (CONNECT_TIMEOUT=90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3) 
   (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   ( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
   (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   ( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521)))
  (CONNECT_DATA=(SERVICE_NAME = gold-cloud)))

関連項目

親トピック: 計画メンテナンスの管理

6.5.5 計画フェイルオーバー

計画フェイルオーバーは、Oracle Databaseによってセッションのフェイルオーバーが可能と判断されたポイントでデータベースにより強制的に実行されるフェイルオーバーです。

この機能は主に、計画メンテナンス中のセッションの削減に使用されます。また、ロードのリバランスにも使用されます。

Oracle Databaseリリース18c以降の計画メンテナンスでは、データベースは、計画メンテナンスのために排出するセッションにマークを付けます。データベースは、すべてのセッションが排出されるわけではないことを認識します。計画フェイルオーバーでは、データベースが排出ではなくフェイルオーバーを想定するセッションをプロアクティブにフェイルオーバーします。

  1. データベースは、セッションが排出対象としてマークが付けられていることと、排出ポイントが有効になっていない、または排出ポイントが有効になっているのに許容時間内に到達しないことを認識します。

  2. データベースは、透過的アプリケーション・コンティニュイティまたはアプリケーション・コンティニュイティがセッションで有効になるタイミングを認識します。

  3. データベースは、リクエストの率およびサイズに関する統計を保持し、アプリケーション・コンティニュイティが有効になっている場合は、リプレイのコールの保護レベルおよびリカバリする必要のあるセッションの状態を保持します。

  4. データベースは、セッションがフェイルオーバーできるタイミングと、リカバリする必要があった場合にどの程度のリカバリが必要かを認識します。

データベースによってセッションがフェイルオーバーされると、データベースによってこの判断が行われたことを示すレコードがアラート・ログに表示されます。

親トピック: 計画メンテナンスの管理

6.6 アプリケーション・コンティニュイティの構成

アプリケーション・コンティニュイティを使用するように環境を構成する際には、接続とサービスの可用性を高くすること、データベースを変更すること、セッション状態の管理方法を理解することが必要になります。

親トピック: アプリケーション・コンティニュイティの確保

6.6.1 アプリケーション・コンティニュイティ構成タスクの概要

各種Oracleアプリケーションのアプリケーション・コンティニュイティ機能が自動的に使用されます(必要なサービス属性を設定した場合)。

アプリケーション・コンティニュイティのサポートは多くのOracleアプリケーションに統合されているため、アプリケーション・コンティニュイティに関連するサービス属性を設定する場合、それらのアプリケーションの機能は自動的に使用されます。

アプリケーションの透過的リプレイを確実にするための主なアクションは次のとおりです。

  1. Javaを使用している場合のみ、アプリケーションがOracle JDBCの具象クラスを使用するかどうか判別します。アプリケーション・コンティニュイティを使用するには、非推奨の具象クラスを置換する必要があります。

    ORAchkユーティリティに-acchkパラメータを使用して、アプリケーションに具象クラスがあるかどうかを確認します。リプレイされてはならないものがある場合は、アプリケーション・コンティニュイティのない接続を使用します。(ほとんどのアプリケーションがリプレイ可能です)。

    関連項目:

    ORAchkの詳細は、Oracle Autonomous Health Frameworkユーザーズ・ガイドを参照してください

  2. 必要なCPUおよびメモリー・リソースがあることを確認します。

    • CPU: アプリケーション・コンティニュイティは、クライアント側とサーバー側で管理され、動作のための最小限のCPUオーバーヘッドが必要になります。

      クライアントでは、プロキシ・オブジェクトの構築とガベージ・コレクション(GC)のためにCPUが使用されます。

      サーバーでは、CPUは検証のために使用されます。CPUオーバーヘッドは、検証がハードウェアによって補佐されている、現在のIntelおよびSPARCチップを使用したプラットフォームでは減少します。

    • メモリー: アプリケーション・コンティニュイティを使用している場合、呼出しがリクエストの最後まで保持されるため、リプレイ・ドライバにはベース・ドライバよりも多くのメモリーが必要です。リクエストの最後で、呼出しはガベージ・コレクタに解放されます。この処理は、クローズされた呼出しを解放するベース・ドライバによって異なります。

      リプレイ・ドライバのメモリー消費量は、リクエストごとのコール数によって異なります。この数が小さい場合、リプレイ・ドライバのメモリー消費量は少なくなり、ベース・ドライバと同程度になります。

      最良のパフォーマンスを得るには、クライアント側でパラメータ-Xmxと-Xmsの両方に同じ値を設定する必要があります。たとえば、十分なメモリーがある場合、仮想マシン(VM)に4から8GB (以上)を割り当てます。たとえば、4GBであれば-Xms4gと設定します。-Xmsパラメータがこれより低い値に設定されている場合、VMもオペレーティング・システムから低い値を使用するため、パフォーマンスが悪化する可能性があり、ガベージ・コレクション操作が増加します。

  3. 各リクエストに対してアプリケーションが接続プール(たとえば、WebLogic Server Pool、ユニバーサル接続プール、OCIセッション・プール、Oracle Tuxedoリクエストまたは各リクエストのODP.NET接続プール)から接続を流用して返却しているかどうか、またはリクエスト境界を識別するためにbeginRequestおよびendRequest APIをアプリケーション固有の接続プールに追加するかどうかを判別します(Javaの場合のみ)。

    警告:

    リクエスト境界以外の場所では、Java APIコールのbeginRequestおよびendRequestは使用しないでください(接続プールの接続の流用と返却)。endRequestは、リクエストが完了していることと、現在はステートレスであることを示します。次のbeginRequestからリプレイが開始されます。前の状態がある場合は、FAILOVER_RESTOREまたはコールバックを使用して、その状態を再確立する必要があります。

  4. アプリケーション・コンティニュイティは、リクエスト内のすべての状態をリプレイします。アプリケーションが接続を公表する前に状態を設定する場合は、FAILOVER_RESTOREまたはコールバックが必要です。Oracle WebLogic Serverまたはユニバーサル接続プールの使用時には、FAILOVER_RESTORE、接続ラベリングまたはトリガーを使用します。Oracle Call Interface (OCI)セッション・プール、Oracle TuxedoまたはODP.NETをOracle Database 18c以降のクライアントとともに使用する場合、FAILOVER_RESTOREを使用して、必要な場合は透過的アプリケーション・フェイルオーバー(TAF)コールバックのみを追加します。ラベリングはランタイムとリプレイの両方で使用されます。

  5. アプリケーションがフェイルオーバー時にSYSDATE、SYSTIMESTAMPおよびSYS_GUIDとその順序を必要とするか、さらにこれらの元の値の維持構成を行う必要があるかどうかを判別します。

  6. session_state_consistency値のアプリケーション・スタイルを評価し、サービスに適した値を設定します。

    • session_state_consistencyがAUTOに設定されている場合、透過的アプリケーション・コンティニュイティはセッション状態を監視し、処理を決定します。状態の使用状況が不明か、状態が将来変更されることがわかっている場合は、透過的アプリケーション・コンティニュイティを使用します。追加の事前設定された状態をリストアする必要がある場合があるため、事前設定されたセッション状態のリストを参照してください。

    • session_state_consistencyがDYNAMICに設定されている場合、アプリケーションはリクエスト時に環境または設定を変更します。リプレイは、最初のCOMMITの後、次のリクエストの開始まで無効化されます。デフォルトのモードはDYNAMICであり、ほとんどのアプリケーションに適しています。

    • session_state_consistencyがSTATICに設定されている場合、アプリケーションは、初期設定後にセッション状態を変更しません。このモードは、PL/SQL状態を使用せずにトランザクションの途中でALTERを使用しない、データベースに依存しないアプリケーションの基本的なモードです。透過的アプリケーション・コンティニュイティは、session_state_consistencyをSTATICではなくAUTOに設定して使用します。AUTO設定により、セッション・ステートが静的であることが検証されます。

  7. アプリケーションにリプレイが不要なリクエストがあるかどうかを調べます。

    たとえば、外部PL/SQLアクションを使用するリクエストに対して、リプレイを無効化する必要がある場合があります。

  8. 次の構成のガイドラインに従ってください。

    • Javaの場合は、Oracle Database 12c リリース1 (12.1.0.1)以降を使用します。OCIベースのアプリケーションの場合は、Oracle Database 12c リリース2 (12.2)以降を使用します。

    • .NETアプリケーションの場合は、Oracle Database 12c リリース2 (12.2)以降に接続しているODP.NET管理対象外ドライバ12.2以降を使用します。デフォルトでは、この構成でODP.NETアプリケーションのアプリケーション・コンティニュイティが有効化されます。OCIセッション・プールを使用しないOCIベース・アプリケーション(SQL*Plusを含む)を使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティを使用します。

    • Javaベースのアプリケーションでは、JDBC Replayデータソースに対して構成されたユニバーサル接続プール12.1 (以上)またはWebLogic Server 12.1.2 (以上)を使用します。または、サード・パーティ・アプリケーション(サード・パーティJDBCプールなど)の場合はJDBCリプレイ・ドライバを使用します。IBM WebSphere、Apache Tomcat、Red Hat SpringおよびカスタムJavaソリューションの場合は、プールされたデータ・ソースとしてUCPを使用することが最も効果的なソリューションになります。

      カスタムJavaプールおよびスタンドアロンJavaアプリケーションは、JDBC Replayデータソースを直接使用することもできます。カスタムJavaプールとスタンドアロン・アプリケーションを使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティの使用をお薦めします。アプリケーションに、Java APIのbeginRequestとendRequestを追加することもできます。

    • アプリケーションがOracle接続プールからの接続の流用および戻しを行わない場合は、明示的にリクエスト境界をマークしてください。たとえば、カスタムJDBCプールなどのプールを使用する場合は、自動で境界が追加される透過的アプリケーション・コンティニュイティの使用をお薦めします。アプリケーションに、Java APIのbeginRequestとendRequestを追加することもできます。これらのAPIは、接続プールのないスタンドアロンJDBCアプリケーションに対しても使用できます。

    • エラーに対する高速な中断としてFANを有効化します。これは、フェイルオーバーが開始する前にTCPハングが発生することを回避するにはを不可欠です。12.2 FANはJDBCドライバおよびOCIドライバに組み込まれ、Javaではデフォルトでオンになっています。

    • 接続にはデータベース・サービスを使用します。SIDやインスタンス名、または管理サービス(DB_NAMEまたはDB_UNIQUE_NAME)は使用しないでください。

    • 新規着信接続に対する再試行およびこれらの再試行間の遅延を設定する接続文字列を使用します。

    • サービスに対して、アプリケーション・コンティニュイティの手動モードの場合はFAILOVER_TYPEをTRANSACTIONに設定するか、透過的アプリケーション・コンティニュイティの場合はFAILOVER_TYPEをAUTOに設定します。COMMIT_OUTCOMEをTRUEに設定し、OCI FANに対してNOTIFICATIONをTRUE-に設定します。必要に応じて、使用に適した接続を探す場合は、GOALをSERVICE_TIMEに、CLB_GOALをLONGに設定します。

    • リクエスト境界および保護レベルの統計を使用してカバレッジのレベルを監視します。さらに詳細情報が必要な場合、アプリケーション・コンティニュイティ・チェック・カバレッジ(ORAchkユーティリティに付属)を使用すると、アプリケーション・コンティニュイティによって完全に保護されているリクエストの割合と、完全には保護されていないリクエストの場所が報告されます。このカバレッジ・チェックは、デプロイメントの前と、アプリケーションの変更後に使用します。開発者と管理者は、アプリケーション・リリースが基盤のインフラストラクチャの障害から、どの程度適切に保護されているかを認識できます。問題がある場合、アプリケーションのリリース前に、その問題を修正できます。または、カバレッジのレベルを考えて放棄します。

関連項目

親トピック: アプリケーション・コンティニュイティの構成

6.6.2 高可用性およびアプリケーション・コンティニュイティに対応する接続の構成

高可用性のアプリケーションに使用する接続を構成する際の一般的な推奨事項を示します。

Javaを使用している場合、oracle.jdbc.replay.OracleDataSourceImpl、oracle.jdbc.replay.OracleConnectionPoolDataSourceImplまたはoracle.jdbc.replay.driver.OracleXADataSourceImplデータ・ソースを使用して、JDBC接続を取得する必要があります。これらのデータ・ソースは、すべてのOracle JDBCデータソース(oracle.jdbc.pool.OracleDataSourceなど)のプロパティおよび構成パラメータをすべてサポートしています。

OCIベースのアプリケーション(SQL*Plus、ODP.NET、OCIドライバ12.2以降など)は、アプリケーション・コンティニュイティをサポートしています。

接続URLの使用時には次の点に注意する必要があります。

  • データベースのREMOTE_LISTENER設定がクライアントのADDRESS_LISTのアドレスと一致しない場合、接続は行われず、「サービスが見つかりません」と表示されます。このため、データベースのREMOTE_LISTENER設定はクライアントのADDRESS_LIST内のアドレスと一致する必要があります。

    • 接続文字列がSCAN名を使用する場合は、REMOTE_LISTENERにSCAN名を設定する必要があります。
    • 接続文字列がホストVIPのADDRESS_LISTを使用する場合は、REMOTE_LISTENERにすべてのSCAN VIPとすべてのホストVIPを含むアドレス・リストを設定する必要があります

    注意:

    場所に依存しないSCANを使用すると、ノードの追加時や削除時または別のノードで実行するためのデータベースの変更時に、クライアントを再構成する必要がなくなります。

  • 接続文字列にRETRY_COUNT、RETRY_DELAY、CONNECT_TIMEOUTおよびTRANSPORT_CONNECT_TIMEOUTパラメータを設定します。これらの設定により、ランタイム時、リプレイ時、および計画済停止の作業排出時に新規接続の取得効率が向上します。

    CONNECT_TIMEOUTは、sqlnet.oraファイル内のSQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータと等価であり、完全接続に適用されます。TRANSPORT_CONNECT_TIMEOUTパラメータは、アドレスごとに適用されます。

  • CONNECT_TIMEOUTを上限値に設定して、過剰なログインを防止します。低い値にすると、ログイン・ストームが発生して、アプリケーションやサーバー・プールが取消しと再試行を繰り返す可能性があります。(RETRY_COUNT+1)*RETRY_DELAYまたはCONNECT_TIMEOUTは、レスポンス時間のSLAよりも大きな値に設定しないでください。アプリケーションは、レスポンス時間のSLAの範囲内で接続するか、エラーを受信する必要があります。

  • Oracle Databaseリリース19c以降、高可用性機能があるため、簡易接続構文を使用できます。次に例を示します。

    primary-vip,secondary-vip:1521/sales.example.com?connect_timeout=90&transport_connect_timeout
=3&retry_count=30&retry_delay=3

例6-2 ONSのTNSエントリの例

次に、Transparent Network Substrate (TNSエントリ)の例を示します。これは、Oracle Notification Service (ONS)を自動構成する際に必須のTNS書式です。ONSは、高速アプリケーション通知(FAN)に使用されるトランスポート・システムです。アプリケーション・コンティニュイティでFANを使用して、高速の停止検出を提供することをお薦めします。

myAlias=(DESCRIPTION= 
   (CONNECT_TIMEOUT=90)(RETRY_COUNT=30)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=RAC-scan)(PORT=1521)))
   (ADDRESS_LIST=
      (LOAD_BALANCE=ON)
      (ADDRESS=(PROTOCOL=TCP)(HOST=DG-Scan)(PORT=1521)))
   (CONNECT_DATA=(SERVICE_NAME=service_name))

関連項目

親トピック: アプリケーション・コンティニュイティの構成

6.6.3 アプリケーション・コンティニュイティのためのOracle Databaseの構成

アプリケーション・コンティニュイティを使用するには、システムが正しく構成されていることを確認する必要があります。

アプリケーション・コンティニュイティを使用するには、Oracle Database構成に次が含まれている必要があります。

  • Oracle Real Application Clusters (Oracle RAC)、Oracle RAC One Node、Oracle Data GuardまたはOracle Active Data Guardを使用している場合、Oracle Database 12c以降のプールおよびドライバと通信するためにOracle Notification Service (ONS)とともに高速アプリケーション通知(FAN)が構成されていることを確認します。

  • リプレイおよびロード・バランシングにサービスのサービス属性を設定します。たとえば、次を設定します。

    • FAILOVER_TYPE = AUTO | TRANSACTION: 透過的アプリケーション・コンティニュイティの場合、FAILOVER_TYPE=AUTOを使用するか、手動アプリケーション・コンティニュイティの場合、FAILOVER_TYPE=TRANSACTIONを使用します。この属性は、リプレイ・ドライバおよびアプリケーション・コンティニュイティのリプレイ機能を有効にします。Oracleドライバは、データベース・セッション中に発行されたすべてのリプレイ可能な文を追跡します。すべての文がリプレイ可能で、進行中のトランザクションがコミットしなかったか、セッションが対話中の場合、Oracleでは計画済または計画外のデータベース停止の後にコミットしていない作業をリプレイします。このモードでは、追加のアプリケーション・ステップを使用しないで自動的にトランザクション状態および非トランザクション状態を再確立します。

    • REPLAY_INITIATION_TIMEOUT = n: リプレイが開始できるようになるまでの期間(秒数)を設定する場合。たとえば、nの値を300に設定できます。

    • FAILOVER_RETRIES = 30: リプレイごとに接続の再試行回数を指定する場合

    • FAILOVER_DELAY = 10: 接続の再試行間の遅延時間を秒単位で設定する場合

    • GOAL = SERVICE_TIME: Oracle RACまたはOracle Global Data Servicesを使用する場合の推奨設定です

    • CLB_GOAL = LONG: Oracle RACまたはOracle Global Data Servicesを使用する場合の推奨設定です

    • COMMIT_OUTCOME = TRUE: トランザクション・ガードを使用している場合、-commit_outcomeサービス・パラメータにより、COMMITが実行されて停止が発生した後にトランザクション・コミット結果にアクセスできるかどうかが決まります。Oracle Databaseでは常にCOMMITアクションが永続的になりますが、トランザクション・ガードではCOMMITの結果が永続的になります。

    • FAILOVER_RESTORE = AUTO | LEVEL1: 透過的アプリケーション・コンティニュイティにFAILOVER_RESTORE=AUTOを、手動アプリケーション・コンティニュイティにFAILOVER_RESTORE=LEVEL1を使用します。リプレイの開始前に、接続プールに事前設定されているクライアント状態:が自動的にリストアされます(AUTOCOMMIT状態(JavaおよびSQL*Plus用)、NLS状態およびTAGS (MODULE、ACTION、ECID、CLIENT_ID、CLIENT_INFO)状態など)。

警告:

DB_NAMEまたはDB_UNIQUE_NAMEに対応するデータベース・サービスは使用しないでください。また、高可用性のデフォルト・データベース・サービスも使用しないでください。このサービスは有効化および無効化できず、Oracle RACで再配置することもOracle Data Guardに切り替えることもできないためです。このサービスは、Oracle Enterprise Manager Cloud Control (Cloud Control)およびDBA用として予約されています。

親トピック: アプリケーション・コンティニュイティの構成

6.6.4 アプリケーション・コンティニュイティのリプレイ前の初期状態の確立

一部のアプリケーションは、接続を使用できるようにするために、まず、初期状態を設定します。

この項のトピックは、リクエストの開始時にのみ状態を設定するアプリケーションや、事前設定された状態で接続を使用することでパフォーマンスが向上するステートフル・アプリケーションに適用されます。

  • アプリケーション・コンティニュイティの初期状態の確認
    アプリケーションで初期状態が必要な場合は、必要な状態が一般的な状態であるかどうか、またはコールバックを追加する必要があるかどうかを確認します。
  • FAILOVER_RESTORE
    FAILOVER_RESTOREをLEVEL1(手動アプリケーション・コンティニュイティの場合)またはAUTO(透過的アプリケーション・コンティニュイティの場合)に設定すると、リクエストのリプレイ前に一般的な状態の初期設定が自動的にリストアされます。
  • FAILOVER_RESTOREによってリストアされる状態
    このトピックでは、FAILOVER_RESTOREがLEVEL1またはAUTOに設定されている場合に、リストアされるセッション状態とサポートされないセッション状態を示します。
  • FAILOVER_RESTORE拡張
    Oracle Database 19.5およびOracleクライアント・ドライバ19.5以降では、アプリケーションが共通のクライアント側セッション状態以外のセッション状態を使用する場合、FAILOVER_RESTOREは、リクエストがリプレイされる前にALTER SESSIONで設定したすべてのセッション・パラメータをリストアします。
  • FAILOVER_RESTOREのためのキーストアの構成
    次のステップを使用し、FAILOVER_RESTOREで使用するためのソフトウェア・キーストア(ウォレット)と透過的データ暗号化(TDE)を使用してディクショナリ資格証明の暗号化を構成します。
  • FAILOVER_RESTOREのためのウォレットとSQLNET.ORAの構成
    次のステップを使用し、FAILOVER_RESTOREで使用するためのウォレットの場所を指すためにSQLNET.ORAを使用してディクショナリ資格証明の暗号化を構成します。
  • FAILOVER_RESTORE = NONEおよびコールバックなし
    Oracle Database 18c以降のリリースのデータベースおよびクライアントでは、すべてのアプリケーションについてFAILOVER_RESTOREをLEVEL1またはAUTOに設定することをお薦めします。
  • 接続ラベリング
    ベスト・プラクティスとして、汎用プール機能である接続ラベリングを使用することをお薦めします。
  • 接続初期化コールバック
    リプレイ・ドライバがアプリケーション・コールバックを使用して実行時およびリプレイ時にセッションの初期状態を設定する場合、コールバック・インタフェースは、ドライバがJDBCドライバであるかOCIドライバであるかによって異なります。

親トピック: アプリケーション・コンティニュイティの構成

6.6.4.1 アプリケーション・コンティニュイティの初期状態の確認

アプリケーションで初期状態が必要な場合は、必要な状態が一般的な状態であるかどうか、またはコールバックを追加する必要があるかどうかを確認します。

アプリケーションで接続が使用できるようになる前にアプリケーションによって接続の初期状態が設定される場合、アプリケーション・コンティニュイティはリプレイの開始前にこの初期状態を確立する必要があります。この項のトピックに示す一般的な状態では、FAILOVER_RESTOREによって状態がリストアされます。ただし、一般的な状態について説明しているトピックを確認する必要があります。アプリケーションで事前設定される状態が示されおらず、アプリケーションで初期状態が必要な場合は、別のコールバックを追加する必要があります。

次に、事前設定が可能な状態の例を示します。

  • PL/SQLパッケージの状態
  • NLS設定
  • オプティマイザ設定

リクエスト時に、アプリケーション・コンティニュイティはリクエストの状態全体を再確立します。この前提条件は、アプリケーション・コンティニュイティがリプレイを開始する前の初期状態のためのものです。

必要とされるすべての状態がFAILOVER_RESTOREによってリストアされる場合、コールバックは不要です。これは、ほとんどすべてのアプリケーションに当てはまります。

関連項目:

各リリースでリストアされるパラメータが増えるため、ご使用のプラットフォーム用の『Oracle Databaseリリース・ノート』を参照してください

親トピック: アプリケーション・コンティニュイティのリプレイ前の初期状態の確立

6.6.4.2 FAILOVER_RESTORE

FAILOVER_RESTOREをLEVEL1(手動アプリケーション・コンティニュイティの場合)またはAUTO(透過的アプリケーション・コンティニュイティの場合)に設定すると、リクエストのリプレイ前に一般的な状態の初期設定が自動的にリストアされます。

FAILOVER_RESTOREは、サービスの設定です。Oracle Database 12.2以降で使用可能なFAILOVER_RESTOREにより、クライアント側のアプリケーションに使用可能なすべてのセッション・ステートが自動的にリストアされます。

すべてのアプリケーションでFAILOVER_RESTOREをLEVEL1またはAUTOに設定することをお薦めします。

リストアされるクライアント側のセッション状態については、「FAILOVER_RESTOREによってリストアされる状態」を参照してください。

6.6.4.3 FAILOVER_RESTOREによってリストアされる状態

このトピックでは、FAILOVER_RESTOREがLEVEL1またはAUTOに設定されている場合に、リストアされるセッション状態とサポートされないセッション状態を示します。

リストアされるセッション状態

  • NLS_CALENDAR
  • NLS_CURRENCY
  • NLS_DATE_FORMAT
  • NLS_DATE_LANGUAGE
  • NLS_DUAL_CURRENCY
  • NLS_ISO_CURRENCY
  • NLS_LANGUAGE
  • NLS_LENGTH_SEMANTICS
  • NLS_NCHAR_CONV_EXCP
  • NLS_NUMERIC_CHARACTER
  • NLS_SORT
  • NLS_TERRITORY
  • NLS_TIME_FORMAT
  • NLS_TIME_TZ_FORMAT
  • TIME_ZONE
  • NLS_TIMESTAMP_FORMAT
  • NLS_TIMESTAMP_TZ_FORMAT
  • CURRENT_SCHEMA
  • MODULE
  • ACTION
  • CLIENT_ID
  • AUTOCOMMIT状態(JavaおよびSQL*Plusの場合)
  • CONTAINER (PDB)およびSERVICE
  • ROLES (引き続きコールバックを必要とするセキュア・ロールは除く)
  • ROW_ARCHIVAL
  • EDITION
  • ERROR_ON_OVERLAP_TIME
  • SQL_TRANSLATION_PROFILE
  • CLIENT_INFO(JDBC)

FAILOVER_RESTORE=AUTOではリストアされないセッション状態

次のものはTHINドライバではサポートされていません。そのため、自動リストア・オプションから除外されます。

  • NLS_COMP
  • CALL_COLLECT_TIME
  • CLIENT_INFO
6.6.4.4 FAILOVER_RESTORE拡張

Oracle Database 19.5およびOracleクライアント・ドライバ19.5以降では、アプリケーションが共通のクライアント側セッション状態以外のセッション状態を使用する場合、FAILOVER_RESTOREは、リクエストがリプレイされる前にALTER SESSIONで設定したすべてのセッション・パラメータをリストアします。

フェイルオーバー時に、拡張FAILOVER_RESTOREは、セッションで変更されたセッション・パラメータをリストアします。リストアされるセッション・パラメータには、セッションで設定されたoptimizer_capture_sql_plan_baselinesやcreate_stored_outlinesなどがあります。

セッション・パラメータのリストアにログオン・トリガー、接続ラベルまたはコールバックをすでに使用している場合は、それらを引き続き使用できます。ラベルとコールバックは、拡張FAILOVER_RESTOREの有無にかかわらず完全にサポートされています。拡張FAILOVER_RESTOREの使用には、アプリケーションの変更に合わせた更新の必要がないという利点があります。

この機能を使用するには、FAILOVER_RESTOREをLEVEL1またはAUTOに設定して、ディクショナリ資格証明がシステムで暗号化されるようにする必要があります。

ディクショナリ資格証明の暗号化用にウォレットまたはキーストアを追加する方法は2つあります。

  • 推奨: WALLET_ROOTデータベース・インスタンス初期化パラメータを使用して、ウォレットの場所を指定します。ウォレットの場所に初期化パラメータを使用すると、Oracle Real Application Clusters (Oracle RAC)とOracle Data Guardの間の一貫性が確保されます。この方法には、データベースのローリング再起動が必要です。

  • ウォレットの場所を指すように、データベース・サーバーのTNS_ADMINディレクトリ内にあるsqlnet.oraファイルを変更します。この方法ではデータベースの再起動は必要ありません。ただし、Microsoft Windowsオペレーティング・システムでデータベースを実行している場合は再起動が必要です。すべてのORACLE_HOMEディレクトリでsqlnet.oraファイルの一貫性が保たれていることを確認する必要があります。また、データベースのアップグレードを実行するときには、sqlnet.oraに追加のメンテナンスが必要になる場合もあります。

6.6.4.5 FAILOVER_RESTOREのためのキーストアの構成

次のステップを使用して、FAILOVER_RESTOREで使用するためのソフトウェア・キーストア(ウォレット)と透過的データ暗号化(TDE)を使用してディクショナリ資格証明の暗号化を構成します。

  1. Oracle Autonomous Databaseを使用している場合は、ここに示すステップを実行する必要はありません。
    Oracle Autonomous Databaseの場合、すでにソフトウェア・キーストアが存在していて、ディクショナリ資格証明が暗号化されています。
  2. Oracle Autonomous Databaseを使用していない場合は、すでにシステムがディクショナリ資格証明の暗号化を強制するように構成されているかどうかを確認します。
    1. 次のSQL問合せを使用して、ウォレット(キーストア)が存在していることを確認します。
      SELECT con_id, wrl_type, status , wallet_type FROM V$ENCRYPTION_WALLET
ORDER BY con_id;
    CON_ID WRL_TYPE     STATUS   WALLET_TYPE
---------- ------------ -------- -----------
         0 FILE         OPEN     PASSWORD

      このSQL問合せで行が戻されない場合は、ウォレット(キーストア)が存在していません。

    2. 次のSQL問合せを使用して、ディクショナリ資格証明が暗号化されていることを確認します。
      SQL> SELECT enforcement FROM DICTIONARY_CREDENTIALS_ENCRYPT;
ENFORCEMENT
---------------
ENABLED

      このSQL問合せでDISABLEDが返される場合、ディクショナリは暗号化されません。

    ウォレットと暗号化したディクショナリ資格証明の準備が完了していると、サービスの属性を設定することで拡張FAILOVER_RESTOREを使用できます。この手順の以降のステップを完了する必要はありません。

    既存のウォレットがない場合やディクショナリ資格証明の暗号化を有効にする必要がある場合は、次のステップに進みます。

  3. ソフトウェア・キーストアを使用するようにデータベースを構成します。

    次のステップは、SYSKM権限を持つオペレータが実行する必要があります。オペレータ・ユーザーにロールSYSKMを付与します。

    1. 必要に応じて、ウォレットを格納するディレクトリを作成します。

      選択した場所はOracle RACノード間で共有して、Oracle Data Guardサイトにレプリケートする必要があります。Oracle RACの場合、ディレクトリは共有記憶域上にあることが必要です。

    2. 静的な初期化パラメータWALLET_ROOTを変更します。
      パラメータの値は、ウォレットが格納されているディレクトリにする必要があります。
      ALTER SYSTEM SET WALLET_ROOT='/myOracleBase/admin/wallet/' SCOPE=spfile;
    3. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'
    4. データベース・インスタンスのローリング再起動を実行し、新しい初期化パラメータをアクティブ化します。

      たとえば、orclという名前の2ノード・クラスタ・データベースがあり、インスタンス名がorcl1とorcl2の場合は、次のコマンドを使用して、データベースが完全に停止しないように各インスタンスを個別に停止および再起動します。 

      $ srvctl stop instance -db orcl -instance orcl1 -drain_timeout 600 -stopoption IMMEDIATE
$ srvctl start instance -db orcl -instance orcl1
 
srvctl stop instance -db orcl -instance orcl2 -drain_timeout 600 -stopoption IMMEDIATE
srvctl start instance -db orcl -instance orcl2

      注意:

      フリート・パッチ適用およびプロビジョニングを使用すると、このプロセスが自動化されます。また、パッチ・アップグレード時にパラメータを変更する場合は、かわりに使用できます。
    5. インスタンスの再起動後に、パラメータが正しい値に設定されていることを確認します。
      SQL> SHOW PARAMETER WALLET_ROOT;

SQL> SHOW PARAMETER TDE_CONFIGURATION;
  4. パスワードを使用してキーストアを作成します(まだキーストアが存在しない場合)。

    次の例では、passwordはキーストアのパスワードです。パスワードの大文字と小文字は区別されます。キーストアのパスワードはデータベース・ユーザーのパスワードと同じ規則に従います。 

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY "password";
  5. キーストアを開いて、暗号化キーを設定します。

    データベースがOracle Multitenantデータベースとして構成されている場合は、CONTAINER=all句を使用して、各PDBにキーストアと暗号化キーを設定する必要があります。次の例では、passwordはキーストアのパスワードです。 

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP CONTAINER=all;

    データベースがOracle Multitenantデータベースとして構成されていない場合は、次のSQLコマンドを使用します。passwordは、キーストアのパスワードです。 

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password";
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP;
  6. データベース・ディクショナリ資格証明を暗号化します。

    SYSKMロールを持つ演算子を使用して、コンテナ・データベース(CDB)ルートと各PDBから次のSQLコマンドを実行します。 

    ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

情報の暗号化と復号化は、フェイルオーバーのリストア中にサーバーで自動的に実行されます。

警告:

ソフトウェア・キーストアとウォレットの場所をバックアップするようお薦めします。TDEソフトウェア・キーストアまたはWALLET_ROOTの場所を失わないようにしてください。そうしたときに、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティの場合、新しいキーストアは作成できますが、暗号化したディクショナリ資格証明は再インスタンス化が必要になります。ウォレット・キーに不一致があると、フェイルオーバーは成功しません。

6.6.4.6 FAILOVER_RESTOREのためのウォレットとSQLNET.ORAの構成

次のステップを使用して、FAILOVER_RESTOREで使用するためのウォレットの場所を指すためにSQLNET.ORAを使用してディクショナリ資格証明の暗号化を構成します。

この方法ではデータベースの再起動は必要ありません。ただし、Microsoft Windowsオペレーティング・システムでデータベースを実行している場合は再起動が必要です。すべてのORACLE_HOMEディレクトリでsqlnet.oraファイルの一貫性が保たれていることを確認する必要があります。

  1. Oracle Autonomous Databaseを使用している場合は、ここに示すステップを実行する必要はありません。
    Oracle Autonomous Databaseの場合、すでにソフトウェア・キーストアが存在していて、ディクショナリ資格証明が暗号化されています。
  2. Oracle Autonomous Databaseを使用していない場合は、すでにシステムがディクショナリ資格証明の暗号化を強制するように構成されているかどうかを確認します。
    1. 次のSQL問合せを使用して、ウォレットが存在していることを確認します。
      SELECT con_id, wrl_type, status , wallet_type FROM V$ENCRYPTION_WALLET
ORDER BY con_id;
    CON_ID WRL_TYPE     STATUS   WALLET_TYPE
---------- ------------ -------- -----------
         0 FILE         OPEN     PASSWORD

      このSQL問合せで行が戻されない場合は、ウォレット(キーストア)が存在していません。

    2. 次のSQL問合せを使用して、ディクショナリ資格証明が暗号化されていることを確認します。
      SQL> SELECT enforcement FROM DICTIONARY_CREDENTIALS_ENCRYPT;
ENFORCEMENT
---------------
ENABLED

      このSQL問合せでDISABLEDが返される場合、ディクショナリは暗号化されません。

    ウォレットと暗号化したディクショナリ資格証明の準備が完了していると、サービスの属性を設定することで拡張FAILOVER_RESTOREを使用できます。この手順の以降のステップを完了する必要はありません。

    既存のウォレットがない場合やディクショナリ資格証明の暗号化を有効にする必要がある場合は、次のステップに進みます。

  3. ウォレットを使用するようにデータベースを構成します。
    1. TNS_ADMIN環境変数を表示して、データベースで使用されるネットワーク構成ファイルの場所を探します。

      • LinuxおよびUNIXシステムでは、Oracleホーム・ソフトウェア所有者として、TNS_ADMIN環境変数の現在の設定を表示します。 

        $ env | grep TNS_ADMIN

      • Microsoft Windowsシステムでは、環境変数とレジストリ(パスComputer\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_HOME_NAME)の両方でTNS_ADMINの値セットを確認します。

      TNS_ADMIN変数が設定されない場合、Oracle Net構成ファイルには、デフォルトの場所である$ORACLE_BASE_HOME/network/adminが読取り専用のOracleホームとともに使用されます。
    2. 必要に応じて、ウォレットを格納するディレクトリを作成します。

      選択した場所はOracle RACノード間で共有して、Oracle Data Guardサイトにレプリケートする必要があります。Oracle RACの場合、ディレクトリは共有記憶域上にあることが必要です。

    3. SQLNET.ORAファイルを探して編集します。
      前述のサブステップで取得した場所を使用して、sqlnet.oraファイルを編集し、次のエントリを追加します。/myOracleWalletLocは、ウォレットを格納するために作成したディレクトリの完全パス名です。
      ENCRYPTION_WALLET_LOCATION =
  (SOURCE=
   (METHOD=FILE)
    (METHOD_DATA=
     (DIRECTORY=/myOracleWalletLoc)))
    4. 初期化パラメータTDE_CONFIGURATIONを変更して、ソフトウェア・キーストアを指定します。
      ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE=BOTH SID='*'
  4. パスワードを使用してキーストアを作成します(まだキーストアが存在しない場合)。

    次の例のmyOracleWalletLocは、ウォレット(またはキーストア)を格納するために作成したディレクトリのフルパス名です。passwordは、キーストアのパスワードです。パスワードの大文字と小文字は区別されます。キーストアのパスワードはデータベース・ユーザーのパスワードと同じ規則に従います。 

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/myOracleWalletLoc' IDENTIFIED BY "password";
  5. キーストアを開いて、暗号化キーを設定します。

    データベースがOracle Multitenantデータベースとして構成されている場合は、CONTAINER=all句を使用して、各PDBにキーストアと暗号化キーを設定する必要があります。次の例では、passwordはキーストアのパスワードです。 

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password" CONTAINER=all;
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP CONTAINER=all;

    データベースがOracle Multitenantデータベースとして構成されていない場合は、次のSQLコマンドを使用します。passwordは、キーストアのパスワードです。 

    
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "password";
ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY IDENTIFIED BY "password" 
WITH BACKUP;
  6. データベース・ディクショナリ資格証明を暗号化します。

    SYSKMロールを持つ演算子を使用して、コンテナ・データベース(CDB)ルートと各PDBから次のSQLコマンドを実行します。 

    ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS;

情報の暗号化と復号化は、フェイルオーバーのリストア中にサーバーで自動的に実行されます。

警告:

ウォレットの場所は、バックアップすることをお薦めします。ウォレットまたは場所は失われないようにしてください。そうしたときに、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティの場合、新しいウォレットは作成できますが、暗号化したディクショナリ資格証明は再インスタンス化が必要になります。

ウォレット・キーに不一致があると、フェイルオーバーは成功しません。

6.6.4.7 FAILOVER_RESTORE = NONEおよびコールバックなし

Oracle Database 18c以降のリリースのデータベースおよびクライアントでは、すべてのアプリケーションについてFAILOVER_RESTOREをLEVEL1またはAUTOに設定することをお薦めします。

FAILOVER_RESTOREをNONEに設定するのは、リリース18cより前のOracle Databaseデータベースおよびクライアントの場合です。この設定では、アプリケーションはプールからの接続を流用するときに、どのような状態も想定しません。また、初期状態を再確立するためにUCPやWebLogicラベルを使用します。

6.6.4.8 接続ラベリング

ベスト・プラクティスとして、汎用プール機能である接続ラベリングを使用することをお薦めします。

接続ラベリングを構成すると、アプリケーション・コンティニュイティではこの機能を使用してアプリケーションの状態を再作成します。接続ラベリングによって状態が再作成されるため、FAILOVER_RESTOREパラメータをNONEに設定できます。

このシナリオは、Universal Connection Pool (UCP)およびOracle WebLogic Serverに適用できます。接続で事前設定された状態を利用するようにアプリケーションを変更できます。接続ラベリングAPIにより、接続がどの程度一致しているかが判別されます。接続が流用されると、接続ラべリングによりコールバックを使用してギャップが移入されます。

6.6.4.9 接続初期化コールバック

リプレイ・ドライバがアプリケーション・コールバックを使用して実行時およびリプレイ時にセッションの初期状態を設定する場合、コールバック・インタフェースは、ドライバがJDBCドライバであるかOCIドライバであるかによって異なります。

このシナリオでは、Java Database Connectivity (JDBC)またはOracle Call Interface (OCI)のいずれかで、ドライバはアプリケーション・コールバックを使用して、実行時およびリプレイ時にセッションの初期状態を設定します。JDBCリプレイ・ドライバでは、oracle.jdbc.replay.OracleDataSourceインタフェースで接続初期化コールバックを登録および登録解除するために、接続初期化コールバックのインタフェースおよびメソッドがドライバに用意されています。OCIおよびOracle Data Provider for .NET (ODP.NET)では、透過的アプリケーション・フェイルオーバー(TAF)コールバックを登録します。

登録されると、接続がプールから流用されるたびに、またリカバリ可能なエラー後に再接続が成功するたびに、初期化コールバックが実行されます。(これは、JDBC/UCP初期化コールバックの場合に当てはまり、TAFに対しても同様にする必要があります。)ランタイムとリプレイの両方で同じコールバックを使用すると、セッションが最初に確立されたときと同じ初期化がリプレイ時に確立されます。アプリケーションは、初期化アクションがフェイルオーバー前の元の接続時のものと同じであることを確認する必要があります。コールバックの起動が失敗した場合、リプレイはその接続で無効になります。接続初期化コールバックは、アプリケーションにUCPとWebLogic接続ラベリングが実装されていないため、FAILOVER_RESTORE=AUTO(透過的アプリケーション・コンティニュイティの場合)またはFAILOVER_RESTORE=LEVEL1(手動アプリケーション・コンティニュイティの場合)の設定では自動的に状態がリストアできない場合にのみ使用します。

6.6.5 RESETSTATE

RESETSTATEサービス属性を使用すると、リクエスト内のアプリケーションで設定したセッション状態は、リクエストの終了時にクリアされます。

リクエストでセッション状態を設定すると、セッションは使用されたままになり、つまりセッション状態がクリアされていない場合、そのセッションの次の使用時にその状態が確認されます。たとえば、アプリケーションが接続を流用して接続プールに返却すると、そのセッションの次の使用時に、その前に使用していたセッション状態を確認できます。RESETSTATEを使用しない場合、アプリケーション開発者はカーソルを取り消して、接続を再利用する前に設定されていたセッション状態をクリアする必要があります。

RESETSTATEは、ステートレス・アプリケーションに使用します。このタイプのアプリケーションはリクエスト内のセッション状態を使用し、その後のリクエストでそのセッション状態に依存することはありません。リクエストに必要なセッション状態は、そのリクエスト自体に含まれています。ステートレス・アプリケーションの例として、RESTおよびOracle Application Expressがあります。

RESETSTATEは、アプリケーション・コンティニュイティまたは透過的アプリケーション・コンティニュイティの使用時に使用できます。RESETSTATEは、データベース・サービスの属性です。RESETSTATEを使用すると、アプリケーションは、リクエストの終了時にリセットされる状態を基にできます。

RESETSTATEをLEVEL1に設定すると、リクエストの明示的な終了時に次のセッション状態がリセットされます。RESETSTATEは、暗黙的なリクエスト境界には適用されません。

  • カーソルは取り消されます
  • PL/SQLグローバル変数はクリアされます
  • 期間がセッション・ベースの一時表は切り捨てられます
  • 期間がセッション・ベースの一時LOBはクリアされます

RESETSTATEにより、透過的アプリケーション・コンティニュイティの使用時の保護が向上します。RESETSTATEは、非常に重要なデータベース機能です。つまり、開発者は、セッションがOracle接続プールに戻される際、クリーンなセッション状態を基にできます。

親トピック: アプリケーション・コンティニュイティの構成

6.7 アプリケーション・コンティニュイティの操作および使用の管理

アプリケーション・コンティニュイティの使用を管理する方法とアプリケーションで使用する方法について説明します。

親トピック: アプリケーション・コンティニュイティの確保

6.7.1 計画メンテナンスに対するアプリケーション・コンティニュイティの使用

計画メンテナンスの場合、完了していないリクエストについてアプリケーション・コンティニュイティと組み合せて、Oracle接続プールからリクエストを排出することをお薦めします。

これは、完了する必要があるリカバリが最小限である場合、最も影響の少ない手順です。パッチが適用されたソフトウェアにスイッチオーバーするには、インスタンスを停止する必要があります。

  1. FAN対応プール(OCI、UCP、WebLogic Server、ODP.NET管理ドライバ、管理対象外ドライバなど)を使用します。

    FAN計画イベントの場合、リクエスト境界で排出します。

    注意:

    ODP.NET管理ドライバは、アプリケーション・コンティニュイティをサポートしていません。

  2. srvctl relocate serviceコマンドを使用して、セッションを中断することなくインスタンスのサービスを再配置します。または、均一サービスの場合、インスタンスでsrvctl stop serviceコマンドを使用します(-forceパラメータは使用しないでください)。

    FANの計画イベントはアイドル・セッションを即時にクリアして、アクティブ・セッションをチェックイン時(リクエストの最後)に解放するとマーク付けします。これによって作業を妨げずにセッションがインスタンスから排出されます。

  3. 一部のセッションがチェックインしておらず、インスタンスを停止する時間になったら、インスタンスを停止(中断)します。

    アプリケーション・コンティニュイティが有効なプール(UCP、WebLogic、Tuxedo、ODP.NET、およびOCI)、およびbeginRequest/endRequestを追加するJavaプールの場合、アプリケーション・コンティニュイティは、そうした残っているセッションをリカバリしようとします。

  4. インスタンスおよびサービスを再起動します。

    実行時ロード・バランシング(がもし有効な場合)では、次のリクエスト境界でリストアされたインスタンスにセッションを戻して均衡化します。

関連項目

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.2 可変値の管理

可変値を管理するには、特定の権限を付与する必要があります。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.2.1 可変関数とアプリケーション・コンティニュイティ

リクエストがリプレイされると、可変オブジェクトのデフォルトおよび目的の処理が変化する可能性があります。

現在、可変関数値を保持するためのサポートは、SYSDATE、SYSTIMESTAMP、SYS_GUIDおよびsequence.NEXTVALに対して提供されています。元の値が保持されていないため、これらの可変オブジェクトの別の値がクライアントに戻されると、クライアントが認識する値が異なるため、リプレイは拒否されます。アプリケーションが元の値を使用できる場合、所有されている順序にはKEEP句を使用し、他のユーザーにはGRANT KEEPを使用して、可変関数を構成してください。(ほとんどのアプリケーションでは、バインド変数の一貫性を維持するために、リプレイ時に順序値を保持する必要があります。)

注意:

SYS_GUID値の保持は、シリアル実行計画に対してのみサポートされています。パラレル問合せを使用する場合、アプリケーション・コンティニュイティは、SYS_GUIDの元の値をリストアできません。

次の表に、リプレイ時の可変関数の処理の例を製品別に示します。(実際の実装は特定の製品およびリリースによって異なります。)

表6-4 リプレイ時の可変オブジェクトの処理の製品別の例

可変関数 製品1 製品2 製品3

SYSDATE、SYSTIMESTAMP

オリジナル

オリジナル

現行

順序NEXTVALおよびCURRVAL

オリジナル

オリジナル

(該当なし)

SYS_GUID

オリジナル

(該当なし)

(該当なし)

アプリケーション・コンティニュイティがリプレイ時に元のファンクション結果を保持および使用できるようにするには、次のようにします。

  • アプリケーションを実行するデータベース・ユーザーに、KEEP DATE TIMEおよびKEEP SYSGUID権限を付与し、値を保持する順序ごとにKEEP SEQUENCEオブジェクト権限を付与できます。次に例を示します。 

    GRANT KEEP DATE TIME TO user2;
GRANT KEEP SYSGUID TO user2;
GRANT KEEP SEQUENCE ON sales.seq1 TO user2;

    注意:

    • GRANT ALL ON objectには、KEEP DATE TIMEおよびKEEP SYSGUID権限とKEEP SEQUENCEオブジェクト権限は含まれません(つまり、これらによって提供されるアクセスは承認しません)。

    • 可変関数サポートに関連する権限はアプリケーション・ユーザーに対してのみ付与し、各アプリケーション・ユーザーに対して必要な権限のみを付与します。

    • リプレイを有効化するアプリケーションを実行するデータベース・ユーザーには、DBA権限を付与しないでください。

  • アプリケーション内の順序には、KEEP属性を使用できます。この属性は、順序所有者に対してsequence.NEXTVALの元の値を保持することにより、リプレイ時にキーが一致するようにします。ほとんどのアプリケーションでは、リプレイ時に順序値を保持する必要があります。次の例では、順序に対してKEEP属性を設定しています(この場合は、文を実行するユーザーが所有する順序ですが、他の場合はGRANT KEEP SEQUENCEを使用してください)。 

    SQL> CREATE SEQUENCE my_seq KEEP;
SQL> -- Or, if the sequence already exists but without KEEP:
SQL> ALTER SEQUENCE my_seq KEEP;

    注意:

    ALTER SEQUENCE ... KEEP/NOKEEPの指定は、順序の所有者に適用されます。これは、KEEP SEQUENCEオブジェクト権限を持つ他のユーザー(所有者ではありません)には影響しません。すべてのユーザーにNOKEEPを指定する場合、これらのユーザーにKEEP SEQUENCEオブジェクト権限を付与しない(または、すでに権限が付与されている場合はそれを取り消さない)ようにしてください。

  • リプレイ時にファンクション結果(名前付きファンクションの場合)を保持するには、ファンクションを起動するユーザーにDBAがKEEP権限を付与する必要があります。このセキュリティ制限により、ユーザーによって所有されていないコードに対するファンクション結果をリプレイのために保存およびリストアできるようになります。

6.7.2.2 可変に対するKEEP権限の付与および取消し

リプレイで関数の結果を保持するには、関数を呼び出すユーザーにKEEP権限を付与する必要があります。

  • SYSDATEおよびSYSTIMESTAMPまたはSYSGUIDの可変を維持する権限を付与するには、次のようにします。
    GRANT [KEEP DATE TIME | KEEP SYSGUID]...[to USER]

    たとえば、次のように、元の日付でOracle E-Business Suiteを使用できます。

    GRANT KEEP DATE TIME, KEEP SYSGUID to [custom user];
GRANT KEEP DATE TIME, KEEP SYSGUID to [apps user];
  • SYSDATEおよびSYSTIMESTAMPまたはSYSGUIDの可変を維持する権限を取り消すには、次のようにします。
    REVOKE [KEEP DATE TIME | KEEP SYSGUID]...[from USER]

親トピック: 可変値の管理

6.7.2.3 Oracle順序の可変を維持するための権限の付与

キーが一致するようにリプレイでsequence.nextvalの元の値を維持するには、順序に対する権限を付与する必要があります。

  • 順序の所有者としての権限を付与するには、次のようにします。
    CREATE SEQUENCE [sequence object] [KEEP|NOKEEP];
ALTER SEQUENCE [sequence object] [KEEP|NOKEEP];
  • 順序を使用するその他のユーザーに対して権限の付与および取消しを行うには、次のようにします。
    GRANT KEEP SEQUENCE...[to USER] on [sequence object];
REVOKE KEEP SEQUENCE...[from USER] on [sequence object];

    たとえば、次のように、元の順序値でOracle E-Business Suiteを使用できます。

    GRANT KEEP SEQUENCE to [apps user] on [sequence object];
GRANT KEEP SEQUENCE to [custom user] on [sequence object];

親トピック: 可変値の管理

6.7.2.4 可変に対する権限のルール

これらの考慮事項は、可変関数に対する権限の付与および取消しに適用されます。

  • ユーザーのオブジェクトに対してすべてを付与していても、可変は除外されています。可変には明示的な付与が必要です。SYS、AUDSYS、GSMUSER、SYSTEMなど、Oracle Databaseによって提供または作成されるユーザーへの可変の付与はサポートしていません。

  • DBAロールには、可変権限が含まれます。

  • ユーザーに可変が付与されている場合、(SYS_GUID、SYSDATEおよびSYSTIMESTAMPで)可変関数が呼び出されたときに、オブジェクトは可変アクセスを継承します。

  • 順序オブジェクトに対する可変の維持が取り消されると、そのオブジェクトを使用するSQLまたはPL/SQLコマンドは、その順序の可変コレクションまたはアプリケーションを許可しません。

  • ランタイムおよびフェイルオーバー間で権限が取り消されると、収集された可変は適用されません。

  • ランタイムおよびフェイルオーバー間で権限が付与されると、可変は収集されず、したがって何も適用されません。

親トピック: 可変値の管理

6.7.3 保護レベルの統計

リクエスト境界および保護レベルの統計を使用してカバレッジのレベルを監視します。

アプリケーション・コンティニュイティはシステム、セッション、およびサービスの統計を収集し、これにより、ユーザーは保護レベルを監視できるようになります。統計情報は、V$SESSTAT、V$SYSSTATで入手でき、サービス統計が有効になっている場合は、V$SERVICE_STATSでも入手できます。たとえば、V$SESSTATを問い合せてV$STATNAMEと結合した場合は、次のような出力が表示されます。 

NAME                                                             VALUE
---------------------------------------------------------------- ----------
cumulative begin requests                                               731
cumulative end requests                                                 739
cumulative user calls in requests                                      7285
cumulative user calls protected by Application Continuity              7228
cumulative time in requests                                      2665167909

これらの統計は自動ワークロード・リポジトリ(AWR)に保存され、AWRレポートで使用できます。統計には、次の情報が含まれます。

  • 完了リクエスト/秒
  • リクエストでのユーザー・コール
  • 保護されたユーザー・コール

AWRレポートの出力は、次のようになります。

Statistic                                Total    per Second    per Trans
---------------------------------------- -------- ------------- ---------
cumulative requests                       177,406          49.2       5.0
cumulative user calls in request          493,329         136.8      13.8
cumulative user calls protected           493,329         136.8      13.8

保護レベルの統計を有効にするには、(_request_boundaries = 3)を使用します。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.4 セッション状態一貫性

セッション状態一貫性は、リクエスト中に非トランザクション状態がどのように変化するかを示します。

  • セッション状態一貫性について
    session_stateサービス・パラメータを使用する方法について説明し、そのパラメータを使用するためのOracleガイドラインを確認します。
  • 自動的なセッション状態の一貫性
    サービス・パラメータsession_stateをAUTOに設定した場合、透過的アプリケーション・コンティニュイティでは、リカバリ可能な停止の後にデータベース・セッションがリカバリできるようにセッションおよびトランザクションの状態を追跡および記録します。session_stateをAUTOに設定することは、透過的アプリケーション・コンティニュイティで唯一許容される値です。
  • 動的なセッション状態の一貫性
    セッション状態の値がFAILOVER_RESTOREまたは初期化コールバックの追加で完全にリストアできない場合、セッションの状態は動的になります。
  • 静的なセッション状態の一貫性
    Staticモードは、長時間実行するステートレスのアプリケーションに使用します。ステートレスではないアプリケーションには、Staticモードを使用しないでください。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.4.1 セッション状態一貫性について

session_stateサービス・パラメータを使用する方法について説明し、そのパラメータを使用するためのOracleガイドラインを確認します。

セッション状態一貫性を確保するために、透過的アプリケーション・コンティニュイティで使用可能なサービス・パラメータsession_stateをAUTOに設定することをお薦めします。透過的アプリケーション・コンティニュイティでは、セッション状態を追跡および管理します。透過的アプリケーション・コンティニュイティを使用することを選択した場合、セッション状態の一貫性を確保するために何かを行う必要はありません。

手動アプリケーション・コンティニュイティの場合、session_stateをDYNAMICまたはSTATICに設定できます。session_stateをDYNAMICまたはSTATICに設定するのは、アプリケーションを十分に理解し、アプリケーションが設定された値を変更しないと想定される場合のみです。

セッション状態の例としては、NLS設定(グローバリゼーション・サポート)、オプティマイザのプリファレンス、イベントの設定、PL/SQLグローバル変数、一時表、アドバンスト・キュー、ラージ・オブジェクト(LOB)、結果キャッシュがあります。コミットされたトランザクションで非トランザクション値が変更される場合は、デフォルト値DYNAMICを使用します。

COMMITの実行後にDYNAMICモードを使用すると、そのトランザクションで状態が変更された場合、セッションが失われたときに、その状態を再確立するためのトランザクションのリプレイができなくなります。初期設定後のセッション状態が静的と動的のどちらであるか、さらにCOMMIT操作後の処理続行が正しいかどうかに応じて、アプリケーションを分類できます。

AUTOモードはほとんどすべてのアプリケーションに適しています。顧客またはユーザーがアプリケーションを変更できる場合は、AUTOまたはDYNAMICモードを使用する必要があります。AUTOモードは、DYNAMICモードの新しいバージョンであり、可能な場合は自動的に再度有効になる追加機能を備えています。

注意:

長時間実行するステートレス・アプリケーションの場合、session_stateをAUTOまたはSTATICに設定します。ステートレスでないアプリケーションの場合、session_stateをSTATICに設定しないでください。手動アプリケーション・コンティニュイティを必要としない場合、session_stateをAUTOに設定することをお薦めします。
6.7.4.2 自動的なセッション状態の一貫性

サービス・パラメータsession_stateをAUTOに設定した場合、透過的アプリケーション・コンティニュイティでは、リカバリ可能な停止の後にデータベース・セッションがリカバリできるようにセッションおよびトランザクションの状態を追跡および記録します。session_stateをAUTOに設定することは、透過的アプリケーション・コンティニュイティで唯一許容される値です。

AUTOに設定すると、アプリケーションがユーザー・コールを発行するときに、状態追跡インフラストラクチャによりセッション状態の使用状況が分類されます。追跡されるセッション状態は監視および検証されます。

6.7.4.3 動的なセッション状態の一貫性

セッション状態の値がFAILOVER_RESTOREまたは初期化コールバックの追加で完全にリストアできない場合、セッションの状態は動的になります。

最初のトランザクションが完了した後、フェイルオーバーは次のリクエストが開始されるまでは内部的に無効化されます。Dynamicセッション状態一貫性モードでは、リクエスト中に状態の変更が行われ、次のリクエストの開始時点でリプレイが有効化されます。

トランザクションの実行時に非トランザクション・セッション状態が変更される場合、セッション状態一貫性モードをDynamicに設定します。ランタイム時に変更される可能性がある非トランザクション・セッション状態の例には、ALTER SESSION、PL/SQLグローバル変数、SYS_CONTEXTおよび一時表のコンテンツがあります。アプリケーションがトランザクション以外の状態をトランザクション内で変更し、それをコミットする場合、この状態はリプレイできないため、状態の設定をDynamicに設定する必要があります。アプリケーション・コンティニュイティに対してDynamicモードを使用する場合、次のリクエストが開始されるまではCOMMIT時にリプレイは無効です。デフォルト値はDynamicです。

セッション状態一貫性モードがDynamicのときには、リクエスト中に非トランザクションのセッション状態(NTSS)が変更されます。

リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、COMMIT時(endRequestコール)または制限付きのコール時に無効化されます。次に、3つのアプリケーション・シナリオのステップ・ロジックを示します。

  • トランザクションなし

  • 最後の文としてCOMMITが使用されたトランザクション

  • COMMIT文が埋め込まれたトランザクション

トランザクションなしのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. その他のアクションを実行します。

  5. チェックインします。

  6. リクエストを終了し、リプレイを無効化します。

最後の文としてCOMMITが使用されたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. チェックインします。

  8. リクエストを終了します。

COMMIT文が埋め込まれたトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. その他のアクションを実行します。

  6. コミット(リプレイを無効化)します。

  7. その他のアクション。この間、アプリケーションはアプリケーション・コンティニュイティでカバーされません。

  8. チェックインします。

  9. リクエストを終了します。

6.7.4.4 静的なセッション状態の一貫性

Staticモードは、長時間実行するステートレスのアプリケーションに使用します。ステートレスではないアプリケーションには、Staticモードを使用しないでください。

NLS設定、SYS_CONTEXT、PL/SQL変数、およびオプティマイザ・プリファレンスなどのすべての非トランザクション状態の変更がリクエストごとに1回の初期化の一環として設定され、このセッション状態がトランザクション中に変更されない場合にのみ、セッション状態一貫性モードをStaticに設定します。これらの設定は、FAILOVER_RESTORE=LEVEL1、コールバック、またはラベルなどを使用した接続の確立時、またはプールからの各チェックアウト時に、接続ごとに1回確立できます。

アプリケーション・コンティニュイティに対してStaticモードを使用する場合、トランザクションのフェイルオーバーはリクエストの最初のトランザクションの後も続行されます。これは、beginRequestを1回設定して、バッチ・ジョブや長いレポートなど、長時間の処理操作を実行するアプリケーションに役立ちます。

静的モードは、トランザクションで非トランザクション状態を変更する呼出しを使用するアプリケーションではサポートされません。このようなコールの具体的な例を次に示します。

  • PL/SQLサブプログラム

  • SYS_CONTEXT

  • ALTER SESSION

静的モードは慎重に指定してください。静的モードは、アプリケーションがトランザクション内で非トランザクションのセッション状態を変更しない場合にのみ使用します。セッション状態一貫性モードをStaticとして宣言することは、リクエスト内の最初のCOMMITの後に続行しても安全であることを示します。動的モードはほとんどのアプリケーションに適しています。ユーザーがアプリケーションを変更またはカスタマイズできる場合は、静的モードを使用しないでください。

セッション状態一貫性モードがStaticのときに、リクエスト中の非トランザクションのセッション状態は一定に保たれます(つまり、変更されません)。

リプレイ(つまり、アプリケーション・コンティニュイティ)はbeginRequestコールで有効化され、制限付きコール、disableReplayまたはOCIRequestDisableReplayコール、またはendRequestコールで無効化されます。

次に、3つのアプリケーション・シナリオのステップ・ロジックを示します。

  • トランザクションなし

  • 最後の文としてCOMMITが最後に使用される1つ以上のトランザクション

  • アプリケーション・コンティニュイティを無効化する制限付きコールを使用したトランザクションが続くCOMMIT文を使用したトランザクション

トランザクションなしのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. その他のアクションを実行します。

  5. チェックインします。

  6. リクエストを終了し、リプレイを無効化します。

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

1つ以上のトランザクション(それぞれの最後の文としてCOMMITが使用される)のリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. トランザクションがコミットされます。

  6. トランザクションがパージされます。

    (追加トランザクションごとに、ステップ4から6が実行されます。)

  7. その他のアクションを実行します。

  8. チェックインします。

  9. リクエストを終了します。

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

制限付きコールを使用したトランザクションが続くCOMMIT文を使用したトランザクションのリクエストの場合、論理的なステップは次のようになります。

  1. チェックアウトします。

  2. リクエストを開始し、リプレイを有効化します。

  3. 1つ以上のSELECT文、および場合によっては他のPL/SQL文を発行します。

  4. トランザクションが開始されます。

  5. トランザクションがコミットされます。

  6. トランザクションがパージされます。

  7. 2番目のトランザクションが開始されます。

  8. トランザクションが制限付きのコールを発行し、これによってアプリケーション・コンティニュイティが無効化されます。

  9. トランザクションがパージされます。

  10. その他のアクションを実行します

  11. チェックインします。

  12. リクエストを終了します。

リプレイは、endRequest、制限付きコール、および明示的なdisableReplayまたはOCIRequestDisableReplayコールで無効化されます。

関連項目

親トピック: セッション状態一貫性

6.7.5 アプリケーション・コンティニュイティでの再接続の遅延

手動コンティニュイティまたは透過的アプリケーション・コンティニュイティを使用して再接続を管理するためのパラメータの設定方法について説明し、シングル・インスタンス・データベースおよびOracle Real Application Clusters (Oracle RAC)データベースの例を確認します。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.5.1 アプリケーション・コンティニュイティでの再接続を遅延させる方法の理解

計画および計画外の停止を管理するには、アプリケーション・コンティニュイティの管理に使用するパラメータについて理解します。

デフォルトでは、アプリケーション・コンティニュイティがフェイルオーバーを開始した場合、ドライバが、サービスを利用できるインスタンスで実行中の作業のリカバリを試みます。作業をリカバリするために、ドライバはインスタンスとの良好な接続を確立する必要があります。サービスが再配置および発行される前にデータベースまたはインスタンスを再起動する必要がある場合、再接続に時間がかかる場合があります。このため、サービスが別のインスタンスまたはデータベースから使用可能になるまでに、フェイルオーバーを遅延させる必要があります。

接続および再接続を管理するには、FAILOVER_RETRIESおよびFAILOVER_DELAYパラメータを使用する必要があります。これらのパラメータは計画済停止と連動して使用すると効果があります。たとえば、サービスが数分間使用不可になる可能性がある停止の場合などです。FAILOVER_DELAYおよびFAILOVER_RETRIESパラメータを設定する場合は、まずREPLAY_INITIATION_TIMEOUTパラメータの値を確認します。このパラメータのデフォルト値は900秒です。FAILOVER_DELAYパラメータの値が高い場合、リプレイが取り消されることがあります。

パラメータ名 使用可能な値 デフォルト値

FAILOVER_RETRIES

正の整数ゼロ以上

30

FAILOVER_DELAY

秒数

10

デフォルト値は、透過的アプリケーション・コンティニュイティのサービスにのみ使用されます。サービスがアプリケーション・コンティニュイティに使用される場合、デフォルト値はNULLです。

6.7.5.2 アプリケーション・コンティニュイティを使用するOracle RACのサービスの作成

透過的アプリケーション・コンティニュイティまたは手動アプリケーション・コンティニュイティを利用するサービスをOracle RACで作成できます。

注意:

Oracle Grid Infrastructure 20c以降、ポリシー管理データベースは非推奨です。

次のように、透過的アプリケーション・コンティニュイティを使用するサービスを作成できます。

ポリシー管理データベースの場合:
$ srvctl add service -db codedb -service GOLD -serverpool ora.Srvpool -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failover_restore AUTO -failoverretry 30 -failoverdelay 10
  -commit_outcome TRUE -failovertype AUTO -replay_init_time 1800 -retention 86400
  -notification TRUE
管理者管理データベースの場合:
$ srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2 -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failover_restore AUTO -failoverretry 30 -failoverdelay 10
  -commit_outcome TRUE -failovertype AUTO -replay_init_time 1800 -retention 86400
  -notification TRUE

次のように、手動アプリケーション・コンティニュイティを使用するサービスを作成できます。

ポリシー管理データベースの場合:

$ srvctl add service -db codedb -service GOLD -serverpool ora.Srvpool -clbgoal SHORT
  -rlbgoal SERVICE_TIME -failover_restore LEVEL1 -failoverretry 30 -failoverdelay 10
  -commit_outcome TRUE -failovertype TRANSACTION -replay_init_time 1800 -retention 86400
  -notification TRUE

管理者管理データベースの場合:

$ srvctl add service -db codedb -service GOLD -preferred serv1 -available serv2  -clbgoal SHORT 
  -rlbgoal SERVICE_TIME -failover_restore LEVEL1 -failoverretry 30 -failoverdelay 10 -commit_outcome TRUE
  -failovertype TRANSACTION -replay_init_time 1800 -retention 86400 -notification TRUE
6.7.5.3 単一インスタンスのデータベースのサービスがアプリケーション・コンティニュイティを使用するように変更する方法

単一インスタンス・データベースを使用している場合は、次に示すようにDBMS_SERVICEパッケージを使用してサービスを変更します。

手動アプリケーション・コンティニュイティの場合:
DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='TRANSACTION';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='LEVEL1';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/
透過的アプリケーション・コンティニュイティ:
DECLARE
params dbms_service.svc_parameter_array;
BEGIN
params('FAILOVER_TYPE'):='AUTO';
params('REPLAY_INITIATION_TIMEOUT'):=1800;
params('RETENTION_TIMEOUT'):=86400;
params('FAILOVER_DELAY'):=10;
params('FAILOVER_RETRIES'):=30;
params('FAILOVER_RESTORE'):='AUTO';
params('commit_outcome'):='true';
params('aq_ha_notifications'):='true';
dbms_service.modify_service('[your service]',params);
END;
/

6.7.6 アプリケーション・コンティニュイティなしでの実行

無効化コールが発行されたために、アプリケーション・コンティニュイティが有効でない場合もあります。

アプリケーション・コンティニュイティは、起動されていない場合や無効化されている場合は有効ではありません。無効化されている場合、endRequestコールを介して無効のままにされます。

サービス・プロパティFAILOVER_TYPEの値がTRANSACTIONまたはAUTOに設定されていない場合、アプリケーション・コンティニュイティは起動されません。計画メンテナンスの場合、FAILOVER_TYPEの値を事前にTRANSACTIONまたはAUTOに設定します。この設定が新しい接続に適用され、既存の接続は元のサービス値のままになります。

アプリケーション・コンティニュイティは、次のいずれかが発生したときには、現在のリクエストに対して無効化されます。

  • アプリケーション・コンティニュイティが制限されている文をアプリケーションが実行する(たとえば、ALTER SYSTEM)。

  • disableReplayを使用してアプリケーション・コンティニュイティが明示的に無効化されます。

  • サービス・パラメータsession_state_consistencyがDynamic (透過的アプリケーション・コンティニュイティを使用しない場合はデフォルト)に設定されているときにCOMMIT文が発行されます。

  • 次のbeginRequestが発行されるまでendRequest文が発行されます。

  • セッションが終了または切断され、NOREPLAYキーワードが指定されます。

関連項目

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.7 アプリケーション・コンティニュイティにおけるリプレイの無効化

アプリケーションでリプレイを無効にする方法と、リプレイを無効にするための特定のルールおよびガイドラインについて説明します。

この項で説明されているルールは一般的なものです。これらは、アプリケーション・コンティニュイティおよびTAF (リリース12.2以降)が含まれていて、作業をリプレイするアプリケーションのすべてに適用されます。

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.7.7.1 アプリケーション・コンティニュイティにおけるリプレイの有効化および無効化の理解

リプレイはリカバリ可能なエラーの後に実行されますが、リプレイを無効にできます。

繰り返す必要のないリクエストがアプリケーションにある場合、アプリケーションはアプリケーション・コンティニュイティが有効になっていないサービスへの接続を取得するか、これらのリクエストのリプレイを無効にするAPIを明示的に呼び出すことができます。透過的アプリケーション・コンティニュイティを使用する場合、副作用は自動的に検出され、無効化されます。アプリケーションを理解したり、副作用を含むリクエストを無効にする必要はありません。

手動アプリケーション・コンティニュイティを使用する場合、すべてのコールがリプレイされます。たとえば、アプリケーションがUTL_SMTPを使用しているためにメッセージを繰り返す必要がない場合は、アプリケーションでは別のサービスへの接続を使用するか、disableReplay API (Javaの場合)またはOCIRequestDisableReplay API (Oracle Call Interface (OCI)の場合)を使用できます。他のすべてのリクエストは引き続きリプレイされます。

外部アクション(自律型トランザクション、またはUTL_HTTPを使用したSOAコールを発行するトランザクションの使用など)の場合、障害後にこれらの外部アクションがリプレイされるときにアプリケーションの正確性が保持されている場合、アプリケーション・コンティニュイティは透過的のままです。

6.7.7.2 繰り返さない自律型トランザクション、外部PL/SQLまたはJavaアクションをアプリケーションがコールする場合

自律型トランザクション、外部PL/SQLコールおよびJavaコールアウトには、メイン・トランザクションとは異なる副作用がある場合があり、これらの副作用は、リプレイされないよう指定しないかぎりリプレイされます。

メイン・トランザクションとは別の副作用の例を次に示します。

  • 外部表への書込み、電子メールの送信、PL/SQLからのセッションの分岐(UTL_HTTP、UTL_URL、UTL_FILE、UTL_FILE_TRANSFER、UTL_SMPT、UTL_TCP、UTL_MAIL, DBMS_PIPEまたはDBMS_ALERTへのコールを含む)
  • 外部表への書込み、電子メールの送信、Javaからのセッションの分岐(Process proc = rt.exec(command);の形式でのシェル・スクリプトの実行を含む)、ファイルの転送および外部URLへのアクセス

このようなアクションの結果、永続的な副作用が残ります。PL/SQLメッセージングおよびJavaコールアウトの結果、永続的な結果が残される可能性があります。たとえば、ユーザーがコミットせずに作業を途中で止めた場合、セッションがタイムアウトした場合、またはユーザーが[Ctrl] + [C]コマンドを発行した場合、フォアグラウンドまたはコンポーネントは失敗します。その結果、メイン・トランザクションがロールバックされる一方、副作用が適用されている場合があります。

アプリケーション開発者は、外部アクションに対してリプレイを許可するかどうかを決定します。例として、UTL_HTTPを使用したSOAコールの発行、UTL_SMTPを使用したメッセージの送信、またはUTL_URLを使用したWebサイトへのアクセスがあります。この種の外部処理をリプレイしない場合は、アプリケーション・コンティニュイティなしで接続を使用するか、無効になっているリプレイAPIのいずれかを使用します。

6.7.7.3 アプリケーションが独立セッションを同期化する場合

COMMIT、ROLLBACK、またはセッション喪失まで保持される揮発エンティティを使用してアプリケーションが独立セッションと同期する場合、リプレイ用にアプリケーションを構成しないでください。

たとえば、複数のデータ・ソースに接続されている複数のセッションをアプリケーションで同期する場合(それ以外の場合、これらのセッションはデータベース・ロックなどのリソースを使用して相互に依存します)、この同期は、アプリケーションがこれらのセッションのみをシリアライズ化し、いずれかのセッションが失敗する可能性があることを認識している場合に許容されます。ただし、あるデータ・ソースによって保持されているロックまたは他の揮発リソースが、他の接続から同じまたは別のデータ・ソースのデータに対する排他的アクセスを意味するとアプリケーションが想定している場合、この想定はリプレイ時に無効になる可能性があります。

リプレイ中、セッションがロックまたは他の揮発リソースを維持している別のセッションに依存していることは、クライアント・ドライバでは認識されていません。障害によって失われた同期を実装するために、リソース(セマフォ、デバイス、ソケットなど)を使用しているパイプ、バッファ・キューまたはストアド・プロシージャを使用することもできます。

6.7.7.4 アプリケーションが実行ロジックで中間層の時刻を使用する場合

アプリケーションが実行ロジックの一部として中間層で実時間を使用する場合は、リプレイ用にアプリケーションを構成しないでください。

クライアント・ドライバは中間層の時間ロジックを繰り返しませんが、かわりにこのロジックの一部として実行されるデータベース・コールを使用します。たとえば、中間層の時間を使用するアプリケーションが明示的にこれを使用していなければ、時間T1で実行された文が時間T2で再実行されないと想定することがあります。

6.7.7.5 ROWIDが変更されないことをアプリケーションが前提としている場合

アプリケーションがROWID値をキャッシュする場合、データベースが変更されているためにこれらのROWID値へのアクセスが無効になることがあります。

ROWIDによって表内の行が一意に特定されても、次のような状況ではROWIDの値が変更されることがあります。

  • 基礎となる表が再編成されます。

  • 表で索引が作成されます。

  • 基礎となる表がパーティション化されます。

  • 基礎となる表が移行されます。

  • 基礎となる表が、EXP/IMP/DULを使用してエクスポートおよびインポートされます。

  • 基礎となる表が、Oracle GoldenGateまたはその他のレプリケーション・テクノロジを使用して再構築されます。

  • 基礎となる表のデータベースがフラッシュバックまたはリストアされます。

一般に、将来の使用のためにアプリケーションがROWID値を保存することはお薦めできません。これは、対応する行が存在しないことや、まったく異なるデータを含んでいることがあるためです。ROWID値の使用がアプリケーション・コンティニュイティの使用を妨げることはありません。リプレイは拒否できます。

6.7.7.6 ロケーション値が変更されないことをアプリケーションが前提としている場合

物理的な識別子を使用するアプリケーションがある場合は、ここでガイドラインおよび例を確認して問題を回避します。

SYSCONTEXTオプションは、次の2つのセットで構成されます。

  • 各国語サポート(NLS)設定、ISDBA、CLIENT_IDENTIFIER、MODULE、ACTIONなどのロケーションに依存しないセット
  • 物理ロケータを使用する、ロケーションに依存するセット

通常、アプリケーションはテスト環境を除いて物理的な識別子を使用しません。物理ロケータがメインライン・コードで使用されている場合、リプレイによって不一致が検出され、拒否されます。ただし、リクエスト間(beginRequestの前)またはコールバックでは物理ロケータを使用してもかまいません。QAの一般的な問題は、テスト・アプリケーションがV$INSTANCEを選択するように変更することです。V$INSTANCEは変更可能なため、このチェックはコールバックにのみ配置するか、インスタンスをデータベースからではなくクライアントでローカルに選択します。

物理的な識別子の使用例 

select 
    sys_context('USERENV','DB_NAME') 
    ,sys_context('USERENV','HOST') 
    ,sys_context('USERENV','INSTANCE') 
    ,sys_context('USERENV','IP_ADDRESS') 
    ,sys_context('USERENV','ISDBA')  
    ,sys_context('USERENV','SESSIONID') 
    ,sys_context('USERENV','TERMINAL') 
    ,sys_context('USERENV','SID') 
from dual;

6.7.8 リプレイなしのセッションの終了または切断

DBAがALTER SYSTEM KILL SESSIONまたはALTER SYSTEM DISCONNECT SESSION文を使用してセッションの終了または切断を行ったときに、リプレイを無効にする方法について説明します。

アプリケーション・コンティニュイティが構成されている場合、DBAがALTER SYSTEM KILL SESSIONまたはALTER SYSTEM DISCONNECT SESSION文を使用してセッションを終了または切断すると、デフォルトではアプリケーション・コンティニュイティがセッションをリカバリしようとします。ただし、セッションをリプレイしない場合は、NOREPLAYキーワードを使用します。次に例を示します。 


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

alter system disconnect session 'sid, serial#, @inst' noreplay

$ srvctl stop service -db orcl -instance orcl2 –drain_timeout 60 -stopoption immediate -force -noreplay

$ srvctl stop service -db orcl -node myode3 –noreplay -drain_timeout 60 -stopoption immediate -force

$ srvctl stop instance -node mynode3 -drain_timeout 60 -stopoption immediate -force –noreplay

ローカル・インスタンスで実行している(1つのセッションのみではなく)すべてのセッションを終了して、それらのセッションがリプレイされないようにする場合は、DBMS_SERVICE.DISCONNECT_SESSION PL/SQLプロシージャを使用して、disconnect_optionパラメータにNOREPLAYを指定することもできます。

関連項目

親トピック: アプリケーション・コンティニュイティの操作および使用の管理

6.8 クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

トランザクション・ガードは、アプリケーション・コンティニュイティがリプレイするトランザクションが複数回適用されないようにします。

親トピック: アプリケーション・コンティニュイティの確保

6.8.1 トランザクション・ガードについて

トランザクション・ガードには、自動的かつ透過的に基準化された方法で冪等性を達成するためにアプリケーションで使用される、完全統合ツールが用意されています。

トランザクション・ガードでは、論理トランザクションID (LTXID)を使用して、重複したトランザクションの送信を回避します。この機能は、トランザクションの冪等性と呼ばれます。LTXIDはコミット時に継続され、ロールバックの後に再使用されます。通常の実行中、LTXIDは、各データベース・トランザクションについてクライアントおよびサーバーの両方で自動的にセッションで保持されます。コミット時に、LTXIDはトランザクションのコミットの一環として継続され、次に使用するLTXIDがクライアントに返されます。

最後の送信がコミットされたことまたはこれからコミットされること、あるいは最後の送信の実行が完了していないことを認識できない場合、アプリケーションには問題があります。これらの送信状態を認識できないアプリケーションでは、再送信するユーザーや独自のリプレイを使用するアプリケーションが重複するリクエストを発行したり、データベースにすでにコミットされている変更を繰り返したり、その他の形式の論理破損が発生する原因となる可能性があります。トランザクション・ガードを使用すると、この問題を解決できます。

アプリケーション・コンティニュイティは、自動的にトランザクション・ガードを有効化して使用しますが、トランザクション・ガードは個別に有効化することもできます。アプリケーションがアプリケーション・レベルのリプレイを実装している場合は、冪等性を実現するためにアプリケーションをトランザクション・ガードと統合する必要があります。

XAトランザクション用のトランザクション・ガード

トランザクション・ガードは、XAベースのトランザクションもサポートします。これは、Oracle WebLogic Server、Oracle Tuxedo、およびMicroSoft Transaction Server (Oracle ODP.NETを通じてOracle Databaseに公開)などのトランザクション・マネージャのオプションです。

XAトランザクションのトランザクション・ガード・サポートは、Oracle WebLogic ServerでのXAトランザクションのリカバリ可能な停止の後の安全なリプレイを実現します。XAサポートの追加により、Oracle WebLogic Serverは、トランザクション・ガードを使用した冪等性を持つリプレイを実現できます。

関連項目

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

6.8.2 トランザクション・ガードの構成チェックリスト

トランザクション・ガードのサービスを構成する前に、この構成チェックリストを使用することをお薦めします。

トランザクション・ガードのサービスを構成する前に、このリストの各チェックを完了します。

  • 次のように、GET_LTXID_OUTCOMEを呼び出すアプリケーション・ユーザーに権限を付与します。 

    GRANT EXECUTE ON DBMS_APP_CONT to user_name;

    注意:

    アプリケーション・コンティニュイティを使用する場合は、この文を実行しないでください。

  • 最適なパフォーマンスを実現するためにトランザクション履歴表を特定および定義します。

    トランザクション履歴表(LTXID_HIST)は、Oracle Databaseの作成時またはアップグレード時にデフォルトでSYSAUX表領域に作成されます。最後のパーティションの記憶域を使用して、インスタンスの追加時に新しいパーティションが追加されます。トランザクション履歴表の場所がパフォーマンス上最適でない場合は、別の表領域に移動して、そこでパーティションを作成できます。たとえば、次の文により、FastPaceという名前の表領域にトランザクション履歴表を移動します。 

    ALTER TABLE LTXID_TRANS move partition LTXID_TRANS_1 tablespace FastPace
   storage ( initial 10G next 10G minextents 1 maxextents 121 );

  • -commit_outcomeおよび-retentionサービス・パラメータの値を設定します。

  • Oracle Real Application Clusters (Oracle RAC)、Oracle Data GuardまたはOracle Active Data Guardを使用している場合は、停止の迅速な通知を取得するために、高速アプリケーション通知(FAN)を使用することをお薦めします。

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

6.8.3 トランザクション・ガードのサービスの構成

トランザクション・ガードを使用するようにサービスを構成するには、必要なサービス・パラメータを確認して設定します。

次のパラメータを確認して設定します。

  • -commit_outcome: -commit_outcomeサービス・パラメータをTRUEに設定します。

    -commit_outcomeサービス・パラメータにより、COMMITが実行されて停止が発生した後に、トランザクションのコミット結果にアクセスできるかどうかが決まります。Oracle DatabaseではCOMMITが常に永続的になりますが、トランザクション・ガードではCOMMITの結果が永続的になります。アプリケーションでは、コミットのこの永続性を使用して、停止前に実行された最後のトランザクションのステータスを強制適用します。

  • -retention: -retentionサービス・パラメータを-commit_outcomeとともに使用します。-retentionサービス・パラメータにより、COMMIT結果が保持される時間(秒)が決まります。ほとんどのインストールではデフォルト値を使用することをお薦めします。

次の例では、SRVCTLコマンドにより、salesという名前のポリシー管理サービスがトランザクション・ガード用に構成されます。 

$ srvctl add service -db crm -service sales -serverpool spool_1
  -commit_outcome TRUE -retention 86400 -notification TRUE

次の例では、SRVCTLコマンドにより、salesという名前の管理者管理サービスがトランザクション・ガード用に構成されます。 

$ srvctl add service -db crm -service sales -preferred crm_1,crm_2
  -available crm_3,crm_4 -commit_outcome TRUE -retention 86400
  -notification TRUE

srvctl modify serviceコマンドを使用して、既存のサービスをトランザクション・ガード用に構成するように変更することもできます。

注意:

デフォルト・データベース・サービス(db_nameまたはdb_unique_nameの値に名前が設定されているサービス)は使用しないでください。デフォルト・サービスは、管理目的に使用されるものであり、ユーザー作成のサービスと同じプロパティを備えていません。

関連項目

親トピック: クライアント・フェイルオーバーを向上させるためのトランザクション・ガード

6.9 透過的アプリケーション・フェイルオーバーによるOCIクライアントのフェイルオーバー

Oracle Net Servicesによってインスタンスへの接続が確立されると、Oracle Call Interface (OCI)クライアントが接続をクローズするか、インスタンスが停止するか、または障害が発生するまで、接続はオープン状態のまま維持されます。

接続に透過的アプリケーション・フェイルオーバー(TAF)を構成すると、インスタンスで障害が発生した場合、Oracle Databaseは障害が発生していないインスタンスでセッションをリプレイします。

TAFでは、フェイルオーバーが完了すると問合せは再開できますが、INSERT、UPDATE、DELETEなどの他のトランザクションの場合、アプリケーションで、失敗したトランザクションをロールバックして再度送信する必要があります。FAILOVER_RESTOREをLEVEL1またはAUTOに設定しなかった場合は、フェイルオーバーの発生後、セッションのカスタマイズ、つまりALTER SESSION文も再実行する必要があります。ただし、TAFでは、ワークロードが変化しても、通常処理の間は接続が移動されません。

サービスはTAFのデプロイメントを簡素化します。サービスのTAFポリシーを定義でき、このサービスを使用するすべての接続によって、自動的にTAFが有効になります。これには、クライアント側の変更は必要ありません。サービスのTAF設定は、クライアントの接続定義内のTAF設定よりも優先されます。

-failovermethodおよび-failovertypeパラメータを定義して、サービスのすべてのユーザー用のTAFポリシーを定義できます。-failoverretryおよび-failoverdelayパラメータをそれぞれ使用して、失敗したセッションによるサービスへの再接続試行回数、および再接続の試行間での待機時間を設定して、TAFポリシーをさらに詳しく定義できます。

サービスのTAFポリシーを定義するには、次の例に示すようにSRVCTLを使用します(サービス名はtafconn.example.com、データベース名はcrmです)。 

$ srvctl modify service -db crm -service tafconn.example.com -failovermethod BASIC
  -failovertype SELECT -failoverretry 10 -failoverdelay 30

TAFが有効なOCIアプリケーションでは、高速接続フェイルオーバーのためにFAN高可用性イベントを使用します。

トランザクション・ガードとFAILOVER_RESTOREをサポートするTAF

トランザクション・ガードを使用すると、開発者向けのエラーがTAFによって管理されます。TAFとトランザクション・ガードの両方を使用すると、開発者はTAFエラーを使用して、コミットされていないトランザクションをロール・バックして安全に再送信することも、そのトランザクションを返すこともできます(TAFエラー・コードORA-25402、ORA-25408、ORA-25405の場合)。

FAILOVER_RESTOREを使用していると、TAFは自動的に一般的な状態をリストアします。これにより、ほとんどのアプリケーションでコールバックの必要がなくなります。

関連項目

親トピック: アプリケーション・コンティニュイティの確保