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

Figure 12-3. Backout strategy with Data Guard in place
Using that approach you could downgrade the database to the previous release you migrated off and even switch
back to the old hardware if that was required. Additionally you get the benefit of being able to implement separation
of duties when installing the software on a different machine. An upgrade of Oracle Restart on the same server does
not easily allow you to change the owner of the binaries. If you installed both Oracle Restart 11.2 and the Oracle
database as the oracle account you tend to keep this configuration for version 12c.
In this chapter it is assumed that you are upgrading the database on the same host. Also note that the example
assumes you are running a platform which is in premier support-at the time of this writing only Oracle 11.2 was in that
support state. And since it is always good to be on the latest patchset to avoid the inevitable “apply the latest patchset”
reply in a service request this is the case as well.
Before you upgrade production...
Performing a major release upgrade is anything but trivial depending on the application. The complexity increases
with hardware and potentially associated platform change. The old rule that well-written, well-designed applications
are easier to migrate still applies today. Complex applications written under a lot of time pressure are the most
difficult to migrate. Hard-coded and undocumented connection strings buried deep within the application logic core
are only the tip of the iceberg! You really need to ensure that you are working with all stakeholders, technical and
functional, of your current product to ensure a smooth transition to Oracle 12c. This type of project definitely requires
sufficient time for testing the application against the next database release. In the author's opinion there are two main
areas to focus on during the testing period:
• Functional . Does the application perform as expected from a technical point of view? Does
your regression test produce the same output on screen and in reports that you had previously?
You are in a lucky position if your regression testing is automated, including the comparison
of the application's output. If everything is the same: great! If not, you need to spend time
investigating why. A prominent although somewhat older example includes the change from 9i
to 10g when result sets were no longer implicitly ordered if the select statement did not have an
“order by” clause. This is exactly the type of problem you want to catch before going live!
• Technical . Does the latest Oracle release produce the same results as the previous one? Did
execution plans change? Do your important queries finish within the allowed time and Service
Level Agreement? If not, why? Do you get any contention in the critical Oracle memory areas?