首页 > 代码库 > 手动升级到 11gR2 的完整核对清单

手动升级到 11gR2 的完整核对清单

2024-07-23 05:12:00   220人阅读

适用于:

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


本文出自 “Permanent” 博客，请务必保留此出处http://ericklee.blog.51cto.com/6941516/1554633

手动升级到 11gR2 的完整核对清单


联系
我们