Advanced Queuing - Oracle

Maximum number of bytes propagated in a window
Average number of messages propagated in a window
Average size of propagated messages
JMS Propagation
Average time to propagated a message
These statistics have been designed to provide useful information to the queue
administrators for tuning the schedules such that maximum efficiency can be
achieved.
Propagation has built-in support for handling failures and reporting errors. For
example, if the database link specified is invalid, or the remote database is
unavailable, or the remote topic/queue is not enabled for enqueuing, then the
appropriate error message is reported. Propagation uses an exponential backoff
scheme for retrying propagation from a schedule that encountered a failure. If a
schedule continuously encounters failures, the first retry happens after 30 seconds,
the second after 60 seconds, the third after 120 seconds and so forth. If the retry time
is beyond the expiration time of the current window then the next retry is
attempted at the start time of the next window.
A maximum of 16 retry attempts are made after which the schedule is automatically
disabled. When a schedule is disabled automatically due to failures, the relevant
information is written into the alert log. At anytime it is possible to check if there
were failures encountered by a schedule and if so how many successive failure
were encountered, the error message indicating the cause for the failure and the
time at which the last failure was encountered. By examining this information, an
administrator can fix the failure and enable the schedule.
During a retry if propagation is successful then the number of failures is reset to 0.
Propagation has built-in support for Real Application Clusters and is transparent to
the user and the administrator. The job that handles propagation is submitted to the
same instance as the owner of the queue table where the source topic resides. If at
anytime there is a failure at an instance and the queue table that stores the topic is
migrated to a different instance, the propagation job is also automatically migrated
to the new instance. This will minimize the pinging between instances and thus
offer better performance. Propagation has been designed to handle any number of
concurrent schedules.
Note that the number of job_queue_processes is limited to a maximum of 36
and some of these may be used to handle non-propagation related jobs.Hence,
propagation has built in support for multi-tasking and load balancing. The
propagation algorithms are designed such that multiple schedules can be handled
by a single snapshot (job_queue) process. The propagation load on a job_queue
Creating Applications Using JMS 12-91