Monitoring the Topology Defining an Optimal Input File Strategy for Oracle IPM

12 Managing the Topology 12-1 12 Managing the Topology This chapter describes some operations that you can perform after you have set up the topology, including monitoring, scaling, and backing up your topology. It contains the following sections: ■ Section 12.1, Monitoring the Topology ■ Section 12.2, Defining an Optimal Input File Strategy for Oracle IPM ■ Section 12.3, Deploying Composites and Artifacts in SOA Enterprise Deployment Topology ■ Section 12.4, Managing Space in the SOA Infrastructure Database ■ Section 12.5, Configuring UMS Drivers ■ Section 12.6, Scaling the Topology ■ Section 12.7, Performing Backups and Recoveries ■ Section 12.8, Troubleshooting ■ Section 12.9, Best Practices

12.1 Monitoring the Topology

For information on monitoring the Oracle ECM topology, see the following documents: ■ Oracle Fusion Middleware System Administrators Guide for Content Server ■ Oracle Fusion Middleware Application Administrators Guide for Content Server ■ Oracle Fusion Middleware Administrators Guide for Imaging and Process Management

12.2 Defining an Optimal Input File Strategy for Oracle IPM

The input file is the smallest unit of work that the input agent can schedule and process. There are multiple elements to be taken into consideration to achieve the highest performance, scalability, and high availability in an IPM cluster: ■ All of the machines in an Oracle IPM cluster share a common input directory. ■ Input files from this directory are distributed to each machine via a JMS queue. ■ The frequency with which the directory is polled for new files is configurable. ■ Each machine has multiple parsing agents that process the input files. The number of parsing agents is configured via the Work Manager created within the Oracle I PM deployment. 12-2 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle ECM Suite Optimum performance will be achieved when: ■ Each Oracle IPM cluster instance has the maximum affordable number of parsing agents configured via the Work Manager without compromising the performance of the other IPM activities, such as the user interface and Web services. ■ The inbound flow of documents is partitioned into input files containing the appropriate number of documents. On average there should be two input files queued for every parsing agent within the cluster. ■ If one or more machines within a cluster fails, active machines will continue processing the input files. Input files from a failed machine will remain in limbo until the server is restarted. Smaller input files ensure that machine failures do not place large numbers of documents into this limbo state. For example, consider 10,000 inbound documents per hour being processed by two servers. A configuration of two parsing agents per server produces acceptable overall performance and ingests two documents per second per agent. The four parsing agents at two documents per second is eight documents per second, or 28,800 documents per hour. Note that a single input file of 10,000 documents will not be processed in an hour since a single parsing agent working at 7,200 documents per hour will be unable to complete it. However, if you divide the single input file up into eight input files of 1,250 documents, this ensures that all four parsing agents are fully utilized, and the 10,000 documents are completed in the one hour period. Also, if a failure should occur in one of the servers, the other can continue processing the work remaining on its parsing agents until the work is successfully completed.

12.3 Deploying Composites and Artifacts in SOA Enterprise Deployment Topology