1、RAC， Data Gurad， Stream 是 Oracle 高可用性体系中的三种工具，每个工具即可以独立应用，也可以相互配合。 他们各自的侧重点不同，适用场景也不同。 RAC 它的强项在于解决单点故障和负载均衡，因此 RAC 方案常用于 7*24 的核心系统，但 RAC 方案中的数据只有一份，尽管可以通过 RAID 等机制可以避免存储故障，但是数据本身是没有冗余的，容易形成单点故障。Data Gurad 通过冗余数据来提供数据保护，Data Gurad 通过日志同步机制保证冗余数据和主数据之前的同步，这种同步可以是实时，延时，同步，异步多种形式。Data Gurad 常用于异地容灾和小企
2、业的高可用性方案，虽然可以在 Standby 机器上执行只读查询，从而分散 Primary 苏菊哭的性能压力，但是 Data Gurad 决不是性能解决方案。Stream 是以 Oracle Advanced Queue 为基础实现的数据同步，提供了多种级别的灵活配置，并且 Oracle 提供了丰富的 API 等开发支持，Stream 更适用在应用层面的数据共享。在 Data Gurad 环境中，至少有两个数据库，一个处于 Open 状态对外提供服务，这个数据库叫作 Primary Database。 第二个处于恢复状态，叫作 Standby Database。 运行时 primary Dat
3、abase 对外提供服务，用户在 Primary Database 上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给 Standby Database。 这个日志会在 Standby Database 上重演，从而实现 Primary Database 和 Standby Database 的数据同步。Oracle Data Gurad 对这一过程进一步的优化设计，使得日志的传递，恢复工作更加自动化，智能化，并且提供一系列参数和命令简化了 DBA 工作。如果是可预见因素需要关闭 Primary Database，比如软硬件升级，可以把 Standby Database 切换
4、为 Primary Database 继续对外服务，这样即减少了服务停止时间，并且数据不会丢失。如果异常原因导致 Primary Database 不可用，也可以把 Standby Database 强制切换为Primary Database 继续对外服务，这时数据损失成都和配置的数据保护级别有关系。因此Primary 和 Standby 只是一个角色概念，并不固定在某个数据库中。一 Data Guard 架构DG 架构可以按照功能分成 3 个部分：1） 日志发送（Redo Send）2） 日志接收（Redo Receive）3） 日志应用（Redo Apply）1. 日志发送（Redo Se
5、nd）Primary Database 运行过程中，会源源不断地产生 Redo 日志，这些日志需要发送到Standy Database。 这个发送动作可以由 Primary Database 的 LGWR 或者 ARCH 进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。 1.1 使用 ARCH 进程1）Primary Database 不断产生 Redo Log，这些日志被 LGWR 进程写到联机日志。2）当一组联机日志被写满后，会发生日志切换（Log Switch） ，并且会触发本地归档，本地归档位置是采
6、用 LOG_ARCHIVE_DEST_1=LOCATION=/path 这种格式定义的。如：alter system set log_archive_dest_1 = LOCATION=/u01/arch scope=both;3）完成本地归档后，联机日志就可以被覆盖重用。4）ARCH 进程通过 Net 把归档日志发送给 Standby Database 的 RFS（Remote File Server） 进程。5）Standby Database 端的 RFS 进程把接收的日志写入到归档日志。6）Standby Database 端的 MRP(Managed Recovery Process
7、)进程（Redo Apply）或者 LSP 进程（SQL Apply）在 Standby Database 上应用这些日志，进而同步数据。用 ARCH 模式传输不写 Standby Redologs，直接保存成归档文件存放于 Standby 端。说明：逻辑 Standby 接收后将其转换成 SQL 语句，在 Standby 数据库上执行 SQL 语句实现同步，这种方式叫 SQL Apply。物理 Standby 接收完 Primary 数据库生成的 REDO 数据后，以介质恢复的方式实现同步，这种方式也叫 Redo Apply。注意：创建逻辑 Standby 数据库要先创建一个物理 Stand
8、by 数据库，然后再将其转换成逻辑 Standby 数据库。使用 ARCH 进程传递最大问题在于： Primary Database 只有在发生归档时才会发送日志到Standby Database。 如果 Primary Database 异常宕机，联机日志中的 Redo 内容就会丢失，因此使用 ARCH 进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用 LGWR 又分 SYNC（同步）和 ASYNC（异步）两种方式。在缺省方式下，Primary Database 使用的是 ARCH 进程，参数设置如下：alter system set log_archive_dest
9、_2 = SERVICE=ST scope=both;1.2 使用 LGWR 进程的 SYNC 方式1）Primary Database 产生的 Redo 日志要同时写道日志文件和网络。也就是说 LGWR 进程把日志写到本地日志文件的同时还要发送给本地的 LNSn 进程（Network Server Process） ，再由 LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个 LNS 进程，多个 LNS 进程能够并行工作。2）LGWR 必须等待写入本地日志文件操作和通过 LNSn 进程的网络传送都成功，Primary
10、Database 上的事务才能提交，这也是 SYNC 的含义所在。3）Standby Database 的 RFS 进程把接收到的日志写入到 Standby Redo Log 日志中。4）Primary Database 的日志切换也会触发 Standby Database 上的日志切换，即 Standby Database 对 Standby Redo Log 的归档，然后触发 Standby Database 的 MRP 或者 LSP 进程恢复归档日志。因为 Primary Database 的 Redo 是实时传递的，于是 Standby Database 端可以使用两种恢复方法： 实时
11、恢复（Real-Time Apply）： 只要 RFS 把日志写入 Standby Redo Log 就会立即进行恢复；归档恢复： 在完成对 Standby Redo Log 归档才触发恢复。Primary Database 默认使用 ARCH 进程，如果使用 LGWR 进程必须明确指定。使用LGWR SYNC 方式时，可以同时使用 NET_TIMEOUT 参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR 进程会抛出错误。 示例如下：alter system set log_archive_dest_2 = SERVICE=ST LGWR SYNC NET_TIMEOUT=
12、30 scope=both;1.3 使用 LGWR 进程的 ASYNC 方式使用 LGWR SYNC 方法的可能问题在于，如果日志发送给 Standby Database 过程失败，LGWR 进程就会报错。也就是说 Primary Database 的 LGWR 进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用 LGWR ASYNC 方式。 它的工作机制如下：1） Primary Database 一段产生 Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是 LGWR 进程只需成功写入日志文件就可以，不必等待 LNSn 进程的网络传送成功。2） LNSn
13、进程异步地把日志内容发送到 Standby Database。多个 LNSn 进程可以并发发送。3） Primary Database 的 Online Redo Log 写满后发生 Log Switch，触发归档操作，也触发Standby Database 对 Standby Database 对 Standby Redo Log 的归档；然后触发 MRP 或者LSP 进程恢复归档日志。因为 LGWR 进程不会等待 LNSn 进程的响应结果，所以配置 LGWR ASYNC 方式时不需要NET_TIMEOUT 参数。示例如下：alter system set log_archive_dest_
14、2 = SERVICE=ST LGWR ASYNC scope=both;2. 日志接收（Redo Receive）Standby Database 的 RFS（Remote File Server）进程接收到日志后，就把日志写到 Standby Redo Log 或者 Archived Log 文件中，具体写入哪个文件，取决于 Primary 的日志传送方式和 Standby database 的位置。如果写到 Standby Redo Log 文件中，则当 Primary Database 发生日志切换时，也会触发 Standby Database 上的 Standby Redo Log
15、的日志切换，并把这个Standby Redo Log 归档。 如果是写到 Archived Log，那么这个动作本省也可以看作是个归档操作。在日志接收中，需要注意的是归档日志会被放在什么位置：1） 如果配置了 STANDBY_ARCHIVE_DEST 参数，则使用该参数指定的目录。2） 如果某个 LOG_ARCHIVE_DEST_n 参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录。3） 如果数据库的 COMPATIBLE 参数大于等于 10.0，则选取任意一个LOG_ARCHIVE_DEST_n 的值。4） 如果 STANDBY_ARCH
16、IVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置，使用缺省的 STANDBY_ARCHIVE_DEST 参数值，这个缺省值是$Oracle_HOME/dbs/arc.3. 日志应用（Redo Apply）日志应用服务，就是在 Standby Database 上重演 Primary Database 日志，从而实现两个数据库的数据同步。 根据 Standby Database 重演日志方式的不同，可分为物理Standby（Physical Standby） 和 逻辑 Standby（Logical Standby） 。Physical Standby 使用的是 Med
17、ia Recovery 技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。 Physical Standby 数据库只能在 Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。Logical Standby 使用的是 Logminer 技术，通过把日志内容还原成 SQL 语句，然后 SQL引擎执行这些语句，Logminer Standby 不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。 Logical Standb
18、y 数据库可以在恢复的同时进行读写操作。Standby 数据库的相关进程读取接收到的 REDO 数据（可能来自于 Standby 端的归档文件，也可能来自于 Standby Redologs） ，再将其写入 Standby 数据库。保存之后数据又是怎么生成的呢？两种方式：物理 Standby 通过 REDO 应用，逻辑 Standby 通过 SQL 应用根据 Redo Apply 发生的时间可以分成两种： 一种是实时应用（Real-Time Apply） ， 这种方式必须 Standby Redo Log，每当日志被写入Standby Redo Log 时，就会触发恢复，使用这种方式的好处在与
19、可以减少数据库切换（Switchover 或者 Failover）的时间，因为切换时间主要用在剩余日志的恢复上。 另一种是归档时应用，这种方式在 Primary Database 发生日志切换，触发 Standby Database 归档操作，归档完成后触发恢复。 这也是默认的恢复方式。如果是 Physical Standby，可以使用下面命令启用 Real-Time：Alter database recover managed standby database using current logfile;如果是 Logical Standby，可以使用下面命令启用 Real-Time：Alt
20、er database start logical standby apply immediate;查看是否使用 Real-Time apply：Select recovery_mode from v$archive_dest_status;SQL set wrap offSQL select process,status,thread#,sequence#,client_pid from v$managed_standby;PROCESS STATUS THREAD# SEQUENCE# CLIENT_PID- - - - -ARCH CONNECTED 0 0 240ARCH CONNEC
21、TED 0 0 196ARCH CONNECTED 0 0 1944ARCH CONNECTED 0 0 3956MRP0 WAIT_FOR_LOG 1 30843 N/ARFS RECEIVING 1 30838 2620RFS RECEIVING 1 30837 2612RFS RECEIVING 1 30833 2652RFS ATTACHED 1 30841 2628RFS ATTACHED 1 30835 2604RFS ATTACHED 1 30842 2608二 数据保护模式Data Guard 允许定义 3 钟数据保护模式，分别是最大保护（Maximum Protection）
22、 ，最大可用（Maximum Availability）和 最大性能（Maximum Performance ） 。1. 最大保护（Maximum Protection）这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其 REDO 不仅被写入到本地的 Online Redologs，还要同时写入到 Standby 数据库的Standby Redologs，并确认 REDO 数据至少在一个 Standby 数据库中可用（如果有多个的话），然后才会在 Primary 数据库上提交。如果出现了什么故障导致 Standby 数据库不可用的话（比如网络中断） ，Prim
23、ary 数据库会被 Shutdown，以防止数据丢失。使用这种方式要求 Standby Database 必须配置 Standby Redo Log，而 Primary Database 必须使用 LGWR，SYNC ，AFFIRM 方式归档到 Standby Database.2. 最高可用性（Maximum availability）这种模式在不影响 Primary 数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台 Standby 数据库的Standby Redologs 中，不过与最大保护模式不同的是，如果出现故障导致
24、Standby 数据库无法访问，Primary 数据库并不会被 Shutdown，而是自动转为最高性能模式，等 Standby 数据库恢复正常之后，Primary 数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求 Standby Database 必须配置 Standby Redo Log，而 Primary Database 必须使用LGWR，SYNC，AFFIRM 方式归档到 Standby Database.3. 最高性能（Maximum performance）缺省模式。 这种模式在不影响 Primary 数据库性能前提下，提
25、供最高级别的数据保护策略。事务可以随时提交，当前 Primary 数据库的 REDO 数据至少需要写入一个 Standby 数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对 Primary 数据库的性能有轻微影响。这也是创建 Standby 数据库时，系统的默认保护模式。这种方式可以使用 LGWR ASYNC 或者 ARCH 进程实现，Standby Database 也不要求使用 Standby Redo Log。4. 修改数据保护模式步骤1）关闭数据库，重启到 Mount 状态，如果是 RAC，需要关闭所有实例，然后只启动一个实例到
26、 mount 状态。2）修改模式：语法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION | AVAILABILITY | PERFORMANCE; 如：SQLALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;3) 打开数据库： alter database open;4) 确认修改数据保护模式：SQLselect protection_mode,protection_level from v$database; 三 自动裂缝检测和解决当 Primary Da
27、tabase 的某些日志没有成功发送到 Standby Database， 这时候发生饿了归档裂缝（Archive Gap） 。缺失的这些日志就是裂缝（Gap） 。 Data Guard 能够自动检测，解决归档裂缝，不需要DBA 的介入。这需要配置 FAL_CLIENT， FAL_SERVER 这两个参数（FAL: Fetch Archive Log） 。从 FAL 这个名字可以看出，这个过程是 Standby Database 主动发起的“取”日志的过程，Standby Database 就是 FAL_CLIENT. 它是从 FAL_SERVER 中取这些 Gap， 10g 中，这个FAL_
28、SERVER 可以是 Primary Database， 也可以是其他的 Standby Database。如：FAL_SERVER=PR1,ST1,ST2;FAL_CLIENT 和 FAL_SERVER 两个参数都是 Oracle Net Name。 FAL_CLIENT 通过网络向 FAL_SERVER 发送请求，FAL_SERVER 通过网络向 FAL_CLIENT 发送缺失的日志。 但是这两个连接不一定是一个连接。 因此 FAL_CLIENT 向 FAL_SERVER 发送请求时，会携带 FAL_CLIENT 参数值，用来告诉 FAL_SERVER 应该向哪里发送缺少的日志。 这个参数
29、值也是一个 Oracle Net Name，这个 Name 是在 FAL_SERVER 上定义的，用来指向FAL_CLIENT.当然，除了自动地日志缺失解决，DBA 也可以手工解决。 具体操作步骤如下：1） 查看是否有日志 GAP： SQL SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; SQL SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 2） 如果有，则拷贝过来3） 手工的
30、注册这些日志： SQL ALTER DATABASE REGISTER LOGFILE 路径; 四 指定日志发送对象1VALID_FOR 属性指定传输及接收对象LOG_ARCHIVE_DEST_n 参数中的 VALID_FOR 属性，用来指定传输的内容。从字面理解VALID_FOR 就是基于那谁有效，该属性有两个参数值需要指定： REDO_LOG_TYPE 和DATABASE_ROLE，我们基本上可以将其理解为：发送指定角色生成的指定类型的日志文件，该参数的主要目的是为了确保，一旦发生角色切换操作后数据库的正常运转。其中，REDO_LOG_TYPE 和 DATABASE_ROLE 两个参数可供
31、选择的参数值如下：REDO_LOG_TYPE：可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。 DATABASE_ROLE：可设置为 PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。 注意：VALID_FOR 参数默认值是：VALID_FOR=（ALL_LOGFILES,ALL_ROLES） 。 推荐手动设置该参数而不要使用默认值，在某些情况下默认的参数值不一定合适，如逻辑Standby 在默认情况下就处于 OPEN READ WRITE 模式，不仅有 REDO 数据而且还包含多种日志文件（Online Redologs、
32、Archived Redologs 及 Standby Redologs） 。默认情况下，逻辑 Standby 数据库生成的归档文件和接收到的归档文件在相同的路径下，这既不便于管理，也极有可能带来一些隐患。建议对每个 LOG_ARCHIVE_DEST_n 参数设置合适的 VALID_FOR 属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。2通过 DB_UNIQUE_NAME 属性指定数据库DB_UNIQUE_NAME 属性是 10g 版本新增加的一个关键字，在之前版本并没有这一说法。该属性的作用是指定唯一的 Oracle 数据库名称，也正因有了 DB_UNIQUE_NAME
33、，REDO数据在传输过程中才能确认传输到 DBA 希望被传输到的数据库上。当然要确保 REDO 数据被传输到指定服务器，除了在 LOG_ARCHIVE_DEST_n 参数中指定正确 DB_UNIQUE_NAME 属性之外，还有一个初始化参数 LOG_ARCHIVE_CONFIG 也需要进行正确的配置。该参数除了指定 Data Guard 环境中的唯一数据库名外，还包括几个属性，用来控制 REDO 数据的传输和接收：SEND：允许数据库发送数据到远端。RECEIVE：允许 Standby 接收来自其他数据库的数据。NOSEND,NORECEIVE：自然就是禁止喽。例如，设置 Primary 数据
34、库不接收任何归档数据，可以做如下的设置：LOG_ARCHIVE_CONFIG=NORECEIVE,DG_CONFIG= (PRI,ST) 如果做了如上的设置，如果该服务器发生了角色切换，那它也没有接收 REDO 数据的能力。五 Data Guard 环境应配置的初始化参数下列参数为 Primary 角色相关的初始化参数DB_NAME注意保持同一个 Data Guard 中所有数据库 DB_NAME 相同例如：DB_NAME=DaveDB_UNIQUE_NAME为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非 DBA 主动修改它例如：DB_UNIQUE_NAME=DavePr
35、eLOG_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 官方文档。D
36、ata Guard 白皮书第 14 章专门介绍了该参数各属性及子参数的功能和设置)。例如：LOG_ARCHIVE_DEST_1=LOCATION=l:OracleoradataDave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePreLOG_ARCHIVE_DEST_STATE_n是否允许 REDO 传输服务传输 REDO 数据到指定的路径。该参数共拥有 4 个属性值，功能各不相同。REMOTE_LOGIN_PASSWORDFILE推荐设置参数值为 EXCLUSIVE 或者 SHARED，注意保证相同 Data Guard 配置
37、中所有DB 服务器 SYS 密码相同以下参数为与 Standby 角色相关的参数（建议在 Primary 数据库的初始化参数中也进行设置，这样即使发生角色切换，新的 Standby 也能直接正常运行）FAL_SERVER指定一个 Net 服务名，该参数值对应的数据库应为 Primary 角色。当本地数据库为Standby 角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器例如：FAL_SERVER=DavePre提示：FAL 是 Fetch Archived Log 的缩写FAL_SERVER 参数支持多个参数值的哟，相互间以逗号分隔FAL_CLIENT又指定一个 N
38、et 服务名，该参数对应数据库应为 Standby 角色。当本地数据库以 Primary角色运行时，向参数值中指定的站点发送中断的归档文件例如：FAL_CLIENT=DaveDGFAL_CLIENT 参数也支持多个参数值，相互间以逗号分隔。DB_FILE_NAME_CONVERTStandby 数据库的数据文件路径与 Primary 数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT 参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式例如：DB_FILE_NAME_CONVERT=f:oradataDavePre,l:
39、oradataDaveDGLOG_FILE_NAME_CONVERT使用方式与上相同，只不过 LOG_FILE_NAME_CONVERT 专用来转换日志文件路径例如：LOG_FILE_NAME_CONVERT=f:oradataDavePre,l:oradataDaveDGSTANDBY_FILE_MANAGEMENT如果 Primary 数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby 数据库中作相应修改。设为 AUTO 表示自动管理。设为 MANUAL 表示需要手工管理例如：STANDBY_FILE_MANAGEMENT=AUTO对于归档失败的处理，LOG_AR
40、CHIVE_DEST_n 参数有几个属性，可以用来控制归档过程中出现故障时应该采取的措施。1REOPEN 指定时间后再次尝试归档使用 REOPEN=seconds（默认为 300 秒）属性，在指定时间重复尝试向归档目的地进行归档操作，如果该参数值设置为 0，则一旦失败就不会再尝试重新连接并发送，直到下次REDO 数据再被归档时会重新尝试。例如，设置 REOPEN 为 100 秒：LOG_ARCHIVE_DEST_2=SERVICE=DavePrimary LGWR ASYNC REOPEN=100 2ALTERNATE 指定替补的归档目的地ALTERNATE 属性定义一个替补的归档目的地，所谓
41、替补就是一旦主归档目的地因各种原因无法使用，则临时向 ALTERNATE 属性中指定的路径写。例如：LOG_ARCHIVE_DEST_1=LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2 LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_2=LOCATION=/disk2 LOG_ARCHIVE_DEST_STATE_2=ALTERNATE 上述参数设置归档路径为/disk1，当/disk1 路径下无法成功归档时，自动尝试向 /disk2 路径下归档文件。从功能上来看，REOPEN 与 ALTERNATE
42、是有一定重复的，不过需要注意一点， REOPEN属性比 ALTERNATE 属性的优先级要高，如果你指定 REOPEN 属性的值0，则LGWR（或 ARCn）进程会首先尝试向主归档目的地写入，直到达到最大重试次数，如果仍然写入失败，才会向 ALTERNATE 属性指定的路径写。3MAX_FAILURE 控制失败尝试次数用 REOPEN 指定失败后重新尝试的时间周期，MAX_FAILURE 则控制失败尝试的次数。例如，设置 LOG_ARCHIVE_DEST_1 在本地归档文件时，如果遇到错误，则每隔 100 秒尝试一次，共尝试不超过 3 次，设置如下：LOG_ARCHIVE_DEST_1=LOC
43、ATION=E:ora10goradatajsspdg REOPEN=100 MAX_FAILURE=3 六 物理 Standby 和逻辑 Standby 的区别Standby 数据库类型分为两类：物理 Standby 和逻辑 Standby。1物理 Standby我们知道物理 Standby 与 Primary 数据库完全一模一样，DG 通过 REDO 应用来维护物理Standby 数据库。通常在物理 Standby 没有执行 REDO 应用操作的时候，可以将物理 Standby 数据库以READ ONLY 模式打开，如果数据库中指定了 Flashback Area 的话，甚至还可以被临时性
44、的置为 READ WRITE 模式，操作完之后再通过 Flashback Database 特性恢复回 READ WRITE 前的状态，以便继续接收 Primary 端发送的 REDO 并应用。REDO 应用。物理 Standby 通过 REDO 应用来保持与 Primary 数据库的一致性，所谓的REDO 应用，实质是通过 Oracle 的恢复机制，应用归档文件（或 Standby Redologs 文件）中的 REDO 数据。恢复操作属于块对块的应用。如果正在执行 REDO 应用的操作，Oracle数据库就不能被 Open。READ ONLY 模式打开。以 READ ONLY 模式打开后，
45、可以在 Standby 数据库执行查询或备份等操作（变相减轻 Primary 数据库压力） 。此时 Standby 数据库仍然能够继续接收Primary 数据库发送的 REDO 数据，不过并不会应用，直到 Standby 数据库重新恢复 REDO应用。也就是说在 READ ONLY 模式下不能执行 REDO 应用， REDO 应用时数据库肯定处于未打开状态。如果需要的话，你可以在两种状态间转换，如先应用 REDO，然后将数据库置为READ ONLY 状态，需要与 Primary 同步时再次执行 REDO 应用命令，切换回 REDO 应用状态。呵呵，人生就是循环，数据库也是一样。提 示： Ora
46、cle 11g 版本中增强物理 Standby 的应用功能，在 11g 版本中，物理 Standby 可以在 OPEN READ ONLY 模式下继续应用 REDO 数据，这就极大地提升了物理 Standby 数据库的应用场合。READ WRITE 模式打开。如果以 READ WRITE 模式打开，那么 Standby 数据库将暂停从Primary 数据库接收 REDO 数据，并且暂时失去灾难保护的功能。当然，以 READ WRITE模式打开也并非一无是处，如你可能需要临时调试一些数据，但又不方便在正式库中操作，那就可以临时将 Standby 数据库置为 READ WRITE 模式，操作完之后
47、将数据库闪回到操作前的状态（闪回之后，Data Guard 会自动同步，不需要重建物理 Standby，不过如果从另一个方向看，没有启动闪回，那就回不到 READ WRITE 前的状态了） 。物理 Standby 特点如下：（1）灾难恢复及高可用性。物理 Standby 提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理 switchover/failover 角色转换及在更短的计划内或计划外停机时间。（2）数据保护。使用物理 Standby 数据库，DG 能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理 Standby 是基于块对块的复制，因此与对象、语句无关
48、，Primary 数据库上有什么，物理 Standby 数据库端也会有什么。（3）分担 Primary 数据库压力。通过将一些备份任务、仅查询的需求转移到物理 Standby数据库，可以有效节省 Primary 数据库的 CPU 及 I/O 资源。（4）提升性能。物理 Standby 所使用的 REDO 应用技术使用最底层的恢复机制，这种机制能够绕过 SQL 级代码层，因此效率最高。2逻辑 Standby逻辑 Standby 也要通过 Primary 数据库（或其备份，或其复制库，如物理 Standby）创建，因此在创建之初与物理 Standby 数据库类似。不过由于逻辑 Standby 通过
49、 SQL 应用的方式应用 REDO 数据，因此逻辑 Standby 的物理文件结构，甚至数据的逻辑结构都可以与Primary 不一致。与物理 Standby 不同，逻辑 Standby 正常情况下是以 READ WRITE 模式打开，用户可以在任何时候访问逻辑 Standby 数据库，就是说逻辑 Standby 是在 OPEN 状态执行 SQL 应用。同样有利也有弊，由于 SQL 应用自身特点，逻辑 Standby 对于某些数据类型及一些DDL/DML 语句会有操作上的限制。可以在视图 DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。逻辑 Standby 的读写打开可以使它做报表系统，
