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

Both of the above mentioned areas are equally important, although the database administrator is more likely to
be able to help with the second bullet point. For reasons outlined in chapter 1 it can be very difficult for an operational
DBA to be reasonably familiar with the database he or she is about to upgrade. Changes from a technical point of view
are easier visible to the technical staff. Comparing execution plans, response times and the general behavior between
versions can be detected using the Automatic Workload Repository and other monitoring solutions. What's more
difficult is to work out if the application does not show regressions under the new database release.

■ ideally you are not changing the application code when migrating to a new release! otherwise, how would you
be able to attribute a problem post migration to the new database release or the new application release?

Note

To address bullet point number two more forward-looking planning is necessary. Ideally an application support
team has a set of end-to-end testing systems allowing (fully?) automated regression testing of the application.
If the application features a graphical user interface then macro-recording software could be used to replay key
transactions. Every Key Performance Indicator (KPI) of your software, especially if the KPI is under a Service Level
Agreement, must be tested repeatedly and as automated as possible to prevent deviations due to human error. And
let's face it-repeatedly testing the same processes is not the most entertaining activity in the world.
This section's nugget is that thorough testing using automated procedures would be ideal to prevent unpleasant
surprises when going life in production with the next database release. This has been true for any major release
change, not only Oracle 12c by the way. If automated testing is not available then the project manager should at
least be available to identify key processes that the application team can test post the test migrations. In case of
performance degradation theses users should contact the database team for further investigation. This could involve
tracing specific end-user processes if possible or other “business as usual” troubleshooting processes. A migration
to the next database release should not cause unexpected problems in the ideal world. In reality though all testing is
limited to the ingenuity of the people involved, and sometimes it simply is not possible to plan for all eventualities.
The more time you can spend on the migration, the more likely it is to capture problems beforehand. But please
do not let the migration intimidate you too much: staying on a particular release for too long will make upgrades
happening too late and even more daunting.

Upgrading Oracle Restart on the same server
If you are already using Oracle Restart in a version supporting a direct upgrade, the first step in the migration of
your database is to upgrade Clusterware Since Oracle 11.2.0.2 all patches to Grid Infrastructure-clustered and
unclustered-require an out-of-place upgrade. This means that you will need an additional, separate Grid Home for
the base release, and each subsequent major patch. Oracle mandates the out-of-place upgrade to make it easier to
revert to a previous version of the software. After sufficient testing has ensured that your environment is stable you
can of course delete the old one, after a complete file system backup. As with every operation, the removal of the old,
now unused, Grid Home must be tested first on an identical environment before performing this task in production,
in addition to the file system backup you have taken! If possible you should draft a plan to create storage snapshots
of the LUNs containing the Oracle binaries (all of them-not only the Grid home!) and if the storage admin is in good
mood try to get the same service for your database LUNs as well. If storage snapshots are not possible then you must
ensure alternative means of file system and database backups before starting any work. Snapshots based on the
Logical Volume Manager (LVM) have proven to be useful in the world of Engineered Systems, and they might equally
be useful for “regular” Oracle builds as well. You should perform a backup of the Oracle Local Registry manually just
in case, before initiating the file system backup:

[root@server1 ~]# ocrconfig -local -manualbackup