Oracle Database 2日でデータ・レプリケーションおよび統合ガイド 11g リリース1(11.1) E05777-03 |
|
この章では、データベースおよびアプリケーション間でメッセージを送信するOracle Streams Advanced Queuing(AQ)環境の構成方法を説明します。また、構成後のメッセージング環境の管理、監視およびトラブルシューティングについても説明します。
この章は次の項で構成されています。
メッセージング環境は、情報をキューに格納します。メッセージをキューに置くプロセスがエンキュー、メッセージをキューから取得するプロセスがデキューです。
キュー内の情報は、タスクを完了するために使用されることも、アプリケーションによって処理されることもあります。メッセージング環境では、アプリケーションの非同期な相互通信が可能です。つまり、アプリケーションは他のアプリケーションが特定のタスクを完了するまで待機する必要がありません。非同期通信の重要性は、メッセージング・システムがそれを利用するアプリケーションの機能に最小の影響しか与えないという点にあります。
たとえば、他のアプリケーションとの通信が必要な場合、アプリケーションはメッセージをキューに置くことができます。メッセージは、他方のアプリケーションによって取得されるまでキュー内に格納されます。実際、メッセージのエンキュー時に他方のアプリケーションが実行されていなくても、メッセージは後で処理されます。メッセージは、取得側アプリケーションにアクションの実行を指示する場合も、あるいは取得側アプリケーションによる処理が必要な情報を含んでいる場合もあります。
組織に、相互通信が必要な複数の異なるシステムがある場合は、メッセージング環境が適切なソリューションになります。様々なシステムが異なる場所にある場合があり、一部は他のシステムより古く、一部は異なるプラットフォームで稼働していることがあります。メッセージングは、これらのシステム間で重要な情報を転送する標準的な信頼性のある方法を提供します。
Oracle Databaseのメッセージング機能は、Oracle Streams Advanced Queuing(AQ)と呼ばれます。Oracle Streams AQはメッセージ機能の利点を提供するとともに、メッセージング・システムとOracle Databaseを統合します。したがって、Oracle Streams AQはOracle Databaseの信頼性、スケーラビリティ、セキュリティ、管理性をもたらします。
Oracle Streams AQを使用して、単一データベース内のキュー間または異なるデータベースのキュー間でメッセージを送信するメッセージング環境を構成できます。キュー間でメッセージを送信するメッセージング環境には、次のコンポーネントが含まれます。
シングル・ユーザーまたはアプリケーションは、プロデューサおよびコンシューマとして動作できます。メッセージング環境では、サブスクライバおよびメッセージ・クライアントは、コンシューマです。サブスクライバおよびメッセージ・クライアントは、キューからメッセージをデキューすることを許可されたメカニズムで、ルールを使用してどのメッセージをデキューするかを判断できます。
Oracle Streams AQは多くの機能を提供し、その一部はこのマニュアルの対象外です。次の各項で、Oracle Streams AQのいくつかの機能の概要を示します。
参照:
メッセージの順序付けでは、メッセージがデキューされる順序を決定します。Oracle Streams Advanced Queuing(AQ)には、メッセージの順序付けに次のオプションが用意されています。
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に設定」を参照してください。
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に、この例で作成するメッセージング環境の概要を示します。
この例を開始する前に、「メッセージ機能の準備」で説明されているタスクを完了します。
注文について送信する情報を定義するユーザー定義タイプを作成します。この例では、注文IDと注文日を含むメッセージ用にstrmadmin.order_id_date
タイプを作成します。
ii1.example.com
データベースにログインします。
order_id_date
と入力します。
strmadmin
が選択されていることを確認します。
ii2.example.com
データベースにログインします。
ii2.example.com
データベースで手順3〜15を完了して、両方のデータベースがstrmadmin.order_id_date
タイプを持つようにします。
各データベースにキューを作成し、注文に関するメッセージを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
である必要があります。方法については、「チュートリアル: データベース・リンクの作成」を参照してください。
ii1.example.com
データベースにログインします。
send_orders
と入力します。
strmadmin.streams_queue
と入力します。このキューは、注文に関するメッセージがエンキューされるii1.example.com
データベースのキューです。
ii2.example.com
です。
strmadmin.streams_queue
を入力します。これは注文に関するメッセージが送信されるii2.example.com
データベースのキューです。
メッセージング・システム内のメッセージをエンキューするメカニズムを構成します。通常、アプリケーションは、別のアプリケーションによってデキューされ、処理されるメッセージを作成し、エンキューします。簡略化のために、この例ではenqueue_orders
というトリガーを作成して、注文の注文IDと注文日を含むメッセージをエンキューします。トリガーは、注文がoe.orders
表に挿入されたときに起動します。
DBMS_STREAMS_MESSAGING
パッケージに対するEXECUTE
権限を付与します。この例では、DBMS_STREAMS_MESSAGING
パッケージのENQUEUE
プロシージャを実行するトリガーを構成します。トリガー内のこのプロシージャを実行するユーザーには、プロシージャを含むパッケージに対する明示的なEXECUTE
権限が必要です。ロールを通じて権限を付与することはできません。したがって、Oracle Streams管理者にはパッケージに対する明示的なEXECUTE
権限を付与する必要があります。
strmadmin
ユーザーに権限を付与できる管理ユーザーとしてEnterprise Managerにログインします。たとえば、SYSDBA
権限を持つユーザーとしてログインできます。この例では、ii1.example.com
データベースにログインします。
「ユーザー」ページが表示されます。
STRMADMIN
ユーザーを選択します。
「ユーザーの編集」ページが表示され、「一般」サブページが表示されます。
SYS.DBMS_STREAMS_MESSAGING
と入力します。
oe.orders
表に変更があったときメッセージを自動的にエンキューするトリガーを、ii1.example.com
データベースに作成します。
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;
oe.orders
と入力します。
OLD
を入力します。
NEW
を入力します。
メッセージング・システム内のメッセージをデキューするメカニズムを構成します。通常、アプリケーションは別のアプリケーションによって作成されたメッセージをデキューして処理します。簡略化のために、この例ではdequeue_orders
というPL/SQLプロシージャを作成して、注文の注文IDおよび注文日を含むメッセージをデキューします。この例ではプロシージャをコールしてメッセージをデキューしますが、アプリケーションはこのようなプロシージャを定期的に実行できます。
ii2.example.com
データベースのOracle Streams管理者に、SYS.DBMS_STREAMS_MESSAGING
パッケージに対するEXECUTE
権限を付与します。ii1.example.com
データベースのOracle Streams管理者にこの権限を付与する例は、「タスク3: メッセージ・エンキュー・メカニズムの構成」の手順1を参照してください。
ii2.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
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
タイプの新しいメッセージをすべてデキューします。
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;
「タスク3: メッセージ・エンキュー・メカニズムの構成」の例では、トリガーを作成しました。トリガーは、oe.orders
表に挿入された注文に関する情報とともにメッセージをstrmadmin.streams_queue
キューにエンキューします。このため、oe.orders
表に行を挿入することにより、メッセージをstrmadmin.streams_queue
キューにエンキューできます。
oe
ユーザーとしてii1.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
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);
COMMIT;
「タスク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
表に挿入した注文に関する情報が含まれます。
ii2.example.com
データベースに接続します。SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
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つのアプリケーションを作成しません。かわりに、メッセージ通知の構成方法、および対象のメッセージがエンキューされたときにメッセージ通知を使用してそのメッセージを自動的にデキューする方法を示します。
図9-2に、この例で作成するメッセージング環境の概要を示します。
注意: データベース間でメッセージを送信する環境でメッセージ通知を構成できます。データベース間でメッセージを送信する環境の例の詳細は、「チュートリアル: Oracle Database間でのメッセージの送信」を参照してください。 |
参照:
ユーザー定義型を作成して、アプリケーションについて追跡する情報を定義します。この例では、パラメータと値を含むメッセージに対してstrmadmin.app_info
型を作成します。
app_info
と入力します。
strmadmin
が選択されていることを確認します。
app_info
型に1番目の属性を追加するには:
app_info
型に次の属性を追加するには:
キュー表とキューを作成して、最初のアプリケーションが2番目のアプリケーションに対して生成するメッセージを格納します。キューの作成後に、メッセージ通知はメッセージをキューからデキューできるコンシューマを必要とします。この例では、メッセージ・クライアントが、streams_queue
キューからメッセージをデキューできるコンシューマです。
streams_queue
という名前のキューをOracle Streams管理者のスキーマに作成します。方法については、「ANYDATAキューの作成」を参照してください。
SQL*Plusの起動の詳細は、『Oracle Database 2日でデータベース管理者』を参照してください。
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
型の新しいメッセージをすべてデキューします。
この拡張例では、2番目のアプリケーションがstreams_queue
キューからメッセージをデキューできる必要があります。簡略化のために、この例ではdequeue_app_messages
というPL/SQLプロシージャを作成して、strmadmin.app_info
型のメッセージをデキューします。このプロシージャは、「タスク2: キューおよびメッセージ・クライアントの構成」で作成したメッセージ・クライアントを使用してメッセージをデキューします。
DBMS_AQ
パッケージに対するEXECUTE
権限を付与します。この例では、DBMS_AQ
パッケージのDEQUEUE
プロシージャを実行するプロシージャを構成します。このプロシージャを実行するユーザーには、プロシージャを含むパッケージに対する明示的なEXECUTE
権限が必要です。ロールを通じて権限を付与することはできません。したがって、Oracle Streams管理者にはパッケージに対する明示的なEXECUTE
権限を付与する必要があります。
strmadmin
ユーザーに権限を付与できる管理ユーザーとして、Enterprise Managerにログインします。
「ユーザー」ページが表示されます。
STRMADMIN
ユーザーを選択します。
「ユーザーの編集」ページの「一般」サブページが表示されます。
SYS.DBMS_AQ
と入力します。
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
型のメッセージをデキューする単純な通知プロシージャです。
この拡張例では、新しいメッセージがstrmadmin.streams_queue
キューにエンキューされたときにメッセージ通知がstrmadmin.dequeue_app_messages
プロシージャを起動します。このプロシージャは、新しいメッセージをデキューします。デキュー後に、アプリケーションはカスタマイズされた任意の方法でメッセージを処理できます。この例では、2番目のアプリケーションはメッセージ内の情報を使用してアプリケーション・パラメータ値を設定します。簡略化のために、この例では2番目のアプリケーションを構成しません。
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; /
この拡張例では、1つのアプリケーションが、2番目のアプリケーションによって処理されるメッセージをエンキューします。簡略化のために、この例ではメッセージを手動でエンキューします。メッセージがエンキューされた後で、メッセージ通知を通じて自動的にデキューされたことを確認できます。
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
キュー内のメッセージを表示し、これらがメッセージ通知を使用して自動的にデキューされたかどうかを確認します。方法については、「キュー内のメッセージの表示」を参照してください。この例で構成したメッセージ通知が正常に動作している場合は、「メッセージ」ページに次のいずれかが表示されます。
Enterprise Managerを使用して、次のプロパティを含め、既存のキューのプロパティの一部を変更できます。
これらのプロパティは、キューからメッセージをデキューするアプリケーションで最適な値に設定できます。
Enterprise Managerを使用して、既存のキュー表の記憶域オプションの一部を変更できます。キュー表の記憶域オプションを変更すると、キュー表を使用するキューのパフォーマンスが向上します。
「Streams」ページが表示され、「概要」サブページが表示されます。
「キュー表の編集」ページが表示され、「一般」サブページが表示されます。
Enterprise Managerを使用して、既存の伝播のスケジュールを変更できます。伝播スケジュールによって、伝播があるキューから別のキューに送信される時期と頻度、および各伝播が終了するまでの時間が決定されます。次のスケジュール・オプションを変更できます。
一般的に、伝播スケジュールを変更して、メッセージング環境での伝播のパフォーマンスを向上します。これらのオプションはデフォルト設定では、通常最適な設定になっています。ただし、これらのオプションに対して異なる設定をして、パフォーマンスを最適化できます。
「Streams」ページが表示され、「概要」サブページが表示されます。
この項では、Enterprise Managerを使用してメッセージング環境に関する情報を表示する方法を説明します。この項では、キュー内のメッセージ、キュー統計およびキュー・コンシューマを表示する方法も示します。
次の各項で、メッセージング環境の監視について説明します。
キュー内のメッセージを表示して、アプリケーションがメッセージを正しくエンキューしていることを確認したり、どのメッセージが現在デキューまたは別のキューに伝播される準備ができているかを参照したりできます。
「Streams」ページが表示され、「概要」サブページが表示されます。
ページの詳細は、ページの「ヘルプ」をクリックしてください。
永続メッセージング・モードを使用している場合、メッセージはハード・ディスクのキュー表に格納されます。この項では、永続モードで永続キューにエンキューされたメッセージの統計の表示について説明します。
「Streams」ページが表示され、「概要」サブページが表示されます。
メッセージ統計は、永続キュー内の各状態のメッセージ数を示します。これらは、メッセージがデキューされる合計待機時間と平均待機時間も示します。
注意:
|
コンシューマは、特定のキューからメッセージをデキューするように構成されます。メッセージング環境では、コンシューマはキューへのサブスクライバによって表現され、複数のコンシューマが単一のサブスクライバを使用できます。
コンシューマは次の処理を行うことができます。
「Streams」ページが表示され、「概要」サブページが表示されます。
「サブスクライバ」ページには、キューに対する各サブスクライバに関する次の情報が含まれます。
このページの詳細を表示するには、「ヘルプ」をクリックします。
この項では、メッセージング環境で最も一般的な問題について説明します。これらの問題の修正方法も説明します。
次の各項で、メッセージング環境のトラブルシューティングについて説明します。
必要な権限のないユーザーがメッセージをエンキューまたはデキューしようとする場合、Oracle Databaseから次のエラーが返されます。
ORA-01031: insufficient privileges
Oracle Databaseがこのメッセージを返す場合、エンキューまたはデキュー操作は失敗します。問題を修正するには、キューでのENQUEUE
またはDEQUEUE
権限をユーザーに付与します。
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がこのメッセージを返す場合、メッセージはエンキューされません。
コンシューマは次の処理を行うことができます。
メッセージの送信時、伝播ではソース・キューを所有しているデータベース・ユーザーの権限が使用されます。ソース・キューの所有者が、伝播で使用するデータベース・リンクにアクセスできない場合、Oracle Databaseから次のエラーが返されます。
ORA-02019: connection description for remote database not found
Oracle Databaseがこのメッセージを返す場合、メッセージは伝播されません。この問題を修正する最も簡単な方法は、データベース・リンクを削除し、再作成して、ソース・キューの所有者がデータベースにアクセスできるようにします。
SYSTEM
またはOracle Streams管理者などの管理者ユーザーとしてデータベースにログインします。
「データベース・リンク」ページが表示されます。
伝播のソース・キューの所有者にデータベース・リンクへのアクセス権があることを確認するには、データベース・リンクを作成したときに、「接続モード」セクションで固定ユーザーとしてこのユーザーを指定します。
メッセージがデキューされた後、次の理由によりメッセージはキュー内に残ります。
キュー内でコンシューマがデキューしたメッセージが検出された場合、Enterprise Managerを使用して、メッセージのコンシューマを確認し、すべてのメッセージのコンシューマがメッセージをデキューしたかどうかを判断します。
PROCESSED
が表示された場合、すべてのメッセージのコンシューマはメッセージをデキューします。この場合、バックグラウンド・プロセスでメッセージが自動的に削除されるまで、メッセージはキュー内に残ります。
|
Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|