c





 

   
Choosing and implementing the architecture that best fits the availability requirements of a business can
be a daunting task. This architecture must encompass appropriate redundancy, provide adequate
protection from all types of outages, ensure consistent high performance and robust security, while
being easy to deploy, manage, and scale. Needless to mention, this architecture should be driven by
well-understood business requirements. Choosing and implementing high-availability architecture is
covered in Oracle Database High Availability Overview.

Before using the best practices presented in this book, your organization should have already chosen
high-availability architecture for your database as described in Oracle Database High Availability
Overview. If you have not already done so, then refer to that document to learn about the high-
availability solutions that Oracle offers for Oracle

c




 

 
 
To build, implement and maintain high-availability architecture, a business needs high-availability best
practices that involve both technical and operational aspects of its IT systems and business processes.
Such a set of best practices removes the complexity of designing a high-availability architecture,
maximizes availability while using minimum system resources, reduces the implementation and
maintenance costs of the high-availability systems in place, and makes it easy to duplicate the high-
availability architecture in other areas of the business. An enterprise with a well-articulated set of high-
availability best practices that encompass high-availability analysis frameworks, business drivers and
system capabilities, will enjoy an improved operational resilience and enhanced business agility.

Building, implementing, and maintaining a high-availability architecture for Oracle Database using high-
availability best practices is the purpose of this book. By using the Oracle Database high-availability best
practices described, you will be able to:

yY educe the implementation cost of an Oracle Database high-availability system by

following detailed guidelines on configuring your database, storage, application failover,
backup and recovery
yY Avoid potential downtime by monitoring and maintaining your database using Oracle
Grid Control
yY ecover quickly from unscheduled outages caused by computer failure, storage failure,
human error, or data corruption
yY Gliminate or reduce downtime that might occur due to scheduled maintenance such as
database patches or application upgrades
c



   
Oracle Maximum Availability Architecture (MAA) is an Oracle best practices blueprint based on proven
Oracle high-availability technologies and recommendations. The high-availability best practices
described in this book make up one of several components of MAA. MAA involves high-availability best
practices for all Oracle products across the entire technology stackͶOracle Database, Oracle Application
Server, Oracle Applications, Oracle Collaboration Suite, and Oracle Grid Control.

Some of the key features of MAA include:

yY Considers various business service level agreements (SLA) to make high-availability best
practices as widely applicable as possible
yY Leverages database grid servers and storage grid with low-cost storage to provide highly
resilient, lower cost infrastructure
yY Ñses results from extensive performance impact studies for different configurations to
ensure that the high-availability architecture is optimally configured to perform and
scale to business needs
yY Gives the ability to control the length of time to recover from an outage and the amount
of acceptable data loss from a natural disaster
yY Gvolves with each Oracle version and is completely independent of hardware and
operating system

Y Y
Y
  

 
 

 
ecovery Manager (MAN) is an Oracle utility that can back up, restore, and recover database
files. The product is a feature of the Oracle database server and does not require separate
installation.

ecovery Manager is a client/server application that uses database server sessions to perform
backup and recovery. It stores metadata about its operations in the control file of the target
database and, optionally, in a recovery catalog schema in an Oracle database.

You can invoke MAN as a command-line executable from the operating system prompt or use
some MAN features through the Gnterprise Manager GÑI.

  
Most production database systems impose stringent requirements on backup and recovery. As
a DBA in charge of backup and recovery, you must:

yY Manage the complexity of backup and recovery operations

yY Minimize the possibility of human error
yY Make backups scalable and reliable
yY Ñtilize all available media hardware
yY Make backups proportional to the size of transactional changes, not to the size of
database
yY Make recovery time proportional to the amount of data recovered

You have two basic methods for performing these backup and recovery tasks on an Oracle
release 8.0 or higher database:

yY Ñsing operating system commands to perform backup and restore operations, and SQL
or SQL*Plus statements to perform recovery
yY Ñsing ecovery Manager for backup, restore, and recovery

The advantage of using MAN is especially true if you use Oracle Managed Files. When you let
Oracle name and manage your datafiles, control files, and online redo logs, the system becomes
easier to use. On the other hand, it may be harder for you to keep track of the filenames of the
various database files because you have not named them yourself. MAN users do not suffer
from this problem because MAN handles all record keeping.

2
 !
"
"  

" "  

Y
Y

Besides the obvious advantage of automation, MAN provides a host of other useful features.
Below chart compares some of the differences between the MAN methodology and the
traditional user-managed methodology.

2
 #
"  

" " 

 

 

Ñses a media management API so that MAN
works seamlessly with third-party media
management software. More than 20 vendors
support the API.
When backing up online files, MAN rereads
fractured data blocks to get a consistent read. You
do not need to place online tablespaces in backup
mode when performing backups.
Performs incremental backups, which back up
only those data blocks that changed after a
  


Does not have support of a published API.
equires placing online tablespaces in
backup mode before backing them up, and
then taking the tablespaces out of this
mode after the backup is complete. Serious
database performance and manageability
problems can occur if you neglect to take
tablespaces out of backup mode after an
online backup is complete.
Backs up all blocks, not just the changed
blocks. Does not allow you to recover a
  

    



previous backup. You can recover the database NOACHIVGLOG database.
using incremental backups, which means that you
can recover a NOACHIVGLOG database. However,
you can only take incremental backups of a
NOACHIVGLOG database after a consistent
shutdown.
Computes checksums for each block during a Does not provide error checking.
backup, and checks for corrupt blocks when
backing up or restoring. Many of the integrity
checks that are normally performed when
executing SQL are also performed when backing
up or restoring.
Omits never-used blocks from datafile backups so Includes all data blocks, regardless of
that only data blocks that have been written to whether they contain data.
are included in a backup.
Ñses the repository to report on crucial Does not include any reporting
information, including: functionality.

yY Database schema at a specified time

yY Which files need a backup
yY Which files have not had a backup in a
specified number of days
yY Which backups can be deleted because
they are redundant or cannot be used for
recovery
yY Current MAN persistent settings

Stores MAN scripts in the recovery catalog.
Allows you to easily create a duplicate of the
production database for testing purposes, or
easily create or back up a standby database.
Performs checks to determine whether backups
on disk or in the media catalog are still available.
Performs automatic parallelization of backup and
restore operations.
equires storage and maintenance of
operating system-based scripts.
equires you to follow a complicated
procedure when creating a test or standby
database.
equires you to locate and test backups
manually.
equires you to parallelize manually by
determining which files you need to back
up and then issuing operating system
  

 

Tests whether files can be backed up or restored
without actually performing the backup or
restore.
Performs archived log failover automatically. If
MAN discovers a corrupt or missing log during a
backup, then it considers all logs and log copies
listed in the repository as alternative candidates
for the backup.
  


commands in parallel.
equires you to actually restore backup
files before you can perform a trial recovery
of the backups.
Cannot failover to an alternative archived
log if the backup encounters a problem.

c #! $ 

The MAN environment consists of the utilities and databases that play a role in a backup and
recovery strategy. A typical MAN setup utilizes the following:

yY MAN executable
yY Target database
yY ecovery catalog database
yY Media management software

Of these components, only the MAN executable and target database are required. MAN
automatically stores its metadata in the target database control file, so the recovery catalog
database is optional. Nevertheless, maintaining a recovery catalog is strongly encouraged. If
you create a catalog on a separate machine, and if the production machine fails completely,
then you have all the restore and recovery information you need in the catalog.

Y
 


The MAN executable is automatically included with the Oracle software installation. Its
location is platform-specific and is typically located in the same place as the other Oracle
executables. On Ñnix systems, for example, the MAN executable is located in
$OACLG HOMG/bin.

To start the executable, simply enter the filename on the command line. For example, on a
ÑNIX system, enter:

% rman

 





The target database is the database that MAN is backing up, restoring, or recovering. You can
use a single recovery catalog in conjunction with multiple target databases. For example,
assume that your data center contains 10 databases of varying sizes. You can use a single
recovery catalog located in a different data center to manage the metadata from all of these
databases.

   

The MAN repository is a set of metadata that MAN uses to store information about the
target database and its backup and recovery operations. Among other things, MAN stores
information about:

yY Backup sets and pieces

yY Image copies (including archived redo logs)
yY Proxy copies
yY The target database schema
yY Persistent configuration settings

You can access this metadata by issuing LIST, GPOT, and SHOW commands in the MAN
interface, or by using SGLGCT statements on the catalog views (only if you use a recovery catalog)

Y
 %  
"   

Y
Y

You can either create a  

 in which to store the repository, or let MAN store the
repository exclusively in the target database control file. Below chart depicts MAN using a
recovery catalog.

# c 
 2



Y
Y

Although MAN can conduct all major backup and recovery operations using just the control
file, note these advantages of using the catalog:
 yY Some MAN commands and operations function only with a catalog.
yY The recovery catalog retains historical backup information that can get overwritten in
the control file.
yY The recovery catalog stores information about backups from different incarnations of
the database.

The recovery catalog is maintained solely by MAN; the target database never accesses it
directly. MAN automatically propagates information about the database structure, archived
redo logs, backup sets, and datafile copies into the recovery catalog from the target database's
control file. You can also propagate this information to the catalog manually using the GSYNC
CATALOG command.

 


  !


To store backups on tape, MAN requires a 


 . A media manager is a software
program that loads, labels, and unloads sequential media such as tape drives used to back up
and recover data. Below shows the architecture for a media manager integrated with Oracle.

   ! %&
"# c


The Oracle server session is the same type of server session used when a client such as
SQL*Plus connects to the database. The media management library (MML) in above figure
represents vendor-supplied media management software library that can interface with Oracle.
Oracle calls MML software routines to back up and restore data files to and from media
controlled by the media manager
 c


"



 

'
"

The data guard means any DML, DDL, or DCL issued will affect both the databases. In other
words you don't need to duplicate the database again and again; your databases are up to date
at any point.

Data guard can perform failovers and switchovers transparently without informing the client.

Standby database and data guard are 2 different things, because standby database do not
performs failovers and switchovers. The client will receive the error. Data Guard is one step
forward then the standby database

c


'
"
Oracle Data Guard provides the management, monitoring, and automation software to create
and maintain one or more standby databases to protect Oracle data from failures, disasters,
human error, and data corruptions while providing high availability for mission critical
applications

Data Guard's loosely coupled architecture provides optimal data protection and availability:

yY Database changes are transmitted directly from memory, isolating the standby from I/O
corruptions that occur at the primary.
yY A standby database uses a different software code-path than the primary ʹ isolating it
from firmware and software errors that impact the primary database.
yY Oracle corruption detection insures that data is logically and physically consistent before
it is applied to a standby database.
yY Data Guard detects silent corruptions caused by hardware errors (memory, cpu, disk,
NIC) and data transfer faults, and prevents them from impacting the standby database.
yY A standby database is used to perform planned maintenance in a rolling fashion,
minimizing downtime and eliminating the risks inherent with introducing change to
production environments.

Oracle Active Data Guard 11g extends basic Data Guard functionality by allowing read-only
access to a physical standby database while continuously applying changes received from the
primary database. This increases performance and return on investment by offloading ad-hoc
queries, Web-based access, reporting, and backups from the primary database while also
providing disaster protection



'
"!


A 

 "
 !
 consists of one production database and one or more standby
databases. The databases in a Data Guard configuration are connected by Oracle Net and may
be dispersed geographically. There are no restrictions on where the databases are located,
provided they can communicate with each other. For example, you can have a standby
database on the same system as the production database, along with two standby databases
on other systems at remote locations.

You can manage primary and standby databases using the SQL command-line interfaces or the
Data Guard broker interfaces, including a command-line interface (DGMGL) and a graphical
user interface that is integrated in Oracle Gnterprise Manager.

#$Y x 





A Data Guard configuration contains one production database, also referred to as the primary
database that functions in the primary role. This is the database that is accessed by most of
your applications.

The primary database can be either a single-instance Oracle database or an Oracle eal
Application Clusters (AC) database.

$Y 



 

A standby database is a transactionally consistent copy of the primary database. Ñsing a backup
copy of the primary database, you can create up to thirty standby databases and incorporate
them in a Data Guard configuration. Once created, Data Guard automatically maintains each
standby database by transmitting redo data from the primary database and then applying the
redo to the standby database.

Similar to a primary database, a standby database can be either a single-instance Oracle

database or an Oracle AC database.

The types of standby databases are as follows:

yY x  
 





Provides a physically identical copy of the primary database, with on disk database
structures that are identical to the primary database on a block-for-block basis. The
database schemas, including indexes, are the same. A physical standby database is kept
synchronized with the primary database, through edo Apply, which recovers the redo data
received from the primary database and applies the redo to the physical standby database.

As of Oracle Database 11à release 1 (11.1), a physical standby database can receive and
apply redo while it is open for read-only access. A physical standby database can therefore
be used concurrently for data protection and reporting.

yY º
 





It contains the same logical information as the production database, although the
physical organization and structure of the data can be different. The logical standby
database is kept synchronized with the primary database through  º , which
transforms the data in the redo received from the primary database into SQL
statements and then executes the SQL statements on the standby database.

A logical standby database can be used for other business purposes in addition to
disaster recovery requirements. This allows users to access a logical standby database
for queries and reporting purposes at any time. Also, using a logical standby database,
you can upgrade Oracle Database software and patch sets with almost no downtime.
Thus, a logical standby database can be used concurrently for data protection,
reporting, and database upgrades.

yY 
 





A snapshot standby database is a fully updatable standby database.

Like a physical or logical standby database, a snapshot standby database receives and
archives redo data from a primary database. Ñnlike a physical or logical standby
database, a snapshot standby database does not apply the redo data that it receives.
The redo data received by a snapshot standby database is not applied until the snapshot
standby is converted back into a physical standby database, after first discarding any
local updates made to the snapshot standby database.

A snapshot standby database is best used in scenarios that require a temporary,

updatable snapshot of a physical standby database. Note that because redo data
received by a snapshot standby database is not applied until it is converted back into a
physical standby, the time needed to recover from a primary database failure is directly
proportional to the amount of redo data that needs to be applied.

 Y

 

Below image shows a typical Data Guard configuration that contains a primary database
that transmits redo data to a standby database. The standby database is remotely
located from the primary database for disaster recovery and backup operations. You can
configure the standby database at the same location as the primary database. However,
for disaster recovery purposes, Oracle recommends you configure standby databases at
remote locations.

j 


'
"2!




( )
*&
 +,,

&  j