最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
问答文章1 问答文章501 问答文章1001 问答文章1501 问答文章2001 问答文章2501 问答文章3001 问答文章3501 问答文章4001 问答文章4501 问答文章5001 问答文章5501 问答文章6001 问答文章6501 问答文章7001 问答文章7501 问答文章8001 问答文章8501 问答文章9001 问答文章9501
当前位置: 首页 - 科技 - 知识百科 - 正文

无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟

来源:懂视网 责编:小采 时间:2020-11-09 14:33:16
文档

无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟

无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟:同事发来一个语句,说5个小时不出结果,我滴个神呀,想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道,一看吓一跳,3个表关联,强制使用了2个index hint,其中一个表9g,一个表67g,还有一个小表40Mb。无知的开发人员,以为走index就是快
推荐度:
导读无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟:同事发来一个语句,说5个小时不出结果,我滴个神呀,想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道,一看吓一跳,3个表关联,强制使用了2个index hint,其中一个表9g,一个表67g,还有一个小表40Mb。无知的开发人员,以为走index就是快

同事发来一个语句,说5个小时不出结果,我滴个神呀,想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道,一看吓一跳,3个表关联,强制使用了2个index hint,其中一个表9g,一个表67g,还有一个小表40Mb。无知的开发人员,以为走index就是快的,

同事发来一个语句,说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。下面是执行计划:

 
/*
涉及的表大小:
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设为接近最大

5小时不出结果,优化后20分钟不到出结果,就是这么神奇。

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

声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文档

无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟

无语的indexhint:手工分配哈希区,5小时不出结果,优化后20分钟:同事发来一个语句,说5个小时不出结果,我滴个神呀,想看看到底是什么垃圾语句造成的。于是叫同事发过来。不看不知道,一看吓一跳,3个表关联,强制使用了2个index hint,其中一个表9g,一个表67g,还有一个小表40Mb。无知的开发人员,以为走index就是快
推荐度:
标签: 手工 不出 5小时
  • 热门焦点

最新推荐

猜你喜欢

热门推荐

专题
Top