Grid Control 11 Known Issues, Bugs and Features.

Background & Overview

Given that Grid Control 11g is relatively new, I thought it might be useful to have a Known Issues section which appeared outside of the main install and configuration guides. Furthermore, there are a couple of issues that do not naturally fit into any of the guides and therefore, deserve a known issues section in their own right and indeed are not problems with Grid Control per se, but more to do with browser features.

Assumptions & Pre-Requisites

This document expects and assumes the following:

  • The instructions are carried out by a qualified DBA/Grid Control Administrator

Problems Configuring Grid 11g Agent against an 11g ASM Instance.

When configuring the Grid Control monitoring credentials for 11g ASM using SYSASM role the connection test fails with "DiskGroup_Usage - ORA-24300: bad value for mode".

When an attempt to use the SYSDBA role is made ORA-1031 is returned.


For 11gR2 ASM

1. Create the password file for ASM on all nodes using the following command

  • orapwd file=$GRID_INFRASTRUCTURE_HOME/dbs/orapw+ASM password=<password> entries=5

2. Update the password file with the following users and roles

  • sqlplus / as sysasm
  • SQL> create user asmsnmp identified by
  • SQL> grant sysasm to sys;
  • SQL> grant sysdba to asmsnmp;

3. Review the changes to the password

  • SQL> select * from v$pwfile_users;

4. Within Grid Control configure the agent monitoring credentials to connect to the ASM instance as asmsnmp with the role of SYSDBA

For 11gR1 ASM

1. Create the password file for ASM on all nodes using the following command

  • orapwd file=$GRID_INFRASTRUCTURE_HOME/dbs/orapw+ASM password=<password> entries=5

2. Update the password file with the following users and roles

  • sqlplus / as sysasm
  • SQL> grant sysasm to sys;

3. Review the changes to the password

  • SQL> select * from v$pwfile_users;

4. Within Grid Control configure the agent monitoring credentials to connect to the ASM instance as sys with the role of SYSDBA


The SYSASM role is not the recommended configuration from a security and privilege perspective for monitoring due to its super user types of privileges.

For more information see Metalink note 977472.1

Policy Violation Reported Various Oracle Database Files.

The Oracle Grid Control Agent reports a critical policy violation on the following database files


According to the Grid Control Agent these files have the wrong file ownership. Grid expects oracle, the files actually have root ownership.

This is a bug in the Grid Control Agent. These files are changed to root ownership by the script run at the end of the database install procedure. This bug is currently being fixed under an enhancement request 9814302


To work around this policy violation, the DBA can disable this policy. However, please note that disabling this policy will turn off ALL checking of file ownership for all files in the $ORACLE_HONE/bin directory. A more appropriate action for the DBA to take would be to suppress the violation. This will effectively remove this component from the default policy violation views and therefore, not distract DBAs monitoring genuine policy violations.

1. From the targets home page within grid control, select databases
2. Click on the critical policy violations link.
3. In the Evaluations Results column click the on the violations link.
4. Click the tick boxes next to the violations you wish to suppress.
5. Click the Suppress Violation button.
6. Ensure radio button Remove Suppression is specified is selected.
7. Add a suitable comment in the Add Comments box.
8. Click Ok

FMW Welcome Page Application( Down

A clean and default install of Grid Control reports that the FMW Welcome Page Application( application is down.


If you remove this target from Grid Control it is automatically rediscovered.

Oracle Note 1100553.1 states that this issue can be ignored and is filed as a bug with Oracle development. However, it is considered a low priority bug and may not be fixed for some time.


At the time of writing this, Oracle have published the following advice under note: 1100553.1

1. The Down status is harmless. It has NO impact on other components.
2. The Welcome Page Application is a demo application.
3. Some users may find the Down status useful, in comparing with other FMW components that one knows to be Up.
4. For the reasons above, this is a low priority issue, and may not receive an immediate fix.


There is now a patch for this bug. Patch No: 9431704

To apply this patch, follow the insturctions in the README file paying particular notice to the points below.

  • Download the latest opatch utility from Metalink.
  • When installing patch 9431704 the oracle home referred to in the README file is /u01/app/middleware/oracle_common
  • Opatch may report an error opatch -d64 not found, in which case you need to update the opatch script as follows
    • In the opatch script change JRE_MEMORY_OPTIONS=${MEM_ARGS} ${JVM_D64} to JRE_MEMORY_OPTIONS="${MEM_ARGS} ${JVM_D64}". i.e. Put double quotes around the variables.
    • See Metalink note: 1082141.1 for more details.

How to Stop and Start Grid Control 11.

In the advanced install guide for Grid Control 11 (e16847-02, section 7.6.1 steps 3 and 5) it states to start the weblogic server you should run the script and to start iasconsole run emctl start iasconsole.

The manual also talks about starting and stopping the WebCache using the following command OMS_HOME/opmn/bin/opmnctl stopproc ias-component=WebCache However, when talking about stopping and starting all components on one server the WebCache is not mentioned.

Finally, in the manual at section 7.6.1, it states that the following commands are to be run when starting GC11

  • DB_HOME/bin/lsnrctl start
  • Using SQLPLUS start DB
  • OMS_HOME/bin/emctl start oms
  • MIDDLEWARE_BASE/gc_inst/user_projects/domians/EMGC_DOMAIN/
  • AGENT_HOME/bin/emctl start agent
  • IAS_HOME/bin/emctl start iasconsole

And for shutting down Grid (Section 7.6.2) the manual says to use the following commands

  • OMS_HOME/bin/emctl stop oms
  • IAS_HOME/bin/emctl stop iasconsole
  • MIDDLEWARE_BASE/gc_inst/user_projects/domians/EMGC_DOMAIN/
  • AGENT_HOME/bin/emctl stop agent
  • Using SQLPLUS stop DB
  • DB_HOME/bin/lsnrctl stop

Clearly, there are some errors and inconsistencies in the current batch of manuals. The proper way to stop and start Grid Control 11g when all components reside on a single node is detailed below and has been confirmed with Oracle Support via an SR.



. oraenv
lsnrctl start
sqlplus '/ as sysdba' «EOF
cd /u01/app/middleware/oms11g/bin
./emctl start oms
cd /u01/app/middleware/agent11g/bin
./emctl start agent


cd /u01/app/middleware/agent11g/bin
./emctl stop agent
cd /u01/app/middleware/oms11g/bin
./emctl stop oms -all
. oraenv
lsnrctl stop
sqlplus '/ as sysdba' «EOF
shutdown immediate


  • There is no need to run the WebLogic script, nor to stop/start the WebCache or iAS. This is all done via the emctl start/stop oms command.
  • Ensure the -all flag is specified on when stopping the OMS. Failure to specify this flag will leave the following Oracle processes running.

/usr/java/jdk1.6.0_18/jre/bin/java -classpath /usr/java/jdk1.6.0_18/jre/lib/rt.jar:/usr/java/jdk1.6.0_18/jre/
/bin/sh /u01/app/gc_inst/user_projects/domains/GCDomain/bin/
/bin/sh /u01/app/gc_inst/user_projects/domains/GCDomain/bin/
/usr/java/jdk1.6.0_18/bin/java -client -Xms256m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxP

Using FireFox with Grid Control 11.

This is an interesting feature that came to light with the FireFox browser which I thought was worth a mention.

Having installed Grid Control 11, I was puzzled why every time I connected to Grid Control I was forced to add a certificate exception to FireFox. My first thought, not being overly familiar with SSL, was that there was something wrong with the certificate issued by Grid Control and spent some time investigating how Grid Control managed SSL certificates.

However, just by chance I used a different PC with the same version of Firefox to test something on GC11 and found that I was not asked to accept the cert.

So what was the difference? Well on my PC the browser history is not saved, whereas on the other PC it is. As a consequent of this, the certificate is not accepted as permanent and is instead accepted as temporary.

The problem with certificates being accepted as temporary is that temporary certs do not persist across browser sessions. Therefore, every time I closed the browser I lost the cert and had to accept it every time I connected to Grid Control.

Turning on my browser history fixed the issue and allowed the cert to be imported as permanent.

Obvious in retrospect I suppose, except interestingly, if you then turn off the browser history and delete all of the history, the certificate does not get deleted or changed to temporary. Therefore, you can have browser history turned off and indeed completely empty, just so long as you start with it turned on!!


1. For the first time you access the GC frontend, ensure your history is enabled as this will ensure the cert is accepted as permanent.

2. Subsequent browser sessions can be performed with history disabled and indeed all of your history deleted.

3. If you ever manually delete the certificate (Not sure why you would do this), you will need to re-enable the history for the first visit.

So ultimately, deleting history does not delete certificates, but having history turned off stops certificates being stored as permanent. Whether this is expected behaviour or not I have no idea, but it is worth bearing in mind if you use FireFox.

Using Internet Explorer v8 with Grid Control 11.

When clicking on the Login button for Grid Control 11g using Internet Explorer v8 a yellow triangle appears in the bottom left hand corner of the browser reporting an Error on page

Double clicking on the yellow triangle reports a message similar to the following

Message: Element not found.

Line: 2815
Char: 1
Code: 0


The reason is that window.external is not a valid method for a window object. This problem may happen if you've registered the module shdocvw.dll after Internet Explorer v8 was installed. This is just another side-effect caused by the registration of shdocvw.dll in a system running Internet Explorer v8.

See metalink note: 1153436.1
(opens in a new window)


  1. Click Start —> Run and type regedit
  2. Backup the registry
  3. Navigate to the following location HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win32
  4. Double-click default and set the data value to C:\WINDOWS\system32\ieframe.dll
  5. Quit Registry Editor
  6. Restart the brwser

Error Messages in the Agent11g Logs

Independent Products at N/A not Readable

The following message is written to the emagentfetchlet.trc

2010-04-30 09:51:28,137 [main] WARN track.OracleInventory mineHomeInventory.2320 - 
ECM: Oracle Home : Independent Products at N/A is not readable, please check permissions ..


This message can be ignored. Alternatively, the following directories can be created in the AGENT_HOME directory.

mkdir -p $AGENT_HOME/sysman/emd/N/A

Error Message in EMGC_OMS1.out Log

The following error is written to logfile /u01/app/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out

java.lang.IllegalArgumentException: Service already exists: oracle.sysman.emSDK.chart.EmChartCacheManager
at oracle.sysman.emSDK.svc.EMServiceUtil.setEMService(
at oracle.sysman.emSDK.svc.ServiceUtil.setService(
at oracle.sysman.emSDK.svc.ServiceUtil.initService(
at weblogic.servlet.internal.EventsManager$
at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(
at weblogic.servlet.internal.WebAppServletContext.preloadResources(
at weblogic.servlet.internal.WebAppServletContext.start(
at weblogic.servlet.internal.WebAppModule.startContexts(
at weblogic.servlet.internal.WebAppModule.start(
at weblogic.application.internal.flow.ModuleStateDriver$
at weblogic.application.utils.StateMachineDriver.nextState(
at weblogic.application.internal.flow.ModuleStateDriver.start(
at weblogic.application.internal.flow.ScopedModuleDriver.start(
at weblogic.application.internal.flow.ModuleListenerInvoker.start(
at weblogic.application.internal.flow.ModuleStateDriver$
at weblogic.application.utils.StateMachineDriver.nextState(
at weblogic.application.internal.flow.ModuleStateDriver.start(
at weblogic.application.internal.flow.StartModulesFlow.activate(
at weblogic.application.internal.BaseDeployment$
at weblogic.application.utils.StateMachineDriver.nextState(
at weblogic.application.internal.BaseDeployment.activate(
at weblogic.application.internal.EarDeployment.activate(
at weblogic.application.internal.DeploymentStateChecker.activate(
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(
at weblogic.t3.srvr.


This is due to the service EMChartCacheManager being initiated twice. Once by oracle.sysman.emSDK.topo.TopoUtil and again by


This error can be ignored.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License