Database Reference
In-Depth Information
Application Continuity (AC) of Oracle 12c
In pre-Oracle 12c Database, depending on the applications, application errors may occur during a database instance
outage despite the successful commit of the transaction at the moment of failure. Such errors may leave applications
in doubt, and users may receive errors or need to log in again or resubmit requests, etc. These problems are due to the
lack of a way for applications to know the outcome of a failed transaction, the inability to migrate the workload that is
affected by the planned or unplanned outage, and also the need to repair the workload.
To ensure that applications are minimally impacted in the event of node failure or instance failure, Oracle 12c
introduces a new solution called Application Continuity (AC). This new feature masks recoverable outages from
end-users and applications by replaying the database request at another Oracle RAC instance (for RAC) or another
database for the standby database. This feature is designed to preserve the commit outcome and ensure application
continuity for both unplanned and planned downtime.
High Availability Against Planned Downtime
Oracle RAC helps achieve database HA by reducing database service downtime due to the scheduled maintenance
of the database infrastructure. Scheduled maintenance work may include server hardware upgrades or maintenance,
server OS upgrade, and Oracle software upgrades. Depending on the task, these maintenance jobs may require bringing
down the database instance or OS, or the server hardware itself. With Oracle RAC, maintenance work can be done in
rolling fashion without the need to bring down the entire database service. Let's see how to perform rolling-fashion
maintenance for different types of maintenance tasks.
Hardware maintenance of the database server may be needed during the lifetime of the server, for example
upgrading or replacing hardware components such as CPUs, memory, and network cards. Although server downtime
is required for this kind of maintenance, with Oracle RAC the database connections on the database instance of the
impacted server can be relocated to other instances on the cluster. The maintenance can be done in rolling fashion by
the following steps:
1.
Relocate the database connections to the other instance;
2.
Shut down the entire software stack in this order:
a)
Database instance
b)
ASM and Clusterware
c)
Operating system
d)
Server hardware
3.
Perform the server hardware upgrade;
4.
Restart the software stack in the reverse order
5.
Repeat steps 1 to 4 for all other servers in the cluster.
Since the database connections are relocated to the other instance during hardware maintenance, the database
service outage is eliminated. This rolling-fashion system maintenance enables system upgrades without database
service downtime.
A similar rolling-upgrade method applies to OS upgrades, as well as other utility upgrades such as firmware,
BIOS, network driver, and storage utility upgrades. Follow steps 1 to 5 except for the server hardware shutdown at
step 2, and perform the OS or utility upgrade instead of the hardware upgrade at step 3.
You can also perform a rolling upgrade of Oracle Clusterware and ASM to avoid Clusterware and ASM downtime.
In Oracle RAC 12.1, you can use Oracle Universal Installer (OUI) and Oracle Clusterware to perform a rolling upgrade
to apply a patchset release of Oracle Clusterware. This allows you to shut down and patch RAC instances one or
more at a time while keeping other RAC instances available online. You can also upgrade and patch clustered Oracle
ASM instances in rolling fashion. This feature allows the clustered ASM environment to continue to function while
 
Search WWH ::




Custom Search