月归档：九月 2011

cursor: pin S事件

发表于 2011 年 9 月 15 日 由 惜分飞

A session waits for “cursor: pin S” when it wants a specific mutex in S (share) mode on a specific cursor and there is no concurrent X holder but it could not acquire that mutex immediately. This may seem a little strange as one might question why there should be any form of wait to get a mutex which has no session holding it in an incompatible mode. The reason for the wait is that in order to acquire the mutex in S mode (or release it) the session has to increment (or decrement) the mutex reference count and this requires an exclusive atomic update to the mutex structure itself. If there are concurrent sessions trying to make such an update to the mutex then only one session can actually increment (or decrement) the reference count at a time. A wait on “cursor: pin S” thus occurs if a session cannot make that atomic change immediately due to other concurrent requests.
Mutexes are local to the current instance in RAC environments.

Oracle10g中引用的mutexes机制一定程度的替代了library cache pin，其结构更简单，get&set的原子操作更快捷。
它相当于，每个child cursor下面都有一个mutexes这样的简单内存结构，当有session要执行该SQL而需要pin cursor操作的时候，session只需要以shared模式set这个内存位+1，表示session获得该mutex的shared mode lock.可以有很多session同时具有这个mutex的shared mode lock；但在同一时间，只能有一个session在操作这个mutext +1或者-1。+1 -1的操作是排它性的原子操作。如果因为session并行太多，而导致某个session在等待其他session的mutext +1/-1操作,则该session要等待cursor: pin S等待事件。
当看到系统有很多session等待cursor: pin S事件的时候，要么是CPU不够快，要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。如果是Capacity的问题，则可以升级硬件。如果是因为SQL的并行太多，则要么想办法降低该SQL执行次数，要么将该SQL复制成N个其它的SQL。
select /*SQL 1*/object_name from t where object_id=?
select /*SQL 2*/object_name from t where object_id=?
select /*SQL …*/object_name from t where object_id=?
select /*SQL N*/object_name from t where object_id=?
这样就有了N个SQL Cursor,N个Mutex内存结构，就将争用分散开来，类似partition的作用了

发表在 Oracle性能优化 | 评论关闭

Oracle常用诊断事件清单

发表于 2011 年 9 月 14 日 由 惜分飞
事件 说明 例子
Event 10013 – Monitor Transaction Recovery 在Startup时跟踪事务恢复 ALTER SESSION SET EVENTS ’10013 trace name context forever, level 1′;
Event 10015 – Dump Undo Segment Headers- 在事务恢复后做Dump回退段头信息 ALTER SESSION SET EVENTS ’10015 trace name context forever, level 1′;
Event 10032 – Dump Sort Statistics Dump排序的统计信息 ALTER SESSION SET EVENTS ’10032 trace name context forever, level 10′;
Event 10033 – Dump Sort Intermediate Run Statistics 排序过程中，内存排序区和临时表空间的交互情况 ALTER SESSION SET EVENTS ’10033 trace name context forever, level 10′;
Event 10045 – Trace Free List Management Operations FREELIST的管理操作 ALTER SESSION SET EVENTS ’10045 trace name context forever, level 1′;
Event 10046 – Enable SQL Statement Trace 跟踪SQL,有执行计划,邦定变量和等待的统计信息,level 12最详细。 ALTER SESSION SET EVENTS ’10046 trace name context forever, level 12′;

LEVEL定义如下：

1:SQL 语句，执行计划和执行状态

4:1的内容加上绑定变量信息

8:1的信息加上等待事件信息

12:1＋4＋8
Event 10053 – Dump Optimizer Decisions 在分析SQL语句时,Dump出优化器所做的选择,级别level 1最详细 ALTER SESSION SET EVENTS ’10053 trace name context forever, level 1′;

LEVEL定义如下：

1：状态和估算信息

2：只显示估算信息
Event 10060 – Dump Predicates DUMP SQL语句中的断语信息。需要在需要DUMP的用户下创建以下表

CREATE TABLE kkoipt_table
(c1 INTEGER,

c2 VARCHAR2(80));

断语信息会写入该表

 ALTER SESSION SET EVENTS ’10060 trace name context forever, level 1′;
Event 10065 – Restrict Library Cache Dump Output for State Object Dumps 限制对象状态DUMP的时候LIBRARY CACHE信息的详细程度
1 Address of library object only

2 As level 1 plus library object lock details

3 As level 2 plus library object handle and library object

缺省是LEVEL 3

 ALTER SESSION SET EVENTS ’10065 trace name context forever, level level’;
Event 10079 – Dump SQL*Net Statistics- Dump SQL*NeT的统计信息 ALTER SESSION SET EVENTS ’10079 trace name context forever, level 2′;
Event 10081 – Trace High Water Mark Changes HWM的改变 ALTER SESSION SET EVENTS ’10081 trace name context forever, level 1′;
Event 10104 – Dump Hash Join Statistics HASH JOIN的统计信息 ALTER SESSION SET EVENTS ’10104 trace name context forever, level 10′;
Event 10128 – Dump Partition Pruning Information 分区表调整信息 ALTER SESSION SET EVENTS ’10128 trace name context forever, level level’;

Level取值：

1   Dump pruning descriptor for each partitioned object

0×0002 Dump partition iterators

0×0004 Dump optimizer decisions about partition-wise joins

0×0008 Dump ROWID range scan pruning information

在9.0.1或者后面的版本,在level 2后还需要建立如下的表:

CREATE TABLE kkpap_pruning

(

partition_count    NUMBER,

iterator           VARCHAR2(32),

partition_level    VARCHAR2(32),

order_pt         VARCHAR2(12),

call_time        VARCHAR2(12),

part#             NUMBER,

subp#              NUMBER,

abs#               NUMBER

);
事件 说明 例子
Event 10200 – Dump Consistent Reads DUMP一致读的信息 ALTER SESSION SET EVENTS ’10200 trace name context forever, level 1′;
Event 10201 – Dump Consistent Read Undo Application DUMP一致性读涉及UNDO信息的内容 ALTER SESSION SET EVENTS ’10201 trace name context forever, level 1′;
Event 10220 – Dump Changes to Undo Header Dump出Undo头信息的改变 ALTER SESSION SET EVENTS ’10220 trace name context forever, level 1′;
Event 10221 – Dump Undo Changes Dump Undo的改变 ALTER SESSION SET EVENTS ’10221 trace name context forever, level 7′;
Event 10224 – Dump Index Block Splits / Deletes 索引块的分裂和D删除信息 ALTER SESSION SET EVENTS ’10224 trace name context forever, level 1′;
Event 10225 – Dump Changes to Dictionary Managed Extents DUMP字段管理的扩展变化 ALTER SESSION SET EVENTS ’10225 trace name context forever, level 1′;
Event 10231 全表扫描时跳过坏块，在有坏块的情况下做数据拯救时很有用 ALTER SYSTEM SET EVENTS ’10231 trace name context forever,level 10′;
Event 10241 – Dump Remote SQL Execution 远程SQL语句的执行信息 ALTER SESSION SET EVENTS ’10241 trace name context forever, level 1′;
Event 10246 – Trace PMON Process 跟踪PMON进程 只能修改参数，不能用ALTER SYSTEM

event = “10246 trace name context forever, level 1″
Event 10248 – Trace Dispatcher Processes 跟踪DISPATCHER的工作情况 event = “10248 trace name context forever, level 10″
Event 10249 – Trace Shared Server (MTS) Processes- 跟踪共享服务器的工作情况 event = “10249 trace name context forever, level 10″
Event 10270 – Debug Shared Cursors 跟踪共享CURSORS的情况 event = “10270 trace name context forever, level 10″
Event 10299 – Debug Prefetching 跟踪表数据块和索引数据块的PREFETCHING event = “10299 trace name context forever, level 1″
Event 10357 – Debug Direct Path ALTER SESSION SET EVENTS ’10357 trace name context forever, level 1′;
Event 10390 – Dump Parallel Execution Slave Statistics 跟踪并行操作中的SLAVE的状态 ALTER SESSION SET EVENTS ’10390 trace name context forever, level 1;
Event 10391-Dump Parallel Execution Granule Allocation 跟踪并行操作的粒度 ALTER SESSION SET EVENTS ’10391 trace name context forever, level 2′;
Event 10393 – Dump Parallel Execution Statistics 跟踪并行操作的状态（每个SLAVE单独列出状态） ALTER SESSION SET EVENTS ’10393 trace name context forever, level 1′;
Event 10500 – Trace SMON Process 跟踪SMON进程 event = “10500 trace name context forever, level 1″
Event 10608 – Trace Bitmap Index Creation 跟踪BITMAP索引创建的详细过程 ALTER SESSION SET EVENTS ’10608 trace name context forever, level 10′;
Event 10704 – Trace Enqueues 跟踪锁的使用情况 ALTER SESSION SET EVENTS ’10704 trace name context forever, level 1′;
Event 10706 – Trace Global Enqueue Manipulation 跟踪全局锁的使用情况 ALTER SESSION SET EVENTS ’10706 trace name context forever, level 1′;
Event 10708 – Trace RAC Buffer Cache 跟踪RAC环境下的BUFFER CACHE ALTER SESSION SET EVENTS ’10708 trace name context forever, level 10′;
事件 说明 例子
Event 10710 – Trace Bitmap Index Access 跟踪位图索引的访问情况 ALTER SESSION SET EVENTS ’10710 trace name context forever, level 1′;
Event 10711 – Trace Bitmap Index Merge Operation 跟踪位图索引合并操作 ALTER SESSION SET EVENTS ’10711 trace name context forever, level 1′;
Event 10712 – Trace Bitmap Index OR Operation 跟踪位图索引或操作情况 ALTER SESSION SET EVENTS ’10712 trace name context forever, level 1′;
Event 10713 – Trace Bitmap Index AND Operation 跟踪位图索引与操作 ALTER SESSION SET EVENTS ’10713 trace name context forever, level 1′;
Event 10714 – Trace Bitmap Index MINUS Operation 跟踪位图索引minus操作 ALTER SESSION SET EVENTS ’10714 trace name context forever, level 1′;
Event 10715 – Trace Bitmap Index Conversion to ROWIDs Operation 跟踪位图索引转换ROWID操作 ALTER SESSION SET EVENTS ’10715 trace name context forever, level 1′;
Event 10716 – Trace Bitmap Index Compress/Decompress 跟踪位图索引压缩和解压缩情况 ALTER SESSION SET EVENTS ’10716 trace name context forever, level 1′;
Event 10717 – Trace Bitmap Index Compaction ALTER SESSION SET EVENTS ’10717 trace name context forever, level 1′;
Event 10719 – Trace Bitmap Index DML 跟踪位图索引列的DML操作（引起位图索引改变的DML操作） ALTER SESSION SET EVENTS ’10719 trace name context forever, level 1′;
Event 10730 – Trace Fine Grained Access Predicates 跟踪细粒度审计的断语 ALTER SESSION SET EVENTS ’10730 trace name context forever, level 1′;
Event 10731 – Trace CURSOR Statements 跟踪CURSOR的语句情况 ALTER SESSION SET EVENTS ’10731 trace name context forever, level level’;

LEVEL定义

1     Print parent query and subquery

2     Print subquery only
Event 10928 – Trace PL/SQL Execution 跟踪PL/SQL执行情况 ALTER SESSION SET EVENTS ’10928 trace name context forever, level 1′;
Event 10938 – Dump PL/SQL Execution Statistics 跟踪PL/SQL执行状态。使用前需要执行rdbms/admin下的tracetab.sql ALTER SESSION SET EVENTS ’10938 trace name context forever, level 1′;
flush_cache 刷新BUFFER CACHE ALTER SESSION SET EVENTS ‘immediate trace name flush_cache’;
DROP_SEGMENTS 手工删除临时段。当这些临时段无法自动清除的时候可以手工清除 alter session set events ‘immediate trace name DROP_SEGMENTS level ts#+1′;

ts#是指要删除临时段的表空间的ts#
发表在 Oracle | 评论关闭

ORA-600 [LibraryCacheNotEmptyOnClose] on shutdown

发表于 2011 年 9 月 14 日 由 惜分飞

一、现象
alert.log中记录
Mon May 9 19:56:10 2011（shutdown 数据库过程中）
Errors in file /opt/oracle/admin/xunzhi/udump/xunzhi_ora_328.trc:
ORA-00600: internal error code, arguments: [LibraryCacheNotEmptyOnClose], [], [], [], [], [], [], []

trace中记录

*** 2011-05-09 19:56:10.843
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [LibraryCacheNotEmptyOnClose], [], [], [], [], [], [], []
Current SQL information unavailable - no session.
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
ksedst()+31          call     ksedst1()            000000000 ? 000000001 ?
                                                   7FFFB5A19840 ? 7FFFB5A198A0 ?
                                                   7FFFB5A197E0 ? 000000000 ?
ksedmp()+610         call     ksedst()             000000000 ? 000000001 ?
                                                   7FFFB5A19840 ? 7FFFB5A198A0 ?
                                                   7FFFB5A197E0 ? 000000000 ?
ksfdmp()+21          call     ksedmp()             000000003 ? 000000001 ?
                                                   7FFFB5A19840 ? 7FFFB5A198A0 ?
                                                   7FFFB5A197E0 ? 000000000 ?
kgerinv()+161        call     ksfdmp()             000000003 ? 000000001 ?
                                                   7FFFB5A19840 ? 7FFFB5A198A0 ?
                                                   7FFFB5A197E0 ? 000000000 ?
kgeasnmierr()+163    call     kgerinv()            0068966E0 ? 01EFD6610 ?
                                                   7FFFB5A198A0 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000000 ?
kglshu()+757         call     kgeasnmierr()        0068966E0 ? 01EFD6610 ?
                                                   7FFFB5A198A0 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000001 ?
kqlnfy()+468         call     kglshu()             0068966E0 ? 000000000 ?
                                                   7FFFB5A198A0 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000001 ?
kscnfy()+587         call     kqlnfy()             000000018 ? 000000000 ?
                                                   7FFFB5A198A0 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000001 ?
ksmshu()+269         call     kscnfy()             000000018 ? 000000000 ?
                                                   000000000 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000001 ?
opistp_real()+1052   call     ksmshu()             000000018 ? 000000000 ?
                                                   000000000 ? 7FFFB5A197E0 ?
                                                   000000000 ? 000000001 ?
opistp()+309         call     opistp_real()        000000031 ? 000000002 ?
                                                   7FFFB5A1E560 ? 000000000 ?
                                                   000000000 ? 000000001 ?
opiodr()+984         call     opistp()             000000031 ? 000000002 ?
                                                   7FFFB5A1E560 ? 000000000 ?
                                                   000000000 ? 000000001 ?
ttcpip()+1012        call     opiodr()             000000031 ? 000000002 ?
                                                   7FFFB5A1E560 ? 000000000 ?
                                                   0059C02A8 ? 000000001 ?
opitsk()+1322        call     ttcpip()             00689E3B0 ? 000000001 ?
                                                   7FFFB5A1E560 ? 000000000 ?
                                                   7FFFB5A1E058 ? 7FFFB5A1E6C8 ?
opiino()+1026        call     opitsk()             000000003 ? 000000000 ?
                                                   7FFFB5A1E560 ? 000000001 ?
                                                   000000000 ? 4E5000B00000000 ?
opiodr()+984         call     opiino()             00000003C ? 000000004 ?
                                                   7FFFB5A1F728 ? 000000001 ?
                                                   000000000 ? 4E5000B00000000 ?
opidrv()+547         call     opiodr()             00000003C ? 000000004 ?
                                                   7FFFB5A1F728 ? 000000000 ?
                                                   0059C0460 ? 4E5000B00000000 ?
sou2o()+114          call     opidrv()             00000003C ? 000000004 ?
                                                   7FFFB5A1F728 ? 000000000 ?
                                                   0059C0460 ? 4E5000B00000000 ?
opimai_real()+163    call     sou2o()              7FFFB5A1F700 ? 00000003C ?
                                                   000000004 ? 7FFFB5A1F728 ?
                                                   0059C0460 ? 4E5000B00000000 ?
main()+116           call     opimai_real()        000000002 ? 7FFFB5A1F790 ?
                                                   000000004 ? 7FFFB5A1F728 ?
                                                   0059C0460 ? 4E5000B00000000 ?
__libc_start_main()  call     main()               000000002 ? 7FFFB5A1F790 ?
+244                                               000000004 ? 7FFFB5A1F728 ?
                                                   0059C0460 ? 4E5000B00000000 ?
_start()+41          call     __libc_start_main()  000723088 ? 000000002 ?
                                                   7FFFB5A1F8E8 ? 000000000 ?
                                                   0059C0460 ? 000000002 ?

二、问题展示形式
ORA-600 [LibraryCacheNotEmptyOnClose] is reported in the alert.log on shutdown
The trace file shows the following call stack trace and will also include a System State:
kglshu kqlnfy kscnfy ksmshu opistp_real opistp opiodr ttcpip opitsk opiino opiodr opidrv sou2o opimai_real main libc_start_main

三、问题原因及其后果
This is a bug in that an ORA-600 error is reported when it is found during shutdown, after database close, that there are still objects in the library cache. It does not indicate any damage or a problem in the system.
Ignore the error as it just indicates that there are some items in the library cache when closing down the instance. The error itself occurs AFTER the database close and dismount stages so only affects the instance shutdown itself. Datafiles have been closed cleanly.

四、影响版本/修复

发表在 ORA-xxxxx | 评论关闭