oracle 11g latch之v$latch和systemstate dump文件之系列四

最新推荐文章于 2024-09-29 16:19:38 发布

clg10051

最新推荐文章于 2024-09-29 16:19:38 发布

阅读量166

点赞数

文章标签：数据库后端操作系统

背景

在上文 http://blog.itpub.net/9240380/viewspace-1821684/
基础上，
整合latch和systemstate dump文件的分析，逐步掌握如何分析systemstate dump文件，同时加深对于latch理解。

结论

1,当数据库发生等待LATCH时，可以采用systemstate dump进行分析
2,分析systemstate dump文件的原则如下：
A,查找waiting for，可以找到等待LATCH的进程，这样就获取到等待LATCH的进程相关信息了
B,waiting for后面跟的信息即等待LATCH的地址，即V$LATCH的ADDR列，如果是子LATCH,即V$LATCH_CHILDRENT的ADDR列，并且还有哪个子LATCH的编号标识，即LATCH#
C，同样从等待LATCH的进程，查找holder，则可以定位到持LATCH的进程信息，即HOLDER ORAPID=ORACLE进程号
或者查找POSSIBLE HOLDER PID也可以

PROCESS 30:
----------------------------------------
SO: 0xdd5bc340, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bc340, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:30, ser:6, calls cur/top: 0xdcd53638/0xdcd53638
flags : (0x0) -
flags2: (0x0), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 134 0 2
last post received-location: ksl2.h LINE:2165 ID:kslpsr
last process to post me: dd5a8e80 1 6
last post sent: 0 0 26
last post sent-location: ksa2.h LINE:282 ID:ksasnd
last process posted by me: dd5a8e80 1 6
(latch info) wait_event=0 bits=0
Location from where call was made: kgh.h LINE:6334 ID:kghalo:
waiting for 601038c8 Child shared pool level=7 child#=1 ---waiting for可见这个进程30正在等待shared pool latch的子latch ,latch#为1，而且601038c8为等待的latch地址，对应v$latch的addr
Location from where latch is held: kgh.h LINE:6354 ID:kghfre: Chunk Header
Context saved from call: 3739691352
state=busy [holder orapid=1] wlstate=free [value=0] --holder可以发现持LATCH的信息，表明1号ORACLE进程占有了上述的LATCH
waiters [orapid (seconds since: put on list, posted, alive check)]:
27 (95, 1446364071, 95)
15 (92, 1446364071, 92)
30 (72, 1446364071, 72)
60 (71, 1446364071, 71)
waiter count=4
gotten 3610857 times wait, failed first 3931 sleeps 4121
gotten 0 times nowait, failed: 0
possible holder pid = 1 ospid=
on wait list for 601038c8
Process Group: DEFAULT, pseudo proc: 0xdd9a34d0
O/S info: user: oracle, term: UNKNOWN, ospid: 7581
OSD pid info: Unix process pid: 7581, image: oracle@seconary (TNS V1-V3)

D, 然后基于持LATCH的进程信息，查找PROCESS 持LATCH进程，再去分析持LATCH的进程
E，每个进程也包括对应会话近期的历史等待事件列表，而非当前的等待事件，字样为session wait history

Session Wait History: --表明已经发生的等待事件的历史列表
elapsed time of 0.000010 sec since current wait
0: waited for 'SQL*Net message to client'
driver id=0x62657100, #bytes=0x1, =0x0
wait_id=164 seq_num=165 snap_id=1
wait times: snap=0.000005 sec, exc=0.000005 sec, total=0.000005 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000038 sec of elapsed time
1: waited for 'log file sync'
buffer#=0x21bb, sync scn=0x3eab9ed, =0x0
wait_id=163 seq_num=164 snap_id=1
wait times: snap=0.000155 sec, exc=0.000155 sec, total=0.000155 sec
wait times: max=infinite
wait counts: calls=1 os=1
occurred after 0.453650 sec of elapsed time
2: waited for 'latch: shared pool' --看到没，这就是上述用ORADEBUG POKE模拟的LATCH:SHARE POOL等待事件
address=0x601038c8, number=0x125, tries=0x0
wait_id=162 seq_num=163 snap_id=1
wait times: snap=20 min 1 sec, exc=20 min 1 sec, total=20 min 1 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000183 sec of elapsed time

3,1号进程为pseudo,它是一个特殊的进程，用于启动ORACLE数据库，将于下文继续分析此进程的含义
4,1号进程不是ORACLE后台进程，但也没有对应会话信息
5,1号进程状态好像一直就是DEAD,即不活跃
6，对1号进程的几种分析思路：
1，查询V$SESSION
2, 查询V$PROCESS
3，V$BGPROCESS
4，ORADEBUG分析
5，SYSTEMSTATE DUMP分析
6，BAIDU

测试

先声明一点，在下面的测试中无关的内容略去不略。

会话1
SQL> select pid,spid from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum=1));

PID SPID
---------- ------------------------------------------------
31 7675

SQL> select sid from v$mystat where rownum=1;

SID
----------
40

会话2
SQL> select pid,spid from v$process where addr=(select paddr from v$session where sid=(select sid from v$mystat where rownum=1));

PID SPID
---------- ------------------------------------------------
30 7581

SQL> select sid from v$mystat where rownum=1;

SID
----------
38

会话1
SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x0000000060103C88 4 0x00000001;
BEFORE: [060103C88, 060103C8C) = 00000000
AFTER: [060103C88, 060103C8C) = 00000001
SQL> oradebug poke 0x0000000060103BE8 4 0x00000001;
BEFORE: [060103BE8, 060103BEC) = 00000000
AFTER: [060103BE8, 060103BEC) = 00000001
oradebug poke 0x0000000060103AA8 4 0x00000001;
oradebug poke 0x0000000060103B48 4 0x00000001;
BEFORE: [060103B48, 060103B4C) = 00000000
AFTER: [060103B48, 060103B4C) = 00000001
SQL> oradebug poke 0x0000000060103AA8 4 0x00000001;
BEFORE: [060103AA8, 060103AAC) = 00000000
AFTER: [060103AA8, 060103AAC) = 00000001
SQL> oradebug poke 0x0000000060103A08 4 0x00000001;
BEFORE: [060103A08, 060103A0C) = 00000000
AFTER: [060103A08, 060103A0C) = 00000001
SQL> oradebug poke 0x0000000060103968 4 0x00000001;
BEFORE: [060103968, 06010396C) = 00000000
AFTER: [060103968, 06010396C) = 00000001
SQL> oradebug poke 0x00000000601038C8 4 0x00000001;
BEFORE: [0601038C8, 0601038CC) = 00000000
AFTER: [0601038C8, 0601038CC) = 00000001

会话2
SQL> create table t_test_only_latch(a int);

hang住

会话1
---手工生成一个systemstate dump文件
SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug dump systemstate 10
Statement processed.
SQL> oradebug tracefile_name
/oracle/diag/rdbms/guowang/guowang/trace/guowang_ora_7675.trc

分析生成的systemstate dump文件

--过滤process 30(注：30为等待shared pool latch的会话的pid)
PROCESS 30:
----------------------------------------
SO: 0xdd5bc340, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bc340, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:30, ser:6, calls cur/top: 0xdcd53638/0xdcd53638
flags : (0x0) -
flags2: (0x0), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 134 0 2
last post received-location: ksl2.h LINE:2165 ID:kslpsr
last process to post me: dd5a8e80 1 6
last post sent: 0 0 26
last post sent-location: ksa2.h LINE:282 ID:ksasnd
last process posted by me: dd5a8e80 1 6
(latch info) wait_event=0 bits=0
Location from where call was made: kgh.h LINE:6334 ID:kghalo:
waiting for 601038c8 Child shared pool level=7 child#=1 ---waiting for可见这个进程30正在等待shared pool latch的子latch ,latch#为1，而且601038c8为等待的latch地址，对应v$latch的addr
Location from where latch is held: kgh.h LINE:6354 ID:kghfre: Chunk Header
Context saved from call: 3739691352
state=busy [holder orapid=1] wlstate=free [value=0] --holder可以发现持LATCH的信息，表明1号ORACLE进程占有了上述的LATCH
waiters [orapid (seconds since: put on list, posted, alive check)]:
27 (95, 1446364071, 95)
15 (92, 1446364071, 92)
30 (72, 1446364071, 72)
60 (71, 1446364071, 71)
waiter count=4
gotten 3610857 times wait, failed first 3931 sleeps 4121
gotten 0 times nowait, failed: 0
possible holder pid = 1 ospid=
on wait list for 601038c8
Process Group: DEFAULT, pseudo proc: 0xdd9a34d0
O/S info: user: oracle, term: UNKNOWN, ospid: 7581
OSD pid info: Unix process pid: 7581, image: oracle@seconary (TNS V1-V3)

--沿着上述思路，我们过滤process 1，所以说进程30等待1号进程，而1号进程因某种元素死了，所以
PROCESS 1:
----------------------------------------
SO: 0xdd59ec00, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd59ec00, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:1, ser:0, calls cur/top: (nil)/(nil)
flags : (0x20) PSEUDO --可见1号进程为PSEUDO进程
flags2: (0x0), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 0
last post sent-location: No post
last process posted by me: none
(latch info) wait_event=0 bits=0
O/S info: user: , term: , ospid: (DEAD) --1号进程死了
OSD pid info: Unix process pid: 0, image: PSEUDO

再看下31号进程，它是正常的，没有看到持LATCH及等待LATCH的任何信息，所以在我之前的文章，查询V$LATCHHOLDER是看不到信息，这就是原因所在
PROCESS 31:
----------------------------------------
SO: 0xdd5bd380, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bd380, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:31, ser:1, calls cur/top: (nil)/0xdcd52ac0
flags : (0x0) -
flags2: (0x1000), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 0
last post sent-location: No post
last process posted by me: none
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 0xdd9a34d0
O/S info: user: oracle, term: UNKNOWN, ospid: 7675
OSD pid info: Unix process pid: 7675, image: oracle@seconary (TNS V1-V3)

这就引出一个问题，1号进程PSEUDO是个什么进程，含义是什么，起什么作用？

会话1
我们先暂搁下这个问题，释放shared pool latch

SQL> oradebug setmypid
Statement processed.
SQL> oradebug poke 0x0000000060103C88 4 0x00000000;
BEFORE: [060103C88, 060103C8C) = 00000001
AFTER: [060103C88, 060103C8C) = 00000000
SQL> oradebug poke 0x0000000060103BE8 4 0x00000000;
BEFORE: [060103BE8, 060103BEC) = 00000001
AFTER: [060103BE8, 060103BEC) = 00000000
SQL> oradebug poke 0x0000000060103B48 4 0x00000000;
BEFORE: [060103B48, 060103B4C) = 00000001
AFTER: [060103B48, 060103B4C) = 00000000
oradebug poke 0x0000000060103AA8 4 0x00000000;
BEFORE: [060103AA8, 060103AAC) = 00000001
AFTER: [060103AA8, 060103AAC) = 00000000
SQL> oradebug poke 0x0000000060103A08 4 0x00000000;
BEFORE: [060103A08, 060103A0C) = 00000001
AFTER: [060103A08, 060103A0C) = 00000000
SQL> oradebug poke 0x0000000060103968 4 0x00000000;
BEFORE: [060103968, 06010396C) = 00000001
AFTER: [060103968, 06010396C) = 00000000
SQL> oradebug poke 0x00000000601038C8 4 0x00000000;
BEFORE: [0601038C8, 0601038CC) = 00000001
AFTER: [0601038C8, 0601038CC) = 00000000

会话2
SQL> create table t_test_only_latch(a int);

Table created.

刚才HANG住的建表创建表成功

再次手工SYSTEMSTATE DUMP
会话1
---手工生成一个systemstate dump文件
SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug dump systemstate 10
Statement processed.
SQL> oradebug tracefile_name
/oracle/diag/rdbms/guowang/guowang/trace/guowang_ora_7675.trc

再次分析SYSTEMSTATE DUMP文件

可见30号进程当前没有等待什么资源或LATCH
PROCESS 30:
----------------------------------------
SO: 0xdd5bc340, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bc340, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:30, ser:6, calls cur/top: (nil)/0xdcd53638
flags : (0x0) -
flags2: (0x0), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 134 0 2
last post received-location: ksl2.h LINE:2165 ID:kslpsr
last process to post me: dd5a8e80 1 6
last post sent: 0 0 26
last post sent-location: ksa2.h LINE:282 ID:ksasnd
last process posted by me: dd5a8e80 1 6
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 0xdd9a34d0
O/S info: user: oracle, term: UNKNOWN, ospid: 7581
OSD pid info: Unix process pid: 7581, image: oracle@seconary (TNS V1-V3)
Dump of memory from 0x00000000DD522970 to 0x00000000DD522B78
0DD522970 00000000 00000000 00000000 00000000 [................]
Repeat 31 times
0DD522B70 00000000 00000000 [........]
(FOB) flags=2050 fib=0xd8f365d0 incno=0 pending i/o cnt=0
fname=/oracle/oradata/guowang/tbs_undo_nb.dbf
fno=7 lblksz=8192 fsiz=6560
(FOB) flags=2050 fib=0xd8f34188 incno=0 pending i/o cnt=0
fname=/oracle/oradata/guowang/system01.dbf
fno=1 lblksz=8192 fsiz=136960
----------------------------------------
SO: 0xdcb58300, type: 4, owner: 0xdd5bc340, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bc340, name=session, file=ksu.h LINE:11467, pg=0
(session) sid: 38 ser: 13 trans: (nil), creator: 0xdd5bc340
flags: (0x41) USR/- flags_idl: (0x0) -/-/-/-/-/-
flags2: (0x40008) -/-
DID: , short-term DID:
txn branch: (nil)
oct: 1, prv: 0, sql: 0xde0d9e58, psql: 0xde0d9e58, user: 0/SYS
ksuxds FALSE at location: 0
service name: SYS$USERS
client details:
O/S info: user: oracle, term: pts/1, ospid: 7580
machine: seconary program: sqlplus@seconary (TNS V1-V3)
application name: sqlplus@seconary (TNS V1-V3), hash value=3800523690
Current Wait Stack:
0: waiting for 'SQL*Net message from client'
driver id=0x62657100, #bytes=0x1, =0x0
wait_id=165 seq_num=166 snap_id=1
wait times: snap=1 min 39 sec, exc=1 min 39 sec, total=1 min 39 sec
wait times: max=infinite, heur=1 min 39 sec
wait counts: calls=0 os=0
in_wait=1 iflags=0x1a0
Wait State:
fixed_waits=0 flags=0x22 boundary=(nil)/-1
Session Wait History: --表明已经发生的等待事件的历史列表
elapsed time of 0.000010 sec since current wait
0: waited for 'SQL*Net message to client'
driver id=0x62657100, #bytes=0x1, =0x0
wait_id=164 seq_num=165 snap_id=1
wait times: snap=0.000005 sec, exc=0.000005 sec, total=0.000005 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000038 sec of elapsed time
1: waited for 'log file sync'
buffer#=0x21bb, sync scn=0x3eab9ed, =0x0
wait_id=163 seq_num=164 snap_id=1
wait times: snap=0.000155 sec, exc=0.000155 sec, total=0.000155 sec
wait times: max=infinite
wait counts: calls=1 os=1
occurred after 0.453650 sec of elapsed time
2: waited for 'latch: shared pool' --看到没，这就是上述用ORADEBUG POKE模拟的LATCH:SHARE POOL等待事件
address=0x601038c8, number=0x125, tries=0x0
wait_id=162 seq_num=163 snap_id=1
wait times: snap=20 min 1 sec, exc=20 min 1 sec, total=20 min 1 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000183 sec of elapsed time

进程1
PROCESS 1:
----------------------------------------
SO: 0xdd59ec00, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd59ec00, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:1, ser:0, calls cur/top: (nil)/(nil)
flags : (0x20) PSEUDO
flags2: (0x0), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 0
last post sent-location: No post
last process posted by me: none
(latch info) wait_event=0 bits=0
O/S info: user: , term: , ospid: (DEAD) --发现其进程还是死的，所以说我前面说的结论并不正确，不能说因为进程1死了，就是引起进程30等待SHARED POOL LATCH的原因
OSD pid info: Unix process pid: 0, image: PSEUDO
Dump of memory from 0x00000000DD51EE88 to 0x00000000DD51F090
0DD51EE80 00000000 00000000 [........]
0DD51EE90 00000000 00000000 00000000 00000000 [................]
Repeat 31 times
----------------------------------------
SO: 0x6000c478, type: 5, owner: 0xdd59ec00, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=(nil), name=kss parent, file=kss2.h LINE:125, pg=0
----------------------------------------
SO: 0xd492f8e8, type: 83, owner: 0x6000c478, flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5af000, name=circuit holder, file=kmc.h LINE:2615, pg=0
(circuit holder) disp = 0xd492f860 (0, 1), proc = (0xdd5af000, 1)

再看下进程31
也是一切正常
PROCESS 31:
----------------------------------------
SO: 0xdd5bd380, type: 2, owner: (nil), flag: INIT/-/-/0x00 if: 0x3 c: 0x3
proc=0xdd5bd380, name=process, file=ksu.h LINE:11459, pg=0
(process) Oracle pid:31, ser:1, calls cur/top: (nil)/0xdcd52ac0
flags : (0x0) -
flags2: (0x1000), flags3: (0x0)
intr error: 0, call error: 0, sess error: 0, txn error 0
intr queue: empty
ksudlp FALSE at location: 0
(post info) last post received: 0 0 0
last post received-location: No post
last process to post me: none
last post sent: 0 0 0
last post sent-location: No post
last process posted by me: none
(latch info) wait_event=0 bits=0
Process Group: DEFAULT, pseudo proc: 0xdd9a34d0
O/S info: user: oracle, term: UNKNOWN, ospid: 7675
OSD pid info: Unix process pid: 7675, image: oracle@seconary (TNS V1-V3)

再回来头，我们分析下上述提出的问题，进程1到底是什么？

并且这个1号进程在操作系统层面没有对应的进程信息，只存在于ORACLE层面
SQL> select addr,pid,spid,pname,username,program,tracefile from v$process where pid=1;

ADDR PID SPID PNAME USERNAME PROGRAM TRACEFILE
---------------- ---------- ------------------------------------------------ ---------- --------------- -------------------- --------------------------------------------------
00000000DD59EC00 1 PSEUDO /oracle/diag/rdbms/guowang/guowang/trace/guowang_o
ra_0.trc

可见1号进程没有对应的会话，仅是一个后台进程
SQL> select sid,module from v$session where paddr='00000000DD59EC00';

no rows selected

我们查看下对应的TRACEFILE
可见没有生成这样的TRACEFILE
[oracle@seconary ~]$ ll -l /oracle/diag/rdbms/guowang/guowang/trace/guowang_ora_0*
ls: /oracle/diag/rdbms/guowang/guowang/trace/guowang_ora_0*: No such file or directory
[oracle@seconary ~]$

换个思路，我们重启下数据库，不进行任何操作，看还有这个1号进程吗
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 2137886720 bytes
Fixed Size 2215064 bytes
Variable Size 1409287016 bytes
Database Buffers 721420288 bytes
Redo Buffers 4964352 bytes
Database mounted.
Database opened.

可见只要数据库在运行着，就有这个1号进程
SQL> col spid for 999999
SQL> select addr,pid,spid,pname,username,program,tracefile from v$process where pid=1;

ADDR PID SPID PNAME USERNAME PROGRAM TRACEFILE
---------------- ---------- ------------------------------------------------ ---------- -------------------- --------------- --------------------------------------------------
00000000DD59EC00 1 PSEUDO /oracle/diag/rdbms/guowang/guowang/trace/guowang_o
ra_0.trc
继续换个思路分析，
SQL> select paddr,name,description,error from v$bgprocess where lower(name) like '%pmon%';

PADDR NAME DESCRIPTION ERROR
---------------- ---------- -------------------------------------------------- -----------
00000000DD59FC40 PMON process cleanup 0

可见1号进程不属于ORACLE后台进程，但又没有对应的会话信息，它是一个特殊的进程
SQL> select count(*) from v$bgprocess where paddr='00000000DD59EC00';

COUNT(*)
----------
0

继续换思路分析，用ORADEBUG SETORAPID分析，可见PSEUDO 1号进程当前不活跃
SQL> oradebug setorapid 1
ORA-00072: process "Unix process pid: 0, image: PSEUDO" is not active
SQL> oradebug tracefile_name
ORA-00074: no process has been specified

沿着上述思路，既然现在1号进程不活跃，哪何时它会活跃呢？尝试再新建一个会话

[oracle@seconary ~]$ sqlplus scott/system

SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 1 03:55:51 2015

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

可见新建会话还是不活跃
SQL> oradebug setorapid 1
ORA-00072: process "Unix process pid: 0, image: PSEUDO" is not active

尝试从监听新建一个会话
[oracle@seconary ~]$ sqlplus scott/system@guowang

SQL*Plus: Release 11.2.0.1.0 Production on Sun Nov 1 03:57:04 2015

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

可见用监听建立的会话还是不活跃
SQL> oradebug setorapid 1
ORA-00072: process "Unix process pid: 0, image: PSEUDO" is not active

后在BAIDU发现1号进程是用于启动ORACLE的初始化进程，也就是说用这个进程启动ORACLE数据库的
将在下文进行针对性分析。