|
在Data Guard环境中，至少有2个数据库，一个处于Open状态对外提供服务，称为Primary Database，一个处于恢复状态，称为 Standby Database。 运行时primary Database对外提供服务，用户在Primary Database上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database。这个日志会在Standby Database上重演，从而实现Primary Database和Standby Database的数据同步。 架构 按功能分成3部分日志发送(Redo Send) 日志接送(Redo Receive) 日志应用(Redo Apply) 日志发送在Primary Database上产生的Redo Log发送到Standy Database端，由主库上的LGWR或ARCH进程完成。 使用ARCH进程方式
Primary Database中持续产生的Redo Log，会被LGWR进程写入到在线联机日志文件
当一组联机日志被写满后，便会发生日志切换(logfile switch)，并触发归档本地日志 其配置定义格式：LOG_ARCHIVE_DEST_1='LOCATION=/path'
完成本地归档后，联机日志就可以被覆盖重用
ARCH进程通过Net方式将归档日志发送给Standby Database端的RFS（remote file server）进程 缺省情况下，使用ARCH发送日志，配置定义：LOG_ARCHIVE_DEST_2='SERVICE=biudbst'
Standby Database端的RFS进程把接送到的日志写入到归档日志文件。用ARCH模式传输不写Standby Redologs，直接保存成归档文件存放于Standby端
Standby Database端的MRP（Managed Recovery Process）进程[Redo Apply]或者LSP（logical standby process）进程[SQL Apply]在Standby Database上应用，从而同步数据 逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply 物理Standby接收完Primary数据库生成的REDO(Standby Redologs)数据后，以介质恢复的方式实现同步，这种方式也叫Redo Apply
配置 alter system set log_archive_dest_2 = 'SERVICE=biudbst' scope=both;注意： 使用ARCH进程传递最大问题在于：Primary Database只有在发生归档时才会发送日志到Standby Database。如果Primary Database异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题 使用LGWR进程+SYNC方式在Primary Database产生的Redo日志要同时写入日志文件和网络 LGWR进程要将日志写入到本地日志文件的同时发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程将日志通过网络发送给远程的目录。每个远程目录对应一个LNS进程，多个LNS进程能够并行工作 LGWR必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database上的事务才能提交 Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中 Primary Database的日志切换也会触发Standby Database上的日志切换，即Standby Database对Standby Redo Log的归档，然后触发Standby Database的MRP或者LSP进程恢复归档日志 Primary Database的Redo是实时传递的，Standby Database端可以使用两种恢复方法 实时恢复（Real-Time Apply）：只要RFS把日志写入Standby Redo Log就会立即进行恢复 归档恢复：在完成对Standby Redo Log归档才触发恢复
配置方式 -- NET_TIMEOUT: 如果多长时间内网络发送没有响应，LGWR进程会抛出错误, 单位:秒 alter system set log_archive_dest_2 = 'SERVICE=biudbst LGWR SYNC NET_TIMEOUT=30' scope=both;
SYNC 可能问题：在于日志发送给Standby Database过程失败，LGWR进程就会报错。Primary Database的LGWR进程非常依赖于网络带宽 使用LGWR进程+ASYNC方式Primary Database 端产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功 LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送 Primary Database的Online Redo Log写满后发生Log Switch，触发归档操作，也触发Standby Database对Standby Database对Standby Redo Log的归档；然后触发MRP或者LSP进程恢复归档日志。
配置 alter system set log_archive_dest_2 = 'SERVICE=biudbst LGWR ASYNC ' scope=both; 日志接收Standby Database的RFS（Remote File Server）进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中。取决于Primary的日志发送方式和Standby database的归档日志文件路径。 如果写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log的日志切换，并把这个Standby Redo Log归档。 Standby database端归档日志文件目录设置若配置了STANDBY_ARCHIVE_DEST参数，则使用该参数指定的目录 如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录。 若数据库的COMPATIBLE参数值>=10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值 如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc 日志应用日志应用就是在Standby database端重演Primary database日志，从而实现数据同步。 重演日志方式：物理Standby和逻辑Standby物理Standby（Physical Standby）使用Media Recovery技术，在数据块级别进行恢复。只能在mount或只读方式打开Physical Standby数据库 逻辑Standby（Logical Standby）使用Logminer技术，它通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句的方式实现数据同步。Logminer 技术不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。 Standby端数据写入方式Standby数据库接收到Redo数据（Standby端的归档日志文件或Standby Redologs）后，通过下面2种方式将数据写入到Standby数据库。 物理Standby：通过REDO应用 逻辑Standby：通过SQL应用 日志应用发生的时间
实时应用（Real-Time Apply）：必须设置Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复
优势：减少数据库切换（Switchover或者Failover）的所需的时间，切换时间主要用在剩余日志的恢复上
启用实时应用方式 -- physical standby alter database recover managed standby database using current logfile disconnect from session; -- logical standby alter database start logical standby apply immediate;
检查 select recovery_mode from v$archive_dest_status; select process,status,thread#,sequence#,client_pid from v$managed_standby;
归档时应用：在Primary Database发生日志切换，触发Standby Database归档操作，归档完成后触发恢复。 分类 1. 物理备库（Physical Standby Database） 2. 逻辑备库(Logical Standby Database) 3. 快照备库(Snapshot Standby Database) 服务类型 数据保护模式 定义 1. 最大保护（Maximum Protection）这种模式能够确保绝无数据丢失。 代价它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。当Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。 配置要求Standby Database必须配置Standby Redo Log Primary Database必须使用LGWR，SYNC，AFFIRM方式发送日志到Standby Database 2. 最大可用（Maximum Availability）这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。 配置要求Standby Database必须配置Standby Redo Log Primary Database必须使用LGWR，SYNC，AFFIRM方式发送日志到Standby Database 3. 最大性能（Maximum Performance）缺省模式。这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最大可用性的数据保护，而仅对Primary数据库的性能有轻微影响。这也是创建Standby数据库时，系统的默认保护模式。 配置要求Primary Database使用LGWR ASYNC或者ARCH进程的方式发送日志到Standby Database Standby Database不要求使用Standby Redo Log 修改模式
Mount状态下修改：关闭数据库，重启到Mount状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。
修改命令 ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION|AVAILABILITY|PERFORMANCE}; -- 示例： ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;
打开数据库
确认数据保护模式 select protection_mode,protection_level from v$database; 配置参数说明 自动裂缝（Gap）检测和解决当Primary Database的某些日志没有成功发送到Standby Database时，便发生了归档裂缝(archive gap)。通常Data Guard能够自动检测并解决归档裂缝，不需要DBA介入。它需要配置FAL_CLIENT，FAL_SERVER参数现实的，参数值都是Oracle Net Name（网络服务名：tnsname） FAL:（ Fetch Archive Log）Standby Database主动发起的“取”日志的过程。此时，Standby Database作为FAL_CLIENT角色，从FAL_SERVER端获取这些Gap的归档日志。 FAL_CLIENT通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 手工解决Gap 查看是否有日志GAP SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG; SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; 拷贝缺少的归档到Standby端 手工注册日志 ALTER DATABASE REGISTER LOGFILE '路径'; 日志发送的对象 VALID_FOR 属性指定传输及接收对象在LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性，用来指定传输的内容。VALID_FOR属性有两个参数值需要指定：REDO_LOG_TYPE和DATABASE_ROLE，说明发送指定角色生成的指定类型的日志文件 参数可选值
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) 建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下 DB_UNIQUE_NAME 属性指定数据库DB_UNIQUE_NAME属性的作用是指定唯一的Oracle数据库名称 LOG_ARCHIVE_CONFIG 初始化参数LOG_ARCHIVE_CONFIG用于指定Data Guard环境中的唯一数据库名及控制REDO数据的传输和接收的属性
SEND：允许数据库发送数据到远端。
RECEIVE：允许Standby接收来自其他数据库的数据。
NOSEND：禁止发送redo数据到远端
NORECEIVE：禁止接收来自其它数据库的数据 示例设置Primary数据库不接收任何归档数据，当发生了角色切换时，它也不会接收REDO数据 LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG=(PRI,ST)' 初始化参数
DB_NAME：同一个Data Guard中所有数据库DB_NAME相同
DB_UNIQUE_NAME：为每一个数据库指定一个唯一的名称
LOG_ARCHIVE_CONFIG：控制从远端数据库接收或发送REDO数据 通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME（含Primary数据库和Standby数据库），每一个DB_UNIQUE_NAME以逗号分隔，SEND/NOSEND属性控制是否可以发送，RECEIVE/NORECEIVE属性控制是否能够接收
LOG_ARCHIVE_DEST_n：归档文件的生成路径
REOPEN：指定时间后再次尝试归档操作 LOG_ARCHIVE_DEST_2='SERVICE=biudb LGWR ASYNC REOPEN=100'
LOG_ARCHIVE_DEST_STATE_n：是否允许REDO传输服务传输REDO数据到指定的路径
REMOTE_LOGIN_PASSWORDFILE：推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有DB服务器SYS密码相同
FAL_SERVER：指定一个Net服务名，表明该参数值对应的数据库应为Primary角色。可以指定多个参数值，以逗号分隔
FAL_CLIENT：指定一个Net服务名，表明该参数值对应的数据库应为Standby角色
DB_FILE_NAME_CONVERT：Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式
LOG_FILE_NAME_CONVERT：用来转换日志文件路径
STANDBY_FILE_MANAGEMENT：如果Primary数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby数据库中作相应修改 AUTO表示自动管理 MANUAL表示需要手工管理 (责任编辑：) |