Beruflich Dokumente
Kultur Dokumente
Environment:
Operating System: Linux
Database Version: 9.2.0.4
Primary Database: prod
Secondary Database: prod2
listener.ora Additions:
Define the standby database SID on the standby site:
(SID_DESC=
(SID_NAME=PROD2)
(ORACLE_HOME=/pgms/oracle/product/v9204)
)
(in $ORACLE_HOME/network/admin/listener.ora)
tnsnames.ora Additions:
Define the standby database connect string on the primary site:
myserver_prod2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS =(PROTOCOL = TCP) (Host = 123.45.67.89) — whatever host IP
has PROD2(Port = 1521)
) )
(CONNECT_DATA = (SID = PROD2) ) )
(define myserver_prod and myserver_prod2 on both primary and standby sites
for quick switchovers)
sqlplus “/ as sysdba”
SQL> create pfile=’$ORACLE_HOME/dbs/initPROD2.ora’from spfile;
Else, if your primary is using a pfile:
cp -p $ORACLE_HOME/dbs/initPROD.ora
$ORACLE_HOME/dbs/initPROD2.ora
Note: We will be modifying both the primary and standby parameter files to handle being in
either the primary or the standby mode for quick switchovers.
(If primary uses spfile, wait until after the standby databasefiles are copied/created to make
these parameter changes.)
‘/orcl/oradata/PROD2/ctrl_PROD_01.ctl’;
Shut down the primary database and copy or FTP its datafiles, redo log files, and the just-
created standby parameter file and standby control file, to the standby site.
Copy the standby control file on the standby site to the other file names listed in the
control_files init.ora parameter.
You now have a working standby database for your primary database
$ sqlplus “/ as sysdba”
SQL> select max(group#) maxgroup from v$logfile;
SQL> select max(bytes) / 1024 “size (K)” from v$log;
On the primary:
SQL> alter database recover managed standby database disconnect from
session;
On the standby:
SQL> alter system archive log current;
Change tnsnames.ora entry on all servers to swap the connect strings (myserver_prod and
myserver_prod2).
On the standby:
SQL> alter database recover managed standby database finish;
SQL> alter database commit to switchover to primary;
SQL> shutdown immediate
SQL> startup
Change tnsnames.ora entry on all servers to point the primary connect string to the standby
database.
This query detects gaps in the logs that have been received. If any rows are returned by this
query then there is a gap in the sequence numbers of the logs that have been received.
This gap must be resolved before logs can be applied.
This query detects bad statuses. When a bad status is present this query will return a “1″.
The ‘ARCH’ process should always be ‘CONNECTED’. The ‘MRP0′ process should always
be waiting for a log or applying a log, and when this is not true it will report the error in the
status. The ‘RFS’ process exists when the Primary is connected to the Standby and should
always be ‘IDLE’ or ‘RECEIVING’.
This query detects missing processes. If we do not have exactly 3 distinct processes then
there is a problem, and this query will return a “1″.
The most likely process to be missing is the ‘RFS’ which is the connection to the Primary
database. You must resolve the problem preventing the Primary from connecting to the
Standby before this process will start running again.
Verify all STANDBY PROCESSES are running normally on the STANDBY database.
SELECT PROCESS,STATUS,RESETLOG_ID,SEQUENCE#,ACTIVE_AGENTS
FROM V$MANAGED_STANDBY ;
A query with good results follows proving all processes are connected with normal statuses.
V$DATABASE
PROTECTION_LEVEL: current protection mode setting.
FS_FAILOVER_STATUS: synchronization status
DBA_LOGSTDBY_UNSUPPORTED: unsupported tables.
DBA_LOGSTDBY_EVENTS: monitor transaction activity.
V$LOG: Redo log changed.
V$MANAGED_STANDBY : Recovery progress.
Oracle Data Guard is the management, monitoring, and automation software infrastructure
that creates, maintains, and monitors one or more standby databases to protect enterprise data
from failures, disasters, errors, and corruptions.
Data Guard maintains these standby databases as transitional consistent copies of the
production database. These standby databases can be located at remote disaster recovery sites
thousands of miles away from the production data centre, or they may be located in the same
city, same campus, or even in the same building. If the production database becomes
unavailable because of a planned or an unplanned outage, Data Guard can switch any standby
database to the production role, thus minimizing the downtime associated with the outage,
and preventing any data loss.
Available as a feature of the Enterprise Edition of the Oracle Database, Data Guard can be
used in combination with other Oracle High Availability (HA) solutions such as Real
Application Clusters (RAC), Oracle Flashback and Oracle Recovery Manager (RMAN), to
provide a very high level of data protection and data availability that is unprecedented in the
industry.
it is recommended that the standby databases are hosted at sites that are geographically
separated from the primary site.
A physical standby database 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. The Redo Apply
technology applies redoes data on the physical standby database using standard Oracle media
recovery techniques.
A logical standby database contains the same logical information as the production database,
although the physical organization and structure of the data can be different. The SQL apply
technology keeps the logical standby database synchronized with the primary database by
transforming the data in the redo logs received from the primary database into SQL
statements and then executing the SQL statements on the standby database. This makes it
possible for the logical standby database to be accessed for queries and reporting purposes at
the same time the SQL is being applied to it. Thus, a logical standby database can be used
concurrently for data protection and reporting.
Role Management:
Using Data Guard, the role of a database can be switched from a primary role to a standby
role and vice versa, ensuring no data loss in the process, and minimizing downtime. There are
two kinds of role transitions – a switchover and a failover. A switchover is a role reversal
between the primary database and one of its standby databases. This is typically done for
planned maintenance of the primary system. During a switchover, the primary database
transitions to a standby role and the standby database transitions to the primary role. The
transition occurs without having to re-create either database. A failover is an irreversible
transition of a standby database to the primary role. This is only done in the event of a
catastrophic failure of the primary database, which is assumed to be lost and to be used again
in the Data Guard configuration, it must be re-instantiated as a standby from the new primary.
available on at least one standby database configured in this mode. If the last standby
database configured in this mode becomes unavailable, processing stops on the
primary database. This mode ensures no-data-loss.
Maximum Availability— This mode is similar to the maximum protection mode,
including zero data loss. However, if a standby database becomes unavailable (for
example, because of network connectivity problems), processing continues on the
primary database. When the fault is corrected, the standby database is automatically
resynchronized with the primary database.
Maximum Performance— This mode offers slightly less data protection on the
primary database, but higher performance than maximum availability mode. In this
mode, as the primary database processes transactions, redo data is asynchronously
shipped to the standby database. The commit operation of the primary database does
not wait for the standby database to acknowledge receipt of redo data before
completing write operations on the primary database. If any standby destination
becomes unavailable, processing continues on the primary database and there is little
effect on primary database performance.
Fast-Start Failover
This capability allows Data Guard to automatically, and quickly fail over to a previously
chosen, synchronized standby database in the event of loss of the primary database, without
requiring any manual steps to invoke the failover, and without incurring any data loss.
Following a fast-start failover, once the old primary database is repaired, Data Guard
automatically reinstates it to be a standby database. This act restores high availability to the
Data Guard configuration.
Automatic deletion of applied archived redo log files in logical standby databases
Archived logs, once they are applied on the logical standby database, are automatically
deleted, reducing storage consumption on the logical standby and improving Data Guard
manageability. Physical standby databases have already had this functionality since Oracle
Database 10g Release 1, with Flash Recovery Area.
Oracle Enterprise Manager has been enhanced to provide granular, up-to-date monitoring of
Data Guard configurations, so that administrators may make an informed and expedient
decision regarding managing this configuration.
The Real Time Apply feature allows standby databases to be closely synchronized with the
primary database, enabling up-to-date and real-time reporting (especially for Data Guard
SQL Apply). This also enables faster switchover and failover times, which in turn reduces
planned and unplanned downtime for the business.
The impact of a disaster is often measured in terms of Recovery Point Objective (RPO – i.e.
how much data can a business afford to lose in the event of a disaster) and Recovery Time
Objective (RTO – i.e. how much time a business can afford to be down in the event of a
disaster). With Oracle Data Guard, when Maximum Protection is used in combination with
Real Time Apply, businesses get the benefits of both zero data loss as well as minimal
downtime in the event of a disaster and this makes Oracle Data Guard the only solution
available today with the best RPO and RTO benefits for a business.
One such benefit is human error protection. In Oracle9i, administrators may configure Data
Guard with an apply delay to protect standby databases from possible logical data corruptions
that occurred on the primary database. The side-effects of such delays are that any reporting
that gets done on the standby database is done on old data, and switchover/failover gets
delayed because the accumulated logs have to be applied first. In Data Guard 10g, with the
Real Time Apply feature, such delayed-reporting or delayed-switchover/failover issues do not
exist, and – if logical corruptions do land up affecting both the primary and standby database,
the administrator may decide to use Flashback Database on both the primary and standby
databases to quickly revert the databases to an earlier point-in-time to back out such user
errors.
Another benefit that such integration provides is during failovers. In releases prior to 10g,
following any failover operation, the old primary database must be recreated (as a new
standby database) from a backup of the new primary database, if the administrator intends to
bring it back in the Data Guard configuration. This may be an issue when the database sizes
are fairly large, and the primary/standby databases are hundreds/thousands of miles away.
However, in Data Guard 10g, after the primary server fault is repaired, the primary database
12-14
may simply be brought up in mounted mode, “flashed back” (using flashback database) to
the SCN at which the failover occurred, and then brought back as a standby database in the
Data Guard configuration. No re-instantiation is required.
Rolling Upgrades:
Oracle Database 10g supports database software upgrades (from Oracle Database 10g
Patchset 1 onwards) in a rolling fashion, with near zero database downtime, by using Data
Guard SQL Apply. The steps involve upgrading the logical standby database to the next
release, running in a mixed mode to test and validate the upgrade, doing a role reversal by
switching over to the upgraded database, and then finally upgrading the old primary database.
While running in a mixed mode for testing purpose, the upgrade can be aborted and the
software downgraded, without data loss. For additional data protection during these steps, a
second standby database may be used.
By supporting rolling upgrades with minimal downtimes, Data Guard reduces the large
maintenance windows typical of many administrative tasks, and enables the 24×7 operation
of the business.
Additional Datatypes:
SQL Apply now supports the following additional data types.
NCLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
IOT-s (without overflows and without LOB columns)
This support for additional datatypes allows logical standby databases to recover and protect
a wider variety of data, thus increasing the overall database protection and recovery options
for Data Guard.
Administration of a Data Guard configuration can be done through the new streamlined
browser-based HTML interface of Enterprise Manager that enables complete standby
database lifecycle management. The focus of such streamlined administration is on:
Ease of use.
Management based on best practices.
Pre-built integration with other HA features.
Integrated with Oracle database Data Guard is available as an integrated feature of the
Oracle Database (Enterprise Edition) at no extra cost.
http://pavandba.com/2009/10/24/configuration-of-oracle-10g-data-guard/