在整个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,则表示手动。