无语的index hint：手工分配哈希区，5小时不出结果，优化后20分钟

标签： index hint 工分 | 发表时间：2014-10-25 17:42 | 作者：gdmzlhj1
出处：http://blog.csdn.net
同事发来一个语句，说5个小时不出结果，我滴个神呀，想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道，一看吓一跳，3个表关联，强制使用了2个index hint，其中一个表9g，一个表67g，还有一个小表40Mb。无知的开发人员，以为走index就是快的，哎。。。
下面是同事发来的语句： 
select /*+  parallel(t,4) index(a,IDX_COMMBASUBSHIST_1) index(b,IDX_COMMCMSERVHIST_1)*/
    1,
    t.DISC_ID,
    t.DISC_LEV,
    to_date(20140117082042, 'yyyymmddhh24miss'),
    t.MSINFO_ID,
    t.ORG_ID,
    t.SERV_ID,
    t.SUBS_ID,
    t.OBJ_GRP_ID,
    a.SUBS_CODE,
    a.SUBS_STAT,
    a.SUBS_STAT_REASON,
    a.SUBS_STAT_DATE,
    a.ACTION_ID,
    a.ACTION_TYPE,
    a.ACTION_EX_TYPE,
    a.ACT_DATE,
    a.REQ_ID,
    a.STAFF_ID,
    a.CMMS_CUST_CODE,
    a.SPEED_VALUE,
    b.ACC_NBR,
    b.CUST_ID,
    b.SERV_NBR,
    b.CONSUME_GRADE,
    b.SERV_LEV,
    b.ACCOUNT_NBR,
    b.CITY_VILLAGE_ID,
    b.SERV_CHANNEL_ID,
    b.SERV_STAT_ID,
    b.CUST_CLASS_DL,
    b.CUST_TYPE_ID,
    b.USER_TYPE,
    b.USER_CHAR,
    b.PAYMENT_TYPE,
    b.BILLING_TYPE,
    b.PROD_ID,
    b.PROD_CAT_ID,
    b.EXCHANGE_ID,
    b.SERV_COL1,
    b.SERV_COL2,
    b.AREA_ID,
    b.SUBST_ID,
    b.BRANCH_ID,
    b.STOP_TYPE,
    b.CUST_MANAGER_ID,
    b.CREATE_DATE,
    b.ADDRESS_ID,
    b.SUBS_DATE,
    b.OPEN_DATE,
    b.MODI_STAFF_ID,
    b.CMMS_CUST_ID,
    b.CUST_NAME,
    b.SALES_ID,
    b.SALES_TYPE_ID,
    b.SERV_ADDR_ID,
    t.HIST_CREATE_DATE,
    b.ARREAR_MONTH,
    b.ARREAR_MONTH_LAST,
    t.SALESTAFF_ID,
    t.EHOME_TYPE,
    t.EHOME_CLASS,
    b.strat_grp_dl,
    b.sale_org1,
    b.sale_org2,
    b.sale_org3,
    b.location_type,
    b.region_flag,
    b.terminal_id,
    b.pstn_id,
    b.fee_id,
    b.payment_id,
    b.billing_id,
    b.strat_grp_xl,
    b.fld1,
    b.fld3,
    b.cust_level,
    b.group_cust_type,
    b.cust_region,
    b.group_cust_grade,
    b.control_level,
    b.net_connect_type,
    b.trade_type_id,
    b.acc_nbr2,
    b.cdma_class_id,
    b.phone_number_id,
    b.develop_channel,
    b.online_time,
    t.wireless_type,
    b.new_serv_stat_id,
    b.is_phs_tk,
    b.serv_grp_type,
    b.state,
    t.cdma_disc_type,
    b.mix_disc,
    b.is_3g,
    t.add_disc_type,
    to_number(nvl(b.business_type, '-1')),
    nvl(t.label_num, -1),
    b.is_mix_prod,
    t.price_id,
    t.disc_item_id,
    b.STD_SUBST_ID,
    b.STD_BRANCH_ID,
    t.DISC_ITEM_ID_OP,
    t.PRICE_ID_OP,
    t.business_type,
    b.new_prod_id,
    b.BOARD_SUBST_ID,
    b.BOARD_BRANCH_ID
     from RPT_COMM_BA_SUBS_HIST  a,
          RPT_COMM_CM_SERV_HIST  b,
          TB_COMM_BA_MSDISC_TEMP t
    where a.subs_id = t.subs_id
      and b.serv_id = t.serv_id



--同事说开销比较大。有450W。。下面是执行计划：
<img src="http://img.blog.csdn.net/20141025102001913?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZ2RtemxoajE=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />
 
/*
涉及的表大小：
OWNER	SEGMENT_NAME	SEGMENT_TYPE	Size(Mb)
SUMMARY_SJZ_GZ	TB_COMM_BA_MSDISC_TEMP	TABLE	40
SUMMARY_SJZ_GZ	RPT_COMM_CM_SERV_HIST	TABLE PARTITION	9016.1875
SUMMARY_SJZ_GZ	RPT_COMM_BA_SUBS_HIST	TABLE PARTITION	67330.25

以下是优化思路：
强制使用索引，导致其中9g的表走了index full scan，然后回表。因为除了index fast scan以外，其他索引扫描都是单块读，回表又是单块读。导致速度非常慢。优化时考虑使用哈希连接，40Mb的小表作为驱动表，连接9g的表，最后连接超大的67G的表。
优化时使用的技术：
1.	use_hash（a，b），使用哈希表关联方式
2.	/*+parallel(a 5)*/;并行处理
3.	db_file_multiblock_read_count多块读参数设置为最大
4.	workarea_size_policy设置为手工管理
5.	sort_area_size设为接近最大
6.        hash_area_size设为接近最大

<p>5小时不出结果，优化后20分钟不到出结果，就是这么神奇。</p><p>alter session enable parallel dml;
alter session set workarea_size_policy=manual;
alter session set sort_area_size=2100000000;
alter session set hash_area_size=2100000000;
alter session set db_file_multiblock_read_count=128;




select  /*+parallel(a,5) parallel(b,5) parallel(t,5) leading(t) use_hash(t,b) user_hash(b,a)*/
     1,
    t.DISC_ID,
    t.DISC_LEV,
    to_date(20140117082042, 'yyyymmddhh24miss'),
    t.MSINFO_ID,
    t.ORG_ID,
    t.SERV_ID,
    t.SUBS_ID,
    t.OBJ_GRP_ID,
    a.SUBS_CODE,
    a.SUBS_STAT,
    a.SUBS_STAT_REASON,
    a.SUBS_STAT_DATE,
    a.ACTION_ID,
    a.ACTION_TYPE,
    a.ACTION_EX_TYPE,
    a.ACT_DATE,
    a.REQ_ID,
    a.STAFF_ID,
    a.CMMS_CUST_CODE,
    a.SPEED_VALUE,
    b.ACC_NBR,
    b.CUST_ID,
    b.SERV_NBR,
    b.CONSUME_GRADE,
    b.SERV_LEV,
    b.ACCOUNT_NBR,
    b.CITY_VILLAGE_ID,
    b.SERV_CHANNEL_ID,
    b.SERV_STAT_ID,
    b.CUST_CLASS_DL,
    b.CUST_TYPE_ID,
    b.USER_TYPE,
    b.USER_CHAR,
    b.PAYMENT_TYPE,
    b.BILLING_TYPE,
    b.PROD_ID,
    b.PROD_CAT_ID,
    b.EXCHANGE_ID,
    b.SERV_COL1,
    b.SERV_COL2,
    b.AREA_ID,
    b.SUBST_ID,
    b.BRANCH_ID,
    b.STOP_TYPE,
    b.CUST_MANAGER_ID,
    b.CREATE_DATE,
    b.ADDRESS_ID,
    b.SUBS_DATE,
    b.OPEN_DATE,
    b.MODI_STAFF_ID,
    b.CMMS_CUST_ID,
    b.CUST_NAME,
    b.SALES_ID,
    b.SALES_TYPE_ID,
    b.SERV_ADDR_ID,
    t.HIST_CREATE_DATE,
    b.ARREAR_MONTH,
    b.ARREAR_MONTH_LAST,
    t.SALESTAFF_ID,
    t.EHOME_TYPE,
    t.EHOME_CLASS,
    b.strat_grp_dl,
    b.sale_org1,
    b.sale_org2,
    b.sale_org3,
    b.location_type,
    b.region_flag,
    b.terminal_id,
    b.pstn_id,
    b.fee_id,
    b.payment_id,
    b.billing_id,
    b.strat_grp_xl,
    b.fld1,
    b.fld3,
    b.cust_level,
    b.group_cust_type,
    b.cust_region,
    b.group_cust_grade,
    b.control_level,
    b.net_connect_type,
    b.trade_type_id,
    b.acc_nbr2,
    b.cdma_class_id,
    b.phone_number_id,
    b.develop_channel,
    b.online_time,
    t.wireless_type,
    b.new_serv_stat_id,
    b.is_phs_tk,
    b.serv_grp_type,
    b.state,
    t.cdma_disc_type,
    b.mix_disc,
    b.is_3g,
    t.add_disc_type,
    to_number(nvl(b.business_type, '-1')),
    nvl(t.label_num, -1),
    b.is_mix_prod,
    t.price_id,
    t.disc_item_id,
    b.STD_SUBST_ID,
    b.STD_BRANCH_ID,
    t.DISC_ITEM_ID_OP,
    t.PRICE_ID_OP,
    t.business_type,
    b.new_prod_id,
    b.BOARD_SUBST_ID,
    b.BOARD_BRANCH_ID
     from SUMMARY_SJZ_GZ.RPT_COMM_BA_SUBS_HIST  a,
          SUMMARY_SJZ_GZ.RPT_COMM_CM_SERV_HIST  b,
          SUMMARY_SJZ_GZ.TB_COMM_BA_MSDISC_TEMP t
    where a.subs_id = t.subs_id
      and b.serv_id = t.serv_id
</p>
</pre><pre>


 

    作者：gdmzlhj1 发表于2014-10-25 9:42:52   原文链接


 

    阅读：96 评论：1   查看评论




相关 [index hint 工分] 推荐：
无语的index hint：手工分配哈希区，5小时不出结果，优化后20分钟

-  - CSDN博客数据库推荐文章

同事发来一个语句，说5个小时不出结果，我滴个神呀，想看看到底是什么垃圾语句造成的. 不看不知道，一看吓一跳，3个表关联，强制使用了2个index hint，其中一个表9g，一个表67g，还有一个小表40Mb. 无知的开发人员，以为走index就是快的，哎. 下面是同事发来的语句： 
select /*+  parallel(t,4) index(a,IDX_COMMBASUBSHIST_1) index(b,IDX_COMMCMSERVHIST_1)*/. 
Oracle 常见hint用法

-  - ITeye博客

表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化. 表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化. 表明如果数据字典中有访问表的统计信息,将基于开销的优化方法,并获得最佳的吞吐量;. 表明如果数据字典中没有访问表的统计信息,将基于规则开销的优化方法;. 
常见Oracle HINT的用法

-  - Oracle - 数据库 - ITeye博客

      在SQL语句优化过程中，我们经常会用到hint,现总结一下在SQL优化过程中常见Oracle HINT的用法：. 表明对语句块选择基于开销的优化方法,并获得最佳吞吐量,使资源消耗最小化.. 表明对语句块选择基于开销的优化方法,并获得最佳响应时间,使资源消耗最小化.. 表明如果数据字典中有访问表的统计信息,将基于开销的优化方法,并获得最佳的吞吐量;. 
(转）Oracle中Hint深入理解

-  - 数据库 - ITeye博客

原文出处：   http://czmmiao.iteye.com/blog/1478465. 基于代价的优化器是很聪明的，在绝大多数情况下它会选择正确的优化器，减轻了DBA的负担. 但有时它也聪明反被聪明误，选择了很差的执行计划，使某个语句的执行变得奇慢无比. 此时就需要DBA进行人为的干预，告诉优化器使用我们指定的存取路径或连接类型生成执行计划，从 而使语句高效的运行. 
CSS中的z-index属性

-  - IT技术博客大学习

标签：    z-index. css中z-index也是常用的一个属性，这个z-index说的就是第三轴的位置，网页实际是二维的，但是页面上的元素堆叠的层次就可以看作为第三轴，所以z-index也就很好理解了，在z轴上的索引. 好吧我再说的直白一点这里的z-index指的就是哪个元素显示在上面，哪个显示在下面，数值越大的越靠上，会把z-index值比较小的元素挡住. 
关于z-index的那些事儿

-  - 前端观察

关于z-index的真正问题是，很少有人理解它到底是怎么用. 其实它并不复杂，但是如果你从来没有花一定时间去看具体的z-index相关文档，那么你很可能会忽略一些重要的信息. 好吧，看看你能否解决下面这个问题：. 在 接下来的HTML里 有三个
元素，并且每个
里包含一个元素. 
理解 B*tree index内部结构

-  - CSDN博客数据库推荐文章

转载请注明出处：  http://write.blog.csdn.net/postedit/40589651.     Oracle数据库里的B树索引就好象一棵倒长的树，它包含两种类型的数据块：一种是索引分支块，另一种是索引叶子块 索引分支块包含指向相应索引分支块/叶子块的指针和索引健值列（这里的指针是指相关分支块/叶子块的块地址RDBA. 
index rebuild和rebuild online的区别

-  - CSDN博客数据库推荐文章

       曾经看到过淘宝的这个面试题：在一个24*7的应用上，需要把一个访问量很大的1000万以上数据级别的表的普通索引(a,b)修改成唯一约束(a,b,c)，你一般会选择怎么做，请说出具体的操作步骤与语句.        先online建索引添加约束，然后删除原理的索引.        为什么要用online呢. 
利用 index、explain和profile优化mysql数据库查询小结

-  - 博客园_首页

想必大家对index，explain和profile的利用也很多，这是我最近两天优化mysql语句查询资料整理的一些内容，希望大家可以一起来补充一下. 1.最好是在相同类型的字段间进行比较的操作. 在MySQL 3.23版之前，这甚至是一个必须的条件. 例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较. 
Oracle rebuild index 使用 parallel 时 与 并行度 的注意事项

-  - CSDN博客推荐文章

一.Rebuild 索引 与 并行度 说明. 在之前的Blog里整理了一些列有关索引相关的Blog，如下：. Oracle 索引 详解. 如何加快建index 索引 的时间. Oracle 索引扫描的五种类型. Oracle 索引的维护. Oracle alterindex rebuild 与ORA-08104 说明.