背景

在上文 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資料庫的
將在下文進行針對性分析。

個人簡介：

8年oracle從業經驗，具備豐富的oracle技能，目前在國內北京某專業oracle服務公司從事高階技術顧問。

服務過的客戶：

中國電信

中國移動

中國聯通

中國電通

國家電網

四川達州商業銀行

湖南老百姓大藥房

山西省公安廳

中國郵政

北京302醫院

河北廊坊新奧集團公司

專案經驗:

中國電信3G專案AAA系統資料庫部署及最佳化

中國聯通CRM資料庫效能最佳化

中國移動10086電商平臺資料庫部署及最佳化

湖南老百姓大藥房ERR資料庫sql最佳化專案

四川達州商業銀行TCBS核心業務系統資料庫模型設計和RAC部署及最佳化

四川達州商業銀行TCBS核心業務系統後端批處理儲存過程功能模組編寫及最佳化

北京高鐵訊號監控系統RAC資料庫部署及最佳化

河南宇通客車資料庫效能最佳化

中國電信電商平臺核心採購模組表模型設計及最佳化

中國郵政儲蓄系統資料庫效能最佳化及sql最佳化

北京302醫院資料庫遷移實施

河北廊坊新奧data guard部署及最佳化

山西公安廳身份證審計資料庫系統故障評估

聯絡方式：

手機：18201115468

qq : 305076427

qq微博: wisdomone1

新浪微博：wisdomone9

qq群：275813900

itpub部落格名稱：wisdomone1 http://blog.itpub.net/9240380/

oracle 11g latch之v$latch和systemstate dump檔案之系列四

背景

結論

測試

個人簡介：

相關文章