Maclean’s Oracle Database Tech Blog Archives

前几日，有客户报一个备用库实例中有多个回话hang住的问题，在hang住前本地有维护人员执行了truncate表的操作。 同事前往客户现场进一步确认了问题，并传回了当时hang状况下的266级systemstate文件。该实例的并发回话数量较少，所以实例状态抓取后总的信息量并不多，这种情形中通过分析systemstate信息往往要好于分析hanganalyze信息。 通过著名的源自于metalink的ass awk脚本可以很快找出各进程的状态，以及重要资源的持有者： awk -f ass109.awk systemstate.txt Starting Systemstate 1 ………………………………….. Ass.Awk Version 1.0.9 – Processing systemstate.txt System State 1 ~~~~~~~~~~~~~~~~ 1: 2: last wait for ‘pmon timer’ 3: waiting for ‘rdbms ipc message’ wait 4: waiting for ‘rdbms ipc message’ wait 5: waiting for ‘latch: cache buffers chains'[Latch 70000048c8c66b0] wait DBW0 6: waiting…

We are planning to implement 11gR2 RAC on OCFS2 file system. We are going to have ocr files,voting disk files,database files and flash recovery area files on OCFS2 file system. Generic Note ———————— ocfs2 is certified for oracle 11gr2 but oracle recommends using asm. please see this for more information http://download.oracle.com/docs/cd/E11882_01/install.112/e10812/storage.htm#CWLIN262 3.1.3 Supported Storage Options…

9i 中v$session_wait 是Oracle wait interface的一个主要用户接口，而该动态视图的内容来源于x$ksusecst内部视图： SQL> select view_definition from v$fixed_view_definition where view_name=’GV$SESSION_WAIT’; VIEW_DEFINITION ——————————————————————————– select s.inst_id,s.indx,s.ksussseq,e.kslednam, e.ksledp1,s.ksussp1,s.ksussp1r,e. ksledp2, s.ksussp2,s.ksussp2r,e.ksledp3,s.ksussp3,s.ksussp3r, decode(s.ksusstim, 0,0,-1,-1,-2,-2, decode(round(s.ksusstim/10000),0,-1,round(s.ksusstim/10000))) , s.ksusewtm, decode(s.ksusstim, 0, ‘WAITING’, -2, ‘WAITED UNKNOWN TIME’, -1, ‘ WAITED SHORT TIME’, ‘WAITED KNOWN TIME’) from x$ksusecst s, x$ksled e where bit and(s.ksspaflg,1)!=0 and bitand(s.ksuseflg,1)!=0 and s.ksussseq!=0 and s.ksussop c=e.indx SQL>…

Question #1: ========== _optimizer_cost_based_transformation=false Currently set to false, should we keep or remove it for 11g upgrade? It is a workarond for several bugs, including ORA-600 bug 6666870 fixed only in 11,2? ANSWER ======= _OPTIMIZER_COST_BASED_TRANSFORMATION controls whether or not the optimizer tries different transformations against a query using the cost with and without the transformations…

_optimizer_adaptive_cursor_sharing=false disables the feature. There are 2 new columns in V$sql , IS_BIND_SENSITIVE and IS_BIND_AWARE that indicate the status for individual cursors. 1.) The parameter “_optimizer_adaptive_cursor_sharing” can be changed “on the fly”. This means if you issue an ‘alter system set “_optimizer_adaptive_cursor_sharing” = false |true; ‘ will be reflected in any existing session. Remember, to…

Found that background process of diag is occupied high pga memory usage in RAC of node 1. Value of PGA memory usage is captured by “select sid, name, value from v$statname n, v$sesstat s where n.statistic# = s.statistic# and n.name like ‘%memory%’ and s.sid=481order by sid;” Why occuried high pga memory usage of background process…

On : 10.2.0.1 version, Real Application Cluster When attempting to start gsd resource. the following error occurs. ERROR ———————– Auto-start failed for the CRS resource . Trac the issue with note: Tracing GSD, SRVCTL, GSDCTL, VIPCA and SRVCONFIG (Doc ID 178683.1) Tracing GSD, SRVCTL, GSDCTL, VIPCA and SRVCONFIG PURPOSE ——- The Purpose of this document…

几个月前，在客户的一次演练测试中，一位乙方项目组的经理指出：在RAC环境中使用lsnrctl命令关闭监听，Oracle CRS会自动将该监听重启。客户对他的这个说法十分重视，同时向我咨询，CRS确实会定期对所有资源进行检查，并可能重新启动以外终止的资源；但手动使用lsnrctl关闭监听绝对不能算在以外终止的范畴当中。这位乙方的项目经理年纪已界中年，项目经验十分丰富，而且说起这个问题来信誓旦旦(十分反感这样的自信),不由得别人不信；当时我向客户具体介绍了CRS重启资源的原理，并阐述了我认为“不会重启”的观点，因为不能排除一些意外因素(我认识的Oracle总是带来惊喜),我的口气并不如乙方项目经理那么肯定，客户负责人也只有将信将疑，并认为可以实际测试一下。 当时的测试记录没有保留，我们来看一下RHEL 5.5上Oracle RAC 10.2.0.5版本中的表现(实际与AIX上10.2.0.4的表现一致): [maclean@rh2 ~]$ crs_stat -t Name Type Target State Host ———————————————————— ora…..S13.cs application ONLINE ONLINE rh2 ora….db1.srv application ONLINE ONLINE rh2 ora.racdb.db application ONLINE ONLINE rh1 ora….b1.inst application ONLINE ONLINE rh2 ora….b2.inst application ONLINE ONLINE rh1 ora….SM2.asm application ONLINE ONLINE rh1 ora….H1.lsnr application ONLINE ONLINE rh1 ora.rh1.gsd application ONLINE ONLINE…

Instance 1: Start dump data blocks tsn: 0 file#:1 minblk 95753 maxblk 95753 Block dump from cache: Dump of buffer cache at level 4 for tsn=0, rdba=4290057 BH (0x8df55108) file#: 1 rdba: 0x00417609 (1/95753) class: 1 ba: 0x8dc86000 set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 58,28 dbwrid: 0 obj: 84318 objn:…

6月11日5点天刚蒙蒙亮，极不自然地醒过来，因为要赶飞机的缘故又是一夜没睡好；从家中打车到浦东机场需用一个多小时，抵达时已经6点半了，我要搭乘7点50分的飞机，自上海出发到西安转机到青海西宁。这次是公司在开拓青海省期间的一次技术交流，对象是西宁市的一家政府下属单位。 早晨的浦东机场已经十分忙碌，考虑到是世博期间人流更胜往常；这里是大魔都一处永不停歇的驿站，在这里人流喷涌，为这个国家带来所有未知机遇。 一行无话，11点40分抵达西安，西安的机场还是挺大的，至少在西部诸省仍是佼佼者；我一直很向往这个古老城市：秦，两汉，唐;这个城市记录了中华最辉煌的年代，在我心目中这种气度不是帝都所能比的，不过这次是无缘游访了。 1点钟不到终于到达目的地，青海省西宁市这个边陲省会；从机场向外看去一望无际的土山让生长在上海没有出过远门的我有些惊讶，西宁机场不大，虽然离地震已经过去一段时间了但仍到处插着”青海长青，玉树不倒”的标语，西宁机场目下正在扩建，灾后重建需要一个现代化的机场。 落地后赶忙和负责西北地区的张，胡两位取得了联系，他们下榻在中心广场的如家，据说是此地的市中心，而自机场打的到市区则似乎是统一的一百元；西宁市的的士规格参差不齐，但车顶上大大的广告牌似乎要比上海的还要先进，部分的士甚至是私家的车子，起步费统一的6元；上车前最好问清楚是否能给发票，不然可能会很麻烦。 载我的那位的哥十分健谈，据他介绍青海自古是移民地区，目前是以汉族为主，而部分口音类似于南京周边的方言。青海亦是三江源头为长江，黄河，澜沧江的源头汇水区，比较好玩的景区有青海湖和贵德，土产有牦牛干，人参果，裸鲤，毛毯等。谈话中时间过得飞快，期间途遇到2个收费站，让我对外地的路费有了新的认识。进入城区后先上到高架，大致可以一览市区全貌，据司机师傅介绍目前西宁市区的房价是在6千左右，要想在此处安家却也不容易啊！ 在城区里穿行片刻就抵达了旅馆，与本地的2位从未谋面的同事寒暄过后，自然是要先祭祭五脏的；他们带我去旅馆旁边一个样式古老的美食城就餐，西北向来以面食出名，古来就说西北的水偏碱做面食十分相宜，其名声远胜南方，此外就多是牛羊肉，大盘鸡之属了。牛羊肉做主食，南方人多半受不了，我点了一叠面，口味尚佳，比起上海六七元的阳春面这里要便宜得多了。 吃完饭匆匆赶赴客户单位，路上竟堵了许久，想不到此处下午1点多也会有rush hour。 来到客户单位已是2点多，从客户的张科长，朱工程师口中大致了解了系统规模，这里主用的一套Linux上的RAC系统共有3个节点，硬件是三台Dell的3950 Pc Server以及一台IBM DS4700存储，三个实例接受不同地区的业务，客户目前对这套RAC系统的性能不顶满意，希望此次技术交流能够提出初步的方案，另外他们对与主机上较高的内存使用率表示疑问。 我首先抓取了RDA以及AWR报告，托福于这些工具Oracle的诊断调优信息收集已经十分集成了。这个系统居然还采用了ASM,Linux上RAC系统大致可以采取以下几种存储管理方式:裸设备(最容易也最麻烦),NFS(生产环境无法用),ASM(Oracle 推荐),OCFS2(11g被抛弃了),其他GPFS(譬如RedHat GPFS,Veritas Cluster Filesystem);10g下最时髦的管理方式还属ASM,ASM技术新颖，但普遍认为10gASM还不够成熟，至少客户应用上经验不足，一旦出现问题，除了向Oracle GCS求助外很少能找到其他解决方法。而且这套ASM系统直接使用形如/dev/sd*的块设备作为disk，不同于裸设备，使用块设备将会引起操作系统对块的进一步缓存(OS CACHE)，这套系统除了跑数据库外没有其他应用，总内存为24g而每个实例使用的SGA不足5g,绝大多数内存都用作了缓存块设备。 [oracle@qhds2 ~]$ free total       used       free     shared    buffers     cached Mem:      16408324   16276472    131852          0      44184   13969312 -/+ buffers/cache:    2262976      14145348 Swap:      2031608      90224    1941384 如上所示空闲物理内存131852即128M,OS cache为13G。Oracle使用的高速缓存(Buffer_Cache)要较OS的cache更为有效，而目前三个实例设置的Buffer_cache为2-3G不等，建议客户调大Buffer_Cache至5-10G，同时为杜绝操作系统因物理内存不足，瞬间换页造成宕机事件发生的可能性，建议客户将Linux内核参数vm.min_free_kbytes 设置为512000(即总是保留500M的空闲物理内存)。 数据库中三个实例，整体负载(Load)处于较低的水平。相对而言1号实例最高,16小时快照内1号实例上Average Active Session（平均活动会话数，为10g中数据库负载的重要指标）为(AAS=DB_TIME/Elapsed=2327/960)2.42；2号实例上AAS为592/960=0.61；3号上AAS为1405/960=1.463。 分析AWR 报告可以发现： 1号实例: Event Waits…