Oracle 11g Dataguard参数详解(2)-木庄网络博客

当前第2页返回上一页

log_archive_dest_3='service=Matrix_DR1
                    LGWR ASYNC REOPEN=15
                    COMPRESSION=ENABLE
                    valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
                    db_unique_name=Matrix_DR1'

Matrix_DR0目标库仅在ARCH进程发送用于间隔处理的归档日志的时候才会使用压缩功能(并非用于同步SYNC的归档日志)，而Matrix_DR1库自始至终都会压缩重做日志。这里说明日志并不会在磁盘也保持压缩状态，因为只会在传输过程中压缩日志，所以这些传输到备库的数据会被解压缩，然后再写入到SRL文件中。

MAX_CONNECTIONS 该属性在10gR2中被引入，它允许你指定用于备库间隔处理的归档进程的数量，在11g中已经弃用。不过如果你的版本是10g，你可以为它指定值1-5(默认值1)；如果你设置的值大于1时，每当备库需要进行间隔处理的时候，主库将分配对应数量的归档进程用来发送归档日志文件，这些文件会被分片给这些归档进程，同时在网络中以并行流的形式传送，并在传送到备库时重新装配。

代码如下:

log_archive_dest_2='service=Matrix_DR0
                    LGWR SYNC REOPEN=15 NET_TIMEOUT=15
                    MAX_CONNECTIONS=5
                    valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
                    db_unique_name=Matrix_DR0'

现在当Matrix_DR0库与主库断开连接的时候，主库的间隔处理进程将会对每一个确实的归档日志文件使用多个重做流。

注意：

不要在11g数据库中使用MAX_CONNECTIONS属性，这会降低日志传输的性能。

DELAY 这个属性并不是像大多数想象的那样延迟重做数据的传输，它只是用来指示备库目标的日志应用进程在DELAY属性设置的时间(秒)后应用重做数据。有了闪回数据库，这个属性几乎被弃用，尤其在自从我们建议在主备库中一直启用闪回数据库功能后。如果你倾向于完成一些闪回数据库无法处理的任务量，则可能需要设置这个延迟时间。第8章将讨论闪回数据库和Data Guard。

ALTERNATE 替代(ALTERNATE)目标最初的目的是，当正在归档ORL日志文件的磁盘空间已满时，保持数据库的持续运行。使用替代目标，你可以将归档日志文件重定向到一个备用磁盘中。有了闪回恢复区(自动管理空间)，这个问题基本上消失了。

如果你有多个指向备库的网络路径，也可以为远程备用目标使用该属性。显然，你会在RAC环境中使用多个备库网络路径，但是这并不是ALTERNATE属性设计的初衷。对于有着多网卡的单实例或者RAC的环境，在备库的TNS描述符中使用connect-time failover会更简便。(注：参见connect-time failover )

建议不要使用以下的属性：

LOCATION 在10gR2之前，该属性必须指定一个文件位置用于归档进程存储归档日志文件，并且这在主库(对于ORL文件)和备库(对于SRL文件)确实是正确的。不过随着闪回恢复区和默认本地归档的使用，这个属性已经不再需要设置了。编号为10的目标将自动设置成闪回恢复区。

代码如下:

SQL> SELECT DESTINATION FROM V$ARCHIVE_DEST WHERE DEST_ID=10;
USE_DB_RECOVERY_FILE_DEST

SQL> ARCHIVE LOG LIST
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 19
Next log sequence to archive 21
Current log sequence 2

如果你正在使用闪回恢复区，并且你想定义一个本地目标，那么应该使用相同的语法：

代码如下:

log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix'

如果你还是不使用闪回恢复区，也可以使用旧的磁盘路径写法：

代码如下:

log_archive_dest_1='location=/u03/oradata/Matrix/arch/
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)
db_unique_name=Matrix'

注意在如上的两种情况下，DB_UNIQUE_NAME都是指向你在其上定义了目标(注：也就是归档的存放位置)的数据库，而并非远程的备库。在上面的例子中，归档位置目标在Matrix库上，因此如果你要在这里使用DB_UNIQUE_NAME属性，就需要指定Matrix为DB_UNIQUE_NAME的值。

注意：

如果使用闪回恢复区，就不要使用LOCATION属性来指定本地归档位置了。

MANDATORY 这是备库上最危险的属性之一。基本上，它规定ORL文件中的redo信息必须发送到该备库。如果redo信息无法发送到备库，那么主库中包含redo信息的这个ORL文件在成功发送到备库之前将无法被重用(reuse)。试想当备库无法访问并且主库中所有可用的日志文件都被遍历完了，那么生产系统就会停滞。当然，有一个本地目标是MANDATORY的以使文件存放在磁盘上，不过没有必要再设置另一个了。默认情况下，本地归档中的一个目标会被设置成MANDATORY。

注意：

不要设置MANDATORY属性。

MAX_FAILURE 这个属性是所有属性中最遭人误解的一个。人们都倾向与认为这个属性表示LGWR进程在放弃发生故障的备库并继续产生日志之前，重新连接备库的次数。事实并非如此，如果你设置了该属性，实际是定义了LGWR尝试重连有故障的备库时，日志组切换的次数(注：原文写的更加让人容易误解，这里的意思就是切换一次日志，重连一次备库)。举例来说，如果将MAX_FAILURE的值设置成5，那么LGWR将会在它循环切换日志期间对故障备库总共发起5次连接请求，如果切换了5次还是无法连接到故障备库，那么LGWR将放弃重连，之后你要么等手动重新启用它或者等主库重启重新生效该属性。

注意：

不要设置MAX_FAILURE属性。

NOREGISTER 这是我们讨论的LOG_ARCHIVE_DEST_n参数的最后一个属性。默认情况下，DG要求任何发送到备库的redo数据都需要在归档至磁盘的时候完成对备库的注册。对于一个物理备库来说，意味着数据会被注册到备库的控制文件中；而对于逻辑备库来说，它意味着SQL Apply会在元数据中注册日志文件。DG不需要这个属性，它可以用在使用downstream特性的Streams目标库中。

注意：

不要设置NOREGISTER属性。

LOG_ARCHIVE_DEST_STATE_n 这是和LOG_ARCHIVE_DEST_n配套使用的参数。在过去，有两个原因我们需要配置它。一是启用备库中主角色LOG_ARCHIVE_DEST_n参数的预定义，以使得该参数被启用后归档进程可以使用LOG_ARCHIVE_DEST_n来工作；另一个原因是配置一个如前面所述的ALTERNATE目标。第一个原因已经没有作用了(现在使用了VALID_FOR)，并且除非你使用ALTERNATE属性，否则第二个原因也不成立了，因为现在这个参数默认就是ENABLE的了，你不再需要为你的目标库设置它了。

代码如下:

log_archive_dest_state_1=enable

三、备用角色参数

DB_FILE_NAME_CONVERT 在备库中，该参数允许你逻辑上将数据文件从主库迁移到备库上，如果你使用的是基于磁盘的存储结构并且存储路径在两个系统上并不相同，那么就有必要配置它。只有在备库切换为主库这期间，该转换才会执行。一旦进行主备切换或者故障切换到备库，这些值就会被写入到控制文件和数据文件头。通过简单的字符替换就可以实现功能。

代码如下:

db_file_name_convert='/Matrix/','/Matrix_DR0/'
上面的命令会将如下数据文件名：

代码如下:

'/u03/oradata/Matrix/sysaux.dbf'
转换为：

代码如下:

'/u03/oradata/Matrix_DR0/sysaux.dbf'
同理，如下配置会将数据文件指向到+RECOVERY磁盘组中而不是+DATA；

代码如下:

db_file_name_convert='+DATA','+RECOVERY'
路径的其他部分将保持相同，在本例中，使用了ASM来创建备库，你不需要定义这个参数了。

LOG_FILE_NAME_CONVERT 它的功能和DB_FILE_NAME_CONVERT参数相同，只不过这里转换的是日志文件，包括ORL文件和任何SRL文件。

代码如下:

log_file_name_convert='/Matrix/','/Matrix_DR0/'
FAL_SERVER FAL(Fetch Archive Log)功能相比9iR1时的DG已经有了很大的进步。它只用于物理备库，配置它能够使得物理备库在发现问题时，从DG配置中的一个数据库(主库或备库)中获取缺失的归档日志文件，有时我们又成它为被动间隔处理(reactive gap resolution)，不过FAL技术在之前的三个版本中得到了极大的增强以至于现在几乎不需要再定义FAL参数了。伴随着9iR2版本引入的主动间隔处理(proactive gap resolution)技术的使用，几乎物理或逻辑备库上任何类型的间隔请求都可以由主库上的ping进程来处理了。

在主库的正常工作过程中，归档进程(被指定为ping进程)会轮流查询所有的备库来寻找redo间隔，与此同时处理任何应用进程发来的未解决的间隔请求。当物理备库需要从主库之外的数据库中获得间隔文件时就可以使用FAL技术。举个例子，比如物理备库现在需要进行间隔处理，但是主库无法访问，那么它需要去请求其他的备库来完成间隔处理，为此，你要将FAL_SERVER参数定义为指向主库或者任意备库的TNS标识符列表。如在Matrix_DR0库中加入主库(Matrix)和其他备库(Matrix_DR1)：

代码如下:

fal_server='Matrix, Matrix_DR1'
FAL_CLIENT FAL客户端就是发起间隔请求的数据库的TNS名称，间隔请求的接收方(FAL_SERVER)需要这个TNS名称以使得FAL服务器上的数据库可以反向连接至请求方。在备库Matrix_DR0上，我们发送Matrix_DR0作为客户端名称以便Matrix和Matrix_DR1库可以连接回Matrix_DR0库发送缺失的归档日志文件。

代码如下:

fal_client='Matrix_DR0'
‘Matrix_DR0′必须要在FAL服务器的TNS文件中定义以使得DG能够成功连接备库；因为我们将会在所有这些数据库中设置redo传输参数，所以我们也要为它们配置TNS名称。如果你在FAL参数中使用相同的TNS名称，那么这些TNS名称就是定义好的了。如果你选择了一个不同的名称，你就需要在所有系统的TNS文件中添加这个名称。和FAL_SERVER参数一样，FAL_CLIENT参数只对物理备库有效。

STANDBY_FILE_MANAGEMENT 这是本章节讨论的最后一个参数了。这个简单的参数只用于物理备库。该参数设置成AUTO的时候，主库中添加和删除数据文件的同时，备库中也会自动的进行相应的更改。只要备库中顶级目录存在或能够借助于DB_

FILE_NAME_CONVERT参数找到，那么DG将会执行DDL语句在备库中创建数据文件。它甚至会尽可能的创建缺失的子目录。默认情况下，这个参数的值为MANUAL，这意味着备库上的应用进程不会创建新的数据文件，你需要手动创建它们。

代码如下:

standby_file_management='AUTO'
只有当需要对物理备库上的ORL文件执行定义操作的时候，我们才可能会将该参数设置成MANUAL。SRL文件能够在不改这个参数的情况下添加。如果你真要在物理备库上添加或删除在线日志文件(比如因为主库上发生了更改)，你也可以将这个参数动态的设置成MANUAL，执行DDL操作，然后再还原成AUTO值，无需重启备库。

参数与属性小结

在了解上面的所有参数和属性之后，你应该对它们的功能和特性有了深刻的理解并且可以正确的配置使用了。

希望你不要对这些感到头疼，因为有一点你或许会感到诧异：如果你使用Data Guard Broker(即使不用Grid Control)，就没必要亲自配置这些参数了，DG Broker会为你做好一切。

END

标签：Oracle

返回前面的内容