Grid Control: number of active connections is….

Just for my collection of Grid Control messages, bugs and what so ever – for my effort (between my normal business) to get the ‘pie’ completely green and as few ‘critical’ errors as possible, which is sometimes a very depressive task:

After installing and configuring application server, the agent on that server started to sent messages like ‘The number of active connections is ..’  and a high number, too high for the metric.  But.. there are no connections yet on the system (as far as I know)!  Grid Control (OMS + agent) = 10.2.05, application server



1. “Change the value of the parameter KeepAlive to ‘Off’ in httpd.conf” —>  (nice! and what if this is not to be recommended for the application..).
2. “Restart all components using opmnctl stopall and then opmnctl startall” —> I tried to just stop and start the http-server and the agent, but that didn’t work.
3. “Check the current value of the active connections metric using the metric browser.” —>

What the heck is a metric browser, and how to use this…

Just try it out:

a. vi <AGENT_HOME>/sysman/config/  (make a backup in advance..)

b. uncomment the following line:


c. reload the agent through:

<AGENT_HOME>/bin/emctl reload agent

d. check the metric browser:




By | September 23rd, 2009|Categories: grid control|Tags: |2 Comments

VM-time out of sync, runs too fast with guest-O.S. Suse Linux 9 / 10

Grid Control is calling  >> “Difference between OMS system time and Agent system time is 121 mins and has exceeded the critical threshold 120 mins”

The system time runs too fast on a (Suse) Linux-based (kernel 2.6) virtual machine, while the ntp has been configured. There are a lot of documents regarding this kind of issues. For explanation and understanding a few documents we used: (Microsoft? seems to work for VM-ware too…) (time not syncing with ntp-server)

Next option for me when all above should not be working, but didn’t have to use it:

Solution we implemented, seemed to work:
– add the clock=pit parameter to the kernel entry (for explanation, see below)
– in addition add the option ‘burst iburst‘ to the ntp-configuration.

To see by the way how the ntp is working:
# watch ntpq -p

Clock=pit for the GRUB bootloader
In the guest operating system, open the /boot/grub/menu.lst file by using a text editor such as Vi. For example, type the following command from a console, and then press ENTER:
vi /boot/grub/menu.lst
This file contains the Linux boot options and resembles the following:
title Linux
kernel (hd0,4)/vmlinuz root=/dev/hda7 vga=791
initrd (hd0,4)/initrd
title windows
In the title Linux area of this file, add the clock=pit parameter to the kernel entry. This area should resemble the following:
title Linux
kernel (hd0,4)/vmlinuz root=/dev/hda7 vga=791 clock=pit
initrd (hd0,4)/initrd
Save the changes to the file, exit Vi, and then restart the Linux-based virtual machine.


By | September 9th, 2009|Categories: grid control|Tags: , |0 Comments

Discoverer shows down in Grid Control while up.

Short one this time, all in favour of getting my green ‘pie’ in Grid Control management server.

Grid Control: Discoverer: 10.1.2.x
In Grid Control, after upgrade to, a Discoverer target shows down in the list, while it’s functioning quite well.

It seemed an old bug (Grid Ctrl 10.1.04) is still not fixed:
– Note: 332363.1


1- Remove the Application Server target which owns the Discoverer component (10.1.2) in the Grid Control

2- Stop the agent

3- Backup the file %CENTRAL_AGENT_ORACLE_HOME%/sysman/admin/metadata/oracle_discoverer.xml file.

Replace this file by:

%BI_ORACLE_HOME%/sysman/admin/metadata/oracle_discoverer.xml file

BI_ORACLE_HOME corresponds to the Oracle_Home where Discoverer 10.1.2 is installed.

4- Restart the agent

5- Rediscover the Application Server target on the host, by typing (Agent-environment)  ‘agentca -d’.

By | September 9th, 2009|Categories: grid control|Tags: , |2 Comments

Object ODS.OID_RESPONSE_ARRAY_TYPE does not exist, Grid Control

After installing Oracle Application Server, with corresponding OID,  Grid Control gave me the obove mentioned error, and the the item OID a ‘metric collection error’.

To fix the metric collection error downloaded and applied Patch 5686191 on top of OID product.This is a sql-script to run against the OID-repository. Unpublished bug according to note 764088.1

Shutdown the DAS:

~/media/5686191> opmnctl stopproc process-type=OC4J_SECURITY

~/media/5686191> /software/oracle/product/10.2/infra/OPatch/opatch apply

Oracle Interim Patch Installer version
Copyright (c) 2005 Oracle Corporation. All Rights Reserved..

We recommend you refer to the OPatch documentation under
OPatch/docs for usage reference. We also recommend using
the latest OPatch version. For the latest OPatch version
and other support related issues, please refer to document
293369.1 which is viewable from

Oracle Home = /software/oracle/product/10.2/infra
Location of Oracle Universal Installer components = /software/oracle/product/10.2/infra/oui
Location of OraInstaller.jar  = “/software/oracle/product/10.2/infra/oui/jlib”
Oracle Universal Installer shared library = /software/oracle/product/10.2/infra/oui/lib/linux/
Location of Oracle Inventory Pointer = /etc/oraInst.loc
Location of Oracle Inventory = /software/oracle/product/10.2/infra/inventory
Path to Java = /software/oracle/product/10.2/infra/jre/1.4.2/bin/java
Log file = /software/oracle/product/10.2/infra/.patch_storage/<patch ID>/*.log

Backing up comps.xml …

OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.


By | August 31st, 2009|Categories: grid control|Tags: , |1 Comment

Status application server down in Grid Control, while all components are up.

Platform:  application server on Suse Linux 9. Grid Control agent 10.2.04.

All components within the application server are up, but the home page of Grid Control showing it down.

Underlying cause: bug in discovering ports by the agent.  Agent discovering process gets Forms url Port from < HOME_IAS>/10.1.2/forms/server/target2add.xml. But this port is not the expected port.

Two actions:

I – changed port in targets.xml in agent-home.

1. Check what is the real port for Forms application url (e.g. 7779 in stead of 7778, you can see this in the home-page of the middle-tier in Grid Control), this is  the Oracle HTTP Server Listen port, take the portlist.ini (if you are sure nothing has changed), or in httpd.conf, or through the Grid Control, search for ports in the http-section.

2. Edit <GRID_AGENT_HOME>/sysman/emd/targets.xml

For Target TYPE=”oracle_forms”  change the port in parameter :  Property NAME=”ServletUrl” — In my case from 7778 to 7779.

3. Restart the agent then check if Forms status change in grid control.

II – Changed port in targets.xml in midtier.

1. Navigate to “$ORACLE_HOME /sysman/emd” and open the “targets.xml” file.

2. Find the line reffering to the “ServletUrl” property. It should look like this:
<Property NAME=”ServletUrl” VALUE=”http://<HOST>:<PORT>/forms/lservlet”/>

3. In the above line replace the PORT with the Oracle HTTP Server Listen port).

5. Save and close the targets.xml

6. Run the following command: “opmnctl reload”

7. Run the following command “opmnctl restartproc process-type=HTTP_Server” – or restart through the Enterprise Manager.

8. Test a couple of times the status of the “Forms” component in Enterprise Manager by refreshing the data (In the EM page on the upper right)

But remember: actions like ‘agent -ca’ (rediscovering) may cause this to do the actions above again…

757363.1 : Forms Target Status Shows as Down Although It is UP.
469577.1 : Forms Looks Always Stopped From Oracle Enterprise Manager

By | April 21st, 2009|Categories: grid control|Tags: , |2 Comments