ORA-01628:max # of extents num reached for rollback segment num ！

产生原因：这种错误通常为一个回滚段和一个表空间已经达到MAXEXTENTS参数设置的极限。要注意的是这个MAXEXTENTS不是该回滚段或表空间的硬件极限，硬件极限取决于数据库创建时在init.ora文件中指定的DB_BLOCK_SIZE参数的值。

解决方法：使用SQL命令ALTER TABLESPACE…STORAGE（MAXEXTENTS XXXX）来增加 MAXEXTENTS，其中“XXXX”值必须大于错误信息中所指的数值，但不能大于LARGEST MAXEXTENT的值，如果已经达到了LARGEST MAXEXTENT VALUE，解决的办法就是重新创建较大的范围尺寸，使用带有选项COMPRESS=Y的Export工具导出表，如果表空间有可用空间，先给表做一个备份，用alter tablespace tablespace_name更改其名字，然后再装载表回数据库。查看其错误出现的地方，如果出现在回滚段或索引上，那么必须将其删除并重建，如果出现在临时表空间，修改临时表空间的存储字段，便可解决这个问题。
一个报错例子如下：

ORA-1628: max # extents  32765 reached for rollback segment _SYSSMU27_174648622$
ORA-1628: max # extents  32765 reached for rollback segment _SYSSMU27_174648622$

其实_SYSSMU29_3371171581$就是一个回滚段的名字，在dba_segments里面可以查看到相关信息：

SQL> select SEGMENT_NAME,TABLESPACE_NAME,MAX_EXTENTS from dba_segments where segment_name = '_SYSSMU29_3371171581$';

SEGMENT_NAME              TABLESPACE_NAME                                              MAX_EXTENTS
------------------------- ------------------------------------------------------------ -----------
_SYSSMU29_3371171581$     UNDOTBS1                                                           32765

可以看见是undo表空间上面，我们再看看这个undo表空间的使用情况：

SQL> select ts#,name from v$tablespace where name = 'UNDOTBS1';

TS# NAME
---------- ------------------------------------------------------------
2 UNDOTBS1

SQL> select name,BYTES/1024/1024/1024,CREATE_BYTES/1024/1024/1024,FILE# from v$datafile where ts# = 2;

NAME                                                         BYTES/1024/1024/1024 CREATE_BYTES/1024/1024/1024      FILE#
------------------------------------------------------------ -------------------- --------------------------- ----------
+DG01DATA/unicom/datafile/undotbs1.258.763070125                       1273.99414                    1.953125          3

SQL> select FILE_ID,FILE_NAME,TABLESPACE_NAME,BYTES/1024/1024/1024,MAXBYTES/1024/1024/1024 from dba_data_files where TABLESPACE_NAME = 'UNDOTBS1';

FILE_ID FILE_NAME                                          TABLESPACE_NAME                                              BYTES/1024/1024/1024 MAXBYTES/1024/1024/1024
---------- -------------------------------------------------- ------------------------------------------------------------ -------------------- -----------------------
3 +DG01DATA/unicom/datafile/undotbs1.258.763070125   UNDOTBS1                                                               1273.99414                  131072

可以看见这个undo表空间并没有使用满，下面再看看数据库的当前正在使用的undo表空间：

SQL> select sid,name,value from v$spparameter where name = 'undo_tablespace';

SID        NAME                           VALUE
---------- ------------------------------ ------------------------------
*          undo_tablespace                UNDOTBS3

SQL> select ts#,name from v$tablespace where name like 'UNDO%';

TS# NAME
---------- ------------------------------
2 UNDOTBS1
375 UNDOTBS3

SQL> select SEGMENT_NAME,TABLESPACE_NAME,STATUS from dba_rollback_segs where TABLESPACE_NAME = 'UNDOTBS1' and status = 'ONLINE';

未选定行

可以看见数据库当前使用的已经是UNDOTBS3这个undo表空间，其实解决办法就是重建undo表空间也就OK了。下面是在网上搜到的一个解决办法，没有试过：

alter rollback segment "_SYSSMU27_174648622$" storage(maxextents unlimited);