[20170915]DGMGRL reverse properties.txt
--//这段时间看电子文档.<Oracle Data Guard 11g Handbook.pdf>,出版社: McGraw-Hill Companies
--//里面关于使用dgmgrl管理配置dg时提到一个概念,reverse properties.
--//摘要一段内容:
P229
The same does not apply to the property LogShipping, which enables or defers Redo
Transport to that standby database. This is one of those reverse properties—reverse in the sense
that you set it on a database but the resulting SQL command to change the database parameter is
executed on whatever database is the primary at the time. Assume, for example, that Matrix is our
primary database and Matrix_DR0 is our standby database. Changing the LogShipping property
of Matrix will not cause any SQL to be issued at this time. Changing the LogShipping property
on our standby Matrix_DR0 will set the property for Matrix_DR0 in the configuration files, but the
SQL will be executed on the Matrix database. Here's an example:
DGMGRL> SHOW DATABASE MATRIX LogShipping;
LogShipping = 'ON'
DGMGRL> EDIT DATABASE MATRIX SET PROPERTY LogShipping='OFF';
Property "logshipping" updated
DGMGRL> SHOW DATABASE MATRIX LogShipping;
LogShipping = 'OFF'
DGMGRL> SHOW DATABASE MATRIX_DR0 LogShipping;
LogShipping = 'ON'
DGMGRL> EDIT DATABASE MATRIX_DR0 SET PROPERTY LogShipping='OFF';
Property "logshipping" updated
DGMGRL>
DGMGRL> SHOW DATABASE MATRIX_DR0 LogShipping;
LogShipping = 'OFF'
This would set up Matrix not to receive redo when it becomes a standby database and will
stop the transport of redo to Matrix_DR0 immediately. You can verify this by examining the alert
log of Matrix. The only entry you will see is the following:
ALTER SYSTEM SET log_archive_dest_state_2='RESET' SCOPE=BOTH;
The destination parameter number 2 is currently being used by Data Guard to transport redo to
our standby and is now deferred until we change the LogShipping property back to ON.
--//书中提到的主库Matrix,备库Matrix_DR0.
--//说明:改动LogShipping 属性,实际上对应spfile参数文件是log_archive_dest_state_2.
--//也就是在下一次切换日志的时候停止日志传送并应用.
--//如果使用sqlplus,执行命令在主库,一般我会执行如下:
--//ALTER SYSTEM SET log_archive_dest_state_2='defer' SCOPE=memory; 注:dgmrgl 变成 log_archive_dest_state_2='RESET'
--//如果按照一般的理解,如果在DGMGRL下执行,应该是执行如下:
--//DGMGRL> EDIT DATABASE <主库> SET PROPERTY LogShipping='OFF';
--//实际上这样执行是错误的,应该执行:
--//EDIT DATABASE <备库> SET PROPERTY LogShipping='OFF';
--//文档后面还提到修改参数LOG_ARCHIVE_DEST_n也是一样.摘要如下(P230):
LOG_ARCHIVE_DEST_n Attribute properties All of the LOG_ARCHIVE_DEST_n attribute
properties are individual attributes that modify the way Data Guard ships the redo to each
standby, with each property being one of the attributes that is set in a LOG_ARCHIVE_DEST_n
database parameter. Not all of the Redo Transport attributes are available through the Broker and
you cannot set any attributes that are not visible directly with SQL*Plus, because the Broker will
reset the parameter to its view of the world. What you see is what you get. These properties and
the attributes they relate to are shown here:
■ Binding MANDATORY or OPTIONAL
■ LogXptMode ASYNC or SYNC
■ MaxConnections MAX_CONNECTIONS
■ MaxFailure MAX_FAILURE
■ NetTimeout NET_TIMEOUT
■ RedoCompression COMPRESSION
■ ReopenSecs REOPEN
■ DelayMins DELAY=n
These properties are handled differently from the other properties, because although you set
them on a particular database, they are never actually set on that database regardless of the role.
This is similar to the reverse property mentioned in the preceding section and is the one part of
the Broker logic that has always seemed to confound users.
--//reverse property??
As with the other database properties, each database in your configuration has a set of these
properties. But what they define is the manner in which the LOG_ARCHIVE_DEST_n parameter
will be created on the primary database to ship redo to this database. Let's examine this further
using our Matrix primary database and our Matrix_DR0 standby database.
If you were setting up the standby configuration manually, you would (if you followed the best
practices in Chapter 2), add a LOG_ARCHIVE_DEST_n parameter to Matrix that would include the
attribute SERVICE=Matrix_DR0 and any other settings you wanted, which would send the redo
to Matrix_DR0. You would also include the VALID_FOR attribute to enable this destination only
when Matrix is the primary database. Then you would make similar changes to Matrix_DR0, but
with SERVICE=Matrix and the same VALID_FOR, and so on. This parameter would not be
used until Matrix_DR0 becomes the primary database. So if you look at this logically, Matrix is
currently shipping redo to Matrix_DR0, and Matrix_DR0 will begin to ship redo to Matrix when a
role switch occurs.
The Broker attribute properties, on the other hand, are set on the database that is going to receive
redo when it is in the standby role. So to make sure that redo is sent from Matrix to Matrix_DR0, you
would set the properties on Matrix_DR0 accordingly. And to make sure that the same Redo Transport
goes into effect when Matrix_DR0 becomes the primary, you would set these properties on Matrix.
So, for example, if we were to change the transport mode (LogXptMode) so that we ship redo
in the SYNC mode to Matrix_DR0, we would update the property on Matrix_DR0 but the result of
the change would be an ALTER SYSTEM command on Matrix:
DGMGRL> SHOW DATABASE MATRIX_DR0 LogXptMode;
LogXptMode = 'ASYNC'
DGMGRL> EDIT DATABASE MATRIX_DR0 SET PROPERTY LogXptMode='SYNC';
Property "logxptmode" updated
DGMGRL> SHOW DATABASE MATRIX_DR0 LogXptMode;
LogXptMode = 'SYNC'
You would then see the following ALTER SYSTEM command being executed on Matrix from the
alert log (note that the Broker sets the AFFIRM property automatically when you move to SYNC):
ALTER SYSTEM SET log_archive_dest_2='service="matrix_dr0"',' LGWR SYNC
AFFIRM delay=0 OPTIONAL compression=DISABLE max_failure=0 max_connections=1
reopen=300 db_unique_name="matrix_dr0" net_timeout=30
valid_for=(online_logfile,primary_role)' SCOPE=BOTH;
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
--//实际上在操作时,非常容易犯错误,必要时建议tail -f 看alert*.log文件.
--//我曾经在
--//[20140416]使用dgmgrl管理dataguard(4).txt=>http://blog.itpub.net/267265/viewspace-1143126/
--//[20140416]使用dgmgrl管理dataguard(5).txt=>http://blog.itpub.net/267265/viewspace-1143480/
--//犯过这个错误!!想修改RedoCompression='enable'实际上要在执行:
--//DGMGRL> edit database <备库> set property RedoCompression='enable';
--//也就是工作中注意,我感觉主要集中涉及这个LOG_ARCHIVE_DEST_n,log_archive_dest_state_2参数的属性.
--//如果你修改standby_file_management参数,就不是这种情况.
--//直接:
--//DGMGRL> edit database <主库> set property StandbyFileManagement='manual';
--//也许最笨的方法,同时在另外回话执行tail -f alert*.log观察,确定在那个数据库执行了操作..