ITPub博客

详细分析步骤下面给出两种方法来分析”library cache pin”,目的是找出哪些session在等待资源,哪些session 正占着这些资源,而占着资源的这些session又在做什么,从而找到问题的根源并加以解决.方法1.(1). 通过查询V$SESSION_WAIT找出正在等待”library cache pin”的session,其SQL语句如下:sql>select sid,substr(event,1,30),p1,p2,p3 from v$session_wait where wait_time=0 and event like 'library cache pin%'; SID SUBSTR(EVENT,1,30) P1 P2 P3 -------------------------------------------------------------------------------

概述 造成数据库性能下降或挂起的原因很多,”library cache pin”等待是其中之一.当数据库性能严重下降或挂起时,我们通过查询v$session_wait,发现大量的”library cache pin”等待,查询的SQL语句如下: #su - oracle$svrmgrlsvrmgr>connect internalsvrmgr>select sid,event,p1,p2,p3 from v$session_wait where wait_time=0;SID EVENT P1 P2 P3 ---------- ------------------------- ---------- ---------- -------------- 9 library cache pin 15417016 10090832 20 154 library cache pin 15417016 11224168 20 341 library cach

# man vmstat 得到帮助 # vmstat 2 10 r-->在运行队列中等待的进程数 b-->在等待io的进程数 w-->可以进入运行队列但被替换的进程 memoy swap-->现时可用的交换内存（k表示） free-->空闲的内存（k表示） pages re－－》回收的页面 mf－－》非严重错误的页面 pi－－》进入页面数（k表示） po－－》出页面数（k表示） fr－－》空余的页面数（k表示） de－－》提前读入的页面中的未命中数 sr－－》通过时钟算法扫描的页面 disk 显示每秒的磁盘操作。 s表示scsi盘，0表示盘号 fault 显示每秒的中断数 in－－》设备中断 sy－－》

根据上述两个ORACLE进程号(ORACLE PID)，我们可以找到他们的会话信息和操作系统进程信息SQL> select spid,pid,addr from v$process where pid in (26,28);SPID PID ADDR------------ ---------- ----------------20552 26 C000000109C831E0 ----------- 阻塞其他会话的Oracle进程22580 28 C000000109C83BF0 ----------- 被阻塞的Oracle进程SQL> 我们来进一步证实一下上述信息：SQL>col username for a20SQL> col osuser for a20SQL> col machine for a20SQL> l1 select sid,serial#,username,osuser,machine,to_char(lo

前面我们已经知道碰到'library cache lock'导致进程hang时，如何解决。那么如何避免这类问题的发生呢？这篇文章主要介绍了library cache lock的成因以及如何避免。当我们在执行一些DML，DDL，甚至desc tablename等等操作的时候，会话就hang住了，还有一种情况，当我们使用create or replace procedure/function等语句修改Procedure和Function的时候，会话也会hang住，这是为什么呢？当出现上述情况的时候，我们可以通过v$session_wait查询等待事件，当然，这种情况下，该session的等待事件一定是'Library cache lock'。让我们来解释一下，

这里，简单的介绍一下X$KGLLK，这个基表保存了库缓存中对象的锁的信息，它对于解决这类问题特别有用，其名称的含义如下：[K]ernel Layer [G]eneric Layer [L]ibrary Cache Manager ( defined and mapped from kqlf ) Object Locks X$KGLLK - Object [L]oc[K]s KGLNAOBJ 列包含了在librarky cache中的对象上执行命令的语句的前80个字符（其实从这里我们也可以大大缩小范围了）X$KGLLK.KGLLKUSE 和 x$kgllk.KGLLKSES 对应于跟踪文件中的owner的值X$KGLLK.KGLLKADR X$KGLLK.KGLLKHDL 对应于跟踪文件中的handle的值(handle=C000000122E2A6D8)，

现在我们来dump 系统状态(systemstate)，看看更详细的信息。首先简单的介绍一下 event systemstate。很多人把 systemstate 事件理解为dump发生的那一刻的系统内所有进程的信息，这是个错误的概念，事实上，转储 system state 产生的跟踪文件是从dump那一刻开始到dump任务完成之间一段事件内的系统内所有进程的信息。dump systemstate产生的跟踪文件包含了系统中所有进程的进程状态等信息。每个进程对应跟踪文件中的一段内容，反映该进程的状态信息，包括进程信息， 会话信息，enqueues信息（主要是lock的信息），缓冲区的信息和该进程在

问题的成因已经基本上明确了，这里推荐两种解决问题的方法：方法1，根据 c000000122e2a6d8 地址，我们可以得到当前在library cache中相应的锁信息： SQL> l1 select INST_ID,USER_NAME,KGLNAOBJ,KGLLKSNM,KGLLKUSE,KGLLKSES,KGLLKMOD,KGLLKREQ,KGLLKPNS,KGLLKHDL2* from X$KGLLK where KGLLKHDL = 'C000000122E2A6D8' order by KGLLKSNM,KGLNAOBJSQL> /INST_ID USER_NAME KGLNAOBJ KGLLKSNM KGLLKUSE KGLLKSES KGLLKMOD KGLLKREQ KGLLKPNS KGLLKHDL---------- ------------- ---------------------- ---------- ----------------

现在，我们结束10046的事件跟踪：SQL> exec dbms_system.set_ev(30,24167,0,0,'');PL/SQL procedure successfully completed.SQL> exec dbms_system.set_ev(37,2707,0,0,'');PL/SQL procedure successfully completed.SQL> 根据上面记录的信息，我们知道这两个会话产生的跟踪信息分别为：SID为30的会话，产生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_22580.trcSID为37的会话，产生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_20552.trc看看trace文件：ora9i@cs_dc02:/ora9i > c

跟踪期间咱们再次测试一下，看看有没有其他线索。新开一个进程，找出其sid, serial和spid等信息：ora9i@cs_dc01:/ora9i > sqlplus pubuser/pubuser SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jan 10 11:36:25 2005Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit ProductionWith the Partitioning and Real Application Clusters optionsJServer Release 9.2.0.4.0 - ProductionSQL> select distinct sid from v$mystat;SID------

问题描述：接到应用人员的报告，说是在任何对表CSNOZ629926699966的操作都会hang，包括desc CSNOZ629926699966,例如：ora9i@cs_dc02:/ora9i > sqlplus pubuser/pubuserSQL*Plus: Release 9.2.0.4.0 - Production on Mon Jan 10 10:11:06 2005Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit ProductionWith the Partitioning and Real Application Clusters optionsJServer Release 9.2.0.4.0 - ProductionSQL> conn pubuser/pubuserConne

三、解决方法有两种方法可以查询library cache pin的相关信息，推荐使用第二种。使用这种方法前，有必要先了解以下表或视图：x$kglob、x$kgllk、x$kglpn、DBA_KGLLOCK1) x$kglob该基表主要是library cache object的相关信息。X$KGLOB--[K]ernel [G]eneric [L]ibrary Cache Manager [OB]ject引用该基表的视图有﹕GV$ACCESS、GV$OBJECT_DEPENDENCY、GV$DB_OBJECT_CACHE、GV$DB_PIPES、DBA_LOCK_INTERNAL﹑DBA_DDL_LOCKS2) x$kgllk该基表保存了library cache中对象的锁信息，主要用于解决library cache lock。其名称含义是：[K]ernel Layer [

一、概述一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等.这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住.一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对象(例如:重编译一个包或视图的时候,会加上exclusive类型的锁)或更改对象的定义.总的来说，library cache pin和library cache lock都是用于share pool的并发控制的。pin和lock都可以看作是一种锁。locks/p

　　SGA的阀值摘要　　由下面的表一可以看到，在监视SGA的内存使用时，有几个明显的阀值可以利用。我们可以写一些脚本并在其中集成一些智能，这样就可以在处理的需求变化时重新设置SGA。　　RAM Area Too-small Condition Too-Large Condition 　　Shared pool Library cache misses No misses 　　Data buffer cache Hit ratio < 90% Hit ratio > 95% 　　PGA aggregate high multi-pass executions 100% optimal executions　　　表1：SGA中的异常条件指示　　查看SGA内存区域的负载　　Oracle9i使用了一些新的内部视图或者在现有

Oracle9i数据库在内部特性方面有着非常大的增强，其中一个最令Oracle DBA兴奋的莫过于可以动态设置全部的Oracle SGA控制参数。与8i不同的是，原来都将初始化参数放到一个文本文件中，并且在数据库启动的时候读取，Oracle9i却可以通过ALTER DATABASE和ALTER SYSTEM命令复位全部的Oracle参数。　　在9i前，如果想对Oracle数据库的处理模式作一 些改变的话，Oracle管理员必须关闭数据库并且重新设置INIT.ORA文件中的参数，然后重新启动数据库。对于白天使用OLTP模式运作，晚上切换 到数据仓库模式的Oracle数据库来说，这种重新设置是经常

SQL> select * from test order by id;ID MC-------------------- ------------------------------------------------------------A AAAAAB BBBBBa aaaaab bbbbb执行计划----------------------------------------------------------Plan hash value: 2007178810---------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 4 | 176 | 4 (25)|

由于Oracle不提供用于实时输出消息的工具, Oracle数据库开发者总是要面临实时监视他们的储备过程执行的挑战。他们必须使用dbms_output.put_line调用，这个调用直到过程完成才返回结果。　　在本文中，我想演示如何从Oracle8i数据库直接发送电子邮件，作为一种实时通信解决方案。这样我们要监视存储过程就不再需要等待它们完成了，这样的方法还为开发者提供了其他的一些好处：　　　. 可以在几分钟内调试一些很长的批处理过程，而不需要等几个小时；　　　. 计算用于指定代码块所需的执行时间；　 　这就需要解决一个问题，我们如何从运行

DBMS_BACKUP_RESTORE.DBMS_BACKUP_RESTORE用于特殊情况下的恢复 一般如下:系统崩溃,rman使用控制文件,没有使用控制文件自动备份,现在仅有最后一次全备(备份中包括控制文件),以及其增量备份,规档备份.通常这种情况下不能使用常规RMAN来恢复，因为此全备份中备份的控制文件中没有包含本次的备份信息，rman使用控制文件备份的时候是先备份控制文件后备份其它信息背景知识在Oracle 816 以后的版本中,Oracle提供了一个包:DBMS_BACKUP_RESTORE.DBMS_BACKUP_RESTORE 包是由dbmsbkrs.sql 和 prvtbkrs.plb 这两个脚本创建的.catproc.sql 脚本运行

1 ) Error 980 during db open is causing the shut down of the database2 ) Need to create the Dual Table to resolve the issue (which was not possible in the mount stage)Workaround=========3 ) Set the following parameter in the init.orareplication_dependency_tracking = FALSE4 ) Startup the database5 ) Create the Dual Table and Dual Public SynonymCREATE TABLE "SYS"."DUAL"( "DUMMY" VARCHAR2(1)) PCTFREE 10 PCTUSED 4;Insert Into Dual Values ('X');Commit;Grant Select On Dua

为了保持其最强大和最灵活数据库的地位，Oracle在最近 发布的几个版本里一直都在创建新的机制来对表格和索引的存储进行简化和分块。从Oracle8i开始，Oracle开始在tablespace内部将对象 管理进行自动化。第一个增强的地方原来叫做本地管理tablespace（或者简写作LMT）。在LMT里，Oracle将tablespace里的信息 从数据字典的表格空间里移出去，而直接将其保存到tablespace自身里。这在Oracle9i里已经成为了一个事实的标准，因为它减轻了数据字典的 负担。 表格空间的第二个主要增强的是自动分段空间管理（ASSM），它首次出现在Oracle9i里。