ITPub博客

1:SGA预估为大于shared_pool 和buffer cache之和2:PGA直接采用pga_ADVICEshare_pool建议值，ELTTS=1select t.SHARED_POOL_SIZE_FOR_ESTIMATE "SP", t.ESTD_LC_SIZE "EL", t.ESTD_LC_MEMORY_OBJECTS "ELM",t.ESTD_LC_TIME_SAVED "ELT", t.ESTD_LC_TIME_SAVED_FACTOR "ELTS %", t.ESTD_LC_MEMORY_OBJECT_HITS "ELMO" from v$shared_pool_advice t;查看buffer cache, physical_read % 物理都比较小的时候SELECT size_for_estimate "target M", buffers_for_estimate,

根据创建的函数和一些平时我经常用的DBA调优语句我找出了这条latch buffer问题的语句总体思路：1：找出SQL语句，这是调优数据库性能问题的关键2：查看执行计划，分析执行计划3：查看表大小4：分析表的统计信息5：创建新的索引6：最后，比较关键：重改SQL语句，联系开发修改程序代码。1：查看执行计划SQL> explain plan for 2 select PRICE_PROMO 3 from wiliam.TB_PROMO 4 where CORPID = 'XANDER' 5 and to_number(START_DATE) <= 20110314 6 and to_number(END_DATE) >= 20110314 7 and (PROMO_RANGE = 'A'

Oracle中更新主外键时的一些注意事项1、外键无索引时，子表更新外键未提交，主表更新非子表引用的主键时被阻塞 会话1： create table t1 (x int primary key); insert into t1 values(1); insert into t1 values(2); insert into t1 values(3); commit; create table t2（y int references t1）； insert into t2 values（1）； commit; update t2 set y=2 where y=1; 会话2： update t1 set x=4 where x=3; //会话被阻塞 2、外键有索引时，子表更新外键未提交，主表更新非子表引用的主键时不会被阻塞 会话1： create index t2_index on

COLUMN COLUMNS format a30 word_wrappedCOLUMN tablename format a15 word_wrappedCOLUMN constraint_name format a15 word_wrappedSELECT TABLE_NAME, CONSTRAINT_NAME, CNAME1 || NVL2(CNAME2, ',' || CNAME2, NULL) || NVL2(CNAME3, ',' || CNAME3, NULL) || NVL2(CNAME4, ',' || CNAME4, NULL) || NVL2(CNAME5, ',' || CNAME5, NULL) || NVL2(CNAME6, ',' || CNAME6, NULL) || NVL2(CNAME7, ',' || CNAME7, NULL) || NVL2(CNAME8, ',' || CNAME8, NULL) COLUMNS FROM (SELECT B.TA

Oracle中捕获问题SQL解决CPU过渡消耗 本文通过实际业务系统中调整的一个案例，试图给出一个常见CPU消耗问题的一个诊断方法.大多数情况下，系统的性能问题都是由不良SQL代码引起的，那么作为DBA，怎样发现和解决这些SQL问题就显得尤为重要. 　　本案例平台为Unix，所以不可避免的应用了一些Unix下常用的工具.如vmstat,top等. 　　本文适宜读者范围:中高级. 　　系统环境: 　　　OS: Solaris8 　　　Oracle: 8.1.7.4 　　问题描述: 　　开发人员报告系统运行缓慢,已经影响业务系统正常使用.请求协助诊断. 　　1.登陆数据库主机 　　使用vm

Oracle性能优化经验分享之系统参数设置SGAITPUB个人空间s9S-^mG/d7EKy1、Shared pool tunning3o k n,^1zy6~1PAy;e22934571Shared pool的优化应该放在优先考虑，因为一个cache miss在shared pool中发生比在data buffer中发生导致的成本更高，由于dictionary数据一般比library cache中的数据在内存中保存的时间长，所以关键是library cache的优化。ITPUB个人空间'lN}}M XqcIGets：（parse）在namespace中查找对象的次数；4{{‑kBp22934571Pins：（execution）在namespace中读取或执行对象的次数；ITPUB个人空间;~T;Hg.zI b

提高SQL查询性能的7个法宝2010年04月30日 00:05 IT168网站原创 作者：IT168 黄永兵译 编辑：晓熊 评论：14条 本文Tag： DB2数据库优化 Oracle数据库优化 SQL Server数据库优化 数据库 　　【IT168专稿】每个数据库平台上的SQL开发人员都是在困难中求得生存，我们总是一次又一次犯同样的错误，这是因为数据库领域还相对不成熟，是的，每个数据库厂商都在做着各种不同的努力，但作为开发人员仍然要克服各种问题，无论是在SQL Server，Oracle，DB2，Sybase，MySQL数据库，还是其它关系数据库平台上编写SQL代码，并发性、资源管理、空间管理和

ORACLE SQL语句优化技术分析 收藏 IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。 但是用IN的SQL性能总是比较低的，从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。 推荐方案：在业务密集的SQL当中尽量

oracle是一个庞大的知识体系，各个知识点之间存在着错综复杂的立体网状关系，孤立的引用某个 论点四处应用，南辕北辙的结果恐怕往往会伴随在你左右。同时，Oracle版本众多，同一个知识点在不同的版本里常有一些应用上的 区别，这也是需要引起足够重视的。 建立索引 分析索引 虽然cost-base优化技术帮助了避免在查询中使用不被选中(nonselective)的索引，但是SQL引擎必然一直对表的所有索引进行维护，而不管这个索引是否被使用。在定操作很多的应用中，索引的维护会消耗非常巨大的CPU和I/O资源(resourse)，换句话说，请不要建立不必要的

tuning sql sql语句调优尽量避免在列上调用函数，如果不能避免则在常数上使用函数。下面这证明这一点； (一）SQL语句解释和执行时间比较测试语句A和语句B，功能是等价的，explain plan都走相同的索引，但是cost不一样。 A:这是一个标准的写法，建议都用这个，列"add_time"为date类型。 select count(*)from wiliam.tb_sale where add_time>=to_date('2011-01-11 00:00 ','yyyy-mm-dd hh24:mi:ss')and add_time<to_date('2011-01-12 00:00 ','yyyy-mm-dd hh24:mi:ss') B:在列上“add_time"使用"to_char"

4、为什么有时一个表的某个字段明明有索引,当观察一些语的执行计划确不走索引呢？如何解决呢 ？ A、不走索引大体有以下几个原因 ♀你在Instance级别所用的是all_rows的方式 ♀你的表的统计信息(最可能的原因) ♀你的表很小,上文提到过的,Oracle的优化器认为不值得走索引。 B、解决方法 ♀可以修改init.ora中的OPTIMIZER_MODE这个参数,把它改为Rule或Choose,重起数据库。也可以使用4中所提的Hint.补充：不走索引的原因，甚至加上 /*+index(table_name index_name)*/还不走索引，那可能是因为你要走索引的这列是nullable，虽然这列没有空值。