Oracle10g Data Guard (Standby) 理论与实践
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)