ITPub博客

首页 > Linux操作系统 > Linux操作系统 > downstream环境下archive进程停止传输日志

downstream环境下archive进程停止传输日志

原创 Linux操作系统 作者:talio 时间:2013-08-28 18:57:26 0 删除 编辑
环境:
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博客 ” ,链接:http://blog.itpub.net/27243841/viewspace-769453/,如需转载,请注明出处,否则将追究法律责任。

下一篇: Goldengate常用命令
请登录后发表评论 登录
全部评论

注册时间:2013-05-14

  • 博文量
    17
  • 访问量
    272921