The sizing guidelines outlined in this chapter were obtained by running a virtual environment on the following hardware and operating system combination.

• Hardware -- OCI E5 compute and E5 Oracle Base Database Service deployments.

• Operating System -- Oracle Linux 8

This information is based on an x64 Oracle Linux 8 environment. If you are running on other platforms, you will need to convert the sizing information based on similar hardware performance. This conversion should be based on single-thread performance. Running on a machine with 24 slow cores is not equivalent to running on a machine with 12 fast cores even though the total machine performance might be the same on a throughput benchmark. Single thread performance is critical for good Enterprises Manager user interface response times.

The sizing guidelines for Oracle Enterprise Manager are divided into four sizes: small, medium, large and extra large. The definitions of each size are shown in Table 15-1.

If upgrading from a previous release of Enterprise Manager to Enterprise Manager 24ai, the following queries can be run as the sysman user to obtain the Management Agent and target counts for use in Table 1.

• Agent count - select count (*) from mgmt_targets where target_type = ‘oracle_emd'

• Target count – select count (*) from mgmt_targets

Table 15-2 lists the minimum hardware requirements for the four configurations.

A critical consideration when deploying Enterprise Manager is network performance between tiers. Enterprise Manager ensures tolerance of network glitches, failures, and outages between application tiers through error tolerance and recovery. The Management Agent in particular is able to handle a less performant or reliable network link to the Management Service without severe impact to the performance of Enterprise Manager as a whole. The scope of the impact, as far as a single Management Agent's data being delayed due to network issues, is not likely to be noticed at the Enterprise Manager system wide level.

The impact of slightly higher network latencies between the Management Service and Management Repository will be substantial, however. Implementations of Enterprise Manager have experienced significant performance issues when the network link between the Management Service and Management Repository is not of sufficient quality.

The Management Service host and Repository host should be located in close proximity to each other. Ideally, the round trip network latency between the two should be less than 1 millisecond.

The Small configuration is based on the minimum requirements that are required by the Oracle Enterprise Manager installer.

Minimum OMS Settings

WebLogic container: 2 GB

API Gateway: 384 MB

Zero Downtime WebLogic container: 768 MB

Minimum Database Settings

Table 15-4 lists the minimum recommended database settings.

The Medium configuration modifies several out-of-box Oracle Enterprise Manager settings.

Minimum OMS Settings

WebLogic container: 3 GB

API Gateway: 384 MB

Zero Downtime WebLogic container: 768 MB

Minimum Repository Database Settings

Table 15-5 lists the minimum repository database settings that are recommended for a Medium configuration.

The Large configuration modifies several out-of-box Oracle Enterprise Manager settings.

Minimum OMS Settings

Table 15-6 lists the minimum OMS settings that are recommended for Large configurations.

Minimum Repository Database Settings

Table 15-7 lists the minimum repository database settings that are recommended for a Large configuration.

The Extra Large configuration requires the following settings:

Minimum OMS Settings

Table 15-8 lists the minimum OMS settings that are recommended for Extra Large configurations.

Minimum Repository Database Settings

Table 15-9 lists the minimum repository database settings that are recommended for a Extra Large configuration.

If more than 50 concurrent users are expected per OMS, the following settings should be altered as seen in Table 15-10.

Higher user loads will require more hardware capacity. An additional 2 cores for both the database and OMS hosts for every 50 concurrent users.

Example: A site with 1500 agents and 15,000 targets with 150 concurrent users would require at a minimum the setting modifications listed in Table 15-11 (based on a LARGE 2 OMS configuration).

Minimum Additional Hardware required is listed in Table 15-12.

The physical memory of each machine would have to be increased to support running this configuration as well.

The memory parameters values can be changed using the command:

emctl set property -name <property name> -value <property value>

For example: emctl set property -name OMS_HEAP_MAX -value 2000M

If the jobs system has a backlog for long periods of time or if you would like the backlog processed faster, set the following parameters with the emctl set property command.

These settings assume that there are sufficient database resources available to support more load.

The following section provides examples of changing the OMS settings recommended in this chapter. You may need to change OMS property settings, for example, when increasing the Job Backlog. The values in the examples should be substituted with the appropriate value for your configuration. Use the following instructions to change OMS properties.

Changing the Heap Size

API Gateway:

WebLogic Container:

Zero Downtime WebLogic Container:

The following table describes the above parameters and provides a description, default values, recommendations for their use, and any notes, warnings or issues of which to be aware.

You can use the following command to set the value for any of the above properties:

emctl set property –name <property_name> -value <number_followed_by_G_or_M>

For example:

emctl set property –name OMS_PERMGEN_MAX –value 1024M

Use the following command to get the property name:

emctl get property –name <property_name>

An OMS restart using the below commands is required on each OMS after changing the property value:

emctl stop oms -all
emctl start oms

Changing shortPoolSize

To change the OMS property, oracle.sysman.core.jobs.shortPoolSize, follow these recommendations:

To set the property, enter the following command:

$ emctl set property -name oracle.sysman.core.jobs.shortPoolSize -value 200

To get the property (after changing from the default), enter the following command:

$ emctl get property -name “oracle.sysman.core.jobs.shortPoolSize"

To delete the property (revert to original setting), enter the following command:

$ emctl delete property -name “oracle.sysman.core.jobs.shortPoolSize"

After changing the property, the default value is 25.

Changing longPoolSize

To change the OMS property, oracle.sysman.core.jobs.longPoolSize, follow these recommendations:

To set the property, enter the following command:

$ emctl set property -name oracle.sysman.core.jobs.longPoolSize -value 200

To get the property (after changing from the default), enter the following command:

$ emctl get property -name “oracle.sysman.core.jobs.longPoolSize"

To delete the property (revert to original setting), enter the following command:

$ emctl delete property -name “oracle.sysman.core.jobs.longPoolSize"

After changing the property, the default value is 12.

Changing longSystemPoolSize

To change the OMS property, oracle.sysman.core.jobs.longSystemPoolSize, follow these recommendations:

To set the property, enter the following command:

$ emctl set property -name oracle.sysman.core.jobs.longSystemPoolSize -value 200

To get the property (after changing from the default), enter the following command:

$ emctl get property -name “oracle.sysman.core.jobs.longSystemPoolSize"

To delete the property (revert to original setting), enter the following command:

$ emctl delete property -name “oracle.sysman.core.jobs.longSystemPoolSize"

After changing the property, the default value is 10.

Changing systemPoolSize

To change the OMS property, oracle.sysman.core.jobs.systemPoolSize, follow these recommendations:

To set the property, enter the following command:

$ emctl set property -name oracle.sysman.core.jobs.systemPoolSize -value 200

To get the property (after changing from the default), enter the following command:

$ emctl get property -name “oracle.sysman.core.jobs.systemPoolSize"

To delete the property (revert to original setting), enter the following command:

$ emctl delete property -name “oracle.sysman.core.jobs.systemPoolSize"

After changing the property, the default value is 25.

Changing maxConnForJobWorkers

To change the OMS property, oracle.sysman.core.conn.maxConnForJobWorkers, follow these recommendations:

To set the property, enter the following command:

$ emctl set property -name oracle.sysman.core.conn.maxConnForJobWorkers -value 200

To get the property (after changing from the default), enter the following command:

$ emctl get property -name “oracle.sysman.core.conn.maxConnForJobWorkers"

To delete the property (revert to original setting), enter the following command:

$ emctl delete property -name “oracle.sysman.core.conn.maxConnForJobWorkers"

An OMS restart using ‘emctl stop oms; emctl start oms' is required on each OMS after changing the property value. The default value is 25.

Changing omsAgentComm.ping.heartbeatPingRecorderThreads

To change the OMS property, oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads, follow these recommendations:

To set the property, enter the following command:

emctl set property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads -value 5

To get the property (after changing from the default), enter the following command:

emctl get property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

To delete the properties (revert to original setting), enter the following command:

emctl delete property -name oracle.sysman.core.omsAgentComm.ping.heartbeatPingRecorderThreads

An OMS restart using ‘emctl stop oms; emctl start oms' is required on each OMS after changing the property value.

If you have downloaded the Database Templates for a Preconfigured Repository, you can run the appropriate SQL script to adjust the database parameters to the recommended settings. The scripts that you should run are listed in the following table:

When you are asked to evaluate a site for performance and notice high CPU utilization, there are a few common steps you should follow to determine what resources are being used and where.

1. Use the Processes display on the Enterprise Manager Host home page to determine which processes are consuming the most CPU on any Management Service or Management Repository host that has crossed a CPU threshold.

2. Once you have established that Enterprise Manager is consuming the most CPU, use Enterprise Manager to identify what activity is the highest CPU consumer. Typically this manifests itself on a Management Repository host where most of the Management Service's work is performed. Here are a few typical spots to investigate when the Management Repository appears to be using too many resources.

   1. Check out Top Wait Events metrics for the Enterprise Manager Repository.

   2. Click the CPU Used database resource listed on the Management Repository's Database Performance page to examine the SQL that is using the most CPU at the Management Repository.

   3. Check the Database Locks on the Management Repository's Database Performance page looking for any contention issues.

   4. Check the SQL Monitoring on the Management Repository's Database for any resource intensive SQL.

High CPU utilization is probably the most common symptom of any performance bottleneck. Typically, the Management Repository is the biggest consumer of CPU, which is where you should focus. A properly configured and maintained Management Repository host system that is not otherwise hardware resource constrained should average roughly 40 percent or less total CPU utilization. An OMS host system should average roughly 20 percent or less total CPU utilization. These relatively low average values should allow sufficient headroom for spikes in activity. Allowing for activity spikes helps keep your page performance more consistent over time. If your Enterprise Manager site interface pages happen to be responding well (approximately 3 seconds) while there are no significant backlogs, and it is using more CPU than recommended, you may not have to address it unless you are concerned it is part of a larger upward trend.

The recommended path for tracking down the root cause of high Management Repository CPU utilization is captured under steps 3.a, 3b, 3c, and 3.d listed above. CPU should be always be the topmost wait event. Log File Sync wait event indicating slow I/O performance should not appear in the top 5 waits ideally. To identify the root cause, start at the Management Repository Performance page and work your way down to the SQL that is consuming the most CPU in its processing. Correlate your findings with the AWR report. This approach has been used very successfully on several real world sites.

If you are running Enterprise Manager on Intel based hosts, the Enterprise Manager Management Service and Management Repository will both benefit from Hyper-Threading (HT) being enabled on the host or hosts on which they are deployed. HT is a function of certain late models of Intel processors, which allows the execution of some amount of CPU instructions in parallel. This gives the appearance of double the number of CPUs physically available on the system. Testing has proven that HT provides approximately 1.5 times the CPU processing power as the same system without HT enabled. This can significantly improve system performance. The Management Service and Management Repository both frequently have more than one process executing simultaneously, so they can benefit greatly from HT.

The vital signs for the loader indicate exactly how much data is continuously coming into the system from all the Enterprise Manager Agents. The most important item here is the “Number of Agents Sent Back in the Last Hour" metric. The metric can be found in the All Metrics page of each management service. This is the number of agents instructed to defer loading of data in the last hour. Ideally no agent should be instructed to defer loading, but some level of deferred loading is normal. If this value is above 2 percent of your deployed agent count and it is growing continuously, then action should be taken.

Ensure that back-off requests are spread uniformly across OMS in a multi-OMS environment. If the back-off requests pertain to a specific OMS and does not show uniform trend across OMS, verify that the load-balancing algorithm set at Server Load Balancer is round-robin. Add loader threads only if there are backoffs on important channels in the range of hundreds an hour consistently and there are sufficient free resources on the database.

The number of Loader Threads is always set to 20 per OMS by default. Adding loader threads to an OMS increases the overall host CPU utilization. Customers can change this value as their site requires.

There are diminishing returns when adding loader threads if your repository does not have sufficient resources available. If you have available repository resources, as you add loader threads, you should see the “Number of Agents Sent Back in the Last Hour" metric decrease. If you are not seeing improvement you should explore other tuning or housekeeping opportunities.

To add more loader threads, you can change the following configuration parameter:

oracle.sysman.core.gcloader.max_recv_thread

The default value is 20. This is a per OMS setting.

The rollup process is the aggregation mechanism for Enterprise Manager. The two vital signs for the rollup are the rows/second and % of hour run. Due to the large volume of data rows processed by the rollup, it tends to be the largest consumer of Management Repository buffer cache space. Because of this, the rollup vital signs can be great indicators of the benefit of increasing buffer cache size.

Rollup rows/second shows exactly how many rows are being processed, or aggregated and stored, every second. This value is usually around 2,000 (+/- 500) rows per second on a site with a decent size buffer cache and reasonable speedy I/O. A downward trend over time for this value may indicate a future problem, but as long as % of hour run is under 100 your site is probably fine.

If rollup % of hour run is trending up (or is higher than your baseline), and you have not yet set the Management Repository buffer cache to its maximum, it may be advantageous to increase the buffer cache setting. Usually, if there is going to be a benefit from increasing buffer cache, you will see an overall improvement in resource utilization and throughput on the Management Repository host. The loader statistics will appear a little better. CPU utilization on the host will be reduced and I/O will decrease. The most telling improvement will be in the rollup statistics. There should be a noticeable improvement in both rollup rows/second and % of hour run. If you do not see any improvement in any of these vital signs, you can revert the buffer cache to its previous size. The old Buffer Cache Hit Ratio metric can be misleading. It has been observed in testing that Buffer Cache Hit Ratio will appear high when the buffer cache is significantly undersized and Enterprise Manager performance is struggling because of it. There will be times when increasing buffer cache will not help improve performance for Enterprise Manager. This is typically due to resource constraints or contention elsewhere in the application. Consider using the steps listed in the High CPU Utilization section to identify the point of contention. Enterprise Manager also provides advice on buffer cache sizing from the database itself. This is available on the database Memory Parameters page.

If rollup % of hour run is trending up (or is higher than your baseline) and buffer cache is already set to optimal but there is still many cluster Wait events reported in the AWR report, configure the Rollup database service and set affinity to run the Rollup Service only on a single-instance RAC node. Ensure that single-instance RAC node is sized to handle large I/O volume.

Use the following configuration steps for Rollup database service:

1. Create database service "rollup" and set one of the RAC instances as the primary instance in "-r".

   • srvctl add service -d <dbname>-s rollup -r <primary instance> -a <the other instances> -y automatic

   • srvctl start service -d <dbname>-s rollup

     srvctl status service -d <dbname>

2. As sys user, execute DBMS_SCHEDULER.create_job_class( job_class_name => 'ROLLUP', service => 'rollup')

3. GRANT EXECUTE ON sys.ROLLUP TO sysman;

4. As sysman user, execute DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_ROLLUP_SCHED_JOB', attribute => 'job_class', value => 'ROLLUP')

5. As sysman user, execute GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_ROLLUP_SCHED_JOB', 'ROLLUP')

In addition to configuration of Rollup database service, add Rollup worker threads if the database can handle the increased load from these threads. Configure additional rollup worker threads using configure option in Metric Rollup Performance Chart available in self- monitoring "Managing the Manager" Repository page.

Jobs, notifications, and alerts are indicators of the processing efficiency of the Management Service(s) on your Enterprise Manager site.

Jobs

A growing backlog in Jobs Steps Scheduled at the repository indicates there are not enough resources available at the repository. High Job Dispatcher processing time (%) indicates a repository bottleneck. Low throughput with High Job Dispatcher processing time (%) indicates a processing bottleneck. The Jobs subsystem uses the locks to maintain sequence internally, so you can see application locks wait events, and transaction locking wait events in the AWR report in repository. It is normal to observe the Job system consuming 5-8% of waiting time, but if that value crosses 20-30%, it is quite abnormal and should be triaged. If there are significant amounts of cluster waits for Job SQLs in AWR, you could potentially optimize the Job system by introducing RAC services. Create a database service for Jobs and then set affinity to run on a two-node RAC instance for better optimal performance.

Use the following configuration steps to set up the Rollup database service:

1. Create the database service emjob and set two of the RAC instances as primary instance in "-r".

   srvctl add service -d <dbname> -s emjob -r <primary instances> -a <the other instances> -y automatic

   After creating the database service, you need to restart the service using the srvctl start service command.

2. Execute the following DBMS_SCHEDULER jobs:

   • As a sys user, execute DBMS_SCHEDULER.create_job_class( job_class_name => 'EMJOB', service => 'emjob ')

   • GRANT EXECUTE ON sys.EMJOB TO sysman;

   • As a sysman user, execute DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOBS_STEP_SCHED ', attribute => 'job_class', value => 'EMJOB')

   • As a sysman user, execute DBMS_SCHEDULER.SET_ATTRIBUTE (name => ' EM_JOB_PURGE_POLICIES ', attribute => 'job_class', value => 'EMJOB')

   • As a sysman user, execute GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOBS_STEP_SCHED', 'EMJOB')

   • As a sysman user, run GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_JOB_PURGE_POLICIES', 'EMJOB')

   • INSERT INTO MGMT_PARAMETERS(parameter_name, parameter_value) VALUES ('EM_jobs_step_sched_job_class', 'EMJOB')

3. Set the connect string with ping service name to the emctl property

   oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor

   • Sample: emctl set property -name "company.sysman.core.jobs.conn.service" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=emjob\)\)\)"

Events and Notifications

If the vital sign has crossed the baseline threshold, look for vital signs in self-monitoring Managing the Manager pages. Monitor charts for consistent drastic increase in Metric alerts backlog, Metric Collection errors backlog, and Notification backlog. Key Metrics to check event backlogs are Total Events Pending and Total Events Processed (Last Hour). If Total Events Pending remains high but Total Events Processed (Last Hour) is making good progress, it could be a temporary spike which can be ignored, but if there is a consistent increase in both metrics, the Events subsystem will benefit by introducing a database service and setting affinity to only run on a single-instance RAC node.

Use these configuration steps for an Events database service:

1. Create a database service event and set one of the RAC instances as the primary instance in "-r"

   srvctl add service -d <dbname>-s event -r <primary instance> -a <the the other instances> -y automatic

2. Set the connect string with the 'ping' service name to the emctl property oracle.sysman.core.events.connectDescriptor

   Sample emctl set property -name "oracle.sysman.core.events.connectDescriptor" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=event\)\)\)"

Ping Alerts

Ping Alerts performance is crucial for determining target availability. If the vital signs have crossed a baseline threshold and there are many cluster waits in the AWR report, there is a measurable benefit by introducing a database service for Ping and setting affinity to run only on a single instance RAC node.

Use these configuration steps for defining a Pings database service:

1. Create database service ping and set one of RAC instance as primary instance in "-r"

   srvctl add service -d <dbname>-s ping -r <primary instance> -a <the the other instances> -y automatic

2. Execute the following DBMS_SCHEDULER jobs

   • As a sys user, execute DBMS_SCHEDULER.create_job_class( job_class_name => 'PING', service => 'ping')

   • GRANT EXECUTE ON sys.PING TO sysman;

   • As a sysman user, execute DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_PING_MARK_NODE_STATUS', attribute => 'job_class', value => 'PING')

   • As a sysman user, execute DBMS_SCHEDULER.SET_ATTRIBUTE ( name => 'EM_REPOS_SEV_EVAL', attribute => 'job_class', value => 'PING')

   • As a sysman user, execute GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_REPOS_SEV_EVAL', 'PING')

   • As a sysman user, execute GC_SCHED_JOB_REGISTRAR.SET_JOB_CLASS('EM_PING_MARK_NODE_STATUS', 'PING')

3. Set the connect string with ping service name to emctl property oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor

   Sample

   emctl set property -name oracle.sysman.core.omsAgentComm.ping.connectionService.connectDescriptor" -value "\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=ping\)\)\)

The default values of the settings on Small and Medium Enterprise Manager site sizes works fine. You might need to override the default values for Large and Extra Large configurations.

srvctl add service -d <dbname>-s loaderjob -r <primary instance> -a <the otherinstances> -y automatic

emctl set property -name "oracle.sysman.core.pbs.gcloader.connectDescriptor" -value 
"\(DESCRIPTION=\(ADDRESS_LIST=\(ADDRESS=\(PROTOCOL=TCP\)\(HOST=xxx.example.com\)\(PORT=1521\)\)\)\(CONNECT_DATA=\(SERVICE_NAME=loaderjob\)\)\)"

Large and Extra Large

emctl set property -name "oracle.sysman.core.pbs.gcloader.numThreads" -value 5

emctl set property -name "oracle.sysman.core.gcloader.loaderjob.maxConnections" -value 5

Monitoring the I/O throughput of the different channels in your Enterprise Manager deployment is essential to ensuring good performance. At minimum, there are three different I/O channels on which you should have a baseline and alert thresholds defined:

• Disk I/O from the Management Repository instance to its data files

• Network I/O between the OMS and Management Repository

• Oracle RAC interconnect (network) I/O (on Oracle RAC systems only)

You should understand the potential peak and sustained throughput I/O capabilities for each of these channels. Based on these and the baseline values you establish, you can derive reasonable thresholds for warning and critical alerts on them in Enteprise Manager. You will then be notified automatically if you approach these thresholds on your site. Some site administrators can be unaware or mistaken about what these I/O channels can handle on their sites. This can lead to Enterprise Manager saturating these channels, which in turn cripples performance on the site. In such an unfortunate situation, you would see that many vital signs would be impacted negatively.

To discover whether the Management Repository is involved, you can use Enterprise Manager to check the Database Performance page. On the Performance page for the Management Repository, click the wait graph showing the largest amount of time spent. From this you can continue to drill down into the actual SQL code or sessions that are waiting. This should help you to understand where the bottleneck is originating.

Another area to check is unexpected I/O load from non-Enterprise Manager sources like backups, another application, or a possible data-mining co-worker who engages in complex SQL queries, multiple Cartesian products, and so on.

Total Repository I/O trouble can be caused by two factors. The first is a lack of regular housekeeping. Some of the Enterprise Manager segments can be very badly fragmented causing a severe I/O drain. Second, there can be some poorly tuned SQL statements consuming much of the site I/O bandwidth. These two main contributors can cause most of the Enterprise Manager vital signs to plummet. In addition, the lax housekeeping can cause the Management Repository's allocated size to increase dramatically.

One important feature of which to take advantage is asynchronous I/O. Enabling asynchronous I/O can dramatically improve overall performance of the Enterprise Manager application. The Sun Solaris™ and Linux operating systems have this capability, but may be disabled by default. The Microsoft Windows™ operating system uses asynchronous I/O by default. Oracle strongly recommends enabling of this operating system feature on the Management Repository hosts and on Management Service hosts as well.

Automatic Storage Management (ASM) is recommended for Enterprise Manager repository database storage.

Determining the optimum number of middle tier OMS servers is not a trivial task. A number of data points must be considered for an informed, justified and acceptable decision for introducing additional OMS instances. The number of monitored targets is one of the first considerations, but its weight in decision making is normally not substantial.

The following items should be considered and examined as part of this exercise:

• The volume of job automation and scheduling used

• The number of administrators working simultaneously in the console

• Network bandwidth and data channel robustness from agents to the OMS servers

• Number of triggered violations and notifications

• Speed and stability of the IO system the OMS servers use

Careful investigation of each category is essential to making an informed decision. In some cases, just adding an OMS server or providing more CPU or memory to the same host may not make any difference in performance enhancement. You can use the current running OMS instances to collect accurate statistics on current OMS performance to calculate the number of required OMS servers for current or future deployments. Enterprise Manager has vital signs that reflect its health. These vital signs should be monitored for trends over time as well as against established baseline thresholds.