共计 3272 个字符，预计需要花费 9 分钟才能阅读完成。
今天计划把一个测试环境升级到 Oracle 12C，为了练练手，先在备库上来做。数据库版本是 11.2.0.3.0，计划升级到 12.1.0.2.0。
为了不影响原有的测试主库，我在备库上做了 Failover，两个命令下去就立刻生效了。
SQL> select open_mode from v$database;
OPEN_MODE
——————–
READ ONLY
SQL>alter database recover managed standby database finish force;
Database altered.
SQL>alter database commit to switchover to primary;
Database altered.
然后使用克隆安装 12c 的数据库软件，使用下面的命令即可安装。
$ORACLE_HOME/clone/bin/perl clone.pl ORACLE_BASE=$ORACLE_BASE ORACLE_HOME=$ORACLE_HOME ORACLE_HOME_NAME=OraDb12c_home1
查看数据库已经部署了最新的补丁
$ opatch lsinventory
…
Patch 23054246 : applied on Mon Oct 17 17:01:16 CST 2016
Unique Patch ID: 20464632
Patch description: “Database Patch Set Update : 12.1.0.2.160719 (23054246)”
Created on 5 Jul 2016, 07:07:59 hrs PST8PDT
看了下官方文档，发现对于 12c 的升级和升级 11g 差别不大，手工升级的步骤很多脚本都是一样的，思路完全可以复用。
升级前的检查需要跑一个脚本 /preupgrd.sql
本来想速战速决，没想到检查的时候竟然抛出了一个错误。
DECLARE
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1003 – see DBWR trace file
ORA-01110: data file 1003: ‘+DATA’
ORA-06512: at “SYS.DBMS_PREUP”, line 2380
ORA-06512: at “SYS.DBMS_PREUP”, line 981
ORA-06512: at “SYS.DBMS_PREUP”, line 5471
ORA-06512: at line 73
这个错误看得我有些懵，因为我这个备库是没有使用 ASM 的，怎么会抛出和 ASM 相关的错误呢。
查看参数文件里面，倒是有一行这样的内容
*.db_file_name_convert=’+DATA/sgstatdb3/datafile’,’/U01/app/oracle/oradata/statdb2′,’+ARCH’,’/U01/app/oracle/oradata/statdb2′,’/U01/….
可见原来的主库是使用了 ASM，但是在备库端压根没有用到，怎么会抛出这个错误呢。
查看 alert 日志，发现这个错误还挺特别。
Mon Oct 31 22:27:02 2016
WARNING: ASM communication error: op 36 state 0x40 (15077)
ERROR: slave communication error with ASM
Mon Oct 31 22:28:56 2016
WARNING: ASM communication error: op 36 state 0x40 (15077)
ERROR: slave communication error with ASM
Mon Oct 31 22:30:00 2016
Thread 1 advanced to log sequence 3 (LGWR switch)
从错误日志可以看出，是在和 ASM 实例通信的时候出问题了。这个环境压根没有用 ASM，肯定出问题了。
看错误是文件 1003，查看 v$datafile, 文件号最大才是 800 多，怎么会冒出一个 1003 的文件呢。继续查看 alert 日志，发现 1001 也有问题，看来有问题的还不止一个文件，但是数据库 Open 没有任何问题。
Dictionary check beginning
Mon Oct 31 22:05:05 2016
Errors in file /U01/app/oracle/diag/rdbms/sstatdb2/statdb2/trace/statdb2_dbw0_27706.trc:
ORA-01186: file 1001 failed verification tests
ORA-01157: cannot identify/lock data file 1001 – see DBWR trace file
ORA-01110: data file 1001: ‘+DATA’
File 1001 not verified due to error ORA-01157
脑袋里盘算着，一边翻找日志，发现数据库启动的时候抛出了下面的错误。
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Cannot re-create tempfile +DATA, the same name file exists
Cannot re-create tempfile +DATA, the same name file exists
Cannot re-create tempfile +DATA, the same name file exists
如此一来，问题就很明显了，临时表空间的文件映射存在问题，导致没有创建成功，而临时文件有无不会影响数据库的启动，所以这个问题就这样暂时搁置下来了。
进一步验证，可以看到存着多个临时文件
SQL> SELECT FILE#,NAME FROM V$TEMPFILE
FILE# NAME
———- ——————————
3 +DATA
4 +DATA
1 +DATA
2 +DATA
5 +DATA
6 +DATA
7 +DATA
同时使用 dba_temp_files 会直接抛出之前的错误。
SQL> select file_name from dba_temp_files;
select file_name from dba_temp_files
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 1003 – see DBWR trace file
ORA-01110: data file 1003: ‘+DATA’
问题的原因找到了，解决起来就很容易了。我们可以重新创建一个临时表空间，然后删除原来的。
SQL> create temporary tablespace temp1 tempfile ‘/U01/app/oracle/oradata/statdb2/temp01.dbf’ size 100M;
Tablespace created.
SQL> alter database default temporary tablespace temp1;
Database altered.
SQL> drop tablespace temp including contents and datafiles;
Tablespace dropped.
后台会继续检查 +DATA 这个不存在的虚拟存储，然后最终从数据字典层面统一这些信息。
再次做升级前的检查，就没有任何问题了。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-11/136632.htm
