表中是否原来有数据，创建分区的SQL是怎样的，表空间目前还剩余多少空间，表上是否有global索引

表是创建的新表，L GY_GNLK_201905为10个G空表，temp表也坐了扩大，创建分区表的语句如下：alter table t_gnlk split partition LGY_GNLKZP_MAX at (TO_DATE(' 2019-06-0100:00:00', 'YYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) into (partition LGY_GNLK_201905 tablespace LGY_GNLK_201905,partition LGY_GNLKZP_MAX) UPDATE GLOBAL INDEXES; 

split是拆分分区，split时至少需要两倍的空间，也就是LGY_GNLK_201905至少需要20G。

如果是空表，且占用了10g的空间，建议先MOVE一下分区，然后再进行SLPLIT。

我把分区表又新加了10g的表空间，已经执行250分钟了  还在执行，对于这样的情况是有什么情况卡住了，还是在执行中

如果表真的如你所说是空的，那么即使初始空间有10G，这个操作也应该在1分钟之内结束。

出现了这么长的等待，说明当前操作被挂起，检查一下高级日志，看看是否有报错信息。

在其他会话中检查一下V$SESSION视图，看看当前会话处于何种等待

在原有的大表中创建月份的分区表，T_GNLK表中有数据79855920，新建的5月分区表目前为空

感觉你的描述有点混乱。这张表到底是新表还是原本有数据的表？

你的操作是在SPLIT一个新的分区，不是新建一个分区表。

也就是说，这张表原本是包含很多数据的，你在SPLIT最后一个分区的时候遭遇了ORA-1652错误？

你先通过下面的查询，看看你要SPLIT的这个分区的数据量：

select count(*) from t_gnlk partition LGY_GNLKZP_MAX

t_gnlk表中有数据，select count（*） from t_gnlk partition（LGY_GNLKZP_MAX）查询的数量为35845505，周二早起开始执行分区脚本，执行了400多分钟没有结果，业务说他们解不进去包，不得不把分区操作进行停止，能帮忙分析问题的所在吗？

请在业务空闲时间，并确保空间充足的情况下操作。

还有其他解决的办法吗？

分步操作吧，先不管全局索引，等split完之后再重建失效索引

我把201905的分区表创建了不要索引，如果数据进去，会不会查询的时候比较慢，影响业务

必然会影响

那我先把分区表建上，后续把原来主表里的索引也在新建的分区表，应该跟在创建分区表的时候创建的全局索引效果应该是一样的吧？

split会导致全局索引失效，应用无法使用该索引，需要重建索引。

建议：首先写好方案，测试环境测试，申请停机窗口正式变更。

除了这种办法还有其他的方式吗？ 不行就等业务空闲，我就执行看他具体执行多久，还有一个问题，我执行分区表操作的时候，如果再创建下一个分区表说主表目前为占用状态无法使用，有办法解决这个问题吗？

如果出现ORA-54的错误，说明在执行DDL的时刻有并发的DML操作尚未提交。最简单的办法是等待空闲时刻再进行操作。如果是11g，可以考虑设置ddl_lock_timeout > 0，这样允许DDL进入队列，而不是直接报错。

至于你提到的有没有可能不进行更待，实际上是有方法的。

你现在之所以会出现很长的等待时间，是因为你SPLIT分区的时候，会导致MAX分区的数据重新分配，造成了索引的失效。

如果快速的避免这个问题，可以考虑SPLIT的时候，查看当前分区中分区键值最大的记录，然后SPLIT的时候指定一个分区的范围，保证MAX分区中现有数据可以完全SPLIT到这个分区中，这样相当于把MAX分区的数据切到了一个历史分区，比如分区键值小于TO_DATE('201907', 'YYYYMM')，和一个完全空的MAX分区。

这样由于不会导致任何数据的变化，因为全局索引也不会被置于INVALID，整个操作应该可以在秒级结束。

至于后续是否需要将这个包含大量数据的分区进一步拆分，可以慢慢考虑。

alter table t_gnlk split partition LGY_GNLKZP_MAX at (TO_DATE(' 2019-06-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) into (partition LGY_GNLK_201905 tablespace LGY_GNLK_201905,partition LGY_GNLKZP_MAX) UPDATE GLOBAL INDEXES; 针对这个语句就行修改一下可以吗，帮忙设置一个时间范围LGY_GNLK_201905为五月份的数据，只存放五月份的数据，比如设置时间最小为5.1最大为5.31

一个范围分区存储的数据是大于等于前一个分区的分区边界条件，小于当前分区的边界条件。

所以，你的这条语句执行完，SPLIT的分区中包含的记录为小于6月1日，大于前一个分区边界的所有数据。

如果你想要确保这个分区保存的是5月份的数据，你需要先把存储4月份数据的分区SPLIT出来

我的最大分区表是到2018年9月  这样的话必须把之前的都不上再操作吧？

如果必须要求每个月存储在一个独立分区下，那么你就必须把所有的分区都补上。

如果你确实打算这么做，我建议你把GLOBAL INDEX的定义取一下，然后直接把全局索引都删掉，把所有的分区SPLIT之后，在重新创建索引，比直接SPLIT操作UPDATE INDEX要快得多。

当然，最好申请运维窗口来进行上述的操作

大表t_gnlk中只保留一年的数据，其他的数据比如说2018年3月的数据放到2018历史表中，把201803分区表的索引进行更新，然后删除历史分区表，我觉得2018年的10.11.12以及2019年1.2.3.4月份的分区表没必要创建，只保留一年的数据，到了2019年5月，2018年4月份的数据就可以放到2018年历史分区表中

其实这就是我之前说的，如果你不一定要追求一个分区放一个月的数据，可以创建一个小于5月的分区，把9月之后所有的数据都切分过去，一般情况下是每个月进行老数据的清理，只不过这个分区的清理可以等到20年的5月。

另外，如此频繁进行分区操作的分区表，不应该创建全局索引，联合应用一起看看是否可以改为LOCAL索引，这样后续删除分区等操作就不会导致索引失效了。

能提供相关的语句吗？

我也是刚接手这个项目，交接也没有交代清楚，客户也不懂，运行时间很久了，不想做大的改动

创建索引的时候在结尾出增加LOCAL关键字

索引不需要创建，只需要在创建分区的时候进行更新，目前遇到的问题是按月创建分区表执行不出来结果