操作步骤共分为三步：
总结：
1、去服务器桌面打开cmd→sqlplus/nolog→conn sys/admin as sysdba
2、输入下面第一段命令,查看哪个表空间使用率达到90%
3、达到90%以上的运行第二段命令，拓展空间即可解决
一、表空间报错如下图
二、打开CMD输入：sqlplus/nolog 如下图
继续输入命令：conn sys/admin as sysdba ， 如下图
三、输入第一段命令(关键一步)
SELECT a.tablespace_name "表空间名", total "表空间大小", free "表空间剩余大小", (total - free) "表空间使用大小", total / (1024 * 1024 * 1024) "表空间大小(G)", free / (1024 * 1024 * 1024) "表空间剩余大小(G)", (total - free) / (1024 * 1024 * 1024) "表空间使用大小(G)", round((total - free) / total, 4) * 100 "使用率 %" FROM (SELECT tablespace_name, SUM(bytes) free FROM dba_free_space GROUP BY tablespace_name) a, (SELECT tablespace_name, SUM(bytes) total FROM dba_data_files GROUP BY tablespace_name) b WHERE a.tablespace_name = b.tablespace_name;
反馈如下图:
备注：上面的图片需要看的重点是使用率，达到90%的都需要进行拓展空间
然后输入第二段命令进行查询路径：
select tablespace_name, file_id, file_name,round(bytes/(1024*1024),0) total_space from dba_data_files  order by tablespace_name; 
反馈如图：
然后输入第三段命令(关键一步)：alter tablespace SYSAUX add datafile 'D:\oracle\oradata\orcl\SYSAUX02.DBF' size 30000M;
运行后会出现卡顿，看服务器的配置，一般10分钟就可以处理完。
反馈如图：
就这样完成了
	

解决undo 表空间过大导致磁盘空间不足的问题
undo表空间不断扩大问题的原因：1有较大的事务量让oracle undo 自动扩展，产生过度占有磁盘空间的情况。2有较大事务没有收缩或者没有提交所导致。

  

1.查看还原表空间所在磁盘是否使用率过高，及linux 系统哪个磁盘处于比较空闲的状态
：$df -lh
2.在oracle 数据库中查看所有表空间的占用率：
SQL> SELECT Total.name "Tablespace Name",

  2         nvl(Free_space, 0) Free_space,

  3         nvl(total_space-Free_space, 0) Used_space,

  4         total_space

  5  FROM

  6    (select tablespace_name, sum(bytes/1024/1024) Free_Space

  7       from sys.dba_free_space

  8      group by tablespace_name

  9    ) Free,

 10    (select b.name,  sum(bytes/1024/1024) TOTAL_SPACE

 11       from sys.v_$datafile a, sys.v_$tablespace B

 12      where a.ts# = b.ts#

 13      group by b.name

 14    ) Total

 15  WHERE Free.Tablespace_name(+) = Total.name

 16  ORDER BY Total.name

 17  /
星期二 5月  29                                                        第    1

                        Space Usage for Database in Meg
EXAMPLE                             21.25      78.75         100

STAGING                            1.9375     1.0625           3

SYSAUX                            35.4375   524.5625         560

SYSTEM                              3.125    686.875         690

UNDOTBS1                          194.375     85.625         280

USERS                               .9375     4.0625           5

SQL>

SQL> tti off

SQL>
查询undo表空间的路径
sql>select file_name ,bytes/1024/1024

    from dba_data_files

    where tablespace_name like 'UNDOTBS1';
3.检查还原表空间的segment的状态的信息：

    

  sql>select usn,xacts,rssize/1024/1024/1024,

      hwmsize/1024/10244/1024, shrinks

      from v$rollstat order by rssize;


  0     0            .000358582              .000035844    0

  1     0            .002067566              .000206676    0

  5     0            .002067566              .000206676    0

  6     0            .002067566              .000206676    0

 10     0            .002067566              .000206676    0

  4     0            .002067566              .000206676    0

  9     0            .003105164              .000310395    0

  8     0            .004020691              .000401912    0

  7     0            .005973816              .000597148    0

  3     0            .022575378              .002256656    0

  2     0            .036552429              .003653816    0
这表示该还原表中还存在11个回滚对象，及数据库的历史数据。
4. 创建新的还原表空间。

  sql>create undo tablespace undotbs2

      datafile 'F:\ORACLE11GR2\ORADATA\ORCL\UNDOTBS02.DBF'

      size 10m autoextend on maxsize 1GB;

    

5.在oracle数据库中把默认的还原表空间切换成新建的还原表空间undotbs2

sql>alter system set undo_tablespace=undotbs2 scope=both ;
6.验证当前数据库使用的还原表空间是否为新建的还原表空间：

sql>show parameter undo
7.等待旧的还原表空间所有的数据变成脱机状态（undo segment offline）:

  sql>select t.segment_name , t.tablespace_name, t.segment_id, t.status

      from dba_rollback_segs t;
SYSTEM                         SYSTEM                                  0 ONLINE

_SYSSMU10_3176102001$          UNDOTBS1                               10 ONLINE

_SYSSMU9_1126410412$           UNDOTBS1                                9 ONLINE

_SYSSMU8_1557854099$           UNDOTBS1                                8 ONLINE

_SYSSMU7_137577888$            UNDOTBS1                                7 ONLINE

_SYSSMU6_1834113595$           UNDOTBS1                                6 ONLINE

_SYSSMU5_1018230376$           UNDOTBS1                                5 ONLINE

_SYSSMU4_2369290268$           UNDOTBS1                                4 ONLINE

_SYSSMU3_991555123$            UNDOTBS1                                3 ONLINE

_SYSSMU2_2082490410$           UNDOTBS1                                2 ONLINE

_SYSSMU1_1518548437$           UNDOTBS1                                1 ONLINE


上面对应的回滚段均为 offline 时即可干掉 之前的undo表空间了

 sql>drop tablespace undotbs1 including contents and datafiles;

			解决undo 表空间过大导致磁盘空间不足的问题


undo表空间不断扩大问题的原因：1有较大的事务量让oracle undo
自动扩展，产生过度占有磁盘空间的情况。2有较大事务没有收缩或者没有提交所导致。

 

1.查看还原表空间所在磁盘是否使用率过高，及linux 系统哪个磁盘处于比较空闲的状态


：$df -lh


2.在oracle 数据库中查看所有表空间的占用率：


SQL> SELECT Total.name "Tablespace Name",

 
2        
nvl(Free_space, 0) Free_space,

 
3        
nvl(total_space-Free_space, 0) Used_space,

 
4        
total_space

  5  FROM

 
6    (select
tablespace_name, sum(bytes/1024/1024) Free_Space

 
7      
from sys.dba_free_space

 
8     
group by tablespace_name

 
9    )
Free,

 10   
(select b.name,  sum(bytes/1024/1024)
TOTAL_SPACE

 11      
from sys.v_$datafile a, sys.v_$tablespace B

 12     
where a.ts# = b.ts#

 13     
group by b.name

 14   
) Total

 15  WHERE
Free.Tablespace_name(+) = Total.name

 16  ORDER BY Total.name

 17  /


星期二 5月 
29                                                       
第    1

                       
Space Usage for Database in Meg


EXAMPLE                            
21.25     
78.75        
100

STAGING                           
1.9375    
1.0625          
3

SYSAUX     

      我这边生产环境，一般undo表空间都会预先设置一个大小，并且保留数据文件的自动扩展，一直也相安无事。最近有套系统的undo表空间一直报警，使用率超过85%。看了下表空间大小，才5个G，以后确实是undo表空间过小了，于是扩到10G。结果第二天又报警了，嘿，不信了，于是扩到20g。哎呦，跟我杠上了，第二天又报警了。

      没办法，生了个awr报告，看到到底是哪个倒霉孩子写的大事务一句一直不提交。哎呦我去，没有找到嫌疑语句，啥情况。找来开发人员，交流一下，不存在批量之类的业务。怪了。

     查了下undo状态：select status,sum(bytes)/1024/1024/1024 from dba_undo_extents group by status;发现未过期的undo竟然占了表空间的百分之九十左右。但是我实时查看数据库状态，确实没有发现正在活动的大事务。于是怀疑，莫非是遇到undo方面的bug了，是不是存在未过期undo一直没释放的情况？

    在MOS上看到一篇文档doc：413732.1，有如下解释：

When the UNDO tablespace is created with NO AUTOEXTEND, following the allocation algorithm, here is the explanation for this correct behavior:

For a fixed size UNDO tablespace (NO AUTOEXTEND), starting with 10.2, we provide max retention given the fixed undo space, which is set to a value based on the UNDO tablespace size. 

This means that even if the undo_retention is set to a number of seconds (900 default), the fixed UNDO tablespace supports a bigger undo_retention time interval (e.g: 36 hours), based on the tablespace size, thing that makes the undo extents to be UNEXPIRED. But this doesn't indicate that there are no available undo extents when a transaction will be run in the database, as the UNEXPIRED undo segments will be reused.

大致意思是如果数据文件设置成非自动扩展的，oracle不会按照undo_retention参数所设置的值，对undo数据进行过期。我测试了下，在12.2.0.1版本，依然存在这样的情况。将上述存在问题的undo表空间数据文件设置成自动扩展后，过了一会，未过期的undo数据逐渐减少，直至undo表空间使用率恢复正常。

  oracle当真是博大精深，总有一些知识点很难触及，遇到了，总要记录一番。