AskDBA.net

ACOUG Member – 〇〇

Thu, 01 Jan 1970 06:00:00 +0700

卢涛，网名〇〇

ITpub.net Oracle 开发版版主
《剑破冰山——Oracle开发艺术》联合作者

15年IT工作经验，在某数据管理中心任职系统分析师；曾参与数次全国性数据处理系统的设计与实现。在软件开发、数据库开发和优化、系统架构方面有一定研究。
个人主页：http://blog.csdn.net/l1t
微博：http://weibo.com/lu01

library cache lock和library cache pin到底是什么

Thu, 01 Jan 1970 06:00:00 +0700

可能有很多朋友从来就没有搞清楚过到底什么是library cache lock和library cache pin，它们到底是enqueue还是latch？它们的作用是什么？

这里我尝试对上述问题做一番解释，这些解释可能是有问题的，因为里面包含了我的一些猜测。

最近连续写了一些基于我的猜测、没有确凿证据的文章，这也许不太合适。

我们通常说的library cache lock和library cache pin是enqueue，不是latch，它们是两种DDL lock。但需要我们注意的是，在11gR1之前，Oracle中又存在名为library cache lock和library cache pin的latch。

是不是感觉很混乱？没关系，我们一点一点往下看。很抱歉，我这里引用了大量英文，因为我觉得如果翻译出来就失去了原先的味道。

1、作为enqueue，library cache lock和library cache pin的作用是什么？

Both library cache lock and library cache pin are provided to access objects in the library cache. Library cache lock manages concurrency between processes, whereas library cache pin manages cache coherence. In order to access an object in library cache, a process must first lock the library cache object handle, and then pin the object data heap itself. Requests for both library cache lock and library cache pin will wait until granted. This is a possible source of contention, because there is no NOWAIT request mode.

By acquiring a library cache lock on the library cache object handle, a process can prevent other processes from accessing the object, or even finding out what type it is. It can even maintain a dependency on an object without preventing other processes from accessing the object. Acquiring a library cache lock is also the only way to locate an object in cache--a process locates and locks an object in a single operation.

If the process wants to actually examine or modify the object, then it must acquire a library cache pin on the object data heap itself (after acquiring a library cache lock on the library cache object handle). Pinning the object causes information about the object and its data heaps to be loaded into memory if they were not already there. This information is guaranteed to remain in memory at least until the pin is released. Locks and pins are externalized in X$KGLLK and X$KGLPN, respectively.

2、作为enqueue，library cache lock和library cache pin有哪几种lock mode？

a) Library cache lock有三种lock mode，分别是share、exclusive和null。A process acquires a share library cache lock if it intends only to read the object. For example, it wants to reference the object during compilation. A process acquires an exclusive library cache lock if it intends to create or modify the object. For example, it wants to drop the object from the database. Null library cache locks are a special case. They are acquired on objects that are to be executed like child cursor, procedure, function, package, or type body. You can use them to maintain an interest on an object for a long period of time (session persistency), and to detect if the object becomes invalid. You can break null library cache lock at any time. This is used as a mechanism to notify a session that an executable object is no longer valid. If a null library cache lock is broken, and thus the object is invalidated, then it is an indication to the user who was holding the null library cache lock that the object needs to be recompiled. A null library cache lock is acquired during the parse phase of SQL statement execution and is held as long as the shared SQL area for that statement remains in the shared pool. A null library cache lock does not prevent any DDL operation, and can be broken to allow conflicting DDL operations, hence the term "breakable parse lock." A null library cache lock on an object is broken when there is an exclusive library cache pin on the object.

b) Library cache pin有两种lock mode，分别是share和exclusive。 When a process pins an object data heap that is not in memory, the process can determine whether the data heap is to be loaded in the PGA or SGA. An object must be pinned in Exclusive mode if it is to be modified. However, the process first will always pin the object in Share mode, examine it for errors and security checks, and then, if necessary, (such as needing modification) pin it in Exclusive mode. An object is never pinned in Exclusive mode if only read access is required. This is because all dependent transient objects (cursors) are invalidated (null locks broken) when an object is unpinned from Exclusive mode. The effect would be unnecessary recompilation and reparsing of all dependent packages, procedures, and functions.

3、作为latch，library cache lock和library cache pin的作用是什么？

这是一个很纠结的问题，既然已经有了作为enqueue的library cache lock和library cache pin，为什么在11gR1以前，Oracle里还有同名latch，而且明显这些同名latch是在被使用：

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.5.0

Connected as ipra

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

library cache 5 9221760 1608 800 2596 76766

library cache lock 6 13548247 582 6 0 0

library cache lock allocation 3 208273 0 0 0 0

library cache pin 6 4207462 193 0 2 0

library cache hash chains 9 0 0 0 0 0

library cache pin allocation 3 57276 0 0 0 0

library cache load lock 5 24848 0 0 1 0

7 rows selected

从结果里我们可以看到，对于10.2.0.5而言，Oracle存在7种跟library cache相关的latch，除了library cache hash chains latch之外，其他的跟library cache相关的latch，Oracle都有使用。

那么library cache lock latch、library cache pin latch以及大家最耳熟能详的library cache latch等等，这些latch是做什么用的呢？

也许我们可以从下面的一段文字中找到答案：

The library cache latches serialize access to the objects in the library cache. Access to library cache objects always occurs through library cache locks. Because locking an object is not an atomic instruction, a library cache latch is acquired before the library cache lock request and is released after it. For most operations, the library cache latches are used, and therefore they can become a point of contention.

If an object is not in memory, then a library cache lock cannot be acquired on it. In order to prevent multiple processes to request the load of the same object simultaneously, another latch must be acquired before the load request. This is the library cache load lock latch. The library cache load lock latch is taken and held until a library cache load lock is allocated, then the latch is released. Loading of the object is performed under the library cache load lock and not under the library cache load lock latch as it may take quite a long time.

这里提到了几点值得我们关注：

a) Oracle使用上述library cache latches（包括library cache latch、library cache lock latch、library cache pin latch、library cache pin allocation latch、library cache load lock latch）的目的是控制并发访问library cache object所需要的相关的enqueue或者是为了控制并发访问library cache中的相关的内存结构，比如用相关的library cache lock latch控制并发获得library cache lock。这里我猜测Oracle用library cache lock latch控制并发获得library cache lock，用library cache pin latch控制并发获得library cache pin，用library cache load lock latch控制并发获得library cache load lock，用library cache lock去控制并发访问library cache object handle中的某些结构，如library cache object handle中的flag中的special status flag （special status flags are protected by the library cache latch. Examples of these flags indicate that: The object is valid; The object is authorized; The object has compilation errors）。

b) Library cache load lock是另外一种enqueue。The session tries to find the library cache load lock for the database object so that it can load the object. The library cache load lock is always obtained in Exclusive mode, so that no other process can load the same object. If the library cache load lock is busy the session will wait on this event until the lock becomes available.

好了，现在我们来验证一下，还是上述10.2.0.5的环境，我将上述sql（select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch where name like 'library%'）马上再执行一遍，这是软解析，必然要获得library cache lock和library cache pin，不需要获得library cache load lock，所以对应的latch应该表现为library cache lock latch和library cache pin latch的gets增加，library cache load lock latch的gets不变：

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

library cache 5 9222166 1608 800 2596 76766

library cache lock 6 13548760 582 6 0 0

library cache lock allocation 3 208287 0 0 0 0

library cache pin 6 4207656 193 0 2 0

library cache hash chains 9 0 0 0 0 0

library cache pin allocation 3 57278 0 0 0 0

library cache load lock 5 24848 0 0 1 0

7 rows selected

从结果里我们可以看到，library cache lock latch的gets从13548247递增到了13548760，library cache pin latch的gets从4207462递增到了4207656，但library cache load lock latch的gets还是保持24848不变。

现在我们来让library cache load lock latch的gets发生变化，这是非常容易的事情，我们只需要执行一个需要硬解析的sql就可以了：

SQL> select * from scott.emp_temp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO ISINSPECT

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

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

library cache 5 9223549 1608 800 2596 76766

library cache lock 6 13550296 582 6 0 0

library cache lock allocation 3 208348 0 0 0 0

library cache pin 6 4208118 193 0 2 0

library cache hash chains 9 0 0 0 0 0

library cache pin allocation 3 57294 0 0 0 0

library cache load lock 5 24856 0 0 1 0

7 rows selected

由于我们执行了一个需要硬解析的sql，导致Oracle需要获得library cache load lock以便load相关信息到这个sql的子cursor的heap 6中，而要获得library cache load lock，必须先持有library cache load lock latch。从上述结果中我们可以看到，此时library cache load lock latch的gets已经发生了变化，从24848递增到了24856。

接下来我们再来看一看上述library cache latches的子latch情况：

SQL> show parameter cpu_count

NAME TYPE VALUE

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

cpu_count integer 2

这里cpu的个数为2，显然上述library cache latches的子latch应该为3：

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch_children where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

library cache 5 3274551 1301 94 187 0

library cache 5 2218356 116 80 933 0

library cache 5 3731320 191 626 1476 76766

library cache lock 6 5339737 362 3 0 0

library cache lock 6 6223353 194 3 0 0

library cache lock 6 1987799 26 0 0 0

library cache pin 6 1484918 184 0 0 0

library cache pin 6 891695 3 0 2 0

library cache pin 6 1831837 6 0 0 0

library cache pin allocation 3 23177 0 0 0 0

library cache pin allocation 3 8272 0 0 0 0

library cache pin allocation 3 25849 0 0 0 0

library cache lock allocation 3 75900 0 0 0 0

library cache lock allocation 3 28229 0 0 0 0

library cache lock allocation 3 104237 0 0 0 0

library cache hash chains 9 0 0 0 0 0

18 rows selected

注意，结果里并没有library cache load lock latch，说明library cache load lock latch没有children，它是一个solitary类型的latch。

从10.2.0.2开始，Oracle将_kks_use_mutex_pin的默认值改成了true，这意味着从10.2.0.2开始，Oracle里将再不会有针对cursor的library cache pin等待，取而代之的是mutex等待，具体表现为cursor: pin *等待，如cursor: pin S wait on X。

这里需要我们了解的是：

a) 从10.2.0.2开始，Oracle只是用mutex替代了针对cursor的library cache pin，这并不代表从10.2.0.2开始Oracle里就没有library cache pin等待了。比如这个例子里的library cache pin等待就发生在10.2.0.4中：http://dbsnake.com/2010/06/solve-library-cache-pin.html

b) Mutex和latch是互相独立，没有任何关系的：Latches and mutexes are independent mechanisms i.e. a process can hold a latch and a mutex at the same time. In the case of process death, latches are always cleaned up before mutexes. There is no generic mutex deadlock detection (unlike latches). There is no mutex/latch hierarchy.

从11gR1开始，Oracle用mutex替换了library cache latches，并引了一个新的等待事件：library cache: mutex *，我们来看一下这个知识点：

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0

Connected as nbs

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

library cache load lock 5 0 0 0 0 0

SQL> select name,level#,gets,misses,sleeps,immediate_gets,immediate_misses from v$latch_children where name like 'library%';

NAME LEVEL# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES

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

从结果里我们可以看到，在11.2.0.1里，各种library cache latches都没有了，只剩下了library cache load lock latch，而且Oracle还没有使用这个latch，因为gets是0。

DBA手记:System State之ass109.awk辅助分析

Thu, 01 Jan 1970 06:00:00 +0700

作者：eygle 发布在 eygle.com

在《Oracle DBA手记 3》即将出版之际，我将《Oracle DBA手记 2》上收录的一些文章发布出来，与大家分享。
前文参考：
http://www.eygle.com/archives/2011/05/dbasystem_state_file.html
http://www.eygle.com/archives/2011/05/dbasystem_state_rowcache.html

对于类似的跟踪文件，可以通过Oracle提供的ass109.awk脚本来分析，分析之后可以获得简明的输出（我的Windows上做了Unix工具增强，可以直接运行awk工具进行分析）：

D:\>awk -f ass109.awk edw_ora_8371.trc

..........................

Ass.Awk Version 1.0.9 - Processing edw_ora_8371.trc

System State 1

~~~~~~~~~~~~~~~~

2: waiting for 'rdbms ipc message' wait

3: waiting for 'pmon timer' wait

4: waiting for 'rdbms ipc message' wait

5: waiting for 'rdbms ipc message' wait

6: waiting for 'rdbms ipc message' wait

7: waiting for 'rdbms ipc message' wait

9: waiting for 'rdbms ipc message' wait

10:

11: waiting for 'rdbms ipc message' wait

12: for 'Streams AQ: waiting for time management or cleanup tasks' wait

13: waiting for 'rdbms ipc message' wait

14: waiting for 'Streams AQ: qmn coordinator idle wait' wait

15: waiting for 'rdbms ipc message' wait

16: waiting for 'Wait for shrink lock' wait

17: waiting for 'smon timer' wait

18: waiting for 'SQL*Net message from client' wait

19: waiting for 'rdbms ipc message' wait

21: waiting for 'rdbms ipc message' wait

23: waiting for 'rdbms ipc message' wait

25: waiting for 'SQL*Net message from client' wait

27: waiting for 'SQL*Net message from client' wait

29: last wait for 'ksdxexeotherwait' [Rcache object=4f4e57138,]

Cmd: Insert

30: waiting for 'Streams AQ: qmn slave idle wait' wait

33: for 'Streams AQ: waiting for messages in the queue' wait

Blockers

~~~~~~~~

Above is a list of all the processes. If they are waiting for a resource

then it will be given in square brackets. Below is a summary of the

waited upon resources, together with the holder of that resource.

Notes:

~~~~~

o A process id of '???' implies that the holder was not found in the

systemstate.

Resource Holder State

Rcache object=4f4e57138, 16: waiting for 'Wait for shrink lock'

Object Names

~~~~~~~~~~~~

Rcache object=4f4e57138,

77807 Lines Processed.

注意，输出文件中清晰地指出，数据库的16号进程持有了对象4f4e57138的Row Cache锁，正在等待：Wait for shrink lock。而29号进程正是在4f4e57138对象上产生了等待，处于挂起状态，无法执行INSERT操作。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2011/05/dbasystem_state_ass109.html

学前教育必须选择高收费机构

Thu, 01 Jan 1970 06:00:00 +0700

DBA手记:System State转储之ROW CACHE对象

Thu, 01 Jan 1970 06:00:00 +0700

作者：eygle 发布在 eygle.com

在《Oracle DBA手记 3》即将出版之际，我将《Oracle DBA手记 2》上收录的一些文章发布出来，与大家分享。

前文参考： http://www.eygle.com/archives/2011/05/dbasystem_state_file.html

1.1 ROW CACHE对象的定位

跟踪文件向下显示了更进一步的信息，地址为 4f4e57138 的Row Cache Parent Object紧跟着之前的信息显示出来，跟踪信息同时显示是在DC_OBJECTS层面出现的问题。

跟踪信息显示对象的锁定模式为排他锁定（mode=X）。

下图是跟踪文件的截取，我们可以看到Oracle的记录方式：

进一步的，跟踪文件里也显示了29号进程执行的SQL为INSERT操作：

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

SO: 4f2e82c88, type: 53, owner: 6c10508e8, flag: INIT/-/-/0x00

LIBRARY OBJECT LOCK: lock=4f2e82c88 handle=4f528d510 mode=N

call pin=0 session pin=0 hpc=0000 hlc=0000

htl=4f2e82d08[4f2de4dd8,4f2e844c0] htb=4e84c5db0 ssga=4e84c57c8

user=6c10508e8 session=6c10508e8 count=1 flags=[0000] savepoint=0x4bad2ee7

LIBRARY OBJECT HANDLE: handle=4f528d510 mtx=4f528d640(1) cdp=1

name=INSERT /*+ APPEND*/ INTO CACI_INV_BLB_DC NOLOGGING SELECT :B1 , T.*, SYSDATE FROM CACI_INV_BLB T

hash=6734e347f90993bcd607836585310c4d timestamp=03-24-2010 06:01:54

namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/KST/DBN/MTX/[500100d0]

kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=12 hpc=ffec hlc=ffec

lwt=4f528d5b8[4f528d5b8,4f528d5b8] ltm=4f528d5c8[4f528d5c8,4f528d5c8]

pwt=4f528d580[4f528d580,4f528d580] ptm=4f528d590[4f528d590,4f528d590]

ref=4f528d5e8[4f528d5e8,4f528d5e8] lnd=4f528d600[4f581b4d8,4f5d190a8]

LIBRARY OBJECT: object=4a7227a50

type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0

CHILDREN: size=16

child# table reference handle

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

0 4a7227518 4a7227188 4ae9ed1f0

1 4a7227518 4a7227420 494cd5878

DATA BLOCKS:

data# heap pointer status pins change whr

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

0 4aebaa950 4a7227b68 I/P/A/-/- 0 NONE 00

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

好了，那么现在我们来看看是哪一个进程排他的锁定了之前的4f4e57138对象。在跟踪文件中搜索4f4e57138就可以很容易的找到这个持有排他锁定的SO对象。

以下显示了相关信息，Row Cache 对象的信息在此同样有所显示：

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

SO: 4e86f0508, type: 50, owner: 8c183c258, flag: INIT/-/-/0x00

row cache enqueue: count=1 session=8c005d7c8 object=4f4e57138, mode=X

savepoint=0x2716

row cache parent object: address=4f4e57138 cid=8(dc_objects)

hash=b363a728 typ=11 transaction=8c183c258 flags=00000002

own=4f4e57208[4e86f0538,4e86f0538] wat=4f4e57218[4e86f0418,4e86f0418] mode=X

status=VALID/-/-/-/-/-/-/-/-

set=0, complete=FALSE

data=

00000038 00134944 585f4341 43495f49 4e565f42 4c425f44 43000000 00000000

00000000 04000009 505f3230 31305f51 31000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 000209ca ffff0000 000209ca 14786e01 020e3239

786e0102 0e323978 6e01020e 32390100 00000000 00000000 00000000 00000000

00000000 00000006

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

再向上找到这个进程的信息，发现其进程号为16：

PROCESS 16:

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

SO: 8c00037d0, type: 2, owner: 0, flag: INIT/-/-/0x00

(process) Oracle pid=16, calls cur/top: 8c0095028/8c0094aa8, flag: (0) -

int error: 0, call error: 0, sess error: 0, txn error 0

(post info) last post received: 115 0 4

last post received-location: kslpsr

last process to post me: 6c1002800 1 6

last post sent: 0 0 24

last post sent-location: ksasnd

last process posted by me: 6c1002800 1 6

(latch info) wait_event=0 bits=0

Process Group: DEFAULT, pseudo proc: 4f818c298

O/S info: user: oracle, term: UNKNOWN, ospid: 8200

OSD pid info: Unix process pid: 8200, image: oracle@SF2900 (J000)

在这里可以看到16号进程是一个JOB进程，其进程为J000，那么这个JOB进程在执行什么操作呢？下面的信息可以看出一些端倪，JOB由DBMS_SCHEDULER调度，执行AUTO_SPACE_ADVISOR_JOB任务，处于Wait for shrink lock等待：

Job Slave State Object

Slave ID: 0, Job ID: 8913

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

SO: 8c005d7c8, type: 4, owner: 8c00037d0, flag: INIT/-/-/0x00

(session) sid: 45 trans: 8c183c258, creator: 8c00037d0, flag: (48100041) USR/- BSY/-/-/-/-/-

DID: 0001-0010-0007BFA6, short-term DID: 0000-0000-00000000

txn branch: 0

oct: 0, prv: 0, sql: 0, psql: 0, user: 0/SYS

O/S info: user: oracle, term: UNKNOWN, ospid: 8200, machine: SF2900

program: oracle@SF2900 (J000)

application name: DBMS_SCHEDULER, hash value=2478762354

action name: AUTO_SPACE_ADVISOR_JOB, hash value=348111556

waiting for 'Wait for shrink lock' blocking sess=0x0 seq=5909 wait_time=0 seconds since wait started=3101

object_id=0, lock_mode=0, =0

Dumping Session Wait History

for 'Wait for shrink lock' count=1 wait_time=380596

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107262

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107263

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107246

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107139

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107248

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107003

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107169

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107233

object_id=0, lock_mode=0, =0

for 'Wait for shrink lock' count=1 wait_time=107069

object_id=0, lock_mode=0, =0

temporary object counter: 3

进一步向下查找，可以找到Shrink操作执行的SQL语句：

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

SO: 4e8a2c6c0, type: 53, owner: 8c005d7c8, flag: INIT/-/-/0x00

LIBRARY OBJECT LOCK: lock=4e8a2c6c0 handle=4c3c1ce60 mode=N

call pin=0 session pin=0 hpc=0000 hlc=0000

htl=4e8a2c740[4e81436e0,4e8c80c98] htb=4e8937910 ssga=4e8936e48

user=8c005d7c8 session=8c005d7c8 count=1 flags=[0000] savepoint=0x4bad2eec

LIBRARY OBJECT HANDLE: handle=4c3c1ce60 mtx=4c3c1cf90(1) cdp=1

name=alter index "CACI"."IDX_CACI_INV_BLB_DC" modify partition "P_2010_Q1" shrink space CHECK

hash=0ed1a6f7b2cf775661d314b8d1b7659b timestamp=03-25-2010 22:05:09

namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/KST/DBN/MTX/[500100d0]

kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=15 hpc=0002 hlc=0002

lwt=4c3c1cf08[4c3c1cf08,4c3c1cf08] ltm=4c3c1cf18[4c3c1cf18,4c3c1cf18]

pwt=4c3c1ced0[4c3c1ced0,4c3c1ced0] ptm=4c3c1cee0[4c3c1cee0,4c3c1cee0]

ref=4c3c1cf38[4c3c1cf38,4c3c1cf38] lnd=4c3c1cf50[4c3c1cf50,4c3c1cf50]

LIBRARY OBJECT: object=4aa2bf668

type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0

CHILDREN: size=16

child# table reference handle

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

0 49efa3fe8 49efa3c58 4c3ad91a8

1 49efa3fe8 49efa3ed8 4c3941608

DATA BLOCKS:

data# heap pointer status pins change whr

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

0 4c3589b38 4aa2bf780 I/P/A/-/- 0 NONE 00

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

至此，真相大白于天下：

1．系统通过DBMS_SCHEDULER调度执行AUTO_SPACE_ADVISOR_JOB任务

发出了SQL语句：

alter index "CACI"."IDX_CACI_INV_BLB_DC" modify partition "P_2010_Q1" shrink space CHECK

2．定时任务不能及时完成产生了排他锁定

3．客户端执行的INSERT操作挂起

INSERT语句为：

INSERT /*+ APPEND*/ INTO CACI_INV_BLB_DC NOLOGGING SELECT :B1 , T.*, SYSDATE FROM CACI_INV_BLB T

Shrink Space的语句所以不能成功完成是因为该索引的相关数据表的数据量过为巨大。在Oracle10g中，缺省的有一个任务定时进行分析为用户提供空间管理建议，在进行空间建议前，Oracle执行Shrink Space Check，这个检查工作和Shrink的具体内部工作完全相同，只是不执行具体动作。

这个Shrink Space的检查对于客户环境显得多余。

现场解决这个问题，只需要将16号进程Kill掉，即可释放了锁定，后面的操作可以顺利进行下去。

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2011/05/dbasystem_state_rowcache.html

中国梦 - 美国梦

Thu, 01 Jan 1970 06:00:00 +0700

转载.

我在《郎咸平说：我们的日子为什么这么难》里反复讲要“藏富于民”。各位，请想想看我们的日子到底难在哪里？你知道吗？

去年有人出了一个报告，说中国有1/3的GDP是隐性收入，数字高达9.26万亿。你能想象到的灰色收入可能都在里面。“夜总会小姐唱个歌也能创收好几倍”，我们是这么看问题的，你知道吗？各位想想看，一个社会如果成了这样，你不感到痛心吗？所以9.26万亿已经不是灰色收入的问题了，而是说整个社会在改变。

你有没有想到一个更严重的社会问题出来了。这个隐性收入代表的是什么？是整个社会的阶级固化。《人民日报》去年登了一篇文章，我觉得写得非常好，也非常让人痛心。说的是在封建时代，整个社会是上下流动的。六部官员哪里来的？贫穷子弟十载寒窗，考上秀才、举人，进士及第之后一步步升上来做官的。这个历史传统到今天已经不复存在了。

阶级固化的结果举个最简单的例子，你今天辛辛苦苦念完北大、清华、复旦出来，薪水一个月两千块，还比不上夜总会小姐。这对于我们中华传统文化的颠覆有多大，你知道吗？过去是透过所谓寒窗苦读来出人头地，今天靠什么？投机倒把。今天的问题，我觉得最基本的根源不是人心变得坏了，而是整个社会阶级固化的结果。我们的年轻人再没有出头的机会了。我请问你，80后、90后，你们大学毕业的时候你想做什么？你找到的工作，两三千块一个月，而且搞不好还要做一辈子。当你对整个社会的阶级固化感到绝望的时候，前面说的现象自然而然就产生了。你会发现灰色收入是你人生中最重要的，搞不好你就没有房子、没有车子，老婆都娶不到。那灰色收入怎么来呢？那就是晚上经常到夜总会，上电视非诚勿扰，等等。灰色收入是阶级固化的一个必然结果。

如何解决阶级固化？一定要给老百姓机会。为什么很多人愿意去美国留学，甚至愿意留在美国，为什么？你觉得美国好吗？美国不会比中国精彩，我就非常不愿意到美国生活。但是美国有一点值得我们学习，那就是美国政府可以非常骄傲地告诉任何人美国梦。像奥巴马这样父母离异的黑人也然当上了美国总统。他任命了一个商务部长骆家辉，是第三代移民，父母是从在餐馆洗盘子开始的。还有朱棣文，也是留学到了美国之后留下来的，最后成了能源部长。你知道这是什么意思吗？奥巴马你什么身份？朱棣文、骆家辉你什么身份？完全没有家庭背景。你们凭什么成功啊，就是因为美国社会给了每一个人美国梦。什么叫美国梦？不是给你更多的薪水，不是给你一个灰色收入的空间，而是什么呢？给每一个人希望。你只有给每个人希望，每个人才有创业的机会，才有这种激情能够把每一份事做好，因为他有一个梦，他认为几十年之后他可以变成奥巴马，他可以变成朱棣文、骆家辉。你觉得今天我们中国有这种机会吗？年轻的朋友，你们去公务员团队做事，你觉得你可以到朱棣文、骆家辉的水平吗？有这种可能吗？没可能。

所以我想通过灰色收入告诉我们老百姓一句话，灰色收入跟这一切的问题所象征的是我们缺乏中国梦。如何改变社会的结构？让这个社会每一个老百姓都有个立足点的平等？在这个立足点平等之上，每个人凭着个人的聪明才智，争取到你所能争取到的最高境界？其实这并不难，只是我们目前的政策推动都不朝这个方向走。我们没有给这个社会建立起一个好的价值观。

老百姓不再感觉到有中国梦了。中国梦有多重要，你知道吗？我们每年税增长20%以上，这些钱如果能用在刀刃上的话，就能够帮助老百姓完成中国梦，你知道吗？我们浪费这么多钱做了什么了？我们用在各地大规模的低效率的基础建设上，搞的各地财政是连年赤字，甚至还不起钱都有可能。你没有替老百姓创造一个中国梦，低效率的浪费掉钱了。各位，我尤其想告诉我们官员，你知道最让我痛心什么吗？投资的失误。这种投资的浪费，是千亿、万亿的浪费。如果当初肯听我郎咸平一句话，四万亿你不要投给什么基础建设，你给我们所有民营企业三年免税多好，想想看，他们负担了全中国90%的雇佣量啊。你三年免税了，赤字怎么办呢？财政窟窿怎么办呢？我告诉你，国有企业不准搞房地产，像什么中粮，你不搞粮食你搞什么房地产，不务正业。这些国有企业不准做这种旁门左道的事，你所有利润全部上交，不准买地皮，全部补充财政窟窿。三年免税，各位晓得能创造多少财富吗？这个免税你晓得有什么用处吗？这是中国梦的一部分啊。

你的财政收入投到正确地方之后，大家发现投资企业能够赚大钱，很多人就愿意在这方面发展，而不会说投资环境那么恶化，又不赚钱，干脆炒楼、炒股算了，是不是？各位想一想，这样子是不是对的呢？今天我们这一切问题，是我们缺乏中国梦。灰色收入等等的问题是可以解决的，靠什么解决？这需要靠一个更优良的税收的使用来解决，给每一位朋友创造个中国梦。

使用RPM&YUM进行基础软件管理

Thu, 01 Jan 1970 06:00:00 +0700

Author:NinGoo posted on NinGoo.net

上周花时间研究了下RPM打包的方法，今天和团队分享了一次。之前我们采用shell脚本进行批量的MySQL安装，虽然通过不断改进的脚本，批量安装部署的效率已经算不错。但即使是安装MySQL这样简单的事情，不断提升效率，在大规模的环境中也是会带来更多的收益。

追求简单，做到极致，共勉之。

使用Rpm&yum进行基础软件管理

View more presentations from seaman ning

Related Articles

PermLink: http://www.ningoo.net/html/2011/using_rpm_yum_for_mysql_install.html

Add Comments(0) | Follow NinGoo@Twitter | Google Reader

女儿进公司

Thu, 01 Jan 1970 06:00:00 +0700

OPatch failed with error code 73 when patch Oracle 10.2.0.4 on Mac OS X

Thu, 01 Jan 1970 06:00:00 +0700

现在Mac OS X中的Oracle数据库最新版本是10.2.0.4 （没有10.2.0.5更没有11g）。如果想给该版本数据库打上PSU补丁的时候，会遇到以下错误。

Running prerequisite checks...
Prerequisite check "CheckPatchApplicableOnCurrentPlatform" failed.
The details are:
Patch ( <some_patch_number> ) is not applicable on current platform.
Platform ID needed is : 46
Platform IDs supported by patch are: 293
UtilSession failed: Prerequisite check "CheckPatchApplicableOnCurrentPlatform" failed.
 
OPatch failed with error code 73

这个错误是由于Bug # 8647770引起的。解决方法如下：
1. 下载patch 8647770.
2. 安装补丁

$ export OPATCH_PLATFORM_ID=293
$ cd 8647770
$ opatch apply

安装完此补丁以后，再重新运行PSU Patch，就可以正常打上补丁了。

Notes for Oracle Database PSU/CPU

Thu, 01 Jan 1970 06:00:00 +0700

1. 什么是PSU/CPU？
CPU: Critical Patch Update
Oracle对于其产品每个季度发行一次的安全补丁包，通常是为了修复产品中的安全隐患。

PSU: Patch Set Updates
Oracle对于其产品每个季度发行一次的补丁包，包含了bug的修复。Oracle选取被用户下载数量多的，并且被验证过具有较低风险的补丁放入到每个季度的PSU中。在每个PSU中不但包含Bug的修复而且还包含了最新的CPU。

2. 如何查找最新的PSU？
每个数据库版本都有自己的PSU，PSU版本号体现在数据库版本的最后一位，比如最新的10.2.0.5的PSU是10.2.0.5.3，而11.2.0.2的最新PSU则是11.2.0.2.2。
MOS站点中Oracle Recommended Patches — Oracle Database [ID 756671.1] 文档中查到各个产品版本最新的PSU。
如果你记不住这个文档号，那么在MOS中以“PSU”为关键字搜索，通常这个文档会显示在搜索结果的最前面。

注意：必须购买了Oracle基本服务获取了CSI号以后才有权限登陆MOS站点。

3. 如何正确安装PSU？
每个PSU安装包中都包含一个README.html文档，其中描述了如何安装该PSU，有些PSU是可以直接安装的，而有些PSU则必须要求安装了上一个版本的PSU之后才能继续安装。比如对于10.2.0.4版本的数据库来说，PSU 10.2.0.4.4可以直接安装在最原始的10.2.0.4.0版本中，而最新的PSU 10.2.0.4.8则必须要求先安装10.2.0.4.4。这些信息在README.html中都可以找到，所以请仔细阅读该文档。

通常安装PSU是比较简单的，步骤如下：
1) 安装PSU需要使用到opatch，在README.html中有描述该PSU需要的最低版本opatch，如果当前opatch版本过低，则需要先下载Patch 6880880，该Patch中包含最新的opatch，只需要解压覆盖原先的$ORACLE_HOME/OPatch目录即可。

查看当前的opatch版本，可以使用opatch version命令。

$ opatch version
Invoking OPatch 10.2.0.5.2
 
OPatch Version: 10.2.0.5.2
 
OPatch succeeded.

2）安装PSU，请仔细阅读README.html，确认安装命令，通常是简单的opatch apply。

opatch apply

3）更新数据库，将修改过的SQL文件应用到数据库中，很多DBA在执行完上述安装命令以后就不再进行这一步，那么实际上PSU是没有完整安装的。

cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SQL> STARTUP
SQL> @catbundle.sql opsu apply
SQL> QUIT

4）重新编译CPU相关视图。该步骤在一个数据库上永远只需要执行一次，是为了完成在2008年1月份第一次发布CPU补丁时的后续工作，如果在安装以前的PSU或者CPU时执行过这个步骤那么就可以无需再次执行，另外，即使不执行该步骤，数据库也是正常运行的，只不过意味着2008年1月份的CPU补丁没有正常结束安装。

cd $ORACLE_HOME/cpu/view_recompile
sqlplus / as sysdba
SQL> @recompile_precheck_jan2008cpu.sql
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP UPGRADE
SQL> @view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
SQL> QUIT

注意：该步骤需要重新启动数据库到upgrade状态才可以完成。

4. 如何确认当前数据库已经安装了什么PSU/CPU？
无论是从V$VERSION或者DBA_REGISTRY或者PRODUCT_COMPONENT_VERSION视图中，都无法查找到PSU的信息，这些视图中始终显示的是最原始的版本，比如10.2.0.4.0。

最常用的方法是使用opatch命令。在打完最新的PSU 10.2.0.4.8的10.2.0.4数据库中会有以下显示。

$ opatch lsinventory -bugs_fixed | grep -i 'DATABASE PSU'
9654991    11724977  Wed May 25 16:37:17 CST 2011   DATABASE PSU 10.2.0.4.5 (REQUIRES PRE-REQUISITE 
9952234    11724977  Wed May 25 16:37:17 CST 2011   DATABASE PSU 10.2.0.4.6 (REQUIRES PRE-REQUISITE 
10248636   11724977  Wed May 25 16:37:17 CST 2011   DATABASE PSU 10.2.0.4.7 (REQUIRES PRE-REQUISITE 
11724977   11724977  Wed May 25 16:37:17 CST 2011   DATABASE PSU 10.2.0.4.8 (REQUIRES PRE-REQUISITE 
8576156    9352164   Wed May 25 15:10:48 CST 2011   DATABASE PSU 10.2.0.4.1 (INCLUDES CPUJUL2009)
8833280    9352164   Wed May 25 15:10:48 CST 2011   DATABASE PSU 10.2.0.4.2 (INCLUDES CPUOCT2009)
9119284    9352164   Wed May 25 15:10:48 CST 2011   DATABASE PSU 10.2.0.4.3 (INCLUDES CPUJAN2010)
9352164    9352164   Wed May 25 15:10:48 CST 2011   DATABASE PSU 10.2.0.4.4 (INCLUDES CPUAPR2010)

另外的方法是查看registry$history表。

SQL> select action,comments from registry$history;
 
ACTION			       COMMENTS
------------------------------ --------------------
APPLY			       PSU 10.2.0.4.4
APPLY			       PSU 10.2.0.4.8
CPU			       view recompilation

注意：该表的内容是在上述安装PSU步骤的第三步中运行catbundle.sql才会插入的，因此如果该步骤忘记执行，则此表中无记录。因此我们在作数据库健康检查的时候不但要用opatch检查当前数据库最新的PSU补丁，也要检查registry$history表，以确认其它DBA是否正确地完成了PSU的安装。

5. 参考文档。
Oracle Recommended Patches — Oracle Database [ID 756671.1]
Patch Set Updates for Oracle Products [ID 854428.1]
Introduction To Oracle Database catbundle.sql [ID 605795.1]
How to confirm that a Critical Patch Update (CPU) has been installed in Linux / UNIX [ID 821263.1]