環境：

oracle 10.2.0.5 + solaris 10

問題描述:

A和B兩個資料庫之間透過stream技術同步部分表的資料,同事反映B庫上的downstream hung 在過去某個時間點,狀態為waiting for redo ....這種情況是由於日誌沒有從A資料庫傳過來造成的（具體原因未在該文討論）

現在要解決的問題是如何讓oracle繼續傳送日至.

問題分析:

downstream需要的日誌是透過archive程式傳輸的.

檢視A資料庫引數log_archive_max_processes,我們看到資料庫配置了最多8個archive程式

SQL> show parameter log_archive_max_processes

NAME TYPE VALUE

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

log_archive_max_processes integer 8

select * from v$managed_standby;

PROCESS PID STATUS CLIENT_P CLIENT_PID

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

CLIENT_DBID GROUP# RESETLOG_ID THREAD# SEQUENCE#

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

BLOCK# BLOCKS DELAY_MINS KNOWN_AGENTS ACTIVE_AGENTS

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

ARCH 4001 OPENING ARCH 4001

73286670 N/A 394551950 1 965523

1826817 137 0 0 0

ARCH 4003 OPENING ARCH 4003

73286670 N/A 394551950 1 965519

1669121 1763 0 0 0

ARCH 4005 CLOSING ARCH 4005

73286670 N/A 394551950 1 953814

4128769 268 0 0 0

ARCH 28489 CLOSING ARCH 28489

73286670 2 394551950 1 965517

2195457 1973 0 0 0

ARCH 4297 CONNECTED ARCH 4297

73286670 N/A 0 0 0

0 0 0 0 0

ARCH 28499 OPENING ARCH 28499

73286670 N/A 394551950 1 965520

2195457 1973 0 0 0

ARCH 28504 OPENING ARCH 28504

73286670 N/A 394551950 1 965522

1378305 953 0 0 0

ARCH 28508 OPENING ARCH 28508

73286670 N/A 394551950 1 965521

1456129 879 0 0 0

查詢archive程式狀態可看到其中有5個程式是在OPENING狀態,理論上是可以傳送日誌的.但為什麼不工作呢?

透過truss命令檢視程式系統呼叫狀況,發現archive程式4003處於sleeping狀態:

oracle $ truss -p 4003

/13: lwp_park(0x00000000, 0) (sleeping...)

/17: lwp_park(0x00000000, 0) (sleeping...)

/3: lwp_park(0x00000000, 0) (sleeping...)

/12: lwp_park(0x00000000, 0) (sleeping...)

/2: kaio(6, 0x00000000, 0xFFFFFFFF7AB4A300, 0x00000010, 0xFFFFFFFF7AB4BF98, 0xFFFFFFFF7B900A00) (sleeping...)

為什麼會出現這種狀態呢? 推測是因為發生異常後,archive程式掛起,可能需要一定時間或者是其他程式的喚醒才能讓其繼續工作.但這只是推測,為了不無限期得等待下去,通常會採用一些人為干預措施.

比如,我們可將log_archive_dest_state_引數設定為defer,然後再設定為enable,透過這種方式來喚醒archive程式繼續工作.經驗表明,這種方法很多時候是可以解決問題的.但很不幸,這次沒有生效.

接下來,可採用修改log_archive_max_processes引數的方式,將其值從原來的8改為10,這樣,資料庫會新建2個archive程式,新建程式通常是可以正常工作的.

SQL> select * from v$managed_standby;

PROCESS PID STATUS CLIENT_P CLIENT_PID

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

CLIENT_DBID GROUP# RESETLOG_ID THREAD# SEQUENCE#

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

BLOCK# BLOCKS DELAY_MINS KNOWN_AGENTS ACTIVE_AGENTS

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

ARCH 4001 OPENING ARCH 4001

73286670 N/A 394551950 1 965523

1826817 137 0 0 0

ARCH 4003 OPENING ARCH 4003

73286670 N/A 394551950 1 965519

1669121 1763 0 0 0

ARCH 4005 CLOSING ARCH 4005

73286670 N/A 394551950 1 953814

4128769 268 0 0 0

ARCH 28489 CLOSING ARCH 28489

73286670 2 394551950 1 965517

2195457 1973 0 0 0

ARCH 4297 CLOSING ARCH 4297

73286670 7 394551950 1 965728

471041 1610 0 0 0

ARCH 28499 OPENING ARCH 28499

73286670 N/A 394551950 1 965520

2195457 1973 0 0 0

ARCH 28504 OPENING ARCH 28504

73286670 N/A 394551950 1 965522

1378305 953 0 0 0

ARCH 28508 OPENING ARCH 28508

73286670 N/A 394551950 1 965521

1456129 879 0 0 0

ARCH 6090 WRITING ARCH 6090

73286670 N/A 394551950 1 965523

550913 2048 0 0 0

ARCH 6092 WRITING ARCH 6092

73286670 N/A 394551950 1 965524

120833 2048 0 0 0

10 rows selected.

從v$managed_standby檢視看到,新建的兩個程式為WRITING狀態,表明archive開始寫資料了. truss跟蹤可以看到這一點, B節點上也開始寫新的日誌了.

dtci-ndancnr01:oracle $ truss -p 6090

/1: write(19, "7FDA\0\006\0\0\0\0\001\0".., 32730) = 32730

/1: write(19, "7FDA\0\006\0\0\0\0\0\0\0".., 32730) = 32730

/1: write(19, "7FDA\0\006\0\0\0\0\0 H\0".., 32730) = 32730

/1: write(19, "7FDA\0\006\0\0\0\0\006D9".., 32730) = 32730

/1: write(19, "7FDA\0\006\0\0\0\0\0 B [".., 32730) = 32730

/1: write(19, "7FDA\0\006\0\0\0\0\0\0\0".., 32730) = 32730

downstream環境下archive程式停止傳輸日誌

相關文章