Oracle10g Data Guard (Standby) 理论与实践 2

Oracle10g Data Guard (Standby) 理论与实践 

简单summary : 

A. 日志发送 :

ARCH SYNC -- 将PRI DB上的归档通过RFS传输给Standby的归档或Standby Redo Log(如果有)。

LGWR SYNC -- LGWR提交redo数据到LNSn，LNSn启动网络传输，standby数据库的RFS将接收到
             的redo数据写入standby redo log

LGWR SYNC -- LGWR写数据到online redo log，LNSn进程访问online redo log并传输数据到
             远程standby的RFS

B.

  the log writer process writes to the local online redo log file,
while  LNSn processes asynchronously transmit the redo to remote destinations.
 
The LGWR process continues processing the next request without waiting for
the LNS network I/O to complete.

the LGWR submits the redo data to one or more network server (LNSn) processes, which then initiate the network I/O in

parallel to multiple remote destinations.

Transactions are not committed on
 the primary database until the redo data necessary to recover the transaction is received by all LGWR SYNC

destinations.

 

On the standby system, the remote file server (RFS) receives redo data over the network from the LGWR process and

writes the redo data to the standby redo log files.

 

 

 

1. ARCH网络传输模式

Primary DB中一旦ARC0完成redo log的归档，ARC1进程即开始传输该归档到Standby库
指定的路径，在Standby上的RFS(Remote File Server) 进程轮流将redo数据写入standby
redo log,  再由standby上的ARCn进程将其写入Standby归档日志，然后通过redo应用
(物理备库) 或 SQL应用(逻辑备库)将数据应用到Standby库 (物理备库采用MRP进程-
Media Recovery process , 逻辑备库采用LSP-Logical Standby Process) . 

备注： 如果是Real Time Apply,  直接从Standby redo log通过MRP或LSP应用到standby库。
如果不存在Standby redo log文件，那么ARC1进程通过Net将归档发送给Standby的RFS, RFS
把接收到的日志写入归档日志，由MRP进程对归档进行应用。 

 

 

2. LGWR 网络传输模式
Standby数据库的LGWR进程会先选择一个standby redo log文件映射primary数据库当前
redo log的sequence(以及文件大小)，一旦primary数据库有redo数据产生，会以同步(SYNC)
或非同步(ASYNC)方式传输到standby数据库。

SYNC属性(默认是SYNC):  primary数据库任何时候产生redo操作都会同步触发网络I/O，
并且等到网络I/O全部完成才会继续下面的提交； 即  LGWR必须等待写入本地日志文件
操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交 。
 
ASYNC属性 : LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功
写入日志文件就可以，不必等待LNSn进程的网络传送成功。

如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参
数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR 进程会抛出错误。
示例如下：
alter system set log_archive_dest_2 = 'SERVICE=ST LGWR  SYNC NET_TIMEOUT=30'scope=both;

 

 

3. LGWR 网络传输工作流程

在primary数据库，LGWR提交redo数据到LNSn  (LGWR Network Server process, 存在的
目的就是减轻LGWR进程的负担)进程(n>0)，LNSn启动网络传输(传输给standby上的RFS)。
standby的RFS(Remote File Server)将接收到的redo数据写入standby redo log。
一旦primary数据库执行日志切换，就会级联触发standby的ARCn将standby redo写入
归档，然后通过redo应用(MRP进程)或sql应用(LSP进程)读取归档文件将数据应用至
standby数据库。默认情况下，LGWR网络传输模式使用的是这种读取归档文件应用的
方式，即

SQL> alter database recover managed standby database disconnect from session;

这种不是实时应用的方式，如果需要修改为Real Time Apply ,需要：
SQL> alter database recover managed standby database using current
 logfile disconnect from session ;

如果启用了实时应用的话，MRP/LSP会直接读取standby redo log并应用到standby
数据库，无须再等待归档 。

 

4. Redo 接收 .
Standby Database 的RFS（Remote File Server）进程接收到日志后，就把日志写
到Standby Redo Log或者Archived Log文件中，具体写入哪个文件，取决于Primary
的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中，
则当Primary Database发生日志切换时，也会触发Standby Database上的Standby
Redo Log 的日志切换，并把这个Standby Redo Log 归档。 如果是写到Archived
Log，那么这个动作本身也可以看作是个归档操作。

 

5. Redo Apply .
根据Redo Apply发生的时间可以分成两种：
 
一种是实时应用（Real-Time Apply）， 这种方式必须Standby Redo Log，每当日志被写
入Standby RedoLog时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换
（Switchover 或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。
 
另一种是归档时应用，这种方式在Primary Database发生日志切换，触发Standby
Database 归档操作，归档完成后触发恢复。 这也是默认的恢复方式。
 
归档时应用：
Alter database recover managed standby database disconnect from session ;
 
Real-Time应用(物理)：
Alter database recover managed standby database using current logfile
 disconnect from session ;
Real-Time应用(逻辑)：
Alter database start logical standby apply immediate;

 

注意： 日志发送和应用是两回事 。

LGWR SYNC 日志传送方式确定的情况下， 日志实时应用与非实时应用的区别: 根据
oracle文档上的图示，  不管是arch, lgwr sync, lgwr async 方式 ，  实时应用
就是通过standby redo log 直接传输给MRP 进程进行恢复 ，   非实时传输就是需
要Primary db的归档进程触发Standby上的归档进程对Standby redo log 进行归档，
然后standby 上的归档日志通过MRP进程恢复到Standby .  

 

 

5. 查看相关视图  .
查看是否使用Real-Time apply：
Select recovery_mode from v$archive_dest_status;
select process,status,thread#,sequence#,client_pid from v$managed_standby;
 

6. Primary DB及Standby上的相关进程
在Primary DB中，相关的主要进程有：
 
LGWR：写log进程, 用于将SGA中log buffer的内容写入redo log文件。
 
LNS(Logwriter Network Service)：用于读取LGWR进程flush的redo，并将其
传输到Standby。其存在的目的就是减轻LGWR进程的负担。
 
ARCH：依然是将已经写满的ORL文件进行归档。但是会有一个比较特殊的ARCH会
用于redo log gap的定位与恢复。

在Standby中，相关的进程有：
RFS（Remote File Server）：接收PDB发送的redo data，并将这些放入
network buffer中的内容写入standby redo log（SRL）。
ARCH：同Primary上的ARCH进程作用类似，为standby redo log文件产生相应的归档文件。
MRP（Managed Recovery Process）：用于协调介质恢复管理，唤起物理standby为
永久的恢复模式。它还负责将redo data从相应的SRLs或归档文件中读入到用于恢复的共享空间结构。
LSP（Logical Standby Process）：该进程主要是在逻辑standby中协调SQL Apply的。
       
PR0x（recovery server Process）：读取SRL或归档日志文件中的redo，并将其应用于SDB上。
 

 

7． 数据保护模式
 
Data Guard 允许定义3钟数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum
Availability）和 最大性能（Maximum Performance）。
 
 
 
a. 最大保护（Maximum Protection）
 
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被
写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少
在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障
导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。
 
使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC
，AFFIRM 方式归档到Standby Database.
 
最大保护：   
进程LGWR  
网络传输模式LGWR SYNC 
Standby Redo Log:   需要
磁盘写操作:  AFFIRM

 

 
b. 最高可用性（Maximum availability）
 
这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类
似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模
式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为
最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。
 
这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配
置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

最大可用 ：   
进程LGWR 
网络传输模式LGWR SYNC 
Standby Redo Log:   需要
磁盘写操作:   AFFIRM
 

 

 
c. 最高性能（Maximum performance）
 
缺省模式。 这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提
交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果
网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响
。这也是创建Standby数据库时，系统的默认保护模式。
 
这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。
最大性能：
进程LGWR/ARCH    
网络传输模式LGWR SYNC/LGWR ASYNC/ARCH SYNC
Standby Redo Log:  LGWR时需要， ARCH传输时建议有.
磁盘写操作:  NOAFFIRM

 

 

d. 修改数据保护模式步骤
 
1）关闭数据库，重启到Mount 状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。
2）修改模式：
语法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY |
PERFORMANCE};
如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
3) 打开数据库： alter database open;
4) 确认修改数据保护模式：
SQL>select protection_mode,protection_level from v$database;
 

 

注意： 日志发送， 日志应用及三种模式没有必然关系。 

 

 

 

 

 
8． 自动Archive GAP检测和解决
 
 
当Primary Database的某些日志没有成功发送到Standby Database， 这时候发生了归档裂
缝（Archive Gap）。
 
缺失的这些日志就是裂缝（Gap）。 Data Guard能够自动检测，解决归档裂缝，不需要DBA
的介入。这需要配置FAL_CLIENT， FAL_SERVER 这两个参数（FAL: Fetch Archive Log）。
这两个参数都是在Standby上设置的。

从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”日志的过程，
Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个
FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。
 
如：FAL_SERVER='PR1,ST1,ST2';
 
FAL_CLIENT和FAL_SERVER两个参数都是Tnsnames中設置的。 FAL_CLIENT 通过网络向
FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这
两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时，会携带
FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数
值也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向
FAL_CLIENT.
 
当然，除了自动地日志缺失解决，DBA 也可以手工解决。 具体操作步骤如下：
 
1） 查看是否有日志GAP：
SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
2） 如果有，则拷贝过来
3） 手工的注册这些日志：
SQL> ALTER DATABASE REGISTER LOGFILE '路径';

 

 

 

9. 11g dataguard设置例子

三节点的Production DB初始化参数 

*.db_name='wsjdell'
*.db_unique_name='wsjdell'

# 下面的 fal_client及fal_server只需要在standby上设置，这里设置是为了切换角色。
wsjdell1.fal_client='WSJDELL1'
wsjdell2.fal_client='WSJDELL2'
wsjdell3.fal_client='WSJDELL3'
*.fal_server='WSJDELLDG'

*.log_archive_config='DG_CONFIG=(wsjdell,wsjdelldg)'
*.log_archive_dest_1='LOCATION=+DATA mandatory alternate=log_archive_dest_3 noreopen VALID_FOR=

(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wsjdell'
*.log_archive_dest_2='SERVICE=wsjdelldg LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=wsjdelldg'

*.log_archive_dest_3='LOCATION=+INDX mandatory'
*.log_archive_dest_state_3='ALTERNATE'

 

 

Standby DB初始化参数 

*.db_file_name_convert='+data/wsjdell/datafile/','+data/wsjdell/datafile/','+indx/wsjdell/datafile/','+indx/wsjdell/d

atafile/'
*.db_name='wsjdell'

*.db_unique_name='wsjdelldg'

*.fal_client='wsjdelldg'
*.fal_server='wsjdell1','wsjdell2','wsjdell3'
*.log_archive_config='DG_CONFIG=(wsjdell,wsjdelldg)'
*.log_archive_dest_1='LOCATION=+DATA VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wsjdelldg'
*.log_archive_dest_2='SERVICE=wsjdell LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=wsjdell'
--备库中log_archive_dest_2可以不用设置，主要用于主库备库切换

*.log_archive_format='%t_%s_%r.arc'
*.log_file_name_convert='+data/wsjdell/onlinelog/','+data/wsjdell/onlinelog/','+indx/wsjdell/onlinelog/','+indx/wsjde

ll/onlinelog/'
*.standby_file_management='AUTO'

 

 

 

9． VALID_FOR

VALID_FOR=(redo_log_type, database_role). 
为指定角色设置日志文件的归档路径，主要目的是为了辅助一旦发生角色切换操作后数据库的正常运转。

例子：
*.log_archive_dest_1='LOCATION=+DATA mandatory alternate=log_archive_dest_3 noreopen VALID_FOR=

(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=wsjdell'

redo_log_type可设置为：  ONLINE_LOGFILE， STANDBY_LOGFILE， ALL_LOGFILES
database_role可设置为：  PRIMARY_ROLE， STANDBY_ROLE，ALL_ROLES 

注意valid_for参数是有默认值的，如果不设置的话，其默认值等同于：
valid_for=(ALL_LOGFILES,ALL_ROLES)
推荐主动设置该参数而不要使用默认值，某些情况下默认的参数值不一定合适

比如逻辑standby就不像物理standby，逻辑standby处于open模式，不仅有redo数据
而且还包含多种日志文件(online redologs,archived redologs以及standby redologs)。
多数情况下，逻辑standby生成的online redologs与standby redologs生成在相同的目录内。
因此，推荐你对每个*dest设置合适的valid_for属性。

 

 

10 .  DB_UNIQUE_NAME

  db_unique_name参数是解决在同一台计算机上存在多个相同的db_name的实例共存在而
增加的参数,  如果dataguard的主、备库安装在不同的计算机上，则不需要设置这个参数。

  如果安装到同一台计算机上，则需要设置，如果没有设置实例的这个参数，第一个实例
启动后，再启动第二个实例是将报lk文件无法锁定的错误,第二个实例将无法启动.

DB_UNIQUE_NAME在Dataguard会经常提及的，和DB_NAME不一样的作用，在DG里，要求物理DG
主从库都有一样的DB_NAME 。 这里是数据库的唯一名字。但是他们的DB_UNIQUE_NAME是不
一样的，用以进行不同的标示。

 

 

11 .  LOG_ARCHIVE_CONFIG 

log_archive_config初始化参数还包括几个属性，可以用來控制数据库的传输和接收，
SEND,NOSEND,RECEIVE,NORECEIVE：

SEND     允许数据库发送数据到远端
RECEIVE  则允许standby接收来自其它数据库的数据
NOSEND,NORECEIVE  自然就是禁止

 

12. REOPEN, MAX_FAILURE, ALTERNATE

例子：
LOG_ARCHIVE_DEST_1='LOCATION=E:\ora10g\oradata\jsspdg\ REOPEN=60 MAX_FAILURE=3'

使用REOPEN=seconds(默认=300)属性，在指定时间重复尝试向归档目的地进行归档
操作，如果该参数值设置为0，则一旦失败就不会再尝试重新连接并发送，直到下次
redo数据再被归档时会重新尝试，不过并不会归档到已经失败的归档目的地，而是
向替补的归档目的地发送。

alternate属性定义一个替补的归档目的地，所谓替补就是一旦主归档目的地因各
种原因无法使用，则临时向alternate属性中指定的路径写。

需要注意一点，reopen的属性会比alternate属性优先级要高，如果你指定reopen
属性的值>0， 则lgwr/arch会首先尝试向主归档目的地写入，直到达到最大重试次
数，如果仍然写入失败，才会向alternate属性指定的路径写。

*.log_archive_dest_3='LOCATION=+INDX mandatory'
*.log_archive_dest_state_3='ALTERNATE'

max_failure属性指定一个最大失败尝试次数，大家应该能够联想到reopen，没错
两者通常是应该配合使用，reopen指定失败后重新尝试的时间周期，max_failure则
控制失败尝试的次数

http://www.linuxidc.com/Linux/2011-03/33521.htm 
http://tech.it168.com/db/2008-02-26/200802261700804.shtml
 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-708047/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-708047/