Oracle10g Data Guard (Standby) 理论与实践

Oracle10g Data Guard (Standby) 理论与实践 

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

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;

 

 

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
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 Name。 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． VALID_FOR

VALID_FOR=(ALL_LOGFILES, ALL_ROLES)
 

http://tech.it168.com/db/2008-02-26/200802261700804_1.shtml

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

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