1. 组合分区表的创建方式（"范围-哈稀"），见附1
创新互联专注于石泉网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供石泉营销型网站建设，石泉网站制作、石泉网页设计、石泉网站官网定制、小程序开发服务，打造石泉网络公司原创品牌,更为您提供石泉网站排名全网营销落地服务。
2. 楼主的需求，即"范围-范围分区"，在ORACLE 9i, 10g经过测试都是不能实现的
在附1的基础上修改为"范围-范围"组合分区，创建时报错：ORA-14151：无效的表分区方法
3. 关于sxdtgsh兄的回答，我测了
3.1 没有maxvalue上限分区设置，在插入超出分区的数据时会报错ORA-14400: 插入的分区关键字未映射到任何分区
3.2 按回答的语句创建分区表没有问题，但数据无法按照楼主的需求分布
＝＝＝＝附1
附录：创建"范围-哈稀"组合分区表
CREATE TABLE TAB11 (ID NUMBER,DT DATE)
PARTITION BY RANGE (DT)
SUBPARTITION BY HASH (ID) SUBPARTITIONS 2 -- 自分区个数，可以不写，由系统判断
(
PARTITION Y2012 VALUES LESS THAN (TO_DATE('2013-01-01','YYYY-MM-DD'))
(
SUBPARTITION Y2012_H1
,SUBPARTITION Y2012_H2
)
,PARTITION Y2013 VALUES LESS THAN (TO_DATE('2014-01-01','YYYY-MM-DD'))
(
SUBPARTITION Y2013_H1
,SUBPARTITION Y2013_H2
)
,PARTITION YMAX VALUES LESS THAN (MAXVALUE)
(
SUBPARTITION YMAX_H1
,SUBPARTITION YMAX_H2
)
)
＝＝＝＝附2，请楼主检查最后查询的数据分布
create table T_TEST
(
ID NUMBER(20) NOT NULL,
TIME DATE NOT NULL
)
partition by range(TIME, ID) -- 按时间、ID范围分区 这个例子是按年的
(
partition P_2012_10 values less than (to_date('2013-01-01','yyyy-MM-dd'), 10),
partition P_2012_20 values less than (to_date('2013-01-01','yyyy-MM-dd'), 20),
partition P_2012_MAX values less than (to_date('2013-01-01','yyyy-MM-dd'), MAXVALUE),
partition P_2013_10 values less than (to_date('2014-01-01','yyyy-MM-dd'), 10),
partition P_2013_20 values less than (to_date('2014-01-01','yyyy-MM-dd'), 20),
partition P_2013_MAX values less than (to_date('2014-01-01','yyyy-MM-dd'), MAXVALUE),
partition P_MAX values less than (MAXVALUE,MAXVALUE)
);
INSERT INTO T_TEST VALUES (1,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (12,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (32,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (2,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (12,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (33,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (3,TO_DATE('20141204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (23,TO_DATE('20141204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (43,TO_DATE('20151204 00:00:00','YYYYMMDD HH24:MI:SS'));
SELECT * FROM T_TEST;
SELECT * FROM T_TEST PARTITION(P_2012_10);
SELECT * FROM T_TEST PARTITION(P_2012_20);
SELECT * FROM T_TEST PARTITION(P_2012_MAX);
SELECT * FROM T_TEST PARTITION(P_2013_10);
SELECT * FROM T_TEST PARTITION(P_2013_20);
SELECT * FROM T_TEST PARTITION(P_2013_MAX);
SELECT * FROM T_TEST PARTITION(P_MAX);
配置不同的oracle用户就相当于不同的databases;比如system,scott
dataHost name="oracle1" maxCon="1000" minCon="1"balance="0" writeType="0" dbType="oracle" dbDriver="jdbc"
heartbeatselect1 from dual/heartbeat
connectionInitSqlaltersession set nls_date_format='yyyy-mm-dd hh24:mi:ss'/connectionInitSql
writeHosthost="hostM1" url="jdbc:oracle:thin:@localhost:1521:orcl"user="system" password="123456" /
/dataHost
dataHost name="oracle2" maxCon="1000" minCon="1"balance="0" writeType="0" dbType="oracle" dbDriver="jdbc"
heartbeatselect1 from dual/heartbeat
connectionInitSqlaltersession set nls_date_format='yyyy-mm-dd hh24:mi:ss'/connectionInitSql
writeHosthost="hostM1" url="jdbc:oracle:thin:@localhost:1521:orcl"user="scott" password="123456" /
/dataHost
oracle暂时没有这个功能。
关于你说的“oracle分区表还是不能解决几百亿数据存量下的插入性能”是什么意思？是将数据插入这么多记录的表上性能无法保证，还是太大并发会导致性能问题？
另外，如果你的并发不太大，而且还想实现分表，可以通过触发器实现啊
其实不需要拆分表，分区就可以，还是原来的表名，只是将原来的表分成了若干的分区，这样能起到分表的效果，还不用分成很多的表。
比如你原来的表的名字是A，那么将该表改为A1，然后从新建立一个分区表A，分区的依据是班级，也就是list分区，也就是一般意义上的列表分区表。
然后再将A1的数据插入新A表就可以了。
至于分区表的建立方式，往上很多，可以自行查找。
这样操作查询的语句不需要变，只是在不跨分区查询的情况下，相当于分成了若干张表去查询。比如查询1班的成绩，那么就是在1班的分区内，不会有2班的问题，就相当于你用一个指头就能解决问题，不会动用这个手一样。
如果分表的话，那么假设有12个班，那么就要建立12张表，这样的话，语句就要写12次，冗余太大了。
1 基本思想之什么是分库分表？
从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表？
数
据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增
删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
3.2
何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库
上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、
part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，
然后将这些表按照一定的规则存储到多个userDB上。
3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体
的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。
4 分库分表存在的问题。
4.1 事务问题。
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
4.2 跨库跨表的join问题。
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
4.3 额外的数据管理负担和数据运算压力。
额
外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于
一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order
by语句就可以搞定，但是在进行分表之后，将需要n个order
by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。
这个要看你是什么数据库。
Oracle 或者 SQL Server 企业版本的， 可以尝试使用 分区表来处理。
如果对 分区表不熟悉， 或者不高兴折腾。
SQL Server 可以尝试使用 分区视图的方式来处理。
