oracle技术之一次RMAN备份报错的诊断过程（五）

最新推荐文章于 2023-03-31 21:30:00 发布

weixin_33733810

最新推荐文章于 2023-03-31 21:30:00 发布

阅读量189

点赞数

文章标签：数据库操作系统运维

原文链接：http://blog.51cto.com/19880614/1207581

版权

今天检查数据库中的备份输出脚本时，发现RMAN备份出现了错误。

通过清除racgimon以及racgmain check进程来尝试解决问题。

在上一篇文章中清除了大量的僵死进程，但是这个方法只能治标而不能治本。

除了操作系统中看到的大量racgmain check进程之外，数据库中还可以看到一些racgimon会话：

SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME

2 FROM V$SESSION

3 WHERE PROGRAM LIKE 'racg%';

SID USERNAME PROGRAM EVENT TIME

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

123 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276138

124 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276142

130 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276123

132 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276145

147 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276145

148 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276105

150 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276111

151 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276051

156 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276123

279 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276142

284 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276138

290 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276102

297 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276138

298 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276132

306 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276105

314 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 0

319 SYS racgimon@ahrac1 (TNS V1-V3) SQL*Net message from client 276145

已选择17行。

可以看到，除了其中一个之外，其他所有racgimon会话的等待时间都要比刚才清除的僵死进程时间要长，那么数据库现在共享资源被锁定的“元凶”很可能就是这些会话。但是由于对这个会话的任务不了解，而且kill这些会话的进程后果也不清楚，因此一直没有碰这些会话。经过前面的步骤，清除了大量的占用锁的会话以及处于等待的会话，问题仍然没有解决，说明刚才清除的会话都不是造成问题的根本所在。

为了避免清除掉这个racgimon进程，导致实例崩溃，在一个RAC测试环境尝试了一下杀掉racgimon会话对应的进程，发现实例并不会报错，而是随后自动启动了一个新的racgimon进程。

SQL> SELECT 'kill -9 ' || SPID

2 FROM V$PROCESS

3 WHERE ADDR IN

4 (SELECT PADDR FROM V$SESSION

5 WHERE PROGRAM LIKE 'racgimon%'

6 AND SECONDS_IN_WAIT > 86400);

'KILL-9'||SPID

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

kill -9 8042

kill -9 8219

kill -9 8221

kill -9 23136

kill -9 19091

kill -9 23140

kill -9 19441

kill -9 22653

kill -9 22655

kill -9 22686

kill -9 19406

kill -9 23171

kill -9 21666

kill -9 22004

kill -9 23134

kill -9 23169

已选择16行。

SQL> HOST

$ kill -9 8042

$ kill -9 8219

$ kill -9 8221

$ kill -9 23136

$ kill -9 19091

$ kill -9 23140

$ kill -9 19441

$ kill -9 22653

$ kill -9 22655

$ kill -9 22686

$ kill -9 19406

$ kill -9 23171

$ kill -9 21666

$ kill -9 22004

$ kill -9 23134

$ kill -9 23169

$ exit

在另一个实例上执行同样的操作：

SQL> SELECT SID, USERNAME, PROGRAM, EVENT, SECONDS_IN_WAIT TIME

2 FROM V$SESSION

3 WHERE PROGRAM LIKE 'racg%';

SID USERNAME PROGRAM EVENT TIME

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

113 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 277028

142 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 276532

197 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 3

309 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 278230

324 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 277631

325 SYS racgimon@ahrac2 (TNS V1-V3) SQL*Net message from client 276592

已选择6行。

SQL> SELECT 'kill -9 ' || SPID

2 FROM V$PROCESS

3 WHERE ADDR IN

4 (SELECT PADDR FROM V$SESSION

5 WHERE PROGRAM LIKE 'racgimon%'

6 AND SECONDS_IN_WAIT > 86400);

'KILL-9'||SPID

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

kill -9 10059

kill -9 10219

kill -9 4510

kill -9 9827

kill -9 10217

SQL> HOST

$ kill -9 10059

$ kill -9 10219

$ kill -9 4510

$ kill -9 9827

$ kill -9 10217

$ exit

问题仍然没有完全解决，看来只能将实例1上大量的racgmain check进程杀掉。

进程杀掉之后问题仍然没有解决，看来是数据库的状态存在问题了，现在唯一的方法就只能重启实例了，好在是RAC环境，可以先重启一个节点，然后再重启另一个。

没想到问题远比我想象的还要复杂，实例1通过svrctl命令关闭数据库没有相应，随后使用SHUTDOWN IMMEDIATE，也没有响应，最终导致所有的用户都无法登陆到实例，但是数据库并没有关闭，后台日志显示：

Wed May 27 12:25:13 2009

Starting background process EMN0

Wed May 27 12:27:13 2009

ERROR: Emon failed to start.

Shutting down instance: further logons disabled

Wed May 27 12:27:16 2009