Oracle Data Guard 理论知识文档格式.docx

Oracle Data Guard 理论知识文档格式.docx

《Oracle Data Guard 理论知识文档格式.docx》由会员分享，可在线阅读，更多相关《Oracle Data Guard 理论知识文档格式.docx（21页珍藏版）》请在冰点文库上搜索。

3）日志应用（RedoApply）

1.日志发送（RedoSend）

PrimaryDatabase运行过程中，会源源不断地产生Redo日志，这些日志需要发送到StandyDatabase。

这个发送动作可以由PrimaryDatabase的LGWR或者ARCH进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。

选择哪个进程对数据保护能力和系统可用性有很大区别。

1.1使用ARCH进程

1）PrimaryDatabase不断产生RedoLog，这些日志被LGWR进程写到联机日志。

2）当一组联机日志被写满后，会发生日志切换（LogSwitch），并且会触发本地归档，本地归档位置是采用LOG_ARCHIVE_DEST_1='

LOCATION=/path'

这种格式定义的。

如：

altersystemsetlog_archive_dest_1='

LOCATION=/u01/arch'

scope=both;

3）完成本地归档后，联机日志就可以被覆盖重用。

4）ARCH进程通过Net把归档日志发送给StandbyDatabase的RFS（RemoteFileServer）进程。

5）StandbyDatabase端的RFS进程把接收的日志写入到归档日志。

6）StandbyDatabase端的MRP（ManagedRecoveryProcess）进程（RedoApply）或者LSP进程（SQLApply）在StandbyDatabase上应用这些日志，进而同步数据。

用ARCH模式传输不写StandbyRedologs，直接保存成归档文件存放于Standby端。

说明：

逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQLApply。

物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫RedoApply。

注意：

创建逻辑Standby数据库要先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。

使用ARCH进程传递最大问题在于：

PrimaryDatabase只有在发生归档时才会发送日志到StandbyDatabase。

如果PrimaryDatabase异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分SYNC（同步）和ASYNC（异步）两种方式。

在缺省方式下，PrimaryDatabase使用的是ARCH进程，参数设置如下：

altersystemsetlog_archive_dest_2='

SERVICE=ST'

1.2使用LGWR进程的SYNC方式

1）PrimaryDatabase产生的Redo日志要同时写道日志文件和网络。

也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（NetworkServerProcess），再由LNSn（LGWRNetworkServerprocess）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。

2）LGWR必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，PrimaryDatabase上的事务才能提交，这也是SYNC的含义所在。

3）StandbyDatabase的RFS进程把接收到的日志写入到StandbyRedoLog日志中。

4）PrimaryDatabase的日志切换也会触发StandbyDatabase上的日志切换，即StandbyDatabase对StandbyRedoLog的归档，然后触发StandbyDatabase的MRP或者LSP进程恢复归档日志。

因为PrimaryDatabase的Redo是实时传递的，于是StandbyDatabase端可以使用两种恢复方法：

实时恢复（Real-TimeApply）：

只要RFS把日志写入StandbyRedoLog就会立即进行恢复；

归档恢复：

在完成对StandbyRedoLog归档才触发恢复。

PrimaryDatabase默认使用ARCH进程，如果使用LGWR进程必须明确指定。

使用LGWRSYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR进程会抛出错误。

示例如下：

SERVICE=STLGWRSYNCNET_TIMEOUT=30'

1.3使用LGWR进程的ASYNC方式

使用LGWRSYNC方法的可能问题在于，如果日志发送给StandbyDatabase过程失败，LGWR进程就会报错。

也就是说PrimaryDatabase的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWRASYNC方式。

它的工作机制如下：

1）PrimaryDatabase一段产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。

2）LNSn进程异步地把日志内容发送到StandbyDatabase。

多个LNSn进程可以并发发送。

3）PrimaryDatabase的OnlineRedoLog写满后发生LogSwitch，触发归档操作，也触发StandbyDatabase对StandbyDatabase对StandbyRedoLog的归档；

然后触发MRP或者LSP进程恢复归档日志。

因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWRASYNC方式时不需要NET_TIMEOUT参数。

示例如下：

SERVICE=STLGWRASYNC'

2.日志接收（RedoReceive）

StandbyDatabase的RFS（RemoteFileServer）进程接收到日志后，就把日志写到StandbyRedoLog或者ArchivedLog文件中，具体写入哪个文件，取决于Primary的日志传送方式和Standbydatabase的位置。

如果写到StandbyRedoLog文件中，则当PrimaryDatabase发生日志切换时，也会触发StandbyDatabase上的StandbyRedoLog的日志切换，并把这个StandbyRedoLog归档。

如果是写到ArchivedLog，那么这个动作本省也可以看作是个归档操作。

在日志接收中，需要注意的是归档日志会被放在什么位置：

1）如果配置了STANDBY_ARCHIVE_DEST参数，则使用该参数指定的目录。

2）如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR=（STANDBY_LOGFILE,*）选项，则使用这个参数指定的目录。

3）如果数据库的COMPATIBLE参数大于等于10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值。

4）如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc.

3.日志应用（RedoApply）

日志应用服务，就是在StandbyDatabase上重演PrimaryDatabase日志，从而实现两个数据库的数据同步。

根据StandbyDatabase重演日志方式的不同，可分为物理Standby（PhysicalStandby）和逻辑Standby（LogicalStandby）。

PhysicalStandby使用的是MediaRecovery技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。

PhysicalStandby数据库只能在Mount状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。

LogicalStandby使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句，LogminerStandby不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

LogicalStandby数据库可以在恢复的同时进行读写操作。

Standby数据库的相关进程读取接收到的REDO数据（可能来自于Standby端的归档文件，也可能来自于StandbyRedologs），再将其写入Standby数据库。

保存之后数据又是怎么生成的呢？

两种方式：

物理Standby通过REDO应用，逻辑Standby通过SQL应用

根据RedoApply发生的时间可以分成两种：

一种是实时应用（Real-TimeApply），这种方式必须StandbyRedoLog，每当日志被写入StandbyRedoLog时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。

另一种是归档时应用，这种方式在PrimaryDatabase发生日志切换，触发StandbyDatabase归档操作，归档完成后触发恢复。

这也是默认的恢复方式。

如果是PhysicalStandby，可以使用下面命令启用Real-Time：

Alterdatabaserecovermanagedstandbydatabaseusingcurrentlogfile;

如果是LogicalStandby，可以使用下面命令启用Real-Time：

Alterdatabasestartlogicalstandbyapplyimmediate;

查看是否使用Real-Timeapply：

Selectrecovery_modefromv$archive_dest_status;

SQL>

setwrapoff

selectprocess,status,thread#,sequence#,client_pidfromv$managed_standby;

PROCESSSTATUSTHREAD#SEQUENCE#CLIENT_PID

----------------------------------------------------------------------------

ARCHCONNECTED00240

ARCHCONNECTED00196

ARCHCONNECTED001944

ARCHCONNECTED003956

MRP0WAIT_FOR_LOG130843N/A

RFSRECEIVING1308382620

RFSRECEIVING1308372612

RFSRECEIVING1308332652

RFSATTACHED1308412628

RFSATTACHED1308352604

RFSATTACHED1308422608

已选择11行。

二．数据保护模式

DataGuard允许定义3钟数据保护模式，分别是最大保护（MaximumProtection），最大可用（MaximumAvailability）和最大性能（MaximumPerformance）。

1.最大保护（MaximumProtection）

这种模式能够确保绝无数据丢失。

要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的OnlineRedologs，还要同时写入到Standby数据库的StandbyRedologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。

如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。

使用这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase.

2.最高可用性（Maximumavailability）

这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。

其实现方式与最大保护模式类似，也是要求本地事务在提交前必须至少写入一台Standby数据库的StandbyRedologs中，不过与最大保护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。

这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。

这种方式要求StandbyDatabase必须配置StandbyRedoLog，而PrimaryDatabase必须使用LGWR，SYNC，AFFIRM方式归档到StandbyDatabase.

3.最高性能（Maximumperformance）

缺省模式。

这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。

事务可以随时提交，当前Primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。

如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。

这也是创建Standby数据库时，系统的默认保护模式。

这种方式可以使用LGWRASYNC或者ARCH进程实现，StandbyDatabase也不要求使用StandbyRedoLog。

4.修改数据保护模式步骤

1）关闭数据库，重启到Mount状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到mount状态。

2）修改模式：

语法：

ALTERDATABASESETSTANDBYDATABASETOMAXIMIZE{PROTECTION|AVAILABILITY|PERFORMANCE};

ALTERDATABASESETSTANDBYDATABASETOMAXIMIZEPROTECTION;

3）打开数据库：

alterdatabaseopen;

4）确认修改数据保护模式：

selectprotection_mode,protection_levelfromv$database;

三．自动裂缝检测和解决

当PrimaryDatabase的某些日志没有成功发送到StandbyDatabase，这时候发生饿了归档裂缝（ArchiveGap）。

缺失的这些日志就是裂缝（Gap）。

DataGuard能够自动检测，解决归档裂缝，不需要DBA的介入。

这需要配置FAL_CLIENT，FAL_SERVER这两个参数（FAL:

FetchArchiveLog）。

从FAL这个名字可以看出，这个过程是StandbyDatabase主动发起的“取”日志的过程，StandbyDatabase就是FAL_CLIENT.它是从FAL_SERVER中取这些Gap，10g中，这个FAL_SERVER可以是PrimaryDatabase，也可以是其他的StandbyDatabase。

FAL_SERVER='

PR1,ST1,ST2'

;

FAL_CLIENT和FAL_SERVER两个参数都是OracleNetName。

FAL_CLIENT通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。

但是这两个连接不一定是一个连接。

因此FAL_CLIENT向FAL_SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。

这个参数值也是一个OracleNetName，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT.

当然，除了自动地日志缺失解决，DBA也可以手工解决。

具体操作步骤如下：

1）查看是否有日志GAP：

SELECTUNIQUETHREAD#,MAX（SEQUENCE#）OVER（PARTITIONBYTHREAD#）LASTFROMV$ARCHIVED_LOG;

SQL>

SELECTTHREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE#FROMV$ARCHIVE_GAP;

2）如果有，则拷贝过来

3）手工的注册这些日志：

ALTERDATABASEREGISTERLOGFILE'

路径'

四．指定日志发送对象

1．VALID_FOR属性指定传输及接收对象

LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性，用来指定传输的内容。

从字面理解VALID_FOR就是基于那谁有效，该属性有两个参数值需要指定：

REDO_LOG_TYPE和DATABASE_ROLE，我们基本上可以将其理解为：

发送指定角色生成的指定类型的日志文件，该参数的主要目的是为了确保，一旦发生角色切换操作后数据库的正常运转。

其中，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）。

推荐手动设置该参数而不要使用默认值，在某些情况下默认的参数值不一定合适，如逻辑Standby在默认情况下就处于OPENREADWRITE模式，不仅有REDO数据而且还包含多种日志文件（OnlineRedologs、ArchivedRedologs及StandbyRedologs）。

默认情况下，逻辑Standby数据库生成的归档文件和接收到的归档文件在相同的路径下，这既不便于管理，也极有可能带来一些隐患。

建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。

本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。

2．通过DB_UNIQUE_NAME属性指定数据库

DB_UNIQUE_NAME属性是10g版本新增加的一个关键字，在之前版本并没有这一说法。

该属性的作用是指定唯一的Oracle数据库名称，也正因有了DB_UNIQUE_NAME，REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。

当然要确保REDO数据被传输到指定服务器，除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外，还有一个初始化参数LOG_ARCHIVE_CONFIG也需要进行正确的配置。

该参数除了指定DataGuard环境中的唯一数据库名外，还包括几个属性，用来控制REDO数据的传输和接收：

SEND：

允许数据库发送数据到远端。

RECEIVE：

允许Standby接收来自其他数据库的数据。

NOSEND,NORECEIVE：

自然就是禁止喽。

例如，设置Primary数据库不接收任何归档数据，可以做如下的设置：

LOG_ARCHIVE_CONFIG='

NORECEIVE,DG_CONFIG=（PRI,ST）'

如果做了如上