一个超大Table切换成分区的经历
近日，公司要求将一个Table做优化，原因是因为在基于这个Table做查询时异常慢。
看了下这个Table的基本情况，表有27G大小，有两个索引，一个索引24G，一个索引15G，
超大啊。这种情况，明显要做分区。看了下Table的结构，数据是按日期插入的，考虑到
以后删除的需要，采取用按月来做分区。由于每天都有近百万的数据量，只用range的方式
是不行了，只好采用range-hash的方式。
在设子分区的数量时，走了一些弯路。开始盲目的将子分区数设的很大，每个分区设了
1024个子分区。结果测试时，竟然比原来还要慢。看来分区数不能瞎设啊。做了多次实验，
在考虑到以后的发展，最后子分区数定为16个，测试后性能比原来要快10%左后，相当满意了。
在生产数据库上创建时，由于业务繁忙，连续两次做了10个小时也没完成，看来在正常
上班时间是完成不了了。抽了个周末，用时6个小时就搞定了。
正式创建时，由于分区所在的表空间是UNIFORM的，竟然花了34G，真是浪费，两个索引
一个用local,占用空间12G；一个用global，占用14G。两个索引的栏位都相同，只是顺序不同，
竟然空间占用还不一样。
在做分区数测试时发现，分区数并不是越多越好，它和设备有很大的关系。设备好，多设些
确实可以提示性能，设备差，还是少设些吧。[@more@]
看了下这个Table的基本情况，表有27G大小，有两个索引，一个索引24G，一个索引15G，
超大啊。这种情况，明显要做分区。看了下Table的结构，数据是按日期插入的，考虑到
以后删除的需要，采取用按月来做分区。由于每天都有近百万的数据量，只用range的方式
是不行了，只好采用range-hash的方式。
在设子分区的数量时，走了一些弯路。开始盲目的将子分区数设的很大，每个分区设了
1024个子分区。结果测试时，竟然比原来还要慢。看来分区数不能瞎设啊。做了多次实验，
在考虑到以后的发展，最后子分区数定为16个，测试后性能比原来要快10%左后，相当满意了。
在生产数据库上创建时，由于业务繁忙，连续两次做了10个小时也没完成，看来在正常
上班时间是完成不了了。抽了个周末，用时6个小时就搞定了。
正式创建时，由于分区所在的表空间是UNIFORM的，竟然花了34G，真是浪费，两个索引
一个用local,占用空间12G；一个用global，占用14G。两个索引的栏位都相同，只是顺序不同，
竟然空间占用还不一样。
在做分区数测试时发现，分区数并不是越多越好，它和设备有很大的关系。设备好，多设些
确实可以提示性能，设备差，还是少设些吧。[@more@]
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/106358/viewspace-1046873/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
Oracle 合并行/多行合并成一行
请登录后发表评论
登录
全部评论
