环境：
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
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/27243841/viewspace-769453/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
Goldengate常用命令
请登录后发表评论
登录
全部评论
