现在使用ASM的用户越来越多了，而ASM最不方便的就是所有的文件都在oracle自己管理的系统里。我们碰到需要将某个文件拷贝出来的时候就比较麻烦，可能要依赖于RMAN，今天客户突然有个需求要拷贝REDO LOG出来，后来查了METALINK，发现有个方法可以用：create or replace directory SOURCE_DIR as '+DATADG/sfoss/onlinelog/';create or replace directory ORACLE_DEST as '/tmp/oralog/dest';BEGINdbms_file_transfer.copy_file(source_directory_object =>'SOURCE_DIR', source_file_name => 'group_1.257.695065683',destination_directory_object => 'ORACLE_DEST',destination_file_name => 'redo_1.log');END;/试了一下，确实不错，这样今后就不怕从ASM里拷贝任何文件出来了

点击此处查看原文

我和秦工说，如果在单机环境下，加大DB CACHE的效果可能没有这么好，不过在RAC环境下，我们这回做的几个调整，是相当重要的。通过加大DB CACHE减少了GLOBAL CACHE方面的消息数量，从而大幅度提高了gcs方面的性能。通过加大sequence的cache，大幅度减少了dc_segments带来的row cache object等待，通过加大SHARED POOL，提高了LIBRARY CACHE的性能，通过设置instance_groups限制了并行查询的范围。这些措施对于提高RAC系统的性能都是十分有帮助的。第二次模拟测试完成了，我们咨询了几个参与测试的人员，他们在第一次测试的后期感觉了系统有点变慢的迹象，特别是有一段几分钟的时间，系统变得十分缓慢。而第二次测试一直比较平稳，感觉系统速度明显比第一次快一些，而且没有再次出现第一次那种有几分钟特别慢的现象。从最终客户的感受上我们也能看出来优化的效果。第一次测试人员感觉特别慢的几分钟就是由于audseq$引起的性能问题爆发的时候，我们将这个SEQUENCE的CACHE参数加大为5000后，这个问题就没有再次出现了。这次测试顺利完成了，秦工心里也感到踏实了很多

点击此处查看原文

1.1.1. 后记在本章中，老白实际上介绍了3个案例，大家可能觉得有点乱，不知道老白需要表达些什么意思。实际上老白在本章主要向大家介绍一个工作方法。在这里，老白想问大家一个问题：DBA做故障处理的时候，最重要的是什么？可能有些朋友会说，做故障处理最重要的是技术。实际上我们所学习的技术都是大同小异的，可能某些人学的多一些，有些人学的少一些。一般性的问题，绝大多数DBA平时学习的技术都能够处理了，不过我们总是会碰到一些从来没有碰到过的故障，在这种情况下，有些人会处理的很好，有些人就感觉无从入手，是不是这样呢？难道真是技术决定了故障处理的成败吗？答案肯定是否定的，技术是故障处理中确实能够起到一定的作用，不过绝对不是决定性的作用。实际上现在很多DBA的理论基础和技术都很不错，在很多技术细节方面，要比老白强得多，不过老白很自信，如果大家一起去处理同一个问题，可能老白的成算更大一些，这是为什么呢？还是那句话：没有技术是不行的，只有技术还是不够的。

点击此处查看原文

1.1.1. 8月9日 求人不如求自己昨天下午由于时间很紧张，所以只分析了4031的问题，而那个ORA-600问题还没来得及处理。昨晚本来想分析分析，后来又被几个广州的朋友拖去喝酒，回来后头昏昏沉沉的，连澡都没洗就睡了。今天早上醒的很早，我一喝酒睡眠就不好。在床上又躺了一会实在睡不着了，就起床了，看看手机才6点半。起床后想起了昨天下午我更新的那个TAR，不知道是不是有回复了。登上METALINK，发现那个叫Diwakar印度人还是很执着的要求我提供RDA的数据以及LMON的TRACE。实际上我昨天下午已经把所有的TRACE文件都发送给了他，不过我们就一直没有找到宕机前的LMON的TRACE文件，Diwakar认为由于缺少了lmon的TRACE，影响了他的分析，因此他暂时无法给出任何建议。看样子这个Diwakar事指望不上了，印度人的死板我是领教过的，由于lmon日志的缺少，这个哥们真的可能不做进一步的分析了。

点击此处查看原文

1.1. 好的方法是成功的一半1.1.1. 8月8日 又宕机了今天是8月8日，广东人眼中的好日子，不过今天一早起床我的右眼就跳个不停。按照东北的说法，左眼跳财右眼跳祸。难道今天又要碰到什么麻烦事。到了公司以后首先收了一下邮件，还好没什么紧急事件。打开MSN和QQ后也没有什么异常，看样子是我多心了。中午吃饭的时候，老储也说今天早上眼睛跳，我问他是左眼还是右眼，老储说记不起来了，好像是右眼。最近这段时间我和老储都比较忙，很少有机会在一起吃饭，就在一起聊了聊最近的项目。老储最近也碰到了几个比较棘手的问题，一个事一家券商的系统，白天营业的时候经常出现所有的在线日志都是处于active状态，经过观察发现是由于CHECKPOINT没有完成导致的，但是这个系统的负载也不是十分高，

点击此处查看原文

1.1.1. 8月6日 extent pre-allocation 昨天处理了那张变态的表后，系统性能提升十分明显，今天早上我快10点才到客户的现场。9点-10点是这些天业务比较集中的时段，这个时候系统负载最大，我采集了一个9点到10点的STATSPACK报告。报告中的TOP EVENT和昨天下午调整后差不多：Top 5 Timed Events

点击此处查看原文

有个客户的系统中某个模块突然变得十分慢，以前每小时处理1万笔业务，今天每小时只能处理1000笔业务。大量的业务堆积，使客户感到十分头痛。从V$SESSION_WAIT看，存在大量的LATCH FREE等待，从STATSPACK报告上看：Load Profile~~~~~~~~~~~~ Per Second Per Transaction--------------- ---------------Redo size: 606,513.75 10,096.93Logical reads: 263,689.83 4,389.77Block changes: 3,438.74 57.25Physical reads: 817.62 13.61Physical writes: 319.30 5.32User calls: 9,289.06 154.64Parses: 2,764.50 46.02Hard parses: 334.28 5.56Sorts: 1,460.77 24.32Logons: 3.53 0.06Executes: 2,808.80 46.76Transactions: 60.07Instance Efficiency Percentages (Target 100%)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Buffer Nowait %: 97.29 Redo NoWait %: 100.00Buffer Hit %: 99.75 In-memory Sort %: 100.00Library Hit %: 93.44 Soft Parse %: 87.91Execute to Parse %: 1.58 Latch Hit %: 88.50Parse CPU to Parse Elapsd %: 74.96 % Non-Parse CPU: 88.71Top 5 Timed Events~~~~~~~~~~~~~~~~~~ % TotalEvent Waits Time (s) Ela Time-------------------------------------------- ------------ ----------- --------latch free 44,261,551 122,352 46.29CPU time 44,436 16.81buffer busy global CR 24,549,325 29,212 11.05db file sequential read 2,298,542 23,234 8.79wait list latch free 810,305 17,562 6.64-------------------------------------------------------------LATCH FREE等待占了46.29%。经过检查，发现是ROW CACHE OBJECTS等待十分严重。初步怀疑在某张表上，客户在前一天晚上对这张表做了一些修改。询问应用开发部门，他们都不承认做了操作。从数据库上看，并没有多大的问题。通过HANGANALYZE看：存在大量的HANG住现象：Found 26 objects waiting for <cnode/sid/sess_srno/proc_ptr/ospid/wait_event><1/270/2196/0x47a8100/1259/No Wait>Found 10 objects waiting for <cnode/sid/sess_srno/proc_ptr/ospid/wait_event><1/1238/35370/0x4784820/966/latch free>Found 14 objects wa

点击此处查看原文

数据库出现：Fri Nov 28 09:27:00 2008Errors in file /home/oracle9i/admin/ora9i/udump/ora9i2_ora_6615.trc:ORA-00600: internal error code, arguments: [kkxprpic8], [], [], [], [], [], [], []这个ORA-600错误一般出现在9.2.0.8环境，查看日志信息：ksedmp: internal or fatal errorORA-00600: internal error code, arguments: [kkxprpic8], [], [], [], [], [], [], []Current SQL statement for this session:INSERT INTO TB_RM_MIN_NBR (MIN_ID, MIN, MIN_GRP, INPUT_STAFF, INPUT_DATE, USE_STATE, USE_STAFF, USE_SITE, SERV_ID) SELECT SQ_RM_MIN_NBR_ID.NEXTVAL, IB_MIN, PG_CDMA_RM_NEW.TRAN_MIN_TO_MINGRP(IB_MIN_GRP), 'C_GJ', C_OPER_DATE, IB_MIN_STATE, NULL, 0, IB_SERV_ID FROM MID_CARD_PHONE_MIN_INFO M WHERE M.C_OPER_DATE = (SELECT MAX(N.C_OPER_DATE) FROM MID_CARD_PHONE_MIN_INFO N WHERE M.IB_MIN = N.IB_MIN GROUP BY IB_MIN HAVING COUNT(*) >= 1)----- PL/SQL Call Stack -----object line objecthandle number namec00000102dd6d620 1687 package body ZQIB.PG_CDMA_RM_NEWc00000102dd6d620 1518 package body ZQIB.PG_CDMA_RM_NEWc00000102dd6d620 28 package body ZQIB.PG_CDMA_RM_NEWc00000104f5a74f8 1 anonymous block在存储过程ZQIB.PG_CDMA_RM_NEW的时候报错。通过日志查看这个存储过程的信息：SO: c00000102c122418, type: 51, owner: c000000fe86436f0, flag: INIT/-/-/0x00LIBRARY OBJECT LOCK: lock=c00000102c122418 handle=c00000102dd6d620 mode=Ncall pin=c00000102c1241c8 session pin=0000000000000000htl=c00000102c122488[c00000102c1222f0,c000001051799268] htb=c000001051799268user=c000000fe86436f0 session=c000000fe86436f0 count=1 flags=PNC/[04] savepoint=25053LIBRARY OBJECT HANDLE: handle=c00000102dd6d620name=ZQIB.PG_CDMA_RM_NEWhash=ccb300c5 timestamp=11-28-2008 09:16:45namespace=BODY/TYBD flags=KGHP/TIM/SML/[02000000]kkkk-dddd-llll=0000-0039-00bf lock=N pin=S latch#=61lwt=c00000102dd6d650[c00000102dd6d650,c00000102dd6d650] ltm=c00000102dd6d660[c00000102dd6d660,c00000102dd6d660]pwt=c00000102dd6d

点击此处查看原文

甲：今天一个客户说有个库无法删除表。10.2.0.3的库白：是有一张表无法删除？甲：不是，任何一张表都无法删除，如果新建一张表，马上删除，就会报错白：报什么错？甲：ORA-604,ORA-942 ERROR at line 1:ORA-00604: error      occurred at recursive SQL level 1ORA-00942: table or view does not             existORA-06512: at line 19白：检查过有什么触发器没有？甲：好像没什么白：做个942的TRACE ,alter session set events '942 trace name ERRORSTACK level 3';甲：ksedmp: internal or fatal errorORA-00942: table or view does not existCurrent SQL statement for this session:SELECT  topology   FROM  SDO_TOPO_METADATA_TABLE a, TABLE(a.Topo_Geometry_Layers) b   WHERE b.owner = :owner AND b.table_name = :tab ----- PL/SQL Call Stack -----白：看样子是SDO_TOPO_METADATA_TABLE找不到，好像是SPATIAL的表，做个10046看看，为什么会用到这个表甲：除了刚才那个语句，看到这些比较奇怪DECLARE  type vcurType is REF CURSOR;  vcur vcurType;  stmt VARCHAR2(1000);  stm2 VARCHAR2(200);  rdt  VARCHAR2(80);  rsid number;  cnt  number;BEGIN  IF dictionary_obj_type = 'USER' THEN    stmt := 'DELETE FROM SDO_GEOR_SYSDATA_TABLE WHERE SDO_OWNER = :name';    EXECUTE IMMEDIATE stmt using dictionary_obj_name;  ELSIF dictionary_obj_type = 'TABLE' AND        dictionary_obj_owner <> 'MDSYS' AND        dictionary_obj_name <> 'SDO_GEOR_SYSDATA_TABLE' THEN    stmt := 'SELECT COUNT(*) FROM SDO_GEOR_SYSDATA_TABLE ' ||            ' WHERE SDO_OWNER = :1 AND GEORASTER_T

点击此处查看原文

客户的一个ORACLE 9.2.0.6 RAC，两台SUN E4900,EMC DMX 1000磁盘阵列，2台服务器不在同一个机房，INTERCONNECT网卡、SAN连接均采用裸光纤连接，INTERCONNECT网卡在同一网段，使用VERITAS的VCS，CFS。不过PUBLIC网卡不在同一网段，中间经过了一个防火墙。PUBLIC网卡经过路由和防火墙本来是不建议的方式，不过客户的特殊情况需要这样配置。在测试的时候，发现TAF无法成功，CLIENT的TNSNAMES.ORA中配置：testdb=  (DESCRIPTION =    (ADDRESS_LIST =      (ADDRESS = (PROTOCOL = TCP)(HOST = 161.140.2.241)(PORT = 1521))      (ADDRESS = (PROTOCOL = TCP)(HOST = 161.140.5.73)(PORT = 1521))      (LOAD_BALANCE = on)    )    (CONNECT_DATA =      (SERVICE_NAME = testdb)      (FAILOVER_MODE =        (TYPE = SELECT)        (METHOD = BASIC)        (RETRIES = 30)        (DELAY = 20)      )    )  )测试过程中，发现一旦一个实例关闭，连接在上面的连接马上出现ORA-3113，连接没有被切换过去。由于只有一个ORA-3113错误信息，很难进行定位，因此为了定位问题，需要进行TRACE。为了找到ORA-3113的原因，设置了CLIENT和服务器端的TRACE，在LISTENER的TRACE里没有发现任何有价值的信息。在CLIENT的TRACE有了比较重大的发现：设置：在SQLNET.ORA中设置：TRACE_LEVEL_CLIENT = 16      在TRACE文件中发现：ntt2err: soc 10 error - operation=5, ntresnt[0]=517, ntresnt[1]=131, ntresnt[2]=0[20-JUN-2008 21:43:39:294] ntt2err: exit[20-JUN-2008 21:43:39:294] nttrd: exit[

点击此处查看原文

算起来，从第一次给客户优化系统到现在也有10多年了。在这些年里，接触过不同的客户，不同的系统，对于优化的体会也越来越深刻。刚开始做优化的时候，总是希望找出系统中所有存在问题的地方，然后一个一个的进行调整。由于对Oracle的基本原理的认识不够，并且对优化的认识也仅限于调整不合理的部分这种浅层次上，因此往往做出一些事与愿违的事情来。对于系统优化，最有感触的几点，今天总结一下，和大家共享：1、优化是基于目标的，我们的最终目的是达到一个目标，而不是做优化。目标的合理性决定了优化项目的成败。刚刚开始给用户优化的时候，我会把所有能够调整的东西一次性全部调整完毕。哪怕有些调整给系统性能带来的好处不到0.1%。对于生产系统，不确定因素十分多，而很多参数方面的调整本身就是双刃剑，如果你无法预期其调整的影响，那么这种调整是存在风险的，在实施的时候就应该慎重考虑。现在我做优化的项目，往往会根据用户的优化目标，然后在此基础上进行分析，制定方案，实施的结果虽然一般会超出客户的期望，但是我不会在生产系统上做一些没把握的事情。锦上添花的事情，有时候也要考虑考虑，是否值得，因为弄不好，锦上添花会变成画蛇添足。2、1+1不一定大于1，在优化过程中，抓住主要矛盾，解决主要问题，而不要胡子眉毛一把抓。很多调整之间有关联性，甚至是互斥的，不合理的调整可能带来更坏的结果。3、客户需要的是系统的优化，而不仅仅是DB的优化。客户的目标里，看到的是一个系统，而不是一个孤立的DB。在10年前，我可能会说，OS的问题，你们还是找一下厂家。而现在，我会对客户说，你放心，我们做的是系统优化。4、用适当的方式和应用开发厂商配合。很多优化项目由于无法和应用厂商有效的配合，其效果大打折扣。因为应用是和系统性能关系最为紧密的。如果应用开发厂商不能很好的配合，那么优化项目将举步维艰。如果你和开发厂商说，“你这个SQL开销太大，需要修改一下”，那么得到可能就是强烈的反对。如果你说“这个SQL开销太大，我给你们提供了几个方案，第一是，。。。”，这样你很可能会得到比较好的结果。你是优化专家，找出几个TOP SQL这样的工作，不需要专家来完成，而专家的职责，不仅仅是发现TOP SQL，而是如何解决掉TOP SQL。5、不要相信什么优化规则，实际上并没有条条框框限制你，实现目标的任何方法你都可以使用。对于一个初级DBA来说，可能老DBA会告诉你，什么是

点击此处查看原文

数据库HANG住是计较头痛的事情，如何找到HANG住的原因，是DBA必须面临的课题。当数据库HANG住的时候，大多数DBA往往是通过V$SESSION_WAIT视图来进行分析。实际上Oracle有一个十分有效的工具----hanganalyze。HANGANALYZE可以十分清晰的将HANG住的信息告诉DBA，便于DBA进行进一步分析。Hanganalyze是从Oracle 8i r2(8.1.6)开始提供的，其用法十分简单：ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>';或者ORADEBUG hanganalyze <level>比如：sql>oradebug setmypid;sql>oradebug hanganalyze 3;对于<LEVEL>：      10     Dump all processes (IGN state)      5      Level 4 + Dump all processes involved in wait chains (NLEAF state)      4      Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state)      3      Le

点击此处查看原文

国内的用户对INSTANCE_GROUPS和PARALLEL_INSTANCE_GROUP参数比较陌生，因为在国内多节点的RAC比较少。要说这两个参数，我们必须说说并行查询（PQ,PARALLEL QUERY），并行查询是Oracle为了提高长时间运行的查询操作的性能而提供的功能，可以把一个QUERY分解为多个TASK,然后启动PX进程，由多个进程共同完成一个QUERY。在RAC环境下，PQ是可以跨实例的，也就是说可以由一个CLUSTER数据库的多个实例协同来完成一个QUERY。在这个情况下，就需要使用开头我们所说的那两个参数了。首先INSTANCE_GROUPS指出了本实例属于的GROUP的名字。这个参数可以指定多个值，用“，”分开。也就是说一个实例可以属于多个实例组。实例组通过名字来区分PARALLEL_INSTANCE_GROUP是并行查询使用的组的名字，如果这个参数是空的，那么说明PQ可以使用数据库的所有实例。如果指定了某个名字，那么说明PQ只能在指定的INSTANCE GROUP里进行。PARALLEL_INSTANCE_GROUP参数是可以在会话级动态修改的，因此通过调整这个参数，可以控制并行查询的范围。这个特性对于双节点RAC和多节点RAC都十分有用。要注意的是在不同的ORACLE版本中，这2个参数的设置是不同的，因此要了解详细的信息，请参考相关手册。比如在很多版本中，如果设置了一个不存在的GOUP，那么该SQL会使用串行方式执行，而不使用PQ，在有些版本中，错误的PARALLEL_INSTANCE_GROUP会报错。 参数参考：INSTANCE_GROUPSProperty  DescriptionParameter type  StringSyntax  INSTANCE_GROUPS = group_name [, group_name ] ...Default value  There is no default value.Modifiable  NoRange of values  One or more instance group names, separated by commasBasic  NoReal Application Clusters  Multiple instances can have different values.INSTANCE_GROUPS is a Real Application Clusters parameter that you can specify only in parallel mode. Used in conjunction with the PARALLEL_INSTANCE_GROUP parameter, it lets you restrict parallel query operations to a limited number of instances.This parameter specifies one or more instance groups and assigns the current instance to those groups. If one of the specified

点击此处查看原文

KCVFH是文件头结构。每个数据库的SYSTEM表空间中都存在一个SUPER BLOCK，这个BLOCK位于文件1的1号块。我们首先以10G为蓝本来看一下KCVFH的结构：struct kcvfh {  kcbh                 kcvfhbfh; /*  标准块头，每个块都有的结构，20个字节  */  kccfhg               kcvfhhdr;   krdba                kcvfhrdb; /*  指向bootstrap$的RDBA地址，这个是我们今天要关注的重点，这个值只有在FILE# 1才存在  */  kscn                 kcvfhcrs; /* 文件创建的SCN  */  ub4                  kcvfhcrt; /*  文件创建的时间戳  */  ub4                  kcvfhrlc;   kscn                 kcvfhrls;  ub4                  kcvfhbti;  kscn                 kcvfhbsc;  ub2                  kcvfhbth;   ub2                  kcvfhsta;   ub4&nbs

点击此处查看原文

对于LEFT JOIN中包含子查询的SQL,从9204开始会有问题，下面是个例子:SQL> create table test1(id integer, b varchar2(10));表已创建。SQL> create table test2(id number,d date);表已创建。SQL>SQL> insert into test1 values(1,'abc');已创建 1 行。SQL> insert into test1 values(2,'abc2');已创建 1 行。SQL>SQL>SQL> insert into test2 values(2,sysdate);已创建 1 行。SQL> insert into test2 values(1,sysdate);已创建 1 行。SQL>SQL> commit;提交完成。SQL> select t1.id from test1 t1 left join test2 t2 on t1.id=t2.id and  2  t2.d=(select max(ID) from test2 d);select t1.id from test1 t1 left join test2 t2 on t1.id=t2.id and*ERROR 位于第 1 行:ORA-01799: 列不可以外部连接到子查询如何解决这个问题呢？创建一个存储过程，把子查询用存储过程来实现就可以了,下面是例子：SQL> select t1.id from test1 t1 left join test2 t2 on t1.id=t2.id and  2  t2.d=(select max(ID) from test2 d where d.id=t1.id);select t1.id from test1 t1 left join test2 t2 on t1.id=t2.id and*ERROR 位于第 1 行:ORA-01799: 列不可以外部连接到子查询SQL> create or replace function func1(pid number) return date is  2   vid date;  3  begin  4    select max(d) into vid from test2 where id=pid;  5    return vid;  6  end;  7  /函数已创建。SQL>SQL> select t1.id from test1 t1 left join test2 t2 on t1.id=t2.id and  2  t2.d=func1(t1.id);        ID----------         1         2

点击此处查看原文

Wed May 21 18:45:53 2008Starting ORACLE instance (normal)Wed May 21 18:46:16 2008Starting ORACLE instance (normal)Wed May 21 18:47:08 2008Errors in file /home/oracle/admin/yhsfcg/udump/yhsfcg_ora_24583.trc:ORA-00600: 内部错误代码, 参数: [keltnfy-ldmInit], [46], [1], [], [], [], [], []Wed May 21 18:47:33 2008Errors in file /home/oracle/admin/yhsfcg/udump/yhsfcg_ora_24586.trc:ORA-00600: 内部错误代码, 参数: [keltnfy-ldmInit], [46], [1], [], [], [], [], []Wed May 21 18:47:38 2008Starting ORACLE instance (normal)Wed May 21 18:47:43 2008Shutting down instance (abort) 通过TRACE文件可以看到：ksedmp: internal or fatal errorORA-00600: 内部错误代码, 参数: [keltnfy-ldmInit], [46], [1], [], [], [], [], []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 ?                                                   000000000 ?

点击此处查看原文

这几天由于客户的需求，写了一个修改错误块的小程序，把其中的一些代码贴出来给大家共享一下#include <stdio.h>#include <fcntl.h>#include <sys/types.h>#include <sys/stat.h>#include <errno.h>#include <string.h>#include <stdlib.h>typedef unsigned int   ub4;typedef unsigned short ub2;typedef unsigned char  ub1;#ifndef LINUX#define OFFSET 0         /* if it's needed specify an offset !=0 */#else #define OFFSET 0#endif#define FALSE      0#define TRUE       1#define NUMORABLOCK(fsize,orabsize) \   ((fsize==(orabsize-OFFSET)) ? (1) : ((fsize/(orabsize-OFFSET))-1)) #define FILE_ID(dba) (dba >> 22)     /* right shift dba over 22 to get file# */#define BLOCK_ID(dba) (dba & 0x3fffff)/*mask 22 lower bits of dba to get block#*/#define CHECKCONDITION(bh) ((bh->type==6) && (bh->flg & 0x4))#define PRINT_HEADER(bh) fprintf(stdout,\   "file# %d,block# %d \n type: 0x%x fmt: 0x%x rdba: 0x%x base SCN: 0x%x\   \n wrap SCN: 0x%x chk: 0x%x",   BLOCK_ID(bh->rdba),\   FILE_ID(bh->rdba),bh->type, bh->Fmt, bh->rdba, bh->bas, bh->wrp, bh->cks)   #define PRINT_COMPUTED_CHECKSUM(bh,cks) fprintf(stdout,\   " [kcbhxor: 0x%x]\n\n",cks)#define PRINT_FILEINFO(fname,fstat,orablocks) \   fprintf(stdout,"name: %s size: %d n-blocks: %d\n",fname,\   fstat.st_size,orablocks)

点击此处查看原文

本文以9.2为目标版本，各个版本可能略有不同：语法：alter session set events 'immediate trace name library_cache level <level>';level:    Level = 1   Dump library cache 状态    Level = 2   Dump hash table 统计信息    Level = 4   Dump library cache objects 的基本信息    Level = 8   Dump objects 的详细信息，包含child的信息以及pin等待者等信息     Level = 16  Dump heap 大小 (可能引起闩锁问题，在生产系统中注意)    Level = 32  Dump heap的信息        Level > 100      DUMP某个LIBRARY CACHE OBJECT的明细信息（中等详细），LEVEL=OBJECT HANDLE    Level > 1000000000       DUMP某个LIBRARY CACHE OBJECT的明细信息（详细），LEVEL=1000000000+OBJECT HANDLE 

点击此处查看原文

今天开始出差了，晚上有更多的时间写东西，今天我们来分析分析LIBRAY CACHE PIN/LOCK和SESSION CACHED CURSORS的一些关系吧。首先我们要使用EVENT 10049：var id number;exec :id:=1099;select empno,ename from emp where empno=:id;select hash_value from v$sqlarea where sql_text like 'select empno,ename%';HASH_VALUE----------2892642740用计算器看看16进制：AC6A39B4低位是39B4，我们要TRACE PIN/LOCK因此TRACE LEVEL=39B42030,转换为10进制就是：968106032alter session set session_cached_cursors=0 ;alter session set events '10049 trace name context forever,level 968106032';然后多次执行exec :id:=1010;select empno,ename from emp where empno=:id;exec :id:=1011;select empno,ename from emp where empno=:id;从TRACE看到，每次执行：KGLTRCLCK kglget     hd = 0x1FBCB8A4  KGL Lock addr = 0x20F75530 mode = NKGLTRCLCK kglget     hd = 0x1FBCB7C0  KGL Lock addr = 0x20FA8970 mode = NKGLTRCPIN kglpin     hd = 0x1FBCB7C0  KGL Pin  addr = 0x20F259D0 mode = SKGLTRCPIN kglpndl    hd = 0x1FBCB7C0  KGL Pin  addr = 0x20F259D0 mode = SKGLTRCLCK kgllkdl    hd = 0x1FBCB7C0  KGL Lock addr = 0x20FA8970 mode = NKGLTRCLCK kgllkdl    hd = 0x1FBCB8A4  KGL Lock addr = 0x20F75530 mode = N首先我们来看这里涉及2个地址，通过library_cache的trace看到：BUCKET 14772:  LIBRARY OBJECT HANDLE: handle=1fbcb8a4 mutex=1FBCB958(1)  name=select empno,ename from emp where empno=:id  hash=cedcee1ccc9795f332f72482ac6a39b4 timestamp=12-24-2007 21:55:26  namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=3 hpc=0000 hlc=0000  lwt=1FBCB900[1FBCB900,1FBCB900] ltm=1FBCB908[1FBCB908,1FBCB908]  pwt=1FBCB8E4[1FBCB8E

点击此处查看原文

最近比较忙好久没更新这个系列了，今天写一小段，大家不要骂人就好了。BIND VALUE PEEKING是Oracle 9i才引入的新技术（我的印象里是9.2，不知道是否准确）。在没有这个技术之前，使用绑定变量后，执行计划的产生要靠缺省的选择性判断，这种判断往往会出现严重的偏差。在具有这个技术后，当SQL PARSE的时候，就会对BIND VALUE进行PEEKING,根据PEEKING的结果来生成执行计划。下面的实验可以说明这种BIND VALUE PEEKING的工作原理：SQL> var a number;SQL> exec :a:=10;PL/SQL 过程已成功完成。SQL> select * from dept where deptno=:a;    DEPTNO DNAME          LOC                                                   ---------- -------------- -------------                                                 10 ACCOUNTING     NEW YORK                                              SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ADVANCED'));  ----ADVANCED是Oracle内部使用的未正式发布的参数PLAN_TABLE_OUTPUT                                   &

点击此处查看原文