从10.2.0.1升级到10.2.0.5操作实验（下）
上篇中我们完成了Oracle软件的升级，下面我们进行补丁包安装和数据库升级。
4、使用OPatch打补丁
补丁11724962是需要使用OPatch进行打补丁动作。先将压缩包解压。
[oracle@SimpleLinux upload]$ ls -l
total 4348
drwxr-xr-x 5 oracle oinstall 4096 Mar 14 2011 11724962
-rw-r--r-- 1 oracle oinstall 4278863 May 13 11:27 p11724962_10205_LINUX.zip
-rwxrwxrwx 1 oracle oinstall 165290 Jul 20 2010 README.html
直接使用当前的OPatch进行apply动作。
[oracle@SimpleLinux 11724962]$ /u01/app/oracle/product/10.2.0/db_1/OPatch/opatch apply
Invoking OPatch 10.2.0.4.9
（篇幅原因，有省略……）
ApplySession applying interim patch '11724962' to OH '/u01/app/oracle/product/10.2.0/db_1'
ApplySession failed: ApplySession failed to prepare the system.
Patch 11724962 requires OPatch version 10.2.0.5.0.
The OPatch version being used (10.2.0.4.9) doesn't meet the minimum version required by the patch(es). Please download latest OPatch from My Oracle Support.
System intact, OPatch will not attempt to restore the system
OPatch failed with error code 73
补丁要求OPatch版本为10.2.0.5，但是当前OPatch只有10.2.0.4.9。报错不匹配。注意：我们使用OPatch打补丁的时候，经常会遇到版本不匹配的情况。所以，经常需要我们到MOS上下载对应Oracle软件版本的最新版OPatch。
我们首先备份当前的OPatch包。
[oracle@SimpleLinux bin]$ cd /u01/app/oracle/product/10.2.0/db_1/OPatch/
[oracle@SimpleLinux OPatch]$ ./opatch version
Invoking OPatch 10.2.0.4.9
OPatch Version: 10.2.0.4.9
OPatch succeeded.
[oracle@SimpleLinux db_1]$ tar zcvf opatch_bk.tar OPatch
OPatch/
OPatch/opatchprereqs/
OPatch/opatchprereqs/prerequisite.properties
（篇幅原因，有省略……）
[oracle@SimpleLinux db_1]$ ls -l | grep opatch
-rw-r--r-- 1 oracle oinstall 1467463 May 13 12:33 opatch_bk.tar
从MOS下载针对10g的最新版本OPatch，上传到目录中。
[oracle@SimpleLinux upload]$ ls -l
total 31120
drwxr-xr-x 5 oracle oinstall 4096 Mar 14 2011 11724962
-rw-r--r-- 1 oracle oinstall 4278863 May 13 11:27 p11724962_10205_LINUX.zip
-rw-r--r-- 1 root root 27412455 May 13 12:49 p6880880_102000_LINUX.zip
-rwxrwxrwx 1 oracle oinstall 165290 Jul 20 2010 README.html
[oracle@SimpleLinux upload]$ unzip p6880880_102000_LINUX.zip -d $ORACLE_HOME
Archive: p6880880_102000_LINUX.zip
extracting: /u01/app/oracle/product/10.2.0/db_1/OPatch/ocm/ocm.zip
inflating: /u01/app/oracle/product/10.2.0/db_1/OPatch/ocm/lib/osdt_jce.jar
inflating: /u01/app/oracle/product/10.2.0/db_1/OPatch/ocm/lib/osdt_core3.jar
inflating: /u01/app/oracle/product/10.2.0/db_1/OPatch/ocm/lib/emocmclnt-14.jar
(......)
重新进行补丁操作。
[oracle@SimpleLinux 11724962]$ /u01/app/oracle/product/10.2.0/db_1/OPatch/opatch apply
Invoking OPatch 10.2.0.5.1
Oracle Interim Patch Installer version 10.2.0.5.1
Copyright (c) 2010, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
from : /etc/oraInst.loc
OPatch version : 10.2.0.5.1
OUI version : 10.2.0.5.0
OUI location : /u01/app/oracle/product/10.2.0/db_1/oui
Verifying the update...
Inventory check OK: Patch ID 11724962 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 11724962 are present in Oracle Home.
The local system has been patched and can be restarted.
OPatch succeeded.
验证补丁正确性。
[oracle@SimpleLinux OPatch]$ ./opatch lsinventory
Invoking OPatch 10.2.0.5.1
Oracle Interim Patch Installer version 10.2.0.5.1
Copyright (c) 2010, Oracle Corporation. All rights reserved.
Oracle Home : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oracle/oraInventory
from : /etc/oraInst.loc
OPatch version : 10.2.0.5.1
OUI version : 10.2.0.5.0
OUI location : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch2014-05-13_12-55-24PM.log
Patch history file: /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatch_history.txt
Lsinventory Output file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/lsinv/lsinventory2014-05-13_12-55-24PM.txt
--------------------------------------------------------------------------------
Installed Top-level Products (2):
Oracle Database 10g 10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 4 10.2.0.5.0a
There are 2 products installed in this Oracle Home.
Interim patches (1) :
Patch 11724962 : applied on Tue May 13 12:54:00 CST 2014
Unique Patch ID: 13426771
Created on 13 Mar 2011, 21:24:09 hrs PST8PDT
Bugs fixed:
（篇幅原因，有省略……）
OPatch succeeded.
5、数据库升级
最后就是对现有数据库ora11g的升级动作。进行数据库升级有两个方法，dbua图形化方法和手工脚本执行方法。dbua方法比较简单，但是在一些早期版本中问题比较多。手工脚本虽然麻烦，但是诊断错误更加方便。笔者选择手工脚本方法。
首先需要将数据库以upgrade模式进行启动。
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup upgrade
ORACLE instance started.
Total System Global Area 251658240 bytes
Fixed Size 1273080 bytes
Variable Size 83886856 bytes
Database Buffers 163577856 bytes
Redo Buffers 2920448 bytes
Database mounted.
Database opened.
执行脚本（在服务器端！！）catupgrd.sql，升级数据字典对象。
SQL> @?/rdbms/admin/catupgrd.sql
（长时间等待）
DOC>#######################################################################
DOC>
DOC> The above PL/SQL lists the SERVER components in the upgraded
DOC> database, along with their current version and status.
DOC>
DOC> Please review the status and version columns and look for
DOC> any errors in the spool log file. If there are errors in the spool
DOC> file, or any components are not VALID or not the current version,
DOC> consult the Oracle Database Upgrade Guide for troubleshooting
DOC> recommendations.
DOC>
DOC> Next shutdown immediate, restart for normal operation, and then
DOC> run utlrp.sql to recompile any invalid application objects.
DOC>
DOC>#######################################################################
DOC>#######################################################################
DOC>#
在执行过程中，很多数据库字典对象都是被重建，所以容易出现对象失效的情况。所以Oracle建议在之后重启数据库，进行失效对象重新编译动作。
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 251658240 bytes
Fixed Size 1273080 bytes
Variable Size 121635592 bytes
Database Buffers 125829120 bytes
Redo Buffers 2920448 bytes
Database mounted.
Database opened.
执行脚本：
SQL> @?/rdbms/admin/utlrp.sql
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2014-05-13 13:27:54
DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#
OBJECTS WITH ERRORS
-------------------
0
DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#
ERRORS DURING RECOMPILATION
---------------------------
0
在提示信息中，也介绍了一些查看过程进展的方法。最后，我们验证数据库升级情况：
[oracle@SimpleLinux OPatch]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.5.0 - Production on Tue May 13 13:29:30 2014
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
SQL> conn / as sysdba
Connected.
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 – Production
各个数据库组件升级成功，并且状态均为valid。
SQL> select comp_name, version, status from dba_registry;
COMP_NAME VERSION STATUS
----------------------------------- --------------- ------
Oracle Database Catalog Views 10.2.0.5.0 VALID
Oracle Database Packages and Types 10.2.0.5.0 VALID
Oracle Workspace Manager 10.2.0.5.0 VALID
JServer JAVA Virtual Machine 10.2.0.5.0 VALID
（篇幅原因，有省略……）
Oracle Enterprise Manager 10.2.0.5.0 VALID
17 rows selected
db time zone信息也能显示正常。
SQL> select START_DATE from dba_scheduler_jobs;
START_DATE
----------------------------------------------------
01-7月 -05 03.00.00.800000 上午 AMERICA/LOS_ANGELES
13-5月 -14 02.24.49.000000 下午 +08:00
13-5月 -14 01.24.31.629677 下午 +08:00
13-5月 -14 01.09.56.713160 下午 +08:00
8 rows selected
升级成功！
6、结论
Oracle升级，特别是10g版本升级，是我们进行部署时候经常遇到的问题。随着版本升级过程，一些不兼容问题可能都会出现。充分的测试实验加合理稳妥的方案规划，是保证我们在生产系统中不出问题、少出问题的法宝。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/17203031/viewspace-1164222/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/17203031/viewspace-1164222/