1、DATAGUARD原理
DATAGUARD是通过建立一个PRIMARY和STANDBY组来确立其参照关系。
STANDBY一旦创建,DATAGUARD就会通过将主数据库(PRIMARY)的REDO传递给STANDBY数据库,然后在STANDBY中应用REDO实现数据库的同步。
有两种类型的STANDBY:物理STANDBY和逻辑STANDBY
物理STANDBY提供与主数据库完全一样的拷贝(块到块),数据库SCHEMA,包括索引都是一样的。它是直接应用REDO实现同步的。
逻辑STANDBY则不是这样,在逻辑STANDBY中,逻辑信息是相同的,但物理组织和数据结构可以不同,它和主库保持同步的方法是将接收的REDO转换成SQL语句,然后在STANDBY上执行SQL语句。逻辑STANDBY除灾难恢复外还有其它用途,比如用于用户进行查询和报表。
DATAGUARD包含三个服务(日志传输、日志应用、角色转换)
日志传输服务控制REDO数据的传输(传输日志,实施数据库保护模式)————–STANDBY上通过起用RFS进程接收REDO数据。
日志应用服务则一方面自动应用日志,另一方面自动检测STANDBY缺少的REDO,并从主数据库或其它STANDBY中自动查询出丢失的REDO。
DATAGUARD的几种保护模式:最大保护,最大可用,最大性能
最大保护是指除非REDO在至少一个STANDBY中可用,否则事务不能提交。如果在某个STANDBY中不可用,则主数据库的操作被停止。通常受制约比较多,在生产环境中不是很常用(性价比不好)。
最大可用是指如果STANDBY不可用,主数据库仍然可以处理事务,只是在问题被纠正后,STANDBY和主数据库进行再同步。这样的一个问题是:当再同步之前有FAILOVER时,有些数据可能会丢失。
最大性能是指主数据库的提交操作不等待STANDBY。PRIMARY和STANDBY松耦合,数据保护级别较低。
物理STANDBY可能的模式:只读模式(OPEN READONLY)和恢复模式(MANANGED RECOVERY)
2、物理DATAGUARD实施简要过程
主数据库的准备工作:FORCE LOGGING,ENABLE ARCHIVING,一个本地归档目的地。
创建STANDBY数据库:
1.关闭主库,冷备份主库数据文件、日志文件和密码文件,然后启动主库,在主库上创建STANDBY的控制文件:alter database create standby controlfile as ‘文件名’
2.准备参数文件,将参数文件、备份的主库文件和STANDBY控制文件拷贝到STANDBY系统。
需要更改的参数有:standby_archive_dest—–接收的归档日志存放处
db_file_name_convert和log_file_name_convert—–仅当主库和STANDBY库在同一系统下时用
log_archive_dest_1—–本地归档目的地
log_archive_dest_2=’service=standby’—–归档到STANDBY的目的地
standby_file_management=auto
remote_archive_enable=true
fal_server
fal_client
instance_name—–当主库和STANDBY库在同一系统下时该参数用于区分主库
lock_name_space—–当主库和STANDBY库在同一系统下时指定STANDBY的实例名和INSTANCE_NAME相同
3.如果是WINDOWS系统,需要创建WINDOWS服务。
4.配置两台机器的tnsnames.ora,双方都能tnsping通
5.在主库和STANDBY库上配置监听
6.起用STANDBY系统上的死连接检测:sqlnet.ora中设置sqlnet.expire_time=2
7.在STANDBY上创建SPFILE
8.启动STANDBY:
startup nomount
alter database mount standby database
9.初始化日志应用服务
alter database recover managed standby database disconnect from session;
3DATAGUARD维护
1.日志传送服务
有些情况下,你可能需要在归档日志和应用日志之间有个时间间隔,此时可以通过在STANDBY上指定参数log_archive_dest_n中指定delay=minutes属性。
STANDBY上的日志应该与主库上的日志大小相同,另外STANDBY上的日志组应该比主库多,因为这样归档操作才有时间完成。也就是RFS(日志接收)进程在使用STANDBY的日志前,不用等待该日志被归档。最简单判断日志组是否够的方法是查看警告日志和RFS的TRACE文件。
增加STANDBY日志文件的方法:
alter database 语句中使用add standby logfile子句。相关视图vstandbylog,vlogfile
增加STANDBY日志组的方法:
alter database add standby logfile group 10 (‘文件名1’,’文件名2’) size 100M对于多个 STANDBY共享归档日志文件目的地,有些情况下需要指定log_archive_dest_n参数的dependency属性,该属性的作用是说明该目的地依赖于父目的地的成功归档。
参数log_archive_dest_n还可以指定reopen、max_failures、sync、async属性。通过给该参数指定LGWR或者ARCH属性以选择是用LGWR还是ARCH进程传送日志。
用于日志接收的几个进程是:LGWR,ARCH,RFS,FAL。FAL进程用于解决日志缝。
设置数据保护模式的语句为:alter database set standby database to maximun(protection|availability|performance)
2.日志应用服务
对于物理STANDBY,日志应用服务涉及到下面几个进程:RFS,ARC,MRP。MRP是管理恢复进程。
启动STANDBY的恢复操作的几个命令:alter database recover managed standby database(启动前台会话);alter database recover managed standby database disconnect from session(启动后台会话,也就是说会话可以继续干别的事情);alter database recover managed standby database cancel(停止日志应用).
可以通过查询视图v$managed_standby查看日志应用情况。
3.数据文件管理
当主库新创建数据文件,可定义参数standby_file_management为auto,让standby也自动创建数据文件。如果主库和standby的数据文件的目录结构不一样,可以设定db_file_name_convert将主库上的文件名转换成standby上的文件名。如果standby_file_management设为auto,则不能在standby上重命名或创建数据文件、日志文件。
每分钟主库会询问standby是否有gap,该行为被称为heartbeat.
可以查询视图varchivedgap,如果发现有GAP,则可以从主库上将日志文件拷贝到standby,然后将相关文件注册到standby,具体方法是:alterdatabaseregisterlogfile‘文件名′。当然也可以通过设置参数falserver,falclient,让日志应用服务自动处理gap问题。对于STANDBY日志应用服务,下面几个视图有助于监控:vmanaged_standby,varchiveddeststatus,varchived_log,vlogstatus,vdataguard_status.
可以设置参数log_archive_trace对归档进行不同级别的跟踪。
4.角色转换
ORACLE支持两种形式的角色转换—-switchover和failover
switchover包含两个步骤,首先主库被转换成STANDBY,然后STANDBY被转换成主库
switchover的准备工作:完成角色转换需要改变的参数(必须改变所有STANDBY上的 log_archive_dest_n和log_archive_dest_state_n);确保主库和所有STANDBY都有连接;确认没有用户连接到数据库;对于RAC环境确保只有一个实例是活动状态;角色转换之前,主库实例应该是OPEN状态,而STANDBY实例是MOUNT状态,因为这样的话,转换过程中STANDBY数据库也可以应用归档日志,如果STANDBY为READONLY,切换操作仍然可以进行,只是要花一点额外的时间;如果切换操作包含逻辑STANDBY,那么,主库实例和STANDBY实例都必须为OPEN状态;将要转换成主库的STANDBY变成归档模式;取消在该STANDBY库上的日志延迟。
switchover的步骤:在当前主库上,首先确认可以执行switchover操作(select switchover_status from vdatabase,如果值为TOSTANDBY则可以切换,否则需要检查当前DATAGUARD配置是否运行正常),然后将主库切换为STANDBY(执行ALTERDATABASECOMMITTOSWITCHOVERTOPHYSICALSTANDBY;这样原控制文件被备份并生成新的STANDBY控制文件,然后只要重新启动该库为STANDBY模式就可以了);以上操作完成后,在原STANDBY数据库上,需要查询原主库的切换信息是否被目标STANDBY接收到(SELECTSWITCHOVERSTATUSFROMVDATABASE;如果结果为SWITCHOVER PENDING说明STANDBY切换为PRIMARY是可行的,否则需要检查DATAGUARD的配置是否运行正常),然后执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;将STANDBY转换成PRIMARY,并重新启动该库。这里需要说明的是如果该库在线重做日志不存在,该切换语句会自动创建它们,然而这样一来,会花费很长的时间。因此ORACLE建议手工增加在线重做日志。手工增加在线重做日志的方法有两种:第一种是将原主库的日志拷贝到原STANDBY,并且定义参数log_file_name_convert,让它将standby和新的日志联系起来。第二种方法是DROP所有目标STANDBY上存在的日志,并且用命令ALTER DATABASE ADD STANDBY LOGFILE创建新的日志。switchover的最后一步是将新生成的STANDBY转换成恢复模式,并将新PRIMARY进行一次归档操作。
failover的准备工作:完成角色转换需要改变的参数(必须改变所有STANDBY上的log_archive_dest_n和log_archive_dest_state_n);确保主库和所有STANDBY都有连接;对于RAC环境确保只有一个实例是活动状态;如果要进行failover操作的STANDBY当前运行于最大保护模式,则应该将它转换成最大性能模式(通过命令ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;)
failover的步骤:首先发现并解决日志GAP的问题,然后从其它库中将日志号高于本库的日志拷贝过来并应用这些日志,如果你没有手工注册新的日志,那么可以执行下面的语句ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;否则需要执行的语句为ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH SKIP STANDBY LOGFILE;接下来执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;完成切换并重新启动新的主库,可能的话对主库进行一次备份。
5.启动STANDBY
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
6.关闭STANDBY
首先确认是否处于恢复状态:SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
取消恢复操作:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SHUTDOWN IMMEDIATE;
7.让standby运行于只读访问模式
启动STANDBY为只读模式:
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE OPEN READ ONLY;
将恢复模式的STANDBY转换成read only模式:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN READ ONLY;
8.让STANDBY从READ ONLY转变成恢复模式
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
i.让为只读模式的STANDBY执行排序操作应该注意的问题:
排序操作不能使用非临时表空间,临时表空间必须是本地管理的,并且只包含临时文件
如果在创建STANDBY时主库没有临时表空间,则需要在主库上创建临时表空间,并执行ALTER SYSTEM SWITCH LOGFILE;将redo传给STANDBY。如果要给STANDBY的临时表空间增加临时文件,需要先将STANDBY转换成READ ONLY模式,并执行命令ALTER TABLESPACE temp1 ADD TEMPFILE ‘/disk1/oracle/dbs/s_temp1.dbf’ SIZE 10M REUSE;增加临时文件。
9.可以通过对STANDBY的备份实现对数据库的备份。
10.主库上的操作和STANDBY的应对:
如果你执行ALTER DATABASE CLEAR UNARCHIVED LOGFILE或者打开数据库时使用RESETLOGS,那么必须重新创建STANDBY。
如果你在主库上执行ALTER DATABASE ENABLE|DISABLE,如果你改变表空间的状态,如果你设置了参数STANDBY_FILE_MANAGEMENT为AUTO并创建表空间或者增加数据文件,则不需要对STANDBY进行操作。
如果你在主库上删除了表空间或者数据文件,你需要在STANDBY上等日志应用后在操作系统上删除相关数据文件。
如果你在主库上重命名了数据文件,你也要在STANDBY上重命名(因为是对控制文件的改变,所以没有日志传过去,因此两边都要进行相同的操作)
如果你在主库上改变了控制文件,你就要重新创建STANDBY控制文件或者重建STANDBY数据库。
如果你在主库上增加或删除日志文件,你也需要在STANDBY上进行同步变化。
具体方法为:先取消恢复,如果STANDBY_FILE_MANAGEMENT为AUTO,则改为MANUAL,然后使用命令ALTER DATABASE ADD STANDBY LOGFILE ‘prmy3.log’ SIZE 100K;增加日志文件或者用命令ALTER DATABASE DROP STANDBY LOGFILE ‘prmy3.log’DROP掉日志文件,最后恢复参数STANDBY_FILE_MANAGEMENT的值。
如果你在主库上进行了nologging|unrecoverable等操作,则应该将包含这些变化的表空间拷贝到STANDBY。
如果你改变了主库的参数文件,那么你也应该改变STANDBY的参数文件。
三、监控进程
SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
m.监控恢复操作的进程
SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;
DATA GUARD的最主要的功能是冗灾。当然根据配置的不同,DATA GUARD还可以具备以下特点:高可用、性能提升、数据保护以及故障恢复等。
DATA GUARD可以分为物理STANDBY和逻辑STANDBY两种。二者的最大差别在于,物理STANDBY应用的是主库的归档日志,而逻辑STANDBY应用的是主库的归档日志中提取的SQL语句。由于二者这一点的区别,决定了物理STANDBY无论从逻辑结构和物理结构都是和主库保持一致,而逻辑STANDBY则只需保证逻辑结构一致,且逻辑STANDBY在应用SQL语句的时候,数据库可以处于打开的状态。
如果从DATA GUARD的保护模式分,可以分为三种不同的保护模式:
保护最大化:这种模式的配置可以保证主库和备库的同步,任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题,或者备库本身出现问题,都会导致主库停止数据处理。
可用最大化:这种模式和上面一种类似,也是会保证主库和备库的同步,区别在于,当网络或备库不可用时,主库仍然可以继续处理。
性能最大化:主库和备库是异步的。这种模式可能在主库出现损毁时,丢失一部分数据。但是这种模式对主库负荷最小,因此具有最好的性能。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31562969/viewspace-2286285/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31562969/viewspace-2286285/