Quick Configuration Guide for Oracle11gDataGuard physical standby Database

I recently conducted a physical standby Database Configuration experiment for Oracle10g and 11g, and found that mongouard is actually very easy, but lacks good documentation. I started the experiment by referring to the official documentation and thought it

I recently conducted a physical standby Database Configuration experiment for Oracle 10g and 11g, and found that Data Guard is actually very easy, but there is a lack of good documentation. I started the experiment by referring to the official documentation and thought it

Origin
I recently conducted a physical standby Database Configuration experiment for Oracle 10g and 11g, and found that Data Guard is actually very easy, but there is a lack of good documentation. I started my experiment by referring to the official document and thought it was not very clear.

Google has two pdf documents, and I think they are much better than the official documents. Translation may be useful to some friends. At the same time, I am more familiar with these two documents. I haven't translated English for a long time. You can practice it by the way.

Original document (documents ):

Configure upload uard 11gR2 Physical Standby Part 1
Configure upload uard 11gR2 Physical Standby Part 2

Part 1
Introduction
Data Guard is a feature of Oracle databases that provides database redundancy. Redundancy is achieved by creating a standby (physical copy) database. The standby database should be in different geographical locations or on different disks. The slave database maintains data synchronization through changes in the application master database. The standby database can use the redo log application (physical standby database) or SQL application synchronization (logical standby database ).

This article aims to show that the configuration of Data Guard is not complex and requires no special skills or training to be built. It will quickly show readers how to build a physical standby database. My goal is to help you quickly build a physical standby database that runs normally even if you are new to Data Guard for the first time or worry about how difficult it will be to configure.

Why use Data Guard?
Each type of Oracle High Availability tool has its own purpose. Data Guard is used for the following reasons:

Database Redundancy
Rapid fault recovery
After the fault occurs, the client can automatically reconnect
Run backup in the slave Database
Good average fault repair time
Not Complex
System Environment
After writing this article, I used DBCA to create a new database JED and re-run the configuration steps in this article to confirm that it is applicable to a basic Oracle 11g Database. The master database is called JED and runs on a server called dev-db1. The slave database is called JED2 and runs on a server called dev-db2.

Basic Prerequisites
There are some basic settings that any production database should have. One of them is the archive mode. For production databases, this should be an obvious requirement. If your production database does not apply the archive mode, you either need to start reading the book immediately, or you have to have a very good reason. I'm not sure who can find a reason, but there are exceptions to any criterion.

How to change your database to archive mode:

SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
SQL> archive log list;

Master database preparation
First, to make the standby database identical to the primary database, it must receive redo logs from the primary database. In Oracle databases, a user can use a specified operation to generate no logs (for example, using the NOLOGGING Statement ). This is a problem for the slave database. You must confirm that the user cannot instruct the database not to generate redo logs. This requires the forced log feature of the database to be enabled. You can use the following method to enable the Service:

SQL> alter database force logging;
SQL> select name, force_logging from v $ database;

You should see the force_logging column as YES.

Second, you need to confirm that when the master database adds or deletes data files, these files will also be added or deleted in the slave database. To enable this function, follow these steps:

SQL> alter system set standby_file_management = 'auto ';

Again, we need to confirm that the library has a Standby Log file (Standby Log Files ). The slave database uses the backup log file to save the redo logs received from the master database. There are two reasons for the backup log file to be created on the master database: one is that the master database may be converted to the slave database, and the other is that if the backup log is created on the master database, the slave database will be automatically created. Backup logs should be as large as online logs, and the number of groups should be at least the same as online logs, or more. I like to give the backup log a number that is different from the online log range. For example, the online log group is 1 to 6, and the backup log is 11 to 16. The method for creating backup logs is as follows:

SQL> alter database add standby logfile group 11 ('/oradata/JED/g11m01. sdo','/oradata/JED/g11m02. sdo') size 50 M;

If you do not use SSL for redo log transfer verification (generally not), you need to use the password file for verification. You must create a password file and set the REMOTE_LOGIN_PASSWORDFILE parameter to EXCLUSIVE or SHARED. Generally, the database has a password file by default, and this parameter is EXECUSIVE by default. Check the two items first. If they are not the default items, set them as follows:

SQL> alter system set remote_login_passwordfile = exclusive scope = spfile;
OS> orapwd password =

Finally, check whether the db_unique_name parameter of the database is set. If not, use alter system for settings:

SQL> show paramter db_unique_name;
SQL> alter system set db_unique_name = some_name scope = spfile;

Flash back database
I strongly recommend that you enable the database flashback function. Flash back allows you to restore the database to a previous time point. This function is very useful when a Failover occurs. It allows you to flash the old master database back to the fault and convert it into a slave database. If the flash back function is not enabled, you must recreate the slave database, which means you need to copy the data file again. In addition to this benefit, flash back can also prevent you from restoring data from backup in some cases.

To enable the Flash Recovery function, you must first configure the Flash/Fast Recovery Area. The method is as follows:

SQL> alter system set db_recovery_file_dest = '& Quick Recovery partition directory or ASM disk name ';
SQL> alter system set db_recovery_file_dest_size = 400G;

After the quick recovery area is configured, you can enable the flashback log function:

SQL> alter database flashback on;
SQL> select flashback_on from v $ database;

The value of FLASHBACK_ON should be YES. If you encounter an ORA-01153 error, it must be performed in the slave database. You need to cancel the redo log application, enable the flashback log, and then re-enable the log application.

Enable the flash back log in the master database, and do not enable the synchronization of the slave database. You must manually enable the flashback log on both the master and slave databases. If flash back logs are not enabled, you need to create a slave database completely when a Failover occurs.

SQL * NET Configuration
Before creating a slave database, make sure that the databases on the two servers can communicate with each other. If we want to use the RMAN duplicate from active database command to create the slave database. We need to configure the listener and TNS name. You can manually configure or use the network configuration tool (netca ). I prefer manual configuration, because I am a veteran and these configuration files are not complex,

First, configure the listener for the master and slave databases. Although the database automatically registers the listener, if you want to use the RMAN duplicate command to create a slave database, the slave database must first be In the NOMOUNT state. In the NOMOUNT status, the database instance does not automatically register the listener. You must configure a static listener. In addition, you must note that the database in NOMOUNT state must be connected using the dedicated server.

The TNS name files on the two servers must be configured so that the master and slave databases can find the target database using the Service name (Service Names) in the LOG_ARCHIVE_DEST_N and FAL_SERVER parameters (these parameters will be described later. The specific configuration should be similar to the following example.

Listening configuration for the master database (dev-db1: