ARCHIVE_LAG_TARGET引數的作用 -from others

(一)  設定archive_lag_target引數

1.      一旦設定了archive_lag_target初始化引數，資料庫將會週期性的檢查例項的當前重做日誌。如果遇到下列情況，例項將會切換日誌：

n  當前日誌n秒前建立，當前日誌的歸檔時間估計為m秒，n+m的值超過archive_lag_target引數設定。

n  當前日誌包含重做記錄。

2.      在RAC環境中，例項總是使其他執行緒切換並歸檔他們的日誌（如果他們滯後的話）。這是特別有用的，當叢集中的一個例項比其他例項更空閒。

3.      archive_lag_target初始化引數指定在主資料庫關閉或失效的事件中，備用資料庫可以損失多少秒的重做資料（如果data guard環境沒有被配置為no-data-loss模式）。它同時也指定了主資料庫的當前日誌可以跨越的時間上限（秒）。因為歸檔時間是個估計數，所以這不是一個精準的日誌切換時間。

4.      以下語句設定日誌切換間隔為30分鐘（典型配置）

archive_lag_target=1800

5.      該引數的預設值為零，表示禁用基於時間的日誌切換功能；

6.      即使沒有備用資料庫也可以設定archive_lag_target引數。例如：archive_lag_target可以設定為強制日誌切換和歸檔；

7.      archive_lag_target是動態引數，應該使用alter system語句設定。

8.      在RAC環境中，每個例項的archive_lag_target引數必須設定為相同的值。

(二)  影響設定archive_lag_target的因素

1.      如果想設定archive_lag_target引數，應該考慮下列因素：

n  切換日誌（也歸檔）的負載；

n  正常日誌切換的頻率；

n  備用資料庫可以承受的重做資料丟失是多少。

2.      如果自然的日誌切換已經比指定的切換間隔更頻繁，設定archive_lag_target可能並不是非常有用。然而，重做日誌產生的速度不規則的情況下，間隔可以為當前日誌的覆蓋時間範圍提供一個上限限制；

3.      如果archive_lag_target被設定為很低的值，可能會影響效能。因為這樣會強制頻繁地切換日誌；

4.      archive_lag_target應該設定成一個不會降低主資料庫效能的值。

在DataGuard環境中，為了減少故障時資料損失，我們可以設定ARCHIVE_LAG_TARGET引數，強制進行日誌切換。

ARCHIVE_LAG_TARGET引數可以設定一個時間，透過時間限制，指定資料庫強制進行Log Switch，進行歸檔。

這個引數的預設值是0，即為不啟用該引數。該引數合理的取值範圍在60 ~ 7200之間。
通常大於7200和小於1800不被推薦，低於30分鐘的切換時間可能導致效能問題。

以下是我的一個生產環境的設定效果。
設定之前:

SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

Session altered.

SQL> col name for a60
SQL> select name,COMPLETION_TIME from v$archived_log where name is not null;

NAME COMPLETION_TIME
------------------------------------------------------------ -------------------
/data2/oradata/STAT/archive/1_5441_593258512.dbf 2006-11-20 10:49:57
/data2/oradata/STAT/archive/1_5442_593258512.dbf 2006-11-20 15:49:50

由於資料庫並不繁忙，日誌很久才會切換一次。

設定archive_lag_target引數:

SQL> show parameter archive_lag

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
SQL> alter system set archive_lag_target=1800;

System altered.

SQL> show parameter archive_lag

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 1800

此時可以看到日誌切換時間發生改變:

[oracle@STAT ~]$ sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.2.0 - Production on Mon Nov 20 21:31:31 2006

Copyright (c) 1982, 2005, Oracle. All Rights Reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining Scoring Engine options

SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /data2/oradata/STAT/archive
Oldest online log sequence 5449
Next log sequence to archive 5451
Current log sequence 5451
SQL> !
[oracle@STAT ~]$ ll /data2/oradata/STAT/archive
total 125776
-rw-r----- 1 oracle oinstall 43030016 Nov 20 10:49 1_5441_593258512.dbf
-rw-r----- 1 oracle oinstall 43122688 Nov 20 15:49 1_5442_593258512.dbf
-rw-r----- 1 oracle oinstall 14172672 Nov 20 17:31 1_5443_593258512.dbf
-rw-r----- 1 oracle oinstall 3620864 Nov 20 18:02 1_5444_593258512.dbf
-rw-r----- 1 oracle oinstall 3511296 Nov 20 18:32 1_5445_593258512.dbf
-rw-r----- 1 oracle oinstall 3626496 Nov 20 19:02 1_5446_593258512.dbf
-rw-r----- 1 oracle oinstall 4903936 Nov 20 19:32 1_5447_593258512.dbf
-rw-r----- 1 oracle oinstall 3521536 Nov 20 20:02 1_5448_593258512.dbf
-rw-r----- 1 oracle oinstall 5144576 Nov 20 20:32 1_5449_593258512.dbf
-rw-r----- 1 oracle oinstall 3916800 Nov 20 21:02 1_5450_593258512.dbf

這個引數在DataGuard/Standby環境中是非常有效的。