この章では、データベースおよびアプリケーション間でメッセージを送信するOracle Streamsアドバンスト・キューイング(AQ)環境の構成方法を説明します。この項では、構成後のメッセージング環境の管理、監視およびトラブルシューティングについても説明します。
この章は次の項で構成されています。
メッセージング環境は、情報をキューに格納します。エンキューは、メッセージをキューに置くプロセスです。デキューは、メッセージをキューから取得するプロセスです。
キュー内の情報は、タスクを完了するために使用されることも、アプリケーションによって処理されることもあります。メッセージング環境では、アプリケーションの非同期な相互通信が可能です。つまり、アプリケーションは他のアプリケーションが特定のタスクを完了するまで待機する必要がありません。非同期通信の重要性は、メッセージング・システムがそれを利用するアプリケーションの機能に最小の影響しか与えないという点にあります。
たとえば、他のアプリケーションとの通信が必要な場合、アプリケーションはメッセージをキューに置くことができます。メッセージは、他方のアプリケーションによって取得されるまでキュー内に格納されます。実際、メッセージのエンキュー時に他方のアプリケーションが実行されていなくても、メッセージは後で処理されます。メッセージは、取得側アプリケーションにアクションの実行を指示する場合も、あるいは取得側アプリケーションによる処理が必要な情報を含んでいる場合もあります。
組織に、相互通信が必要な複数の異なるシステムがある場合は、メッセージング環境が適切なソリューションになります。様々なシステムが異なる場所にある場合があり、一部は他のシステムより古く、一部は異なるプラットフォームで稼働していることがあります。メッセージングは、これらのシステム間で重要な情報を転送する標準的な信頼性のある方法を提供します。
Oracle Databaseのメッセージング機能は、Oracle Streams Advanced Queuing(AQ)と呼ばれます。Oracle Streams AQはメッセージ機能の利点を提供するとともに、メッセージング・システムとOracle Databaseを統合します。したがって、Oracle Streams AQはOracle Databaseの信頼性、スケーラビリティ、セキュリティ、管理性をもたらします。
Oracle Streams AQを使用して、単一データベース内のキュー間または異なるデータベースのキュー間でメッセージを送信するメッセージング環境を構成できます。キュー間でメッセージを送信するメッセージング環境には、次のコンポーネントが含まれます。
キュー: メッセージをメッセージング環境に格納する抽象ストレージ・ユニット
プロデューサ: メッセージをエンキューするユーザーまたはアプリケーション
伝播: 設定されたスケジュールに従って、あるキューから別のキューにメッセージをコピーするOracle Schedulerジョブ
コンシューマ: メッセージをデキューするユーザーまたはアプリケーション
シングル・ユーザーまたはアプリケーションは、プロデューサおよびコンシューマとして動作できます。メッセージング環境では、サブスクライバおよびメッセージ・クライアントは、コンシューマです。サブスクライバおよびメッセージ・クライアントは、キューからメッセージをデキューすることを許可されたメカニズムで、ルールを使用してどのメッセージをデキューするかを判断できます。
Oracle Streams AQは多くの機能を提供し、その一部はこのマニュアルの対象外です。次の各項で、Oracle Streams AQのいくつかの機能の概要を示します。
関連項目:
|
メッセージの順序付けでは、メッセージがデキューされる順序を決定します。Oracle Streams Advanced Queuing(AQ)には、メッセージの順序付けに次のオプションが用意されています。
エンキュー時間: メッセージは、エンキューされたのと同じ順序でデキューされます。このオプションは、先入れ先出し(FIFO)の順序付けと呼ばれることがあります。たとえば、銀行アプリケーションは、多くの場合にこの順序付けを使用して、財務トランザクションが常に発生した時刻に従って順序付けされるようにします。
優先度: 優先度は、エンキュー中にメッセージに対して指定され、メッセージは優先度に基づいてデキューされます。たとえば、輸送会社では、一部の荷物の優先度が他よりも高いため、この順序付けを使用することがあります。
コミット時間: メッセージは、メッセージをエンキューしたトランザクションがコミットされた時刻に基づいてデキューされます。通常、コミット時間順序付けは、メッセージによってトランザクション依存関係のあるデータベース変更が行われる場合に使用されます。たとえば、会社の売上げを処理するアプリケーションは、メッセージによって依存性を持つ複数のデータベース表が変更される場合にコミット時間順序付けを使用できます。
Oracle Streams Advanced Queuing(AQ)では、次のメッセージ・モードがサポートされています。
永続メッセージ機能: メッセージは、ディスク上のキュー表と呼ばれるデータベース表に常に格納されます。この記憶域のタイプは、永続キュー記憶域と呼ばれることがあります。
バッファ・メッセージ機能: メッセージは、メモリーに格納されますが、一定の条件でキュー表にあふれることがあります。この記憶域のタイプは、バッファ・キュー記憶域と呼ばれることがあります。
バッファ・メッセージ機能は、より高いパフォーマンスを提供しますが、メッセージ保持などの一部のメッセージ機能をサポートしません。メッセージ保持では、デキュー後にメッセージがキュー表に保持される時間を指定できます。また、データベースが予期せず停止した場合、永続メッセージはディスクに保持されますが、バッファ・メッセージはメモリーに格納されているため失われることがあります。
メッセージ保留は、一部の組織で必要な場合がある監査証跡を提供します。たとえば、メッセージがキュー表に格納されている間でも、ユーザーおよびアプリケーションは問合せを実行してそのメッセージに関する情報を収集することができます。その例として、販売アプリケーションでは販売情報を収集して注文に関するレポートを生成できます。
関連項目:
|
Oracle Streams Advanced Queuing(AQ)には、対象のメッセージがエンキューされたときにアプリケーションおよびユーザーに通知する機能があります。 通知によって、アプリケーションおよびユーザーは、作業中にキューで新しいメッセージを頻繁にチェックする必要がなくなります。アプリケーションへの通知の送信には、PL/SQL、Java Message Service(JMS)またはOracle Call Interface(OCI)のコールバック機能を使用できます。通知は、指定した電子メール・アドレスやHTTPポストに送信することもできます。また、通知はRAW
データ型形式でもXML形式でも表示することができます。通知を受信する際、アプリケーションおよびユーザーはデータベースに接続している必要はありません。対象のメッセージがキューに出現したことを通知されてからデータベースに接続し、キューをチェックできます。
伝播は、あるキューから別のキューにメッセージを送信するプロセスです。これらのキューは同じデータベースにあっても異なるデータベースにあってもかまいません。伝播はメッセージング・システムに必須の要素ではありません。伝播により、アプリケーションは同じデータベースまたは同じキューに接続されていなくても相互に通信できます。また、複数の伝播を使用して、あるキューから他の複数のキューに同じメッセージを送信できます。
伝播では、データベース・リンクを使用して、異なるデータベースのキュー間でメッセージを送信します。データベース・リンクは、Oracle Databaseから別のデータベースへの1方向通信パスを定義するポインタです。伝播は、伝播ジョブと呼ばれるOracle Schedulerジョブによって実行されます。伝播スケジュールによって、伝播がメッセージを送信する頻度が決定され、各伝播ジョブのスケジュールを制御できます。
Oracle Streams Advanced Queuing(AQ)は、キューとキューの間(キュー・ツー・キュー)でも、キューとデータベース・リンクの間(キュー・ツーdblink)でも伝播をサポートしています。 キュー・ツー・キュー伝播では、常に独自の排他的な伝播ジョブを使用してソース・キューから宛先キューにメッセージを伝播します。そのため、キュー・ツー・キューの各伝播スケジュールは個別の管理が可能です。複数のキュー・ツー・キュー伝播では、1つのデータベース・リンクを使用できます。1つのキューからメッセージを送信する複数の伝播をファイングレイン制御する際に、キュー・ツー・キュー伝播を使用し、各伝播が異なるスケジュールを使用する必要があります。
一方、キュー・ツーdblink伝播の場合は、同じデータベース・リンクを使用する同じソース・キューからのキュー・ツーdblink伝播の間で、伝播ジョブが共有されます。複数の伝播によって、1つのソース・キューからリモート・データベースの複数のキューにメッセージが送信される場合、同じ伝播スケジュールが共有されます。伝播スケジュールに変更があれば、データベース・リンクを使用する同じソース・キューからのキュー・ツーdblink伝播のすべてに影響します。1つのキューからメッセージを送信する複数の伝播を一括処理する際、キュー・ツーdblink伝播を使用し、すべての伝播が同じスケジュールを使用する必要があります。
関連項目:
|
Oracle Messaging Gatewayは、Oracle Streams Advanced Queuing(AQ)メッセージング・システムを、IBM Websphere MQ(以前はMQSeriesと呼ばれていました)やTIBCO Rendezvousなどの他のメッセージング・システムと統合します。この統合により、Oracle Streams AQを使用するOracle Databaseアプリケーションは、Oracle以外のメッセージング・システムを使用する他のアプリケーションと、双方向でシームレスに通信できます。
Messaging Gatewayでは、ゲートウェイ・エージェントを使用して、Oracle Streams AQキューからOracle以外のメッセージング・システムのキューにメッセージを送信します。また、ゲートウェイ・エージェントによってOracle Streams AQキューがOracle以外のメッセージング・システムからメッセージを受信できるようになります。
Messaging Gatewayは、Oracle以外のメッセージング・システムに直接マッピングできるOracle Streams AQタイプの自動タイプ変換をサポートします。直接マッピングできないタイプの場合は、カスタム変換を定義してタイプをマッピングできます。一度定義されると、カスタム変換は伝播の間実行されます。
Messaging Gatewayは、メッセージ・システムのネイティブ・メッセージの書式をサポートします。Oracle Streams AQメッセージには、RAW
またはOracle Streams AQにサポートされるOracleのオブジェクト型ペイロードが含まれます。IBM Websphere MQメッセージは、テキストまたはバイト形式のメッセージです。TIBCO Rendezvousメッセージは、TIBCO Rendezvousワイヤ書式のデータ型です。
Oracle Streams AQキューには、インターネットを通じて安全にアクセスできます。Messaging Gatewayは、安全なインターネット対応メッセージングをOracle Streams AQキューとOracle以外のメッセージング・システムのキューの間に提供します。
関連項目:
|
この項では、メッセージング環境用のデータベースの準備に必要なアクションについて説明します。
メッセージング環境用にデータベースを準備するには:
メッセージング環境に関係する各データベースでGLOBAL_NAMES
初期化パラメータをTRUE
に設定します。方法については、「GLOBAL_NAMES初期化パラメータをTRUEに設定」を参照してください。
ネットワーク接続を構成して、メッセージを送信するデータベースがメッセージを受信するデータベースと通信できるようにします。データベース間のネットワーク接続の構成の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
メッセージング環境に関係する各データベースでOracle Streams管理者を構成します。方法については、「チュートリアル: Oracle Streams管理者の構成」を参照してください。
Oracle Streamsプールが、メッセージング環境に対して作成されるキューを収容するのに十分な大きさであることを確認します。各キューには、少なくとも10MBのメモリーが必要です。Oracle Streamsプールは、システム・グローバル領域(SGA)の一部です。MEMORY_TARGET
初期化パラメータ(自動メモリー管理)、SGA_TARGET
初期化パラメータ(自動共有メモリー管理)またはSTREAMS_POOL_SIZE
初期化パラメータを設定することでOracle Streamプールを管理できます。Oracle Streamsプールの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照してください。
この項の例には、本社のOracle Databaseに注文を入力する企業が関係します。注文が入力されると、企業はメッセージング・システムを使用して、注文IDと注文日を異なる場所の倉庫にあるOracle Databaseに送信します。これらのメッセージは、倉庫の従業員に注文を通知し、従業員が注文を履行して出荷できるようにします。倉庫の従業員は、本社のデータにアクセスして、特定の注文に関する詳細情報を検索できます。
この例では、注文入力スキーマとしてoe
サンプル・スキーマを使用します。 oe
サンプル・スキーマはOracle Databaseとともにデフォルトでインストールされます。
この例では、本社のデータベースのグローバル名はii1.example.com
で、倉庫のデータベースのグローバル名はii2.example.com
です。ただし、例を完了するために、ご使用の環境の2つのデータベースに置き換えることもできます。
図9-1に、この例で作成するメッセージング環境の概要を示します。
この例を開始する前に、「メッセージ機能の準備」で説明されているタスクを完了します。
注文に関するメッセージをii1.example.comデータベースからii2.example.comデータベースに送信するメッセージング・システムを構成するには:
注文について送信する情報を定義するユーザー定義タイプを作成します。この例では、注文IDと注文日を含むメッセージ用にstrmadmin.order_id_date
タイプを作成します。
各データベースにstrmadmin.order_id_dateタイプを作成するには:
まだ準備していない場合は、メッセージ機能用に環境を準備します。詳細は、「メッセージ機能の準備」を参照してください。
Oracle Enterprise Managerで、Oracle Streams管理者としてii1.example.com
データベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「ユーザー定義タイプ」セクションの「オブジェクト・タイプ」をクリックします。
「オブジェクト・タイプ」ページで、「作成」をクリックして「オブジェクト・タイプの作成」ページを開きます。
「名前」フィールドにorder_id_date
と入力します。
「スキーマ」フィールドでstrmadmin
が選択されていることを確認します。
「属性」セクションで「データ型」に対して「事前定義済タイプ」が選択されていることを確認します。
「属性」セクションで「追加」をクリックして、「事前定義済タイプ属性の追加」ページを開きます。
属性を追加するには:
「名前」フィールドにorder_id
と入力します。
「タイプ」ではNUMBER
を選択します。
「長さ」フィールドに12
と入力します。
「OK」をクリックします。
「オブジェクト・タイプの作成」ページの「属性」セクションで「事前定義済タイプ」が選択されていることを確認します。
「属性」セクションで「追加」をクリックして、「事前定義済タイプ属性の追加」ページを開きます。
属性を追加するには:
「名前」フィールドにorder_date
と入力します。
「タイプ」ではVARCHAR2
を選択します。
「長さ」フィールドに100
と入力します。
「OK」をクリックします。
「オブジェクト・タイプの作成」ページで、「OK」をクリックしてタイプを作成します。
Enterprise ManagerのOracle Streams管理者としてii2.example.com
データベースにログインします。
ii2.example.com
データベースで手順3から15を完了して、両方のデータベースがstrmadmin.order_id_date
タイプを持つようにします。
この拡張例を続行するには、「タスク2: キューの構成とキュー間の伝播の構成」の手順に進んでください。
注意: SQL文CREATE TYPE を使用して、タイプを作成することもできます。 |
各データベースにキューを作成し、注文に関するメッセージをii1.example.com
データベースのキューからii2.example.com
データベースのキューに送信する伝播を作成します。
伝播を作成するには:
streams_queue
という名前のキューをii1.example.com
データベースとii2.example.com
データベース両方のOracle Streams管理者のスキーマに作成します。方法については、「ANYDATAキューの作成」を参照してください。
ii2.example.com
という名前のデータベース・リンクをii1.example.com
のOracle Streams管理者スキーマに作成します。Oracle Streams管理者スキーマに接続するデータベース・リンクをii2.example.com
に構成します。データベース・リンクのサービス名は、ii2.example.com
である必要があります。詳細は、「チュートリアル: データベース・リンクの作成」を参照してください。
Oracle Enterprise Managerで、Oracle Streams管理者としてii1.example.com
データベースにログインします。
「データベース」ホームページに移動します。
「高可用性」の下にある「Streamsコンポーネント」の番号リンクをクリックします。
「レプリケーションの管理」ページで、「関連リンク」の「伝播の設定」をクリックして「伝播の設定」ページを開きます。
「伝播名」フィールドにsend_orders
と入力します。
「ソース・キュー」フィールドにstrmadmin.streams_queue
と入力します。このキューは、注文に関するメッセージがエンキューされるii1.example.com
データベースのキューです。
手順2で作成したデータベース・リンクの名前を「接続先データベース・リンク」フィールドに入力します。この例では、データベース・リンク名はii2.example.com
です。
「宛先キュー」フィールドで、strmadmin.streams_queue
を入力します。これは注文に関するメッセージが送信されるii2.example.com
データベースのキューです。
「ポジティブ・ルール・セット」フィールドと「ネガティブ・ルール・セット」フィールドは空のままにします。伝播にルール・セットがない場合は、ソース・キュー内のすべてのメッセージが宛先キューに送信されます。
「キューからキューへの伝播」オプションを有効にします。
「OK」をクリックして伝播を作成します。
この拡張例を続行するには、「タスク3: メッセージ・エンキュー・メカニズムの構成」の手順に進んでください。
注意: DBMS_PROPAGATION_ADM.CREATE_PROPAGATION プロシージャを使用して、伝播を作成することもできます。 |
メッセージング・システム内のメッセージをエンキューするメカニズムを構成します。通常、アプリケーションは、別のアプリケーションによってデキューされ、処理されるメッセージを作成し、エンキューします。簡略化のために、この例ではenqueue_orders
というトリガーを作成して、注文の注文IDと注文日を含むメッセージをエンキューします。トリガーは、注文がoe.orders
表に挿入されたときに起動します。
メッセージ・エンキュー・メカニズムを構成するには:
Oracle Streams管理者に、DBMS_STREAMS_MESSAGING
パッケージに対するEXECUTE
権限を付与します。
この例では、DBMS_STREAMS_MESSAGING
パッケージのENQUEUE
プロシージャを実行するトリガーを構成します。トリガー内のこのプロシージャを実行するユーザーには、プロシージャを含むパッケージに対する明示的なEXECUTE
権限が必要です。ロールを通じて権限を付与することはできません。したがって、Oracle Streams管理者にはパッケージに対する明示的なEXECUTE
権限を付与する必要があります。
strmadmin
ユーザーに権限を付与できる管理ユーザーとして、Enterprise Managerにログインします。たとえば、SYSDBA
権限を持つユーザーとしてログインできます。この例では、ii1.example.com
データベースにログインします。
「データベース」ホームページに移動します。
「サーバー」をクリックして「サーバー」サブページを開きます。
「セキュリティ」セクションで「ユーザー」をクリックします。
「ユーザー」ページが表示されます。
STRMADMIN
ユーザーを選択します。
「編集」をクリックします。
「ユーザーの編集」ページが表示され、「一般」サブページが表示されます。
「オブジェクト権限」をクリックして「オブジェクト権限」サブページを開きます。
「オブジェクト・タイプの選択」リストの「パッケージ」を選択します。
「追加」をクリックしてパッケージ・オブジェクト権限の追加ページを開きます。
「パッケージ・オブジェクトの選択」フィールドにSYS.DBMS_STREAMS_MESSAGING
と入力します。
「使用可能な権限」リストから「選択した権限」リストにEXECUTEを移動します。
「OK」をクリックして権限を追加します。
「適用」をクリックして権限を付与します。
Enterprise Managerからログアウトします。
注意: SQL文GRANT を使用して、ユーザーに権限を付与することもできます。 |
oe.orders
表に変更があったときメッセージを自動的にエンキューするトリガーを、ii1.example.com
データベースに作成します。
Oracle Streams管理者としてEnterprise Managerのii1.example.com
データベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「プログラム」セクションで「トリガー」をクリックします。
「トリガー」ページで、「作成」をクリックします。
「トリガーの作成」ページが表示され、「一般」サブページが表示されます。
「名前」フィールドにenqueue_orders
と入力します。
「スキーマ」フィールドでstrmadmin
が入力されていることを確認します。
DECLARE message strmadmin.order_id_date; BEGIN message := strmadmin.order_id_date( order_id => :NEW.order_id, order_date => TO_CHAR(:NEW.order_date)); DBMS_STREAMS_MESSAGING.ENQUEUE ( queue_name => 'strmadmin.streams_queue', payload => ANYDATA.CONVERTOBJECT(message)); END;
「イベント」をクリックして「イベント」サブページを開きます。
「対象オブジェクト」リストで「表」が選択されていることを確認します。
「表(Schema.Table)」フィールドにoe.orders
と入力します。
「起動タイミング」では「後」を選択します。
「イベント」では「挿入」を選択します。この例では、メッセージが既存の注文に対する変更ではなく新しい注文を追跡するため、「挿入」のみが選択されている必要があります。
「詳細」をクリックします。
「行レベル・トリガー」を選択します。
「参照」セクションの「旧値(OLD AS)」フィールドにOLD
を入力します。
「参照」セクションの「新規値(NEW AS)」フィールドにNEW
を入力します。
「OK」をクリックしてトリガーを作成します。
注意: SQL文CREATE TRIGGER を使用して、トリガーを作成することもできます。 |
この拡張例を続行するには、「タスク4: メッセージをデキューするためのメッセージ・クライアントの構成」の手順に進んでください。
メッセージング・システム内のメッセージをデキューするメカニズムを構成します。通常、アプリケーションは別のアプリケーションによって作成されたメッセージをデキューして処理します。簡略化のために、この例ではdequeue_orders
というPL/SQLプロシージャを作成して、注文の注文IDおよび注文日を含むメッセージをデキューします。この例ではプロシージャをコールしてメッセージをデキューしますが、アプリケーションはこのようなプロシージャを定期的に実行できます。
メッセージをデキューするためのメッセージ・クライアントを構成するには:
ii2.example.com
データベースのOracle Streams管理者に、SYS.DBMS_STREAMS_MESSAGING
パッケージに対するEXECUTE
権限を付与します。ii1.example.com
データベースのOracle Streams管理者にこの権限を付与する例は、「タスク3: メッセージ・エンキュー・メカニズムの構成」の手順1を参照してください。
コマンドラインでSQL*Plusを開き、Oracle Streams管理者としてii2.example.com
データベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
メッセージ・クライアントを作成して、Oracle Streams管理者がstreams_queue
キューからメッセージをデキューできるようにします。
BEGIN DBMS_STREAMS_ADM.ADD_MESSAGE_RULE ( message_type => 'strmadmin.order_id_date', rule_condition => ':MSG.ORDER_ID > 0', streams_type => 'DEQUEUE', streams_name => 'strmadmin', queue_name => 'strmadmin.streams_queue'); END; /
Oracle Streams管理者のユーザー名は、streams_name
パラメータで指定する必要があります。この例では、Oracle Streams管理者のユーザー名はstrmadmin
です。
メッセージ・クライアントは、ルールを使用して、どのメッセージをデキューするかを判断します。この例では、メッセージ・クライアントのルールは、order_id
が0より大きいすべてのメッセージをデキューする必要があることを指定します。このため、このルールを使用すると、メッセージ・クライアントは、strmadmin.streams_queue
キューに出現するstrmadmin.order_id_date
タイプの新しいメッセージをすべてデキューします。
Oracle Enterprise Managerで、Oracle Streams管理者としてii2.example.com
データベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「プログラム」セクションで「プロシージャ」をクリックします。
「プロシージャ」ページで「作成」をクリックします。
「プロシージャの作成」ページで、「名前」フィールドにdequeue_orders
と入力します。
「スキーマ」フィールドでstrmadmin
が入力されていることを確認します。
「ソース」フィールドのサンプル・テキストを削除します。
AS msg ANYDATA; user_msg strmadmin.order_id_date; num_var PLS_INTEGER; more_messages BOOLEAN := TRUE; navigation VARCHAR2(30); BEGIN navigation := 'FIRST MESSAGE'; WHILE (more_messages) LOOP BEGIN DBMS_STREAMS_MESSAGING.DEQUEUE( queue_name => 'strmadmin.streams_queue', streams_name => 'strmadmin', payload => msg, navigation => navigation, wait => DBMS_STREAMS_MESSAGING.NO_WAIT); IF msg.GETTYPENAME() = 'STRMADMIN.ORDER_ID_DATE' THEN num_var := msg.GETOBJECT(user_msg); DBMS_OUTPUT.PUT_LINE('Order ID: ' || user_msg.order_id); DBMS_OUTPUT.PUT_LINE('Order Date: ' || user_msg.order_date); END IF; navigation := 'NEXT MESSAGE'; COMMIT; EXCEPTION WHEN SYS.DBMS_STREAMS_MESSAGING.ENDOFCURTRANS THEN navigation := 'NEXT TRANSACTION'; WHEN DBMS_STREAMS_MESSAGING.NOMOREMSGS THEN more_messages := FALSE; DBMS_OUTPUT.PUT_LINE('No more messages.'); WHEN OTHERS THEN RAISE; END; END LOOP; END;
「OK」をクリックします。
この拡張例を続行するには、「タスク5: メッセージのエンキュー」の手順に進んでください。
注意: SQL文CREATE PROCEDURE を使用して、プロシージャを作成することもできます。 |
「タスク3: メッセージ・エンキュー・メカニズムの構成」の例では、トリガーを作成しました。トリガーは、oe.orders
表に挿入された注文に関する情報とともにメッセージをstrmadmin.streams_queue
キューにエンキューします。このため、oe.orders
表に行を挿入することにより、メッセージをstrmadmin.streams_queue
キューにエンキューできます。
行をoe.orders表に挿入するには:
コマンドラインでSQL*Plusを開き、oe
ユーザーとしてii1.example.com
データベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SQL*Plusで、行をoe.orders
表に挿入します。
INSERT INTO oe.orders VALUES(3000, SYSDATE, 'direct', 116, 0, 4000.00, 153, NULL); INSERT INTO oe.orders VALUES(3001, SYSDATE, 'direct', 117, 5, 5000.00, 163, NULL); INSERT INTO oe.orders VALUES(3002, SYSDATE, 'direct', 118, 7, 6000.00, 159, NULL);
SQL*Plusで、変更をコミットします。
COMMIT;
この拡張例を続行するには、「タスク6: メッセージのデキュー」の手順に進んでください。
「タスク5: メッセージのエンキュー」の例では、ii1.example.com
データベースのstrmadmin.streams_queue
キューにメッセージをエンキューします。メッセージがエンキューされた後で、「タスク2: キューの構成とキュー間の伝播の構成」で構成した伝播により、メッセージがii2.example.com
データベースのstrmadmin.streams_queue
キューに送信されます。
この例では、「タスク4: メッセージをデキューするためのメッセージ・クライアントの構成」で作成したdequeue_orders
プロシージャを使用して、ii2.example.com
データベースのキューからメッセージをデキューします。
メッセージをデキューするには:
オプションとして、メッセージのデキューを試みる前に、ii2.example.com
のstrmadmin.streams_queue
キューにメッセージが到着したことを確認することもできます。ii1.example.com
のキューからii2.example.com
のキューにメッセージを送信する伝播には時間がかかる可能性があります。方法については、「キュー内のメッセージの表示」を参照してください。
「メッセージ」ページには、3つのメッセージが表示されます。各メッセージには、「タスク5: メッセージのエンキュー」でoe.orders
表に挿入した注文に関する情報が含まれます。
コマンドラインでSQL*Plusを開き、Oracle Streams管理者としてii2.example.com
データベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
SQL*Plusで、dequeue_orders
プロシージャを実行します。
SET SERVEROUTPUT ON exec dequeue_orders;
出力は、次のようになります。
Order ID: 3000 Order Date: 01-FEB-07 01.47.48.000000000 PM Order ID: 3001 Order Date: 01-FEB-07 01.47.57.000000000 PM Order ID: 3002 Order Date: 01-FEB-07 01.48.04.000000000 PM No more messages. PL/SQL procedure successfully completed.
対象のメッセージがエンキューされたときにアプリケーションまたはユーザーに警告するメッセージ通知を構成することができます。
この項の例では、メッセージ通知を使用して、2つのアプリケーションが相互に通信できるようにする方法を示します。この例では、アプリケーションは次の方法で通信します。
最初のアプリケーションは、2番目のアプリケーションで設定する必要のある様々なパラメータと、それらのパラメータの値を判断します。
最初のアプリケーションは、次の属性を含むメッセージをエンキューします。
parameter:
2番目のアプリケーションで設定するパラメータを指定する
value:
パラメータ値を指定する
メッセージ通知は、キュー内に新しいメッセージがあることを2番目のアプリケーションに警告します。
2番目のアプリケーションは、メッセージをデキューし、パラメータをメッセージ内の値に設定します。
簡略化のために、この例では2つのアプリケーションを作成しません。かわりに、メッセージ通知の構成方法、および対象のメッセージがエンキューされたときにメッセージ通知を使用してそのメッセージを自動的にデキューする方法を示します。
図9-2に、この例で作成するメッセージング環境の概要を示します。
注意: データベース間でメッセージを送信する環境でメッセージ通知を構成できます。データベース間でメッセージを送信する環境の例の詳細は、「チュートリアル: Oracle Database間でのメッセージの送信」を参照してください。 |
メッセージ通知を構成するには:
ユーザー定義型を作成して、アプリケーションについて追跡する情報を定義します。この例では、パラメータと値を含むメッセージに対してstrmadmin.app_info
型を作成します。
strmadmin.app_info型を作成するには:
まだ準備していない場合は、メッセージ機能用に環境を準備します。詳細は、「メッセージ機能の準備」を参照してください。
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「ユーザー定義タイプ」セクションの「オブジェクト・タイプ」をクリックします。
「オブジェクト・タイプ」ページで、「作成」をクリックして「オブジェクト・タイプの作成」ページを開きます。
「名前」フィールドにapp_info
と入力します。
「スキーマ」フィールドでstrmadmin
が選択されていることを確認します。
「属性」セクションで「データ型」に対して「事前定義済タイプ」が選択されていることを確認します。
「属性」セクションで「追加」をクリックして、「事前定義済タイプ属性の追加」ページを開きます。
app_info
型に1番目の属性を追加するには:
「名前」フィールドにparameter
と入力します。
「タイプ」ではVARCHAR2
を選択します。
「長さ」フィールドに20
と入力します。
「OK」をクリックします。
「オブジェクト・タイプの作成」ページの「属性」セクションで「データ型」に対して「事前定義済タイプ」が選択されていることを確認します。
「属性」セクションで「追加」をクリックして、「事前定義済タイプ属性の追加」ページを開きます。
app_info
型に次の属性を追加するには:
「名前」フィールドにvalue
と入力します。
「タイプ」ではNUMBER
を選択します。
「長さ」フィールドに12
と入力します。
「OK」をクリックします。
「オブジェクト・タイプの作成」ページで、「OK」をクリックしてタイプを作成します。
この拡張例を続行するには、「タスク2: キューおよびメッセージ・クライアントの構成」の手順に進んでください。
注意: SQL文CREATE TYPE を使用して、タイプを作成することもできます。 |
キュー表とキューを作成して、最初のアプリケーションが2番目のアプリケーションに対して生成するメッセージを格納します。キューの作成後に、メッセージ通知はメッセージをキューからデキューできるコンシューマを必要とします。この例では、メッセージ・クライアントが、streams_queue
キューからメッセージをデキューできるコンシューマです。
キューおよびメッセージ・クライアントを構成するには:
streams_queue
という名前のキューをOracle Streams管理者のスキーマに作成します。方法については、「ANYDATAキューの作成」を参照してください。
コマンドラインでSQL*Plusを開き、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
メッセージ・クライアントを作成して、Oracle Streams管理者がstreams_queue
キューからメッセージをデキューできるようにします。
BEGIN DBMS_STREAMS_ADM.ADD_MESSAGE_RULE ( message_type => 'strmadmin.app_info', rule_condition => ':MSG.VALUE >= 0', streams_type => 'DEQUEUE', streams_name => 'strmadmin', queue_name => 'strmadmin.streams_queue'); END; /
Oracle Streams管理者のユーザー名は、streams_name
パラメータで指定する必要があります。この例では、Oracle Streams管理者のユーザー名はstrmadmin
です。新しいメッセージ・クライアントの名前もstrmadmin
です。
メッセージ・クライアントは、ルールを使用して、どのメッセージをデキューするかを判断します。この例では、メッセージ・クライアントのルールは、value
が0よりも大きいすべてのメッセージをデキューする必要があることを指定します。このため、このルールを使用すると、メッセージ・クライアントは、すべてのパラメータ値が0以上であるため、strmadmin.streams_queue
に出現するstrmadmin.app_info
型の新しいメッセージをすべてデキューします。
この拡張例を続行するには、「タスク3: メッセージをデキューするメカニズムの構成」の手順に進んでください。
この拡張例では、2番目のアプリケーションがstreams_queue
キューからメッセージをデキューできる必要があります。簡略化のために、この例ではdequeue_app_messages
というPL/SQLプロシージャを作成して、strmadmin.app_info
型のメッセージをデキューします。このプロシージャは、「タスク2: キューおよびメッセージ・クライアントの構成」で作成したメッセージ・クライアントを使用してメッセージをデキューします。
メッセージをデキューするメカニズムを構成するには:
Oracle Streams管理者に、DBMS_AQ
パッケージに対するEXECUTE
権限を付与します。
この例では、DBMS_AQ
パッケージのDEQUEUE
プロシージャを実行するプロシージャを構成します。このプロシージャを実行するユーザーには、プロシージャを含むパッケージに対する明示的なEXECUTE
権限が必要です。ロールを通じて権限を付与することはできません。したがって、Oracle Streams管理者にはパッケージに対する明示的なEXECUTE
権限を付与する必要があります。
「サーバー」サブページに進みます。
「セキュリティ」セクションで「ユーザー」をクリックします。
「ユーザー」ページが表示されます。
STRMADMIN
ユーザーを選択します。
「編集」をクリックします。
「ユーザーの編集」ページの「一般」サブページが表示されます。
「オブジェクト権限」をクリックして「オブジェクト権限」サブページを開きます。
「オブジェクト・タイプの選択」リストの「パッケージ」を選択します。
「追加」をクリックしてパッケージ・オブジェクト権限の追加ページを開きます。
「パッケージ・オブジェクトの選択」フィールドにSYS.DBMS_AQ
と入力します。
「使用可能な権限」リストから「選択した権限」リストにEXECUTEを移動します。
「OK」をクリックして権限を追加します。
「適用」をクリックして権限を付与します。
注意: SQL文GRANT を使用して、ユーザーに権限を付与することもできます。 |
メッセージをデキューするPL/SQLプロシージャを作成します。
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「プログラム」セクションで「プロシージャ」をクリックします。
「プロシージャ」ページで「作成」をクリックします。
「プロシージャの作成」ページで、「名前」フィールドにdequeue_app_messages
と入力します。
「スキーマ」フィールドでstrmadmin
が入力されていることを確認します。
「ソース」フィールドのサンプル・テキストを削除します。
( context ANYDATA, reginfo SYS.AQ$_REG_INFO, descr SYS.AQ$_DESCRIPTOR) AS dequeue_options DBMS_AQ.DEQUEUE_OPTIONS_T; message_properties DBMS_AQ.MESSAGE_PROPERTIES_T; message_handle RAW(16); message ANYDATA; app_message strmadmin.app_info; rc PLS_INTEGER; BEGIN -- Get the message identifier and consumer name from the descriptor dequeue_options.msgid := descr.msg_id; dequeue_options.consumer_name := descr.consumer_name; -- Dequeue the message DBMS_AQ.DEQUEUE( queue_name => descr.queue_name, dequeue_options => dequeue_options, message_properties => message_properties, payload => message, msgid => message_handle); rc := message.getobject(app_message); COMMIT; END;
メッセージ通知PL/SQLプロシージャには次のシグネチャが必要です。
PROCEDURE procedure_name(
context IN ANYDATA,
reginfo IN SYS.AQ$_REG_INFO,
descr IN SYS.AQ$_DESCRIPTOR);
ここで、procedure_name
はプロシージャの名前を意味します。プロシージャは、メッセージ通知で起動されるユーザー定義PL/SQLプロシージャを指定するPLSQLCALLBACK
データ構造体です。
この例のプロシージャは、通知によって送信されたメッセージ識別子とコンシューマ名を使用してstrmadmin.app_info
型のメッセージをデキューする単純な通知プロシージャです。
「OK」をクリックしてプロシージャを作成します。
注意: SQL文CREATE PROCEDURE を使用して、プロシージャを作成することもできます。 |
この拡張例を続行するには、「タスク4: メッセージ通知の構成」の手順に進んでください。
この拡張例では、新しいメッセージがstrmadmin.streams_queue
キューにエンキューされたときにメッセージ通知がstrmadmin.dequeue_app_messages
プロシージャを起動します。このプロシージャは、新しいメッセージをデキューします。デキュー後に、アプリケーションはカスタマイズされた任意の方法でメッセージを処理できます。この例では、2番目のアプリケーションはメッセージ内の情報を使用してアプリケーション・パラメータ値を設定します。簡略化のために、この例では2番目のアプリケーションを構成しません。
プロシージャを起動するメッセージ通知を構成するには:
コマンドラインでSQL*Plusを開き、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
メッセージがエンキューされ、strmadmin
メッセージ・クライアントがデキューできるときに、strmadmin.dequeue_app_messages
プロシージャを起動するメッセージ通知を設定します。
BEGIN DBMS_STREAMS_ADM.SET_MESSAGE_NOTIFICATION ( streams_name => 'strmadmin', notification_action => 'strmadmin.dequeue_app_messages', notification_type => 'PROCEDURE', include_notification => TRUE, queue_name => 'strmadmin.streams_queue'); END; /
この拡張例を続行するには、「タスク5: メッセージのエンキューとメッセージ通知のチェック」の手順に進んでください。
この拡張例では、1つのアプリケーションが、2番目のアプリケーションによって処理されるメッセージをエンキューします。簡略化のために、この例ではメッセージを手動でエンキューします。メッセージがエンキューされた後で、メッセージ通知を通じて自動的にデキューされたことを確認できます。
メッセージをエンキューし、メッセージ通知をチェックするには:
コマンドラインでSQL*Plusを開き、データベースにOracle Streams管理者として接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
メッセージをstrmadmin.streams_queue
キューにエンキューします。
DECLARE msg strmadmin.app_info; BEGIN msg := strmadmin.app_info( parameter => 'THRESHOLD', value => 1000); DBMS_STREAMS_MESSAGING.ENQUEUE ( queue_name => 'strmadmin.streams_queue', payload => ANYDATA.CONVERTOBJECT(msg)); COMMIT; END; / DECLARE msg strmadmin.app_info; BEGIN msg := strmadmin.app_info( parameter => 'MIN_WAIT', value => 1); DBMS_STREAMS_MESSAGING.ENQUEUE ( queue_name => 'strmadmin.streams_queue', payload => ANYDATA.CONVERTOBJECT(msg)); COMMIT; END; / DECLARE msg strmadmin.app_info; BEGIN msg := strmadmin.app_info( parameter => 'BUFFER_SIZE', value => 30); DBMS_STREAMS_MESSAGING.ENQUEUE ( queue_name => 'strmadmin.streams_queue', payload => ANYDATA.CONVERTOBJECT(msg)); COMMIT; END; /
オプションとして、streams_queue
キュー内のメッセージを表示し、これらがメッセージ通知を使用して自動的にデキューされたかどうかを確認します。方法については、「キュー内のメッセージの表示」を参照してください。
この例で構成したメッセージ通知が正常に動作している場合は、「メッセージ」ページに次のいずれかが表示されます。
1つ以上のエンキューされたメッセージが、「状態の異なるコンシューマ」フィールドに「処理済」
と表示されることがあります。このフィールドの「処理済」
値は、メッセージがすべてのコンシューマによってデキューされたことを意味します。
キューにメッセージは表示されません。最終的に、処理されたメッセージはキューから自動的に削除されます。メッセージが表示されない場合は、エンキューされたメッセージがメッセージ通知によってデキューされ、自動的に削除されました。
Enterprise Managerを使用して、次のプロパティを含め、既存のキューのプロパティの一部を変更できます。
再試行最大数: メッセージが例外キューに移動されるまでに許可されるデキュー試行の数。メッセージング環境が接続不良の場合、メッセージのデキュー処理中に、接続が切断される可能性があります。このような環境では、メッセージが例外キューに移動されるまでアプリケーションが何度もメッセージをデキューするよう、最大再試行数を増やす必要があります。
再試行の遅延: アプリケーションのロールバック後、スケジュールされたメッセージの再処理が行われるまでの時間量。メッセージング環境が接続不良の場合、メッセージのデキューに失敗した後、アプリケーションを一定の時間待機させる必要があります。このような環境では、待機時間を指定して再試行の遅延設定を増やす必要があります。
保有時間: メッセージがすべてのコンシューマにデキューされた後、メッセージがキュー内に保持される時間。消費されたメッセージを追跡する場合、キュー内に格納されたメッセージに関する情報を記録できる保存期間を設定できます。
これらのプロパティは、キューからメッセージをデキューするアプリケーションで最適な値に設定できます。
キューを変更するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「Streams」セクションで、「アドバンスト・キューの管理」をクリックして「アドバンスト・キューの管理」ページを開きます。
変更するキューを選択します。必要に応じて、検索ツールを使用してキューを検索してから選択します。
「編集」をクリックして「キューの編集」ページを開きます。
1つ以上のキュー・プロパティを変更します。
「適用」をクリックすると変更が保存されます。
注意: DBMS_AQADM.ALTER_QUEUE プロシージャを使用して、キューを変更することもできます。 |
Enterprise Managerを使用して、既存のキュー表の記憶域オプションの一部を変更できます。キュー表の記憶域オプションを変更すると、キュー表を使用するキューのパフォーマンスが向上します。
キュー表を変更するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「アドバンスト・キューの管理」をクリックします。
「関連リンク」セクションで、「キュー表」をクリックして、「キュー表」ページを開きます。
変更するキュー表を選択します。
「編集」をクリックします。
「キュー表の編集」ページが表示され、「一般」サブページが表示されます。
「記憶域」をクリックして「記憶域」サブページを開くか、「LOB記憶域」をクリックして「LOB記憶域」サブページを開きます。
1つ以上のキュー・プロパティを変更します。
「適用」をクリックすると変更が保存されます。
注意: DBMS_AQADM.ALTER_QUEUE_TABLE プロシージャを使用して、キュー表を変更することもできます。 |
Enterprise Managerを使用して、既存の伝播のスケジュールを変更できます。伝播スケジュールによって、伝播があるキューから別のキューに送信される時期と頻度、および各伝播が終了するまでの時間が決定されます。次のスケジュール・オプションを変更できます。
待機時間: 完全に伝播されたキュー内の新しいメッセージが伝播される前に待機する時間
伝播の期間: 個々の伝播が終了するまでの時間
次回: 個々の伝播間の時間
一般的に、伝播スケジュールを変更して、メッセージング環境での伝播のパフォーマンスを向上します。これらのオプションはデフォルト設定では、通常最適な設定になっています。ただし、これらのオプションに対して異なる設定をして、パフォーマンスを最適化できます。
伝播を変更するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「アドバンスト・キューの管理」をクリックして「アドバンスト・キューの管理」ページを開きます。
変更する伝播のソース・キューを選択します。ソース・キューは、伝播がメッセージを宛先キューに送信する元のキューです。
「アクション」リストの「伝播スケジュール」を選択します。
「実行」をクリックして「伝播スケジュール」ページを開きます。
変更する伝播スケジュールを選択します。
「編集」をクリックして「伝播スケジュールの編集」ページを開きます。
1つ以上のスケジュール・オプションを変更します。
「適用」をクリックすると変更が保存されます。
注意: DBMS_AQADM.ALTER_PROPAGATION_SCHEDULE プロシージャを使用して、伝播スケジュールを変更することもできます。 |
この項では、Enterprise Managerを使用してメッセージング環境に関する情報を表示する方法を説明します。この項では、キュー内のメッセージ、キュー統計およびキュー・コンシューマを表示する方法も示します。
次の各項で、メッセージング環境の監視について説明します。
キュー内のメッセージを表示して、アプリケーションがメッセージを正しくエンキューしていることを確認したり、どのメッセージが現在デキューまたは別のキューに伝播される準備ができているかを参照したりできます。
キューに現在格納されているメッセージを表示するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「アドバンスト・キューの管理」をクリックして「アドバンスト・キューの管理」ページを開きます。
メッセージを含むキューを選択します。必要に応じて、検索ツールを使用してキューを検索してから選択します。
「アクション」リストの「メッセージ」を選択します。
「実行」をクリックします。
「メッセージ」ページで、「実行」をクリックします。メッセージがリストされます。
「状態の異なるコンシューマ」フィールドの番号リンクをクリックして、メッセージのコンシューマを表示します。コンシューマは、メッセージを別のキューに送信する伝播またはメッセージをデキューするアプリケーションです。
永続メッセージング・モードを使用している場合、メッセージはハード・ディスクのキュー表に格納されます。この項では、永続モードで永続キューにエンキューされたメッセージの統計の表示について説明します。
永続キュー統計を表示するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「アドバンスト・キューの管理」をクリックして「アドバンスト・キューの管理」ページを開きます。
メッセージを含むキューを選択します。必要に応じて、検索ツールを使用してキューを検索してから選択します。
「アクション」リストの「キュー統計」を選択します。
「実行」をクリックします。
「キュー統計」ページで、「メッセージの統計」をクリックしてキューの永続キュー統計を表示します。
メッセージ統計は、永続キュー内の各状態のメッセージ数を示します。これらは、メッセージがデキューされる合計待機時間と平均待機時間も示します。
注意:
|
コンシューマは、特定のキューからメッセージをデキューするように構成されます。メッセージング環境では、コンシューマはキューへのサブスクライバによって表現され、複数のコンシューマが単一のサブスクライバを使用できます。
コンシューマは次の処理を行うことができます。
メッセージをデキューして処理するアプリケーションまたはユーザー
あるキューから別のキューにメッセージを送信する伝播
メッセージング環境のカスタム・プロセスのメッセージのデキュー、またはレプリケーション環境のデータベース・オブジェクトに対する変更のデキューを行えるプロセスの適用
特定のキューからメッセージをデキューできるコンシューマを表示するには:
Oracle Enterprise Managerで、Oracle Streams管理者としてハブ・データベースにログインします。
「データベース」ホームページに移動します。
「データ移動」をクリックして「データ移動」サブページを開きます。
「アドバンスト・キューの管理」をクリックして「アドバンスト・キューの管理」ページを開きます。
キューを選択します。必要に応じて、検索ツールを使用してキューを検索してから選択します。
「アクション」リストの「サブスクライバ」を選択します。
「実行」をクリックして「サブスクライバ」ページを開きます。
「サブスクライバ」ページには、キューに対する各サブスクライバに関する次の情報が含まれます。
「名前」フィールドには、サブスクライバの名前が含まれます。
「アドレス」フィールドは、通常、サブスクライバが別のキューにメッセージを送信する伝播である場合に移入されます。「アドレス」フィールドは、メッセージを受信するキューの名前を示します。
「データベース・リンク」フィールドは、サブスクライバがリモート・データベースにいる場合にリモート・データベースへのデータベース・リンクを示します。
「ルール」フィールドは、サブスクライバによって使用されるルールを示します。ルールによって、サブスクライバがデキューするメッセージを決定できます。一部のサブスクライバはルールを使用しません。
「変換」フィールドは、サブスクライバによって使用される変換を示します。変換は、デキュー中にメッセージを変更します。一部のサブスクライバは変換を使用しません。
注意: ALL_QUEUE_SUBSCRIBERS データ・ディクショナリを問い合せて、メッセージをデキューできるコンシューマを表示することもできます。 |
この項では、メッセージング環境で最も一般的な問題について説明します。これらの問題の修正方法も説明します。
次の各項で、メッセージング環境のトラブルシューティングについて説明します。
必要な権限のないユーザーがメッセージをエンキューまたはデキューしようとする場合、Oracle Databaseから次のエラーが返されます。
ORA-01031: insufficient privileges
Oracle Databaseがこのメッセージを返す場合、エンキューまたはデキュー操作は失敗します。問題を修正するには、キューでのENQUEUE
またはDEQUEUE
権限をユーザーに付与します。
ユーザーにENQUEUEまたはDEQUEUE権限を付与するには:
コマンドラインでSQL*Plusを開き、Oracle Streams管理者やSYSTEM
などの管理ユーザーとしてデータベースに接続します。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
DBMS_AQADM
プロシージャを実行し、必要なキュー権限をユーザーに付与します。パッケージで
GRANT_QUEUE_PRIVILEGE
たとえば、strmadmin.streams_queue
キューで、ENQUEUE
権限をhr
ユーザーに付与し、次のプロシージャを実行します。
BEGIN DBMS_AQADM.GRANT_QUEUE_PRIVILEGE ( privilege => 'ENQUEUE', queue_name => 'strmadmin.streams_queue', grantee => 'hr'); END; /
strmadmin.streams_queue
キューで、DEQUEUE
権限をhr
ユーザーに付与するには、次のプロシージャを実行します。
BEGIN DBMS_AQADM.GRANT_QUEUE_PRIVILEGE ( privilege => 'DEQUEUE', queue_name => 'strmadmin.streams_queue', grantee => 'hr'); END; /
ユーザーまたはアプリケーションがメッセージをエンキューしょうとするとき、メッセージのコンシューマがない場合、Oracle Databaseから次のエラーが返されます。
ORA-24033: no recipients for message
Oracle Databaseがこのメッセージを返す場合、メッセージはエンキューされません。
問題を解決するには:
メッセージに対して少なくとも1つのコンシューマを構成します。
メッセージをエンキューします。
コンシューマは次の処理を行うことができます。
メッセージをデキューして処理するアプリケーションまたはユーザー
あるキューから別のキューにメッセージを送信する伝播
メッセージング環境のカスタム・プロセスのメッセージのデキュー、またはレプリケーション環境のデータベース・オブジェクトに対する変更のデキューを行えるプロセスの適用
メッセージをデキューし、アプリケーションに渡すメッセージ・クライアント
メッセージの送信時、伝播ではソース・キューを所有しているデータベース・ユーザーの権限が使用されます。ソース・キューの所有者が、伝播で使用するデータベース・リンクにアクセスできない場合、Oracle Databaseから次のエラーが返されます。
ORA-02019: connection description for remote database not found
Oracle Databaseがこのメッセージを返す場合、メッセージは伝播されません。この問題を修正する最も簡単な方法は、データベース・リンクを削除し、再作成して、ソース・キューの所有者がデータベースにアクセスできるようにします。
データベース・リンクを削除し、再作成するには:
Oracle Enterprise Managerで、SYSTEM
またはOracle Streams管理者などの管理者ユーザーとしてデータベースにログインします。
「データベース」ホームページに移動します。
「スキーマ」をクリックして「スキーマ」サブページを開きます。
「データベース・オブジェクト」セクションの「データベース・リンク」をクリックします。
「データベース・リンク」ページが表示されます。
検索ツールを使用して、削除および再作成するデータベース・リンクを表示します。
データベース・リンクを選択します。
「削除」をクリックします。
確認ページで「はい」をクリックしてデータベース・リンクを削除します。
「チュートリアル: データベース・リンクの作成」の手順に従って、このデータベース・リンクを再作成します。
伝播のソース・キューの所有者にデータベース・リンクへのアクセス権があることを確認するには、データベース・リンクを作成したときに、「接続モード」セクションで固定ユーザーとしてこのユーザーを指定します。
メッセージがデキューされた後、次の理由によりメッセージはキュー内に残ります。
メッセージの1つ以上のコンシューマがメッセージをデキューしていません。すべてのコンシューマがメッセージをデキューするまで、キューからメッセージは削除されません。
メッセージはバックグラウンド・プロセスでクリーン・アップされていません。すべてのメッセージのコンシューマがメッセージをデキューした後、バックグラウンド・プロセスでメッセージが自動的に削除されるまで、キュー内にメッセージが残ります。
キュー内でコンシューマがデキューしたメッセージが検出された場合、Enterprise Managerを使用して、メッセージのコンシューマを確認し、すべてのメッセージのコンシューマがメッセージをデキューしたかどうかを判断します。
キュー内でメッセージを確認するには:
「メッセージをデキューできるコンシューマの表示」の手順に従い、メッセージをデキューできるコンシューマを表示します。メッセージに対して、複数のコンシューマがある場合、一部のコンシューマはまだメッセージをデキューできない場合があります。
「キュー内のメッセージの表示」の手順に従います。「状態の異なるコンシューマ」フィールドで、メッセージに対してPROCESSED
が表示された場合、すべてのメッセージのコンシューマはメッセージをデキューします。この場合、バックグラウンド・プロセスでメッセージが自動的に削除されるまで、メッセージはキュー内に残ります。