oracle dataguard affirm,oracle dataguard

ORACLE DG

data

guard(数据卫士)：DG最多可以有一个主节点(primary)，9个从节点(standby),通过网络服务名连接。

一、架构

二、保护模式

三、Dataguard的硬软件需求

四、分类

五、物理standby配置过程

六、服务

一、架构

DG架构可以按照功能分成3个部分:

1. 日志发送(Redo Send)

2. 日志接收(Redo Receive)

3. 日志应用(Redo Apply)

1. 日志发送(Redo Send)

Arch

Lgwr: sync或async

Primary Database 运行过程中，会源源不断地产生Redo

日志，这些日志需要发送到Standy Database。(Primary Database 的LGWR

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

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

1.1 使用ARCH

进程 日志归档后才会发送

1) Primary Database 不断产生Redo Log，这些日志被LGWR 进程写到联机日志。

2) 当一组联机日志被写满后，会发生日志切换(Log Switch)，并且会触发本地归档。(本地归档位置是采用

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)进程(Redo Apply)或者LSP 进程(SQL Apply)在Standby

Database上应用这些日志，进而同步数据。

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

说明：

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

Apply。

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

Apply。

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

使用ARCH进程传递最大问题在于： Primary Database 只有在发生归档时才会发送日志到Standby

Database。 如果Primary Database 异常宕机，联机日志中的Redo 内容就会丢失，因此使用ARCH

进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR

又分SYNC(同步)和ASYNC(异步)两种方式。

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

alter system set log_archive_dest_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 Database

上的事务才能提交，这也是SYNC的含义所在。

3)Standby

Database的RFS进程(remote file

server)把接收到的日志写入到Standby Redo Log日志中。

4)Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby

Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP(Managed

Recovery Process)进程(Redo Apply)或者LSP 进程(SQL

Apply)进程恢复归档日志。

因为Primary Database 的Redo 是实时传递的，于是Standby Database

端可以使用两种恢复方法：

实时恢复(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=30' scope=both;

affirm:写入standby重做日志中，才算日志传输成功

noaffirm

1.3 使用LGWR进程的ASYNC 方式

使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby

Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR

进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。 它的工作机制如下：

1) Primary Database 一段产生Redo 日志后，LGWR

把日志同时提交给日志文件和本地LNS(LGWR network server process)

进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。

2) LNSn进程异步地把日志内容发送到Standby

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

3) Primary Database的Online Redo Log 写满后发生Log

Switch，触发归档操作，也触发Standby Database对Standby Database对Standby Redo Log

的归档；然后触发MRP(manage recover process )(redo apply )或者LSP (sql

apply)进程恢复归档日志。

因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR

ASYNC方式时不需要NET_TIMEOUT参数。示例如下：

alter system set log_archive_dest_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

的日志切换，并把这个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_ARCHIVE_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 使用的是Media Recovery

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

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

Logical Standby 使用的是Logminer 技术，通过把日志内容还原成SQL

语句，然后SQL引擎执行这些语句，Logminer

Standby不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED

中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。 Logical

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

Standby数据库的相关进程读取接收到的REDO数据(可能来自于Standby端的归档文件，也可能来自于Standby

Redologs)，再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用

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

一种是实时应用(Real-Time Apply)， 这种方式必须Standby Redo Log，每当日志被写入Standby

Redo Log时，就会触发恢复，使用这种方式的好处在于可以减少数据库切换(Switchover

或者Failover)的时间，因为切换时间主要用在剩余日志的恢复上。

另一种是归档时应用，这种方式在Primary Database发生日志切换，触发Standby Database

归档操作，归档完成后触发恢复。这也是默认的恢复方式。

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

Alter database recover managed standby database using current

logfile disconnect from session;

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

Alter database start logical standby apply immediate;

查看是否使用Real-Time apply：

Select recovery_mode from v$archive_dest_status;

SQL> set wrap off

SQL> select process,status,thread#,sequence#,client_pid from

v$managed_standby;

二、保护模式

三种模式

最大保护(Maximum Protection)，

最高可用性(Maximum Availability)

最高性能(Maximum Performance)。

1. 最大保护(Maximum Protection)

确保绝无数据丢失。

它要求所有的事务在primary数据库上提交前必须同时满足以下三个条件：

(1)事务的REDO已经写入到本地的Online Redologs，

(2)事务的REDO已经写入到至少一个Standby数据库的Standby Redologs，

(3)事务的REDO数据至少在一个Standby数据库中可用(如果有多个的话)

若出现了故障导致Standby数据库不可用(eg:

网络中断)，Primary数据库会被Shutdown，以防止数据丢失。

使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary

Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

2. 最高可用性(Maximum availability)

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

与最大保护模式类似，唯一的不同是primary不会因Standby数据库不可用而shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary数据库又会自动转换成最高可用性模式。

这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby

Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby

Database.

3. 最高性能(Maximum performance)

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

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

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

这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby

Database也不要求使用Standby Redo Log。

4.

修改数据保护模式步骤

(primary上执行)

SQL> select protection_mode,protection_level from

v$database;

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

2)修改模式：

语法：ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION

| AVAILABILITY | PERFORMANCE};

如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE

availability;

3) 打开数据库： alter database open;

4)重启后生效

SQL >shutdown immediate;

SQL>startup ;

SQL>select protection_mode,protection_level from

v$database;

PROTECTION_MODE PROTECTION_LEVEL

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

MAXIMUM AVAILABILITY  RESYNCHRONIZATION

5)开启备库，同步后protection_level也会变为maximum availability

三、Dataguard的硬软件需求

(一)硬件需求

(二)软件需求

(一)硬件需求

1、相同的系统架构。

2、硬件配置可以不同(CPU、MEMORY etc.)

3、操作系统平台必须相同，版本可以略有差异

(二)软件需求

1、企业版支持，标准版不支持

2、配置所有初始化参数：compatible的值必须相同

3、primary处于归档模式且要打开force

logging(避免通过NOLOGGING之类的操作方式，跳过redo数据的生成，从而导致无法顺利传输到standby)

4、primary和standby可以是单实例或RAC, 同一个DG中可以有物理和逻辑standby同时存在。

5、primary和standby数据库必须是拥有SYSDBA系统权限的用户

6、primary和standby要采用相同的存储架构

7、primary和standby可以在同一台服务器上。

四、分类

(一)、物理standby

(二)逻辑standby

根据同步机制不同，其中standby可分为物理和逻辑两类。

(一)物理standby

1、物理standby所处的三种状态

2、物理Standby特点

是接受主节点的redo数据后，以介质恢复(应用归档日志和联机日志进行恢复)的方式进行同步(REDO Apply)。

1、物理standby所处的三种状态：

(1)REDO应用

(2)READ ONLY模式打开

(3)READ WRITE模式打开

(1)REDO应用。 (一般为mount状态)

应用状态数据库不能被open

物理Standby通过REDO应用来保持与Primary数据库的一致性，

REDO应用是通过Oracle的恢复机制，应用归档文件(或Standby

Redologs文件)中的REDO数据。恢复操作属于块对块的应用。如果正在执行REDO应用的操作，Oracle数据库就不能被Open。

(2)READ ONLY模式打开。

可以接受redo数据但不会应用。(可以查询、备份)

以READ

ONLY模式打开后，可以在Standby数据库执行查询或备份等操作(变相减轻Primary数据库压力)。此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据，不过并不会应用，直到Standby数据库重新恢复REDO应用。

如果需要的话，你可以在两种状态间转换，如先应用REDO，然后将数据库置为READ

ONLY状态，需要与Primary同步时再次执行REDO应用命令，切换回REDO应用状态。

提 示： Oracle

11g版本中增强物理Standby的应用功能，在11g版本中，物理Standby可以在OPEN READ

ONLY模式下继续应用REDO数据，这就极大地提升了物理Standby数据库的应用场合。

(3)READ WRITE模式打开。

暂停接收和应用，失去灾难保护功能

如果以READ

WRITE模式打开，那么Standby数据库将暂停从Primary数据库接收REDO数据，并且暂时失去灾难保护的功能。何时以READ

WRITE模式打开？如你可能需要临时调试一些数据，但又不方便在正式库中操作，那就可以临时将Standby数据库置为READ

WRITE模式，操作完之后将数据库闪回到操作前的状态(闪回之后，Data

Guard会自动同步，不需要重建物理Standby，不过如果从另一个方向看，没有启动闪回，那就回不到READ

WRITE前的状态了)。

2、物理Standby特点：

(1)灾难恢复及高可用性。

物理Standby提供了一个健全、高效的灾难恢复，以及高可用性的解决方案。更加易于管理switchover/failover角色转换及在更短的计划内或计划外停机时间。

(2)数据保护。

使用物理Standby数据库，DG能够确保即使面对无法预料的灾害也能够不丢失数据。前面也提到物理Standby是基于块对块的复制，因此与对象、语句无关，Primary数据库上有什么，物理Standby数据库端也会有什么。

(3)分担Primary数据库压力。

通过将一些备份任务、仅查询的需求转移到物理Standby数据库，可以有效节省Primary数据库的CPU及I/O资源。

(4)提升性能。

物理Standby所使用的REDO应用技术使用最底层的恢复机制，这种机制能够绕过SQL级代码层，因此效率最高。

(二)逻辑standby：

1、模式

2、特点

是接受主节点的redo数据后,先将redo数据转换成SQL语句，然后再standby上执行该SQL语句实现的同步(SQL

Apply)。

逻辑Standby也要通过Primary数据库(或其备份，或其复制库，如物理Standby)创建，与物理Standby数据库类似。不过由于逻辑Standby通过SQL应用的方式应用REDO数据，因此逻辑Standby的物理文件结构，甚至数据的逻辑结构都可以与Primary不一致。

1、逻辑standby所处模式：

READ WRITE模式 (OPEN状态下执行SQL应用)

用户可以在任何时候访问逻辑Standby数据库。同样有利也有弊，由于SQL应用自身特点，逻辑Standby对于某些数据类型及一些DDL/DML语句会有操作上的限制。可以在视图DBA_LOGSTDBY_UNSUPPORTED

中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。

逻辑Standby 的读写打开可以使它做报表系统，这样减轻系统的压力。

2、除了上述物理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的话。

五、物理standby配置过程

1、准备工作(primary端执行)

(1)配置监听

(2)启动force logging

(3)启动归档

(4)配置standby redologs(可以不配置)，创建密钥文件

(5)配置初始化参数

(6)创建备份

(7)创建standby控制文件

2、在standby端执行

(1)创建输出目录

(2)配置监听

(3)复制秘钥文件

(4)初始化参数

(5)以spfile启动到nomount

(6)恢复

3、接收与应用redo

4、监控恢复状态

5、其他

6、调整物理standby端redo数据应用频率

1、准备工作(在primary端执行)：

(1)启动force logging。

数据库会记录除临时表空间或临时回滚段外的所有操作，若在执行force

logging时有nologging之类的语句在执行，force logging会等待，直到语句全部执行。force

logging作为固定参数在控制文件中，不受重启之类操作的影响(只执行一次即可)。

查看：SQL>select force_logging from v$database;

启动：SQL>alter database force logging;

取消：SQL>alter database no force logging;

(2)将primary数据库处于归档模式

查看：SQL>select name,log_mode from v$database;或SQL>archive

log list;

改变模式：

SQL>shutdown immediate;

SQL>startup mount;

SQL>alter database archivelog;

SQL>alter database open;

(3)配置standby redologs

(也可以不配置)

关于standby redologs

a:文件大小与primary online redologs大小相同

b:数量适量：standby redologs要比primary redologs日志文件组至少多一组

(每线程的日志数+1)*最大线程数(线程：RAC中的节点)

管理standby redologs

SQL>alter database add standby logfile group 4

('/u/app/oradata/standby/redo04..log'') size 10m;

SQL>alter database drop standby logfile group 4;

SQL>select member,type,status from

v$logfile;

SQL>select group#,status from v$standby_log;

(4)配置primary初始化参数。

通过当前spfile创建pfile,

SQL>create pfile='path' from

spfile (SQL>create pfile

from spfile)

编辑pfile修改初始化参数

通过pfile重建spfile

SQL>shutdown immediate;

SQL>create spfile from pfile='path' (SQL>create spfile

from pfile)

SQL>startup ;

Db_name (data_guard中db_name均相同)

Db_unique_name(每个数据库有唯一的db_unique_name)

Log_archive_config

Log_archive_dest_n (log_archive_dest_1与log_archive_dest_2)

Log_archive_dest_state_n(log_archive_dest_state_1与log_archive_dest_state_2)

Remote_login_passwordfile

Fal_server

Fal_client

Db_file_name_convert

Log_file_name_convert

Standby_file_management

1、DB_NAME

同一个Data Guard中所有数据库DB_NAME相同 eg:

db_name=test

2、DB_UNIQUE_NAME

为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非DBA主动修改它

eg:

primary端 db_unique_name=pridb

standby端 db_unique_name=stydb

3、LOG_ARCHIVE_CONFIG

该参数用来控制从远端数据库接收或发送REDO数据，通过DG_CONFIG属性罗列同一个Data

Guard中所有DB_UNIQUE_NAME(含Primary数据库和Standby数据库)，以逗号分隔，SEND/NOSEND属性控制是否可以发送，RECEIVE/NORECEIVE属性控制是否能够接收

eg：

primary 端：LOG_ARCHIVE_CONFIG='DG_CONFIG=’(pridb,stydb)'

standby端：LOG_ARCHIVE_CONFIG='DG_CONFIG=’(stydb,pridb)'

4、LOG_ARCHIVE_DEST_N

Show parameter log_archive_dest_n

Show parameter log_archive_dest

v$archive_dest视图

归档文件的生成路径。该参数非常重要，并且属性和子参数也特别多

属性：

(1)Location或service

(2)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=(all_logfiles,all_roles)

(3)noaffirm/affirm：affirm表示只有当日志写入standby重做日志后才算日志传送成功

(4)sync/async

(5)net_time_out (lgwr sync配合使用)

LOG_ARCHIVE_DEST_1

本地归档路径：

Primary:

log_archive_dest_1 =’location=/u/app/oracle/oradata/pridb/archivelog/

valid_for=(all_logfiles,all_roles) db_unique_name=pridb’

standby:

log_archive_dest_1 =’location=/u/app/oracle/oradata/stydb/archivelog/

valid_for=(all_logfiles,all_roles)

db_unique_name=stydb’

LOG_ARCHIVE_DEST_2

该参数仅当数据库角色为primary时生效，指定primary传输redo log到该参数定义的standby

database上。

log_archive_dest_2可以说是dataguard上最重要的参数之一，它定义了redo log的传输方式(sync

or async)以及传输目标(即standby apply node)，直接决定了dataguard的数据保护级别。

Primary: log_archive_dest_2=’service=stydb lgwr sync AFFIRM valid_for=(online_logfiles,primary_role)

db_unique_name=stydb net_timeout=30’

Standby: log_archive_dest_2=’service=pridb lgwr async valid_for=(online_logfiles,primary_role)

db_unique_name=pridb’

当前节点设置的均为另一端数据库的db_unique_name

5、REMOTE_LOGIN_PASSWORDFILE

推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data

Guard配置中所有DB服务器SYS密码相同

以下参数为与Standby角色相关的参数(建议在Primary数据库的初始化参数中也进行设置，这样即使发生角色切换，新的Standby也能直接正常运行)

6、FAL_SERVER

Show parameter fal;

指定一个Net服务名，该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器

例如：FAL_SERVER=pridb

提示：FAL是Fetch Archived Log的缩写

FAL_SERVER参数支持多个参数值的哟，相互间以逗号分隔

7、FAL_CLIENT

又指定一个Net服务名，该参数对应数据库应为Standby角色。当本地数据库以Primary角色运行时，向参数值中指定的站点发送中断的归档文件

例如：FAL_CLIENT=stydb

FAL_CLIENT参数也支持多个参数值，相互间以逗号分隔。

8、DB_FILE_NAME_CONVERT

Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式

例如：DB_FILE_NAME_CONVERT='f:\oradata\DavePre','l:\oradata\DaveDG'

9、LOG_FILE_NAME_CONVERT

使用方式与上相同，只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径

例如：

LOG_FILE_NAME_CONVERT='f:\oradata\DavePre','l:\oradata\DaveDG'

10、STANDBY_FILE_MANAGEMENT

如果Primary数据库表空间或数据文件发生修改(如新建、重命名等)则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理，若数据文件是从其他数据库复制而来的，则不管standby_file_management如何设置，都必须手工复制到standby数据库，并重建物理standby数据库的控制文件。

例如：STANDBY_FILE_MANAGEMENT=AUTO

(4)创建密钥文件(若不存在的话)

同一个dataguard中，所有数据库服务器的sys用户拥有相同的密码，以保证redo数据的顺利传输。(redo传输服务是通过认证网络会话来传输redo数据，而会话使用包含在密钥文件中的sys用户密码来认证)

创建方式：

a: dbca创建数据库时自动创建密钥文件$ORACLE_HOME/database目录下，

b: 也可以使用命令创建:orapwd,

生成文件在$ORACLE_HOME/dbs/orap下

#orapwd file=orapwtest password=test entries=30 force=y

Orapwd

file=/u/app/oracle/product/10.2.0/db_1/dbs/orapw

password=foxconn88 entries=30

force=y

(5)创建备份(用户管理或rman )

A、用户管理方式：

SQL>alter database begin backup; 或alter tablespace uses01

begin backup ;

拷贝操作系统文件

SQL>alter database end backup或alter tablespace user01 end

backup;

B、rman备份

RMAN>backup database;

(6)创建standby数据库控制文件

SQL>alter databse create standby controlfile as

'/home/oracle/fu

/control01.ctl'

或 RMAN>backup current controlfile for

standby;

或RMAN>copy current controlfile for standby to ‘path’;

或RMAN>backup database includes current controlfile for

standby;

2、在standby端执行

(1)创建输出目录

(2)配置监听

(3)复制秘钥文件

(4)初始化参数

(5)以spfile启动到nomount

(6)恢复

(1)创建日志输出文件相关目录及数据文件存放目录

Mkdir –p  $ORACLE_BASE/admin/adump

Mkdir –p  $ORACLE_BASE/admin/bdump

Mkdir –p  $ORACLE_BASE/admin/cdump

Mkdir –p  $ORACLE_BASE/admin/udump

Mkdir –p $ORACLE_BASE/oradata/teststb

(2)配置监听和网路服务

Listener.ora/ tnsnames.ora

Listener.ora:静态注册(5)

(SID_DESC =

(GLOBAL_DBNAME = teststa)

(ORACLE_HOME = /u/app/oracle/product/10.2.0/db_1)

(SID_NAME = teststa)

)

tnsnames.ora

TESTSTA =

(DESCRIPTION =

(ADDRESS

= (PROTOCOL = TCP)(HOST = 10.147.139.125)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = teststa)

)

)

(3)复制primary端的密钥文件

Cp $ORACLE_HOME/dbs/orapwtest $ORACLE_HOME/dbs/orapwteststb

(4)修改初始化参数

Audit_file_dest

Background_dump_dest

Core_dump_dest

User_dump_dest

Control_files

Db_name

(data_guard中db_name均相同)

Db_unique_name(每个数据库有唯一的db_unique_name)

Log_archive_config

Log_archive_dest_n (log_archive_dest_1与log_archive_dest_2)

Log_archive_dest_state_n(log_archive_dest_state_1与log_archive_dest_state_2)

Remote_login_passwordfile

Fal_server

Fal_client

Db_file_name_convert

Log_file_name_convert

Standby_file_management

(5)数据库启动到nomount

SQL>create spfile from pfile;

SQL>startup nomount;

(6)执行恢复后启动到mount状态

A、用户管理方式：

先将创建的standby控制文件拷贝到对应路径启动到mount状态，在将复制的数据文件拷贝到适当位置，再开启数据库

B、restore

Rman>restore controlfile from ‘path’;

Rman >catalog start with ‘path’(可选)

Rman>restore database;(不需要recover)

C、duplicate restore

#export ORACLE_SID=pridb

#rman target / auxiliary sys/foxconn@stidb

Rman> catalog start with ‘path’

RMAN>duplicate target database for standby;

3、接收与应用redo

(1)启动Redo应用：

Primary：

SQL>alter system set

log_archive_dest_state_2=enable;

Standby:

SQL>startup mount;

SQL> alter database recover managed standby database

disconnect from session; /*应用redo(disconnect from session 指定启动应用后自动退出到命令操作符)

或SQL> alter database recover managed standby database

disconnect from session using current

logfile (using current logfile

启用实时应用，前提：redo采用lgwr进程发送 )

(2)停止standby数据库：

Primary：

SQL>alter system set log_archive_dest_state_2=defer;

Standby:

SQL>alter database recover managed standby databse

cancel; /*停止应用日志，但还是会接收日志。

SQL>shutdown immediate;

Primary端：SQL>alter system set

log_archive_dest_state_2=enable; (执行该SQL后，primary就会发送redo数据到standby，standby数据库的接收是自动进行的)

查看接收到的归档文件(v$archived_log),primary和standby端执行如下命令对比：

Select max(sequence#) from v$archived_log;

Primary修改的数据是否能在standby端看到受如下因素影响：

A:同步模式

B:是否启用应用(实时应用)

4、监控恢复状态

(1)查看进程活动状态v$managed_standby

查看当前redo应用和redo传输服务活动状态

SQL> select process,client_process,sequence#,status from

v$managed_standby;

SQL> select

process,status,thread#,sequence#,blocks,blocks from v$managed_standby;

(2)检查redo应用进度v$archive_dest_status

检查应用模式

select dest_name

archived_thread#,archived_seq#,applied_thread#,applied_seq# from v$archive_dest_status where

status='VALID';

SQL> select recovery_mode from v$archive_dest_status

where dest_id=2;

(3)查看归档文件路径和创建信息。V$archived_log;

SQL> select name,creator,sequence#,applied,completion_time

from v$archived_log;\

(4)查询归档历史，v$log_history,可以查询所有已被应用的归档文件信息(无论该归档文件是否还存在)

SQL>select first_time,first_change#,next_change#,sequence#

from v$log_history;

SQL>select thread#,max(sequence#) as "last_applied_log"

from

v$log_history group by thread#; /*查询最后应用的归档文件。

或SQL> select thread#,sequence#,applied from

v$archived_log;

(5)查看standby端未接收的日志(primary端执行)

SQL> select local.thread#,local.sequence# from (select

thread#,

2 sequence# from

v$archived_log where dest_id=1) local

3 where local.sequence# not

in

4 (select sequence# from

v$archived_log where dest_id=2 and

5 thread#=local.thread#);

5、其他

(1)查询当前数据库基本信息v$database

SQL> select

database_role,db_unique_name,open_mode,protection_mode,

2 protection_level,switchover_status from v$database;

(2)data guard事件(v$dataguard_status)

自动触发写入alert.log或服务器trace文件的事件。

SQL> select message from v$dataguard_status;

6、调整物理standby端redo数据应用频率

实质是调整I/O读取能力，从如下几个方面入手：

(1)设置recover并行度

SQL>recover standby database parallel 2; (内存中有效)

Parallel建议设置为#cpus乘以2

SQL>show parameter

parallel_max_servers(设置parallel_max_servers参数)

(2)加快redo应用频繁

Db_block_checking_false

(3)parallel_execution_message_size参数值

(4)优化磁盘I/O

六、服务

Log_archive_dest_n

服务确保数据传输、日志应用、状态检查、角色转换等

(一)redo传输服务：RTS (Redo transport services)

传送redo数据到standby端

oracle通过RTS控制redo数据，从primary数据库发送到一个或多个归档目标(本地或远端归档路径)

1、使用arch归档redo数据

(1)初始化参数(log_archive_dest_n及log_archive_max_processes)控制ARCn进程归档行为：

进程数量受参数log_archive_max_processes(最大值为30)影响

Alter system set log_archive_max_processes=n (0

(2)Arcn进程(仅在最高性能模式下可用)归档REDO数据

(3)ARCn归档过程

2、使用LGWR归档REDO数据

(1)Sync同步归档

Redologs 并应用到standby数据库，无需再等待归档完成。

(2)Async异步归档：

与sync同步归档的差别在于：LNsn进程的地方

(二)LOG应用服务：Log Apply Services ;

LAS服务

应用redo数据到standby数据库

Redo应用：标准的RECOVER方式应用redo数据，物理standby数据库专用

SQL应用：首先将接收到的REDO数据转换成SQL语句，然后再执行SQL语句的方式应用REDO数据，逻辑standby数据库专用

1、物理standby 数据库处于mount或open read only状态

前台应用

SQL>alter database recover managed standby

database; /*不会将控制权返回到命令行窗口，除非手动终止

后台应用：

SQL>alter database recover managed standby database

disconnect; /*常用

redo数据实时应用(redo数据不需要归档完成，接收到即可被应用)：

SQL> alter database recover managed standby database using

current logfile;

停止应用：

SQL>alter database recover managed standby database

cancel:

逻辑standby应用redo数据：

应用(没有前后台之说)

SQL>alter database start logical standby apply;

启用实时应用：

SQL>alter database start logical standby apply immediate;

停止(考虑事务是否结束)：

SQL>alter database stop logical standby apply;

停止(不考虑事务是否结束)：

SQL>alter database abort logical standby apply;

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数据实时应用

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

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY

IMMEDIATE;

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> ALTER SYSTEM SET LOG_ARCHIVE_DEST_3='SERVICE=DavePrimary

ARCH VALID_ FOR=

(ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME=Dave

DELAY=15';

不过，如果DBA在启动REDO应用时指定了实时应用，那么即使在LOG_

7.2 应用REDO数据到Standby数据库

7.2.2．逻辑Standby应用REDO数据

SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行，因此逻辑Standby需要启动至OPEN状态。

(1)启动SQL应用。逻辑Standby数据库启动SQL应用没有前、后台运行之说，语句执行完之后，控制权就会自动返回当前命令行窗口。

要启动SQL应用，直接执行下列语句即可：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

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

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY

IMMEDIATE;

(2)停止SQL应用，如：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

由于是执行SQL语句的方式应用REDO数据，因此上述语句的执行需要等待当前执行的SQL触发的事务结束，才能真正停止REDO应用的状态。

如果不考虑事务执行情况，马上停止REDO应用，可以通过下列的语句来完成：

SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;