library cache pin,library cache lock和library cache load lock
具体见METALINK NOTE:444560.1 [@more@]在library cache中,对象以handle和object heap的方式存储1、library cache lock通过在handle上加锁的方式控制进程对对象的并行访问,主要是对对象的PARSE和编译,该锁是死锁检测敏感的Parameters:handle address Address of the object being loaded. lock address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is a State Object. mode Indicates the data pieces of the object which need to be loaded. 2、library cache pin该事件是用来管
等待事件Cursor: Pin S Wait On X和Library Cache Load Locks可能意味着过度的内存调整
METALINK NOTE:731233.1相关验证语句为:SQL> select to_char(start_time ,'mm/dd/yyyy hh24'),count(*) from v$sga_resize_ops group by to_char(start_time ,'mm/dd/yyyy hh24');最近,单位数据库曾出现过CPU利用率100%的现象,大量会话无法及时完成,经查上面这两个等待事件非常突出,而且故障期间内存调整次数几乎为正常时候的20~50倍。过量的内存调整导致了CPU的高度消耗?内存调整到底是原因还是结果?这里暂且存疑。[@more@]
AIX中TOPAS命令详解
Topas命令可以监控系统活动――memory,I/O,paging space,cpu,process。此命令包含在perfagent.tools文件集里面。下文将对该命令进行详细介绍:[@more@]命令使用方法:topas [ -d number_of_monitored_hot_disks ] [ -h ] [ -i monitoring_interval_in_seconds ] [ -n number_of_monitored_hot_network_interfaces][ -p number_of_monitored_hot_processes ] [ -w number_of_monitored_hot_WLMclasses ] [ -c number_of_monitored_hot_CPUs ] [ -P | -W ]参数:-d:指定要监控的磁盘数。如果屏幕显示的区域足够大的话,这也是磁盘可显示
ORA-02069
最近遇到一个ORA-02069的错误,这里记录下,见METALINK note 1047673.6[@more@]
在aix oracle rac 环境下,增加lv的步骤
1.停掉数据库2.停掉hacmp3.在一台机上增加lv4.另外一台机上importvg5.然后在原来那台机上同步(smitty hacmp)6.起hacmp,crs7.起数据库[@more@]
HP下对进程的跟踪
最近有同事遇到执行srvctl命令hang的问题,METALINK上给出了进行跟踪诊断的方法,这里记载一下学习OS: HP UX 11.11DB:10.2.0.3 RAC[@more@]1)tusc -aef -o /tmp/srvctl <run srvctl command>upload /tmp/srvctl---tusc为HP提供的跟踪进程的工具,参考http://h20331.www2.hp.com/hpsub/cache/286022-0-0-225-121.html2)set SRVM_TRACE=truescript /tmp/srvctl_srvm<srvctl command>upload /tmp/srvctl_srvm3)upload crsd,cssd logs 4)Run oswatcher and upload oswatcher logs also---oswatcher:Oracle OS watcher (OSWatcher
自作自受,很好的一个成语!
纵观人的一生,无论悲剧还是喜剧、幸福还是痛苦,基本上都是自作自受![@more@]
责任、尊严和荣誉
美国西点军校的校训是责任、荣誉、国家,我一直觉得这六个字准确浓缩了军人的终极目标。作为一个普通人,我想我们的终极目标是责任、尊严和荣誉。生活中总是有各种各样的遗憾的,男人不能纠缠在这些遗憾中不能自拔。与我们的崇高的目标相比,一切都是渺小的!让我们骄傲地活着去创造完美的成功!即使失败,也让失败来得酣畅淋漓。[@more@]
10G新特性笔记之AWR,ASH,METRIC,ALERT&ADVISOR
这里对10G的AWR,ASH,METRIC,ALERT&ADVISOR进行下总结[@more@]1、AWR架构包含两个部分,一个是in-memory statistics,存放在内存中,一个是persistent portion2、AWR中存放下面的统计信息:Object statistics,new SQL statistics,The new wait classes interface,The new time-model statistics,V$SYSSTAT and V$SESSTAT,Oracle optimizer statistics,Operating system statistics,Active Session History,Metrics3、ASH中包含最近会话的活动信息,系统每秒对v$session进行抽样,放在SGA中的ASH区,该ASH区采用的是循环使用的机
10G新特性笔记之自动管理
10G的自动管理功能包含ADDM、自动共享内存管理、自动统计信息收集、自动undo retention调整、自动checkpoint调整[@more@]1、ADDM相关进程为MMONADDM默认情况下是起用了的。通常数据库默认情况下每小时会从SGA中抓取统计信息存储在AWR(Automatic Workload Repository)中,每次SNAPSHOT被收集,ADDM被启动对最近的两个SNAPSHOT进行分析。为了让ADDM自动工作,必须设置STATISTICS_LEVEL为typical或者all.ADDM对IO性能的分析倚赖于IO子系统的速度,该速度ORACLE默认为10,000 microseconds,可以手工设置DBIO_EXPECTED的值,具体方式为:SQL&
/etc/hosts文件不可读导致10.2.0.3数据库不能起来
今天客户数据库无法启动,即使是启动到nomount状态,错误信息是:ORA-600 [keltnfy-ldminit][@more@]经查是ORACLE BUG# 5486074:OERI [keltnfy-ldminit] when DNS is not available让/etc/hosts文件可访问后一切正常。
关于错误ora-00064
今天在给用户设置db_keep_cache_size为80G时,数据库无法启动,错误信息为:ORA-00064: object is too large to allocate on this O/S (1,16777216)[@more@]查找相关ORACLE文档,解决方案是:设置隐含参数_ksmg_granule_size=67108864通常对于SGA大于128M的数据库,每个granule的大小是16M,这里是把它设置成了64M了。个人认为出现上面错误的原因是80G对于16M的granule太大,即granule数太多,因此增大granule的大小进而减小granule数。
遭遇BUG 4483368出现ORA-19693错误后的处理办法
客户数据库通过手工脚本实现DATAGUARD,即通过将生产库归档日志定时备份、恢复到备库的方式实现。然而今天却出现了恢复不成功的问题:[@more@]错误信息:RMAN-00571: ====================================RMAN-00569: ====== ERROR MESSAGE STACK FOLLOWS ======RMAN-00571: ====================================RMAN-03002: failure of recover command at 05/23/2008 09:38:48ORA-19693: backup piece /opt/oracle/admin/mnt_new/HERMES_NEW/2008-05-23.00-00-01/jrjh24rf_1_1 already included通过list backupset of archivelog all;
关于ORA-01555
工作中经常会遇到错误ORA-01555,结合工作中的经验,参考几篇ORACLE文档,下面进行一下总结。[@more@]一、ORA-01555错误发生的两个原因原因之一是回滚段太小、回滚段数目少导致回滚段中的相关数据块被overwritten原因之二是延迟块清除如果一个会话对某个表进行了大量更新,oracle并不是马上去回写数据块并清除块的事务信息,而是在下次访问这些块的时候进行这些操作。这样事务信息在延迟清除之前的状态是:在数据块头有未提交事务的相关回滚段、事务槽的信息,而对应回滚段头对应事务槽的状态为committed,当下一次数据块被访问到的时候,
PMON与library cache latch
曾经有个客户数据库出现问题,警告日志文件显示:PMON FAILED TO ACQUIRE LATCH,而TRACE文件中显示PMON在等待某个library cache latch。当时有点疑问:PMON用于清理进程资源或者重新启动DEAD DISPATCHER进程,为什么要获取library cache latch?关于这个问题,METALINK上的答复是:Simply when Pmon cleans up the held resources it has to aquire latches in Library cache to clear that resources. It gets the library cache latch to get the right hash bucket and then knows the exact status of the resource to take the right
汶川地震之殇
2008年注定是个不安定的年份:年初大雪、西藏骚乱、山东火车相撞、手足口病、汶川地震,也许未来还会有很多的类似事件发生。天灾人祸本就不是我们能控制的,可是我们却看到,全国人民因这些事件团结了起来。中国,注定要在苦难中成长![@more@]
RAC环境下死锁的问题
RAC环境下系统检测死锁的时间间隔由隐含参数_lm_dd_interval决定,缺省值是1分钟,这与单实例数据库是不同的。[@more@]
死锁问题总结
工作中经常会碰到一些ORA-00060的错误,这里给个总结:[@more@]1、如何解读相关TRACE文件a.Current SQL statement for this session指的是接收到ORA-00060错误的会话正在执行的语句,该语句接收到错误后被回滚b.对于TX模式的X锁,下面的信息说明session 10在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID'AAAAv2AAEAAAAqKAAB',session 11在等待object_id为3062的对象(to_number('BF6','XXXXXX')=3062)的ROWID 'AAAAv2AAEAAAAqKAAA'Rows waited on:Session 10: obj - rowid = 00000BF6 - AAAAv2AAEAAAAqKAABSession
SHARED POOL总结
本文试图对shared pool的内部机制做一个总结,目的是加强对相关内容的了解。shared pool内存的几个特征:a.以CHUNK为单位,CHUNK大小不等,每个chunk跟x$ksmsp中每条记录有一一对应关系b.当会话结束,相关内存空间并不全部释放,因为无法预知这些信息会不会被后来的会话用到c.不能被PAGE OUT到系统的磁盘交换区,AGE OUT的是一些可重建的信息 [@more@]1、shared pool内存结构及内存分配方式shared pool 包含dictionary & sql区、保留区、永久区保留区存储大对象,大小由shared_pool_reserved_size决定,缺省为shared pool大小的5%,当
呵呵,网上看到这样一段话,说得挺好!
为什么要言论自由? 世界公认的原因有三个:一、任何见解都有可能是正确的,所以某些人要压制任何一个论点的时候都存在可能性把真理压制了。二、所有论点多少都包含了一些对的错的东西,有合理的也有不合理的话,如果压制一种见解的话,就把其中合理的部分一并压制了。三、即使某种见解我们可以确认它是大错特错的,没有任何一点对的地方——虽然这是不可能的,但我们姑且相信这样极端的例子——即使是这样也有其存在的价值。因为它有助于我们分辨正确的见解,有助于我们去澄清正确的见解究竟是什么,以防正确的见解养尊处优失去了生命力和战