不知道大家在工作中的表空间管理情况如何，大体会分为两派。以前的公司我们更喜欢直接把空间都分配好，比如500G的容量规划，那就提前准备500G，另外一类是我先给定200G，后续的空间就自动增长，反正容量还是500G。这个其实很大程度上就是个人习惯和公司流程规范的差别了。

目前成都创新互联已为1000+的企业提供了网站建设、域名、雅安服务器托管、绵阳服务器托管、企业网站设计、柳城网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

   为什么这么说呢，因为我在一套环境上收到了一个奇怪的报警。

DBA:        IP: xxxx       Tablespace: PERFSTAT: 122.5%        [Critical!!]

    关键就在这个122.5%。看起来很不正常，如果这样一个报警找不到问题的症结，那么这个检测表空间的脚本感觉还是有潜在的问题，或者说检测的结果是会让人质疑的。

   从我的了解，这个脚本用了很多年，之前还真没碰到过问题。现在的这套环境就偏偏抛出了错误，我们来挖掘一下。

    首先这个表空间检测的脚本是使用我上面所说的第二种情况，即不断的增大数据文件，给定一个最大值。其实这样算出来不是实际的文件大小情况，和实际结果还是有出入的。

   如果要让你检测一下表孔家使用率该怎么做，很显然我们可以根据数据文件的数据字典来得到一个当前值和文件最大值。

select tablespace_name,
               round(sum(bytes) / (1024 * 1024)) b,
               round(sum(decode(maxbytes, 0, bytes, maxbytes))/(1024 * 1024)) mb
          from dba_data_files
         group by tablespace_name;

另外还有一个视图需要用，是dba_free_space,这个视图的结果得到的是表空间的可用情况，这个视图非常重要。内部会迭代调用一些数据字典来综合得到一个表空间可用率的数据。

select tablespace_name, round(sum(bytes) / (1024 * 1024)) b
          from dba_free_space
         group by tablespace_name;

两者结合起来，最大值减去可用值就是使用率了。我们看看dba_data_files的数值。

SQL> select file_name,bytes/1024/1024 size_MB ,maxbytes/1024/1024 max_MB from dba_data_files where  tablespace_name='PERFSTAT';
FILE_NAME                                             SIZE_MB     MAX_MB
-------------------------------------------------- ---------- ----
/U02/app/oracle/oradata/xxxx/perfstat01.dbf              3100       2000
/U02/app/oracle/oradata/xxxx/perfstat02.dbf             10240       2000

   看到这里感觉很奇怪。最大值maxsize竟然比当前值bytes还要低很多。

   看到这里感觉离bug不远了。但是不管如何这个问题现在来看还不够严重，我们先想办法解决。

    一种思路就是修复一下，我们制定表空间最大值

SQL> alter tablespace perfstat autoextend on maxsize 14G;
alter tablespace perfstat autoextend on maxsize 14G
*
ERROR at line 1:
ORA-32773: operation not supported for smallfile tablespace PERFSTAT

没想到这种模式不支持，oerr的帮助信息提示，我们可以使用alter database datafile的方式来改进。

  所以修复方式就是找到那个数据字典不一致的数据文件，重新做一下设置一下maxsize值。

SQL> alter database datafile '/U02/app/oracle/oradata/xxxx/perfstat02.dbf' autoextend on maxsize 12G;
Database altered.

这样操作之后，再次查看表空间检测脚本，就没有问题了。

我在MOS上看了下，这个问题原来很常见。

Value in BYTES Column Greater than MAXBYTES Column in DBA_DATA_FILES (文档 ID 197244.1)

文档还写出了样例来模拟这个问题。

create tablespace tst
       datafile 'd:\oracle\tst01.dbf' size 5m autoextend on；
alter database datafile 'd:\oracle\tst01.dbf' autoextend on maxsize 10m;
alter database datafile 'd:\oracle\tst01.dbf' resize 20m;
select file_name, bytes, maxbytes, autoextensible from dba_data_files;
FILE_NAME                                     BYTES   MAXBYTES AUT
---------------------------------------- ---------- ---------- ---
D:\ORACLE\TST01.DBF                        20971520   10485760 YES

   看来问题的症结就在于之前做了resize的操作导致。我的处理方式介于两者之间，我喜欢创建一个初始大小的文件，然后resize到一个最大值。看来还是使用方式和习惯的不同在一些场景中会出现较大的偏差。

新闻标题：表空间检测异常的问题诊断
当前地址：http://chengdu.cdxwcx.cn/article/gidgpd.html