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

• Post Upgrade Recommendations : Although not strictly speaking necessary Oracle might
recommend upgrading the time zone file. This step is needed if your application makes use of
named timezones (for example timestamp '2013-08-16 19:00:00 Europe/London BST' and the
timezones you are storing changed recently. Remember to upgrade the server and all clients
to the new timezone file!

• Summary : Presents a summary of the gathered information and lists any error that might
prevent your upgrade from succeeding. Do not proceed until you fixed any potential error
unless you want to practice restores under pressure!

In the demo system used for this chapter Oracle complained about too low a setting for the processes
initialization parameter. In previous versions it was common to have this set to 150, especially for databases with
fewer concurrent users. Oracle now insists on a value of 300 for the processes parameter. Note that if the tool finds
the Enterprise Manager DBConsole repository in the database the preupgrade utility advises that the OEM repository
will be removed as part of the upgrade. In order to save time it is therefore recommended by the utility to remove the
repository prior to the upgrade. The final recommendation for the database was to gather dictionary statistics before
starting the actual upgrade.
Before continuing you should get a list of objects currently invalid in the database. In an ideal world there are
no invalid objects in a database after a global compilation using utlrp.sql for example has been started during a
maintenance window. However the world is not perfect and there might be objects that do not compile. You should
take note of them and compare the list with the list of invalid objects after the migration has completed. To do so,
execute the script utluiobj.sql before and after the migration to get a list of invalid objects. The upgrade guide lists the
following additional areas of interest before the upgrade:

• Access Control Lists (ACLs) which have been introduced with Oracle 11g for network related

PL/SQL packages have been revised. The new database release 12c uses Real Application
Security removing the dependency on XML DB.

• The way that database passwords for database links are stored has changed. If you plan

on downgrading the database from 12c to your original release you should preserve the
passwords before you upgrade.

• As with many Oracle migrations you need to upgrade the timezone files as part of the process.

Be careful with the procedure-columns using TIMESTAMP WITH TIMEZONE could become
corrupted if not treated correctly. Even if your application does not make use of this, the
Oracle Scheduler does make intensive use of it!

• If your application or database makes use of materialized views, please ensure that all refresh

operations have completed before migrating.

Additional information about pre-upgrade checks and prerequisites can be found in the official Database
Upgrade Guide, section 2.5.

Making a database available for a first test migration
In the following step you need to make the database available to the new server for a first upgrade attempt. This can
either be a clone of the database's LUNs or an RMAN-created clone. In any way you should try and get a database
which has not been in use to ease the time pressure of having to succeed within a change window.
If you have been lucky and you storage administrator has given you a clone of the LUNs used for the test
database, then you might have to rescan the SCSI bus and update the multipath configuration. The kpartx utility
is a great way of making partitions on device-mapper multipathed devices known to the operating system without
rebooting the server. If you are on an earlier version of RedHat or Oracle Linux and use ASMLib, then you might need
to perform a scandisks operation to make the new LUNs available to Oracle ASM.