Differences between EM10g and EM11g

For those who have already played with EM11g, you will have noticed that there are quite a few differences in the OMS tech stack between 10g and 11g...

To give you all a quickstart on EM11g, here are the key differences you will see:

  • Stopping and starting the OMS and the Middle tier
    In 10g there was OPMN and the OMS. In 11g, you have WebLogic and the OMS. Stopping and starting these stacks has slightly changed...

    Stopping the entire tech stack:
    • In EM 10g: $ $ORACLE_HOME/opmn/bin/opmnctl stopall;
    • In EM 11g: $ emctl stop oms -all
    Starting the entire stack:
    • In EM 10g: $ $ORACLE_HOME/opmn/bin/opmnctl startall;
    • In EM 11g: $ emctl start oms

    Stopping and starting just the OMS is still the same command in both versions:
       $ emctl stop oms
       $ emctl start oms

    The key difference in EM11g is, that the EMCTL 'start' command will take care of the entire stack, and start whichever component needs to get started behind the scenes, without the need of another tool or command.

  • Setting OMS parameter
    If you ever had to tweak the loader threads, or increase job threads or something similar in EM 10g, this was always done by editing the editing the 'emoms.properties' file.
    In EM 11g, this file is no longer there: All OMS parameters are stored in the repository. And changing them, requires an EMCTL command to update the values in the repository (This also implies that you now need the SYSMAN password to make an update to the properties!).

    Setting or changing an OMS property:
    • In EM 10g: Editing of the file emoms.properties
    • In EM 11g: $ emctl set property -name <name> -value <value> -module emoms

    There is also a separate command to list out the properties an OMS has in EM 11g:
       $ emctl list properties

  • Setting OMS logging and tracing parameter
    And the same applied for setting logging and tracing parameters for the OMS. To change logging parameters:
    • In EM 10g: Editing of the file emomslogging.properties
    • In EM 11g: $ emctl set property -name <name> -value <value> -module logging

  • Location of the log and trace files
    Yes: Here is where it gets 'funky' in EM 11g: With the Weblogic stack and the separation of code (read: static) and runtime (read: dynamic) information, the location of the log files has substantially changed.

    The logic to use to find out what is where, is (once you know about it) pretty straightforward:
    • Look at the file emInstanceMapping.properties in the $ORACLE_HOME/sysman/config directory of the OMS.

      This file will tell you the internal ID (OMS name) of the OMS, and a pointer to the file with all the port and directory details used for this OMS.
      Example: EMGC_OMS1=/oracle/gc_inst/em/EMGC_OMS1/emgc.properties

    • Once you know the location of the instance specific files of the OMS, everything else will fall into place. Take note of three key properties in the file, which will help you find the log files:
      • EM_INSTANCE_HOME
      • EM_DOMAIN_HOME
      • EM_WEBTIER_INSTHOME

    The OMS application log files:
    • In EM 10g: Files are located in the $ORACLE_HOME/sysman/log directory of the OMS
    • In EM 11g: Files are located in the <EM_INSTANCE_HOME>/sysman/log directory.
      Example: /oracle/gc_inst/em/EMGC_OMS1/sysman/log
       
    The OMS JAVA application log files:
    • In EM 10g: Files are located in the $ORACLE_HOME/j2ee/j2ee/OC4J_EM/log/OC4J_EM_default_island_1 directory of the OMS
    • In EM 11g: Files are located in the <EM_DOMAIN_HOME>/servers/<OMS ID>/logs directory.
      Example: /oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs

    The Application stack log files:
    • In EM 10g: Files are located in the $ORACLE_HOME/opmn/logs directory of the OMS
    • In EM 11g: Files for the Admin server are located in the <GC_INST>/domains/GCDomain/servers/EMGC_ADMINSERVER/logs directory fo the 1st OMS (The one with the Adminserver).
      Example: /oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_ADMINSERVER/logs

      The NodeManager will write the log/trc files in the same location of the JAVA application log files: <EM_DOMAIN_HOME>/servers/<OMS ID>/logs (Example: /oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs) and also in <EM_DOMAIN_HOME>/servers/<OMS ID>/sysman/log (Example: /oracle/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/sysman/log

    The Apache (HTTP Server) log files:
    • In EM 10g: File are located in the $ORACLE_HOME/Apache/Apache/logs directory of the OMS
    • In EM 11g: Files are located in the <EM_WEBTIER_INSTHOME>/diagnostics/logs/OHS/ohs1 directory.
      Example: /oracle/gc_inst/WebTierIH1/diagnostics/logs/OHS/ohs1

  • No more SQL*Plus in the OMS ORACLE_HOME in EM 11g
    And this has two major consequences for administrators of the Grid Control and the OMS software:

    1. Patching will be different in EM11g. Instead of being able to launch SQL*Plus to run a post-install SQL file, you will now have to run RCU to run the SQL files (details will be in the patch README file)

    2. For those using EMDIAG, it will mean that EMDIAG can no longer be installed in the ORACLE_HOME of the OMS. With SQL*Plus gone, EMDIAG will no longer be able to run the SQL files to get the output (And just FYI: RCU does not do formatted SQL output - It just runs SQL commands).

      Recommendation is for EM11g to install and use EMDIAG on the repository machine, in the ORACLE_HOME of the repository database.

  • Increasing the JAVA heap size of the OMS
    For the larger sites, the standard out-of-box heap size of 512Mb might not be enough. Changing this requires a change in the configuration of the Application server:

    • In EM 10g: Edit the $ORACLE_HOME/opmn/conf/opmn.xml file, and change the -Xmx parameter to -Xmx1024M for the OC4J_EM application.
    • In EM 11g: Edit the startEMServer.sh file in the <EM_DOMAIN_HOME>/bin directory, and add these lines just before the last one in the file:

      if [ "${SERVER_NAME}" != "EMGC_ADMINSERVER" ] ; then
      USER_MEM_ARGS="-Xms256m -Xmx1024m -XX:MaxPermSize=512m -XX:CompileThreshold=8000 -XX:PermSize=128m"
      export USER_MEM_ARGS
      fi

Comments:

Werner, Excellent post. How about checking the status of the stack? In R5 and below, you could execute opmnctl status -l to see all the processes, ports, etc.. Now if you run the same command, you only get the OHS process status: $ opmnctl status -l Processes in Instance: instance1 ---------------------------------+--------------------+---------+----------+------------+----------+-----------+------ ias-component | process-type | pid | status | uid | memused | uptime | ports ---------------------------------+--------------------+---------+----------+------------+----------+-----------+------ ohs1 | OHS | 1864 | Alive | 40661380 | 365900 | 376:38:16 | http:4889,https:4900,https:9999,https:7799,http:7788 Is there a command line option to see the whole stack similar to what was there in the past? If not, I assume that is no longer necessary. Thanks.

Posted by Greg ory Grimes on September 02, 2010 at 01:27 AM PDT #

Werner, As a pre-cursor to this post, it might be beneficial to see a complete listing of new environment variables compared to old environment variables. Thanks.

Posted by Gregory Grimes on September 02, 2010 at 01:30 AM PDT #

Thanks for the comparison. I've been struggling with the new configuration/changes. I must say, these changes are frustrating! What has been gained by these "improvements"? # In EM 11g: $ emctl stop oms -all What was wrong with "opmnctl stopall" and why the "-all" on this command? Why not keep in step with 10g and use "stopall" ? # Location of the log and trace files The log files are all over the place and consume far too much space. For example, after ~30 days of uptime the mod_wl_ohs.log was over 4.5 gb!! I have yet to find a Metalink Note on how to trim the logging options down like I was able to do with EM 10g. # No more SQL*Plus in the OMS ORACLE_HOME in EM 11g Could someone explain why sqlplus was left out? This just seems like an oversight -- aka mistake. I made a mistake by upgrading to EM 11gR1. I wish I could take it back but I'd regret downgrading. I have 14 one-off patches on the 11.1 Agents and 28 on the EM 11g itself. It's ridiculous. There are still things that don't work. I have an open SR regarding the BEA-101020 errors that never end. Using "My Oracle Support" through EM 11g causes more harm than good. When I try to upload support files for an SR it'll fail more than 50% of the time. But when I login outside of EM 11g the uploads work fine. Heck, it wasn't until I applied a one-off patch that the Support Workbench would even work and several times my SR technicians have asked me to re-upload the zip without using EM because they're having problems accessing the file. "Skipped" jobs still show up as problem jobs. When you're looking at the Security Alerts you cannot see "All Targets" anymore. I always have 1 "DOWN" target because of poor quality control control in the WebLogic modules. I could go on for hours... just ask my local sales team ;-) Honestly, I spend more time babysitting this product than I do any of our production apps. It's extremely frustrating.

Posted by Richard on September 07, 2010 at 04:30 AM PDT #

Excellent! Great summary of admin differences! I've been looking for exactly this! A few more key examples of how to change the database connect string (especially where SCAN is concerned) and how to migrate to a new OMS would be great additions!

Posted by Courtney on September 09, 2010 at 04:45 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Latest information and perspectives on Oracle Enterprise Manager.

Related Blogs




Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
3
5
6
7
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today