-
编辑 删除
深入理解shared pool共享池之library cache的library cache pin系列三
背景 关于library cache相关的LATCH非常多，名称差不多，我相信一些人对这些概念还是有些晕，我之前也有些晕，希望此文可以对这些概念有个更为清晰的理解，本文主要学习library cache pin前期相关文章http://blog.itpub.net/9240380/结论1,library cache pin是用于并发的一种特殊锁，它不是LATCH2...
-
编辑 删除
深入理解shared pool共享池之library cache系列二
背景 继续上文：深入理解shared pool共享池之library cache系列一，http://blog.itpub.net/9240380/viewspace-1844964/，学习library cache数据结构，本文主要学习library cache object(lco)的数据结构：data blocks为了直观理解，先放一张网上关于DATA BLOCK中存储不同HEAP的结构图： &...
-
编辑 删除
深入理解shared pool共享池之library cache系列一
背景 为了更为直观理解library cache,贴2张相关图，如下：结论1,oradebug dump library_cache不同级别dump的library cache内容及粒度会有所区别，具体见测试开始部分2,本文测示基于oradebug dump library_cache 32，即产生最为详细的library cachem内容，进而分析library cache数据结构3,...
-
编辑 删除
由修改cpu_count参数parameter引发一点小故事
结论1，ORACLE参数调整大致分为几类：2, 某些参数可以调整为指定的值3, 某些参数即使调整为指定的值，ORACLE仍会基于复杂的内部算法，对进进行降级处理，即调整的值和指定的值有一定的差异4，某些参数不能调整，一调整即会直接报错5，某些参数不能调整，虽然调囊可以成功，但调整后仍是原来的值6，还有一些其它的...
-
编辑 删除
基于参数shared_pool_reserved_size进一步理解共享池shared pool原理
结论1,与共享池相关的参数为:shared_pool_size,shared_pool_reserved_size,_shared_pool_reserved_pct _shared_pool_reserved_min_alloc2,shared_pool_reserved_size一般默认是shared_pool_size的5%，这个比例由参数_shared_pool_reserved_pct控制3,_shared_pool_reserved_min_alloc控制保留池中最小的分配大...
-
编辑 删除
基于oracle 10.2.0.5演进到oracle 11.2.0.1 分析x$kqfta表所想到的一些事儿
结论1,x$表是对应ORACLE内核层不同的层，比如：X$KSMSP即对应ORACLE内核层：KS 即KERNAL SERVER内核服务层2,ORACLE内核层的含义，请参考下述测试之 oracle内核层 相关内容3,X$KSTFA即存储X$所有表，且共计604个X$表4,基于ORACLE内核层，可以大致猜测X$不同表的含义，然后进行对应测试与理解，我认为这是...
-
编辑 删除
深入理解shared pool共享池空间及library cache分配之ora-4031 系列一
结论1,可以通过x$ksmsp分析共享池chunk的分配回收情况，深入分析ora-4031错误的原因2,x$ksmsp的列ksmchcls为chunk的类型，共计6个值，具体如下：KSMCHCLS--------R-freeR-freeafreefreeablpermrecr6 rows selected.3，关于上述ksmchcls列的不同含义，见下：free：这种类型的chunk不包含有效的对象，...
-
编辑 删除
分析为何oracle 10.2.0.5只会获取child#=1的shared pool latch之系列六
结论1,可以用oradebug dump heapdump 3转储共享池的结构信息 这个级别一般3即可，6的代价有些大了2,语法如下： SQL> oradebug setmypidStatement processed.SQL> oradebug dump heapdump 3Statement processed.SQL> oradebug tracefile_name/home/ora10g/admin/ora10g/udump/ora10g_ora_653...
-
编辑 删除
在oracle 10.2.0.5分析硬解析及软解析及软软解析获取shared pool latch机制系列五
结论1,测试环境是oracle 10.2.0.52,_kghdsidx_count=1，即共享池子池个数是1个3,硬解析需要获取shared pool latch4,软解析需要获取shared pool latch5,软软解析不需要获取shared pool latch6,上次各类解析皆要获取library cache latch7,上述各类解析要获取的shared pool latch是child#=1,即第1个子latch ...
-
编辑 删除
学习oracle 10.2.0.1 rac集群进程cssd的原理及机制之系列一
结论1,cssd进程访问表决磁盘2,如果RAC节点间私网通讯出现故障，不是马上会导致RAC节点驱逐，有个时间间隔，大约为1分钟 由CSSD的日志看出 [ CSSD]2015-11-19 03:13:19.281 [1205823808] >TRACE: clssnmPollingThread: node jingfa2 (2) missed(2) checkin(s)[ ...
-
编辑 删除
基于oracle 10.2.0.1 rac学习lmon进程系列六之增补一
背景 本文是文章:基于oracle 10.2.0.1 rac学习lmon进程系列六 :http://blog.itpub.net/9240380/viewspace-1839875/的 延续，我们继续深入理解lmon进程的一些原理及含义，好我们进入正题。结论1,如果rac中某个节点的lmon出现故障，并且其它节点关闭实例，会产生IPT TIMEPUT 而且如...
-
编辑 删除
基于oracle 10.2.0.1 rac学习lmon进程系列六
结论1,经目前的测试，lmon仅在RAC节点关闭及重启，才会发挥其巨大作用2,lmon进程如何工作，需要分析lmon的trc文件3,lmon trc文件里面的内容非常多，也很复杂，要在另一文章中进行分析与测试4,可以基于bdump进行基于时间排序，也就是说基于最新时间进行比对，就知道你一个测试操作，到底与哪些后台进程有关系了 ...
-
编辑 删除
oracle 用户user锁定lock如何知道是什么原因导致的
问题数据库用户被锁了，如何查看什么原因导致被锁的呢结论1,dba_users是由底层表user$,profile$,profname$相关表构成，当然还有ts$2,dba_users与账户锁定或过期相关的列有：created,account_status,lock_date,expiry_date,profile3,具体如何分析到底是dba_profiles中的哪个参数为用户锁定的原因，要结合上述这...
-
编辑 删除
由oradebug poke process allocation latch引发dfs lock handle等待事件进一步分析
结论1,阻塞process allocation latch,数据库会出现latch free及dfs lock handle2,dfs lock handle通过systemstate dump找不到有价值的信息 却可通过v$session的p1,p2,p3找到有价值的信息3,因为dfs lock handle的p1,p2,p3含义不知，只能借助于mos,找到文章：Understanding 'DFS Lock Handle' and Cross-Instanc...
-
编辑 删除
基于oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列六
结论1,为了模拟db hang,尝试oradebug suspend ckpt,dbwr,smon,lmd无果，可见对于后台进程还要继续深入研究2,oradebug suspend process allcation latch,模拟出会话无法登陆3,从目前测试看，普通的等待事件，仍在other chains中，仅为latch或mutex方会在open chains中出现4,latch free诊断，通过v$session.p1或p2定位...
-
编辑 删除
由研究oracle rac lms进程引发10708 event及oradebug dump buffer
结论1,对于报错的分析，可见猜测能力非常重要，联想能力极为重要 这个非常重要，如果理解报错，直接决定你分析思路，最终要花多久时间解决问题2,oradebug用法还是理解不深3,oradebug dump buffer 后面的数字，不是字面的级别，而是缓冲区中数据块的地址即rdba4,rdba可以基于测试表dbms_rowid,然后dump ...
-
编辑 删除
基于oracle 10.2.0.1 rac学习lms进程系列四
背景 之前，我们了解了lmd进程一些概念，这儿我们学习下另一个重要RAC后台进程，LMS进程。结论1,如果lms出现故障，会导致dml事务无法提交，即提交或回退hang住;并且远端节点的DML操作会HANG住2,lms进程的等待事件和lmd进程的相似，是gcs remote message 引申，即和远端节点的LMS进程进行通...
-
编辑 删除
从v$sysstat的指标ges messages sent理解oracle 10.2.0.1 rac lmd进程系列三
结论1,如果节点间的DML操作非常频繁，会在节点间产生大量的GES信息传递2,ges messages sent可以评估RAC节点的DML操作或通讯是否频繁，如果此值小，说明RAC数据库并不繁忙3,lmd进程是负责发送ges message到远端的RAC节点4,如果用oradebug suspend lmd,会导致远端RAC节点的insert操作受阻，可见lmd进程就是管理全局锁...
-
编辑 删除
用strace跟踪分析oracle 10.2.0.1 rac lmd进程系列二
结论：1,strace -p跟踪lmd进程，是和fd为9及17的2个socket进行通讯2,这2个socket为 9为socket:[1361566]，而17为socket:[1361581]3，strace的应用关键在于有针性性理解操作系统的函数，比如times,getrusage,poll的含义是什么，你就明白了lmd进程到底在作什么4, find .|xargs grep -ri "2015-11-1...
-
编辑 删除
oracle 10.2.0.1 rac发现sql查询hang之gc cr request
背景： 在学习oracle 10.2.0.1 rac时，发现RAC出现明显的GC CR REQUEST事件，导致select查询hang住，分析处理如下：分析处理：含义： 本地节点需要一致性读的UNDO数据不在本地节点，需要到远端节点获取，等待返回的过程。先用下述SQL，查查本地节点一致性数据块获取的平均时间s...
