Oracle 11g DG Concepts and Processes ____oracle

Rac,data Gurad,stream is the three tools in the Oracle High-availability system, each of which can be used independently or in conjunction with each other. Their respective emphasis is different, the application scenario is also different.

RAC its strength lies in solving single point of failure and load balancing , so the RAC scheme is often used in the core system of 7*24, but the data in the RAC scheme is only one, although the storage failure can be avoided by mechanisms such as RAID, but the data itself is not redundant and easy to form a single point of failure.

Data Gurad through the redundant data to provide the protection , the information Gurad through the log synchronization mechanism guarantees the redundant data and the main data synchronization before, this kind of synchronization may be real-time, the delay, the synchronization, the asynchronous various forms. Data Gurad is often used in remote disaster-tolerant and small-business high-availability scenarios, although the performance pressures of primary databases can be spread by performing read-only queries on standby machines, but data gurad is by no means a performance solution.

Stream is data synchronization based on Oracle Advanced queue, provides multiple levels of flexible configuration , and Oracle provides rich API and other development support, Stream is more suitable for data sharing at the application level.

A Data Guard Architecture

The DG Architecture can be divided into 3 parts by function:

1 log send (Redo send)

2) Log receive (Redo receive)

3 Log application (Redo apply)

1. Log send (Redo send)

During the Primary database run, there will be a steady stream of redo logs that need to be sent to the Standy database. This send action can be done by the LGWR or arch process of primary database, different archive destinations can use different methods, but for a destination, only one method can be chosen. Choosing which process is a big difference between data protection and system availability.

1.1 Using the Arch process

1 Primary database constantly produces redo log, which is written to the online log by LGWR process.

2 when a group of online logs is full, log switching occurs and triggers a local archive where the local archive location is defined using the format log_archive_dest_1= ' Location=/path '.

such as: Alter system set log_archive_dest_1 = ' Location=/u01/arch ' Scope=both;

3 after the local archive is completed, the online logs can be overwritten and reused.

4 The ARCH process sends the archive log to the standby database RFS (Remote file Server) process through net.

5 The Standby database-side RFS process writes the received log to the archive log.

6) Standby Database-side MRP (Managed Recovery process) processes (Redo apply) or the LSP process (SQL apply) Apply these logs to the Standby database to synchronize data.

In arch mode, the Redo log (Standby redologs), which is not written to the standby, is stored directly into an archive file at the Standby end.

Description

The logical standby is received and converted to an SQL statement, and execution of the SQL statement on the standby database is implemented synchronously, which is called SQL Apply.

After the physical standby receives the redo data generated by the primary database, it realizes synchronization in the form of media recovery, which is also called Redo Apply.

Note: To create a logical standby database, you first create a physical standby database and then convert it to a logical standby database.

The biggest problem with the arch process delivery is that the Primary database sends logs to standby database only when an archive occurs. If the primary database abnormal downtime, the redo content in the online logs will be lost, so using the arch process can not avoid the problem of data loss, to avoid data loss, you must use the LGWR, and the use of LGWR Also divided into sync (synchronous) and async (asynchronous) two ways.

By default, the Primary database uses the arch process and the parameters are set as follows:

alter system set log_archive_dest_2 = ' service=st ' Scope=both;

1.2 Sync mode using LGWR process

1 Primary Database produces the redo log to write both the log file and the network. That is, the LGWR process writes the log to the local log file and sends it to the local LNSN process (LGWR network server processes), which is then LNSN (LGWR network server Process) processes send logs over the network to remote destinations, each remote destination corresponds to a LNS process, and multiple LNS processes work in parallel.

2 LGWR must wait to write local log file operations and network transfer through the LNSN process is successful, Primary database transactions can be submitted, which is the meaning of sync.

3 The RFS process of Standby database writes the received log to the Standby Redo log log.

4 log switching of Primary database also triggers log switching on the standby database, that is, standby database standby Redolog archive, and then triggers standby Database MRP or LSP process to restore archive logs.

Because the redo of the primary database is delivered in real time, there are two recovery methods available standby the database side:

Real-time recovery (real-time Apply): As long as RFS write the log standby Redo log will be immediately restored;

Archive recovery: Recovery is triggered after completing the standby Redolog archive.

The Primary database uses the arch process by default, which must be explicitly specified if the LGWR process is used. When using the Lgwr sync method, you can use the Net_timeout parameter, which is a second, which indicates that the LGWR process throws an error if the network send does not respond for much longer. Examples are as follows:

alter system set Log_archive_dest_2 = ' service=st lgwr SYNC net_timeout=30 ' Scope=both;

1.3 Async ways to use the LGWR process

The possible problem with using the Lgwr sync method is that if the log is sent to the standby database process fails, the LGWR process will complain. That is to say, the LGWR process of primary database relies on network conditions, which can sometimes be too harsh to use LGWR async. Its working mechanism is as follows:

1 Primary Database A section produces redo log, lgwr the log file and the local LNS process, but the LGWR process can only write successfully to log files, do not have to wait for the LNSN process network transfer successfully.

2 The LNSN process asynchronously sends the log contents to the standby Database. Multiple LNSN processes can be sent concurrently.

3 Primary database online Redo log after the log switch triggered archiving operation, but also triggered the standby database standby Redo log archive, and then trigger the MRP or LSP Process Recovery archive log.

Because the LGWR process does not wait for the response result of the LNSN process, net_timeout parameters are not required to configure the LGWR async mode. Examples are as follows:

alter system set Log_archive_dest_2 = ' service=st lgwr ASYNC ' Scope=both;

2. Log receive (Redo receive)

After the RFS (Remote File Server) process in Standby database receives the log, it writes the log to the Standby Redo log or archived log file, which file is written to. Depends on the primary log shipping mode and the location of the standby database. If you write to the standby Redo log file, the log switch of standby Redo log on the standby database is also triggered when log switching occurs on the primary database, and this standby Redo log is archived. If you write to archived Log, the action itself can also be considered an archive operation.

In a log receipt, you need to be aware of where the archive log will be placed:

1 if the Standby_archive_dest parameter is configured, the directory specified by the parameter is used.

2 If a log_archive_dest_n parameter explicitly defines the valid_for= (standby_logfile,*) option, the directory specified by this parameter is used.

3 Select any Log_archive_dest_n value if the compatible parameter of the database is greater than or equal to 10.0.

4 if the standby_archive_dest and Log_archive_dest_n parameters are not configured, using the default standby_archive_dest parameter value default value is $oracle_home/dbs/arc.

3. Log application (Redo apply)

Log application service is to replay the primary database log on the standby db to achieve data synchronization between the two databases. According to the different Standby database replay log mode, it can be divided into physical Standby (physical Standby) and logical Standby (Logical Standby).

Physical standby uses media Recovery technology to restore at the block level, which has no data type limitations and can guarantee two databases to be identical. The physical standby database can be restored only in Mount state, or open, but only read-only and cannot perform a restore operation when it is opened.

Logical Standby uses Logminer technology to restore the contents of the log to SQL statements, and then the SQL engine executes the statements, Logminer Standby does not support all data types, and can be in the view Dba_logstdby_ Unsupported data types are not supported, and if this data type is used, the database is not guaranteed to be exactly the same. The Logical standby database can be read and write while resuming.

The associated process of the standby database reads the received redo data (possibly from the standby-side archive or from standby redologs) and writes it to the standby database. How is the data generated after the save? Two ways: physical standby through redo application, logic standby through SQL application

Depending on the time that redo apply to occur, it can be divided into two types:

One is the real-time application (real-time apply), which must be standby Redo log, which triggers a recovery whenever the log is written to standby Redo log, and the benefit of using this approach is to reduce database switching (switchover or failover), because the switching time is mainly used in the recovery of the remaining logs.

The other is the application of archiving, this way in the primary database log switching, triggering the standby database archive operation, the completion of the archive triggered recovery. This is also the default recovery method.

If you are physical Standby, you can enable real-time using the following command:

Alter database recover managed standby database using current logfile;

If you are logical Standby, you can enable real-time using the following command:

Alter database start logical standby apply immediate;

See if using real-time apply:

Select Recovery_mode from V$archive_dest_status;

Sql> Set Wrap off
Sql> select Process,status,thread#,sequence#,client_pid from V$managed_standby;

PROCESS STATUS thread# sequence# client_pid
--------- ---------------------   ----------   -----------------------              ------------

ARCH CONNECTED 0 0 240