问题介绍

oracle rac环境下面，一个实例使用的undo表空间出现问题，经现场实施人员调整后，实例能够启动，但是不能提供写数据服务，只能提供查询服务。

实例对应表空间的管理方式已经改成manual，写数据（建表或者插入数据）的时候报出ORA-01552错误。

问题分析

解决问题之后看这个问题，思路应该还是比较清晰。oracle的undo在ddl和dml操作的时候都会用到。由于实例对应的undo是manual方法，不能实现空间的自动扩展，当undo空间满了之后，不能再分配更多的空间。问题就这么出来了。

问题解决

这个问题的解决大概有两种方式，第一通过rman进行恢复，问题的根源我猜测是undo的数据文件损坏，应该是可以通过rman的方式进行恢复，限于本人的学识，对rman不熟，也没时间去折腾，所以我没用这种方式。

第二通过新建undo表空间，修改实例对应的默认undo空间。这个方式应该是比较容易操作的。也是我选用的。下面介绍当时的实施过程。

1、新建undo表空间，注意undo表空间能够自动扩展。

2、修改实例对应的undo表空间。

    现在回过头来看这个问题估计只要一条命令就可以了“alter system set undo_tablespace=UTBS1 scope=spfile sid=‘rac1‘;”,由于当时没有制定sid，执行这条命令后，虽然命令执行成功，但是实例重启之后，实例的undo表空间还是原来的。我的分析是，虽然“alter system set undo_tablespace=UTBS1 scope=spfile;”这条命令执行成功了，spfile中确实多了一条记录*.undo_tablespace=UTBS1,但是spfile中还存在原来的一条记录rac1.undo_tablespace=UTBS，这种情况下，实例启动过的时候是rac1.undo_tablespace=UTBS起作用了，所以实例的undo表空间没修改成功。

    当时没那个觉悟，我选择的做法是修改pfile中rac1.undo_tablespace的值来实现修改的目的。

    （1）通过spfile生成pfile（注意rac中实例共用一个spfile文件，且都存在asm中）；

    （2）修改pfile的rac1.undo_tablespace值为新建的undo表空间名；

    （3）通过pfile文件启动实例。

    （4）通过pfile生成spfile文件。

    （5）利用spfile文件启动数据库实例

    （6）修改undo表空间的管理方式。

需要注意的问题：

    （1）生成spfile有两种方式，通过pfile和memory，memory的方式我试过，这种方式生成的spfile只能启动一个rac实例，其他实例不能启动，我分析的原因，memory生成的spfile是单个实例的参数文件，两个或以上的实例使用同一份参数配置的时候，就会出问题，比如说instance_number busy的问题，参数不一致ORA-01105 ORA-01606的问题。这里我的做法是通过pfile文件直接生成spfile，注意spfile需要制定路径，而且是asm下面的路径。

    （2）oracle的startup命令读参数文件（spfiletrain1.ora，inittrain1.ora）的顺序问题。oracle在用startup启动的时候先找spfileSID.ora文件，不存在该文件的情况下找initSID.ora文件。由于我在生成spfile的时候，最开始没有指定spfile的路径，这样在默认的路径下面就存在了spfiletrain1.ora这个文件，这就造成我启动实例的一个困惑，重新制定spfile的路径重建后，重启实例后，查看spfile的参数都不是asm中的文件。之后移除本地目录的spfiletrain1.ora文件，再重启实例，就正常了。

用到的命令

由于生成环境，考出当时的sql语句很麻烦，这里只能给出图片了。

ORA-01552: 非系统表空间不能使用系统回退段-问题解决