最近帮助开发的同学处理了一个简单的问题,想通过这个问题来反思一下。
在一天下午的时候,开发的同事突然找到我说,有一个开发的数据库貌似有些表空间的问题,尽管这个数据库是划分在他们名下,但是对于数据库的操作他们还是没底,想让我帮忙看看,当然对于这类问题,我都脑海里闪现一两分钟搞定问题的成就感了。刚好下午有些事情,就叫了另外一个新同事去练练手,但是过了一会儿,新同事给我打来了电话,说现在好像有些问题,目前他们的库使用的是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的空间是有些捉襟见肘了。需要进一步扩容。当然更多的数据库相关的工作我还是乐于支持的。从这个看起来非常不经意的案例中,我们发现很多问题其实早就产生在了萌芽之中,如果不重视,就会逐步扩大影响,如果在这个期间出现了严重的问题,那就很可能是不可恢复的灾难,从这也可以窥探出如果管理不够专业和规范,很容易出现各种奇怪的问题,问题要扼杀在摇篮之中。
在一天下午的时候,开发的同事突然找到我说,有一个开发的数据库貌似有些表空间的问题,尽管这个数据库是划分在他们名下,但是对于数据库的操作他们还是没底,想让我帮忙看看,当然对于这类问题,我都脑海里闪现一两分钟搞定问题的成就感了。刚好下午有些事情,就叫了另外一个新同事去练练手,但是过了一会儿,新同事给我打来了电话,说现在好像有些问题,目前他们的库使用的是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的空间是有些捉襟见肘了。需要进一步扩容。当然更多的数据库相关的工作我还是乐于支持的。从这个看起来非常不经意的案例中,我们发现很多问题其实早就产生在了萌芽之中,如果不重视,就会逐步扩大影响,如果在这个期间出现了严重的问题,那就很可能是不可恢复的灾难,从这也可以窥探出如果管理不够专业和规范,很容易出现各种奇怪的问题,问题要扼杀在摇篮之中。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2051060/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23718752/viewspace-2051060/