RAC的强项在于解决单点故障和负载均衡,但RAC方案中数据只有一份,数据本身没有冗余,容易形成单点故障
而Data Guard是通过冗余数据来提供数据保护,通过日志同步机制保证冗余数据和主数据之间的同步
这种同步可以是实时、延时,同步或者异步
㈠ 日志发送
主库的日志由LGWR或ARCn负责从主库发送到其他一个或多个归档目标
不同的归档目标可以使用不同的方法,但是同一个目的地只能选用一种方法
归档目标由log_archive_dest指定
可以指定本地,也可以指向远端的Service Name
最常见的启动数据库归档模式就是设置了一个本地归档路径
① 使用ARCn进程 (延时)
缺省主库便是使用ARCn进程发送日志
⑴ 主库redo被LGWR写到online redo log
⑵ 当一组online redo log满,会发生log switch,触发本地归档
⑶ ARCn进程通过Net把已经归档的日志发送给备库的RFS进程
⑷ RFS进程把接收到的日志写到归档日志
⑸ 备库的MRP进程或LSP进程应用日志以同步数据
ARCn进程传递最大的问题是,主库只有在发生归档时才会发送日志到备库
online redo log中的redo entries可能会丢失
② LGWR sync方式 (Oracle 推荐使用)
什么是sync?
答:
LGWR必须等待写入online redo log操作和通过LNSn进程的网络传送都成功
主库的事务才能commit,这便是sync的含义所在
⑴ LGWR把redo entries写到online redo log的同时还要发送给本地的LNSn进程
再由LNSn把日志通过Net发送给远端归档目标
每个远程目的地对应一个LNS进程,多个LNS进程可以并行工作
⑵ 备库的RFS进程把接收到日志写入standby redo log
⑶ 主库的switch log也会触发备库对standby redo log的归档
然后触发备库的MRP或LSP进程应用日志
因为主库的redo是实时传送,于是备库可以使用两种方式恢复:
* 实时恢复:直接从standby redo logs取
* 归档恢复:需从archived log取
使用LGWR的sync方式时,建议带上参数net_timeout
log_archive_dest_2=\'service=stdby lgwr sync net_timeout=30\'
LGWR的sync方式最大的问题是,依赖于网络状况
③ LGWR async方式
⑴ LGWR只需写入noline redo log即可,不必等待LNSn的网络传送成功
⑵ LNSn异步把redo发送到备库,多个LNSn可以并发发送
⑶ 主库log switch也会触发备库对standby redo log的归档
然后触发MRP或LSP应用日志
async也只是归档恢复,无须指定net_timeout
㈡ 日志接收
RFS进程收到的日志写入standby redo log还是archived log
取决于主库的日志传送方式和备库的配置
当写到standby redo log时,主库log switch也会连带对standby redo log进行归档
备库配置说明:
① 如果配置了standby_archive_dest,则使用这个参数指定的目录
② 如果某个log_archive_dest_n明确定义valid_for=(standby_logfile,*),则使用这个目录
③ 如果数据库的compatible>=10.0,则选取一个log_archive_dest_n的值
④ 如果standby_archive_dest和log_archive_dest_n都没有指定,则使用
standby_archive_dest的缺省值:$ORACLE_HOME/dbs/arch
㈢ 日志应用
① physical standby使用media recovery技术应用
即:redo apply
⑴ 实时应用
这种方式必须指定standby redo log
每当日志被写入standby redo log时,便会触发恢复
好处在于可以减少数据库角色却换的时间
因为却换时间主要用在剩余日志内容的恢复上
⑵ 归档应用
这种方式在主库log switch时,会触发备库的归档操作
归档后会触发恢复,这也是缺省的恢复方式
② logical standby使用logminer技术应用
即:sql apply
physical standby启用实时应用:
alter database recover managed standby database using current logfile;
logical standby启用实时应用:
alter database start logical standby apply immediate;
查看是否使用了实时应用:
select recovery_mode from v$archive_dest_status;
㈣ 自动裂痕检测
当主库的某些日志没有成功发送到备库,这时就发生了archive gap
缺失的这些日志就是gap
DG能够自动检测并处理gap,不需DBA介入
这需要配置fal_client,fal_server(fetch archive log)
向谁要日志就是server,server不仅限于主库,可能是备库
所以,在DG中,主库、备库只是角色概念,并不固定在某个库上
当然,DBA可以介入
① 确认备库少了的日志
② 把缺失的日志从主库拷贝到备库
③ 在备库手工注册这些日志:
alter database register logfile \'logfilename\';
㈤ 三种数据保护的模式
① 最大保护(Maximum protection):
所有的事务在提交前至少一个standby数据库redo数据被同步写入
如果出现了什么故障导致standby数据库不可用的话,primary数据库会被shutdown
② 最高性能(Maximum performance):
事务可以随时提交,当前primary数据库的redo数据也需要至少写入一个standby数据库
③ 最高可用性(Maximum availability):
和maximum protection一样,至少一个standby数据库redo数据被同步写入
不过与之不同的是,如果出现故障导入无法同时写入standby数据库redo log,primary数据库并不会shutdown
㈥ 角色转换
一套DG环境只有两种角色:primary和standby
却换也只有两种:
switchover:无损却换,不会丢失数据
两个阶段:
① 主库却换成备库
② 备库却换成主库
failover:可能丢失数据,并且却换后,原主库就不属于该DG环境的一份子
而Data Guard是通过冗余数据来提供数据保护,通过日志同步机制保证冗余数据和主数据之间的同步
这种同步可以是实时、延时,同步或者异步
㈠ 日志发送
主库的日志由LGWR或ARCn负责从主库发送到其他一个或多个归档目标
不同的归档目标可以使用不同的方法,但是同一个目的地只能选用一种方法
归档目标由log_archive_dest指定
可以指定本地,也可以指向远端的Service Name
最常见的启动数据库归档模式就是设置了一个本地归档路径
① 使用ARCn进程 (延时)
缺省主库便是使用ARCn进程发送日志
⑴ 主库redo被LGWR写到online redo log
⑵ 当一组online redo log满,会发生log switch,触发本地归档
⑶ ARCn进程通过Net把已经归档的日志发送给备库的RFS进程
⑷ RFS进程把接收到的日志写到归档日志
⑸ 备库的MRP进程或LSP进程应用日志以同步数据
ARCn进程传递最大的问题是,主库只有在发生归档时才会发送日志到备库
online redo log中的redo entries可能会丢失
② LGWR sync方式 (Oracle 推荐使用)
什么是sync?
答:
LGWR必须等待写入online redo log操作和通过LNSn进程的网络传送都成功
主库的事务才能commit,这便是sync的含义所在
⑴ LGWR把redo entries写到online redo log的同时还要发送给本地的LNSn进程
再由LNSn把日志通过Net发送给远端归档目标
每个远程目的地对应一个LNS进程,多个LNS进程可以并行工作
⑵ 备库的RFS进程把接收到日志写入standby redo log
⑶ 主库的switch log也会触发备库对standby redo log的归档
然后触发备库的MRP或LSP进程应用日志
因为主库的redo是实时传送,于是备库可以使用两种方式恢复:
* 实时恢复:直接从standby redo logs取
* 归档恢复:需从archived log取
使用LGWR的sync方式时,建议带上参数net_timeout
log_archive_dest_2=\'service=stdby lgwr sync net_timeout=30\'
LGWR的sync方式最大的问题是,依赖于网络状况
③ LGWR async方式
⑴ LGWR只需写入noline redo log即可,不必等待LNSn的网络传送成功
⑵ LNSn异步把redo发送到备库,多个LNSn可以并发发送
⑶ 主库log switch也会触发备库对standby redo log的归档
然后触发MRP或LSP应用日志
async也只是归档恢复,无须指定net_timeout
㈡ 日志接收
RFS进程收到的日志写入standby redo log还是archived log
取决于主库的日志传送方式和备库的配置
当写到standby redo log时,主库log switch也会连带对standby redo log进行归档
备库配置说明:
① 如果配置了standby_archive_dest,则使用这个参数指定的目录
② 如果某个log_archive_dest_n明确定义valid_for=(standby_logfile,*),则使用这个目录
③ 如果数据库的compatible>=10.0,则选取一个log_archive_dest_n的值
④ 如果standby_archive_dest和log_archive_dest_n都没有指定,则使用
standby_archive_dest的缺省值:$ORACLE_HOME/dbs/arch
㈢ 日志应用
① physical standby使用media recovery技术应用
即:redo apply
⑴ 实时应用
这种方式必须指定standby redo log
每当日志被写入standby redo log时,便会触发恢复
好处在于可以减少数据库角色却换的时间
因为却换时间主要用在剩余日志内容的恢复上
⑵ 归档应用
这种方式在主库log switch时,会触发备库的归档操作
归档后会触发恢复,这也是缺省的恢复方式
② logical standby使用logminer技术应用
即:sql apply
physical standby启用实时应用:
alter database recover managed standby database using current logfile;
logical standby启用实时应用:
alter database start logical standby apply immediate;
查看是否使用了实时应用:
select recovery_mode from v$archive_dest_status;
㈣ 自动裂痕检测
当主库的某些日志没有成功发送到备库,这时就发生了archive gap
缺失的这些日志就是gap
DG能够自动检测并处理gap,不需DBA介入
这需要配置fal_client,fal_server(fetch archive log)
向谁要日志就是server,server不仅限于主库,可能是备库
所以,在DG中,主库、备库只是角色概念,并不固定在某个库上
当然,DBA可以介入
① 确认备库少了的日志
② 把缺失的日志从主库拷贝到备库
③ 在备库手工注册这些日志:
alter database register logfile \'logfilename\';
㈤ 三种数据保护的模式
① 最大保护(Maximum protection):
所有的事务在提交前至少一个standby数据库redo数据被同步写入
如果出现了什么故障导致standby数据库不可用的话,primary数据库会被shutdown
② 最高性能(Maximum performance):
事务可以随时提交,当前primary数据库的redo数据也需要至少写入一个standby数据库
不过这种写入可以是不同步的
这是一种缺省模式
③ 最高可用性(Maximum availability):
和maximum protection一样,至少一个standby数据库redo数据被同步写入
不过与之不同的是,如果出现故障导入无法同时写入standby数据库redo log,primary数据库并不会shutdown
而是自动转为最高性能模式,等standby数据库恢复正常之后,它又会再自动转换成最高可用性模式
它是一种狡猾的模式、平时以最大保护运行、一旦遇到故障、就自动却换为最大性能模式
这是很多人的选择、如果带宽足够(当然、现在的带宽很足的说)、强烈建议转换为这个模式
㈥ 角色转换
一套DG环境只有两种角色:primary和standby
却换也只有两种:
switchover:无损却换,不会丢失数据
两个阶段:
① 主库却换成备库
② 备库却换成主库
failover:可能丢失数据,并且却换后,原主库就不属于该DG环境的一份子
转载于:http://blog.itpub.net/26515977/viewspace-1207917/