Understanding AQs in Workflow

This blog post contributed by Shivdas Tomar.

In Oracle Workflow, Advanced Queues are used for inter-process communication, background processing, sending messages to external agents and so on. Many times the messages may not be dequeued by the consumers such as Workflow Agent Listeners or Workflow Background Engines.

Symptoms

  • Workflow Agent Listeners or Background engines are not able to dequeue messages in READY state.
  • Messages continue to be in WAIT state even after passing the "delay" interval
  • Processed messages are not purged after passing the "retention" interval
  • Queue propagation is not happening

Checks

Always check AQ view (AQ$<Queue_Table_Name> for message state and not the under lying table directly.

  • If messages are in READY state but consumers such as Workflow Agent Listeners and Workflow Background Engines are not able to dequeue, then there might be issues with message recipients or AQ subscribers. Check the CONSUMER_NAME and ADDRESS columns value in that AQ and then the subscriber rule sets.
  • If event messages are not moving from one state to another, check AQ_TM_PROCESSES parameter's value to be greater than 0.
Note: In 10gR1 or later database releases, the AQ time management and many other background processes are automatically controlled by a coordinator-slave architecture called Queue Monitor Coordinator (QMNC). QMNC dynamically spawns slaves named qXXX depending on the system load.
If you want to disable the Queue Monitor Coordinator, then you must set AQ_TM_PROCESSES = 0 in your pfile or spfile. Oracle strongly recommends that you DO NOT set AQ_TM_PROCESSES = 0. If you are using Oracle Streams, setting this parameter to zero (which Oracle Database respects no matter what) can cause serious problems. So either remove AQ_TM_PROCESSES parameter or do not set its value as zero.
  • Check if processes, named like 'qmnc' or 'ora_qxxx' are running at the OS level. If there are no such process(es) running then bounce the Oracle Database after removing AQ_TM_PROCESSES or changing its value to a non-zero value as recommended in Oracle Applications setup documentation.

  • If Queue propagation is not happening, job_queue_processes parameter's value should be checked.
Note: In 11gR1 or later database releases, the init.ora parameter JOB_QUEUE_PROCESSES does not need to be set for AQ propagations. AQ propagation is now handled by DBMS_SCHEDULER jobs rather than DBMS_JOBS.
Propagation takes advantage of the event based scheduling features of DBMS_SCHEDULER for better scalability. If the value of the JOB_QUEUE_PROCESSES database initialization parameter is zero, then that parameter does not influence the number of Oracle Scheduler jobs that can run concurrently. However, if the value is non-zero, it effectively becomes the maximum number of scheduler jobs and job queue jobs that can run concurrently. If a non-zero value is set, it should be large enough to accommodate a scheduler job for each Messaging Gateway agent to be started.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog is dedicated to bring latest information on Oracle Workflow new features, best practices, troubleshooting techniques and important fixes directly from it's Development Team.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today