Normal switchover of Oracle Data Guard physical standby Database

Oracle Data Guard is used to protect Oracle Data and provides the highest level of Data protection and availability while maintaining the best performance for Oracle databases. Its operation follows the principle of transmitting redo data and then applying redo data.

It is divided into logical standby database (logical standby) and physical standby database (physical standby), which are used in different application scenarios respectively.

In the Oracle 10g physical standby database, you can use the normal switchover operation to switch the standby database to the primary database, and then switch back to the standby database.

Its application scenarios include database disaster recovery verification, seamless switchover of Database hardware maintenance, and data migration of database for server.

Here is a case by the way. In the previous data migration work, I used database backup and remote recovery to achieve remote migration of large databases, and the switching time would be several minutes. However, this solution has one disadvantage. For example, if another fault occurs in the new environment after the switchover, such as network unavailability, it is impossible to migrate back because the new environment database has already written data.

However, if you use data gauard for data migration, you can quickly switch back if the new environment is unavailable.

Next I will introduce the implementation and switching PROCESS OF THE PHYSICAL standby database.

Part 1: create a physical standby database to implement the physical standby mode
Modify the initialization parameters on the master database. The protection level adopts the default value, that is, the maximum performance. The redo log transmission mode adopts ARCH. Here we will perform data migration. If it is a disaster recovery requirement, we need to set it to the maximum availability or protection. The method for transmitting redo logs is lgwr sync affrem.

Alter system set log_archive_config = 'dg _ config = (mikidb, mikidg) 'scope = memory;

Alter system set log_archive_dest_2 = 'service = MIKIDB_STANDBY arch async affrem VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = MIKIDG 'scope = memory;

Add a tnsname to the tnsnames. ora file of the master database, that is, mikidb_standby specified in log_archive_dest_2.

Mikidb_STANDBY =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.64.1) (PORT = 1521 ))

)

(CONNECT_DATA =

(SID = mikidb)

)

)

Modify the initialization parameters on the slave database and set db_unique_name, fal_client, and fal_server.

As follows:

*. Db_unique_name = 'mikidg'

*. Fal_client = 'mikidb _ standby'

*. Fal_server = 'mikidb _ primary'

Fal is used to detect the interval between archiving log files between the master database and the slave database. It is called fetch archive log.

In addition, the archive path is also set to save the archive log files transmitted from the master database.

*. Log_archive_config = 'dg _ config = (mikidb, mikidg )'

*. Log_archive_dest_1 = 'location = + VG1/valid_for = (all_logfiles, all_roles) db_unique_name = mikidg'

In the tnsnames. ora file of the slave database, you must add two tnsname values, namely, the values of fal_client and fal_server, which are mikidb_standby and mikidb_primary.

Mikidb_STANDBY =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.64.1) (PORT = 1521 ))

)

(CONNECT_DATA =

(SID = mikidb)

)

)

Mikidb_primary =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 192.168.89.1) (PORT = 1521 ))

)

(CONNECT_DATA =

(SID = mikidb)

)

)

After the initialization parameters of the master and slave databases are set, we can restore the backup of the master database on the slave database. To restore the use of control files, the master database must be specially generated for the backup database application of data guard.

1 2 Next Page