第一.最严重的失误:

    db冷备时,只冷备出了oracle_base,和oradata目录(此目录中包含了控制文件,日志文件,还有oracle本身的数据文件),没有备份出应用的数据文件.这样导致,之后升级失败时(升级的过程,也就是执行sql的过程,执行sql时,controlfile中会记录最新的改变,同时,将此最新的改变应用到应用的数据文件中.这样一来,即使能还原了oracle_base,和oradata目录,但是由于无法还原应用的数据文件,在这种情况下,startup,会报:

SQL> startup
ORACLE 例程已经启动。

Total System Global Area 2550136832 bytes
Fixed Size                  2006416 bytes
Variable Size             553648752 bytes
Database Buffers         1979711488 bytes
Redo Buffers               14770176 bytes
数据库装载完毕。
ORA-01122: 数据库文件 5 验证失败
ORA-01110: 数据文件 5: 'D:\CWDATA\GS_ORADB_001.DBF'
ORA-01207: 文件比控制文件更新 - 旧的控制文件

),

这也就是说,还原不到原来的起点.

第二.没有先将"Metalink Note:62290.1 Changing between 32-bit and 64-bit Word Sizes" 通读三遍,没有做到结合本次升级现场的环境制定出适合本次升级的步骤.

 造成的后果:

因为一般metalink的文章,是在某一步陈述完毕之后,才有Note: ,(正如第17步,第17步见下),我却是先执行完了sql,最后才从Note: 中发现,原来这个sql是不需要执行的.这个情况为"江湖人士所不齿"!!!

17. Locate the version you are migrating from below, and execute the appropriate
    script.:

    - If you are migrating an Oracle 8.0, Oracle8i or Oracle 9i 9.0.x database,
    run the following script.:

    SQL> @$ORACLE_HOME/rdbms/admin/catalog.sql

    - If you are migrating an Oracle9i 9.2.0.x database, run the following
    script.:

    SQL> @$ORACLE_HOME/rdbms/admin/catpatch.sql

    - If you are migrating an Oracle10g 10.1.0.x or 10.2.0.x database, run the
    following script.:
 
    SQL> @$ORACLE_HOME/rdbms/admin/catupgrd.sql

=============================================================================

    Note:

    If the patchset level is not being changed (for example, you are
    migrating a 9.2.0.8 32-bit database to 9.2.0.8 64-bit) then there is no
    need to run the $ORACLE_HOME/rdbms/admin/catpatch.sql script. or the
    $ORACLE_HOME/rdbms/admin/catupgrd.sql script. because the data dictionary
    is already at the correct level.

=============================================================================

第三,没用按照第10步中的做,没有 doubling the size of parameters

10.

 When changing wordsize from a 32-bit Oracle version to a 64-bit Oracle
    version, Oracle recommends doubling the size of parameters such as:

    SHARED_POOL_SIZE
    SHARED_POOL_RESERVED_SIZE
    LARGE_POOL_SIZE

    This is mainly due to an increase in the size of internal data structures.
    For an in-depth explanation of this, please see Note 209766.1
    'Memory Requirements of Databases Migrated from 32-bit to 64-bit'

没有 doubling the size of parameters 的后果,是在in normal mode 执行@D:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlrp.sql时,有报错,

SQL> DECLARE
  2   threads pls_integer := &&1;
  3  BEGIN
  4   utl_recomp.recomp_parallel(threads);
  5  END;
  6  /
DECLARE

*
第 1 行出现错误:
ORA-03113: 通信通道的文件结束

SQL>
SQL> SELECT dbms_registry_sys.time_stamp('utlrp_end') as timestamp from dual;
ERROR:
ORA-03114: 未连接到 ORALCE