MYSQL教程之完全弄分明library cache lock的成因和...
能够以较低的成本向客户提供IT所有权，当节约成本成为客户最高优先级时，解决方案提供商可以向更多的客户同时提供服务。虽然有许多来自RDBMS固有的局限性。cache|办理成绩形貌：
接到使用职员的呈报，说是在任何对表CSNOZ629926699966的操纵城市hang，包含descCSNOZ629926699966,
比方：
ora9i@cs_dc02:/ora9i>sqlpluspubuser/pubuser
SQL*Plus:Release9.2.0.4.0-ProductiononMonJan1010:11:062005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
SQL>connpubuser/pubuser
Connected.
SQL>descCSNOZ629926699966
。。。
这个历程hang了
。。。
扣问了一下之前有没有出格的操纵，营业职员说好久之前实行了剧本，可是该教本运转好久都没有了局，然后他就加入了会话，再以后，就呈现了下面的情形。剧本内容以下：
$catCSNOZ629926699966.sh
#!/bin/sh
sqlpluspubuser/pubuser@csmisc<<EOF#useyourusername/password
createtableCSNOZ629926699966asselect*fromCSNOZ62992266cs
wheremidnotin(selectmidfrompubuser.SUBSCRIPTION_BAK_200412@newdbwhereservid=020999011964andstatusin(A,B,S));
exit;
$
$
$
$
办理历程：
ora9i@cs_dc02:/ora9i>sqlplus"/assysdba"
SQL*Plus:Release9.2.0.4.0-ProductiononMonJan1010:19:132005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
SQL>select*fromv$lockwhereblock=1;
norowsselected
SQL>/
norowsselected
SQL>/
norowsselected
SQL>
我们看到今朝没有锁的信息
SQL>selectxidusn,object_id,session_id,locked_modefromv$locked_object;
。。。
XIDUSNOBJECT_IDSESSION_IDLOCKED_MODE
-----------------------------------------
1418373
。。。
SQL>/
。。。
XIDUSNOBJECT_IDSESSION_IDLOCKED_MODE
-----------------------------------------
1418373
。。。
SQL>/
。。。
XIDUSNOBJECT_IDSESSION_IDLOCKED_MODE
-----------------------------------------
1418373
。。。
SQL>
查找v$locked_object，我们发明了一个可疑的会话，SID37：
SQL>selectobject_name,owner,object_typefromdba_objectswhereobject_id=18;
。。。。。。
OBJECT_NAMEOWNEROBJECT_TYPE
------------------------------------------------------------------------------
OBJ$SYSTABLE
。。。。。。
SQL>
奇异怎样一向有这个锁？？
开端推测是因为SID为37的会话实行了下面的DDL语句，并在语句未完成前非常加入，
形成了一切会见谁人（DDL语句中触及到的）工具的历程都hang了。
接上去我们看看守候事务：
SQL>selectevent,sid,p1,p2,p3fromv$session_waitwhereeventnotlikeSQL*%andeventnotlikerdbms%;
EVENTP1P2SID
----------------------------------------------------------------------------------------------
pmontimer30001
gesremotemessage3204
gcsremotemessage6405
gcsremotemessage6407
smontimer300019
librarycachelock1.3835E+191.3835E+1930
wakeuptimemanager0022
7rowsselected.
SQL>/
EVENTP1P2SID
----------------------------------------------------------------------------------------------
pmontimer30001
gesremotemessage3204
gcsremotemessage6405
gcsremotemessage6407
smontimer300019
librarycachelock1.3835E+191.3835E+1930
wakeuptimemanager0022
7rowsselected.
SQL>/
EVENTP1P2SID
----------------------------------------------------------------------------------------------
pmontimer30001
gesremotemessage3204
gcsremotemessage6405
gcsremotemessage6407
smontimer300019
librarycachelock1.3835E+191.3835E+1930
wakeuptimemanager0022
7rowsselected.
SQL>/
EVENTP1P2SID
----------------------------------------------------------------------------------------------
pmontimer30001
gesremotemessage3204
gcsremotemessage6405
gcsremotemessage6407
smontimer300019
librarycachelock1.3835E+191.3835E+1930
wakeuptimemanager0022
7rowsselected.
SQL>
我们注重到上面的事务：
EVENTP1P2SID
----------------------------------------------------------------------------------------------
。。。
librarycachelock1.3835E+191.3835E+1930
。。。
P1是句柄地点(handleaddress),也就是librarycachelock产生的地点。
P2是一个形态工具，在这里，它暗示在工具上加载的锁的地点(lockaddress)。
P1和P2都是迷信计数宣布示的10进制数。
这些信息再次证明了下面的推测，SID37堵塞了SID30。
找出这两个可疑历程的sid和serial，然后对他们设置10046事务：
SQL>selectsid,serial#fromv$sessionwheresidin(30,37);
SIDSERIAL#
--------------------
3024167
372707
SQL>execdbms_system.set_ev(30,24167,10046,12,);
PL/SQLproceduresuccessfullycompleted.
SQL>execdbms_system.set_ev(37,2707,10046,12,);
PL/SQLproceduresuccessfullycompleted.
SQL>
跟踪时代我们再次测试一下，看看有无其他线索。
新开一个历程，找出其sid,serial和spid等信息：
ora9i@cs_dc01:/ora9i>sqlpluspubuser/pubuser
SQL*Plus:Release9.2.0.4.0-ProductiononMonJan1011:36:252005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
SQL>selectdistinctsidfromv$mystat;
SID
----------
33
SQL>selectsid,serial#fromv$sessionwheresid=33;
SIDSERIAL#
--------------------
336639
SQL>SELECTSPID,PIDFROMV$PROCESSWHEREADDR=(SELECTPADDRFROMV$SESSIONWHERESID=37);
SPIDPID
----------------------
2055226
SQL>SELECTSPID,PIDFROMV$PROCESSWHEREADDR=(SELECTPADDRFROMV$SESSIONWHERESID=30);
SPIDPID
----------------------
2258028
SQL>showparameterdump
NAMETYPEVALUE
-----------------------------------------------------------------------------
background_core_dumpstringpartial
background_dump_deststring/ora9i/app/oracle/admin/csmisc
/bdump
core_dump_deststring/ora9i/app/oracle/admin/csmisc
/cdump
max_dump_file_sizestringUNLIMITED
shadow_core_dumpstringpartial
user_dump_deststring/ora9i/app/oracle/admin/csmisc
/udump
SQL>
然后，再实验对CSNOZ629926699966表举行操纵
SQL>descCSNOZ629926699966
。。。
仍是hang住了。
因而中止这个操纵（CTRL+C）：
SQL>descCSNOZ629926699966
ERROR:
ORA-01013:userrequestedcancelofcurrentoperation
SQL>selecttnamefromtabwheretname=CSNOZ629926699966;
norowsselected
SQL>
检察PUBUSER用户下的这个表，竟然不存在！！
进一步证明了后面的推测，也就是说会话37堵塞了其他一切操纵表CSNOZ629926699966的会话，形成了历程的hang，固然，包含下面的SID30和SID33的DDL语句
如今，我们停止10046的事务跟踪：
SQL>execdbms_system.set_ev(30,24167,0,0,);
PL/SQLproceduresuccessfullycompleted.
SQL>execdbms_system.set_ev(37,2707,0,0,);
PL/SQLproceduresuccessfullycompleted.
SQL>
依据下面纪录的信息，我们晓得这两个会话发生的跟踪信息分离为：
SID为30的会话，发生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_22580.trc
SID为37的会话，发生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_20552.trc
看看trace文件：
ora9i@cs_dc02:/ora9i>cd/ora9i/app/oracle/admin/csmisc/udump
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>ll-tlc
total4432
-rw-r-----1ora9idba332995Jan1012:00csmisc2_ora_22580.trc
-rw-r-----1ora9idba3168Jan1011:59csmisc2_ora_20552.trc
-rw-r-----1ora9idba407133Jan715:10csmisc2_ora_2708.trc
-rw-r-----1ora9idba640Jan714:48csmisc2_ora_835.trc
-rw-r-----1ora9idba1590Dec3022:50csmisc2_ora_16244.trc
-rw-r-----1ora9idba1308403Dec3022:44csmisc2_ora_16033.trc
-rw-r-----1ora9idba616Dec2814:16csmisc2_ora_2176.trc
-rw-r-----1ora9idba644Dec818:22csmisc2_ora_21083.trc
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>mailx-s"csmisc2_ora_22580.trc"zhangdp@aspire-tech.com<csmisc2_ora_22580.trc
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>mailx-s"csmisc2_ora_20552.trc"zhangdp@aspire-tech.com<csmisc2_ora_20552.trc
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>exit
SQL>
我们看到SID为30的会话，发生的跟踪文件（csmisc2_ora_22580.trc）为的次要内容是：
/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_22580.trc
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
ORACLE_HOME=/ora9i/app/oracle/product/920
Systemname:HP-UX
Nodename:cs_dc02
Release:B.11.11
Version:U
Machine:9000/800
Instancename:csmisc2
Redothreadmountedbythisinstance:2
Oracleprocessnumber:28
Unixprocesspid:22580,image:oracle@cs_dc02(TNSV1-V3)
***2005-01-1011:31:49.416
***SESSIONID:(30.24167)2005-01-1011:31:49.354
WAIT#0:nam=librarycachelockela=507258p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=505686p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507678p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507595p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507880p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507317p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507703p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507683p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=508265p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507100p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507684p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=505889p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507731p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507650p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507604p1=-4611686013547141416p2=-4611686013691716064p3=1301
WAIT#0:nam=librarycachelockela=507698p1=-4611686013547141416p2=-4611686013691716064p3=1301
。。。。。。
我们看到SID30的跟踪文件中的守候事务就是在V$SESSION_WAIT中看到的librarycachelock.
再看看SID为37的会话，发生的跟踪文件（csmisc2_ora_20552.trc）为的次要内容是：
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
ORACLE_HOME=/ora9i/app/oracle/product/920
Systemname:HP-UX
Nodename:cs_dc02
Release:B.11.11
Version:U
Machine:9000/800
Instancename:csmisc2
Redothreadmountedbythisinstance:2
Oracleprocessnumber:26
Unixprocesspid:20552,image:oracle@cs_dc02(TNSV1-V3)
***2005-01-1011:33:22.702
***SESSIONID:(37.2707)2005-01-1011:33:22.690
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
***2005-01-1011:35:07.452
WAIT#1:nam=SQL*Netmessagefromdblinkela=102293555p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=3p1=675562835p2=1p3=0
***2005-01-1011:36:55.980
WAIT#1:nam=SQL*Netmessagefromdblinkela=105969709p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
***2005-01-1011:39:05.416
WAIT#1:nam=SQL*Netmessagefromdblinkela=126390826p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
***2005-01-1011:41:12.878
WAIT#1:nam=SQL*Netmessagefromdblinkela=124461520p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
***2005-01-1011:43:01.285
WAIT#1:nam=SQL*Netmessagefromdblinkela=105859385p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
***2005-01-1011:44:48.200
WAIT#1:nam=SQL*Netmessagefromdblinkela=104397696p1=675562835p2=1p3=0
WAIT#1:nam=SQL*Netmessagetodblinkela=4p1=675562835p2=1p3=0
。。。。。。
如今我们来dump体系形态(systemstate)，看看更具体的信息。
起首复杂的先容一下eventsystemstate。
良多人把systemstate事务了解为dump产生的那一刻的体系内一切历程的信息，这是个毛病的观点，现实上，
转储systemstate发生的跟踪文件是从dump那一刻入手下手到dump义务完成之间一段事务内的体系内一切历程的信息。
dumpsystemstate发生的跟踪文件包括了体系中一切历程的历程形态等信息。每一个历程对应跟踪文件中的一段内容，反应该历程的形态信息，包含历程信息，会话信息，enqueues信息（次要是lock的信息），缓冲区的信息和该历程在SGA区中持有的（held）工具的形态等信息。
那末一般在甚么情形下利用systemstate对照符合呢？
Oracle保举的利用systemstate事务的几种情形是：
数据库hang住了数据库很慢历程正在hang数据库呈现某些毛病资本争用
dumpsystemstate的语法为：
ALTERSESSIONSETEVENTSimmediatetracenamesystemstatelevel10;
也能够利用ORADEBUG完成这个功效
ORADEBUGDUMPSYSTEMSTATElevel10
假如但愿在数据库产生某种毛病时除非systemstate事务，能够在参数文件（spfile大概pfile）中设置event参数，
比方，当体系产生逝世锁（呈现ORA-00060毛病）时dumpsystemstate：
event="60tracenamesystemstatelevel10"
言回正传，我们dump体系形态：
SQL>ALTERSESSIONSETEVENTSIMMEDIATETRACENAMESYSTEMSTATELEVEL8;
Sessionaltered.
SQL>host
ora9i@cs_dc02:/ora9i>cd/ora9i/app/oracle/admin/csmisc/udump
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>ll-ctl
-rw-r-----1ora9idba1070863Jan1013:02csmisc2_ora_22580.trc
-rw-r-----1ora9idba1345368Jan1013:01csmisc2_ora_22568.trc
-rwxrwxrwx1ora9idba44114Jan1012:52ass1015.awk
-rw-r-----1ora9idba407133Jan715:10csmisc2_ora_2708.trc
-rw-r-----1ora9idba640Jan714:48csmisc2_ora_835.trc
-rw-r-----1ora9idba1590Dec3022:50csmisc2_ora_16244.trc
-rw-r-----1ora9idba1308403Dec3022:44csmisc2_ora_16033.trc
-rw-r-----1ora9idba616Dec2814:16csmisc2_ora_2176.trc
-rw-r-----1ora9idba644Dec818:22csmisc2_ora_21083.trc
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>
ora9i@cs_dc02:/ora9i/app/oracle/admin/csmisc/udump>mailx-s"22568"zhangdp@aspire-tech.com<csmisc2_ora_22568.trc
这个跟踪文件很年夜（由于它包括了一切历程的信息），那末我们从那里入手下手看起呢？
起首，经由过程在跟踪文件中查找字符串"waitingforlibrarycachelock"，我们找到了被堵塞历程的信息：
PROCESS28:----------------被堵塞的Oracle历程，这里PROCESS28对应了V$PROCESS中的PID的值，
也就是说我们能够依据这一信息在V$PROCESS和V$SESSION找到被堵塞的会话的信息
----------------------------------------
SO:c000000109c83bf0,type:2,owner:0000000000000000,flag:INIT/-/-/0x00
(process)Oraclepid=28,callscur/top:c00000010b277890/c00000010b277890,flag:(0)-
interror:0,callerror:0,sesserror:0,txnerror0
(postinfo)lastpostreceived:17246
lastpostreceived-location:ksusig
lastprocesstopostme:c000000109c840f8250
lastpostsent:0015
lastpostsent-location:ksasnd
lastprocesspostedbyme:c000000109c7ff9016
(latchinfo)wait_event=0bits=0
ProcessGroup:DEFAULT,pseudoproc:c000000109eefda0
O/Sinfo:user:ora9i,term:pts/th,ospid:22580----------------该历程的操纵体系历程号，对应于V$PROCESS中的SPID
OSDpidinfo:Unixprocesspid:22580,image:oracle@cs_dc02(TNSV1-V3)
----------------------------------------
SO:c000000109f02c68,type:4,owner:c000000109c83bf0,flag:INIT/-/-/0x00
(session)trans:0000000000000000,creator:c000000109c83bf0,flag:(100041)USR/-BSY/-/-/-/-/-
DID:0002-001C-00000192,short-termDID:0000-0000-00000000
txnbranch:0000000000000000
oct:0,prv:0,sql:c00000011f8ea068,psql:c00000011f8ea068,user:50/PUBUSER
O/Sinfo:user:ora9i,term:,ospid:22536,machine:cs_dc02
program:sqlplus@cs_dc02(TNSV1-V3)
applicationname:SQL*Plus,hashvalue=3669949024
waitingforlibrarycachelockblockingsess=0x0seq=18589wait_time=0
handleaddress=c000000122e2a6d8,lockaddress=c00000011a449e20,100*mode+namespace=515
。。。。。。
SO:c00000010b277890,type:3,owner:c000000109c83bf0,flag:INIT/-/-/0x00
(call)sess:curc000000109f02c68,rec0,usrc000000109f02c68;depth:0
----------------------------------------
SO:c00000011a449e20,type:51,owner:c00000010b277890,flag:INIT/-/-/0x00
LIBRARYOBJECTLOCK:lock=c00000011a449e20handle=c000000122e2a6d8request=S
callpin=0000000000000000sessionpin=0000000000000000
htl=c00000011a449e90htb=c00000011a4bc350
user=c000000109f02c68session=c000000109f02c68count=0flags=savepoint=463
therestoftheobjectwasalreadydumped
。。。。。。
请注重上面的信息：
waitingforlibrarycachelockblockingsess=0x0seq=18589wait_time=0
handleaddress=c000000122e2a6d8,lockaddress=c00000011a449e20,100*mode+namespace=515
这段信息告知我们ORACLEPID为28的历程(PROCESS28)，正在守候librarycachelock，经由过程‘handleaddress=c000000122e2a6d8’我们能够找到堵塞它的会话的ORACLEPID信息。
还要注重这段信息：
LIBRARYOBJECTLOCK:lock=c00000011a449e20handle=c000000122e2a6d8request=S
callpin=0000000000000000sessionpin=0000000000000000
htl=c00000011a449e90htb=c00000011a4bc350
user=c000000109f02c68session=c000000109f02c68count=0flags=savepoint=463
这里就是堵塞PROCESS28历程的会话的信息。
复杂的记着这个根据的要点是：
waitingsession的handleaddress的值对应于blockingsession的handle的值。
回过火来，看看这个值，它应于下面我们在V$SESSION_WAIT中看到的P1和P2的值：
SQL>selectto_number(C000000122E2A6D8,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)fromdual;
TO_NUMBER(C000000122E2A6D8,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX)
----------------------------------------------------------------
1.3835E+19
SQL>
成绩的成因已基础上明白了，这里保举两种办理成绩的办法：
办法1，依据c000000122e2a6d8地点，我们能够失掉以后在librarycache中响应的锁信息：
SQL>l
1selectINST_ID,USER_NAME,KGLNAOBJ,KGLLKSNM,KGLLKUSE,KGLLKSES,KGLLKMOD,KGLLKREQ,KGLLKPNS,KGLLKHDL
2*fromX$KGLLKwhereKGLLKHDL=C000000122E2A6D8orderbyKGLLKSNM,KGLNAOBJ
SQL>/
INST_IDUSER_NAMEKGLNAOBJKGLLKSNMKGLLKUSEKGLLKSESKGLLKMODKGLLKREQKGLLKPNSKGLLKHDL
-------------------------------------------------------------------------------------------------------------------------------------------
2PUBUSERCSNOZ62992669996630C000000109F02C68C000000109F02C680200C000000122E2A6D8
2PUBUSERCSNOZ62992669996637C000000108C99E28C000000108C99E283000C000000122E2A6D8
SQL>
依照Oracle保举的做法，我们如今应当利用altersystemkillsession命令kill失落SID37，
了局失掉了ORA-00031毛病：
SQL>altersystemkillsession37,2707;
altersystemkillsession37,2707
*
ERRORatline1:
ORA-00031:sessionmarkedforkill
SQL>
反省SID37的形态：
SQL>setlinesize150
SQL>colprogramfora50
SQL>selectsid,serial#,status,username,programfromv$sessionwheresid=37;
SIDSERIAL#STATUSUSERNAMEPROGRAM
------------------------------------------------------------------------------------------------------------
372707KILLEDPUBUSERsqlplus@cs_dc02(TNSV1-V3)
SQL>
再次证明了我们最后的设法——有人在实行了某个必要运转好久的DDL（多半是语句效力低，固然不扫除遭受bug的大概），
然后没等语句停止就非常加入了会话。
这个例子中我们在下面的跟踪文件已找到了该会话对应的操纵体系历程(SPID)，假如在其他情形下，我们怎样找到这类形态为KILLED
的操纵体系历程号（SPID）呢？
上面给出了一个办法，能够自创：
SQL>l
1SELECTs.username,s.status,
2x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
3decode(bitand(x.ksuprflg,2),0,null,1)
4FROMx$ksuprx,v$sessions
5WHEREs.paddr(+)=x.addr
6andbitand(ksspaflg,1)!=0
7*ands.sid=37
SQL>/
USERNAMESTATUSADDRKSLLAPSCKSLLAPSNKSLLASPOKSLLID1RKSD
---------------------------------------------------------------------------------------------------
PUBUSERKILLEDC000000109C831E041151624317
SQL>
x$ksupr.ADDR列的值对应了V$PROCESS中的ADDR的值，晓得了这个SPID的地点，找到这个操纵体系历程(SPID)就复杂了，比方：
SQL>selectspid,pidfromv$processwhereaddr=C000000109C831E0;
SPIDPID
----------------------
2055226
SQL>
如今，我们只必要在操纵体系上kill操纵体系历程20552就能够了：
ora9i@cs_dc02:/ora9i>ps-ef|grep20552
ora9i2055210Jan8?0:01oraclecsmisc2(LOCAL=NO)
ora9i1474214740017:19:02pts/ti0:00grep20552
ora9i@cs_dc02:/ora9i>kill-920552
ora9i@cs_dc02:/ora9i>ps-ef|grep20552
ora9i1496614964017:40:01pts/ti0:00grep20552
ora9i@cs_dc02:/ora9i>
再来反省一下SID37的信息，我们看到这个会话是真的被kill失落了，
ora9i@cs_dc02:/ora9i>exit
SQL>selectsid,serial#,status,username,programfromv$sessionwheresid=37;
norowsselected
SQL>l
1SELECTs.username,s.status,
2x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
3decode(bitand(x.ksuprflg,2),0,null,1)
4FROMx$ksuprx,v$sessions
5WHEREs.paddr(+)=x.addr
6andbitand(ksspaflg,1)!=0
7*ands.sid=37
SQL>/
norowsselected
SQL>
回到方才hang住的会话，它已恢复了一般操纵，
而且我们已失掉了ORA-04043:objectCSNOZ629926699966doesnotexist这个一般的信息：
SQL>descCSNOZ629926699966
ERROR:
ORA-04043:objectCSNOZ629926699966doesnotexist
SQL>
在开一个会话，测试一把:
ora9i@cs_dc02:/ora9i>sqlpluspubuser/pubuser
SQL*Plus:Release9.2.0.4.0-ProductiononMonJan1017:42:162005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.4.0-64bitProduction
WiththePartitioningandRealApplicationClustersoptions
JServerRelease9.2.0.4.0-Production
SQL>settimingon
SQL>descCSNOZ629926699966
ERROR:
ORA-04043:objectCSNOZ629926699966doesnotexist
SQL>
当收回命令descCSNOZ629926699966的时分，我们看到体系立即前往了ORA-04043:objectCSNOZ629926699966doesnotexist信息，成绩就此办理了。
这里，复杂的先容一下X$KGLLK，这个基表保留了库缓存中工具的锁的信息，它关于办理这类成绩出格有效，其称号的寄义以下：
ernelLayer
enericLayer
ibraryCacheManager(definedandmappedfromkqlf)
ObjectLocks
X$KGLLK-Objectocs
KGLNAOBJ列包括了在librarkycache中的工具上实行命令的语句的前80个字符（实在从这里我们也能够年夜年夜减少局限了）
X$KGLLK.KGLLKUSE和x$kgllk.KGLLKSES对应于跟踪文件中的owner的值
X$KGLLK.KGLLKADR
X$KGLLK.KGLLKHDL对应于跟踪文件中的handle的值(handle=C000000122E2A6D8)，也就是librarycachelock的地点
X$KGLLK.KGLLKPNS对应于跟踪文件中的sessionpin的值
X$KGLLK.KGLLKSPN对应于跟踪文件中的savepoint的值
我们再来看一下更周全的信息：
SQL>setlinesize2000
SQL>select*fromX$KGLLKwhereKGLLKHDL=C000000122E2A6D8orderbyKGLLKSNM,KGLNAOBJ
2/
ADDRINDXINST_IDKGLLKADRKGLLKUSEKGLLKSESKGLLKSNMKGLLKHDLKGLLKPNCKGLLKPNSKGLLKCNTKGLLKMODKGLLKREQKGLLKFLGKGLLKSPNKGLLKHTBKGLNAHSHKGLHDPARKGLHDNSPUSER_NAMEKGLNAOBJ
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
800003FB0007E4D0332C00000011A449E20C000000109F02C68C000000109F02C6830C000000122E2A6D800000020463C00000011A4BC3503990848181C000000122E2A6D81PUBUSERCSNOZ629926699966
800003FB0007E5B0342C00000011A44A150C000000108C99E28C000000108C99E2837C000000122E2A6D800001300179C00000011A4BB3283990848181C000000122E2A6D81PUBUSERCSNOZ629926699966
SQL>setlinesize100
SQL>l
1*select*fromX$KGLLKwhereKGLLKHDL=C000000122E2A6D8orderbyKGLLKSNM,KGLNAOBJ
SQL>/
ADDRINDXINST_IDKGLLKADRKGLLKUSEKGLLKSESKGLLKSNM
----------------------------------------------------------------------------------------------
KGLLKHDLKGLLKPNCKGLLKPNSKGLLKCNTKGLLKMODKGLLKREQKGLLKFLG
----------------------------------------------------------------------------------------
KGLLKSPNKGLLKHTBKGLNAHSHKGLHDPARKGLHDNSPUSER_NAME
--------------------------------------------------------------------------------------------
KGLNAOBJ
------------------------------------------------------------
800003FB0007E4D0332C00000011A449E20C000000109F02C68C000000109F02C6830
C000000122E2A6D800000020
463C00000011A4BC3503990848181C000000122E2A6D81PUBUSER
CSNOZ629926699966
800003FB0007E5B0342C00000011A44A150C000000108C99E28C000000108C99E2837
C000000122E2A6D800001300
179C00000011A4BB3283990848181C000000122E2A6D81PUBUSER
CSNOZ629926699966
SQL>
————待续————
DBaaS系统其实具有更大的市场机遇：像其他云服务一样，DBaaS意味着更短的销售周期，更少的启动费用，持续不断的收入，也意味着比之前更多的客户。 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。 再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SETNULL和SETDEFAULT属性，能够提供能好的级联设置。 现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层. SP4包括用于以下SQLServer2000组件的程序包：Database组件（下载文件：SQL2000-KB884525-SP4-x86.EXE）更新SQLServer2000的32位Database组件，包括数据库引擎、复制、客户端连接组件及工具。有关其他信息，请参阅ReadmeSql2k32Sp4.htm。AnalysisServices组件（下载文件：SQL2000.AS-KB884525-SP4-x86.EXE）更新SQLServer2000的32位AnalysisServices。 索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。 是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。 代替了原来VB式的错误判断。比Oracle高级不少。
页:
[1]