Going to the Cloud

It's been a while (a long while at that) since my last post. I thought it would be fun to start writing again and so will I with a new series of my experience upgrading one of the dev OEM Grid Control 11g to the new OEM Cloud Control 12c

My first day at this task was spent downloading the media packs (I also read through the upgrade documentation and surfed some interesting news sites, had lunch, surfed 9gag for a little while and finally decided to leave the second media pack downloading overnight as it's almost time to go home and it's still at about 60%) due to my limited internet connection (over a vpn link to HQ).

This is my first OEM GC upgrade so I'm not sure what to expect and certainly can't compare it to previous upgrades (i.e. 10g to 11g). I can, however, compare this upgrade to a database upgrade and perhaps to a EBS upgrade.

At first glance I really liked the two-system approach, it makes the upgrade look easy. However I'm not sure I have two systems to do this upgrade, so I might take the one system approach. On the other hand, the system I'm upgrading is clustered, so in theory I could break the cluster, leave only one OMS up and use the second node as the "second system". I think I need to re-read the two-system approach as I mostly focused on 1-system.

The current set up:

I have two nodes with Linux Red Hat Enterprise Linux Server release 5.6 (Tikanga)
The kernel I'm using is:

[oracle@oem1 ~]$ uname -a
Linux oem1 2.6.18-238.5.1.el5 #1 SMP Mon Feb 21 05:52:39 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

I have a 11.2.0.2.0 RAC running with about 7 cluster databases (one of which acts as EM Repository). I also have the entire grid control installed on this cluster. Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0 with PSU4 applied

The target is to have the OMS upgraded to 12c Release 1 as the database version requirement is already me. This is a clustered OMS so I will need to upgrade all the OMS according to the documentation. This looks fairly simple. I will try to keep the most accurate record of my upgrade I can.

Buenos Aires Timezone Change

This is a strictly unsupported comment

The set up:
===========
Oracle 11g (11.1.0.7)
KUbuntu Intrepid (8.10) (Linux omega 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux)

I followed one of the many tutorials to get 11g on ubuntu and it worked flawlessly EXCEPT for the enterprise manager.

When I finished creating the database, I found that EM would not start. After checking the logs I found problems with the timezone and finally came to realize that Oracle had anticipated the Daylight Saving Time whereas KUbuntu had not. So, for the OS it was -180min and for Oracle it was -120min. You can see the problem there, EM would not start.

Workaround:
===========
I've done this a few times, and there are many workarounds... here are the most 'pretty' ones.

1. use enviroment variable to force the timezone variation.

$ export TZ=etc/GMT+3

2. Set the OS timezone to an etc/GMT

# echo 'etc/GMT+3' > /etc/timezone

Note: you may need to reboot after this.

Oracle changes:
===============

You may need to run emctl resetTZ agent.

and run the mgmt_target.set_agent_tzrgn to update the repository:

SQL> exec mgmt_target.set_agent_tzrgn('omega:3938','-03:00');

After this small 'trick' everything worked.

Note that when DST changes again, you will need to follow these steps yet again... but still better than nothing. I'm looking into an ubuntu update to take into consideration Argentina's DST policy which is rather new.

hth
Guillermo Alan Bort
Oracle Certified Associate.