[Data Guard]Oracle10g Data Guard學習筆記（一）

1. Oracle Data Guard: Overview

Types of Standby Databases

Physical standby database block-for-block, redo apply

Logical standby database Shares the same schema definition, SQL apply

Types of Services

Redo transport services, Log apply services, Role-management services

Role Transitions

Switchover

Failover

Data Protection Modes

Maximum protection：commit完成前保證redo已被寫入主資料庫和至少一個備資料庫，備機若異常不能傳輸redo則主庫自動下掉

Maximum availability：備機正常情況下同最大保護模式，異常情況下同最大效能模式

Maximum performance：redo非同步傳輸，不影響主資料庫效能

2. Understanding the Oracle Data Guard Architecture

Data Guard Operational Requirements: Hardware and Operating System

硬體配置可不同，作業系統版本可不同，作業系統和平臺必須一致。如主備資料庫在同一伺服器，必須保持作業系統支援。

Data Guard Operational Requirements: Oracle Database Software

資料庫版本一致，具有 sysdba許可權，主備資料庫有各自的控制檔案，主資料庫開啟歸檔，enable forcing logging，如使用ASM或OMF，則主備同時配置。

Primary Database Flow(process)

LGWR：同步方式下直接與RFS互動並等待確認，非同步方式下直接提一個網路請求給LNSn

ARCn：也可與RFS互動進行redo的傳輸，同時對主備間的gap進行檢查和處理

FAL：提供一種client/server的機制來處理主備間的gap，只要需要時啟動程式。

Standby Database Flow(process)

RFS：負責接收redo，並將其寫如standby redo log或直接寫如archive log。與ARCn或LNSn一一對應。

ARCn：負責將standby redo log歸檔

MRP：負責redo apply，只用與physical standby。使用alter database recover managed standby database則使用當前程式進行recovery。加上disconnect from session則起MRP後臺程式。

LSP：對logical standby的SQL apply操作進行控制

三種必須使用Standby Redo Logs的情況：

The maximum protection and maximum availability levels of data protection

Real-time apply

Cascaded redo log destinations

SQL Apply Process: Architecture

• The reader process reads redo records from the archived redo log files.

• The preparer processes convert the block changes into table changes or logical change records

(LCRs). At this point, the LCRs do not represent any specific transactions.

• The builder process assembles completed transactions from the individual LCRs.

• The analyzer process examines the records, possibly eliminating transactions and identifying

dependencies between the different transactions.

• The coordinator process (LSP):

- Assigns transactions

- Monitors dependencies between transactions and coordinates scheduling

- Authorizes the commitment of changes to the logical standby database

• The applier process:

- Applies the LCRs to the database

- Asks the coordinator process to approve transactions with unresolved dependencies (the

transactions are scheduled appropriately so that the dependencies are resolved)

- Commits the transactions

Real-Time Apply

普通方式下使用archive log進行redo apply，real-time方式下使用standby redo log進行apply

Start Real-Time Apply

Physical standby:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Logical standby:

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

Setting the DB_UNIQUE_NAME Parameter

Data guard使用db_unique_name引數來識別資料庫，預設與db_name相同。使用EM配置DG時會自動為每個備庫配置一個唯一的db_unique_name。

Specifying Role-Based Destinations

可在log_archive_dest_n中配置valid項以使得資料庫在不同的角色下使用不同的歸檔路徑。

例如：LOG_ARCHIVE_DEST_2= location="/u01/app/oracle/oradata/orcldg2/arc",

valid_for=(STANDBY_LOGFILE,STANDBY_ROLE)

The RFS process writes to an archive redo log file if any of the following conditions are met:

• There are no standby redo logs.

• It cannot find the same size standby redo log as the incoming online redo log file.

• All of the standby redo logs of the correct size have not yet been archived.

Standby Database Modes

physical standby: redo apply/open read-only

logical standby: open read/write

[@more@]