您的位置:首页 > 其它

DATA GUARD中各个参数的整理(未完)

2014-11-26 02:14 253 查看
DB_UNIQUE_NAME 该参数为数据库定义的唯一名称。因为DB_NAME参数对于物理数据库而言必须相同,对于逻辑数据库而且必须不同,所以10g引入该参数,来确定DATA GUARD 配置中的每个数据库。需要在所有的数据库上进行设置,单需要重启数据库。如果未定义该参数,默认的使用DB_NAME,该参数是静态参数,修改后需要重启实例才能生效

LOG_ARCHIVE_CONFIG 该参数定义DATA GUARD配置的有效的DB_UNIQUE_NAME参数列表。与目标参数的DB_UNIQUE_NAME特性结合使用,他为DATA GUARD提供安全性检查:两个数据库之间的连接是允许的。您只需添加配置中其他数据库的唯一名称。当前数据库的名称总在后台添加。但为了清晰期间,并在所有的数据库上定义完全相同的参数,可明确添加所有d名称。对该参数的名称顺序不做要求,但在DATA
GUARD配置的RAC 数据库中这绝对是必须的。应始终使用该参数。

LOG_ARCHVIE_MAX_PROCESSES 此处之所以提及改参数,是因为默认设置为2,而这个是不够的。主数据库上的归档进程负责写满的ORL文件并处理到备用数据库的重做流的间隔。在备用数据库上,他们负责归档SRL文件,并将归档日志发送到级联备用数据库。
在主数据库,一个归档进程仅限为ORL文件提供服务,根本无权与备用数据库进行通信。这个特殊ARCH进程称为“专用ARCH进程”。但其他进程可同时执行这两项功能。当一个一个归档进程向备用数据库发送归档日志时,就不能协助归档ORL文件。尽管归档进程的基本指令是“总是先归档联机日志文件,然后才处理间隔”,但在最糟情况下,仍可能仅有那一个归档进程在归档联机日志文件。如果没有足够进程,当慢速网速存在较大间隔时,可能仅有一个归档进程在处理ORL文件。我们注意到一个棘手问题:如果ORL文件同时全部写满,生产将全部停止,直至其中一个得到归档为止。ORACLE
10G引入多线程间隔处理特性MAX_CONNECTIONS允许DATA GUARD使用多个归档进程向备用数据库发送单个日志文件。因此至少将该参数设置为4,该参数的最大值为30。
LOG_ARCHIVE_DEST_N 这个是DATA GUARD重做传输的主要参数,通常在主数据库上发挥作用。当然有些例外,这些例外主要发生在处理级联备用数据库的情况下。该参数还能用于指定ORL文件或者SRL文件的归档日志文件应该存放在哪儿。该参数有17个特性,可在设置到备用数据库的重做传输时配置所有的这些特性。要使用DATA GUARD将重做数据正确的传输到备用数据库,您只需设置其中的7个特性。下面我们首先讨论这7个特性,然后在实例的引导下描述其用法。再后谈论其他特性,并描述他们的使用位置与原因。建议您不要使用其中的6个特性:
下面是必须的7个特性:
SERVICE 指定创建的指向备用数据库的TNSNAMES描述符
SYNC 指定准备使用的同步方法传输重做数据。这意味着LGWR进程将等待来自LNS的确认消息,然后才告知客户端事务已经提交。对于“最高可用性”和“最大保护”模式而言,至少要有一个备用目标需要该配置。



ASYNC 这个是默认方法,如果不指定传输类型,将得到异步重做传输,这个是“最高性能”重做传输方法。
即使由于带宽有限,使得先前事务的重做数据不能立即传给备用数据库,LGWR也将继续确认提交操作成功完成。如果LNS赶不上进度,将在重做数据传送给备用数据库前就回收了日志 缓冲区,LNS进程将自行从ORL读取和发送重做数据。当LNS赶上进度以后,将自行转回到直接从日志缓冲区读取/发送。如果ASYNC重做传输的速度落后到在日志切换时LNS还在读取ORL的成都,LNS将继续执行操作,直到发送完原ORL的内容为止。此后会平滑转回到从当前联机日志文件读取/发送。当LNS赶上LGWR的进度是,回平滑转回从重做日志缓冲区读取/发送。
可在视图 X$LOGBUF_REDHIST中追踪日志缓冲区的命中率。如果命中率低,则意味着LNS时常从ORL读取,可考虑增大日志缓冲区的大小来获得合适的命中率。
 



 
 
与归档信息相关的视图:

视图

作用

V$DATABASE

LOG_MODE字段归档模式

V$INSTANCE

ARCHIVER字段是否正在归档

V$ARCHIVED_LOG

从控制文件中获取的所有历史归档日志文件信息

V$ARCHIVE_DEST

归档目标位置的信息

V$ARCHIVE_PROCESSES

归档进程的信息

V$BACKUP_REDOLOG

所有已备份的归档日志文件的信息

V$LOG

所有重做日志文件的信息,其中包含那些需要归档的重做日志文件

V$LOG_HISTORY

重做日志文件的历史信息

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: