新足迹 › 论坛 › 兴趣爱好区 › IT与科技 › IT专业论坛 › 大表有11亿条数据,想分区, 求建议!

精华好帖回顾
· 铺复合地板的小窍门 (2009-9-11) dbsdsun	· 复苏的火山, 沉寂的庞贝-(照片上完) (2007-12-28) jeru
· 人生旅途——Port Lincoln-Eucla-Perth-Shark Bay-Exmouth-Broome-Kununurra-完结 (2025-1-15) 小小白虎	· 东东爹教你在家做西餐---更新: wagyu beef tataki (2012-5-14) mickeymickey

查看: 1580|回复: 14

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

oea

光脚族

发表于 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要是管用, 也就不用哥们我来这里玩票了.

先谢谢大家.

卡叔

皮靴族

发表于 2013-7-8 20:01 |显示全部楼层

此文章由卡叔原创或转贴，不代表本站立场和观点，版权归 oursteps.com.au 和作者卡叔所有！转贴必须注明作者、出处和本声明，并保持内容完整

为什么不先索引时间字段？

victorzw

草鞋族

发表于 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.