30012.org

Table of Contents

• 1. 场景
• 2. 错误信息
• 3. 原因分析
  • 3.1. UNDO表空间名不对
  • 3.2. 表空间类型不对
• 4. 解决问题
  • 4.1. 针对场景1
  • 4.2. 针对场景2

1. 场景

ADG switchover 为主库。 然后重启。

2. 错误信息

/u01/app/oracle/diag/rdbms/bossdg/boss/trace/boss_ora_31805.trc
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-30012: undo tablespace 'UNDOTBS' does not exist or of wrong type

从这个报错信息来看，要么是是没找到对应默认的Undo表空间，要么是该表空间的类型是不对的。 也就是说UNDO表空间是被调整过的。

3. 原因分析

3.1. UNDO表空间名不对

本次情况是主库是RAC，adg备库是单实例,那么在主库那边儿，UNDO 表空间是分实例的，一个实例一个undo. 但是在单实例中，默认的undo_tablespace 是 undotbs. 在搭建dataguard的时候，如果没有意识到这个问题, 当备库切换为主库时就会遇到上面的错误。 使用下面SQL 进行验证：

col con_name for a10
col name for a25
col value for a20
set lines 200 pages 200
select b.name as con_name,a.con_id,c.inst_id,a.name,a.value
from gv$parameter a ,
v$containers b,
gv$instance c
where a.con_id = b.con_id
and a.inst_id = c.inst_id
and a.name ='undo_tablespace';

• 备库

  CON_NAME       CON_ID NAME			VALUE
  ---------- ---------- ------------------------- --------------------
  CDB$ROOT	    1 undo_tablespace		UNDOTBS
  

• 主库

  CON_NAME       CON_ID	 INST_ID NAME			   VALUE
  ---------- ---------- ---------- ------------------------- --------------------
  CDB$ROOT	    1	       1 undo_tablespace	   UNDOTBS1
  CDB$ROOT	    1	       2 undo_tablespace	   UNDOTBS2
  

可以看到主库本身确实没有使用名称为 UNDOTBS 的UNDO表空间。可以确定，是由于备库未指定有效UNDO表空间引起的问题。 当然更严谨一些的话，应该还要对比一下UNDO 文件的对应关系。

3.2. 表空间类型不对

那么除第一种类型外，还有一种原因就是表空间创建时，没有创建成undo表空间。而是创建成了permanent表空间。 对于这种情况，一般是数据库处于open状态时进行处理的，重建为Undo表空间即可。 如果数据宕机了，在启动时发现这个问题，可以和第一种场景一样，在mount阶段， 指定正确的undo表空间名。 确认表空间类型:

SQL> select tablespace_name, contents from dba_tablespaces order by 1;

TABLESPACE_NAME                CONTENTS
------------------------------ ---------------------
SYSAUX                         PERMANENT
SYSTEM                         PERMANENT
TEMP                           TEMPORARY
UNDOTBS1                       UNDO
UNDO_2                         PERMANENT
USERS                          PERMANENT

可以看到undo_2 的类型并不是undo ， 而是permanent .

4. 解决问题

4.1. 针对场景1

#针对CDB$root 和非CDB.
alter system set undo_tablespace=UNDOTBS1 scope=spfile;
STARTUP FORCE

# 针对pdb
alter system set undo_tablespace=UNDOTBS1 container=<PDB_NAME> scope=spfile;
alter pluggable database <PDB_NAME> open;

4.2. 针对场景2

drop tablespce undo_2 including contents and datafiles;
create undo tablespace undo_2 datafile '%file_name' size 100M autoextend on next 10M maxsize unlimited;

Validate