Oracle大数据查询问题(求助)!!! 大数据oracle优化 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 题主目前的境况好像很迷糊,无处着手,其实对于效率的优化基本都有一下几条路子: 1、索引: 通过执行计划分析是否有走索引,没有的就创建 2、维表:如果业务事实表中存在很多维度的范式存储(类外键ID),而且当对于的维度数据量较少时,如状态等通过简单枚举可以对应时,可省略关联直接进行字段decode 3、你的T2、T3应该是属性类维表,如果实在是语句上没办法了,直接将这些表转为buffer_pool keep类型的吧,走内存表,匹配效率大大提高 4、当你光光从T1进行select就很慢时,检查IO、NET、你链接程序的吞吐量了。 5、NET、吞吐量正常,检查服务器了,如果服务器不能动(很多这种情况),像你这种线性增长的表设计上不可能就这样让他一直这样下去活下去的!(哥们曾经遇到过1张360亿量的事实表,不过哥们走的IQ数据库),果断拆之(分区也是个好选择)。 select thmr.rela_id, tmi.base_no, tci.company_name, tmi.medicine_name, tmi.stop, tmi.medicine_id, tmi.medicine_type, tmi.medicine_made, tmi.medicine_code, tmi.currency_name, tmi.gsp_id, tmi.list_id, tmi.standard, tmi.drug_form, tmi.quality_level, tmi.packaging, tmi.packaging_amount, tmi.bid_unit, tmi.unit_price, tmi.pack_price, tmi.retail_price, tmi.limited_retail_price, tmi.limited_retail_price_explain, tmi.gov_no, tmi.urban_no, tmi.antibiotics_no, tmi.rural_no, tmi.bid_type, tmi.max_price, thmr.bargain_time, thmr.purchase_price, thmr.bargain, thmr.sts, thi.h_id, thi.h_name from T1 thmr left join t2 tmi on (thmr.m_id = tmi.m_id) left join T2 tci on (tmi.company_id = tci.company_id) left join T3 thi on (thmr.h_id = thi.h_id) where 1 = 1 and thmr.sts is null;sql类似这个增加 and thmr.sts is null;之后,查询速度很慢了! 关系数据库做多表关联时就是很慢,能优化的地方无非就是再加入并行选项(Oracle的写法是seelct /* parallel(n) */ …)充分利用多CPU核,但如果有多人并发访问这些数据库,并行选项又会不起作用了,而且其中某些并发任务的性能会不成比例的急剧下降数十倍(远不是平均的线性下降)。这种运算在ORACLE里除了再加大服务器内存这种硬件扩容的办法外,基本上就没有办法变快了。这种情况应当把数据外置,直接用文件访问获得更高的IO效率,同时也是更便宜的解决方案。而且2K和8K的维表是很小的,完全可以全读入内存处理,只把那个2KW的大表用流式方式遍历一次即可,如果不关心结果集的次序(比如只计算汇总值),还可以用并行方法遍历以提高性能。使得文件存储还可以灵活决定是否使用列式存储以获得更高的性能。可以试试使用润乾集算器来完成上述运算,集算器支持内存小维表连接和大数据表流式读入,也能方便地能写出多线程并行计算。如果数据量再大,还可以使用多机并行的方式进一步提高性能。在有大数据多表连接的情况下,集算器的性能经常能超过ORACLE,而且并发时更稳定(线性下降)。可参考http://blog.raqsoft.cn/?p=360,完整的测试报告下载 .上述问题用集算器代码写出来大概是这样(假定对遍历后的数据再分组汇总): 应该是数据量太大,加上is null筛选太慢 多线程访问ORACLE共有资源 一个itpub没人解决的问题 oracle触发器!帮帮忙! 请教高手一个棘手的问题 windows 系统连接linux下的oracle服务问题 求一查询语句,困扰了许久 这段脚本中的L 和 ;是什么意思? 如何将oracle9i数据移植到sybase11.0.3上 请问在同一操作系统下可以同时安装SQL Server和Oracle吗? 9i中的Date类型是怎么样的格式? 关于sql的问题,求解!! 存储过程分页
1、索引: 通过执行计划分析是否有走索引,没有的就创建
2、维表:如果业务事实表中存在很多维度的范式存储(类外键ID),而且当对于的维度数据量较少时,如状态等通过简单枚举可以对应时,可省略关联直接进行字段decode
3、你的T2、T3应该是属性类维表,如果实在是语句上没办法了,直接将这些表转为buffer_pool keep类型的吧,走内存表,匹配效率大大提高
4、当你光光从T1进行select就很慢时,检查IO、NET、你链接程序的吞吐量了。
5、NET、吞吐量正常,检查服务器了,如果服务器不能动(很多这种情况),像你这种线性增长的表设计上不可能就这样让他一直这样下去活下去的!(哥们曾经遇到过1张360亿量的事实表,不过哥们走的IQ数据库),果断拆之(分区也是个好选择)。
tmi.base_no,
tci.company_name,
tmi.medicine_name,
tmi.stop,
tmi.medicine_id,
tmi.medicine_type,
tmi.medicine_made,
tmi.medicine_code,
tmi.currency_name,
tmi.gsp_id,
tmi.list_id,
tmi.standard,
tmi.drug_form,
tmi.quality_level,
tmi.packaging,
tmi.packaging_amount,
tmi.bid_unit,
tmi.unit_price,
tmi.pack_price,
tmi.retail_price,
tmi.limited_retail_price,
tmi.limited_retail_price_explain,
tmi.gov_no,
tmi.urban_no,
tmi.antibiotics_no,
tmi.rural_no,
tmi.bid_type,
tmi.max_price,
thmr.bargain_time,
thmr.purchase_price,
thmr.bargain,
thmr.sts,
thi.h_id,
thi.h_name
from T1 thmr
left join t2 tmi
on (thmr.m_id = tmi.m_id)
left join T2 tci
on (tmi.company_id = tci.company_id)
left join T3 thi
on (thmr.h_id = thi.h_id)
where 1 = 1
and thmr.sts is null;
sql类似这个增加 and thmr.sts is null;之后,查询速度很慢了!