Database Reference
In-Depth Information
“Pre 12.1 Database Issues in 12c Grid Infrastructure Environment.” Bear in mind that the note is written for Real
Application Clusters as well as Oracle Restart.
Most of the issues documented in the note can be solved if Oracle Restart is operating in a pre 12c friendly
mode. In this mode, the server is said to be “pinned.” When upgrading from a previous version of Oracle Restart the
compatibility mode is always on. If you performed a fresh 12c Grid Infrastructure installation then you need to “pin”
your node using crsctl. Please refer to the aforementioned MOS note for more information.
Another problem is that you cannot manage a pre 12c database when your ORACLE_HOME environment
variable is set to the 12c Grid Home. Trying to interrogating the status of the database results in the following
error message:
[grid@server1 crsconfig]$ srvctl config database -db ora11
PRCD-1027 : Failed to retrieve database ora11
PRCD-1229 : An attempt to access configuration of database ora11 was rejected because
its version 11.2.0.3.0 differs from the program version 12.1.0.1.0. Instead run the
program from /u01/app/oracle/product/11.2.0.3/dbhome_1.
This message is not new with 12c, it has been around for a while and the situation was exactly the same when
using 11.2 Grid Infrastructure and pre 11.2 databases on the same host.
Upgrading the database
Compared to the migration of Oracle Restart which is mostly automatic, the migration of the database to the
new release is where the real work lies. ASM has become a lot more sophisticated over time the databases
acting as ASM clients did not necessarily take notice that a version change has occurred. Changes in the way the
Oracle database operates internally however can make a version change a little more challenging. Luckily for
you researchers have always scrutinized the behavior changes-mostly optimizer related-from release to release.
Jonathan Lewis has published a lot on optimizer changes, and will surely continue to do so for the current release.
Maria Colgan from Oracle is also a great source for information, she contributes to the Oracle blog related to
the optimizer. And then there is too large a number of other reasearchers doing their own publications on how
the current release is different from the previous one. Therefore you are going over multiple iterations until you
understand the upgrade logic, then migrate the lower tiers until it is finally time to migrate production and the
disaster recovery environment.
If there is a “magic” parameter that controls a lot within Oracle it is the initialization parameter named
“compatible.” It is rarely touched, and for good reason. Increasing the value for “compatible” makes it impossible to
downgrade to a lower release unless you perform a restore from your backup medium. The message therefore has
to be: do NOT touch the compatible initialization parameter unless you are absolutely sure that your application
performs within the Service Level Agreements and there are no show stoppers that thorough, professional, regression
testing have found.
From a process point of view the migration project can have multiple phases, not all of which are mandatory:
1.
The engineering department reviews the new Oracle release and becomes familiar with
it. In the absence of an engineering department dedicated members of the operational
support team should test the new release.
2.
An otherwise unused test environment with a clone of a database is created on separate
hardware to allow database administrators to perform the migration without time
pressure. So far the migration process was technology driven.
3.
The development environments are migrated. Special emphasis should be on the
development process. Can the development tools which are used still be used without
limitations? Is the Continuous Integration process still working? Are you capable of
performing unit tests? What about replication-Data Guard or other solutions? At this stage
Search WWH ::
Custom Search