| Oracle® Retail Integration Bus Operations Guide Release 13.0.1 |
|
 Previous |
 Next |
The Oracle Enterprise Messaging Service (OEMS) provides a robust architecture for integrating business-critical applications. Built on Java 2 Enterprise Edition (J2EE) standards such as the Java Message Service (JMS) and the J2EE ConnectorArchitecture (JCA), OEMS reduces the time, cost, and effort required to build integrated and distributed applications. Through a common interface, JMS, OEMS offers developers a quality of service (QoS) choice for persisting messages.
The RIB is designed to be JMS provider agnostic and will be certified with several, starting with the OEMS JMS Database persistence option; which is the JMS interface to the Oracle Database Streams Advanced Queuing (AQ) feature. Subsequent releases will add certification of the OC4J JMS (for the file and memory-persistence version) that is bundled with the Oracle Application Server, as well as other JMS standard providers.
For more details on OEMS, see the Oracle® Containers for J2EE Services Guide 10g - Using Oracle Enterprise Messaging Service.
The AQ JMS is a database and needs to be installed, configured, and tuned to support the anticipated transaction loads for a retailer's production message volumes.
There are some areas to be considered by the RIB team and the Database Administrators.
It is strongly recommended that the Oracle Database Instance that is configured to be the AQ JMS provider is not shared with any other applications and is not on the same host (physical or logical) with any other applications.
AQ, on the server side, is I/O intensive. Pay close attention to the disk layout.
AQ JMS as used by the RIB will have high transaction rates. Consider this in configuration of the redo logs.
AQ JMS should be run in archive log mode. If the database crashes, it must be recoverable to a point-in-time or messages (business events) will be lost.
The RIB is a client of the AQ database and uses JDBC connections via the aqapi client. The average message size for a given interface affects the network and overall performance behavior.
AQ JMS sizing to avoid out-of-space situations is critical.
The QMON processes are optional background processes for Oracle Streams Advanced Queuing (AQ) which monitor and maintain all the system and user owned AQ objects. They provide the mechanism for message expiration, retry, and delay, maintain queue statistics, remove processed messages from the queue table and maintain the dequeue IOT.
The number of queue monitor processes is controlled by the dynamic initialization parameter AQ_TM_PROCESSES. There can be a maximum of 10 QMON processes. The parameter AQ_TM_PROCESSES can be set in the PFILE or SPFILE:
aq_tm_processes=4
alter system set aq_tm_processes=4
Starting with Oracle RDBMS release 10.1, Oracle automatically manages the QMON monitor processes depending on the system load. It is no longer required to explicitly set AQ_TM_PROCESSES. However, it is recommended to monitor the workload and make any adjustments. If the QMON processes lag behind, there is a chance of expired messages remaining in the queue and the tablespace eventually running out of space.
If explicitly setting AQ_TM_PROCESSES, our recommended value is between 2 to 8. Do not set the value to the maximum allowed value of 10 in Oracle 10g. This is due to the fact that all explicitly started QMON processes work only with persistent messages. Oracle can automatically start processes to maintain buffered messages. Setting AQ_TM_PROCESSES to a maximum value of 8 still leaves 2 processes for Oracle that can be started to maintain buffered messages.
The AQ database performance needs to be tuned as per Oracle database tuning practices.
Tuning the SGA. Use tools such as Statspack, Oracle Enterprise Manager and SQL trace to find out bottlenecks. An inefficiently configured SGA will slow-down enqueue and dequeue transactions.
Tune the Server Resources: Check server CPU, memory, I/O and network utilization. Tools such as nmon, sar, iostat, vmstat, glance can be used to collect system statistics. Use shared memory and semaphore parameters that are recommended for the Oracle database on that type of server.
Tune Physical Schema setup: This will include creating right tablespaces, placements of datafiles, tables, and indexes.
|
Note: See also Oracle® Database Administrator's Guide 10g Release 2 (10.2), Oracle® Streams Advance Queuing User's Guide, and Reference 10g Release 2 (10.2) |
There some important considerations required by the RIB team and Database Administrators for sizing for the deployment of the RIB on AQ JMS.
The enqueuing/dequeuing rate for the messages per message family affects the requirement for the number of available database segments.
By default, all RIB topics are created in a single tablespace. AQ creates multiple tables for each topic within that tablespace. A topic (message family) that has a high transaction rate can quickly consume available segments. If the tablespace is not sized appropriately, then a single interface can negatively impact all interfaces.
The QMON background process that is responsible for space management will not keep up the transaction rates of some RIB interfaces. In this case, the transaction rate is defined as the rate of enqueuing vs. dequeuing. Messages that are subscribed (consumed) are not removed from the AQ tables immediately. It is the normal case that the enqueue rate will be faster than the dequeue rate. This time lag should be a sizing consideration.
The total tablespace(s) sizing needs to be calculated based on the business requirement for the number of messages that have to be retained per message family if a subscribing application is off-line.
It is very common for a subscribing application to go off-line. This means that messages have to be retained (persisted) on the JMS until the subscriber comes back on-line. The general sizing guideline for any RIB JMS sub-system is for the disk (mount points or database) to be able to handle 24 hours of maximum messages per topic as defined by the site's projected volume requirements. For example -- OrdersFromRMS may be specified to retain 355,000 details (e.g. 1000 1M messages = 1GB). This calculation needs to be performed for each of the 90+ topics in the GA RIB system and based on the customer's estimated volume per interface.
