新足迹

 找回密码
 注册

精华好帖回顾

· AFL-Footy Tipping (2008-9-5) ukbing · 【我叫小y】 之 某狗1岁啦啦啦~ 1018# (2011-5-14) peanut
· 旅友小韩(原创分享) (2014-12-3) ahyu · 宝宝趣事——还用找吗?(继续骗分分) (2007-9-26) poloand
Advertisement
Advertisement
查看: 1461|回复: 14

大表有11亿条数据,想分区, 求建议! [复制链接]

发表于 2013-7-8 19:55 |显示全部楼层
此文章由 oea 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 oea 所有!转贴必须注明作者、出处和本声明,并保持内容完整
先声明一下, 本人非oracle专业人员,不是开发, 更不是dba, 因为在其他领域比较专业, 临时被抓夫处理这个问题.

数据库是oracle11g 11.0.2.

系统是一个会计的分账应用. 一张大表在线一年, 现有1112813014条数据. (如果我没数错, 应该是11亿多.) 平均每个工作日350万条记录.(一共295个工作日.)

表结构很简单, 单字段主键. 自增形, 值是从sequence来的. 表上没有任何其他索引.

查询基本上是某一时间段(from_date, to_date)的数据(基本是5天范围内), 外加一下其他的条件.

运行效率差可以想像.

好在查询基本是夜间产生报表. sql 加上 hint parallel 跑2,3个小时也没太大关系.  

中间出过一二次大问题, 6,7个小时都运行不完. 最后通过手动减少数据量解决问题.

表的设计和开发者, 已经跳槽到其他公司,很欣慰,不在这祸害了.

随着数据量继续增加, 现在基本的想法就是通过分区(按时间 range) 提高效率.

按天分区,不太可行. 因为周末和节假日根本没有记录进来.

月分区觉得数据太大了.  下面是简单的统计数字


COUNT(*) TRUNC(BAL

---------- ---------

  88375062 01/OCT/12

163326657 01/MAY/13

145804267 01/APR/13

  90561567 01/JUN/13

106122906 01/JAN/13

  98885441 01/DEC/12

110900877 01/FEB/13

  89378244 01/SEP/12

135309877 01/MAR/13

  81850952 01/NOV/12

12 rows selected.


个人感觉按星期分区比较理想.

想在这里请教各位专家.

1) 我的想法是否实际.

2) 如果可行? 有什么注意事项. 重建表, 导入数据,在线修改.

3) 分区后, 从硬件, 维护, 备份的角度, 需要做什么?

4) 如果不可行, 有无其他建议.

如果答案是问dba的话. 可能要失望了. 我们那理dba要是管用, 也就不用哥们我来这里玩票了.

先谢谢大家.
Advertisement
Advertisement

发表于 2013-7-8 20:01 |显示全部楼层
此文章由 卡叔 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 卡叔 所有!转贴必须注明作者、出处和本声明,并保持内容完整
为什么不先索引时间字段?

发表于 2013-7-9 00:03 |显示全部楼层
此文章由 victorzw 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 victorzw 所有!转贴必须注明作者、出处和本声明,并保持内容完整
It depends. If transactional database, partition by year and sub partition by month, move old partition to slow disk and recent partition to fast disk. If DW, can either be solution of above, or bitmap indexing or build an agg tables. While agg table just like cube, should return most of queries in second. But if partition well, and mount to fast SAN disk, a full table scan of 30 millions rows with proper star schema join should take around 10 seconds.

发表于 2013-7-9 00:06 |显示全部楼层
此文章由 victorzw 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 victorzw 所有!转贴必须注明作者、出处和本声明,并保持内容完整
Also, if u use BI tools to generate reports instead of back end scripts, do not use hints. From 10g, oracle handle execution plan very smartly

发表于 2013-7-9 00:06 |显示全部楼层
此文章由 红烧鸡翅 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 红烧鸡翅 所有!转贴必须注明作者、出处和本声明,并保持内容完整
11亿条数据难道天天要用

发表于 2013-7-9 00:33 |显示全部楼层
此文章由 bullying520 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 bullying520 所有!转贴必须注明作者、出处和本声明,并保持内容完整
第一反应也是为啥没有索引.....
Advertisement
Advertisement

发表于 2013-7-9 00:49 |显示全部楼层
此文章由 stevenbian 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 stevenbian 所有!转贴必须注明作者、出处和本声明,并保持内容完整
加3个字段,年,月,日,安上索引,估计飞快

发表于 2013-7-9 04:52 |显示全部楼层
此文章由 很明显 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 很明显 所有!转贴必须注明作者、出处和本声明,并保持内容完整
每天都几百万,是不是应该换hadoop了

发表于 2013-7-9 10:44 |显示全部楼层
此文章由 老衲 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 老衲 所有!转贴必须注明作者、出处和本声明,并保持内容完整
没有任何其他索引

发表于 2013-7-9 10:56 |显示全部楼层
此文章由 Fernando 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 Fernando 所有!转贴必须注明作者、出处和本声明,并保持内容完整
先把你们的 DBA 开掉再说

发表于 2013-7-9 16:07 |显示全部楼层
此文章由 鱼羊鲜 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 鱼羊鲜 所有!转贴必须注明作者、出处和本声明,并保持内容完整
请教各位专家
Advertisement
Advertisement

发表于 2013-7-10 17:56 来自手机 |显示全部楼层
此文章由 典 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 典 所有!转贴必须注明作者、出处和本声明,并保持内容完整
先做Index吧,运气好的话减少到10分钟都有可能。这是Top1的事。
Top2 是增加内存,因为IO 是很慢的,如果内存多就能减少一些IO

分区Partition 或Hint 应该不是那么重要,有帮助但不似index能成倍提高效率。
职业灌水赚分

发表于 2013-7-10 18:01 来自手机 |显示全部楼层
此文章由 典 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 典 所有!转贴必须注明作者、出处和本声明,并保持内容完整
个人觉得怎么做partition取决于你怎么用Query,
如果你的报表只查三个月数据,你就按季度分区。
总之不建议使用。

发表于 2013-7-10 18:41 |显示全部楼层
此文章由 Fernando 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 Fernando 所有!转贴必须注明作者、出处和本声明,并保持内容完整
典说得对。一个普通的index就可以解决了。你们也没有dba,表不动省力点。如果要分区,11g可以自动建 interval 的分区,按天建也没什么。

发表于 2013-7-30 15:58 |显示全部楼层
此文章由 huanged 原创或转贴,不代表本站立场和观点,版权归 oursteps.com.au 和作者 huanged 所有!转贴必须注明作者、出处和本声明,并保持内容完整
先建索引吧,分區是需要額外買license的

发表回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则

Advertisement
Advertisement
返回顶部