Upgrading to Oracle 12c - Expert Consolidation in Oracle Database 12c - page 425

some initial regression testing can be performed. Commercial packaged applications
depending on the database for reporting or business intelligence might need upgrading
too to support Oracle 12c. When migrating it is highly recommended to consider the full
stack from top to bottom and carefully check product compatibility lists for all software
involved.

4. The back-out plan is tested a few times to hone in the routine.

5. Upgrade of higher tiers, except production and disaster recovery (“DR”). This is the phase

that requires most attention. Regression testing of the application, parallel runs, and much
more are performed at this stage to ensure that the application continues to run within
the required parameters. Anything external to the database should not be forgotten: feeds,
web services, externally scheduled jobs, reporting software etc. fall into this category. Only
if all stakeholders sign off can you proceed and migrate the life and DR environments.

6. As a last step of the upgrade project you upgrade production and the Disaster Recovery

environments.

Once the immediate pressure of migrating to 12c is removed you can think of implementing the consolidation
strategies. Non-Container Databases can be consolidated into Container Databases. You should consider
implementing Resource Manager at the CDB and PDB level depending on the class of service the application is using.
Refer back to Chapter 7 for more information about implementing Resource Manager with Pluggable Databases. This
chapter will show you how to migrate a non-CDB into a CDB as part of the migration.
Let's have a look at the steps to be performed in more detail for a database migration.

High level steps
The individual database migration contains a number of steps that need to be performed sequentially. As one of the
first tasks you need to become familiar with the new database release. This is why the author is hoping you are reading
this topic! Then you have to think about an upgrade strategy, which must include the worst case and a downgrade or
a restore from backup if everything else fails. Like with every major task involving the Oracle database you must have
a valid backup before commencing the work. Your upgrade plan should include phone numbers for escalation of calls
to the backup team who will assist with the restore of the database if needed.
The test plan will be put to practice when you begin the migration of a fresh copy of production on a host clearly
marked for development. It is possible that lots of developers depend on the machine you are testing on, if possible
you should migrate an independent copy of the database, not an actual development database, space permitting.
Although labeled development environment many of these systems are as important as the actual production
database, especially for Independent Software Vendors (ISV). Imagine you had 50 developers sitting idle for a couple
of days due to a database outage! Whichever way you choose, please ensure you have a strategy for backing out.
This strategy must be tested and signed off as part of the process. RMAN backups can be used but any other reliable,
supported, documented, tried and tested procedure will also be appropriate, if it has proven to revert back to the start
without any issues.
Consider a cycle as show in Figure 12-6 .