一个Data Guard 配置由一个生产库和一个或者多个standby数据库组成,在Data Guard配置中,主库和备库都既可以是rac环境,也可以是单机环境。

这篇文章主要介绍dataguard的一些基本知识

dataguard的分类、dataguard的服务类型、dataguard的保护模式


1.Dataguard中的备库分为物理备库和逻辑备库及快照备库

备库是主库的一致性拷贝,使用一个主库的备份可以创建多到30个备库,将其加入到dataguard环境中,创建成功后,dataguard通过自动应用从主库传送到备库的redo数据维护每个备库。

1.1   物理备库(Physical standby database)

物理备库提供物理上和主数据库相同的拷贝,磁盘数据库结构和主库是相同的,物理备库是块到块的拷贝,一个物理备库通过应用从主库收到的redo数据保持和主库的同步,称为日志应用(redo apply),11g的dataguard在应用日志的时候是可以打开的,10g是不允许的。11g的这种特性称为active data guard。

1.2   逻辑备库 (Logical standby database)

逻辑备库包含和主库相同的逻辑信息,物理结构和数据结构可以是不同的,逻辑备库把从主库收到的redo转换为sql语句,然后在备库上执行sql语句,称为sql应用(sql apply)。逻辑备库除了能应用于灾难恢复,还允许用户查询逻辑备库和通过逻辑备库生成报表,用于其他目的,使用逻辑备库能升级database软件,在无停机的情况下打补丁等操作。

1.3   快照备库 (Snapshot Standby Database)

快照备库是11g中出现的,类似物理备库和逻辑备库一样,快照备库从主库接收redo数据,和物理或逻辑备库不同的是,快照备库只接收而不应用接收到的redo数据。直至快照备库转换为物理备库,之后先扔掉任何对快照备库的更新,然后应用接收到的redo数据。快照数据库最好用在要求临时的,可更新的物理备库快照场景。

典型的data guard配置如图所示,来自oracle concept

wKiom1YCaUrTFbUvAAEdLBVn9vE036.jpg

2. dataguard的服务类型 (Data GuardServices)

  日志传输服务(Redo Transport Services)

  日志应用服务(Apply Services)

  角色转换     (Role Transitions)


2.1日志传送服务管理从生产库传送redo数据到一个或多个归档目录。日志传输服务完成以下工作:

   2.1.1在配置中从主库传输redo数据到备库

   2.1.2在网络失败后,管理备库缺失的archivelog,自动解决缺失

   2.1.3自动扫描在备库中错误的或损坏的redo,自动从主库或其他备库重新获得并替换损坏的archive log。

log_archive_dest_n初始化参数用来确定本地的redo和远程归档redo的位置。log_archive_dest_n中详细参数解析

2.2日志应用服务在备库中应用redo数据,维护和备库主库之间的同步,redo数据默认从归档redo日志中应用,若启用了实时应用,则直接从standby redo日志中应用;对于非实时应用redo,当主库日志发生切换时,备库才会应用从主库传输来的redo日志。默认情况下,对于非实时应用,应用服务会等待备库redo日志被归档才会应用归档redo日志,实时应用允许应用服务应用当前正在填充的备库redo日志中的redo数据。

日志应用工作方式:redo apply和sql apply

物理备库和逻辑备库主要的区别就是日志应用的工作方式不同,物理备库使用redo apply,逻辑备库使用sql apply,类似MySQL 的主从的方式。

Redo apply在物理备库上使用常规的数据库恢复技术,也就是介质恢复,来应用redo中的数据。如图所示:

wKioL1YCaoOxZvc9AAHKF1JSHmw232.jpg

Sql apply 在逻辑备库上使用这种方式,首先将接收到的redo数据转换为sql语句,然后在逻辑备库中执行生成的sql语句,之后在备库中应用。使用的是logminer技术。如图

wKiom1YCanKDbydeAAIAVoLZpZU559.jpg

日志应用服务配置

standby redolog

实时应用要求standby数据库必须有standby redo日志,lgwr同步和异步传输模式要求传输目的地配置standby redo日志,standby redo日志用于存储从一个主库接收到的redo日志,standby redo日志在结构上和联机redo日志是相同的,也使用创建和管理联机redo日志相同的sql来创建和管理standbyredo日志。

Standby数据库使用RFS前台进程接收传送过来的redo日志,将其写到当前的standby redo日志组,当源数据库发生了日志切换,传入的redo将写到下一个standby redo日志组中,之前的standby 日志通过ARCn前台进程被归档。在源数据库,进程顺序地填充和归档redo日志组,这种方式呗镜像到每个redo传输目的地,在standby数据库以相同的顺序填充和归档standby redo日志组。

每个standby redo日志的大小必须至少和redo源数据库的redo日志组中最大的redo日志一样大,推荐传输目的地的standby redo日志和源主库的redo日志中的所有日志相同大。

对于standby 数据库的每个redo线程,standby redo日志至少比在redo源主库的redo日志多一个redo日志组,在源主库,查询v$log视图确定源主库redo日志组的个数,对于rac,查询v$thread视图确定源主库redo的线程数,对每个线程使用的standby redo日志进行配置。


操作过程:

selectgroup#,bytes from v$Log ;   主库

selectgroup#,bytes from v$standby_log ; 备库

Oracle推荐在dataguard中的主数据库也创建standby redo日志,这样当switchover到备库角色也可以立即实现实时接收redo数据

alterdatabase add standby logfile 创建或添加standby redo日志,如果standby redo日志租不活动或者redo传输用于解决缺失,那么standby数据库接收到的redo数据被直接写到一个归档redo日志。


实时应用redo 数据

若启用实时应用特性,应用服务能在不等待当前standby redo数据被归档的情况下,应用接收到的redo数据,这样使得switchover和failover的速度更快,因为standby redo日志中的数据在failover或者switchover开始的时候已经被应用到standby 数据库,减少了切换需要花费的时间。

物理备库开启实时引用

alterdatabase recover managed standby database using curren logfile dixconnect fromsession ;

逻辑备库开启实时引用

alterdatabase start logical standby apply immediate ;

启用实时应用要求备库配置由standby redo日志,并且开启了归档

注:对于日志传输,可以将其划分为实时传输(同步、异步)和切换时传输(默认传输方式),实时传输与实时应用之间没有关系,实时传输只是和dataguard保护模式有关。

延迟应用redo

在一定程度上保护应用程序对主库的破坏及减少误操作对standby数据库的影响。当设置delay间隔之后,不能延迟传输redo数据到standby数据库,只是会延迟应用redo日志,从standby目的地完成归档开始计算延迟时间。延迟结束之后开始应用归档日志。

指定延迟时间:

在主库和备库通过指定log_archive_dest_n初始化参数delay=<minutes>设置延迟时间,默认情况是没有延迟时间的,若指定了delay参数但是没有指定值,默认是30分钟。

取消指定时间

物理备库

alterdatabase recover managed standby database nodelay ;

逻辑备库

alterdatabase start logical standby apply nodelay;

执行以上的命令,在时间间隔到之前应用服务立即开始应用归档redo日志文件到备库。

2.3使用switch over或failover操作改变数据库角色,将备库转换成主库或将主库转换为备库。

Switchover是主库个一个备库的转换,可以确保没有数据丢失,是在有计划的典型操作。在switchover期间,主库角色转变为备库,备库转换为主库,在主库inactive时,failover可以将备库转换为主库角色,failover可能会导致数据丢失,failover只有在主数据库启动失败的情况下才使用。


3.dataguard的保护模式

Oracle提供三种保护模式满足不同级别的系统。最大保护、最大性能、最高可用。三种保护模式都要求使用特定的redo传送选项发送redo数据到至少一个备库

   3.1最大保护

如果主库失败,最大保护模式可以确保没有数据丢失,事务在完成提交之前,事务恢复需要的redo数据必须写到主库的联机redo日志和至少一个同步的备库的standby redo log,若主库不能写redo数据到至少一个备库,为了确保数据不会丢失,主库会被关闭,正是应了最大保护模式这句话。

使用最大保护模式必须符合的条件:

a.主库在log_archive_dest_n的参数设置中必须使用到lgwr sync affirm属性来归档到备库

b.备库必须配置standby redo log

c.至少有一个备库是可用的

采用最大保护模式的主库,不能使用shutdown immediate对唯一的standby数据库执行关闭操作。因为会导致主库关闭

   3.2最大性能

是默认的保护模式,提供在不影响主库性能的情况下的最高级别的数据库保护模式,主库的用户事务一旦被写入本地联机redo中,就被允许提交,不需要立刻写到至少一个备库中,主库只要使用arch 或lgwr async属性对远程的备库进行归档即可,redo数据也写到一个或多个备库,但是对于事务提交是异步完成的,因此通过延迟写redo数据到备库不会影响主库的性能,这种保护模式提供您比最高可用模式较少的保护,但是能最低程度的影响主库的性能

   3.3最高可用

采用个最大保护模式同样的方式,确保redo日志被完全写入本地数据库和至少一个备库的standby redo log中,才会给用于返回提交完成的信息,若因为某些原因导致备库不可用,主库不能讲redo写入到备库的standby redo 中,此时主库并不会关闭,主库将暂时将保护模式降为最大性能模式,并且继续进行工作,一旦备库恢复正常,主库的缺失消除方案会启动,归档redo日志的缺失部分会被填满,当主库下一个日志打开的时候,主库中的保护模式又会上升为最高可用。采用最高可用必须满足的条件:

a.主库在log_archive_dest_n初始化参数中需要使用lgwr sync affirm属性归档到备库

b.备库必须配置standby redo log

c.至少有一个备库处于可用状态