挑战dataguard（3）――dataguard相关进程（RFS，LNSn，MRP，LSP）和参数配置

 

转载自：http://oxiaobai.blog.51cto.com/3369332/659144

 在整个dg配置中，最复杂的也许就是参数的配置了，并且有许多参数都可以延伸出去讲很多，所以今天我们来看看dg的参数配置，顺便加上一点dataguard进程相关的信息，帮助理解。

在配置dg的过程中，我们必须在参数文件中加上一些参数的配置来保证dg的配置成功，dg的参数有很多，o小白就介绍一些比较重要的，如果要相信看的话可以去官网看相关的文档和说明，以下就是一些比较常用的参数，考虑到primary和standby转换的问题，我们就推荐参数在两边都进行配置：

1.DB_NAME：数据库名，其实这么说有点不准确，很容易让人理解错误，o小白干脆就把他理解成dg名算了，方正整个dg中所有的DB_NAME都必须是一致的。

2.DB_UNIQUE_NAME：真正的数据库名，用来标识在dg中不同的数据库的名字，以示区分。

3.DB_FILE_NAME_CONVERT/LOG_FILE_NAME_CONVERT：如果standby数据库和primary数据库在同一个系统中或者standby系统的数据文件或者是日志文件位置和primary库的不一样，那这个参数必须在standby库的参数文件中进行配置，以逗号分隔，将文件的路径用单引号括起来，以先primary库后standby库的方式配置。例如：db_file_name_convert='/u01/app/oracle/oradata/××××/datafile/','/u01/app/oracle/oradata/×××××/datafile/'。

4.CONTROL_FILES：控制文件的位置。

5.LOG_ARCHIVE_CONFIG：推荐参数。通过DG_CONFIG将dg中所有的DB_UNIQUE_NAME罗列出来，先primary库后standby库的方式配置。例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago, boston)'。

6.LOG_ARCHIVE_DEST_n：归档文件的路径。最重要的参数之一，而且参数本身也十分复杂。那这里就趁势引入dataguard进程相关的一些工作机制。

dataguard中比较重要的进程有以下几个：

RFS：remote file server。该进程是standby库接受来自primary库lgwr进程触发的redo信息并且写入到standby redo log中。RFS进程无疑是要和其他进程配合的，也就是传输的进程。那这里就需要上篇的知识了，我们知道触发同步可能由ARCH或者是LGWR进程触发的，两者是不同的。如果是LGWR进程触发，那10g前的话也是由LGWR进程负责传输redo信息，RFS进程负责接收redo信息写入standby redo log中，10g之后则由LNSn进程完成；如果是ARCH进程触发，也就是归档日志传输的话，那就是由ARCH进程负责传输，RFS进程负责接收，然后写入指定的归档位置，然后再应用的。那这里不同的设置也决定了参数LOG_ARCHIVE_DEST_n的不同设置。详细见下。

LNSn：LGWR触发以后真正负责传输的进程，包括初始化网络I/O等一些列功能。

MRP：managed recovery process，简单来说就是物理standby是通过这个进程来实现数据的同步的，直接通过standby redo log或者是归档日志（取决于模式不同）来进行的一个数据恢复。

LSP:logical standby process：逻辑standby的方式，和上面的一样，只不过当中多了一步将redo信息转换成sql语句再恢复。也可以从这里看出逻辑standby和物理standby的不同。

那插播完了进程介绍，继续LOG_ARCHIVE_DEST_n，这个参数格式如下：

必须指定location/service：location代表的是本地的路径，在之后直接加入路径名例如LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago/'

service代表的是net service name，通常就是standby数据库的net_service_name，可以在tnsnames.ora,定义NET SERVICE NAME.那根据前面所说的不同方式service的制定要复杂的多：LOG_ARCHIVE_DEST_2='SERVICE=net_service_name LGWR ASYNC'，那这里也可以是LGWR SYNC NET_TIMEOUT=××来设置同步并且指定超时时间。如果是应用归档的方式，那就直接LOG_ARCHIVE_DEST_2='SERVICE=net_service_name。

valid_for:这个参数的作用是指定该LOG_ARCHIVE_DEST_n的路径的redo log的type 和redo log的“身份”的，方便在转换的时候使用。VALID_FOR=(redo_log_type,database_role)type有下面这些： ONLINE_LOGFILE, STANDBY_LOGFILE,  ALL_LOGFILES. “身份”是这些: PRIMARY_ROLE, STANDBY_ROLE, ALL_ROLES.

然后再附上DB_UNIQUE_NAME，完整例子如下：

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/boston/VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston'

那这个参数应该是成对出现的LOCATION端一般都会指定，然后再指定standby端，我们在今后的实验中在看具体的例子。

7.LOG_ARCHIVE_DEST_STATE_n：和上面的LOG_ARCHIVE_DEST_n参数配置对应的LOG_ARCHIVE_DEST_n的状态：enable是可用，除此之外还有DEFER（不用）|ALTERNATE（备用）|RESET（不用）。

8.LOG_ARCHIVE_FORMAT：归档进程格式。

9.LOG_ARCHIVE_MAX_PRODUC：归档进程的数量，1-30，默认是4.

10.REMOTE_LOGIN_PASSWORD：三个选项，none（不实用密码文件，dg中不使用）exclusive（单个实例使用单个密码文件）或者shared（多个实例可以使用单个密码文件）。

11.FAL_SERVER：数据库的sid，通常是primary库。

12.FAL_CLIENT 指定一个数据库SID，通常该库为standby 角色。

13.STANDBY_FILE_MANAGEMENT：AUTO或者MANUAL。如果为AUTO则表示primary库的数据文件发生修改（新增，重命名），则在standby库会自动做相应的更改。如果是MANUAL，则表示手动。

哇，好长的一篇，o小白自己都头大了，熟能生巧，哪天这些东西都不用再查阅文档就可以信手拈来，那也算对dg有个初步的了解了～