v$sql和v$sqlarea视图： 上文提到，v$sqlarea和v$sql两个视图的不同之处在于，v$sql中为每一条SQL保留一个条目，而v$sqlarea中根据sql_text进行group by，通过version_count计算子指针的个数。下面对这个问题进行一点延伸探讨。 首先介绍一下v$sql视图，v$sql视图列举了共享SQL区（Shared SQL Area）中的SQL统计信息，这个视图中的信息未经分组，每个SQL指针都包含一条独立的记录。这个视图的主要字段如下： Column Datatype Descrption SQL_TEXT VARCHAR2(1000[......]
Shared Pool Latch和Library Cache Latch竞争
Shared Pool Latch和Library Cache Latch竞争： 这两个Latch是Shared Pool管理中最重要也是最常见的Latch竞争。 Shared Pool Latch用于共享池中内存空间的分配和回收，如果SQL没有充分共享，反复解析，那么将会不断请求Shared Pool Latch在共享池中分配空间，由此可能造成非常严重的CPU消耗。 而Library Cache Latch用于保护Cache在内存中的SQL以及执行计划等，当需要向Library Cache中增加新的SQL时，Library Cache Latch必须被获得。在解析SQL过程中，Oracle[......]
Library cache pin/lock 在Oracle 10g的增强
Library cache pin/lock 在Oracle 10g的增强： 从Oracle 10g开始，以上测试将不会看到同样的效果，这是因为Oracle 10g对于对象编译与重建做出了增强。注意以下测试（来自Oracle 10gR2环境）： sys@NEI> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';Session altered.sys@NEI> select object_name,last_ddl_time from user_objects where object_name='PINING'[......]
LIBRARY CACHE LOCK 等待事件
LIBRARY CACHE LOCK 等待事件： 接上篇日志，如果此时再发出一条grant或compile的命令，那么library cache lock等待事件将会出现。 Session 3：sys@NEI> alter procedure pining compile; 此进程挂起，查询v$session_wait视图可以获得以下信息： sys@NEI> select * from v$session_wait where event like 'library cache%'; SID&nb[......]
LIBRARY CACHE PIN 等待事件
LIBRARY CACHE PIN 等待事件： Oracle文档上这样介绍这个等待事件：library cache pin是用来管理library cache的并发访问的，pin一个Object会引起相应的heap被载入内存中（如果此前没有被加载），pins可以在Null、Share、Exclusive这3个模式下获得，可以认为pin是一种特定形式的锁。 当library cache pin等待事件出现时，通常说明该pin被其他用户已非兼容模式持有。library cache pin的等待时间为3秒钟，其中有1秒钟用于PMON后台进程，即在取得pin之前最多等待3秒钟，否则就超时。libr[......]