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.
Fix
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
NOTES
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
/u01/app/oracle/product/11.2.0/dbhome_1/bin/nmhs
/u01/app/oracle/product/11.2.0/dbhome_1/bin/jssu
/u01/app/oracle/product/11.2.0/dbhome_1/bin/oradism
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 root.sh script run at the end of the database install procedure. This bug is currently being fixed under an enhancement request 9814302
Fix
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(11.1.0.0.) Down
A clean and default install of Grid Control reports that the FMW Welcome Page Application(11.1.0.0.) 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.
Fix
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.
UPDATE
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 StartWebLogic.sh 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/startWebLogic.sh
- 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/startWebLogic.sh
- 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.
Fix
startGC.ksh
export ORACLE_SID=MYSID
export ORAENV_ASK=NO
. oraenv
lsnrctl start
sqlplus '/ as sysdba' «EOF
startup
EOF
cd /u01/app/middleware/oms11g/bin
./emctl start oms
cd /u01/app/middleware/agent11g/bin
./emctl start agent
stopGC.ksh
cd /u01/app/middleware/agent11g/bin
./emctl stop agent
cd /u01/app/middleware/oms11g/bin
./emctl stop oms -all
export ORACLE_SID=MYSID
export ORAENV_ASK=NO
. oraenv
lsnrctl stop
sqlplus '/ as sysdba' «EOF
shutdown immediate
EOF
NOTES
- 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/startEMServer.sh
/bin/sh /u01/app/gc_inst/user_projects/domains/GCDomain/bin/startWebLogic.sh
/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!!
Fix
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
URI: https://myhost.com:5508/em/cabo/jsLibs/Common2_2_24_5.js
Cause
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)
Fix
- Click Start —> Run and type regedit
- Backup the registry
- Navigate to the following location HKEY_CLASSES_ROOT\TypeLib\{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}\1.1\0\win32
- Double-click default and set the data value to C:\WINDOWS\system32\ieframe.dll
- Quit Registry Editor
- 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 ..
Fix
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(EMServiceUtil.java:101)
at oracle.sysman.emSDK.svc.ServiceUtil.setService(ServiceUtil.java:115)
at oracle.sysman.emSDK.svc.ServiceUtil.initService(ServiceUtil.java:95)
at oracle.sysman.eml.app.ContextInitializer.init(ContextInitializer.java:597)
at oracle.sysman.eml.app.ContextInitializer.contextInitialized(ContextInitializer.java:348)
at weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:481)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.EventsManager.notifyContextCreatedEvent(EventsManager.java:181)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1801)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3045)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1397)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:460)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:1267)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:83)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:409)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:54)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:184)
at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:361)
at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51)
at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:196)
at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30)
at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:233)
at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169)
at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123)
at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:173)
at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:89)
at weblogic.t3.srvr.
Cause
This is due to the service EMChartCacheManager being initiated twice. Once by oracle.sysman.emSDK.topo.TopoUtil and again by oracle.sysman.eml.app.ContextInitializer
Fix
This error can be ignored.
