网上很多文章都只是介绍如何搭建Oracle Data Guard，但是很少有介绍到基本的概念和理论知识。同时官方文档是纯英文的，对于英文不好的读起来是非常痛苦。本人因为是英文专业，结合官方文档和自己所学，整理了以下这些文字，和大家一起共同学习。同时感谢谢永生（Warehouse）和OCM群中的其他兄弟们，并以此文献给口香糖同学新出生的儿子。
1． Oracle Data Guard介绍：
Oracle Data Guard是Oracle数据库高可用技术中的一种，通过数据冗余为企业级数据库提供高可用，数据保护和灾难恢复。Data Guard 通过日志同步机制，在主备库之间实现数据同步，由于相互之间是通过网络连接，所以每个库可以放置在不同的地理位置，只要保证网络连接通畅即可。如果主库发生计划中或者异常停机，Data Guard可以将任何1台Standby数据库切换成Primary数据库继续提供服务。
1.1. Primary数据库：
Data Guard配置中包含1台生产数据库，这台数据库可以是单实例也可以是RAC集群，负责对外提供大部分服务，在Data Guard中这台的角色就是Primary。
1.2. Standby数据库：
在一套Data Guard中最多可以有9台Standby数据库，Primary数据库通过网络将日志传输到Standby数据库，然后Standby在接收完日志后进行应用，以实现主备库之间的数据同步和事务一致性。和Primary数据库一样，Standby数据库也可以是单实例或者RAC集群。根据Redo Log的应用方式不同，Standby数据库又可以分为物理Standby和逻辑Standby。另外Data Guard是通过控制文件来识别Primary和Standby数据库的，所以Standby数据库的控制文件一定不能用操作系统复制，一定要通过命令ALTER DATABASE CREATE STANDBY CONTROLFILE AS来进行创建。
1.2.1. 物理Standby：
物理Standby使用的是Media Recovery技术，通过Redo Apply，使用从主库接收到的Redo Log进行恢复，是基于block级的恢复，所以主备库中所有的schema都是完全一样的。物理Standby必须在mount阶段才能进行恢复，但是能通过只读方式打开，在10g版本中如果以只读方式打开的话就无法进行恢复操作。所以在某些情况下，Standby可以分担一部分查询和备份的压力，但是Data Guard还不能作为性能优化的解决方案。
1.2.2. 逻辑Standby：
逻辑Standby使用的是Log Miner技术，把Redo Log中的内容还原成SQL语句，通过SQL Apply在备库执行SQL语句来实现数据同步。Log Miner不支持所有的数据类型，不支持的类型可以在DBA_LOGSTDBY_UNSUPPORTED视图中进行查看。逻辑Standby可以在恢复的同时进行写操作。
1.3. Data Guard保护模式
1.3.1. 最大保护模式Maximum protection
在这种模式下，能够确保在Primary宕机时数据没有任何丢失。在事务提交之前，Primary数据库将Redo Log写入本地Online Redo Log，同时写入Standby数据库的Standby Redo Log，并且确保至少Redo Log在一个Standby数据库上可用，这样事务才会被提交，否则Primary会被shutdown。
1.3.2. 最高可用模式Maximum availability
最高可用和最大保护类似，也是确保Redo在写入本地Online Redo Log和至少一个Standby数据库的Standby Redo Log，事务才会被提交。但是和最大保护不同的是，如果发生故障（如网络中断）导致Redo Log无法被写入Standby数据库时，Data Guard会自动切换到最高性能模式，而不是shutdown Primary数据库。当故障排除，Redo Log的gap被解决之后，Data Guard会自动切换回最高可用模式。
1.3.3. 最高性能模式Maximum performance
Data Guard默认模式。在这种模式下，Primary数据库在写入本地Online Redo Log之后就提交事务，写入Standby Redo Log是异步的，所以对于Primary性能影响是最小的。
1.3.4. 设置Data Guard保护模式
|
| Maximum protection 最大保护 | Maximum availability 最高可用 | Maximum performance 最高性能 |
| Redo归档进程 | LGWR | LGWR | LGWR或ARCH |
| 网络传输模式 | SYNC | SYNC | 如使用LGWR: SYNC或ASYNC 如使用ARCH: SYNC |
| 磁盘I/O模式 | AFFIRM | AFFIRM | AFFIRM或NOAFFIRM |
| 是否必需Standby Redo Log | 是 | 是 | 否，但是建议创建 |
改变Data Guard保护模式可以在Primary数据库（mount阶段）执行SQL语句：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY｜ PERFORMANCE}，另外通过SQL语句：SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE 可以查看当前数据库的保护模式。
1.4. 跨平台Data Guard 配置条件
除了相同的操作系统平台，Data Guard支持跨操作系统。
Oracle版本必须是10g及以上，同时Primary和Standby的操作系统必须有相同的字节序（同为big endian或者little endian），可以通过查询视图V$TRANSPORTABLE_PLATFORM获取信息。
2． Online Redo Logs,Archived Redo Logs, and Standby Redo Logs
2.1. Online Redo Logs
Primary数据库和逻辑Standby数据库都会用到Online Redo Log，但是物理Standby数据库是不使用Online Redo Log的，因为物理Standby只能以只读方式打开，不会有写操作，所以不会有Redo Log产生。
2.2. Archived Redo Logs
Primary数据库和Standby数据库（逻辑和物理）都需要用到Archived Redo Log，来保证Primary和Standby的事务一致性。
2.3. Standby Redo Logs
Standby Redo Log是Standby数据库用来存放从Primary数据库接收到的Redo Log的，以下几种情况必须要使用Standby Redo Log：
Ø 最大保护和最高可用模式 见1.3 Data Guard保护模式。
Ø Real-time apply
Ø Cascaded destinations
Standby Redo Log组的数量必须不少于Primary数据库的Online Redo Log组的数量，建议比Online Redo Log多1组。可以通过观察RFS进程的trace文件或者alert.log，如果日志中记录了RFS进程频繁等待归档进程的话，就需要增加Standby Redo Log组。
SQL语句ALTER DATABASE ADD STANDBY LOGFILE GROUP 1(‘/disk1/stdlog1a.rdo’, ‘/disk2/stdlog1b.rdo’) size 20M; 用于添加一组Standby Redo Log。
SQL语句ALTER DATABASE ADD STANDBY LOGFILE MEMBER ‘/disk3/stdlog1c.rdo’TO GROUP 1; 用于在第1组Standby Redo Log中再增加一个member。
SQL语句ALTER DATABASE DROP STANDBY LOGFILE GROUP1; 用于删除一组Standby Redo Log。
3． Redo传输服务Redo transport services
Redo传输服务是用来自动将Primary数据库产生的Redo Log传输到Standby数据库，并且能自动处理因为网络故障导致的归档日志gap。为了保障日志传输的安全性，Oracle是通过SYS密码来验证的，所以必须确保Primary数据库和所有的Standby数据库密码一致，并且参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE必须设置。
3.1. Redo传输路径的类型
Ø Data Guard Standby数据库 逻辑或者物理Standby数据库
Ø 归档日志容器 类似于Data Guard，archive log repository也是使用Standby controlfile和pfile来启动实例到mount阶段，但是这个数据库没有数据文件，无法进行切换，仅仅是用于保存归档日志。
Ø Stream实时下游捕获数据库 Oracle流复制技术，此处不做深入讨论。
Ø Oracle Change Data Capture stagingdatabase
3.2. 使用LOG_ARCHIVE_DEST_n参数来设置Redo传输路径
LOG_ARCHIVE_DEST_n参数一共有10个（n从1到10），每一个参数都必须使用LOCATION或者SERVICE属性来指定传输路径。对应的LOG_ARCHIVE_DEST_STATE_n参数用来控制其状态，
LOG_ARCHIVE_DEST_STATE_n共有4种状态：
Ø ENABLE 这是默认状态，Redo传输服务会发送日志到参数指定的路径。
Ø DEFER 表示路径有效，但是未使用。Redo传输服务不会把日志发送到指定的路径。
Ø ALTERNATE 表示路径不可用，但是如果和该路径设置为关联的另外一个路径失效的话，会切换成可用状态。
Ø RESET 功能和DEFER一样, 但是如果之前失效的话，会清除相关的错误信息。
3.3. LOG_ARCHIVE_DEST_n参数属性详解
3.1.1. LOCATION和SERVICE属性
每一个归档路径必须设置LOCATION或SERVICE属性，并且没有默认值。
Ø LOCATION
LOCATION=local_disk_directory或者也可以设置成LOCATION=USE_DB_RECOVERY_FILE_DEST，表示使用DB_RECOVERY_FILE_DEST参数指定的路径。通常设置了DB_RECOVERY_FILE_DEST参数后，LOG_ARCHIVE_DEST_10会隐式的设置为USE_DB_RECOVERY_FILE_DEST，即归档到flash_recovery_area。
Ø SERVICE
SERVICE属性用于设置一个通过Oracle NET连接的远程归档路径，SERVICE=net_service_name。net_service_name必须在TNSNAMES.ORA中事先定义好，并且通过tnsping命令确保连接畅通。视图V$ARCHIVE_DEST可以用来查看相关的设置信息。
3.1.2. ARCH和LGWR属性
该属性指定Redo传输服务使用ARCn进程或者LGWR进程来传输Redo Log。默认值是ARCH。
Ø ARCH
ARCH模式是通过ARCn进程，在数据库进行归档时将Redo Log写入指定路径。ARCH模式仅支持Data Guard中的最高性能模式。当Primary数据库触发了log switch事件，ARCn进程会开始本地归档，在归档成功之后，ARCn进程会将本地归档日志（非Online Redo Log）传输到Standby数据库。在Standby数据库上RFS进程（Remote File Server Process）会将日志依次写入归档日志，写完之后MRP进程（物理Standby）或者LSP进程（逻辑Standby）会将日志应用到Standby数据库。查看V$ARCHIVED_LOG视图可以检查归档日志是否成功写入。
Ø LGWR
LGWR模式在每一次commit之后，LGWR进程写本地Online Redo Log，同步或者异步（取决于SYNC和ASYNC）写入LOG_ARCHIVE_DEST_n参数指定的路径（Standby数据库必须存在Standby Redo Logs），如果该路径是远程的，LGWR进程会调用LNSn进程建立一个网络连接访问远端的实例并由该进程负责传输日志。在Standby数据库上RFS进程（Remote File Server Process）会将接收到的Redo Log写入Standby Redo Log中。Primary数据库发起的log switch会同步引起Standby数据库对Standby Redo Log进行归档，归档完成之后MRP进程（物理Standby）或者LSP进程（逻辑Standby）会在下一次归档完成之后将日志应用到Standby数据库。如果启用了LGWR模式，在归档的时候除了本地归档就不会再触发ARCH进程写远程归档路径了，但是如果LGWR在写目标路径时失败，则会自动转换成ARCH模式，直到错误排除。
Ø 使用注意点
a. 如果不指定是ARCH或LGWR，则默认是ARCH。
b. ARCH模式使用的是ARCn进程，LGWR模式则是使用LGWR进程。同一个归档路径不能同时指定两种模式，但是一个数据库中的多个路径可以使用不同的模式，比如LOG_ARCHIVE_DEST_2是ARCH，LOG_ARCHIVE_DEST_3是LGWR。
c. 如果通过ALTER SYSTEM修改了一个归档路径的模式，比如从ARCH修改到LGWR，不是立刻生效的，必须等到下一次log switch才会生效。
3.1.3. SYNC和ASYNC属性
控制LGWR或ARCH进程在写Redo Log时是同步还是异步写。
3.1.4. AFFIRM和NOAFFIRM属性
该属性指定Redo传输服务在写Archived Redo Log和Standby Redo Log时，磁盘I/O是否同步。
Ø AFFIRM
表示Redo传输服务在写Archived Redo Log和Standby Redo Log时，Primary和Standby两边的磁盘I/O是同步的。并且只有在两边都成功写入后，Log写进程才会继续。
Ø NOAFFIRM
默认值，表示Redo传输服务在写Archived Redo Log和Standby Redo Log时是异步的，Primary端的日志写进程不会等待Standby端写Archived Redo Log和Standby Redo Log。
Ø 使用注意点
a. 当Data Guard为最大保护或最高可用模式，并且设置为LGWR和SYNC时，该参数自动设置为AFFIRM。
b. 如果指定了LGWR和AFFIRM，Primary和Standby两边日志写进程会同时写Redo，直到两边的磁盘I/O都完成了用户才能继续操作。
c. 如果指定了ARCH和AFFIRM，ARCn进程会同步将Redo写入本地归档目录和远程路径，所以归档操作会消耗更长的时间。
d. 如果指定了ASYNC和AFFIRM，那么Primary数据库性能将不受影响。
e. AFFIRM和NOAFFIRM对于Primary数据库的Online Redo Log没有影响。
重点：SYNC/ASYNC，AFFIRM/NOAFFIRM 这2对属性单独理解比较困难，需要结合起来一起分析。这2对属性控制了Data Guard在做同步数据时的方式，同时也决定了Data Guard的保护模式。下面结合LGWR和ARCH来分别看这2对属性是如何控制数据同步的。
LGWR模式：
在Primary数据库产生commit事件之后，Primary数据库通过LGWR进程写Online Redo Log，此时LGWR进程会同步或者异步（SYNC/ASYNC）写入Standby Redo Log。如果该归档路径是远程的（归档路径设置为SERVICE），那么LGWR进程会调用LNSn进程，通过Oracle Net建立网络连接，然后往Standby数据库传输Redo Log。在Standby数据库，RFS进程（Remote File Server Process）在接收到LNSn进程传输来的Redo Log后，如果是AFFIRM，那么RFS进程会在成功写入Standby Redo Log之后返回给Primary数据库一个处理结果，Primary数据库的LGWR进程会进行等待直到Standby数据库返回处理结果。如果是NOAFFIRM，那么Standby数据库的RFS进程在接收到Redo Log后，在写入Standby Redo Log之前就返回给Primary数据库处理结果，此时Primary数据库的LGWR进程不会等待Standby数据库的RFS进程写Redo Log，因为已经提前收到了处理结果。
ARCH模式：
在Primary数据库发起log switch事件之后，Primary数据库会通过ARCn进程，将Online Redo Log进行归档，写入本地归档路径。并且会通过Oracle Net建立网络连接，同步或者异步（SYNC/ASYNC）向Standby数据库传输归档日志（Archived Redo Log）。Standby数据库的RFS进程在接收到ARCn进程传输来的Archived Redo Log后，如果是AFFIRM，那么RFS进程会在写完归档日志之后返回给Primary处理结果，在RFS进程写入期间，Primary数据库的ARCn进程会进行等待。如果是NOAFFIRM，则RFS在写归档日志之前先返回处理结果，此时Primary的ARCn进程在收到返回结果后就不会再等待RFS写归档日志了。
3.1.5. ALTERNATE属性
该属性用来指定当一组路径失败时，启用替补归档路径。
Ø 使用方法
Example 1. 自动fail over到替补归档路径
LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='LOCATION=/disk2MANDATORY'
LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
Example 2. 使用不同的Oracle Net自动fail over到Standby数据库上
LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1 OPTIONALALTERNATE=LOG_ARCHIVE_DEST_3'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2OPTIONAL'
LOG_ARCHIVE_DEST_STATE_3=ALTERNATE
Ø 使用注意点
a. ALTERNATE属性是可选的，如果没有指定，那么在原始路径fail之后是无法自动切换到其他的归档路径上的。
b. 每一个LOG_ARCHIVE_DEST_n只能设置一个替补路径。
c. 当前可用的归档路径数量要符合LOG_ARCHIVE_MIN_SUCCEED_DEST参数的值（如果设置的话）。
d. 无法将自己设置为替补路径。
e. 至少要有一个本地强制归档路径。
f. 当一个路径失效时，替补路径会在下一次归档时才生效。
g. 如果设置了REOPEN属性，并且MAX_FAILURE属性为0，那么ALTERNATE将无效。如果同时设置了REOPEN和MAX_FAILURE，那么只有当失效的归档路径达到MAX_FAILURE指定的数量，ALTERNATE才会生效。
3.1.6. LOG_ARCHIVE_MAX_PROCESSES参数
当LOG_ARCHIVE_DEST_n采用ARCH模式时该参数用于限制开启ARCH的进程数量，最大值是30，可以通过ALTER SYSTEM来动态修改。默认情况下会自动开启4个ARCH进程，并且自动进行负载均衡。
3.1.7. VALID_FOR属性
语法为：VALID_FOR=(redo_log_type, database_ role)
redo_log_type的有效值为：ONLINE_LOGFILE,STANDBY_LOGFILE和ALL_LOGFILES。该参数指明了归档路径log_archive_dest_n对哪种类型的日志有效。
database_role的有效值为：PRIMARY_ROLE,STANDBY_ROLE和ALL_ROLES。该参数指明了归档路径
log_archive_dest_n在哪个数据库角色下生效。
如果未设置VALID_FOR属性，默认相当于设置了VALID_FOR=(ALL_LOGFILES, ALL_ROLES)。
3.1.8. DB_UNIQUE_NAME属性
此处的DB_UNIQUE_NAME是指设置在LOG_ARCHIVE_DEST_n参数里的，当LOG_ARCHIVE_DEST_n参数设置了SERVICE属性，则必须同时设置DB_UNIQUE_NAME。
例如：
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWRASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
这个属性的值和参数LOG_ARCHIVE_CONFIG以及参数DB_UNIQUE_NAME的值都对应，如果上述例子中，Standby数据库（boston）的DB_UNIQUE_NAME不是boston，则LOG_ARCHIVE_DEST_2在归档到Standby数据库时连接会被拒绝。
3.1.9. REOPEN和MAX_FAILURE属性
语法为：LOG_ARCHIVE_DEST_1='LOCATION=/arc_destREOPEN=60 MAX_FAILURE=3' ，REOPEN可以单独使用，但是MAX_FAILURE必须和REOPEN一起使用。
REOPEN属性用来设置该归档路径是否会自动重试，单位为秒，默认值300秒。比如上例中如果第一次Redo传输失败，那么在60秒后，ARCn或者LGWR进程会尝试重新传输日志。如果REOPEN=0表示关闭重试功能。
MAX_FAILURE属性用来设置连续失败的次数。比如上例中如果传输日志失败后每隔60秒会重试，重试失败3次后会关闭自动重试功能。
3.1.10.MANDATORY和OPTIONAL属性
语法为：LOG_ARCHIVE_DEST_3= 'LOCATION=/arc_dest MANDATORY | OPTIONAL'
该属性的含义是假如设置了MANDATORY，那么在log switch之后，如果该归档路径下的归档操作没有成功，那么对应的那一组Online Redo Log也不会被覆盖和重用，只有在错误排除后那一组Online Redo Log才变为可用状态。如果设置为OPTIONAL，那么即使发生归档错误，Online Redo Log也会再次被标记为可用状态。
默认值是OPTIONAL，但是即使所有的归档路径都设置了OPTIONAL，仍然有一个本地归档路径是MANDATORY以此来保证至少有一组归档日志是可用的。
3.1.11. DEPENDENCY属性
该属性主要用于共享归档路径，必须和SERVICE一起使用，并且不能设置NOREGISTER属性。具体用法如下：
LOG_ARCHIVE_DEST_1='LOCATION=DISK1MANDATORY'
LOG_ARCHIVE_DEST_2='SERVICE=stdby1OPTIONAL'
LOG_ARCHIVE_DEST_3='SERVICE=stdby2OPTIONAL DEPENDENCY=LOG_ARCHIVE_DEST_2'
以上示例是指Primary数据库将Redo Log传输到stdby1，但是不传输给stdby2，stdby2通过共享stdby1的Redo Log进行恢复。
3.1.12. DELAY属性
语法为：LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120' 必须和SERVICE一起使用。
该属性主要作用是设置Standby数据库从接收到Redo Log到应用Redo Log恢复数据库之间的时间间隔，单位是分钟，默认是没有延迟。从Standby数据库接收到Redo Log并且完成归档动作之后开始计时，计时结束后才会应用Redo Apply去恢复数据库。通过以下语句可以关闭DELAY：
物理Standby： ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
逻辑Standby： ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;
3.1.13. MAX_CONNECTIONS属性
语法为：LOG_ARCHIVE_DEST_3='SERVICE=denverMAX_CONNECTIONS=3'
通常情况下Redo传输服务只会使用一个网络连接来执行远程归档，如果该属性的值设置大于1，Redo传输服务会使用多个网络连接。但是该属性同时受到LOG_ARCHIVE_MAX_PROCESSES和PARALLEL_MAX_SERVERS这两个参数影响。
3.1.14. NET_TIMEOUT
该属性必须在LGWR SYNC传输方式下使用，且仅对LNSn进程生效。单位是秒，默认是180秒。Primary数据库通过LNSn进程发送日志给Standby数据库，如果在NET_TIMEOUT参数指定时间内没得到Standby数据库的响应，则连接超时。如果是最大保护模式，那么数据库会在5分钟内重试连接，而不会立即shutdown Primary数据库。
3.1.15. NOREGISTER
如果SERVICE方式的归档路径不是Data Guard配置中的一部分，那么必须加上NOREGISTER。
3.1.16. TEMPLATE
设置归档日志文件的命名格式。仅对使用SERVICE的归档路径生效，不能命名LOCATION方式的归档日志。
3.1.17. VERIFY
指在完成归档操作后是否对归档日志进行验证。验证操作需要较长的时间来完成，并且可能对Primary数据库造成性能方面的影响。
3.4. 处理归档裂缝Archive Gap
Primary数据库完成了本地归档，但是在传输给Standby数据库时因为各种原因导致远程归档失败，那么这部分丢失的日志就是归档裂缝。
3.4.1. 自动处理归档裂缝
从Data Guard 10g版本开始，Primary数据库每隔1分钟会自动发起检查，如果发现裂缝会自动进行修复，不需要人工进行干预。FAL（Fetch Archive Log）机制有2部分组成，FAL server和FAL client。FAL client的作用是自动发起传输归档日志的请求，FAL server则响应请求并传输缺失的归档日志。如果Data Guard中有多个Standby数据库，FAL可以从其他的Standby数据库那获取归档日志。
FAL机制可以处理以下几种情况的日志裂缝：
a. 在创建Data Guard时，通过Primary数据库的热备份集创建Standby数据库后，FAL会自动检索Primary数据库的归档日志并恢复Standby数据库以进行同步。
b. 如果Standby数据库的归档日志在被应用之前就删除了，FAL会重新传输一份归档日志。
c. 因为磁盘错误等原因或者归档日志被其他文件覆盖导致归档日志无法被应用，FAL会重新传输一份归档日志。
配置该功能需要2个参数FAL_SERVER和FAL_CLINET，这2个参数的值都是在tnsnames.ora中预先定义的Oracle网络服务名：
FAL_SERVER：指定FAL机制获取归档日志的来源，可以包含多个值，例如FAL_SERVER= primary_db,standby3_db。
FAL_CLIENT：指定FAL机制发起请求的客户端，一般来说是Standby数据库，例如FAL_CLIENT=standby1_db。
3.4.2. 手动处理归档裂缝
以下示例是物理Standby数据库手动处理的过程：
Step 1. 查询V$ARCHIVE_GAP视图获得归档裂缝。
Standby数据库：
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
----------- -----------------------------------------------
1 7 10
从视图中看出7号到10号归档日志丢失。
Step 2. 查询V$ARCHIVED_LOG获取归档裂缝所在的归档日志文件。
Primary数据库：
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE#BETWEEN 7 AND 10;
NAME
--------------------------------------------------------------------------------
/primary/thread1_dest/arcr_1_7.arc
/primary/thread1_dest/arcr_1_8.arc
/primary/thread1_dest/arcr_1_9.arc
Step 3. 将以上3个文件copy到Standby数据库的/standby路径下，并注册到Standby数据库中。
Standby数据库：
SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_7.arc’;
SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_8.arc’;
SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_9.arc’;
Step 4. 重启Log Apply服务。
如果是逻辑Standby数据库，则通过在逻辑Standby数据库上查询
DBA_LOGSTDBY_LOG视图：
SQL> SELECT THREAD#, SEQUENCE#,FILE_NAME FROM DBA_LOGSTDBY_LOG L
2> WHERE NEXT_CHANGE# NOT IN
3> (SELECT FIRST_CHANGE# FROMDBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
4> ORDER BY THREAD#,SEQUENCE#;
THREAD# SEQUENCE# FILE_NAME
---------- ---------------------------------------------------------
1 6 /disk1/oracle/dbs/log-1292880008_6.arc
1 10 /disk1/oracle/dbs/log-1292880008_10.arc
将文件编号中7-9的文件从Primary数据库服务器copy到逻辑Standby数据库服务器上，并使用ALTER DATABASE REGISTER命令进行注册，注册后重启Log Apply服务。
4． 日志应用服务Log Apply Services
Standby数据库的RFS进程在接收到传来的日志之后，会写入本地的Standby Redo Log或者Archived Log中，取决于LGWR和ARCH（详见3.3.4）。在Standby Redo Log归档完成之后或者Archived Log写完之后，MRP进程（物理Standby）或者LSP进程（逻辑Standby）会将日志应用到Standby数据库。根据日志应用类型的不同，Standby分为物理Standby（Redo Apply）和逻辑Standby（SQL Apply）（详见1.2）。
4.1. Redo Apply （物理Standby）
默认情况下，在Standby Redo Log归档之后，MRP进程才会开始恢复数据库。但是在LGWR SYNC模式下可以开启实时应用，或者设置DELAY属性开启延时应用。
Ø 开启Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE; 开启前台Redo Apply，开启之后该命令行窗口会停留在Redo Apply阶段并且无法响应其他操作，直到其他的session终止了日志应用。
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE {DISCONNECT | DISCONNECT FROM SESSION}; 开启后台Redo Apply，开启之后Redo Apply将在后台进行，命令行窗口可以继续操作。
Ø 开启Redo Apply实时应用：
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE USING CURRENT LOGFILE;
Ø 设置Redo Apply延时应用：
设置LOG_ARCHIVE_DEST_n参数中的delay属性（详见3.3.11）
Ø 取消Redo Apply延时功能：
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE NODELAY;
Ø 关闭Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE FINISH;
注意：cancel表示switchover, finish表示failover。
4.2. SQL Apply （逻辑Standby）
逻辑Standby是通过LSP进程，在Redo Standby Log归档之后，通过log miner技术从Redo中还原出SQL语句并应用到Standby数据库。
Ø 开启SQL Apply：
SQL> ALTER DATABASE START LOGICALSTANDBY APPLY;
Ø 开启SQL Apply实时应用：
SQL> ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;
Ø 开启SQL Apply延时应用：
方法同Redo Apply。
Ø 取消SQL Apply延时功能：
SQL> ALTER DATABASE START LOGICALSTANDBY APPLY NODELAY;
Ø 关闭SQL Apply：
SQL> ALTER DATABASE STOP LOGICALSTANDBY APPLY;
5． 角色切换
Data Guard角色切换有两种方式：switchover 和 failover。
5.1. Switchover
5.1.1. 物理Standby
Switchover切换不会丢失数据，切换之后原先的Primary数据库和Standby数据库角色互换，并且每个数据库在Data Guard配置中仍然继续运行。切换必须从Primary数据库发起，具体步骤如下：
Step 1. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY则表示可以正常切换，如果是SESSIONS ACTIVE，在切换时带上WITH SESSION SHUTDOWN 子句也可以成功切换。
Step 2. Primary数据库发起switchover切换，ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY; 切换之后重启实例 SHUTDOWN IMMEDIATE; STARTUPMOUNT;
Step 3. Standby数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO PRIMARY则表示可以正常切换，如果是SESSIONS ACTIVE，在切换时带上WITH SESSION SHUTDOWN 子句也可以成功切换。
Step 4. Standby数据库切换Primary数据库，ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 如果该Standby数据库从上次启动实例之后从未以read-only模式打开过，则直接ALTER DATABASE OPEN; 否则需要重启实例 SHUTDOWNIMMEDIATE; STARTUP;
Step 5. 如果必要的话，重启新Standby数据库的Log Apply服务 ALTER DATABASE RECOVER MANAGED STANDBYDATABASE; （详见4.1）。
5.1.2. 逻辑Standby
同物理Standby一样，switchover也必须从Primary数据库发起。
Step 1. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECT SWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY或SESSIONS ACTIVE则表示可以正常切换。
Step 2. Primary数据库执行SQL语句ALTER DATABASE PREPARE TO SWITCHOVER TOLOGICAL STANDBY;这一句SQL的作用是通知当前的Primary数据库准备切换至Standby，并从新的Primary数据库接收Redo Log。 此时V$DATABASE视图中SWITCHOVER_STATUS列的状态是PREPARING SWITCHOVER。
Step 3. Standby数据库执行SQL语句ALTER DATABASE PREPARE TO SWITCHOVER TOPRIMARY; 这一句SQL的作用是在Standby数据库上启动Redo传输服务，此时该Standby数据库会将Redo Log传输到当前的Primary数据库和其他的Standby数据库，但是不做应用。
Step 4. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列，在Step3完成后（LogMiner Multiversioned Data Dictionary被当前Primary数据库接收完成），SWITCHOVER_STATUS状态将变更为TO LOGICAL STANDBY。此时可以取消switchover切换，Primary和Standby分别执行SQL语句：ALTER DATABASE PREPARE TO SWITCHOVERCANCEL;
Step 5. Primary数据库执行ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY; 切换到Standby数据库。检查视图V$DATABASE中的SWITCHOVER_STATUS列，如果是TO_PRIMARY表示切换成功。
Step 6. Standby数据库执行ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 切换到Primary数据库。
Step 7. 在新的Standby数据库（即原先的Primary数据库）执行ALTER DATABASE START LOGICAL STANDBY APPLY; 开启SQL APPLY。
5.2. Failover
5.2.1. 物理Standby
如果使用了failover切换，那么故障的Primary数据库将会被踢出Data Guard配置。大部分情况下，除了将被切换成Primary数据库的那台Standby数据库，其余的Standby数据库在failover切换之后将继续在Data Guard中正常运行，不需要重启或作其他操作。在少数情况下，会需要为新的Primary数据库重做这些Standby，具体情况下面会描述到。如果要进行failover切换，请按照以下的步骤，不要使用ALTER DATABASE ACTIVATE STANDBY DATABASE;语句，否则会造成数据丢失。另外如果Data Guard不是最大保护或者最高可用的话，也会丢失部分数据。
Step 1. 解决gap（详见3.4）。如果Data Guard为最大保护或者最高可用，那么在Primary故障发生时是没有gap的，所以可以直接跳到Step4进行操作。
Step 2. 重复Step1直到没有gap。
Step 3. 待切换的Standby数据库检查视图V$ARCHIVED_LOG，查出最高的日志序列号 SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BYthread#) AS LAST from V$ARCHIVED_LOG; 从Primary数据库的归档日志路径下，找到任何比之前查询到的最高序列号更高的日志，并copy到Standby数据库，使用SQL语句ALTER DATABASE REGISTER PHYSICAL LOGFILE'filespec1'; 进行注册。完成之后重复Step1，确保没有gap。
Step 4. 从Standby数据库发起failover切换。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE; FORCE关键字表示让RFS进程直接终止，而不等待网络超时。
Step 5. 执行SQL语句ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY; 切换成Primary数据库。在执行完这一句SQL语句之后，目标Standby数据库将切换成Primary数据库，切换之后该数据库将无法再被作为Standby数据库，并且从老的Primary数据库再传来任何Redo也无法被应用。Data Guard中其余的Standby数据库将不需要重启，自动从新的Primary数据库接收日志并应用，当然前提是归档路径配置正确。
Step 6. 这一步是否需要取决于该Standby数据库从上次启动到现在是否曾经以只读模式打开，如果打开过，则需要重启，如果没有则直接open即可。
Step 7. 备份新的Primary数据库。
5.2.2. 逻辑Standby
Step 1. 将Primary数据库上会传输过来的归档日志copy到Standby数据库并注册。（详见3.4.2）
Step 2. 检查视图SELECT APPLIED_SCN, LATEST_SCN FROM V$LOGSTDBY_PROGRESS; 如果APPLIED_SCN和LATEST_SCN值相同，则表示Standby恢复的数据和Primary相同。如果Standby数据库没有启用SQL APPLY，则可以通过SQL语句ALTER DATABASE START LOGICAL STANDBY APPLYFINISH; 开启。
Step 3. 检查LOG_ARCHIVE_DEST_2是否配置，VALID_FOR属性是否正确配置。如果没有，先配置好。（详见3.3）
Step 4. Standby数据库执行ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY; 这句语句会终止RFS进程，并且将Standby Redo Log中还未应用的日志进行应用，然后停止SQL APPLY，将数据库切换为Primary数据库。如果没有加FINISH APPLY，那么Standby Redo Log中的日志将不会被应用。
Step 5. 在原先Data Guard配置中其余的Standby数据库上执行以下三步，重新和新的Primary数据库组成Data Guard。
1. ALTER SESSION DISABLE GUARD;
2.创建到新Primary数据库的db link
3.ALTER SESSION ENABLE GUARD;
Step 6. 在Standby数据库上执行ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARYdblink; 这里的dblink就是step 5创建的db link名字。
Step 7. 备份新的Primary数据库。
6． Data Guard物理Standby常用视图
| 视图名 | 数据库角色 | 视图内容描述 |
| V$ARCHIVE_DEST | Primary, physical | 显示Data Guard配置中所有的归档路径 |
| V$ARCHIVE_DEST_STATUS | Primary, physical | 显示归档路径的配置信息和状态 |
| V$ARCHIVE_GAP | Primary, physical | 显示归档日志gap，用于在failover切换时处理归档裂缝 |
| V$ARCHIVED_LOG | Primary, physical | 显示控制文件中保存的归档日志信息 |
| V$DATAGUARD_CONFIG | Primary, physical | 列出Data Guard中所有的DB_UNIQUE_NAME和 LOG_ARCHIVE_CONFIG参数信息 |
| V$DATAGUARD_STATS | Primary, physical | 显示所有Primary上未能传输给Standby的Redo Log信息，如果在Primary上查询该视图，那么结果值将被清除。 |
| V$DATAGUARD_STATUS | Primary, physical | 显示Data Guard中的事件信息，同时这些信息也会被记录在alert.log中和其他的trace文件中 |
| V$MANAGED_STANDBY | Physical only | 显示当前Standby的所有状态信息 |
| V$STANDBY_LOG | Primary, physical | 显示所有的Standby Redo Log信息 |
7． Data Guard 初始化参数
| 参数名 | Primary | Standby | 描述 |
| ARCHIVE_LAG_TARGET = seconds | YES | Physical only | 可选，在指定的时间后强制发生log switch事件。 |
| COMPATIBLE = release_number | YES | Logical and Physical | Data Guard最低版本要求是9.2.0.1.0 如果想进行switchover切换的话，Primary和Standby必须设置相同的release_number。 |
| CONTROL_FILE_RECORD_KEEP_TIME = number_of_days | YES | Logical and Physical | 可选，该参数可以防止记录在制定天数内被覆盖。 |
| CONTROL_FILES = ( 'control_file_name' ,’ control_file_name', '...') | YES | Logical and Physical | 必须，指定控制文件路径和文件名。 |
| DB_FILE_NAME_CONVERT = (‘location_of_primary_database_datafile' , 'location_of_standby_database_datafile_name' , '...' | NO | Physical only | 如果Standby和Primary上数据文件存储的路径不同，则必须设置该参数。（在Standby上设置时，先写Primary路径，后写Standby路径） |
| DB_UNIQUE_NAME = unique_service_provider_name_for_this_database | YES | Logical and Physical | 建议，如果设置LOG_ARCHIVE_CONFIG参数则必须设置该参数，用于唯一标识Data Guard中每个数据库。 |
| FAL_CLIENT = Oracle_Net_service_name | YES | Physical only | 详见3.4.1。 |
| FAL_SERVER = Oracle_Net_service_name | NO | Physical only | 详见3.4.1。 |
| INSTANCE_NAME | YES | Logical and Physical | 可选，如果Primary和Standby在同一台服务器上，那么可以通过指定该参数来区分实例。 |
| LOG_ARCHIVE_CONFIG = 'DG_CONFIG=(db_unique_name,db_unique_name, ...)' | YES | Logical and Physical | 建议，该参数会指定Data Guard中Primary和所有的Standby数据库。 |
| LOG_ARCHIVE_DEST_n = {LOCATION=path_nam |SERVICE=service_name, attribute,attribute, ... } | YES | Logical and Physical | 必须，详见3.3。 |
| LOG_ARCHIVE_DEST_STATE_n = {ENABLE|DEFER|ALTERNATE|RESET} | YES | Logical and Physical | 必须，详见3.2。 |
| LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc | YES | Logical and Physical | 可选，如果设置了STANDBY_ARCHIVE_DEST参数则必须。指定归档日志文件的命名规则。 |
| LOG_ARCHIVE_LOCAL_FIRST = [TRUE|FALSE] | YES | NO | 可选，如果是TRUE表示ARCn进程在传输给Standby之前，至少确保一组本地归档路径归档完成。 |
| LOG_ARCHIVE_MAX_PROCESSES = integer | YES | Logical and Physical | 详见3.1.5。 |
| LOG_ARCHIVE_MIN_SUCCEED_DEST = integer | YES | NO | 可选，至少有指定数量的归档路径成功接收到Redo Log之后，Primary才会重用Online Redo Log |
| LOG_ARCHIVE_TRACE = integer | YES | Logical and Physical | 可选，当Redo Log传输到Standby时进行跟踪，有效值有(0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096) |
| LOG_FILE_NAME_CONVERT = 'location_of_primary_database_redo_logs', 'location_of_standby_database_redo_logs' | NO | Logical and Physical | 同DB_FILE_NAME_CONVERT （在Standby上设置时，先写Primary路径，后写Standby路径） |
| PARALLEL_MAX_SERVERS = integer | YES | Logical only | 必须，设置逻辑Standby数据库中的最大并行进程数。该参数最小不能低于5，Oracle建议最小设置为9。具体计算方法为：（如果PGA_AGGREGATE_TARGET>0） PARALLEL_MAX_SERVERS=CPU_COUNT x PARALLEL_THREADS_PER_CPU x 10 |
| REMOTE_LOGIN_PASSWORDFILE = {EXCLUSIVE|SHARED] | YES | Logical and Physical | 必须，在Data Guard所有节点上设置。 |
| STANDBY_ARCHIVE_DEST = filespec | NO | Logical and Physical | 可选，指定Standby接收归档日志后的存放路径，该参数会覆盖LOG_ARCHIVE_DEST_n参数指定的路径。 （10g开始可以不设置此参数） |
| STANDBY_FILE_MANAGEMENT = {AUTO|MANUAL} | YES | Physical only | 必须，建议设置为AUTO，这样在Primary创建或者删除datafile时，Standby会自动进行同步操作。 |
| USER_DUMP_DEST = directory_path_name_of_trace_file | YES | Logical and Physical | 如果设置了LOG_ARCHIVE_TRACE参数则必须设置此参数。 |
From:http://blog.csdn.net/chrisguy1031/article/details/8308828
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
