ORACLE RAT Real Application Testing Checklist

 

Pre Capture Checklist

Review database version & review list of one off patches applied as per MOS Note 560977.1 both for capture database as well as replay database
Review AWR/Statspack reports from peak workload
Review alert.log at least from last startup in the capture database
Review hardware, storage details & disk space for capture database as well as replay database
Estimate disk space required to do database capture
Review current CPU  & memory usage without database capture
Review plan for SPA capture into the  Sql Tuning Sets
Review  description of application  & database feature usage
Review the exact commands/scripts/navigation From EM  to be used to do the database Capture as well as SPA capture
Review plan for backup & restore of database
Plan for a small duration dry run of database capture & database replay before moving to Large duration database capture & database replay

 

Post Capture check List

Review database capture report
Review database capture period AWR report
Export AWR data at the end of the database capture

 

SPA

Execute & review results of SPA trials & fix any identified SQL regressions in the test system where database replay will be done

 

Preprocess side

Review version of database & list of one off patches applied as per MOS Note 560977.1
Did the preprocess  completed successfully
Review  workload analyzer report & follow recommendations

 

 

Replay Side

Review database version & List of one off patches applied as per MOS Note 560977.1.

Ensure database replay client WRC is executed from a patched ORACLE_HOME  as per MOS Note 560977.1

Review Hardware setup.  Pay special attention for RAC &  Exadata setup
Review network related settings. Listener.ora, tnsnames.ora etc

Ensure to Isolate test database from production databases

Review database restore point and flashback setup
Review schema setup. Validate No missing user, views, synonyms etc as compared to Capture database
Review the exact commands/scripts/ navigation From EM & options to be used to do the Database Replay & deploy WRC. Review connection remapping
Execute database replay of  smaller duration capture  & validate its success
Execute  database replay of larger duration capture & check if it  completes successfully
In case of problem follow MOS Note 1287620.1 for traces & other debug information. Open an SR if needed. Please Provide very detailed information.

 

Post Replay

 

Review Database Replay Report
Review  Compare period Report
Review  Replay Period AWR Report

 

【转】手动升级到 11gR2 的完整核对清单 (Doc ID 1674333.1)

适用于:

Oracle Database – Standard Edition – 版本 9.2.0.8 到 11.2.0.4 [发行版 9.2 到 11.2]
Oracle Database – Enterprise Edition – 版本 9.2.0.8 到 11.2.0.4 [发行版 9.2 到 11.2]
本文档所含信息适用于所有平台

用途

本文档可用作手工将 Oracle 9iR2 (9.2), Oracle 10gR1 (10.1), Oracle 10gR2 (10.2) 或者 Oracle 11gR1 (11.1) 版本数据库升级至 Oracle 11gR2 (11.2) 版本数据库的指南与核对表。

提问,获得帮助,并分享您对于这篇文档的经验

您是否希望与其他 Oracle 客户、Oracle 员工和业内专家进一步探讨此主题?

请点击这里进入Oracle 社区(中文)。
请点击这里进入My Oracle Support 社区的数据库安装/升级(英文)主页发现更多的话题和讨论。

适用范围

数据库管理人员/技术支持

详细信息

推荐在源库上完成的

1) 在升级前确保所有 oracle 提供的组件和对象都是有效的

2) 除了下面的对象外, 确保在 sys 和 system schema 下没有重复存在的对象

下面的对象是允许重复的:

 OBJECT_NAME OBJECT_TYPE

—————————— ——————-
AQ$_SCHEDULES TABLE
AQ$_SCHEDULES_PRIMARY INDEX
DBMS_REPCAT_AUTH PACKAGE
DBMS_REPCAT_AUTH PACKAGE BODY

 如果有除了上面对象以外的重复对象,参照下面的文档移除它们:
NOTE.1030426.6 HOW TO CLEAN UP DUPLICATE OBJECTS OWNED BY SYS AND SYSTEM

注意: 上面的检查会在下面的第三步中完成 (dbupgdiag.sql)

3) 禁用所有自定义的 before/after DDL 类型的触发器,完成升级后再启用它们

4) 在升级一个安装了 XDB 组件的数据库或者安装 XDB 之前,需要先按照文档 Note 1573175.1 “Upgrading or Installing XDB could result in data loss if XDB_INSTALLATION_TRIGGER exists “  中的代码检查是否需要删除一些对象. 注意,如果不这么做的话,可能会引发用户数据或者用户对象(如表,索引)的丢失

推荐/需要在目标库上完成的

  • 在下载安装 11gR2 软件之前,需要先检查软件版本与您的硬件平台/操作系统是否兼容。您可以通过 My Oracle Support 网站来确认这一点。
  • 下载安装 11gR2 软件到一个新的 ORACLE_HOME 并确认没有编译错误
  • 如果有的话, 安装最新的补丁集 (PatchSet)
  • 如果有的话, 安装最新的 OPatch (要安装跟操作系统平台及数据库版本一致的 OPatch)
  • 如果有的话, 安装最新的 Critical Patch Update
  • 对源库做备份 (冷备份或热备份都可以, 推荐冷备份)
  • 如果目标库版本为 11.2.0.2 并且安装了 XDB, 那么在升级前需要安装 patch 10368698。如果没有当前操作系统对应的这个 patch, 请开 SR 申请. 这个 bug 会使得启用了 XDB 的数据库升级时间变得非常长。Bug 10368698 在 11.2.0.3 中被修复。
  • 如果目标库版本为 11.2.0.2 并且安装了 XDB, 那么在升级前需要安装 patch 10419629。请参照文档  Note 1305561.1 While Upgrading From 10.2.0.4.0 To 11.2.0.2.0 Catupgrd.sql=ORA-31061 ORA-19202 LSX-23
  • 如果您使用了 XDB, 在升级前需要设置 SHARED_POOL_SIZE = 250M 或更高和 JAVA_POOL_SIZE = 250M 或更高,否则会碰到以下文档中提到的问题。
    Note 1127179.1 ORA-07445 [qmkmgetConfig()+52] During Catupgrd.sql (11.2.0.1).

 如果数据库使用了 ASMM, 那么也需要按上面来设置两个 pool 的大小做为最小值。

  • 出于对 11.2.0.2 上性能问题的了解,请您参考文档  Note 1320966.1 “Things to Consider Before Upgrade to 11.2.0.2 in Relation to Database Performance”
  • 出于对 SQL Profile 相关已知问题的了解,请您参考 BUG 13646689– SQL PROFILES LOST AFTER UPGRADE ORA-00001 (SYS.I_SQLOBJ$AUXDATA_PKEY) 。当前开发人员仍然在处理这个问题中。 如果下面的语句返回一些行,那么从 10.2 升级到 11gR2 时会丢失 SQL PROFILE。
    select sp.signature, sp.category, count(*) from sqlprof$ sp,sqlprof$desc sd,sql$ s
    where sp.signature = sd.signature(+) and sp.signature = s.signature
    group by sp.signature, sp.category having count(*) > 1;

兼容性矩阵

能够直接升级到 Oracle 11g Release 2 的数据库最小版本

源数据库 目标数据库
9.2.0.8 (或更高版本) 11.2.x
10.1.0.5 (或更高版本) 11.2.x
10.2.0.2 (或更高版本) 11.2.x
11.1.0.6 (或更高版本) 11.2.x

以下的数据库版本需要间接升级:

源数据库 升级路径 目标数据库
7.3.3(或更低版本) —-> 7.3.4 -> 9.2.0.8   —-> 11.2.x
8.0.5(或更低版本) —-> 8.0.6 -> 9.2.0.8 —-> 11.2.x
8.1.7(或更低版本) —-> 8.1.7.4 -> 10.2.0.2(或 10GR2 的其它更高版本) —-> 11.2.x
9.0.1.3(或更低版本) —-> 9.0.1.4 -> 10.2.0.2 (或 10GR2 的其它更高版本) —-> 11.2.x
9.2.0.7(或更低版本) —-> 9.2.0.8 —-> 11.2.x

比如:

如果源库是 8.1.7.0.0,升级路径如下:
8.1.7.0.0 –> 8.1.7.4 –> 10.2.0.2(或 10GR2 的其它更高版本)–> 11.2.x。

提醒:

9.2.0.8 补丁集 (PatchSet): Patch:4547809
10.1.0.5 补丁集 (PatchSet): Patch:4505133
10.2.0.2 补丁集 (PatchSet): Patch:4547817

如果要快速得到各个补丁集对应的补丁号,可以参考下面的两个文档:
Note 438049.1 : How To Find RDBMS patchsets on My Oracle Support
Note 753736.1 : Quick Reference to Patchset Patch Numbers

升级前步骤

这个部分中的所有步骤都需要在设置了旧的数据库的环境变量后执行运行,每个步骤都需要执行。源数据库必须处于正常的状态。

按照下面的文档下载或使用最新的 Pre-Upgrade Information Tool:
How to Download and Run Oracle’s Database Pre-Upgrade Utility Note 884522.1

或者

直接运行 Pre-Upgrade Information Tool 来收集安装前需要检查的信息

 第1步

  • 使用新 11gR2 软件的所有者用户登录操作系统。
  • 把 11gR2 的 ORACLE_HOME/rdbms/admin 目录中的 Pre-Upgrade Information Tool (utlu112i.sql)拷贝到 Oracle Home 以外的一个目录里,比如系统的临时目录。

$ORACLE_HOME/rdbms/admin/utlu112i.sql

如果不运行 pre-upgrade tool (utlu112i.sql) 那么稍后在运行 catupgrd.sql 脚本时会碰到下面错误:

SQL> SELECT TO_NUMBER(‘MUST_BE_SAME_TIMEZONE_FILE_VERSION’)
2 FROM registry$database
3 WHERE tz_version != (SELECT version from v$timezone_file);
SELECT TO_NUMBER(‘MUST_BE_SAME_TIMEZONE_FILE_VERSION’)
*
ERROR at line 1:
ORA-01722: invalid number

这时候就只能把升级前备份的数据库恢复然后再运行 preupgrade tool(utlu112i.sql )。

第2步

  • 进入第1步拷贝 utlu112i.sql 到的那个临时目录中。
  • 启动 sqlplus 并使用 sysdba 权限连接进入 Oracle 数据库,运行 utlu112i.sql 文件并 spool 输出到一个日志文件。注意此时数据库是使用低版本的 ORACLE_HOME 启动的。
$ sqlplus ‘/ as sysdba’
SQL> spool upgrade_info.log
SQL> @utlu112i.sql
SQL> spool off
SQL>

检查 spool 的日志文件中 Upgrade Information Tool 产生的输出。
下面的部分解释了输出的各个部分的含义。
点击这里查看一个Upgrade Information Tool产生的输出示例。

Database
这部分显示关于当前数据库的全局信息,比如数据库名,版本信息和兼容版本(compatibility level). 如果需要在升级数据库前更改 COMPATIBLE 初始化参数,警告信息也在这部分显示。

Logfiles
这部分显示当前数据库中所有比 4MB小 的重做日志(redo log)文件。对于这样的文件,会显示文件名, 哪个组的,以及推荐的大小。
在使用 SQL 脚本及其它工具手工升级数据库前,所有小于 4MB 的日志文件都应该被删除,新的最小为 4MB(10MB 较好)的日志文件需要创建好. 如果使用DBUA升级,那么这些步骤会被自动完成。

Tablespaces
这部分显示当前数据库的 tablespace 相关的信息。对于每个 tablespace, 都会显示 tablespace 的名字和升级需要的 tablespace 大小的最小值。另外, 如果满足升级需要的最小值, 也会有提示信息。在使用 SQL 脚本及其它工具手工升级数据库前, 空闲空间不够的 tablespace 都应该增加大小。如果使用 DBUA 升级,那么这些步骤会被自动完成。

Update Parameters
这部分显示在升级前参数文件中必须修改的初始化参数。调整的工作必须在把参数文件拷贝到新的 11G ORACLE HOME 前完成。

Deprecated Parameters
这部分显示了所有在初始化参数文件中已被 11.2 数据库不推荐使用的参数。
Appendix A: “Deprecated Initialization Parameters” for a list of initialization parameters that are deprecated in Oracle Database 11g release 2 (11.2).

Obsolete Parameters:
这部分显示了所有在初始化参数文件中已被 11.2 数据库废弃掉的参数。这些被废弃的参数需要在升级前从初始化参数文件中移出。被废弃的参数在新的 11.2 数据库中不再有效。
Appendix B: “Obsolete Initialization Parameters” for a list of initialization parameters that are obsolete in Oracle Database 11g release 2 (11.2)

Components
这部分显示在当前的数据库被升级后,新的 11.2 数据库中被升级或者安装的数据库组件。

Miscellaneous Warnings
这部分显示在升级前和升级后其它特定的需要注意的地方。

SYSAUX Tablespace
这部分显示 SYSAUX tablespace 的最小值, 这个 tablespace 在新的 11.2 数据库中是必要的。在新的数据库启动后但是没有运行升级脚本前, 这个 tablespace 如果不存在的话需要被创建 (比如 Oracle9i)。

注意:如果 SYSAUX 是在 9i 数据库中创建的,那么在用新的数据库软件启动数据库后,这个 tablespace 需要被重建. 如果 SYSAUX 是在 10g 或之后版本数据库中创建的,那么不需要重建。

为升级数据库做准备

第3步

检查源库的一致性。

在升级前从 My Oracle Support 文档下载并运行 dbupgdiag.sql 脚本来检查源库的一致性:

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

如果 dbupgdiag.sql 脚本报告了任何无效对象,则运行 $ORACLE_HOME/rdbms/admin/utlrp.sql(可能需要多次)以使数据库中的无效对象变为有效,直至无效对象数目不发生变化为止:

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus “/ as sysdba”
SQL> @utlrp.sql

使无效对象有效之后,再次在数据库中重新运行 dbupgdiag.sql,然后确保一切正常。

第4步

弃用的 CONNECT 角色。

在数据库从 9.2 版本或 10.1 版本升级到 11.2 版本之后, CONNECT 角色就只包含 CREATE SESSION 权限了;在低版本数据库中赋予 CONNECT 角色的其它权限在升级的过程中都被收回了。在你的数据库找到哪个用户或者角色被赋予CONNECT角色,可以使用下面的语句:

SELECT grantee FROM dba_role_privs
WHERE granted_role = ‘CONNECT’ and
grantee NOT IN (
‘SYS’, ‘OUTLN’, ‘SYSTEM’, ‘CTXSYS’, ‘DBSNMP’,
‘LOGSTDBY_ADMINISTRATOR’, ‘ORDSYS’,
‘ORDPLUGINS’, ‘OEM_MONITOR’, ‘WKSYS’, ‘WKPROXY’,
‘WK_TEST’, ‘WKUSER’, ‘MDSYS’, ‘LBACSYS’, ‘DMSYS’,
‘WMSYS’, ‘EXFSYS’, ‘SYSMAN’, ‘MDDATA’,
‘SI_INFORMTN_SCHEMA’, ‘XDB’, ‘ODM’);

如果这些用户或者角色需要除了 CREATE SESSION 以外其它的权限,可以在升级前显式的赋予这些权限。
升级的脚本会自动调整 ORACLE 提供的用户的相关权限。

在 9.2.x 和 10.1.x 数据库中, CONNECT 角色包含下面的权限:

SELECT GRANTEE,PRIVILEGE
FROM DBA_SYS_PRIVS
WHERE GRANTEE =’CONNECT’

GRANTEE PRIVILEGE
——- ———————-
CONNECT CREATE VIEW
CONNECT CREATE TABLE
CONNECT ALTER SESSION
CONNECT CREATE CLUSTER
CONNECT CREATE SESSION
CONNECT CREATE SYNONYM
CONNECT CREATE SEQUENCE
CONNECT CREATE DATABASE LINK

从 ORACLE 数据库 10.2 开始,CONNECT 角色就只包含 CREATE SESSION 权限了

第5步

为 DBLINK 创建脚本 (如果升级后的数据库需要再降级,才需要执行这个步骤)。

在数据库从 9.2 版本或 10.1 版本升级到 11.2 版本时,所有 dblink 的密码会被加密。在需要降级数据库到之前版本的时候, 所有拥有加密的密码的 dblink 都需要在降级前被删除掉,因此降级后的数据库中就没有 dblink 了。如果有预感这个数据库还要被降级到之前的版本,那么从 SYS.LINK$ 表保存受到影响的 dblink 的信息,这样在降级后可以重建这些 dblink:

SELECT ‘CREATE ‘||DECODE(U.NAME,’PUBLIC’,’public ‘)||’DATABASE LINK ‘||CHR(10)
||DECODE(U.NAME,’PUBLIC’,Null, ‘SYS’,”,U.NAME||’.’)|| L.NAME||chr(10)
||’CONNECT TO ‘ || L.USERID || ‘ IDENTIFIED BY “‘||L.PASSWORD||'” USING
”’||L.HOST||””
||chr(10)||’;’ TEXT
FROM SYS.LINK$ L, SYS.USER$ U
WHERE L.OWNER# = U.USER#;


第6步

检查 TIMESTAMP WITH TIMEZONE 类型的数据

数据库 DST patching 在 11gR2 上有了极大的改进,和升级之前的版本(比如从 10.2.0.4 升级到 11.1.0.7)不同, 在升级前不需要再打任何”dst patches”了。

如果把一个低版本的数据库升级到 11.2, 那么升级后 DST 的版本应该还和升级前的 DST 版本一致。

但是对于一些特殊的情况,还有一些额外的步骤需要做。根据需要升级到的 11.2 的具体版本不同, 在升级前请一定检查下面的文档:

Note 1579838.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.4 Patchset
Note 1358166.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3 Patchset
Note 1201253.1 :  Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 Patchset
Note 815679.1 :   Actions For DST Updates When Upgrading To 11.2.0.1 Base Release

虽然在大部分的情况下不需要做什么额外的操作,但是稳妥起见还是要遵循上面的文档。

如果文档提到要在升级前对 11gR2 的 ORACLE_HOME 打 DST 补丁,那么在执行这个文档的其它步骤前,一定先做下面的操作:

确保

SQL> conn / as sysdba
SQL> select TZ_VERSION from registry$database;

返回的数据库 DST 版本是源数据库版本的 DST 版本。

如果 select 返回错误或者一个其它的版本, 那么需要重新运行 utlu112i.sql (Pre-Upgrade Information Tool) 脚本并再次检查。

第7步

检查国家字符集(NLS_NCHAR_CHARACTERSET)是否是 UTF8 或者 AL16UTF16。

select value from NLS_DATABASE_PARAMETERS where parameter = ‘NLS_NCHAR_CHARACTERSET’;

如果返回结果是 UTF8 或者 AL16UTF16,那么什么都不需要做了。
如果返回结果不是 UTF8 或者 AL16UTF16,那么请参考下面的文档:

Note 276914.1 The National Character Set in Oracle 9i and 10g.

第8步

优化器统计信息

在升级数据库到 11gR2 时,会对缺少统计信息的数据字典收集统计信息。对于拥有很多数据字典表的数据库,这个操作可能会很消耗时间. 统计信息收集的工作只影响缺少统计信息的表,或者在升级过程中改变很大的表。

要检查哪些 schemas 缺少统计信息,可以检查 utlu112i.sql 脚本的输出或者下载并运行下面文档中的脚本:

Note 560336.1 Script to Check Schemas with Stale Statistics

为了减少因为统计信息收集而造成的停机时间, 可以在升级数据库之前完成收集统计信息的工作。对于 10.1 版本的数据库,ORACLE 推荐使用 DBMS_STATS.GATHER_DICTIONARY_STATS 来收集统计信息。如,可以使用下面的命令:

$ sqlplus “/as sysdba”

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

对于 9.2 版本的数据库可以使用 DBMS_STATS.GATHER_SCHEMA_STATS 来收集统计信息.要完成这个工作,可以使用 Appendix B 中提供的脚本。

Appendix B 有一个示例脚本,它会创建 dictstattab 表,并把数据库相关组件所对应的 schema 的统计信息导入到这个表。如果数据库中缺少某个组件或者相关组件是失效的,那么这个脚本可能会报一些错误。

如果我们想把这些统计信息再导回到数据库中,这个脚本是很有用的。

比如下面的 PL/SQL 代码可以在删除掉 SYS schema 的统计信息后再导回:

SQL> EXEC DBMS_STATS.DELETE_SCHEMA_STATS(‘SYS’);
SQL> EXEC DBMS_STATS.IMPORT_SCHEMA_STATS(‘SYS’,’dictstattab’);

第9步

禁用 Oracle Database Vault

如果升级的是 10.2 版本的数据库,并且当前的 ORACLE_HOME 启用了 Oracle Database Vault, 那么在升级前必须要把目标 11gR2 数据库的 Oracle Database Vault 禁用掉,并在升级结束后启用。
如果 Oracle Database Vault 在升级时是启用的,那么 DBUA 会返回一个错误要求我们把 Oracle Database Vault 禁用。

我们在升级前必须要把数据库的 Oracle Database Vault 禁用掉,并在升级结束后再次启用。

请参照下面的文档来获得关于禁用/启用 Oracle Database Vault 的详细信息:

Disabling and Enabling Oracle Database Vault

或者

参照下面的文档来禁用/启用 Oracle Database Vault:

Note 453903.1  – Enabling and Disabling Oracle Database Vault in UNIX
Note 453902.1  – Enabling and Disabling Oracle Database Vault in WINDOWS

第10步

备份 Enterprise Manager Database Control 的数据。如果 Enterprise Manager Database Control 没有配置或者没有使用,这个步骤可以忽略。

如果在升级数据库到 11.2 版本后,有需要把 Oracle Enterprise Manager Database Control 降级,那么我们必须在升级前备份 Database Control 的文件才可以. 工具 emdwgrd 可以用来在升级前保存 Database Control 的数据,这个工具存在于 11.2 版本的数据库的 ORACLE_HOME/bin 目录下。

1. 设置 ORACLE_HOME 到旧的数据库版本
2. 设置 ORACLE_SID 为要升级的数据库 SID
3. 设置 PATH, LD_LIBRARY_PATH 和 SHLIB_PATH 到旧的 ORACLE_HOME 相关的目录下

     如 : export SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
4. 切换目录到 11gR2 数据库软件的 ORACLE_HOME/bin
5. 运行 emdwgrd 命令
a. 对于单数据库实例 (非 RAC) 运行下面的命令

$ emdwgrd -save -sid old_SID -path save_directory

old_SID 是要升级的那个数据库的 SID, save_directory 是用来存放 Database Control 文件和数据的目录。

@Note 870877.1  How To Save Oracle Enterprise Manager Database Control Data Before Upgrading The Single Instance Database To Other Release ?

b. 对于 RAC 数据库,需要跨节点远程拷贝.定义一个环境变量来指向远程拷贝的命令。如

$ emdwgrd -save -cluster -sid old_SID -path save_directory

注意,如果 10g 数据库的 ORACLE_HOME 是放在共享存储上的,那么上面的命令还需要指定 -shared 参数。

上面的命令可能会在 HPUX 上失败,这个一个已知问题,请参照下面的文档:

Note 562980.1 – emdwgrd core dumps : emdwgrd[228]: 10366 Memory fault(coredump)

6. 输入 SYS 用户的密码。
注意:在 RAC 数据库上,还需要在每个节点上执行’/tmp/racdwgrd_dbctl.sh’ 。

第11步

配置 Network ACL

Oracle 11gR2 对于使用了 XDB 的 UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, 或者 UTL_INADDR 包引入了更加细粒度的访问控制. 如果你有应用程序用到了这些包,那么必须安装 XDB. 在这些包能正常使用前,必须配置网络访问控制列表(ACLs)。具体的步骤会在第35步提到,因为需要使用的包 DBMS_NETWORK_ACL_ADMIN 是在升级后才有的,升级前没有。

第12步

这个步骤是选做的,是为了检查底层表和依赖的表是否有损坏引入的。
这个步骤可以避免稍后在升级过程中因为数据损坏造成的失败,如果有数据损坏,那么升级很有可能会失败。

可以在 sqlplus 使用下面语句检查数据字典的损坏(connected as sys):

Set verify off
Set space 0
Set line 120
Set heading off
Set feedback off
Set pages 1000
Spool analyze.sql

SELECT ‘Analyze cluster “‘||cluster_name||'” validate structure cascade;’
FROM dba_clusters
WHERE owner=’SYS’
UNION
SELECT ‘Analyze table “‘||table_name||'” validate structure cascade;’
FROM dba_tables
WHERE owner=’SYS’
AND partitioned=’NO’
AND (iot_type=’IOT’ OR iot_type is NULL)
UNION
SELECT ‘Analyze table “‘||table_name||'” validate structure cascade into invalid_rows;’
FROM dba_tables
WHERE owner=’SYS’
AND partitioned=’YES’;

spool off

它会创建一个脚本 analyze.sql。
现在执行这个脚本:

$ sqlplus “/ as sysdba”
SQL> @$ORACLE_HOME/rdbms/admin/utlvalid.sql
SQL> @analyze.sql

这个脚本(analyze.sql)不应该返回任何错误。

注意:
1. 如果存在外部表,那么可能会发生ORA-30657. 但是根据文档 Note 209355.1 ORA-30657: Using ANALYZE TABLE for an External Table,这个错误可以忽略掉。

2. 在执行脚本时下面这样的错误可以忽略掉:
SP2-0734: unknown command beginning “SQL> SELEC…” – rest of line ignored.
SP2-0042: unknown command “SQL>” – rest of line ignored.
SP2-0734: unknown command beginning “SQL> spool…” – rest of line ignored.

3. 在分析 AWR 相关的表(WRH$_…)可能会返回”ORA-00054: resource busy and acquire with NOWAIT specified”的错误。变通方案是把 AWR 临时禁用。

3.a) 找到当前快照间隔时间(snapshot interval)

       select snap_interval,retention from dba_hist_wr_control;

3.b) 把快照间隔时间改为 0 来临时禁用 AWR:

    exec dbms_workload_repository.modify_snapshot_settings(interval=>0);

3.c) 分析以 WRH$ 开头的表

3.d) 把快照间隔时间恢复到原来的值:

  exec dbms_workload_repository.modify_snapshot_settings(interval=><value in mn of snap_interval returned at 3.a>);


第13步

在升级数据库前,我们需要确认所有的物化视图都已经完成了刷新,并且复制已经停止。
用下面的语句检查当前是否有物化视图正在刷新:

SQL> select distinct(trunc(last_refresh)) from dba_snapshot_refresh_times;

SQL> select s.obj#,o.obj#,s.containerobj#,lastrefreshdate,pflags,xpflags,o.name,o.owner#, bitand(s.mflags, 8) from obj$ o, sum$ s
where o.obj# = s.obj# and o.type# = 42 AND bitand(s.mflags, 8) = 8;

如果第二个语句返回一些行, 请参照文档 Note 1442457.1 : During 11g Upgrade, Mview refresh warning

第14步

确保没有数据文件需要介质恢复(media recovery)或处于备份的状态。

SELECT * FROM v$recover_file;
SELECT * FROM v$backup WHERE status != ‘NOT ACTIVE’;

以上的语句不应该有任何返回行。

第15步

密码保护的角色。

在 11.2 版本的数据库里,密码保护的角色默认是不启用的。
如果你的程序依赖默认启用的密码保护的角色,那么它无法来使用 set role 命令来启用密码。建议删除这些角色的密码。
关于更多信息,请参考下面的文档:

Note 745407.1 : What Roles Can Be Set as Default for a User?
Oracle Database Security Guide 10g Release 2 (10.2) Part Number B14266-07
Oracle Database Security Guide 11g Release 1 (11.1) Part Number B28531-15
Oracle Database Security Guide 11g Release 2 (11.2) Part Number E16543-09


第16步

在升级前把未决的分布式事务处理掉。

SQL> select * from dba_2pc_pending;

如果它有返回行,那么用下面的命令处理掉未决的分布式事务:

SQL> SELECT local_tran_id
FROM dba_2pc_pending;
SQL> EXECUTE dbms_transaction.purge_lost_db_entry(”);
SQL> COMMIT;

第17步

用下面的命令检查是否配置了 standby 数据库

SELECT SUBSTR(value,INSTR(value,’=’,INSTR(UPPER(value),’SERVICE’))+1)
FROM v$parameter
WHERE name LIKE ‘log_archive_dest%’ AND UPPER(value) LIKE ‘SERVICE%’;


如果上面的语句有返回行,那么把相应的 standby 数据库与主库进行同步。
1. 确保最后一次 log switch 之后的所有日志都已经传输到 standby 库中。
2. 在standby库中,使用NODELAY的选项来恢复standby库。

第18步

禁用所有的cron job和数据库。
对于 Oracle 数据库的 job,可以使用 DBMS_JOB, DBMS_SCHEDULER 去停掉它们;对于 cron job(由 OS 控制的 job), 需要您的系统管理员来帮忙禁掉它们。

对于使用 DBMS_JOB, DBMS_SCHEDULER,以下文档可以参考:

Note 404238.1 : How to Disable an Entry from DBMS_SCHEDULER
Note 1335741.1 : How To Stop A Running Job Using DBMS_JOB
Note 67695.1 : PROCEDURE DBMS_JOB.BROKEN Specification

第19步

确保 sys 和 system 用户的默认 tablespace 是 SYSTEM。
必须确保 system tablespace 里有足够的空间或者设置成 extents 无限制。

SQL> SELECT username, default_tablespace
FROM dba_users
WHERE username in (‘SYS’,’SYSTEM’);

default_tablespace 的值应该是 SYSTEM, 如果不是的话,可以用下面命令纠正。

SQL> ALTER user SYS default tablespace SYSTEM;
SQL> ALTER user SYSTEM default tablespace SYSTEM;

第20步

确保如果 AUD$ 表存在,它需要属于 SYS 用户并存在于 SYSTEM 表空间。

SQL> SELECT owner,tablespace_name
FROM dba_tables
WHERE table_name=’AUD$’;

如果在升级前 AUD$ 表不属于 SYS 用户或者不存在于 SYSTEM 表空间,那么需要在升级前把它放回 SYSTEM 表空间并属于 SYS 用户。

注意:如果 AUD$ 存在并且非空,那么表里的数据的多少会影响升级的性能。

第21步

检查数据库是否有外部验证的的 SSL 用户(externally authenticated SSL users)。

SQL> SELECT name FROM sys.user$
WHERE ext_username IS NOT NULL
AND password = ‘GLOBAL’;

如果有,那么在升级后做第33步。

第22步

记下数据文件,重做日志和控制文件的路径,并且备份所有的配置文件,如 listener.ora, tnsnames.ora 等等。

SQL> SELECT name FROM v$controlfile;
SQL> SELECT file_name FROM dba_data_files;
SQL> SELECT group#, member FROM v$logfile;.

第23步

如果你已经升级了 Grid Infrastructure, 那么这一步可以忽略,因为它已经包含在 Grid Infrastructure 的升级里了。

a) 停掉数据库的 listener。

$ lsnrctl stop

之前版本的 listener 不能用在 11.2 的数据库上,但是 11.2 的 listener 可以用在之前版本的数据库上。
如果是从 9i 升级或者手工升级,那么需要在升级 RAC 数据库之前运行 netca。

它包含两个步骤:
需要先运行旧的 Oracle_home 里的 netca 删除当前的 listener。
– 运行 Netca
– 选择配置 => 选择 Listener Configuration
– 选择删除选项 => Delete
– 选择要删除的 listener 来删除它

然后在新的 ORACLE_HOME 里运行 netca 来添加新 listener。

– 运行 Netca
– 选择配置 => 选择 Listener Configuration
– 选择添加选项 => Add
– 提供详细信息来添加 listener

必须在添加新 listener 之前删掉旧的,如果新 listener 和旧 listener 用到了相同的名字或者端口号,netca 会返回错误。

注意: 如果要手工升级 RAC 数据库,那么这一步是必须要做的。

b) 停掉其它的相关程序,如 dbconsole, isqlplus 等。

$ emctl stop dbconsole
$ isqlplusctl stop

第24步

停掉数据库。

$ sqlplus “/as sysdba”
SQL> shutdown immediate;

备份数据库

1. 冷备份
或者
2. 使用RMAN备份

Connect to RMAN:

rman “target / nocatalog”

RUN
{
ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT ‘<db_backup_directory>%U’ TAG before_upgrade;
BACKUP CURRENT CONTROLFILE TO ‘<controlfile_backup_directory>’;
}

–> backup_directory >> 存放数据库备份的目录。
–> controlfile_backup_directory >> 存放控制文件备份的目录。

第25步

– 从源 ORACLE_HOME 拷贝初始化参数文件到目标 ORACLE_HOME/dbs 下(如果是 Windows 平台,那么是 ORACLE_HOME/database 目录)

– 之后修改目标 ORACLE_HOME/dbs 下(如果是Windows平台,那么是 ORACLE_HOME/database 目录)的参数文件:

注释掉被废弃的参数 (Appendix A),然后修改所有不推荐的参数 (Appendix A)。

同时建议在升级前删掉所有手工设置的隐藏参数。

* DIAGNOSTIC_DEST 初始化参数替换掉了 USER_DUMP_DEST, BACKGROUND_DUMP_DEST 两个初始化参数。

根据 Bug 8937877,CORE_DUMP_DEST 并没有被废弃。

要理解 11g 的目录结构和 DIAGNOSTIC_DEST 参数,请参考下面的文档:

Note 454442.1 11g Install : Understanding about Oracle Base, Oracle Home and Oracle Inventory locations

* 如果要从 9.2.0.x 升级到 11gR2, 那么 COMPATIBLE 参数最小设成 10.0.0 或更大。10.0.0 是可以升级到 11.2 的最小的 COMPATIBLE 参数值。
这个值在升级的过程中不能变,但是可以在升级成功后改成更大的值。
(请注意,一旦这个 COMPATIBLE 参数设置成了 10.1,那么这个数据库再也不能降到 9iR2, 参考文档
Note 388604.1 : ORA-00201 while downgrading from 10gR2 to 10gR1 or 9iR2 )。

Oracle 建议在升级后做完详细的测试后再加大 COMPATIBLE 参数的值。

如果是从 10.1.0.x 或者 10.2.0.x 升级,可以先不改 COMPATIBLE 的值,在升级完成后再改动。
这样可以避免一些升级过程中在 smon trace 里生成 ORA-942 错误 (因为升级会检查一些还未创建的 10.2 的对象)。

* 更改那些 Pre-Upgrade Information Tool 提示需要设置最小值的初始化参数来满足需要。
确保参数文件中的目录名都是使用的绝对路径而不是相对路径。

* 如果升级的是 RAC 数据库,那么在升级前把 CLUSTER_DATABASE 设置成 false 并在升级后改回成 true。

第26步

如果你的操作系统是 Windows,那么需要做这一步,如果不是那么可以忽略掉这一步。

停掉要升级的那个数据库的服务 OracleServiceSID, SID 是 instance 的名字.比如,如果 SID 是 ORCL,那么执行下面的命令:

设置相应的环境变量对应到源库上(9.2/10.1/10.2/11.1)

1. 停掉数据库服务。

C:\> NET STOP OracleServiceORCL

2. 使用 ORADIM 命令删掉源库的服务:

C:\> ORADIM -DELETE -SID ORCL

3. 用新库的 ORADIM 工具创建一个 11gR2 的数据库 service:

C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD  -STARTMODE AUTO -PFILE %ORACLE_HOME%\DATABASE\INIT<SID>.ORA

比如:

C:\> ORADIM -NEW -SID ORCL -INTPWD <PASSWORD> -STARTMODE AUTO -PFILE %ORACLE_HOME%\DATABASE\INIT<SID>.ORA

第27步

如果你的操作系统是 UNIX,那么需要做这一步,如果不是那么可以忽略掉这一步。

1. 确认下面的环境变量指向了新版本数据库的目录:

– ORACLE_BASE
– ORACLE_HOME
– PATH, LD_LIBRARY_PATH , SHLIB_PATH  and LIBPATH ( for AIX )

比如:

$ export ORACLE_HOME=<location of Oracle 11.2>
$ export PATH=$ORACLE_HOME/bin:$PATH
$ export ORACLE_BASE=<Oracle_Base set during installation>
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
$ export SHLIB_PATH=$ORACLE_HOME/lib:$SHLIB_PATH
$ export LIBPATH=$ORACLE_HOME/lib:$LIBPATH

注意: 如果不知道 ORACLE_BASE, 在 PATH 变量包含了 11gR2的Oracle Home 之后,执行 ‘orabase’ 会提示 ORACLE_BASE 的值。

注意: 如果设置了 ORA_TZFILE 环境变量,需要删掉这个环境变量。

$ orabase
/uo1/app/oracle

2. 更改 /etc/oratab 文件,让 ORCL 指向新的 ORACLE_HOME 并且禁用自动启动。

/etc/orata b的一个例子

#orcl:/opt/oracle/product/10.2/db_1:N
orcl:/opt/oracle/product/11.2/db_1:N

注意: 在改掉 /etc/oratab 之后可以使用 oraenv (/usr/local/bin/oraenv)来设置新的环境变量,需要输入 /etc/oratab 中的指向 11gR2 的那个 SID。

比如:

[oracle@localhost ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2/db_1 is /u01/app/oracle
[oracle@localhost ~]$

升级数据库到11gR2

第28步

在 OS 里,进入 11gR2 的 $ORACLE_HOME/rdbms/admin 里。

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus “/ as sysdba”
SQL> startup UPGRADE

注意: 如果是从 9.2 升级并且 SYSAUX 表空间已经存在,那么需要 drop 掉已存在的 SYSAUX。在数据库用 11gR2 的软件使用 upgrade 模式启动后 SUSAUX 表空间应该立刻被重建。(Compatibility 最小设为 10.1 并且在执行 catupgrd.sql 之前)。

只有在从 9.2 升级到 11gR2 时才需要重建 SYSAUX 表空间,在重建时需要有下面的属性:

ONLINE
PERMANENT
READ WRITE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO

Pre-Upgrade Information Tool 会在输出结果的 SYSAUX 表空间部分预估出 SYSAUX 表空间需要的最小值。可以参照在第一步中 utlu112i.sql 脚本的输出日志。
下面的例子会创建一个 500M 的 SYSAUX 表空间:

SQL> CREATE TABLESPACE SYSAUX
DATAFILE ‘<location>/sysaux01.dbf’
SIZE 500M REUSE
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;

使用 spool 设置一个日志文件,这样可以在升级后检查升级的过程,并执行升级脚本。

SQL> set echo on
SQL> SPOOL upgrade.log
SQL> @catupgrd.sql
SQL> spool off

这个非常重要的步骤可以确保新的数据库软件的完整性和一致性。如果在启动数据库时碰到错误说参数文件中含有被废弃的初始化参数,那么从初始化参数文件中删除这些参数。如果需要的话,可以把 spfile 转换成 pfile 之后就可以编辑 pfile 并删除相关参数了。

执行 Post-Upgrade Status Tool $ORACLE_HOME/rdbms/admin/utlu112s.sql, 它会提供一个关于升级的总结. 它会显示升级后各个数据库组件的状态和各个组件升级花费的时间。任何在升级中碰到的错误也会被列出,这些错误必须得到妥善的处理。

$ sqlplus “/as sysdba”
SQL> STARTUP
SQL> @utlu112s.sql

运行 $ORACLE_HOME/rdbms/admin 目录下的 catuppst.sql, 完成不需要在数据库处于 UPGRADE 模式下操作的其它升级的动作:

SQL> @catuppst.sql

这个脚本可以和 utlrp.sql 并行运行. 在另一个 session 里运行 utlrp.sql 来重新编译剩下的 PL/SQL 和 Java 代码:

SQL> @utlrp.sql

运行从下面文档中得到的 dbupgdiag.sql 来检查升级后数据库的完整性。

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

如果 dbupgdiag.sql 发现了一些失效对象,那么多次执行 $ORACLE_HOME/rdbms/admin/utlrp.sql 来重新编译这些失效对象,直到失效对象的数目不再变化。

在重新编译这些失效对象之后,再次运行 dbupgdiag.sql 确认一切都是正常的。

升级后的步骤

第29步

验证 listener.ora 文件。

确认 ORACLE_HOME 环境变量指向了升级后的 ORACLE_HOME,然后启动listener。

lsnrctl start


第30步

环境变量

1. 确认下面的环境变量指向了新的 Oracle 11gR2:

– ORACLE_BASE
– ORACLE_HOME
– PATH, LD_LIBRARY_PATH, SHLIB_PATH and LIBPATH ( for AIX )

并且检查 oratab 文件和其它的客户端脚本,确认是指向了正确的 11gR2 HOME。

注意: 如果是升级的 RAC 数据库,那么需要在所有的节点上检查。

2. 更改 /etc/oratab 去打开自动启动。

SID:ORACLE_HOME:Y

比如:
orcl:/opt/oracle/product/11.2/db_1:Y

第31步

注意: 这个步骤实际上是根据第6步里提到的文档里的内容做的。

在升级后检查数据库时区的当前版本:

SQL> conn / as sysdba
Connected.
SQL>SELECT version FROM v$timezone_file;

VERSION
———-
4

这个值应该和升级前的值一样的。

如果这个值大于 11(for 11.2.0.1 ) 或 14 (for 11.2.0.2 and 11.2.0.3), 那么忽略这个步骤直接去执行第32步

如果这个值等于 11(for 11.2.0.1 ) 或 14 (for 11.2.0.2 and 11.2.0.3), 那么忽略这个步骤直接去执行第32步

如果这个值小于 11(for 11.2.0.1 ) 或 14 (for 11.2.0.2 and 11.2.0.3), 那么*推荐*升级 DST 的版本

*对于 11.2.0.1,使用文档 Note 1585343.1 Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database 中的脚本把数据库 DST 版本升级到 DSTv11 (standard DST version of 11.2.0.1)。
或者
参照文档 Note 977512.1 Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST (从步骤 3a 开始)来升级,把那篇文档里提到的 the new DST version number 替换成 11。

*对于11.2.0.2 , 11.2.0.3 和 11.2.0.4, 使用文档 Note 1585343.1 :  Scripts to automatically update the RDBMS DST (timezone) version in an 11gR2 or 12cR1 database 中的脚本把数据库 DST 版本升级到 DSTv14 (standard DST version of (for 11.2.0.2 , 11.2.0.3 and 11.2.0.4)。
或者
参照文档 Note 977512.1 Updating the RDBMS DST version in 11g Release 2 (11.2.0.1 and up) using DBMS_DST (从步骤 3a 开始)来升级,把那篇文档里提到的 the new DST version number 替换成 14。

注意:

* 在 11gR2 里使用低版本的 DST 是支持的,但是从技术角度讲,没有必要使用低版本的 DST。
所以我们强烈推荐升级到 11gR2 版本里自带的最高版本的 DST。

* 或者我们还可以升级到当前最高版本的 DST, 您可以从下面的文档找到当前最高版本的 DST:
Note 412160.1 :  Updated DST transitions and new Time Zones in Oracle Time Zone File patch

第32步

升级那些使用 DBMS_STATS 创建的统计信息表(Statistics Tables)。

如果我们使用 DBMS_STATS.CREATE_STAT_TABLE 手工创建了一些统计信息表(statistics tables),那么执行下面的命令来升级这些表(如果没有创建过统计信息表,那这一步骤可以忽略)。例如:

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE(‘SYS’,’dictstattab’);

在上面的例子里, ‘SYS’ 是统计信息表的 owner, ‘dictstattab’ 是统计信息表的表名。对每个统计信息表都要执行一遍上面的命令。

第33步

升级外部验证的的 SSL 用户。

如果数据库是从 9.2.0.x 或 10.1.0.x 升级上来的并且之前使用了外部验证的的 SSL 用户,那么需要执行下面的命令来升级这些用户:

ORACLE_HOME/rdbms/bin/extusrupgrade –dbconnectstring
<hostname:port_no:sid> –dbuser <db admin> –dbuserpassword
<password> -a

如果是从 10.2.0.x(或更高)升级上来的,那么这个步骤可以忽略。

第34步

启用 Database Vault

如果数据库之前使用了 Database Vault,那么参考下面的文档来启用 Database Value (如果之前没有使用 Database Vault,那这一步骤可以忽略):

Note 453903.1 – Enabling and Disabling Oracle Database Vault in UNIX
Note 453902.1 – Enabling and Disabling Oracle Database Vault in WINDOWS

第35步

对外部网络服务(External Network Services)配置细粒度的访问控制。

为了避免在执行和网络相关的 UTL 程序包的时候引发”ORA-24247: network access denied by access control list (ACL)”的错误,访问权限需要赋给使用这些程序包的用户。

下面的例子先查找当前已经分配给 host_name 的访问控制列表(ACL), 如果发现了就赋给 user_name CONNECT 的权限(如果它没有的话)。
如果没有访问控制列表(ACL)存在,就创建叫做 ACL_name 的访问控制列表(ACL),并且把 CONNECT 权限赋给 user_name,然后把这个 ACL 分配给 host_name。

DECLARE
acl_path VARCHAR2(4000);
BEGIN
SELECT acl INTO acl_path FROM dba_network_acls
WHERE host = ‘host_name’ AND lower_port IS NULL AND upper_port IS NULL;
IF DBMS_NETWORK_ACL_ADMIN.CHECK_PRIVILEGE(acl_path,’principal’,’privilege’) IS NULL THEN
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(acl_path,’principal’, is_grant, ‘privilege’);
END IF;
EXCEPTION
WHEN no_data_found THEN
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(‘ACL_name.xml’,’ACL description’, ‘principal’, is_grant, ‘privilege’);
DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL(‘ACL_name.xml’,’host_name’);
END;

COMMIT;

acl_name.xml => 指定访问控制列表的XML文件的名字,
ACL description => 文件的描述,
principal => ‘用户或者角色’,
is_grant => TRUE|FALSE,
privilege => ‘connect|resolve’,
host_name => 主机名

关于如何使用 DBMS_NETWORK_ACL_ADMIN 程序包并避免 ORA-24247 : network access denied by access control list (ACL)请参照下面的文档:

Note 453786.1 ORA-24247 When Executing UTL_HTTP UTL_INADDR Packages

第36步

编辑 init.ora

  • 如果在升级前改动过 CLUSTER_DATABASE,那么需要再把它改回来。
  • 把 pfile 文件改回到 spfile

从 pfile 创建 spfile。

SQL> create spfile from pfile;

它会根据 $ORACLE_HOME/dbs (UNIX)或者%ORACLE_HOME%\database (Windows)目录下的 pfile 产生一个新的 spfile。

第37步

改 Oracle 提供的用户的密码。

根据升级前数据库的版本,可能会存在一些 Oracle 自带的用户。Oracle 推荐把除了 SYS 和 SYSTEM 之外的这样的用户都锁住并让它们的密码过期。
这样在把这些用户解锁的时候就会提示重新设置新密码。

可以用下面的命令检查所有帐号的状态:

SQL> SELECT username, account_status FROM dba_users ORDER BY username;

使用下面的命令锁定用户并让它的密码过期:

SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;

第38步

升级 Oracle Text

只有在使用了 Oracle Text 的时候才需要做这一步。

注意: 如果数据库升级前/后都是同一个大版本( 比如从 11.2.0.1 升级到 11.2.0.2), 那么是不需要做这一步的。

把下面的文件从原 ORACLE HOME 拷贝到新 Oracle Home:

* Stemming user-dictionary 文件
* User-modified KOREAN_MORPH_LEXER dictionary 文件
* USER_FILTER 可执行程序

如果版本是 920, 101, 102,那么下面的文件包含有这些文件的列表:

$ORACLE_HOME/ctx/admin/ctxf<version>.txt
$ORACLE_HOME/ctx/admin/ctxf<version>.sql

比如,如果数据库是从 10.2.0 升级上来的:

1. 对于 User Extended Knowledge Base 文件,检查
$ORACLE_HOME/ctx/admin/ctxf102.txt
2. 使用数据库拥护 SYS,SYSTEM 或者 CTXSYS 执行下面的脚本
$ORACLE_HOME/ctx/admin/ctxf102.sql

如果 Oracle Text 索引用到了 KOREAN_LEXER(在 9i 里不推荐使用了并在 10gR2 里被废弃了), 那么参考下面的文档去手工迁移 KOREAN_LEXER 到 KOREAN_MORPH_LEXER:

Note 300172.1  Obsolescence of KOREAN_LEXER Lexer Type

如果是升级到 11.2.0.3,对于 Lexer Feature Updates 请参考下面的文档:

Note 1354793.1 Oracle Text 11.2.0.3 Support Note for Lexer Feature Updates

对第38步,还可以参考下面的文档来获得更详细的信息:

Note 1319592.1 Upgrading Oracle Text Post 10.2.0.4 To 11.2.0.2 Upgrade

第39步

升级 Oracle Clusterware 的配置

如果升级的是 10.2, 11.1 或 11.2.0.1 的 RAC 数据库,那么要用下面的命令在 Oracle 集群软件里升级数据库的配置:

$ srvctl upgrade database -d db-unique-name -o oraclehome

这里的 db-unique-name 是指的数据库的名字(不是 instance name),oraclehome 是 Oracle Home 的路径。

第40步

配置 Enterprise Manager

只有在数据库使用了 DBconsole 的时候才需要做这一步,如果没有配置 Dbconsole 或者这个数据库没有被 Grid Control 监控,那么忽略这一步。

如果数据库使用了 Enterprise Manager Database Control , 那么使用下面的命令升级配置:

emca -upgrade (db | asm | db_asm) [-cluster] [-silent] [parameters]

这个命令需要在新的 Oracle 11gR2 的 Oracle Home 里运行。当需要提供 Oracle Home 时指定 Oracle Home。

Appendix A: Initialization parameters deprecated in Oracle Database 11g release 2 (11.2)

 

To get a list of all deprecated initialization parameters, issue the following SQL statement:

SQL> SELECT name FROM v$parameter WHERE isdeprecated = ‘TRUE’;

A warning message is displayed at instance startup if a deprecated parameter is specified in the parameter file. In addition, all deprecated parameters are logged to the alert log at instance startup.

Appendix A: Initialization Parameters Obsolete in Oracle Database 11g Release 2 (11.2)

DRS_START
SQL_VERSION

第41步

TDE (Transparent Data Encryption)

如果你使用了 TDE (Transparent Data Encryption)技术,那么需要重新键入 master key:

SQL> alter system set encryption key identified by “<wallet password>”;

对于其它信息请您参照文档 Note 1260584.1 : Ora-28374 After Migration From 10.2.0.4 To 11.2.0.1。

第42步

收集 Fixed Object 统计信息

请在升级后两周后收集 fixed objects 统计信息:
SQL>EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

It would to good to gather the statistic during non-peak hours

其它有用的升级文档:

Note 1561791.2 Upgrade / Downgrade Assistant: Oracle Database/Client
Note 1351112.2 Information Center: Upgrading and Migration Oracle Database
Note 785351.1 Oracle 11gR2 Upgrade Companion
Note 251.1 Database Upgrade Planner from 10.2 to 11.2
Note 264.1 Database Upgrade Planner from 9.2 to 11.2

【数据库升级】dbms_registry_sys.gather_stats过程可能过慢

dbms_registry_sys.gather_stats 存储过程在数据库字典升级 catupgrad.sql运行过程中被调用,该存储过程负责收集各 component 包括字典收集统计信息Gather Dictionary Schema Statistics ,如果 系统中AWR保存时间过长 例如30天以上,则可能耗费大量时间在收集一些WRH$、WRI$的AWR基础表上,这是正常的。 经验是 80GB的SYSAUX表空间在EMC中端存储下, Gather Dictionary Schema Statistics大约耗时58分钟; 有国外的朋友遇到过dbms_registry_sys.gather_stats(NULL)超过4小时。

 

PROCEDURE gather_stats (comp_id IN VARCHAR2);

 

文档During A Manual Database Upgrade To 11.2, Gathering Dictionary Statistics Takes Too Long (catupgrd.sql, cmpupend.sql) [ID 1425763.1]给出了一些解决方案,包括:

Solution

1. Make sure that you gather dictionary statistics as a preparation step before upgrading, by executing the following command:
SQL> EXECUTE dbms_stats.gather_dictionary_stats;

2. To reduce downtime for the database upgrade, set the following parameter in the init.ora (or spfile) before upgrading:

Note: DBUA will not retain the hidden parameter and this parameter is required to be set for the post-installation steps so setting this parameter will not help if you are upgrading database using DBUA .

_optim_dict_stats_at_db_cr_upg = false

Once all post install steps have been completed, remove (or comment out) the _optim_dict_stats_at_db_cr_upg parameter from the init.ora (or spfile)
NOTE: This parameter is only for reducing downtime during a database upgrade

3. Gather dictionary statistics again after the database has been upgraded successfully.

Please refer to the following articles for complete information about gathering statistics:
How to Gather Statistics on SYS Objects and ‘Fixed’ Objects? (Note:457926.1)
How to Gather Optimizer Statistics on 11g (Note:749227.1)

 

Oracle数据库升级与补丁

以下是Maclean.Liu 编写或收集的数据库升级(Upgrade)与补丁(patch fix)方面的知识:

 

甲骨文发布2012 1月数据库安全补丁Critical Patch Update January 2012
Oracle数据库版本10.2实际进入扩展支持Extended Support周期
Patch Set Update and Critical Patch Update October 2011补丁更新发布了
11.2.0.3 Patch Set – List of Bug Fixes by Problem Type
快速升级Oracle 11.2.0.2 RAC到11.2.0.3
Upgrade GI/CRS 11.1.0.7 to 11.2.0.2. Rootupgrade.sh Hanging
Oracle补丁集的补丁号Patch ID/Number速查
Oracle 11gR2发布11.2.0.3 Patchset补丁集-又一重量级更新
Slide:11g新特性-在线实施补丁online patching
Slide:Oracle数据库升级前必要的准备工作
深入了解Oracle数据字典升级脚本catupgrd.sql调用过程
Slide:如何安装Oracle one-off 临时小补丁及注意事项 by Maclean.liu
Slide:了解Oracle critical patch update
Slide:Upgrade 11.2.0.1 GI/CRS to 11.2.0.2 in Linux
Slide:Upgrade 11.2.0.1 RAC DB/RDBMS to 11.2.0.2 in Linux By Maclean
Upgrade 11.2.0.1 DB/RDBMS to 11.2.0.2 in Linux
Upgrade 11.2.0.1 GI/CRS to 11.2.0.2 in Linux
Applying 11G R2 GI PSU 11.2.0.2.3
Critical Patch Update July 2011 Released
了解Oracle Critical Patch Update
了解Oracle数据库的版本号
Pre-check while you are applying one-off patch
Advise on OS patch upgrade with RAC
Oracle Patch Set Update and Critical Patch Update April 2011 Released
11g新特性:Rolling Upgrade With Physical Standby
Patch your 10g Oracle database to PSU 10.2.0.4.5
7月最新发布10.2.0.4.5 Patch Set Update
Oracle Exadata Database Recommended Patch (BP3) for Bug 10387939
Startup Upgrade为我们做了什么?
深入理解Oracle Universal Installer (OUI)
Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
介绍dbms_registry PL/SQL程序包
Applying online patch on 11gr2
January 2011 Patch set Update发布
Advice on upgrading to 11.2.0.2 and converting to RAC
Oracle 9iR2 RAC to Oracle 10gR2 RAC Upgrade
Upgrading to Oracle Database 11g
如何确定所打Patch是否需要停机
Database Upgrade using Transportable Tablespaces
Upgrading to 11g–Why,How and Best Practices
Upgrade from Oracle Database 10g to 11g:What to Expect From the Optimizer
Upgrade to Oracle Database 11g: Single Instance to RAC & ASM
Applying Database PSU 10.2.0.4.6
Oct 12: Patch Set Update Released
Oracle Critical Patch Updates Unwrapped
11.2.0.2补丁集安装体验
Upgrading to RAC 11g R2 What you should know
Oracle 9i/10g/11g数据库升级路线图总览
OPatch工具相关的环境变量
使用OPATCH_DEBUG环境变量调试Opatch工具
opatch java.lang.OutOfMemoryError:Java heap space错误一例

快速升级Oracle 11.2.0.2 RAC到11.2.0.3

11.2.0.3 补丁集在美国时间9月23日发布了,关于11.2.0.3 发布的更多信息可以参考<Oracle 11gR2发布11.2.0.3 Patchset补丁集-又一重量级更新>一文。

这里我们来快速浏览由11.2.0.2 RAC升级到11.2.0.3的过程:

在正式升级GI/CRS之前需要先打上”Patch 12539000: 11203:ASM UPGRADE FAILED ON FIRST NODE WITH ORA-03113″

我们仅需要针对GI/CRS打上补丁,无需在RDBMS/DB上实施。该Patch可以滚动升级Rolling upgrade, 简易的实施流程如下:

 

1. 在所有节点上安装最新的opatch工具,该步骤不需要停止任何服务

[root@vrh1 ~]# su - grid
[grid@vrh1 ~]$ cd $CRS_HOME
[grid@vrh1 grid]$ mv OPatch OPatch_old

[grid@vrh1 grid]$ unzip /tmp/p6880880_112000_Linux-x86-64.zip -d $CRS_HOME

[grid@vrh1 grid]$ opatch
Invoking OPatch 11.2.0.1.3

Oracle Interim Patch Installer version 11.2.0.1.3
Copyright (c) 2010, Oracle Corporation.  All rights reserved.

2. 解压之前下载的 p12539000_112020_Linux-x86-64.zip 的补丁包,!!注意不要解压在/tmp目录下!!

[grid@vrh1 ~]$ mkdir /g01/patch

[grid@vrh1 ~]$ cd /g01/patch

[grid@vrh1 patch]$ unzip /tmp/p12539000_112020_Linux-x86-64.zip

Archive:  /tmp/p12539000_112020_Linux-x86-64.zip
   creating: 12539000/
   creating: 12539000/files/
   creating: 12539000/files/lib/
   creating: 12539000/files/lib/libserver11.a/
  inflating: 12539000/files/lib/libserver11.a/ksxp.o  
   creating: 12539000/etc/
   creating: 12539000/etc/config/
  inflating: 12539000/etc/config/inventory.xml  
  inflating: 12539000/etc/config/actions.xml  
  inflating: 12539000/etc/config/deploy.xml  
   creating: 12539000/etc/xml/
  inflating: 12539000/etc/xml/GenericActions.xml  
  inflating: 12539000/etc/xml/ShiphomeDirectoryStructure.xml 

3. 以root用户执行# opatch auto <UNZIPPED_PATCH_LOCATION> 命令

[root@vrh1 ~]# /g01/11.2.0/grid/OPatch/opatch auto /g01/patch -oh $CRS_HOME

Executing /usr/bin/perl /g01/11.2.0/grid/OPatch/crs/patch112.pl -patchdir /g01 -patchn patch -oh
/g01/11.2.0/grid -paramfile /g01/11.2.0/grid/crs/install/crsconfig_params
2011-09-24 22:34:41: Parsing the host name
2011-09-24 22:34:41: Checking for super user privileges
2011-09-24 22:34:41: User has super user privileges
Using configuration parameter file: /g01/11.2.0/grid/crs/install/crsconfig_params
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.crsd' on 'vrh1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.FRA.dg' on 'vrh1'
................................
Backing up files affected by the patch 'NApply' for restore. This might take a while...

Applying patch 12539000...

ApplySession applying interim patch '12539000' to OH '/g01/11.2.0/grid'
Backing up files affected by the patch '12539000' for rollback. This might take a while...

Patching component oracle.rdbms, 11.2.0.2.0...
Updating archive file "/g01/11.2.0/grid/lib/libserver11.a"  with "lib/libserver11.a/ksxp.o"
ApplySession adding interim patch '12539000' to inventory

Verifying the update...
Inventory check OK: Patch ID 12539000 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 12539000 are present in Oracle Home.
Running make for target ioracle

The local system has been patched and can be restarted.

UtilSession: N-Apply done.

OPatch succeeded.
CRS-4123: Oracle High Availability Services has been started.

4. 在所有节点上重复以上步骤,并确认补丁状态

[root@vrh1 ~]# su - grid

[grid@vrh1 ~]$ opatch lsinventory
Interim patches (1) :

Patch  12539000     : applied on Sat Sep 24 22:36:35 CST 2011
Unique Patch ID:  13976979
   Created on 28 Jul 2011, 12:37:42 hrs PST8PDT
   Bugs fixed:
     12539000

 

如果没有安装以上12539000补丁,在使用OUI升级GI/CRS时会出现以下 Warning:

 

11.2.0.3_12539000_bug

 

升级11.2.0.2 GI/CRS到11.2.0.3

1.解压软件包,第三个zip包为grid软件

[grid@vrh1 tmp]$ unzip p10404530_112030_Linux-x86-64_3of7.zip

2. 以GI拥有者用户启动GI/CRS的OUI安装界面,并选择Out of Place的安装目录

(grid)$ unset ORACLE_HOME ORACLE_BASE ORACLE_SID
(grid)$ export DISPLAY=:0
(grid)$ cd  /tmp/grid
(grid)$ ./runInstaller
Starting Oracle Universal Installer…

upgrade_11.2.0.3_GI_1

 

upgrade_11.2.0.3_GI_2

 

upgrade_11.2.0.3_GI_3

 

upgrade_11.2.0.3_GI_4

 

upgrade_11.2.0.3_GI_5

 

upgrade_11.2.0.3_GI_6

 

upgrade_11.2.0.3_GI_8

 

upgrade_11.2.0.3_GI_9

 

upgrade_11.2.0.3_GI_10

 

upgrade_11.2.0.3_GI_11

 

3. 依次在所有节点上以root用户运行rootupgrade.sh升级脚本

 

su - root 

First Node [root@vrh1 ~]# /g01/11.2.0.3/grid/rootupgrade.sh

Performing root user operation for Oracle 11g 

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /g01/11.2.0.3/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /g01/11.2.0.3/grid/crs/install/crsconfig_params
Creating trace directory
User ignored Prerequisites during installation

ASM upgrade has started on first node.

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.crsd' on 'vrh1'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'vrh1'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'vrh1'
CRS-2673: Attempting to stop 'ora.oc4j' on 'vrh1'
CRS-2673: Attempting to stop 'ora.FRA.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.MACLEAN.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'vrh1'
CRS-2673: Attempting to stop 'ora.SYSTEMDG.dg' on 'vrh1'
CRS-2673: Attempting to stop 'ora.cvu' on 'vrh1'
CRS-2677: Stop of 'ora.cvu' on 'vrh1' succeeded
CRS-2672: Attempting to start 'ora.cvu' on 'vrh2'
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'vrh1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.vrh1.vip' on 'vrh1'
CRS-2677: Stop of 'ora.scan1.vip' on 'vrh1' succeeded
CRS-2672: Attempting to start 'ora.scan1.vip' on 'vrh2'
CRS-2677: Stop of 'ora.vrh1.vip' on 'vrh1' succeeded
CRS-2672: Attempting to start 'ora.vrh1.vip' on 'vrh2'
CRS-2677: Stop of 'ora.registry.acfs' on 'vrh1' succeeded
CRS-2676: Start of 'ora.scan1.vip' on 'vrh2' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN1.lsnr' on 'vrh2'
CRS-2676: Start of 'ora.cvu' on 'vrh2' succeeded
CRS-2676: Start of 'ora.vrh1.vip' on 'vrh2' succeeded
CRS-2676: Start of 'ora.LISTENER_SCAN1.lsnr' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.MACLEAN.dg' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.FRA.dg' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.oc4j' on 'vrh1' succeeded
CRS-2672: Attempting to start 'ora.oc4j' on 'vrh2'
CRS-2676: Start of 'ora.oc4j' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.SYSTEMDG.dg' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'vrh1'
CRS-2677: Stop of 'ora.asm' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'vrh1'
CRS-2677: Stop of 'ora.ons' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'vrh1'
CRS-2677: Stop of 'ora.net1.network' on 'vrh1' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'vrh1' has completed
CRS-2677: Stop of 'ora.crsd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.ctssd' on 'vrh1'
CRS-2673: Attempting to stop 'ora.evmd' on 'vrh1'
CRS-2673: Attempting to stop 'ora.asm' on 'vrh1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'vrh1'
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'vrh1'
CRS-2677: Stop of 'ora.asm' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'vrh1'
CRS-2677: Stop of 'ora.evmd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'vrh1'
CRS-2677: Stop of 'ora.cssd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'vrh1'
CRS-2673: Attempting to stop 'ora.gipcd' on 'vrh1'
CRS-2677: Stop of 'ora.gipcd' on 'vrh1' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'vrh1'
CRS-2677: Stop of 'ora.gpnpd' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.diskmon' on 'vrh1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'vrh1' has completed
CRS-4133: Oracle High Availability Services has been stopped.
OLR initialization - successful
Replacing Clusterware entries in inittab
clscfg: EXISTING configuration version 5 detected.
clscfg: version 5 is 11g Release 2.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

Last Node 

[root@vrh2 ~]# /g01/11.2.0.3/grid/rootupgrade.sh

Performing root user operation for Oracle 11g 

The following environment variables are set as:
    ORACLE_OWNER= grid
    ORACLE_HOME=  /g01/11.2.0.3/grid

Enter the full pathname of the local bin directory: [/usr/local/bin]:
The contents of "dbhome" have not changed. No need to overwrite.
The contents of "oraenv" have not changed. No need to overwrite.
The contents of "coraenv" have not changed. No need to overwrite.

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Using configuration parameter file: /g01/11.2.0.3/grid/crs/install/crsconfig_params
Creating trace directory
User ignored Prerequisites during installation
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'vrh2'
CRS-2673: Attempting to stop 'ora.crsd' on 'vrh2'
CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on 'vrh2'
CRS-2673: Attempting to stop 'ora.LISTENER.lsnr' on 'vrh2'
CRS-2673: Attempting to stop 'ora.registry.acfs' on 'vrh2'
CRS-2673: Attempting to stop 'ora.SYSTEMDG.dg' on 'vrh2'
CRS-2673: Attempting to stop 'ora.oc4j' on 'vrh2'
CRS-2673: Attempting to stop 'ora.cvu' on 'vrh2'
CRS-2673: Attempting to stop 'ora.LISTENER_SCAN1.lsnr' on 'vrh2'
CRS-2677: Stop of 'ora.cvu' on 'vrh2' succeeded
CRS-2672: Attempting to start 'ora.cvu' on 'vrh1'
CRS-2677: Stop of 'ora.LISTENER.lsnr' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.vrh2.vip' on 'vrh2'
CRS-2677: Stop of 'ora.vrh2.vip' on 'vrh2' succeeded
CRS-2672: Attempting to start 'ora.vrh2.vip' on 'vrh1'
CRS-2677: Stop of 'ora.LISTENER_SCAN1.lsnr' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.scan1.vip' on 'vrh2'
CRS-2677: Stop of 'ora.scan1.vip' on 'vrh2' succeeded
CRS-2672: Attempting to start 'ora.scan1.vip' on 'vrh1'
CRS-2676: Start of 'ora.cvu' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.registry.acfs' on 'vrh2' succeeded
CRS-2676: Start of 'ora.vrh2.vip' on 'vrh1' succeeded
CRS-2676: Start of 'ora.scan1.vip' on 'vrh1' succeeded
CRS-2672: Attempting to start 'ora.LISTENER_SCAN1.lsnr' on 'vrh1'
CRS-2676: Start of 'ora.LISTENER_SCAN1.lsnr' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.oc4j' on 'vrh2' succeeded
CRS-2672: Attempting to start 'ora.oc4j' on 'vrh1'
CRS-2676: Start of 'ora.oc4j' on 'vrh1' succeeded
CRS-2677: Stop of 'ora.SYSTEMDG.dg' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.asm' on 'vrh2'
CRS-2677: Stop of 'ora.asm' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.ons' on 'vrh2'
CRS-2677: Stop of 'ora.ons' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.net1.network' on 'vrh2'
CRS-2677: Stop of 'ora.net1.network' on 'vrh2' succeeded
CRS-2792: Shutdown of Cluster Ready Services-managed resources on 'vrh2' has completed
CRS-2677: Stop of 'ora.crsd' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.drivers.acfs' on 'vrh2'
CRS-2673: Attempting to stop 'ora.ctssd' on 'vrh2'
CRS-2673: Attempting to stop 'ora.evmd' on 'vrh2'
CRS-2673: Attempting to stop 'ora.asm' on 'vrh2'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'vrh2'
CRS-2677: Stop of 'ora.asm' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.cluster_interconnect.haip' on 'vrh2'
CRS-2677: Stop of 'ora.evmd' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.cluster_interconnect.haip' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'vrh2'
CRS-2677: Stop of 'ora.cssd' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'vrh2'
CRS-2673: Attempting to stop 'ora.gipcd' on 'vrh2'
CRS-2677: Stop of 'ora.gipcd' on 'vrh2' succeeded
CRS-2673: Attempting to stop 'ora.gpnpd' on 'vrh2'
CRS-2677: Stop of 'ora.diskmon' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.drivers.acfs' on 'vrh2' succeeded
CRS-2677: Stop of 'ora.gpnpd' on 'vrh2' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'vrh2' has completed
CRS-4133: Oracle High Availability Services has been stopped.
OLR initialization - successful
Replacing Clusterware entries in inittab
clscfg: EXISTING configuration version 5 detected.
clscfg: version 5 is 11g Release 2.
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
Started to upgrade the Oracle Clusterware. This operation may take a few minutes.
Started to upgrade the CSS.
Started to upgrade the CRS.
The CRS was successfully upgraded.
Oracle Clusterware operating version was successfully set to 11.2.0.3.0

ASM upgrade has finished on last node.

PRKO-2116 : OC4J is already enabled
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

 

4. 确认GI/CRS成功升级到11.2.0.3 :

 

[grid@vrh2 ~]$ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.3.0]

 

 

升级11.2.0.2 RDBMS/DB到 11.2.0.3

 

1. 解压RDBMS/DB 相关的第1-2个 zip包:

 

[root@vrh1 ~]# su - oracle
[oracle@vrh1 tmp]$ mkdir /s01/patch
[oracle@vrh1 tmp]$ cd /s01/patch

[oracle@vrh1 patch]$ unzip /tmp/p10404530_112030_Linux-x86-64_1of7.zip
[oracle@vrh1 patch]$ unzip /tmp/p10404530_112030_Linux-x86-64_2of7.zip

 

2.
因为11.2.0.2的Patchset以后都是out of place的,所以我们可以不用像在11gr2以前那样必须在原有安装低版本软件的基础上才能升级软件,而可以选择在别的位置完全新安装。

注意该步骤不需要停止数据库实例,可以在前期工作中完成。

以DB/RDBMS数据库软件的拥有者身份(oracle用户)启动方才解压目录下的oui安装界面:
su – oracle

(oracle)$ unset ORACLE_HOME ORACLE_BASE ORACLE_SID
(oracle)$ export DISPLAY=:0
(oracle)$ cd $PATCHHOME
(oracle)$ ./runInstaller

 

upgrade_11.2.0.3_DB_1

 

upgrade_11.2.0.3_DB_2

 

upgrade_11.2.0.3_DB_3

 

upgrade_11.2.0.3_DB_4

 

upgrade_11.2.0.3_DB_5

 

upgrade_11.2.0.3_DB_6

 

upgrade_11.2.0.3_DB_7

 

upgrade_11.2.0.3_DB_8

 

依次在所有节点上执行root.sh脚本

/s01/orabase/product/11.2.0/dbhome_3/root.sh

 

3. 使用DBUA静默模式升级RAC数据库的数据字典

 

su - oracle
[oracle@vrh1 ~]$ export ORACLE_HOME=/s01/orabase/product/11.2.0/dbhome_3

/*  这里的SID指定数据库名 */

[oracle@vrh1 ~]$ $ORACLE_HOME/bin/dbua -silent -sid VPROD

Log files for the upgrade operation are located at: /s01/orabase/cfgtoollogs/dbua/VPROD/upgrade2
Performing Pre Upgrade
1% complete
7% complete
Upgrading Oracle Server
9% complete
10% complete
12% complete
13% complete
15% complete
16% complete
18% complete
20% complete
21% complete
23% complete
24% complete
26% complete
27% complete
29% complete
30% complete
32% complete
33% complete
35% complete
36% complete
Upgrading Real Application Clusters
38% complete
Upgrading Oracle Workspace Manager
40% complete
41% complete
43% complete
44% complete
Performing Post Upgrade
46% complete
84% complete
85% complete
86% complete
92% complete
Generating Summary
Database upgrade has been completed successfully, and the database is ready to use.
100% complete
Check the log file "/s01/orabase/cfgtoollogs/dbua/logs/silent1.log" for upgrade details.

4.更新所有节点上.bash_profile 中的ORACLE_HOME等变量

 

5.执行过DBUA升级工具的节点上的orapw$SID密码文件已被更新,将该文件传播到其他节点上

 

6.确认数据字典升级成功,并重启所有实例

SQL> col comp_name for a40
SQL> col version for a20
SQL> set linesize 140 pagesize 1200
SQL> select comp_name,version from dba_server_registry;

COMP_NAME                                VERSION
---------------------------------------- --------------------
Oracle Workspace Manager                 11.2.0.3.0
Oracle Database Catalog Views            11.2.0.3.0
Oracle Database Packages and Types       11.2.0.3.0
Oracle Real Application Clusters         11.2.0.3.0

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------
www.askmaclean.com & www.askmaclean.com

[oracle@vrh1 dbs]$ opatch lsinventory
Invoking OPatch 11.2.0.1.7

Oracle Interim Patch Installer version 11.2.0.1.7
Copyright (c) 2011, Oracle Corporation.  All rights reserved.

Oracle Home       : /s01/orabase/product/11.2.0/dbhome_3
Central Inventory : /g01/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.2.0.1.7
OUI version       : 11.2.0.3.0
Log file location : /s01/orabase/product/11.2.0/dbhome_3/cfgtoollogs/opatch/opatch2011-09-25_00-18-57AM.log

Lsinventory Output file location : /s01/orabase/product/11.2.0/dbhome_3/cfgtoollogs/opatch
/lsinv/lsinventory2011-09-25_00-18-57AM.txt

--------------------------------------------------------------------------------
Installed Top-level Products (1): 

Oracle Database 11g                                                  11.2.0.3.0
There are 1 products installed in this Oracle Home.

There are no Interim patches installed in this Oracle Home.

Rac system comprising of multiple nodes
  Local node = vrh1
  Remote node = vrh2

[oracle@vrh1 dbs]$ sqlplus  / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Sun Sep 25 00:19:14 2011

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

SQL> shutdown immediate;

SQL> startup ;
ORACLE instance started.

Total System Global Area 1252663296 bytes
Fixed Size                  2227944 bytes
Variable Size             402653464 bytes
Database Buffers          838860800 bytes
Redo Buffers                8921088 bytes
Database mounted.
Database opened.

 

11.2.0.3上optimizer_features_enable造成的一些变化

 

我们知道几乎每个Patchset都会引入Oracle Optimizer优化器的一些微妙变化,升级到11.2.0.3后默认的optimizer_features_enable(OFE)为11.2.0.3,我们来了解一下这与11.2.0.2时有哪些区别:

SQL> col PARAMETER for a30
SQL> col "11.2.0.3" for a20
SQL> col  "11.2.0.2" for a20
SQL> col DESCRIB for a50
SQL> set linesize 200 

SQL> select V11203.NAME    Parameter,
  2         V11203.VALUE   "11.2.0.3",
  3         V11202.VALUE   "11.2.0.2",
  4         V11203.describ
  5    from ofe_11203 V11203, ofe_11202 V11202
  6   where V11203.NAME = V11202.NAME
  7     and V11203.VALUE != V11202.VALUE;

PARAMETER                      11.2.0.3             11.2.0.2             DESCRIB
------------------------------ -------------------- -------------------- --------------------------------------------------
_fastpin_enable                241174785            404585473            enable reference count based fast pins
_db_flash_cache_keep_limit     241098320            404509008            Flash cache keep buffer upper limit in percentage
optimizer_features_enable      11.2.0.3             11.2.0.2             optimizer plan compatibility parameter
_optimizer_undo_cost_change    11.2.0.3             11.2.0.2             optimizer undo cost change

Slide:Oracle数据库升级前必要的准备工作

深入了解Oracle数据字典升级脚本catupgrd.sql调用过程

我们在升级数据库的大版本(如9i -> 10g )或大的补丁集( 如10.2.0.1 -> 10.2.0.4)时总是需要升级现有数据库的数据字典(dictionary),这是因为随着Oracle版本的升级,某些对象的属性需要改变,而这些改变操作都将体现在升级脚本catupgrd.sql中。

举例来说在11.2版本中为了ASH特性增加dbreplay的信息,那么我们到11.2的ORACLE_HOME/rdbms/admin下找到c1102000.sql,可以发现以下的DDL语句:

SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------
www.askmaclean.com

alter table WRR$_REPLAY_FILTER_SET add (default_action varchar2(20));

Rem =======================================================================
Rem  End Changes for Database Replay
Rem =======================================================================

该c1102000.sql会被catupgrd.sql调用,换而言之在升级过程中会为WRR$_REPLAY_FILTER_SET基表增加default_action列。

而与之相对应的e1102000.sql 脚本存在以下drop default_action 列的语句:

Rem
Rem Drop this column for existing dbms_workload_replay
Rem
alter table WRR$_REPLAY_FILTER_SET drop column default_action;
commit;

 

该e1102000.sql在数据字典降级过程中会被catdwgrd.sql调用,也就是说当数据字典要降级到11.2之前的版本时会将WRR$_REPLAY_FILTER_SET基表还原到之前版本的表结构,而这一还原操作就包含在e1102000.sql脚本中。

请注意虽然数据字典的升级(catupgrd.sql)和降级(catdwgrd.sql)是2种逆向的操作,但实际他们对数据字典的变更并非是一一对应的。
假设在catupgrd.sql中创建了某些组件对象(component objects),那么在降级时并不会将这些新增加的组件对象全部drop掉,而是简单地truncate这些对象上的数据。

实际上c1102000.sql 脚本会在升级数据字典即catupgrd.sql脚本运行时被调用,而e1102000.sql 则会在降级数据字典版本即catdwgrd.sql脚本运行过程中被调用。

 

一般来说在$ORACLE_HOME/rdbms/admin目录下的脚本文件名表达了该脚本的作用,如:

 

cat*.sql       一般是用来创组件建对象(create objects)的,如catalog.sql脚本创建数据字典对象
cmpup*.sql     一般是用来升级组件component的,如cmpupjav.sql脚本用来升级JAVAVM和XML
ii1102000.sql  包含了数据字典变化必要的DDL操作
c1102000.sql   包含了绝大多数的数据字典变化
a1102000.sql   包含了更新字典数据的PL/SQL块
cmpupgrd.sql   该脚本调用必要的组件升级脚本,如JAVAVM,CONTEXT,Spatial等
f1102000.sql   该脚本使用PL/SQL包将数据字典变化恢复到老的版本
e1102000.sql   该脚本包含了恢复到老版本的其他一些必要字典变更

 

了解了这些升级脚本的作用之后,我们来看一个数据库升级的实例。 以下是由10.1.0.5 升级到 11.2.0.1 时 catupgrd.sql 脚本的调用追踪情况:

 

@catupgrd.sql
    @catupstr.sql
       @i0902000.sql -> @i1001000.sql -> @i1002000.sql -> i1101000.sql
       @c1001000.sql -> @c1002000.sql -> @c1101000.sql
@catalog.sql
@catproc.sql
@catupprc.sql
       @a1001000.sql -> @a1002000.sql -> @a1101000.sql
@cmpupgrd.sql
 @cmpupstr.sql
 @cmpupjav.sql
 @cmpupnjv.sql
 @cmpupxdb.sql
 @cmpupnxb.sql
 @cmpupord.sql
 @cmpupmsc.sql
  @cmpupend.sql
@catupend.sql

注意以上c*.sql的执行过程是c1001000.sql->@c1002000.sql -> @c1101000.sql -> @catalog.sql (其实就是c1102000.sql) -> @catproc.sql,这说明了当10.1.0.5升级到11.2.0.1时,首先还是要执行10.1、10.2、11.1的数据字典变更,而非直接由10.1.0.5 的字典一步到位到 11.2。

以下列出更多升级脚本的作用:

--- 11.2 Upgrade Scripts

i1102000.sql contains the subset of dictionary changes necessary for DDL operations 
c1102000.sql contains most of the dictionary changes, runs catalog and catproc 
a1102000.sql contains PL/SQL blocks to update data within the dictionary 
cmpupgrd.sql invokes the component upgrade scripts (JAVAVM, CONTEXT, Spatial, etc.) 

---  catupgrd.sql

@catupstr.sql – initial checks – runs “c” scripts
@catalog.sql – creates data dictionary objects
@catproc.sql – creates packages & types
@catupprc.sql – final RDBMS  “a” scripts 
@cmpupgrd.sql – invokes upgrade component scripts
@catupend.sql – final scripts to complete the upgrade

---  Downgrade Scripts – catdwgrd.sql
cmpdbdwg.sql invokes the component downgrade scripts (JAVAVM, CONTEXT, etc.) OR
cmpdwpth.sql invokes the component patch downgrade scripts (most components do not have patch downgrade scripts) 
f1102000.sql contains the dictionary changes that use PL/SQL packages to revert to the previous server 
e1102000.sql contains other dictionary changes necessary to revert to the previous server 

cmpupjav.sql – upgrades JAVAVM and XML
Cmpupnjv.sql – upgrades components not dependent on javavm or xml 
Cmpupxdb.sql – upgrades context and xdb
Cmpupnxb.sql – upgrades components not dependent on context or xdb, but dependent on javavm or xml
Cmpupord.sql – upgrades ordim and spatial (dependent on javavm, xml, and xdb)
Cmpupmsc.sql – upgrades other components dependent on context or xdb (odm, wk, exf, rul)

Oracle 9i/10g/11g数据库升级路线图总览

熟悉Oracle升级服务的朋友可能在文档中反复看到以下几张升级路线图,现在把它们汇总在一起以便于寻找。

 

Upgrade to Oracle Database 9.2
Upgrade to Oracle Database 10g Release 2
Upgrade to Oracle Database 11g

upgrade alternatives

 

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569