【DATAGUARD 學習】同一台主機的dataguard 密碼問題！

DATAGUARD的資料傳輸方式有兩種：LGWR和ARCH。其中前者傳送的是聯機日志的redo，後者傳輸的是歸檔。

FAL是9i推出的DATAGUARD的一大改進，它可以自動傳送備庫缺失的日志，一般情況下，它是不需要手工幹預的。

主庫的日志要傳輸到備庫，兩者的密碼檔案中設定的密碼必須一緻。然而，如果我們不小心設定了不一緻的密碼，則需要重新生成備庫的密碼檔案，但重置密碼檔案後，FAL還并不能自動處理日志的GAP，需要DBA做一些額外的工作。

在這種情況下，用LGWR和ARCH兩種方式的處理方式有所差別，下面分别讨論:

一、ARCH方式傳送日志

--主庫參數

SQL> show parameter dest_2

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_create_online_log_dest_2 string

log_archive_dest_2 string SERVICE=standby LGWR ASYNC VA

LID_FOR=(ONLINE_LOGFILES,PRIMA

RY_ROLE) DB_UNIQUE_NAME=standb

y

--在備庫上查詢

SQL> select * from v$standby_log;

no rows selected

我們知道，用LGWR傳送日志，如果備庫沒有standby redo log，則oracle自動會變成用ARCH傳送歸檔。

為了模拟主備庫密碼檔案不一緻，我們重新生成備庫密碼檔案，并置一個與主庫不一樣的密碼。

[oracle@standby dbs]$ mv orapwprimary orapwprimary.bak

[oracle@standby dbs]$ orapwd file=orapwprimary password=aaa entries=10

接着重新開機主庫，檢視主庫的alert日志，可以發現下面的資訊：

Tue Jul 10 22:10:38 2007

Errors in file /u01/oracle/admin/primary/bdump/primary_arc1_3338.trc:

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing

ORACLE Instance primary - Archival Error. Archiver continuing.

Tue Jul 10 22:10:47 2007

FAL[server]: Fail to queue the whole FAL gap

GAP - thread 1 sequence 68-68

DBID 1463588919 branch 626106231

Tue Jul 10 22:15:50 2007

Error 1017 received logging on to the standby

------------------------------------------------------------

Check that the primary and standby are using a password file

and remote_login_passwordfile is set to SHARED or EXCLUSIVE,

and that the SYS password is same in the password files.

returning error ORA-16191

ORA-16191: Primary log shipping client not logged on standby

PING[ARC1]: Heartbeat failed to connect to standby 'standby'. Error is 16191.

從上面的資訊不難看出，oracle的确換成了ARCH的方式傳送日志，并且因為密碼檔案的原因不能傳送到備庫中。

如果檢視備庫的日志，也可以發現類似如下的資訊：

FAL[client]: Failed to request gap sequence

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

接着，我們在備庫還原密碼檔案，并重新開機備庫：

[oracle@standby dbs]$ rm orapwprimary

[oracle@standby dbs]$ mv orapwprimary.bak orapwprimary

SQL> shutdown immediate

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Total System Global Area 167772160 bytes

Fixed Size 1260696 bytes

Variable Size 134218600 bytes

Database Buffers 29360128 bytes

Redo Buffers 2932736 bytes

Database mounted.

SQL> alter database recover managed standby database disconnect from session;

Database altered.

然而，隔一段時間後觀察主、備庫的日志，仍然有上面的報錯資訊，說明這種情況下重新開機備庫是沒有效果的。

我們再重新開機主庫試試：

Database closed.

SQL> startup

Variable Size 150995816 bytes

Database Buffers 12582912 bytes

Database opened.

隔一小段時間可以分别在主、備庫上看到如下資訊：

--主庫

Tue Jul 10 22:41:57 2007

******************************************************************

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

--備庫

Tue Jul 10 22:31:57 2007

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[5]: Assigned to RFS process 16058

RFS[5]: Identified database type as 'physical standby'

Primary database is in MAXIMUM PERFORMANCE mode

RFS[5]: No standby redo logfiles created

Tue Jul 10 22:32:26 2007

Media Recovery Log /u01/archivelog/1_70_626106231.dbf

Media Recovery Waiting for thread 1 sequence 71 (in transit)

以上資訊充分說明，DATAGUARD日志傳送已經恢複正常。

實際上，經過測試，我們在修改密碼檔案後隻需要重新開機主庫即可恢複日志正常傳送。

二、LGWR方式傳送日志

為了讓oracle可以用LGWR方式傳送日志，我們先在備庫上建立幾個standby redo log。

SQL> alter database add standby logfile group 4 '/u01/oracle/oradata/primary/standbyredo04.log' size 50m;

SQL> alter database add standby logfile group 5 '/u01/oracle/oradata/primary/standbyredo5.log' size 50m;

SQL> alter database add standby logfile group 6 '/u01/oracle/oradata/primary/standbyredo6.log' size 50m;

SQL> alter database add standby logfile group 7 '/u01/oracle/oradata/primary/standbyredo7.log' size 50m;

重新生成一個與主庫不一緻的密碼檔案：

重新生成一個密碼檔案後，必須重新開機備庫才能模拟錯誤（不重新開機的話是不會影響日志傳輸的）

Variable Size 142607208 bytes

Database Buffers 20971520 bytes

此時主庫alert日志報錯如下：

Tue Jul 10 23:06:30 2007

Errors in file /u01/oracle/admin/primary/bdump/primary_arc0_3457.trc:

PING[ARC0]: Heartbeat failed to connect to standby 'standby'. Error is 16191.

備庫alert報錯：

Tue Jul 10 22:53:06 2007

GAP - thread 1 sequence 79-79

上面的資訊與ARCH方式傳送日志的測試報錯類似，就不解析了。

我們重新開機備庫，并備庫觀察日志：

Tue Jul 10 23:13:28 2007

RFS[2]: Assigned to RFS process 16235

RFS[2]: Identified database type as 'physical standby'

Tue Jul 10 23:25:21 2007

RFS[3]: Assigned to RFS process 16237

RFS[3]: Identified database type as 'physical standby'

RFS[3]: Successfully opened standby log 4: '/u01/oracle/oradata/primary/standbyredo04.log'

Tue Jul 10 23:25:23 2007

RFS[4]: Assigned to RFS process 16239

RFS[4]: Identified database type as 'physical standby'

RFS[4]: Successfully opened standby log 4: '/u01/oracle/oradata/primary/standbyredo04.log'

從備庫的alert資訊看，日志傳送已經恢複正常。

但此時主庫還會繼續報如下的錯誤：

Tue Jul 10 23:18:31 2007

GAP - thread 1 sequence 80-80

LNS1 started with pid=18, OS id=3499

這是因為雖然備庫重建了密碼檔案，并且存在standby redo log，但主庫仍然嘗試用ARCH的方式傳送日志，直到切換日志。

我們切換一下主庫日志，主庫alert資訊就不會再報錯了：

SQL> alter system switch logfile;

System altered.

Tue Jul 10 23:35:02 2007

ARC2: Standby redo logfile selected for thread 1 sequence 80 for destination LOG_ARCHIVE_DEST_2

Tue Jul 10 23:35:05 2007

LNS: Standby redo logfile selected for thread 1 sequence 81 for destination LOG_ARCHIVE_DEST_2

進一步測試可以發現：在這種情況下，隻重新開機主庫也可以恢複日志的正常傳送。

簡單總結：

1、ARCH方式傳送日志時，如果主備庫密碼檔案不一緻，在重新設定密碼檔案後，必須重新開機主庫才能使日志傳送恢複正常

2、LGWR方式傳送日志時，如果主備庫密碼檔案不一緻，在重新設定密碼檔案後，隻需可以重新開機主庫或重新開機備庫就可使日志傳送恢複正常。

看來LGWR在減少可能的資料損失同時，還可以減低主庫重新開機的幾率，推薦大家使用這種方式作為日志傳送手段。

<a href="http://www.itpub.net/521086.html" target="_blank">http://www.itpub.net/521086.html</a>