ORACLE10g，数据量上亿，表分区该如何维护？

wlsas

目前想了两个方案：
1、表分区
2、定期新建历史表，数据迁移

现在的问题：
1、表分区的方式，对于以前的数据，如果有修改和删除，需要重新建索引，速度非常慢，是否有更好的方法？
2、历史表需要结合应用，还需要改程序，可维护性较差

各位指点，是否还有更好的方法。

[ 本帖最后由 wlsas 于 2008-5-27 18:29 编辑 ]

Bonniefang

历史数据一般不会做修改，建议按照年月分区
若实在要大量修改历史数据可按年创建表，再建立视图，当然建立合适的索引

wlsas

原帖由 Bonniefang 于 2008-5-22 14:59 发表
历史数据一般不会做修改，建议按照年月分区
若实在要大量修改历史数据可按年创建表，再建立视图，当然建立合适的索引

不会大量修改，而且修改的频率也不会很高，关键是这种方案是否合理？

www.netbor.net

作为一个DBA，合理不合理有时要看你自己的看法，从技术上来说，操作是一样的。DBA的决策同样也关系自己日后工作量

numenhuang

原帖由 wlsas 于 2008-5-22 14:45 发表
目前想了两个方案：
1、表分区
2、定期新建历史表，数据迁移

现在的问题：
1、表分区的方式，对于以前的数据，如果有修改和删除，需要重新建索引，速度非常慢，是否有更好的方法？
2、历史表需要结合应用 ...

1. 表根据时间分区，分区key视具体情况。应用相关的sql也要做一些调整
2. 建local index，不要建global index，这样可能牺牲掉一点查询性能，但是便于后期维护，如果要重建索引，也只是重建一个分区的索引。
3. 如果数据增长量比较大，而且很多历史数据查询的话，在分区的同时，增加历史数据清理，根据数据清理策略，定期将一些历史数据迁移到历史服务器中，修改相关查询。

aixcq

顶起来

wlsas

原帖由 www.netbor.net 于 2008-5-23 15:26 发表
作为一个DBA，合理不合理有时要看你自己的看法，从技术上来说，操作是一样的。DBA的决策同样也关系自己日后工作量

关键我还不是DBA，可能还需要细化一下具体细节。我们给客户做，肯定希望日后的维护量能小一些的。

wlsas

原帖由 numenhuang 于 2008-5-25 15:12 发表


1. 表根据时间分区，分区key视具体情况。应用相关的sql也要做一些调整
2. 建local index，不要建global index，这样可能牺牲掉一点查询性能，但是便于后期维护，如果要重建索引，也只是重建一个分区的索引。
3. 如果数据增长量比较大，而且很多历史数据查询的话，在分区的同时，增加历史数据清理，根据数据清理策略，定期将一些历史数据迁移到历史服务器中，修改相关查询。

感谢回复。

1、应用相关的sql也需要调整？以前用过建历史表，那时候是动态根据时间来调整sql语句，用分区做也要对sql调整？
2、这个建议很好，之前还没考虑过，不过我想知道按照这个方式做了之后，一亿数据量count一次，大约需要多长时间？
3、这个不是我们这次考虑的了，迁移历史服务器也是几年后的事情了。。

wlsas

我还有一个问题，这个方案计划用服务器定时任务来执行分区切换。

假如把1个月前的数据迁移到另外一个分区，具体是怎么操作呢？需要用临时表做过渡吗

numenhuang

原帖由 wlsas 于 2008-5-26 14:26 发表



感谢回复。

1、应用相关的sql也需要调整？以前用过建历史表，那时候是动态根据时间来调整sql语句，用分区做也要对sql调整？

这里说的应用调整，是指分区后，要核查相关sql的执行规划和效率是否有变化。如果是10g，还要采集分区表的统计信息，要关注分区带来的对现有sql执行效率的影响。