最近帮助开发的同学处理了一个简单的问题，想通过这个问题来反思一下。     在一天下午的时候，开发的同事突然找到我说，有一个开发的数据库貌似有些表空间的问题，尽管这个数据库是划分在他们名下，但是对于数据库的操作他们还是没底，想让我帮忙看看，当然对于这类问题，我都脑海里闪现一两分钟搞定问题的成就感了。刚好下午有些事情，就叫了另外一个新同事去练练手，但是过了一会儿，新同事给我打来了电话，说现在好像有些问题，目前他们的库使用的是bigfile tablespace,对于这类表空间，添加数据文件是不行的，然后他尝试了resize竟然也不成功。我脑海里搜索关于bigfile的内容，没有搜索到相关的太多信息，实际工作中这个特性真只是一个特性而已，实践意义应该不大，难得开发的同学这么时髦，竟然用了这个特性。    于是我叫新同事去看看是不是哪里的操作不对，如果实在不行，看看操作系统级是不是没有空间了，他反馈说开发的同学目前还没有权限登录操作系统，他们目前使用的是客户端工具连接。对于这类问题，看起来情况似乎已经非常明显了，但是好像又好像探不到底。于是我建议他，这类空间的，如果实在resize不了，可以再新建一个表空间，把用户的默认表空间改到这个新的表空间应该就可以了。新同事忙活了一会，看起来还是没有起色。在忙完手头的工作之后，我就到开发的同学那里去看看真伪。     到了现场之后，发现这位同事已经尝试了不少的方法。简单了解了问题的前因后果，发现这确实是一个使用了bigfile tablespace的库，数据文件目前已经有50G，开发的同学在调用一个存储过程的时候会抛出空间不足的ORA错误。而且新同事已经创建了一个新的表空间，目前先分配了50M的空间，但是执行这个存储过程还是报错。 为了排除各种影响，我们就一个一个来分析。首先是这个bigfile tablespace的问题，既然抛出了空间不足的错误，怎么使用resize的时候会有问题呢，这类表空间里面只对应一个数据文件，文件可以无限膨胀，达到TB级别都是很容易支持的。对于一个只有50G的数据文件而言，是在是太小儿科了。而同事在同一个目录下面创建了一个表空间，足以说明这个目录下面还是有空间的。所以这个现象就比较奇怪，我再次确认，他使用的命令情况，他是使用resize尝试把数据文件调到100G,50G到100G里面还是有太多的变数，于是我就保守了一下，调到了60G，稍等一会之后，从客户端看命令就执行成功了。从这一点来看，就可以反推出来，这个问题应该不是bug导致，而是由于操作系统的空间剩余在50G以内，导致resize 为100G的时候出错。首先这个问题确认了，问题就解决了一大半，开发同学再次尝试这个存储过程，发现就没有任何错误了，可见问题的解决已经告一段落，那么我们来解释另外几个问题。    问题1:对于bigfile tablespace的表空间，默认都是开启了自动扩展的，为什么这个表空间到了50G就出问题了呢？    问题2：另外一个问题是对于新增的表空间，为什么运行存储过程依旧报错。    问题3：最后一个问题是这个问题后续改怎么改进。 对于第一个问题，自己也着实有些纠结，不过查看一些信息就会明白了。首先表空间CYTJ是一个bigfile tablespace,其它的表空间都是smallfile tablespace. SQL> select tablespace_name,next_extent,bigfile from dba_tablespaces; TABLESPACE_NAME                NEXT_EXTENT BIG ------------------------------ ----------- --- CYTJ_DATA                                  YES TEMP_DATA                          1048576 NO CYTJ_DATA01                                NO 对于这个表空间而言，可以通过查看数据文件的数据字典来查看maxsize了。可以看到目前是61440M。可见这个表空间在创建开始就是指定了50G的maxsize. SQL>select tablespace_name,file_name,bytes/1024/1024 size_MB,bytes/1024/1024 max_size_MB from dba_data_files TABLESPACE_NAME      FILE_NAME                                             SIZE_MB MAX_SIZE_MB -------------------- -------------------------------------------------- ---------- ----------- USERS                /U01/app/oracle/oradata/cytj/users01.dbf                    5           5 CYTJ_DATA            /home/oracle/tablespace/cytj_data.dbf                   61440       61440 CYTJ_DATA01          /home/oracle/tablespace/cytj_data01.dbf                    50          50 当然要看到更多的信息，还是登陆到数据库端去查看日志了，然后让开发同事继续协调，他们连进了操作系统，使用df -h一下子就可以看出来确实是文件系统的空间不足，目前只剩下5G左右的空间了，而从数据库日志里面，可以赫然发现，这个表空间在很早的时候就创建了。 create bigfile tablespace cytj_data logging datafile '/home/oracle/tablespace/cytj_data.dbf' size 10G autoextend on next 200m maxsize 50G extent management local Wed Nov 26 11:45:15 2014 Completed: create bigfile tablespace cytj_data 有了这些一切都明了了。 对于问题2： 为什么新增了表空间之后，运行存储过程依旧报错，这个经过排查发现，同事对里面的用户都指定了新的表空间为more表空间，唯独漏了当前用户，这个也算是操作不够谨慎，所以给开发的同事简单创建一个表验证一下，就很清晰了。 第3个问题。这个问题后续的改进。 可以从数据库日志看出。这个问题其实已经发生很久了。 但是直到最近才被开发的同学重视起来，可能有一些功能缺失需要，产生了很大的影响，所以才被重视了起来，如果细细扒开来看，这个问题发生了已经快半年了。 Thu Mar 03 15:43:34 2016 ORA-1653: unable to extend table REPORTS.CLIENTSTATDATA_REAL by 128 in                 tablespace CYTJ_DATA ORA-1653: unable to extend table REPORTS.CLIENTSTATDATA_REAL by 1024 in                 tablespace CYTJ_DATA 但是明白了问题之后，发现其实都是很简单，从目前他们使用数据的情况来看短期内不会出现问题，但是从长远考虑，目前的硬盘配置有些低了，只剩余5G的空间是有些捉襟见肘了。需要进一步扩容。当然更多的数据库相关的工作我还是乐于支持的。从这个看起来非常不经意的案例中，我们发现很多问题其实早就产生在了萌芽之中，如果不重视，就会逐步扩大影响，如果在这个期间出现了严重的问题，那就很可能是不可恢复的灾难，从这也可以窥探出如果管理不够专业和规范，很容易出现各种奇怪的问题，问题要扼杀在摇篮之中。