How the Oracle Management Pack works: architecture, network and security
How the Opslogix Oracle Management Pack collects its data, what it needs on your network, and how it handles security and high availability.
Applies to: Opslogix Oracle Management Pack (all versions)
Last updated: October 2026 · Latest version: 26.4.4517.0
See also: Upgrade guide for 26.4.4517.0 · Version support · Release notes
Components
- Management packs in SCOM: discoveries, monitors, rules, views, dashboards and reports.
- A SCOM resource pool with one or more management servers or gateway servers. Each Oracle instance is assigned to a resource pool when you add it.
- The Opslogix Oracle Collector, a Windows service that runs on every member of the resource pool. It is deployed automatically by the management pack (during the first Test Connection) and includes Oracle's managed .NET driver (ODP.NET). You don't need to install an Oracle client.
Nothing is installed on the Oracle servers. No SCOM agent is needed on the Oracle servers either.
How the data flows
- SCOM runs the Oracle monitoring workflows on the resource pool member that manages the instance.
- The workflows ask the Opslogix Oracle Collector on that same server for the data.
- The collector connects to the Oracle instance through the Oracle listener and runs read-only queries on Oracle's dynamic performance (v$/gv$) and dictionary (dba_) views.
- The results come back to SCOM as health states, alerts and performance data.
The collector keeps a pool of database connections and shares results between workflows (cook-down), so the load on the Oracle database and on SCOM stays low.
Network requirements
- From each resource pool member to each Oracle server: the Oracle listener port, by default TCP 1521. You set the port per instance when you add it.
- The communication between the SCOM workflows and the collector stays on the same server.
High availability
Because each Oracle instance is managed by a SCOM resource pool, monitoring continues when a pool member is unavailable: another member of the pool takes over. Add two or more members to the resource pool for failover and to spread the load.
Security
- The monitoring account only needs read access. You can restrict it to a fixed list of Oracle views; see KB: How to create the monitoring account for the Oracle monitoring. Data Guard monitoring requires the SYSDBA or SYSDG role.
- Passwords in the connection settings are encrypted.
- The monitoring sessions identify themselves in v$session with the module name OPSLOGIX.IMP.ORACLE, so your DBA can recognise them.