Upgrading Grid OMS and Agent from 10.2.0.1 to Oracle Enterprise Manager 10g Release 5

In order to test the SCOM connector I upgraded my oracle Grid Control infrastructure to 10.2.0.5 from 10.2.0.1

At the beginning it was not clear to me which software had to be installed, as the download, for example, for Linux x86 offered two hefty files gc_10205_part1of2.zip [(1,138,311,452 bytes)] and gc_10205_part2of2.zip [(1,137,845,265 bytes)].

Having carefully read the readme.html that comes with the binaries, I concluded that I only had to apply the patch 3731593

The readme listed a few checks that had to be performed. I have noted out a couple of them that might not be completely obvious.

A. Minimum size for shared pool 512 MB.
SQL> show parameter shared
NAME                                             VALUE
------------------------------------ ----------- -------------------------
__shared_pool_size                   big integer 136M
...
shared_pool_size                     big integer 0
shared_server_sessions               integer
SQL> alter system set shared_pool_size=512M scope=both;
alter system set shared_pool_size=512M scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-04033: Insufficient memory to grow pool

SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 512M
sga_target                           big integer 512M
SQL> alter system set sga_max_size=1024M scope=spfile;

SQL> shutdown immediate
startup


SQL> alter system set shared_pool_size=512M scope=both;
alter system set shared_pool_size=512M scope=both
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-04033: Insufficient memory to grow pool
SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 1G
sga_target                           big integer 512M
SQL> alter system set sga_target=800M;
System altered.


SQL>alter system set shared_pool_size=512M scope=both;
System altered.

B. Make sure that the Partitioning option is enabled in the Database housing the Grid control repository (Sysman schema)

Connected to the Database as sysdba and run the following query to see if the Partioning Option is installed:
SQL> select value from v$option where parameter = ‘Partitioning’;

Should give VALUE=TRUE.
SQL> select parameter, value from v$option order by 1;

PARAMETER  VALUE
----------------------------------------------------------------
... ... ...
Parallel execution                  TRUE
Parallel load                       TRUE
Partitioning                        TRUE
... ... ...
C. Both the DBSNMP and SYSMAN users require the EXECUTE privilege on the DBMS_RANDOM package in the Repository Database.

You must grant the privilege to both users as follows:

a. Log into the Repository Database as SYSDBA.
b. Run the following SQL:
SQL> grant execute on dbms_random to dbsnmp;
SQL> grant execute on dbms_random to sysman;
SQL> select object_name, object_type, owner from dba_objects where status='INVALID';

no rows selected
D.If the repository database is configured with the UTF8 character set, the value of the NLS_LENGTH_SEMANTICS needs to be set to BYTE.

To check this in the database:
SQL> SELECT value FROM nls_database_parameters
     WHERE parameter='NLS_LENGTH_SEMANTICS';

VALUE
--------------------
BYTE
If the value is not set to 'BYTE', change it by running this command: SQL> ALTER SYSTEM SET NLS_LENGTH_SEMANTICS=BYTE SCOPE=both;

D2.If the database housing the Grid control repository is linked with a Data Guard database, before the upgrade starts, the database has to be forced in logging mode, to force all index maintenance commands to be propagated to the standby database. The upgrade by default will perform the index maintenance commands in a 'NOLOGGING' mode. This means that any Data Guard database linked to the repository database will not have these index operations replicated to it. To make sure these commands get replicated to the Data Guard instance,force the database into logging mode: SQL> CONNECT / AS SYSDBA; SQL> ALTER DATABASE FORCE LOGGING;

Once the OMS upgrade is successful then revert the Data Guard force logging changes:

SQL> CONNECT / AS SYSDBA;

SQL> ALTER DATABASE NO FORCE LOGGING;


E. Execute and stop database jobs.

SQL> connect sysman
SQL> exec emd_maintenance.analyze_emd_schema('SYSMAN');
SQL> execute emd_maintenance.remove_em_dbms_jobs;
15.Make sure DBMS JOBS and DBMS Scheduler (for version 10.1+ RDBMS) in the Enterprise Manager Grid Control Repository are turned off during the Enterprise Manager schema upgrade process. To perform this task, follow these steps:

a.Log into the repository as SYSMAN.
b.For each instance, perform the tasks below:

1. Write down the values of job_queue_processes for each of the instances after you run the following command:

select a.instance_name as sid, b.value as jobqueue from gv$instance a, gv$parameter b where a.inst_id = b.inst_id and b.name='job_queue_processes';
SID        JOBQUEUE
-------    --------
REP10G     10
2. Turn off DBMS JOBS by running the following command: SQL> alter system set job_queue_processes=0 sid='*';

System altered.

Be sure there were no active jobs running by waiting until the following query returns 0:

SQL> select sid, job from dba_jobs_running;

no rows selected

3. Turn off the DBMS Scheduler by running (for version 10.1+ RDBMS) the following command:

SQL> exec dbms_scheduler.set_scheduler_attribute ('SCHEDULER_DISABLED','TRUE');

Be sure there were no active schedules running by waiting until the following query returns 0 (for version 10.1+ RDBMS):

SQL> select count(*) from dba_scheduler_running_jobs where SLAVE_PROCESS_ID IS NOT NULL;
COUNT(*)
----------
0


After the upgrade is completed, turn on DBMS JOBS and DBMS Scheduler (for version 10.1+ RDBMS) for each instance by performing the following steps:

Upgrading The Oracle Management Service And Repository

While applying the OMS patch set, leave the repository database and listener instance running.

Note: This Patch set will upgrade only the Grid Control repository (sysman schema) and not the database, which contains the Grid Control repository.

Be sure that you first upgrade the Oracle Management Service (OMS), and then the Management Agent before upgrading the database that contains the Grid Control repository.

To download and extract the Patch Set:

The steps to be taken before upgrading the first OMS are:

In my case, I have one server with one OMS and a few agents on other nodes.

  • $ORACLE_HOME/bin/emctl stop oms
  • $ORACLE_HOME/bin/emctl stop iasconsole
  • $ORACLE_HOME/opmn/bin/opmnctl stopall



    As we are going to upgrade the OMS, the ORACLE_HOME for the OMS has to be selected. In our case there are three ORACLE_HOMEs, one for the OMS, one for the agent and one for the database.



    At this point we are reminded that the database and its listener must be running, as the SYSMAN repository will be modified by the installer.

    asking for SYS password

    The following question is about the Oracle Application Server and it requires the ias_admin's password.

    installing the OAS

    The middle tier won't be available during the upgrade

    Warning: shutting down the middle tier

    The summary will show what the installer is about to do.

    OMS installation summary

    As usual, the GUI will first install and link the binaries and afterwards configure the components.

    installing the binaries

    configuration assistants for the OMS

    The repository upgrade took a long time to complete

    For reason that are not obvious, the OMS Patch Configuration failed the first time; I retried the operation and the second time it completed.



    Rather strangely ... the upgrade was carried out without any particular problem, except that the "OMS Patch Configuration" had to be repeated.

    Upgrading Management Agent

    The Management Agent can be upgraded in two ways - either one host at a time using Oracle Universal Installer, or many hosts at a time using Patch Wizard from Grid Control.

    Upgrading Management Agent - One Host At A Time

    To upgrade Management Agents, one host at a time, using OUI, follow these steps:

    1.Login to the specific host where the Management Agent is running.

    2.Change directory to the Oracle home directory for the Management Agent and stop the Management Agent. For cluster Agent, stop the Agent on all cluster nodes.

    $ORACLE_HOME/bin/emctl stop agent

    3. Ensure that $ORACLE_HOME is set to the Oracle home directory of the Management Agent that is intended for patching.

    4. Extract the software as per section 4.1 and then run the ./runInstaller executable from the 3731593/Disk1 subdirectory. (For Microsoft Windows, run setup.exe) and proceed with the upgrade.
    $ pwd
    /grid/transfer/3731593/Disk1
    $ 10ag
    $ emctl stop agent
    Oracle Enterprise Manager 10g Release 10.2.0.1.0.
    Copyright (c) 1996, 2005 Oracle Corporation.  All rights reserved.
    Agent is Not Running
    $ echo $ORACLE_HOME
    /u01/app/oracle/OracleHomes/agent10g
    
    
    agent ORACLE_HOME

    Again, the correct ORACLE_HOME has to be selected; in this case, the ORACLE_HOME of the agent.

    configuration assistants for the Oracle agent

    After the upgrade, the oms has to be restarted

    $ 10om
    $ emctl start oms
    Oracle Enterprise Manager 10g Release 5 Grid Control
    ... ... ...
    opmnctl: opmn is already running
    Starting HTTP Server ...
    Starting Oracle Management Server ...

    a.Log into the repository as SYSMAN
    b.Turn on DBMS JOBS by setting the job_queue_processes to the values written down earlier for each instance
    c.Turn on DBMS Scheduler (10.1+ RDBMS) using the following command:
    SQL> exec dbms_scheduler.set_scheduler_attribute ('SCHEDULER_DISABLED','FALSE');
    
    $ emctl start agent


    Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0.
    Copyright (c) 1996, 2009 Oracle Corporation. All rights reserved.
    Agent is already running
    ha1->
    ha1-> emctl status agent
    Oracle Enterprise Manager 10g Release 5 Grid Control 10.2.0.5.0. 
    Copyright (c) 1996, 2009 Oracle Corporation.  All rights reserved.
    ---------------------------------------------------------------
    Agent Version     : 10.2.0.5.0
    OMS Version       : 10.2.0.5.0
    Protocol Version  : 10.2.0.5.0
    Agent Home        : /oragrid/OracleHomes/agent10g
    Agent binaries    : /oragrid/OracleHomes/agent10g
    Agent Process ID  : 1684
    Parent Process ID : 1668
    Agent URL         : https://ha1:3872/emd/main/
    Repository URL    : https://grid10g:1159/em/upload
    Started at        : 2009-09-26 17:14:15
    Started by user   : oracle
    Last Reload       : 2009-09-26 17:14:15
    Last successful upload                       : 2009-09-26 17:15:24
    Total Megabytes of XML files uploaded so far :     8.80
    Number of XML files pending upload           :        0
    Size of XML files pending upload(MB)         :     0.00
    Available disk space on upload filesystem    :    13.51%
    Last successful heartbeat to OMS             : 2009-09-26 17:15:21
    ---------------------------------------------------------------
    Agent is Running and Ready
    


    Rate this note ...
    Useless Poor Average Good Very helpful