链接：https://pan.baidu.com/s/1EwC8RsvkadPPJFTgMd7hQQ 

提取码：bksf 

 

Abstract

Oracle has introduced many new features in Oracle9i Data Guard to enhance Oracle8i standby database functionality.  This white paper covers how to implement Oracle9i Data Guard. An actual production Data Guard environment is presented, a bidirectional physical standby database configuration between two Linux Red Hat 7.1 servers running two separate databases.  However, the concepts presented apply to any platform.  Step-by-step procedures and actual configuration files demonstrate a working Data Guard implementation.[ For questions or issues regarding this material, please feel free to contact me at MichaelNew@earthlink.net.]

Specific Data Guard Environment Presented

The environment presented here is that from an implementation of Data Guard at a customer site.  It was a standard bidirectional Data Guard configuration built for two large mission-critical data warehouses on two separate Linux servers, as shown in Figure 1 below:

node1 node2

Primary database: PROD1 Primary database: PROD2

Standby database: PROD2 Standby database: PROD1

 

 

Figure 1: Standard bidirectional Data Guard configuration implemented.

 

The specifics of this implementation were to create a standby database on server node2 for an existing database, PROD1, on node1.  Similarly, to create a standby database on server node1 for a separate existing database, PROD2, on node2.  Because one implementation was the mirror image of the other, the generic steps were the same to build each standby.  The first standby built was the PROD1 standby on node2.  Then the PROD2 standby was built on node1.  Whenever specific commands or values are indicated here, they are for the PROD1 standby implementation on node2.

Each server was running a separate  instance of Oracle 9.2.0.1.0 configured for dedicated server on a Red Hat Linux 7.1 platform.  Each server was a Dell Poweredge 2550 with two 1000Mhz P3 processors and 4GB RAM.  The two servers were located on a WAN, and the network provided high throughput between the servers.  These servers were located in different geographical locations, thereby providing disaster recovery.  The primary database on one server had its standby database on the other server to make efficient use of each system with no idle hardware.  If either primary database became incapacitated, the physical standby database at the other location could be failed over to the primary role so processing could continue.

Overview Of Data Guard Concepts

Data Guard is software that maintains a standby database, or real-time copy of a primary database.  Data Guard is an excellent High Availability (HA) solution, and can be used for Disaster Recovery (DR) when the standby site is in a different geographical location than the primary site.  When the sites are identical, and the physical location of the production database is transparent to the user, the production and standby roles can easily switch between sites for many different types of unplanned or planned outages.[ Much of the material in this section is taken from Oracle9i Data Guard Concepts and Administration.]

Oracle Data Guard manages the two databases by providing remote archiving, managed recovery, switchover and failover features.  A secondary site that is identical to the primary site allows predictable performance and response time after failing over or switching over from the primary site.  An identical secondary site also allows for identical procedures, processes, and management between sites.  The secondary site is leveraged for all unplanned outages not resolved automatically or quickly on the primary site, and for many planned outages when maintenance is required on the primary site.

Data Guard with a physical standby database provides benefits, which fall into two broad classes:

Availability and disaster protection - provides protection from human errors, data failures, and from physical corruptions due to device failure. Provides switchover operations for primary site maintenance, and different database protection modes to minimize or create no data loss environments.  A specified delay of redo application at the standby database can be configured to ensure that a logical corruption or error such as dropping a table will be detected before the change is applied to the standby database.  Using the standby database, most database failures are resolved faster than by using on-disk backups since the amount of database recovery is dramatically reduced.  The standby database can be geographically separate from the primary database, a feature that provides Disaster Recovery against local catastrophic events.  Data Guard, therefore, provides a higher degree of availability than other HA methods that do not employ a second database, such as Real Application Clusters (RAC) or Highly Available Disk Arrays (HADA).

Manageability - provides a framework for remote archiving services and managed standby recovery, contains role management services such as switchover and failover, and allows offloading of backups and read-only activities from the production database.  The Data Guard broker provides the Data Guard Manager GUI and command-line interface to automate the management and monitoring of the Data Guard environment. 

Operational Requirements

Below are operational requirements for maintaining a standby database. Some of these requirements are more lax then Data Guard best practices would dictate (see Best Practices For Data Guard Configurations below):

The primary database must run in ARCHIVELOG mode.

The primary and standby databases must be the same database release. To use the Data Guard broker, the database server must be licensed for Oracle9i Enterprise Edition or Personal Edition. The operating system on the primary and standby sites must be the same, but the operating system release does not need to be the same. The hardware and operating system architecture on the primary and standby locations must be the same. For example, a Data Guard configuration with a primary database on a 32-bit Linux system must be configured with a standby database on a 32-bit Linux system.

The primary database can be a single instance database or a multi-instance Real Application Clusters database. The standby databases can be single instance databases or multi-instance Real Application Clusters databases, and these standby databases can be a mix of both physical and logical types.

If using a physical standby database, log transport services must be configured to specify a dedicated server process rather than a shared server (dispatcher) process in managed recovery mode. Although the read-only mode allows a shared server process, you must have a dedicated server once you open the database again in managed recovery mode.[ Oracle9i Data Guard Concepts and Administration, Section 5.1 Introduction to Log Transport Services. This requirement is easy to miss, only found referenced in a Note in this section.]

The hardware (for example, the number of CPUs, memory size, storage configuration) can be different between the primary and standby systems.