Cross platform upgrade to Cloud Control 12c

I’ve spent the last couple of days working on a cross platform upgrade to Oracle Cloud Control 12c.

I’ve been working with a customer who recently consolidated onto Exadata. Cloud Control 12c has a very nice Exadata plugin to assist in monitoring and performance analysis and tuning, so the Exadata project also included moving them over from Grid Control 10g running on a Windows server to Cloud Control 12c running on Oracle Linux.

Their current Grid Control sits on Windows with a 10.2.0.5 OMS running on top of an 11.1.0.5 database. We’re moved them over to 12.1.0.3 OMS sitting on top of 11.2.0.4 database (sadly no 12.1 database support yet). As they’ve made a lot of customisations to their existing Grid Control environment they were eager to upgrade rather than start fresh.

I’m actually doing what Oracle call a “two system upgrade”. The 10g environment stays where it is, and the 10g agents stay in place. The 12c OMS gets built (the 10g database gets copied over and upgraded) but the 10g OMS remains active until you’re ready to switch it off. As we’re migrating across platforms and database versions, we’re using Data Pump to move the database across rather than RMAN.

Upgrade Console

The first thing you do is install a patch onto the 10g OMS which provides you with an “Enterprise Manager 12c Upgrade Console” in the deployments tab. This is an excellent tool which really guides you through the entire process. At first you use it for downloading and staging the necessary 12c agent software, and later you use it for deploying and configuring your new agents switching over to them.

Download software

There is quite a lot of software to download, but the upgrade console does tell you exactly what you need depending on what type of targets you’re already monitoring. For example in our case it tells us we need to download the Windows 32 and 64 bit core agent software, and a fairly long list of different plugins such as Database, Oracle Home, Fusion Middleware etc. Download all the zip files to a directory on the server and eventually the console will be happy to tell you that you have all the necessary software in place. The console handles the unzip process automatically.

12c repository database

Now is a good time to start thinking about the new 12c repository. You can create a database from the general purpose seed files, but now is a good time to get a few prereqs in place. These include sizing the redo to at least 1GB, and certain other initialisation parameters. You’ll also need to make sure that the Partitioning option is enabled. Don’t worry, anything you miss will be picked up during prereq checks. Do make sure you use the same character set as the 10g OMS uses currently – in our case this means going with WE8MSWIN1252 rather than the standard AL32UTF8. Don’t be optimistic in thinking that you can migrate across character sets or you’ll hit this during upgrade –


ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at "SYSMAN.EM_CRYPTO", line 62
ORA-06512: at "SYSMAN.EM_CRYPTO", line 229
ORA-06512: at line 55

There are also a number of other SQL scripts which need to be run to prepare for the repository database import. You can copy these from the 10g OMS home. They create things which won’t necessarily come across with the import (roles, synonyms, various other things). You also need to drop the SYSMAN schema which is probably already present.

Export / Import

With the software in place on your 10g OMS, you need to make sure you follow the step which copies your agent key to the repository database so that it comes across with the dump files. Then you take an export of the SYSMAN schema and import it into your new database. That should import cleanly. You actually provide the upgrade console with the time that the export was taken so that it knows where to pick up the syncronisation from later.

12c Installation / Upgrade

The 12c software installation and upgrade is a single step, although you can separate it by doing a software installation first if you wish. You point it at the database you imported, and it’ll run the prereq checks. Fix anything it complains about and proceed with the repository upgrade. This does take a while but at the end it’ll present you with a nice screen telling you where to point your browser to login to your new 12c environment! All the users are copied across during upgrade.

Agent Upgrade

This is another step which the upgrade console guides you through, on the 10g environment. You can do this before or after the export and repository upgrade. You select the agent(s) you wish to upgrade, provide OS login details and let it deploy and configure the agent software. The software sits happily beside the old agent software and doesn’t interfere with its operation so you can do this any time you like. It won’t start talking to the 12c repository until you perform an agent switch over later, and the 10g agent will continue to do its job.

The only thing to watch out for here is that the HTTPS upload port configured in the upgrade console is the one you chose during 12c installation.

Agent Health Check / Switch Over

When you have some 12c agent software in place, you can trigger a health check of that new agent. Again the upgrade console takes you through this, but it starts the 12c agent alongside the 10g one, and makes sure that it can communicate on the HTTPS port with the 12c OMS. Any problem, and it’ll likely flag up as a “ping test” failure on the health check report and leave you to investigate the cause. It should be the case that once you get one agent communicating with OMS, the rest work without issue.

When you’re happy that the health check looks good you can switch over that agent to the new 12c repository and it’ll take a minute or two to show up “green” in your new 12c Cloud Control environment! You might want to perform this last step on all agents in one go so that at that point you can turn off your 10g OMS environment.

Summary

I’ve been pleasantly surprised how well this process works, once you fix a few (generally self inflicted!!) problems. The documentation is a bit of a minefield, and it sends you flicking between different documents and different chapters so its quite easy to miss important information. Once you get there though, it all falls into place nicely and leaves you with a new Cloud Control environment which should feel a bit more homely than starting fresh.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: