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

Any release lower than the ones listed require an intermediate upgrade before going to 12.1, or you can pursue
an alternative strategy of some sort, such as to recreate the database and move the data from old to new. If you needed
additional arguments why it is a good idea to stay reasonably current with your production environment, here is one.
If you stayed on a release prior to let's say 10.2.0.5 for too long for example you have to perform one extra step before
going to 12c, which will extend the time window required for the migration. The requirements however are moderate,
and the application of a database patch set is not too much work, only time consuming. The functional risk is really
all the regression testing, which for most applications is still not automated. Too large a “gap” however, might make it
even more difficult to initiate a migration project, as the hurdles may be perceived to be too high.
Another important decision to be made is whether or not you want to perform a hardware refresh at the same
time. Most companies use their hardware for a specific amount of time, and a migration project is often taken as an
opportunity to get newer, faster hardware. Chapters 3 and 4 described hardware and software choices available for
Oracle 12c in more detail.
If you go with a new server, you could install Oracle Restart and all other software homes in their respective
version on the target server, and perform any configuration without time pressure you would certainly experience
when performing the installation on the same host. Remember that you cannot install the 12c database binaries and
continue to use the previous release's Oracle Restart at the same time. It has always been the case that Oracle Restart
(and Clusterware for that matter) had to be a version number equal or higher than the Oracle database. But how
would you get the database across to the new server? If you are staying within the restrictions set by Data Guard then
it is the easiest technology to use for the hardware refresh/migration. Consider the following scenario:
As part of the migration you could perform a Data Guard switchover to the standby database on the new
hardware. Emphasis should be put on the fact that the switchover does not change the Oracle version yet, but it does
get you on newer better hardware! Although you are using Oracle Restart 12.1 on the target hardware you have an
11.2 RDBMS home as well-this is the home to use for the Data Guard configuration. The initial setup is shown in
Figure 12-2 below.
Figure 12-2. Upgrade using a Data Guard switchover
After the successful switchover you can upgrade the database just as you would without the Data Guard setup
in the next step. This strategy gives you lots of freedom, and your back-out plan can be as elaborate as you like. One
possibility is to use an Oracle 12c RDBMS home on the legacy hardware as shown in Figure 12-3 for a physical standby.