One of our OPMN engineers pointed out a blindingly obvious but very helpful usage pattern for opmnctl the other day. Which I’m dutifully passing on. Thanks Jon.
The opmn service/daemon is responsible for managing a process set within an OracleAS installation. At its simplest it starts/stops and actively monitors processes which make up an OracleAS instance.
As the notion of a cluster has evolved, the concept of a ‘scope’ has been introduced into opmnctl to extend the application of the command to a remote instance or the entire cluster, which I’ll loosely define as the collection of all known instances within the current OPMN topology.
The desired scope is applied as a prefix to the command :
Common Startup Pattern
A common use pattern is to issue the following command to start an OracleAS instace:
Which causes the OPMN daemon/service itself to start, which then further starts each of the managed processes such as OC4J, Oracle HTTP Server, etc.
Since this use of opmnctl implicitly starts the OPMN daemon/service, it can’t have a scope applied to it.
Refined Startup Pattern
The prior opmnctl use pattern is equivalent to the following operations:
So what, it’s more typing for the same thing, right?
Where it pays dividends is with the abilility to apply a scope command to the latter command, such as:
>opmnctl @cluster startproc
Or even perform commands on a specific remote instance:
>opmnctl @remote:j2ee_blue.duraace.au.oracle.com stopproc
So once you the OPMN daemon/service is running on each instance (which is a safe assumption in most cases) you can perform a significant set of operational commands across the entire cluster from one command line operation.
Getting used to treating OPMN as a fixed daemon/service provider and then using the scoped commands from opmnctl as a separate task can save you lots of time and effort, allowing you to use opmnctl command against whatever topology you can construct!