莫等闲

下面教大家如何手工算出oracle执行计划中的cost值。成本的计算方式如下：Cost = (       #SRds * sreadtim +       #MRds * mreadtim +       CPUCycles / cpuspeed       ) / sreadtime#SRds - number of single block reads 单

一天查看数据库长会话，发现1个sql跑得很慢，1个多小时不出结果，花了点时间把它给优化了。优化前：SELECT 20131023, "A2"."ORG_ID", COUNT(DISTINCT NLSSORT(CASE "A2"."RES_TYPE" WHEN 'DP' THEN

开发的同事发来一条语句，让我帮忙查看下ods和源端的结果是否一致。因为一下执行没出来，问开发人员，这个语句要跑2-3分钟。因为他们是从本地用dblink连到ods的，我这里把dblink去掉直接从ods查看执行计划。SELECT XSY_CODE,--发展销售员编码 SLY_CODE,--受理销售员编码 XSD_CODE,--销售点编码 DZS_CO

分区表有很多好处，以大化小，一小化了，加上并行的使用，在loap中能往往能提高几十倍甚至几百倍的效果。当然表设计得不好也会适得其反，效果比普通表跟糟糕。为了更好的使用分区表，这里看一下分区表的执行计划。PARTITION RANGE ALL：扫描所有分区PARTITION RANGE ITERATOR：扫描多个分区，小于所有个分区数量PARTITION RANGE SINGLE：扫描单一的

有一个脚本跑了很久不出结果，优化之后瞬间出结果。原语句如下：SQL> explain plan for 2 select * 3 from crm_dg.tb_ba_channelstaff a, 4 crm_dg.tb_ba_subscription_hist b, 5 crm_dg.tb_cm_serv

在大型数据库中，回收站很大，垃圾很多，表空间查询起来特别慢。为了防止意外操作，不可能每次drop表的时候加上perge，这时候垃圾越来越多，查表空间要等很久。这时，定制一个表空间保留策略就显得非常有必要。下面将我的脚本共享一下，加入job中便可自动清理。create or replace procedure lhj_delete_recyclebin ( preserve_date in nu

在olap中，往往能看到性能很差的语句是update语句，跑半天都跑不过去，虽然语句可以千变万化，但是优化起来还是有规可循的。--测试表：drop table t1;drop table t2;create table t1 as select * from dba_objects;create table t2 as select * from dba_objects;--原始

之前同事发过一个语句，实现的功能比较简单，类似group by的分组计数功能，因为where条件有like，又无法用group by来实现。SELECT a.N0,b.N1,c.N2,d.N3,e.N4,f.N5,g.N6,h.N7,i.N8,j.N9 from (select count(*) N0 from tbl_loginfo_20141110 where keyrecord lik

同事发来2个语句，说语句1跑得慢，语句2很快就出结果。一执行，果然很慢。仔细发现，2个语句不等价。语句1：select l.*,o.object_name from v$locked_object l left join all_objects o on l.object_id=o.object_id;语句2：select l.*,o.object_name from v$

如何最大限制利用cpu？如何最快速的扫描完大表。如果大表有主键，count（*）就会走主键，oracle只需要扫描主键就能完成。假设这个表没有主键，那么count（*）的时候只能走全表扫描，数据就非常慢。这里用full(a)强制走全表来模拟。--找100G以上的分区表SQL> @getsegsize_bigEnter value for tablespace_name:Enter v

直方图 当某列数据分布不均衡，为了让CBO能生成最佳的执行计划，我们可能需要对表收集直方图，直方图最大的桶数(Bucket)是254。收集直方图是一个很耗时的过程，如无必要，千万别去收集直方图。Oracle的直方图有两种：一种是频率直方图(FREQUENCY HISTOGRAM)，当列中Distinct_keys 较少(小于254)，如果不手工指定直方图桶数(BUCKET)，Oracle

在oracle中，标量子查询和自定义函数用的比较多，而且开发人员也比较常用，但经常会引起性能问题，特别表比较大的时候。下面的案例将教大家彻底搞懂标量子查询：SQL> create table a (id int,name varchar2(10));Table created.SQL> create table b (id int,name varchar2(10));

什么是单块读？顾名思义，就是单个块单个块得读，等待事件表现为db file sequential read；单块读有哪些情况？大部分索引扫描是单块读（除index fast full scan），rowid回表是单块读，undo里读数据是单块读，行迁移行链接是单块读，读取段头是单块读，读边界块是单块读。现在就来探讨下undo里读数据是单块读的情况：--session1:SQL>

近日查看数据库运行较长的语句，发现我们这边的开发人员真是厉害，不懂装懂的本领真高。开发以为只要走索引就是快的，而且刚好知道index hint可以强制走索引，所以就用上了。可是走的是bitmap index full scan，把整个索引都扫描了，然后根据索引的位图转化（bitmap conversion to rowids）成rowid，再根据索引的rowid和表的row

同事发来一个语句，说5个小时不出结果，我滴个神呀，想看看到底是语句造成的。于是叫同事发过来。不看不知道，一看吓一跳，3个表关联，强制使用了2个index hint，其中一个表9g，一个表67g，还有一个小表40Mb。开发人员，总以为走index就是快的，所以使用了index hint，最终导致走得非常慢。下面是同事发来的语句： select /*+ parallel(t,4) ind

最近监控数据库，发现下面语句跑得非常慢，原来执行计划走了导致笛卡尔积，来看下面语句：SQL> explain plan for 2 SELECT COUNT(*) 3 FROM "GD_FS"."TZZ_SJ_DEV_DISC_79073" "A2", 4 "GD_FS"."TZZ_SJ_DEVELOP_MONTH" "A1" 5 WHERE "A

今天姚工发来个语句，说gz地市的一个语句跑得很慢，1个多钟了还不出结果：原来语句：

同事说这个语句太烂了，从20号跑到21号，跑不出结果还报错，有没有优化的建议。ORA-01410: invalid ROWID:CREATE TABLE MID_TD_D1W_004_08_a NOLOGGING AS select /*+PARALLEL(A,6) PARALLEL(B,6) */