Oracle Data Guard 理论知识（二）

joozh

　　
　　转载标注：
　　原文地址：http://blog.csdn.net/tianlesoftware/article/details/5514082
　　
　　
　　五．Data Guard环境应配置的初始化参数
　　下列参数为Primary角色相关的初始化参数
　　DB_NAME
　　注意保持同一个Data Guard中所有数据库DB_NAME相同
　　例如：DB_NAME=Dave
　　DB_UNIQUE_NAME
　　为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非DBA主动修改它
　　例如：DB_UNIQUE_NAME=DavePre
　　LOG_ARCHIVE_CONFIG
　　该参数用来控制从远端数据库接收或发送REDO数据，通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME（含Primary数据库和Standby数据库），以逗号分隔，SEND/NOSEND属性控制是否可以发送，RECEIVE/NORECEIVE属性控制是否能够接收
　　例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'
　　LOG_ARCHIVE_DEST_n
　　归档文件的生成路径。该参数非常重要，并且属性和子参数也特别多(可以直接查询Oracle官方文档。Data Guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如：
　　LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'
　　LOG_ARCHIVE_DEST_STATE_n
　　是否允许REDO传输服务传输REDO数据到指定的路径。该参数共拥有4个属性值，功能各不相同。
　　REMOTE_LOGIN_PASSWORDFILE
　　推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有DB服务器SYS密码相同
　　以下参数为与Standby角色相关的参数（建议在Primary数据库的初始化参数中也进行设置，这样即使发生角色切换，新的Standby也能直接正常运行）
　　FAL_SERVER
　　指定一个Net服务名，该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器
　　例如：FAL_SERVER=DavePre
　　提示：FAL是Fetch Archived Log的缩写
　　FAL_SERVER参数支持多个参数值的哟，相互间以逗号分隔
　　FAL_CLIENT
　　又指定一个Net服务名，该参数对应数据库应为Standby角色。当本地数据库以Primary角色运行时，向参数值中指定的站点发送中断的归档文件
　　例如：FAL_CLIENT=DaveDG
　　FAL_CLIENT参数也支持多个参数值，相互间以逗号分隔。
　　DB_FILE_NAME_CONVERT
　　Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式
　　例如：DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'
　　LOG_FILE_NAME_CONVERT
　　使用方式与上相同，只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径
　　例如：
　　LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'
　　STANDBY_FILE_MANAGEMENT
　　如果Primary数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理
　　例如：STANDBY_FILE_MANAGEMENT=AUTO
　　对于归档失败的处理，LOG_ARCHIVE_DEST_n参数有几个属性，可以用来控制归档过程中出现故障时应该采取的措施。
　　1．REOPEN 指定时间后再次尝试归档
　　使用REOPEN=seconds（默认为300秒）属性，在指定时间重复尝试向归档目的地进行归档操作，如果该参数值设置为0，则一旦失败就不会再尝试重新连接并发送，直到下次REDO数据再被归档时会重新尝试。
　　例如，设置REOPEN为100秒：
　　LOG_ARCHIVE_DEST_2='SERVICE=DavePrimary LGWR ASYNC REOPEN=100'
　　2．ALTERNATE 指定替补的归档目的地
　　ALTERNATE属性定义一个替补的归档目的地，所谓替补就是一旦主归档目的地因各种原因无法使用，则临时向ALTERNATE属性中指定的路径写。
　　例如：

　　LOG_ARCHIVE_DEST_1='LOCATION=/disk1>　　LOG_ARCHIVE_DEST_STATE_1=ENABLE
　　LOG_ARCHIVE_DEST_2='LOCATION=/disk2'
　　LOG_ARCHIVE_DEST_STATE_2=ALTERNATE
　　上述参数设置归档路径为/disk1，当/disk1路径下无法成功归档时，自动尝试向/disk2路径下归档文件。
　　从功能上来看，REOPEN与ALTERNATE是有一定重复的，不过需要注意一点，REOPEN属性比ALTERNATE属性的优先级要高，如果你指定REOPEN属性的值>0，则LGWR（或ARCn）进程会首先尝试向主归档目的地写入，直到达到最大重试次数，如果仍然写入失败，才会向ALTERNATE属性指定的路径写。
　　3．MAX_FAILURE 控制失败尝试次数
　　用REOPEN指定失败后重新尝试的时间周期，MAX_FAILURE则控制失败尝试的次数。
　　例如，设置LOG_ARCHIVE_DEST_1在本地归档文件时，如果遇到错误，则每隔100秒尝试一次，共尝试不超过3次，设置如下：
　　LOG_ARCHIVE_DEST_1='LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3'
　　六．物理Standby 和逻辑Standby 的区别
　　Standby数据库类型分为两类：物理Standby和逻辑Standby。
　　1．物理Standby
　　我们知道物理Standby与Primary数据库完全一模一样，DG通过REDO应用来维护物理Standby数据库。
　　通常在物理Standby没有执行REDO应用操作的时候，可以将物理Standby数据库以READ ONLY模式打开，如果数据库中指定了Flashback Area的话，甚至还可以被临时性的置为READ WRITE模式，操作完之后再通过Flashback Database特性恢复回READ WRITE前的状态，以便继续接收Primary端发送的REDO并应用。
　　REDO应用。物理Standby通过REDO应用来保持与Primary数据库的一致性，所谓的REDO应用，实质是通过Oracle的恢复机制，应用归档文件（或Standby Redologs文件）中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作，Oracle数据库就不能被Open。
　　READ ONLY模式打开。以READ ONLY模式打开后，可以在Standby数据库执行查询或备份等操作（变相减轻Primary数据库压力）。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据，不过并不会应用，直到Standby数据库重新恢复REDO应用。
　　也就是说在READ ONLY模式下不能执行REDO应用，REDO应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，如先应用REDO，然后将数据库置为READ ONLY状态，需要与Primary同步时再次执行REDO应用命令，切换回REDO应用状态。呵呵，人生就是循环，数据库也是一样。
　　提示：Oracle 11g版本中增强物理Standby的应用功能，在11g版本中，物理Standby可以在OPEN READ ONLY模式下继续应用REDO数据，这就极大地提升了物理Standby数据库的应用场合。
　　READ WRITE模式打开。如果以READ WRITE模式打开，那么Standby数据库将暂停从Primary数据库接收REDO数据，并且暂时失去灾难保护的功能。当然，以READ WRITE模式打开也并非一无是处，如你可能需要临时调试一些数据，但又不方便在正式库中操作，那就可以临时将Standby数据库置为READ WRITE模式，操作完之后将数据库闪回到操作前的状态（闪回之后，Data Guard会自动同步，不需要重建物理Standby，不过如果从另一个方向看，没有启动闪回，那就回不到READ WRITE前的状态了）。
　　物理Standby特点如下：
　　（1）灾难恢复及高可用性。物理Standby提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。
　　（2）数据保护。使用物理Standby数据库，DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制，因此与对象、语句无关，Primary数据库上有什么，物理Standby数据库端也会有什么。
　　（3）分担Primary数据库压力。通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。
　　（4）提升性能。物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。
　　2．逻辑Standby
　　逻辑Standby也要通过Primary数据库（或其备份，或其复制库，如物理Standby）创建，因此在创建之初与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据，因此逻辑Standby的物理文件结构，甚至数据的逻辑结构都可以与Primary不一致。
　　与物理Standby不同，逻辑Standby正常情况下是以READ WRITE模式打开，用户可以在任何时候访问逻辑Standby数据库，就是说逻辑Standby是在OPEN状态执行SQL应用。同样有利也有弊，由于SQL应用自身特点，逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。
　　逻辑Standby 的读写打开可以使它做报表系统，这样减轻系统的压力。
　　除了上述物理Standby中提到的类似灾难恢复、高可用性及数据保护等特点之外，逻辑Standby还有下列一些特点：
　　（1）有效地利用备机的硬件资源。除灾难恢复外，逻辑Standby数据库还可用于其他业务需求。如通过在Standby数据库创建额外的索引、物化视图等提高查询性能并满足特定业务需要；又如创建新的SCHEMA（该SCHEMA在Primary数据库端并不存在），然后在这些SCHEMA中执行那些不适于在Primary数据库端执行的DDL或者DML操作等。
　　（2）分担Primary数据库压力。逻辑Standby数据库可以在保持与Primary同步时仍然置于打开状态，这使得逻辑Standby数据库能够同时用于数据保护和报表操作，从而将主数据库从报表和查询任务中解脱出来，节约宝贵的CPU和I/O资源。
　　（3）平滑升级。可以通过逻辑Standby来实现如跨版本升级，为数据库打补丁等操作。应该说应用的空间很大，而带来的风险却很小（前提是如果你拥有足够的技术实力。另外虽然物理Standby也能够实现一些升级操作，但如果跨平台的话恐怕就力不从心了，所以此项没有作为物理Standby的特点列出），我个人认为这是一种值得可行的在线的滚动的平滑的升级方式，如果你的应用支持创建逻辑Standby的话。
　　七．Log应用服务（Log Apply Services）
　　Data Guard通过应用REDO维持Primary数据库与各Standby数据库之间的一致性，在后台默默无闻地支撑着的就是传说中的Log应用服务。Log应用服务又分以下两种方式：
　　REDO应用：物理Standby数据库专用，通过介质恢复的方式保持与Primary数据库的同步。
　　SQL应用：逻辑Standby数据库专用，核心是通过LogMiner分析出SQL语句在Standby端执行。
　　因此物理Standby在应用REDO数据时必须是MOUNT状态，而逻辑Standby则是以READ WRITE模式打开并应用REDO数据，不过被维护的对象默认处于只读状态，无法在逻辑Standby端直接修改。
　　7.1  Log应用服务配置选项
　　默认情况下，Log应用服务会等待单个归档文件全部接收之后再启动应用，如果Standby数据库配置了Standby Redologs，就可以打开实时应用（Real-Time Apply），这样Data Guard就不需要再等待接收完归档文件，只要RFS进程将REDO数据写入Standby Redologs，即可通过MRP/LSP实时写向Standby数据库。
　　7.1.1．REDO数据实时应用
　　启动实时应用的优势在于，REDO数据不需要等待归档完成，接收到即可被应用，这样执行角色切换时，操作能够执行得更快，因为日志是被即时应用的。
　　要启动实时应用也简单，前提是Standby数据库端配置了Standby Redologs。
　　物理Standby要启用实时应用，要在启动REDO应用的语句后附加USING CURRENT LOGFIE子句，例如：

　　SQL>>　　逻辑Standby要启用实时应用，只需要在启动REDO应用的语句后附加IMMEDIATE子句即可，例如：

　　SQL>>　　7.1.2．REDO数据延迟应用
　　有实时就有延迟，某些情况下你可能不希望Standby数据库与Primary太过同步，那就可以在Primary数据库端发送REDO数据的相应LOG_ARCHIVE_DEST_n参数中指定DELAY属性（单位为分钟，如果指定了DELAY属性，但没有指定值，则默认是30分钟）。
　　注意：该属性并不是说延迟发送REDO数据到Standby，而是指明归档到Standby后，开始应用的时间。
　　例如：设置LOG_ARCHIVE_DEST_3的DELAY属性为15分钟：

　　SQL>>　　(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave DELAY=15';
　　不过，如果DBA在启动REDO应用时指定了实时应用，那么即使在LOG_ ARCHIVE_DEST_n参数中指定了DELAY属性，Standby数据库也会忽略DELAY属性。
　　另外，Standby端还可以在启动REDO应用时，通过附加NODELAY子句的方式，取消延迟应用。
　　物理Standby可以通过下列语句取消延迟应用：

　　SQL>>　　逻辑Standby可以通过下列语句取消延迟应用：

　　SQL>>　　一般设置延迟应用的需求都是基于容错方面的考虑，如Primary数据库端由于误操作，数据被意外修改或删除，只要Standby数据库尚未应用这些修改，你就可以快速从Standby数据库中恢复这部分数据。不过自Oracle从9i版本开始提供FLASHBACK特性之后，对于误操作使用FLASHBACK特性进行恢复，显然更加方便快捷，因此DELAY方式延迟应用已经非常少见了。
　　7.2  应用REDO数据到Standby数据库
　　7.2.1．物理Standby应用REDO数据
　　物理Standby启动REDO应用，数据库要处于MOUNT状态或是OPEN READ ONLY状态，启动REDO应用的命令相信大家已经非常熟悉了。
　　前台应用：

　　SQL>>　　语句执行完成后，不会将控制权返回到命令行窗口，除非你手动中止应用。在这种情况下如果还需要对数据库进行操作，只能新开一个命令行连接，在Oracle 8i刚推出Standby特性时（那时不叫Data Guard），只提供了这种方式。
　　后台应用：

　　SQL>>　　这是现在比较通用的方式，语句执行完后，控制权自动返回到当前的命令行模式，REDO应用以后台进程运行。
　　启动实时应用，附加USING CURRENT LOGFILE子句即可：

　　SQL>>　　如果要停止REDO应用，执行下列语句即可：

　　SQL>>　　7.2.2．逻辑Standby应用REDO数据
　　SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行，因此逻辑Standby需要启动至OPEN状态。
　　（1）启动SQL应用。逻辑Standby数据库启动SQL应用没有前、后台运行之说，语句执行完之后，控制权就会自动返回当前命令行窗口。
　　要启动SQL应用，直接执行下列语句即可：

　　SQL>>　　如果要启动实时应用，附加IMMEDIATE子句即可，例如：

　　SQL>>　　（2）停止SQL应用，如：

　　SQL>>　　由于是执行SQL语句的方式应用REDO数据，因此上述语句的执行需要等待当前执行的SQL触发的事务结束，才能真正停止REDO应用的状态。
　　如果不考虑事务执行情况，马上停止REDO应用，可以通过下列的语句来完成：

　　SQL>>