web-dev-qa-db-ja.com

Data Guard Brokerのカスケードスタンバイ遅延パラメーターは無視されます

3つのデータベースがあります。db01プライマリ、db02スタンバイカスケード、db03スタンバイカスケード。

次の方法でブローカーのパラメーターを構成しました。

DGMGRL> show configuration
Configuration – DB_HQ_DR
Protection Mode: MaxPerformance
Members:
db01 – Primary database
db02 – Physical standby database
db03- Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> edit database ‘db01′ set property RedoRoutes='(LOCAL:db02)(db02:db03)’;
Property “redoroutes” updated

DGMGRL> edit database ‘db02′ set property RedoRoutes='(LOCAL:db01)(db01:db03)’;
Property “redoroutes” updated

-構成されたdelayminsパラメーター:

DGMGRL> edit database ‘db03′ set property DelayMins=’21600’;

Db02でlog_archive_dest_2パラメーターを選択すると、遅延パラメーター21600があるはずです。

SQL> show parameter log_archive_dest_2

log_archive_dest_2   |  service="db03",  delay=21600 optional compression=disable  max_failure=0 max_connections=1 reopen=300

db_unique_name = "db03" net_timeout = 30、有効な_for =(standby_logfile、all_roles)

DGMGRL> show configuration
Configuration – DB_HQ_DR
Protection Mode: MaxPerformance
Members:
db01 – Primary database
db02 – Physical standby database
db03- Physical standby database (receiving archived redo)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

問題は、適用プロセスが遅れないことです。アーカイブログが生成されるとすぐに適用されます。何が起こるのですか?なぜ遅延パラメータが無視されるのですか?

3
kupa

カスケードスタンバイに遅延を適用したい場合は、プライマリでLOG_ARCHIVE_DEST_nDELAYを設定する必要があります。

カスケードスタンバイが使用するDELAY値は、REDOをカスケードスタンバイに送信したプライマリのLOG_ARCHIVE_DEST_nパラメータに設定された値です。

参照: [〜#〜]遅延[〜#〜]

1
JSapkota