3、Standby端配置

啟動監聽器，建立聯絡。但是這個時候，我們不啟動standby資料庫。

[oracle@SimpleLinux ~]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 27-APR-2014 14:32:11

Starting /u01/app/oracle/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 11.2.0.4.0 - Production

System parameter file is /u01/app/oracle/network/admin/listener.ora

Log messages written to /u01/app/diag/tnslsnr/SimpleLinux/listener/alert/log.xml

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SimpleLinux)(PORT=1521)))

Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=SimpleLinux)(PORT=1521)))

STATUS of the LISTENER

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

Alias LISTENER

Version TNSLSNR for Linux: Version 11.2.0.4.0 - Production

Start Date 27-APR-2014 14:32:13

Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File /u01/app/oracle/network/admin/listener.ora

Listener Log File /u01/app/diag/tnslsnr/SimpleLinux/listener/alert/log.xml

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=SimpleLinux)(PORT=1521)))

(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))

Services Summary...

Service "ora11g" has 1 instance(s).

Instance "ora11g", status UNKNOWN, has 1 handler(s) for this service...

Service "ora11gsy" has 1 instance(s).

Instance "ora11gsy", status UNKNOWN, has 1 handler(s) for this service...

The command completed successfully

監聽器啟動之後，Primary端日誌迴圈報錯資訊變化，減少到心跳heartbeat錯誤。

Sun Apr 27 14:33:02 2014

Error 1034 received logging on to the standby

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

錯誤程式碼從原來的12541，變化為1034。

[oracle@SimpleLinux ~]$ oerr ora 1034

01034, 00000, "ORACLE not available"

// *Cause: Oracle was not started up. Possible causes include the following:

// - The SGA requires more space than was allocated for it.

// - The operating-system variable pointing to the instance is

// improperly defined.

// *Action: Refer to accompanying messages for possible causes and correct

// the problem mentioned in the other messages.

// If Oracle has been initialized, then on some operating systems,

// verify that Oracle was linked correctly. See the platform

// specific Oracle documentation.

對於傳遞日誌的ARCH程式而言，在傳遞日誌的過程中，其實就是一個一般的client process。在訪問過程中，遇到的問題和一般連線問題沒有太多的差異。

Standby端啟動過程。

[oracle@SimpleLinux ~]$ export ORACLE_SID=ora11gsy

[oracle@SimpleLinux ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.4.0 Production on Sun Apr 27 14:39:18 2014

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 331353348 bytes

Database Buffers 33554432 bytes

Redo Buffers 6176768 bytes

Standby端alert log資訊。

Sun Apr 27 14:39:32 2014

MMNL started with pid=16, OS id=2339

starting up 1 shared server(s) ...

ORACLE_BASE from environment = /u01/app

Sun Apr 27 14:40:09 2014

Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST

destination database instance is 'started' not 'mounted'

這個時候，Primary日誌也發生變化，heartbeat錯誤依然，錯誤編號變化。

Sun Apr 27 14:39:07 2014

Error 1034 received logging on to the standby

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

Sun Apr 27 14:40:10 2014

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

Sun Apr 27 14:41:10 2014

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

錯誤含義：

[oracle@SimpleLinux ~]$ oerr ora 16058

16058, 00000, "standby database instance is not mounted"

// *Cause: The Remote File Server (RFS) process on the standby database

// received an internal error.

// *Action: Check the standby alert log and RFS trace files for more

// information.

RFS程式是Oracle DG傳遞日誌的一個重要程式。錯誤裡面，也指出standby要啟動到mount才可以。

這個時候，standby端也“感覺”到傳遞的問題，也在不斷報錯。

Sun Apr 27 14:41:10 2014

destination database instance is 'started' not 'mounted'

Sun Apr 27 14:42:10 2014

destination database instance is 'started' not 'mounted'

啟動資料庫到mount狀態。

SQL> alter database mount;

Database altered.

Standby端日誌變化：

Sun Apr 27 14:45:04 2014

alter database mount

ARCH: STARTING ARCH PROCESSES

Sun Apr 27 14:45:09 2014

ARC0 started with pid=20, OS id=2525

ARC0: Archival started

ARCH: STARTING ARCH PROCESSES COMPLETE

ARC0: STARTING ARCH PROCESSES

Sun Apr 27 14:45:10 2014

Successful mount of redo thread 1, with mount id 4242154160

Physical Standby Database mounted.

Lost write protection disabled

Sun Apr 27 14:45:11 2014

ARC1 started with pid=21, OS id=2527

Completed: alter database mount --mount結束，下面就進行接收動作。

Sun Apr 27 14:45:11 2014

ARC2 started with pid=22, OS id=2529

Sun Apr 27 14:45:11 2014

ARC3 started with pid=23, OS id=2531

ARC1: Archival started

ARC2: Archival started

ARC3: Archival started

ARC1: Becoming the 'no FAL' ARCH

Sun Apr 27 14:45:12 2014

ARC4 started with pid=24, OS id=2535

ARC2: Becoming the heartbeat ARCH

ARC2: Becoming the active heartbeat ARCH

ARC4: Archival started

ARC0: STARTING ARCH PROCESSES COMPLETE

--RFS工作

Sun Apr 27 14:45:14 2014

RFS[1]: Assigned to RFS process 2539

RFS[1]: Selected log 5 for thread 1 sequence 32 dbid -55025450 branch 843741722

Sun Apr 27 14:45:14 2014

RFS[2]: Assigned to RFS process 2541

RFS[2]: Opened log for thread 1 sequence 33 dbid -55025450 branch 843741722

Archived Log entry 30 added for thread 1 sequence 33 rlc 843741722 ID 0xfcd0f891 dest 2:

Sun Apr 27 14:45:17 2014

Primary database is in MAXIMUM PERFORMANCE mode

Archived Log entry 31 added for thread 1 sequence 32 ID 0xfcd0f891 dest 1:

RFS[3]: Assigned to RFS process 2547

RFS[3]: Selected log 4 for thread 1 sequence 35 dbid -55025450 branch 843741722

Sun Apr 27 14:45:24 2014

RFS[4]: Assigned to RFS process 2553

RFS[4]: Selected log 5 for thread 1 sequence 34 dbid -55025450 branch 843741722

Sun Apr 27 14:45:35 2014

Archived Log entry 32 added for thread 1 sequence 34 ID 0xfcd0f891 dest 1:

RFS是一個服務，從日誌看，是Primary端的程式來負責完成的。對應程式也的確印證。

oracle 2539 1 0 14:45 ? 00:00:00 oracleora11gsy (LOCAL=NO)

oracle 2547 1 0 14:45 ? 00:00:00 oracleora11gsy (LOCAL=NO)

oracle 2553 1 0 14:45 ? 00:00:00 oracleora11gsy (LOCAL=NO)

oracle 2578 1 0 14:50 ? 00:00:00 oracleora11gsy (LOCAL=NO)

Primary端情況如下：

Sun Apr 27 14:45:15 2014

Thread 1 advanced to log sequence 35 (LGWR switch)

Current log# 1 seq# 35 mem# 0: /u01/app/oradata/ORA11G/onlinelog/o1_mf_1_9mnjwtj9_.log

Current log# 1 seq# 35 mem# 1: /u01/app/fast_recovery_area/ORA11G/onlinelog/o1_mf_1_9mnjwvdm_.log

Sun Apr 27 14:45:15 2014

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

LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2

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

Sun Apr 27 14:45:15 2014

ARC0: Standby redo logfile selected for thread 1 sequence 32 for destination LOG_ARCHIVE_DEST_2

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

Sun Apr 27 14:45:23 2014

Archived Log entry 54 added for thread 1 sequence 34 ID 0xfcd0f891 dest 1:

Sun Apr 27 14:45:23 2014

Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST

ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=MEMORY SID='*';

Sun Apr 27 14:45:24 2014

ARC3: Standby redo logfile selected for thread 1 sequence 34 for destination LOG_ARCHIVE_DEST_2

在ping通standby端之後，Oracle Primary就會將之前invalid狀態的日誌歸檔資料通道打通啟動（自動）。日誌傳輸開始。

4、日誌Apply過程

在standby端啟動應用動作。

SQL> alter database recover managed standby database using current logfile disconnect from session;

Database altered.

日誌對應：

Sun Apr 27 14:55:32 2014

alter database recover managed standby database using current logfile disconnect from session

Attempt to start background Managed Standby Recovery process (ora11gsy)

Sun Apr 27 14:55:33 2014

MRP0 started with pid=29, OS id=2620

MRP0: Background Managed Standby Recovery process started (ora11gsy)

Serial Media Recovery started

Managed Standby Recovery starting Real Time Apply

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Media Recovery Log /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_27/o1_mf_1_32_9os9vxko_.arc

Completed: alter database recover managed standby database using current logfile disconnect from session

Media Recovery Log /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_27/o1_mf_1_33_9os9vtp5_.arc

Media Recovery Log /u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_27/o1_mf_1_34_9os9w9xf_.arc

Sun Apr 27 14:56:12 2014

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

Recovery of Online Redo Log: Thread 1 Group 4 Seq 35 Reading mem 0

Mem# 0: /u01/app/oradata/ORA11GSY/onlinelog/o1_mf_4_9nn8pckn_.log

Mem# 1: /u01/app/fast_recovery_area/ORA11GSY/onlinelog/o1_mf_4_9nn8pjjx_.log

如此，啟動完成。

5、結論

從上面的實驗，我們可以瞭解Oracle DG的一些特性。

ü DG的重要元件是監聽器。一般常見的配置策略，是關閉動態註冊方法，對Primary和Standby採用靜態註冊手段。Oracle Primary在從mount到open過程中，就會非同步的進行日誌傳遞，檢查連線到standby的網路通路。而且，這個檢測過程是貫徹始終的。如果資料庫處在最大保護狀態，相信這個檢測不透過的話，Primary一定會受到影響；

ü 除了監聽器檢查，還會有heartbeat檢查過程。相信在全過程，Primary都在進行heartbeat檢查，判斷Redo Log是否可以正常傳遞。我們配置service只是指定了服務名，至於standby log位置資訊，還要保證standby處在mount狀態下，因為只有這個狀態，例項才知道standby log的位置在哪裡；

ü Standby啟動之後，RFS服務是透過一系列的server process來實現的。來接收日誌進行儲存；

從alert日誌看Oracle 11g Datagurad日誌傳輸（下）

相關文章