Oracle Data Gatherer

[gjb]

Have got a Oracle Database running on Windows NT. I am using Server Manager to administer jobs on the database and server. I need to start the Oracle Data Gatherer to be able to run some events, but I can't start "OracleDataGatherer" service.

I have tried the following.

Start the service through the control panel

From the command line, net start "OracleDataGatherer"

From the command line, vppcntrl -start

No error message is returned, just says it can't start.

Thanks in advance

GJB

[sambavan]

Refer metalink: Note:69509.1


-Sam

[gjb]

No active support contract.

Can you be anymore specific in what might be the problem.

[sambavan]

Goal: To Explain the startup procedure of the OMS
Fact: Oracle Enterprise Manager 2.0.4
Fact: Oracle Enterprise Manager 2.1
Fact: Oracle Enterprise Manager 2.2
Fact: MS Windows NT

Fix: Starting the OMS on Windows NT:

During the installation of the Oracle Management Server (OMS) on NT, the
service which starts the Management server is set to manual.

There are some very good reasons to keep this service set to manual:

- The OMS needs to make a SQL*Net connection to the EM Repository
database during OMS startup. If either the database or listener
is not available, the OMS will fail to start correctly.

- During the installation the installer does not know if the
repository is on a local or remote database, and whether the
repository database will be available at all times for the
OMS to make connections.

- Even if the database, the listener, and the management server
are all local and started automatically when NT boots, there is
no guarantee that the services will start in the correct order,
therefore leaving the system in a questionable state. Services
are triggered asynchronously.

If all services and modules are installed on the same machine (the so called
'collapsed' mode), you have three major group of services on the machine:

1. The core services.
These are the database and the SQL*Net services, which should be started
and available before any other work can begin.

2. The agents: Back-End services.
This layer includes the Intelligent Agent, the Data Gatherer, and all
other services requiring direct interaction with the database, possibly
via SQL*Net.

3. The managers: middle tier services.
This is the group where things like Webservers/Application Servers, the
Management Server, etc., reside. These services require an interaction
with the database via SQL*Net. Sometimes even communication with the
end-tier sevices is necessary.

Note: For the OMS, communication with the Agent is a plus since then
the automatic discovery of the local services can take place!


The order of these services is strict, and must be respected at all times.


Bottom line:
------------
Without any manual intervention, or additional configuration the management
server service should not get changed to 'Automatic' on NT!


-----------------------------------------------------------------------------
When running in the collapsed mode: All on the same system
-----------------------------------------------------------------------------

There are however a few manual operation and modifications possible on a
system to allow the OMS to start up automatically.


1. The Quick and - perhaps not so - Dirty solution.

Just go with the flow: Create a command file, which starts all services
in the correct order.

Assuming the ORCL example, using the 'Default Home', the batch file will
look something like this:

StartEM.CMD:

NET START OracleServiceORCL *1
NET START OracleTNSListener *2
NET START OracleAgent *2
NET START OracleDataGatherer *2
NET START OracleManagementServer *2,3

Notes:
*1: Starting from 8.1.5, the OracleService both creates the Oracle
process and starts the database.
For all pre-8.1.5 databases, a second service call the OracleStart
service is need to start the database. In these versions, the
OracleService service only creates the Oracle process, while the
OracleStart service really opens the database.

If there is more than 1 database installed on the machine, start all
databases first, before continuing with other services.

*2: If the service is not installed in the DEFAULT_HOME, the name of the
$ORACLE_HOME will be in the NT service name.

*3: Enterprise Manager V2.0.4 is still based on 8.0.4. If the local
database is of another version, it is mandatory to install the
Enterprise Manager software in another $ORACLE_HOME.

This batch file can be used as a starting point. It can be enhanced by
adding some more tests and conditions to catch starting failures, error
conditions, etc.

Once this batch file is 'debugged' and 'operational', it can even be
specified in the startup commands of the registry to get this script to
start each time the NT machine boots.

Add the following registry variable:

HKEY_LOCAL_MACHINE
Software
Microsoft
Windows
CurrentVersion
Run
OracleStart REG_SZ C:\ORANT\BIN\StartEM.CMD

Advantages:
- You have full control on the services and the order in which these
services are started.
- Additional tests and conditions can be built into the script to act when
a service fails to start. This will provide a more flexible way to start
the services, and catch error conditions.

Disadvantages:
- Need to program the startup logic.
- Not a self-regulating solution. Add a service, or create a new database
and you'll need to modify the script.


2. Using 'DependOnService'.

To set a service dependancy on services, use the REGEDT32.EXE program.
Add the following key:

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
"The service"
DependOnService REG_MULTI_SZ "Dependant Service"

Using the default settings, with the ORCL database, you can specify the
following:

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services

OracleAgent
DependOnService REG_MULTI_SZ OracleStartORCL

OracleManagementServer
DependOnService REG_MULTI_SZ OracleAgent

Once you click on the OracleManagementServer service to start, all other
services defined as dependencies will automatically start also, in the
correct order.

Advantages:
- Using the standard NT functionality. Syncrhonization of the services is
handled by the NT implementation of the dependencies.
- Easy to implement.

Disadvantages:
- When a service fails to start, all services depending on that service
will also fail to start.
Although this might be a good thing for the repository database service,
services like the Data Gatherer and the listener could be a real problem.
This can lead to a situation where a service will not start, even though
there might be a way to get this service starting without the dependent
service.
- You can only depend on a single service. If several services need to
be started, this option is no longer possible. In the ORCL example, the
OracleTNSListener could be a potential problem, since this service is
referenced nowhere. A second problem is the DataGatherer, which is also
in the chain but is not a dependency of the OMS service.

3. Using 'DependOnGroup'.

Another NT feature is to group services together, and define dependencies
between these groups. This allows an administrator to define logical
entities of services which will all get started once a service depending
on the group is started.

To define groups, there are three modifications needed in the registry:
- Definition of the group. This is a multi-line registry variable, with
the list of all services in the group.
- Specify which services belong to which group.
- Set a group dependency for the service you wish to alter.

To set a group dependency on services, use the REGEDT32.EXE program.
Add the following keys and variables

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Control
GroupOrderList
"Group Name" REG_MULTI_SZ "All services in group"

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
"The service"
DependOnGroup REG_MULTI_SZ "Group Name"

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
"Dependant Service"
Group REG_SZ "Group Name"


Example:

Taking the information from the top of the document, we can now split up
the services in three groups:

OracleCore : All database services, and the SQL*Net listener
OracleTier3: The Agent and Data Gatherer
OracleTier2: The OMS

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Control
GroupOrderList
OracleCore REG_MULTI_SZ
"OracleServiceORCL OracleTNSListener" *1

OracleTier3 REG_MULTI_SZ
"OracleAgent OracleDataGatherer" *1

OracleTier2 REG_MULTI_SZ
"OracleManagementServer" *1

HKEY_LOCAL_MACHINE
System
CurrentControlSet
Services
OracleServiceORCL
Group REG_SZ OracleCore

OracleTNSListener
Group REG_SZ OracleCore

OracleAgent
Group REG_SZ OracleTier3
DependOnGroup REG_MULTI_SZ OracleCore

OracleDataGatherer
Group REG_SZ OracleTier3
DependOnGroup REG_MULTI_SZ OracleCore

OracleManagementServer
Group REG_SZ OracleTier2
DependOnGroup REG_MULTI_SZ OracleTier3

Notes:
*1: For a multi-line registry value, enter each value on a seperate
line. Only the REGEDT32.EXE program allows easy access to multi line
values.

Advantages:
- Using the standard NT functionality. Synchronization of the services is
handled by the NT implementation of the dependencies.
- You can define a clear hierarchy of services.

Disadvantages:
- Need some knowledge of the NT registry and of the already predefined
groups. Some of the device drivers - which are also considered
'services' as far as the OS kernel goes - are already grouped together.
- If one of the services in a group fails to start, the end-service will
not start. All services in a group must be up and running before you
can start the service in question.


-----------------------------------------------------------------------------
Running in a distributed way: On different machines
-----------------------------------------------------------------------------

When the Enterprise Manager software is installed on several systems, there
is no way to modify the services on NT to check the status of services on
another machine. Therefore, when running in this kind of configuration, the
only way to succesfully start the OMS is via a batch file, with the necessary
checks to test the SQL*Net connection and the availability of the repository
database.

Some tools, included in the NT resource kit, can perform some tests. Combine
this with the scripting power of either KIX32 or PERL, and you can write a
script which starts the OMS in a safe way.

Possible tools to use:

SC : Command line program to modify services on a machine in the network.
You'll need administrator privileges to modify a service on a remote
machine.

XNET : Same kind of functionality. This is a shareware tool which provides
a command line interface to work with services on remote machines.
Again, administrator privileges are needed to modify a service on
the remote machine.

PERL : Scripting tool delivered with the resource kit. Provides scripting
possibilities similar to TCL.

KIX32: Scripting language specific for system modifications on Windows 95
and Windows NT.

Example script, still using the ORCL and the default install example:

StartEM.CMD:

SC \\REMOTE_HOST START OracleServiceREPO *1
SC \\REMOTE_HOST START OracleTNSListener *2
SC \\REMOTE_HOST START OracleAgent *2
NET START OracleServiceORCL *3
NET START OracleAgent *2
NET START OracleDataGatherer *2
NET START OracleManagementServer *2,4

Notes:
*1: Starting from 8.1.5, the OracleService both creates the Oracle
process and starts the database.
For all pre-8.1.5 database, a second service call the OracleStart
service is need to start the database. In these versions, the
OracleService service only creates the Oracle process, while the
OracleStart service really opens the database.

If there is more than 1 database installed on the machine, start all
databases first, before continuing with other services.

*2: If the service is not installed in the DEFAULT_HOME, the name of the
$ORACLE_HOME will be in the NT service name.

*3: If there are local databases present on the machine you can also
start them prior to starting the agent and the OMS, to get the
discovery of the local machine properly done.

*4: Enterprise Manager V2.0.4 is still based on 8.0.4. If the local
database is of another version, it is mandatory to install the
Enterprise Manager software in another $ORACLE_HOME.

Like in the local example, this script can then be put in the registry, once
completely debugged, to start the whole environment automatically.

Advantages:
- You have full control on the services and the order in which these
services are started.
- Additional tests and conditions can be built into the script to act when
a service fails to start. This will provide a more flexible way to start
the services and catch error conditions.
- Centralized administration: Only one machine with a startup script,
making it easier to maintain and adminster the environment.

Disadvantages:
- In the distributed model, you need to have access to the other server
in order to start services on the remote machine. This will introduce
additional dangers, like network problems, adminitrator and user
privileges, security issues, etc.
- Need to program the startup logic.
- Not a self-regulating solution. Add a service, or create a new database,
and you'll need to modify the script.


-----------------------------------------------------------------------------
Conclusions
-----------------------------------------------------------------------------

All of the above mentioned workarounds can be solutions for getting the OMS
started automatically. Do however realize the limitations of each of the
solutions and implement them properly, and - more importantly - use them
properly.