dataguard体系结构.docx
《dataguard体系结构.docx》由会员分享,可在线阅读,更多相关《dataguard体系结构.docx(40页珍藏版)》请在冰豆网上搜索。
dataguard体系结构
一、DataGuard总体结构总体目标
1、描述计划和非计划停机的不同因数
2、DataGuard的主要组件
3、物理以及逻辑DataGuard的异同
4、建立DataGuard的好处
5、在高可用环境下HA的用处
数据损失原因
1、硬件与系统故障
2、人为错误
3、计算机病毒
4、软件故障
5、自然灾难
具调查表明,目前一般情况下,数据损失的主要原因是硬件故障和人为的原因而不是自然灾害等。
系统当机
计划当机
1、系统维护:
硬件、操作系统升级
2、数据维护:
表的在线重定义或者是重建索引
非计划当机
1、系统失败:
断电、系统故障
2、人为错误:
误删除表
3、数据失败和灾难:
数据块损坏、地震
DataGuard
HA&DG
SwitchOver&FailOver
1、不会被自动调用,一般情况下通过调用SQL语句执行
2、Switchover
计划中角色转换
主要用于操作系统和硬件的维护
备库切换成主库,而主库切换成备库,在切换完成后,这个过程没有任何的数据丢失和损失。
3、failover
非计划中的角色转换
在紧急情况下使用
根据数据的保护模式的不同,只有少量的或者是很少的数据损失
备用数据库类型
1、物理备用数据库
基于数据块级别和主数据库一致。
通过应用日志(redoapply)与主库保持同步
在mountstandby阶段进行应用日志恢复,而同时也可以openreadonly提供报表查询。
2、逻辑备用数据库
与主库共享同样的模式定义
通过应用SQL(sqlapply)与主库保持一致
当从主库接受到日志后,逻辑备用数据库是通过logmnr将日志转换成sql,在逻辑备库的表中,表可以同时用于恢复,报表查询功能。
REDOAPPLY
物理备用数据库的redoapply主要构架如下:
一个主数据库,最多有九个同样的备用数据库,他们都是对主数据库一个同样的拷贝。
备用数据库的个数受log_archive_dest_n限制,其中一个是用于归档日志目录,另外几个可用于备用数据库。
主节点数据库是打开并且可读写的,而备用数据库要么处于恢复模式或者只读打开模式。
备用数据库自动的获取和应用从主库传送过来的归档日志,日志传输的时机为:
日志在主库产生的时候,日志在主库归档的时候。
当日志在主库产生的时候传输那么就需要在备库创建备用数据库日志文件。
在备库中使用标准的oracle恢复技术应用日志。
在计划停机中,可以切换主库到备用数据库。
当主节点down机时,可以失败切换到其他备用节点。
物理备用数据库可以用来作为对主数据库的备份。
SQLAPPLY
当日志传输到备用数据库时,它并不是立即应用日志,而是通过logmnr将日志文件转化成SQL语句,然后再在备库应用。
逻辑备用数据库可以以readwrite形式打开。
SQLApply引擎构架
物理备用数据库和逻辑备用数据库的最大的区别在于应用引擎,也就是所说logapplyservice。
在逻辑备用数据库环境下,如下进程参与了应用引擎工作。
LSP0:
该进程是一个协调进程,用于协调并行执行的miningprocess和applyprocess。
PX:
由lsp0进程同时产生两组px进程,一组用于挖掘从主节点传送过来的归档日志,将其转化为sql,另外一组PX进程用于应用这些日志到逻辑备用数据库。
需要主要的是挖掘和应用的两组进程是同时执行,并且由lsp0进程进行同步以维持数据库比较高的性能。
DGservice
DataGuard提供了三种类型的服务:
Logtransportservice:
控制从主库到多个备库节点的日志文件的自动传输。
Logapplyservice
控制何时、如何应用日志到备用数据库
Rolemanagementservices
一个数据库只能工作在两个互斥的任一角色下:
primary/standby。
Rolemanagementservice、logtransportservice,logapplyservice一起工作可以动态的改变数据库的运行角色。
改变角色时通常为switchover/failover。
数据保护模式
Oracle提供了三种数据库保护模式,我们可以根据成本,可用性,性能,事务保护等去配置何种模式。
最大保护
Maximumprotection:
最大保护模式是最高级别的数据保护模式,它在灾难恢复时可以零数据损失。
当工作在最大性能保护模式时,重做日志被同步传输到备用数据库。
而对事务而言,至少该事务在其中一个备用数据库节点被确认完成,该事务才能提交。
该种模式下一般至少需要两个备用数据库。
该种方式只对物理备用数据库有效。
最大可用性
Maxavailability
在正常情况下同最大保护模式。
但是当某一个备库网络有问题,那么该备库就临时与主库有数据分歧了。
而当该备库再次可用后,会自动同步相应的日志,这时也无数据损失。
该种模式可用于逻辑备用数据库和物理备用数据库。
最大性能
Maximumperformance
该种保护模式是数据库默认的保护模式,它提供最少的数据保护,但是提供最大的性能模式。
该种模式下的事务以及日志数据都是被异步的传输到备库。
可以通过lgwr或者arch进程进行传输。
事务并不会等待备库的确认就可以在主库直接完成。
如果备库某个节点不可用,对主库没有任何的影响,提供了主库的最大的可用性与最大性能。
当主节点down机后,可能会有部分事务在主节点已经完成,但是日志还没有传输到备库节点。
如果直接切换会有数据丢失的。
RAC&DG
相互补充,可以同时使用。
二、理解DataGuard构架DG整体构架
Oracledataguard为了灾难恢复和高可用性通过使用多个进程达到自动控制的目的。
对于物理备用数据库而言,备用联机日志是可选的。
除非备库运行在最大性能模式,该模式需要数据库运行在物理备用数据库模式,并且含有备用联机重做日志。
逻辑备用数据库并不使用备用联机重做日志。
LogTransportService
主节点上,日志传输服务主要使用如下几个进程:
1、LGWR
LGWR搜集事务日志,并且更新联机日志。
在同步模式下,LGWR直接将redo信息直接传送到备库中的RFS进程,主库在继续进行处理前需要等待备库的确认。
在非同步情况下,也是直接将日志信息传递到备库的RFS进程,但是不等待备库的确认信息主库进程可以继续运行处理。
2、ARCH
ARCHn或者是一个SQLsession执行了一个归档操作,为了恢复的需要,创建了一个联机日志的拷贝。
Archn进程可以在归档的同时,传递日志流到备库的RFS进程。
该进程还用于前瞻性检测和解决备库的日志不连续问题(GAP)。
3、FAL
Fetcharchivelog只有物理备库才有该进程。
FAL进程提供了一个client/server的机制,用来解决检测在主库产生的连续的归档日志,而在备库接受的归档日志不连续的问题。
该进程只有在需要的时候才会启动,而当工作完成后就关闭了,因此在正常情况下,该进程是无法看见的。
我们可以设置通过LGWR,ARCH进程去传递日志到备库,但是不能两个进程同时传送。
该进程是如何交互的呢?
fal_client,fal_server参数的。
LogApplyService
备库节点上,日志应用进程主要使用如下的进程。
1、RFS
Rfs进程主要用来接受从主库传送过来的日志信息。
对于物理备用数据库而言,RFS进程可以直接将日志写进备用重做日志,也可以直接将日志信息写到归档日志中。
为了使用备库重做日志,我们必须创建他们,一般和主库的联机日志大小以及组一样。
2、arch
只对物理备库,arch进程归档备库重做日志,这些日志以后将被MPR进程应用到备库。
3、MRP
Managedrecoveryprocess。
&
nbsp;该进程只针对物理备库。
该进程应用归档日志到备库。
如果我们使用SQL语句启用该进程ALTERDATABASERECOVERMANAGEDSTANDBYDATABASE,那么前台进程将会做恢复。
如果加上disconnect语句,那么恢复过程将在后台进程,发出该语句的进程可以继续做其他的事情。
4、LSP
Logicalstandbyprocess。
只有逻辑备库才会有该进程。
LSP进程控制着应用归档日志到逻辑备用数据库。
DataGuard环境要求
1、主库必须运行在归档模式
2、主备库数据库版本需要一致
3、主备库操作系统一致,但是操作系统的realese小版本号可以不一致。
备库可以与主库的目录结构不一致。
4、主备库的硬件结构必须一致
5、每个主备库必须有他们自己的控制文件
6、如果主备库在同一台服务器上,那么部分操作系统可能不允许在同台主机上打开两个相同数据库名的实例。
那么有些数据库的参数需要另外配置的。
7、为了防止部分直接路径插入而不记录日志的部分信息不能够传递到备库,在备份数据库到备库前,启用主库forcelogging属性。
在备库运行期间,保证主库的forcelogging属性。
备库状态
我们可以维护备库为如下的数据库状态
1、物理备库
Managedrecoverystate
该模式下logtransportservice归档日志到备库,logapplyservice自动应用这些日志。
数据库不处于mount状态,任何读都不允许。
Readonlystate
如果我们想做备库为报表功能,那么在备库环境中,我们以readonly形式打开数据库。
在备库logapplyservice将不能够应用归档日志到备库,但是主库的logtransportservice可以继续传递归档日志到备库。
我们可以非产轻松的在上述两种运行下进程切换,一般情况下我们会在如下的场景下进程切换:
1)物理备库用于报表模式
2)为了灾难的保护,检查数据是否正常的传递到了备库
2、逻辑备库
Openreadwritemode
该种模式,备库仍然可以不断的应用归档日志,但是该备库同时可以提供报表查询功能。
当logapplyservice正在更新一张表时,该表仍然可以查询,但是在该表上无法做任何的DML操作。
如果其他模式下的对象没有被logapplyservice所维护,那么我们可以更新该模式下的那些对象。
三、用SQL创建物理备库
学习完本章节,我们可以使用SQL创建物理备库。
总体
1、启用forcelogging
2、备份主库
3、copy文件到备库
4、设置备库的参数文件
5、启动备库
6、配置oraclenet
7、配置主库的参数文件
8、启动日志传输
启用forcelogging
1、建议启用该属性,以保证数据的一致性
2、启用该属性后,即使执行了nologging操作,也会产生相应日志。
3、临时表空间和临时段的信息不会被记录
4、建议在物理和逻辑备库上启用这些信息
5、alterdatabaseforcelogging
Alterdatabasenoforcelogging
设置该特性后,覆盖了所有的基于表空间以及某个对象设置的log属性。
该特性必须在所有的unlogging的进程完成后才能启用。
Noforcelogging则禁用了该功能。
对应的数据库的字段为v$database.force_logging,该操作可以在数据库打开或者mount阶段执行,但是建议在mount阶段做。
备份主库
1、主库必须在归档模式
Mount:
alterdatabasearchivelog;
同时必须保证log_archive_start=true
2、做一个主库的备份
可以做一个冷备份,也可以做一个联机备份
3、创建备库的控制文件
ALTERDATABASECREATESTANDBYCONTROLFILE
AS'file_name'[REUSE];
拷贝文件到备库
1、拷贝如下文件到备库
数据文件,备库控制文件,参数文件
3、如果主节点与备用节点的目录结构一致,则不需要如下参数,如果目录结构不一致的话,则需要如下参数,并且需要在备库控制文件中修改相关文件的路径。
DB_FILE_NAME_CONVERT:
主库到备库相关目录的路径映射
LOG_FILE_NAME_CONVERT:
主库到备库日志文件路径映射
STANDBY_FILE_MANAGEMENT:
当该参数设置为auto时,在主节点增减或者删除文件,在备份节点也会同样的执行。
这些参数都是在物理备用数据库中的参数文件设置的,但是最好在主库的参数文件中也需要设置。
设置备库参数文件
当参数文件从主库拷贝到备库后,需要在物理备库下修改如下参数文件
1、DB_FILE_NAME_CONVERT
当主备库目录结构不一致的时候需要在物理备库设置该参数。
允许多个文件对。
当在物理备库下,该参数应用于数据库。
db_file_name_convert=
('/oracle1/dba/','/ora1/stby_dba/','/oracle2/dba/','/ora2/stby_dba/')
字符串成对出现,第一个为主库文件路径,接下来的是备库中对应的文件路径。
2、LOG_FILE_NAME_CONVERT
与DB_FILE_NAME_CONVERT参数类似
只有当备库变为主库的时候才需要联机日志
log_file_name_convert=('/oracle1/logs/,'/ora1/stby_logs/')
3、LOG_ARCHIVE_FORMAT
指出日志文件的格式名字
%t:
线程号
%T:
以0补充的线程号
%s/S:
日志序号
%d/D:
数据库ID
%a/A:
数据库激活号(数据库第一次打开时产生)
默认的日志格式为:
log_archive_format=%d_%t_%s.arc,补0一般默认是8位。
在如下路径下生成日志LOG_ARCHIVE_DEST_n,STANDBY_ARCHIVE_DEST。
4、STANDBY_FILE_MANAGEMENT
当在主库上增加或者是删除数据文件的时候可以维持主备库的一致性。
默认值为:
manual必须在备库上手工增加或者是删除文件。
Auto:
在备库的数据文件的增加或者删除是自动执行的
该参数在主备库都起作用。
参数的设置方法:
standby_file_management=auto,主备库都设置。
an">当参数设置为auto时,在备库的如下操作是不允许的:
1)ALTERDATABASERENAME
2)ALTERDATABASEADD/DROPLOGFILE[MEMBER]
3)ALTERDATABASECREATEDATAFILEAS...
但是ALTERDATABASEADD/DROPSTANDBYLOGFILE操作仍然是允许的。
当我们在主库节点增加一个日志文件的时候,而我们想在备库中也增加一个日志文件,那么我们需要做如下的操作:
需要手工去操作。
5、STANDBY_ARCHIVE_DEST
定义在备用数据库上生成归档日志的地址。
在物理备库上被RFS进程所使用。
standby_archive_dest='/standby/arc_dest/'
standby_archive_dest='LOCATION=/standby/arc_dest/'
上述参数与该参数一起使用log_archive_dest_n=’service=standby’。
6、LOG_ARCHIVE_START
自动归档已经填满的日志。
当该参数设置为false时,可能需要管理员手工去归档需要归档的日志。
该参数只有在归档模式下才能生效,如果在非归档模式设置该参数无效。
为了便于切换,一般需要设置此参数为true,该参数在使用standbyredologs和fal_server支持时需要设置此参数为true。
7、REMOTE_ARCHIVE_ENABLE
对日志的发送和接受的控制。
该参数的经常设置的值如下:
该参数在主备库中都需要设置。
TRUE-Allowsbothsendingandreceivingtoandfromremotesites.Thisisthedefault。
FALSE-Preventsbothsendingandreceivingto/fromremotesites。
SEND-Allowsonlysendingtoremotesites。
RECEIVE-Allowsonlyreceivingfromremotesites。
RAC每个节点中该参数的设置必须相同。
该参数的值同v$database.remote_archieve
物理备库参数文件
compatible='9.2.0'
control_files='D:
\USER01\ORADATAB\U01\control01.ctl'
db_file_name_convert=
'D:
\USER01\ORADATAA\U01','D:
\USER01\ORADATAB\U01',
'D:
\USER01\ORADATAA\U02','D:
\USER01\ORADATAB\U02'
db_name='TESTA'
lock_name_space='testb'
log_file_name_convert=
'D:
\USER01\ORADATAA\U03','D:
\USER01\ORADATAB\U03'
remote_archive_enable='TRUE'
remote_login_passwordfile='exclusive'
standby_archive_dest='D:
\USER01\ORADATAB\U04'
standby_file_management='auto'
启动物理备库
启动到mount阶段
STARTUPMOUNTPFILE=STBY_INIT.ORA
创建备库日志文件
ALTERDATABASEADDSTANDBYLOGFILE
('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo')
SIZE500K;
启动MPR进程
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECT(FromSession);
物理备库日志文件是一组日志,RFS进程可以将日志写进备库日志文件,然后由归档进程进行归档,RFS进程也可以直接将日志写进归档日志中。
Standbyredolog在最大保护模式和最大可用模式下是必须的,但是在最大性能模式下是可选的,但是也建议建立备库归档日志。
配置Oracle网络
配置网络,需要使主备库能够相互通信。
配置备库的监听
重启主备库的监听
设置主库参数
LOG_ARCHIVE_DEST
LOG_ARCHIVE_STATE
ARCHIVE_LAG_TARGET
Log_archive_dest_n
至少包括2个该参数,参数中必须包含location,server
Location指定一个有效的路径名,本地的日志归档地址。
Service指定一个有效的网络服务名,该服务名指向:
Astandbydatabase:
就是一个备用数据库,可以为物理的,也可以为逻辑的。
Anarchivelogrepository:
归档知识库,允许远程归档数据库。
归档知识库是通过备库的控制文件创建,启动到mount状态,该知识库不包含任何的数据文件。
Across-instancearchivaldatabase:
交叉的归档库可以是主库也可以是备库。
比如:
log_archive_dest_1='LOCATION=D:
\ARC'
log_archive_dest_2='SERVICE=standby'
MANDATORY和OPTIONAL属性
OPTIONAL为失败做准备,允许主库重写
MANDATORY,除非归档日志已经归档到该地址,否则日志不允许覆盖。
通常情况下,某一个地址将被设置为强制的。
默认值为可选择的。
相关设置如下:
log_archive_dest_1='LOCATION=D:
\ARC'
log_archive_dest_2='SERVICE=standbyMANDATORY'
log_archive_dest_3='SERVICE=o9i1OPTIONAL'
LOG_ARCHIVE_DEST_STATE_n
定义了目前归档地址的状态。
可以应用于主备库。
1、enable默认值,就是该地址是有效的归档地址。
2、defer:
预留相关参数的地址和属性,但是该地址在目前不做为归档地址,除非该地址再次enabled。
3、reset:
与defer一样,但是会清除该参数指定的地址的相关错误
4、alternate:
当一个归档地址失败的时候,另外一个地址作为备用地址。
log_archive_dest_3='SERVICE=stby1_path1NOREOPENALTERNATE=LOG_ARCHIVE_DEST_4'
log_archive_dest_4='SERVICE=stby1_path2NOREOPENOPTIONAL'
log_archive_dest_state_3=ENABLE
log_archive_dest_state_4=ALTERNATE
ARCHIVE_LAG_TARGET
1、在主库设置
2、设置的单位为秒,在主库上即使日志没满,过了这么长时间后日志必须切换。
3、设置备库等待处理日志的最大时间
4、默认设置为0,不使用该功能
5、该参数范围值为:
60—7200,建议值为30分钟
6、该值设置太小,可能会导致主库的日志的频繁切换。
一般情况下要等主库的日志完成后才能应用到备库。
比如日志为100M,而目前日志已经写为80M,而此时主库失败,那么必须在该80M日志在备库应用后,才能无数据损失的切换。
LOG_ARCHIVE_TRACE
1、该参数是可选的作为诊断用
2、设置该参数为一个整数,用来查看想备库