Diagnostic process for Oracle Rman Backup error (v) Clear Racgimon and Racgmain check process

A large number of zombie processes have been eliminated in the previous article, but this approach can only be palliative and not permanent.

In addition to the large number of Racgmain check processes seen in the operating system, some Racgimon sessions are visible in the database:

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

V1-v3 SYS Racgimon@ahrac1 (TNS) 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

V1-v3 SYS Racgimon@ahrac1 (TNS) sql*net message from client 0

319 SYS Racgimon@ahrac1 (TNS v1-v3) sql*net message from client 276145

17 rows have been selected.

As you can see, all but one of the other Racgimon sessions have a longer wait time than the zombie process that was just cleared, so the "culprit" that the database is now sharing the resources locked in is likely to be these sessions. However, because of the lack of understanding of the task of the session and the consequences of the process of kill these sessions, they have not been touched. After the previous steps, the large number of locked sessions and the waiting session were cleared and the problem remained unresolved, stating that the session just cleared was not the root cause of the problem.

To avoid eliminating this racgimon process and causing the instance to crash, a RAC test environment tried to kill the process corresponding to the Racgimon session, discovering that the instance did not complain, but then automatically started a new Racgimon process.

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

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/