【MOS】在不同版本和平台之间进行还原或复制 (文档 ID 1526162.1)--跨版本恢复

原创

小麦苗123 2021-04-10 09:45:34 ©著作权

文章标签 MOS 文章分类 数据库

©著作权归作者所有：来自51CTO博客作者小麦苗123的原创作品，请联系作者获取转载授权，否则将追究法律责任

【MOS】关于在不同版本和平台之间进行还原或复制的常见问题 (文档 ID 1526162.1)--跨版本恢复

Questions and Answers

1) 我能用更高版本的 Oracle 还原或复制旧版本的数据库吗？

2) 我能在两个不同的补丁程序集之间进行还原或复制吗？

3) 我能在同一操作系统的不同版本之间进行还原或复制吗？

4) Oracle 的位（bit）级别（32 位或 64 位）不匹配时，可以进行还原或复制吗？

5) 可以将更高版本的备份还原到较早版本的 Oracle 吗？

6) 我能在两个不同的平台之间还原或复制我的 RMAN 备份吗，例如 Solaris 到 Linux？

适用于: Oracle Database - Enterprise Edition - 版本 9.0.1.0 和更高版本 Oracle Database - Standard Edition - 版本 9.0.1.0 和更高版本本文档所含信息适用于所有平台用途本文档回答了有关如何使用 RMAN 从旧版本以及具有不同字长的系统中还原备份的常见问题。下面列出了一些常与 Oracle 软件升级相关的情形。如果您需要有关当前主题的更多信息，请通过以下链接直接访问“ 备份和恢复社区”与Oracle 客户和专家进行讨论： https://community.oracle.com/community/support/oracle_database/database_backup_and_recovery 问题和答案注意：以下部分中的还原是指用户管理的（非 RMAN）还原或 RMAN 还原。复制（Duplicate）是只有 RMAN 才具有的一种功能，但在提到复制时，它也适用于用户管理的数据库克隆。 1) 我能用更高版本的 Oracle 还原或复制旧版本的数据库吗？RMAN 可将在较旧的数据库版本上进行的备份还原到较新的版本中。旧的备份必须是在 9.2 或更高版本的数据库中进行的。此方法可用作异地（out-of-place）数据库升级的一部分，其中，旧的备份被还原到新版本数据库中，然后升级脚本照常运行。由于旧的数据库在升级过程中可以保持连线状态，因此这种方法相对于就地（in-place）升级更为可取，在就地升级中数据库必须保持离线状态。例如，我希望使用在 10.2 数据库上进行的备份将数据库升级到 11.2。11.2 数据库将驻留在新的主机上。步骤如下： 1. 在新主机上安装 11.2 数据库软件和最新的补丁程序集，并按照本文档中的说明准备 11.2 Oracle 主目录。 2. 允许从新主机访问磁盘和/或磁带备份 3. 将备份还原到 11.2 数据库，并按照本文档中的说明将数据库恢复到一致的时间点。Database Backup and Recovery User's Guide 20 Performing RMAN Recovery: Advanced Scenarios ... Restoring a Database on a New Host'此时不要打开数据库。 4. 将 10.2 数据库手动升级至 11.2，参考文档Database Upgrade Guide 2 Preparing to Upgrade Oracle Database ... Manual Upgrade请确保您完成了相关升级文档（如下所列）中列出的各种数据库组件的升级前/升级后过程： Note 837570.1 Complete Checklist for Manual Upgrades to 11gR2 Note 1503653.1 Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1)注意：上面的过程适用于还原从未升级至 11.2 的 10.2 数据库。如果数据库已经升级，而您需要通过升级之前的备份（版本10.2）还原数据库，则您只需要进行还原和恢复，介质回复将重现由升级完成的一切内容。不支持 RMAN“复制”，因为该功能会在恢复之后尝试自动打开数据库时失败（第 3 步）。从12c开始DUPLICATE TARGET DATABASE增加新选项NOOPEN，这个选项更适合数据库恢复。 . NOOPEN 指定duplicate数据库是不打开数据库。默认RMAN创建duplicate数据库后以RESETLOGS方式打开。.参考: http://docs.oracle.com/database/121/RCMRF/rcmsynta020.htm#i1011578 Oracle? Database Backup and Recovery Reference 12c Release 1 (12.1) E50791-03 . DUPLICATE . dupOptionList 2) 我能在两个不同的补丁程序集之间进行还原或复制吗？正如您可以在不同的 Oracle 版本之间进行还原一样，您也可以在两个不同的补丁程序集之间执行这一操作。有关详细信息，请参阅问题 1。请注意，您必须按照相应 Readme 文件中的说明进行操作。如果需要重置日志(resetlogs)，请在执行升级或降级至某个补丁程序集所需的脚本之前，根据需要执行以下命令： SQL> alter database open resetlogs upgrade; 或 SQL> alter database open resetlogs downgrade;由于 RMAN“复制”会尝试自动打开数据库，因此，在这种情况下您就不应使用 RMAN 复制，而只使用 RMAN 还原。从12c开始DUPLICATE TARGET DATABASE增加新选项NOOPEN，这个选项更适合数据库恢复。 . NOOPEN 指定duplicate数据库是不打开数据库。默认RMAN创建duplicate数据库后以RESETLOGS方式打开。.参考: http://docs.oracle.com/database/121/RCMRF/rcmsynta020.htm#i1011578 Oracle? Database Backup and Recovery Reference 12c Release 1 (12.1) E50791-03 . DUPLICATE . dupOptionList 3) 我能在同一操作系统的不同版本之间进行还原或复制吗？例如，我能将在运行 Solaris 9 的主机上进行的 9.2.0.1.0 RMAN 备份还原到已安装 9.2.0.1.0 但其主机却运行 Solaris 10 的其他机器吗？如果可以使用相同的 Oracle Server 安装 CD（介质包）在 Solaris 9 和 Solaris 10 上安装 9.2.0.1.0，则将支持这类还原。 4) Oracle 的位（bit）级别（32 位或 64 位）不匹配时，可以进行还原或复制吗？例如，可以将我的 9.2 版64 位数据库还原或复制到 9.2.32 位安装吗？执行还原/恢复时，最好保持相同的位版本。但是，除使用复制命令外，使用相同的操作系统平台应该允许在 Oracle 位级别（32 位或 64 位）之间进行还原/恢复。请注意，这可能只适用于特定的操作系统，若有与此相关的任何问题，应向 Oracle Support 报告。如果您要使用 32 位软件运行 64 位数据库（或反之），则在恢复结束之后必须要使用 utlirp.sql 转换数据库位版本。有关在位之间进行切换的详细信息，请参阅以下文档：Note 62290.1 Changing between 32-bit and 64-bit Word Sizes 如果不运行 utlirp.sql，将会出现以下错误（不限于）： ORA-06553: PLS-801: INTERNAL ERROR [56319] 5) 可以将更高版本的备份还原到较早版本的 Oracle 吗？例如，您准备从 10.2 升级至 11.2。在成功升级并在 11.2 上运行几天之后，您对 11.2 数据库进行了新的备份。您想知道，如果 11.2 中出现问题，是否能够将 11.2 备份还原到其他主机上,该主机安装了 10.2 数据库软件，（或在同一主机上重新安装 10.2，然后还原 11.2 备份）。如果在升级后从未增加 COMPATIBLE 参数，则可以进行此类还原。在本示例中，如果 11.2 数据库始终是在 COMPATIBLE 为 10.2 的情况下运行，则可以将 11.2 数据库的备份还原到 10.2 实例中，然后执行降级过程。如果数据库已经在 COMPATIBLE 为 11.2 的情况下打开，则不能进行此类还原。另一种维护 HA 和旧版本数据库（如果需要回滚）的好方法是，使用 Data Guard 滚动（rolling）升级法，该方法涉及临时逻辑备用数据库（只是在升级期间临时把主数据库变成逻辑备用数据库）。将备用数据库升级至新版本后（主数据库仍然在旧版本上运行），您可以进行切换并验证升级后的数据库是否运作正常。如果运作不正常，您可以切换回到旧的版本。 6) 我能在两个不同的平台之间还原或复制我的 RMAN 备份吗，例如 Solaris 到 Linux？通常，您不能在两个不同的平台之间进行还原或复制。注意：请参阅 Note 1079563.1 ，其中列出了 Oracle 支持的跨平台复制/还原/恢复的平台和 Oracle 版本。在 10g 之前的版本中，从一个平台迁移至另一个平台的唯一方法是使用导出/导入。在 10g 中，通过 RMAN 转换（convert）命令，您可以使用 10g 跨平台可传输表空间（Cross-Platform Transportable Tablespaces）选项跨越各个平台。有关更多详细信息，请参阅以下文档：Note 243304.1 Transportable Tablespaces Across Different Platforms以及：http://www.oracle.com/technetwork/database/features/availability/thehartfordprofile-xtts-133180.pdf 在 10.2 及更高版本中，如果源 OS 和目标 OS 具有相同的字节序（endian），您可以发出“CONVERT DATABASE”命令，以便转换数据文件并使其准备好传输到目标机器。有关“CONVERT DATABASE”的更多详细信息，请参阅： Oracle Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Chapter 15, RMAN Cross-Platform Transportable Databases and Tablespaces 注意：请参阅 Note 732053.1 ，了解在版本10.2 和 11.1 中，如何在可传输数据库（transportable database）期间跳过不包含UNDO信息的数据文件。该过程可大大减少总体完成时间。此外，请注意，为了实现这一目的，11.2 还针对 CONVERT DATABASE 提供了 SKIP UNNECESSARY DATAFILES 选项。如果是从 32 位到 64 位，还必须按照 Note 62290.1 中的说明改变字长。此外，在平台之间进行迁移时，可使用第三方应用程序，例如 VERITAS Storage Foundation 便捷式数据容器： http://eval.veritas.com/mktginfo/products/White_Papers/Storage_Server_Management/Portable_Data_Containers_for_Oracle.pdf （有关 VERITAS Storage Foundation 便捷式数据容器的信息，请联系 Veritas）社区讨论您可以在下面的社区参与对本文的讨论。下面的页面是实时讨论页面- 不是截屏;-)参考NOTE:560417.1 - Recovery Through Upgrade returns ORA-1092 on OpenNOTE:558408.1 - RMAN DUPLICATE / RESTORE a database to a higher patchsetNOTE:1079563.1 - RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform SupportNOTE:73431.1 - RMAN Compatibility MatrixNOTE:62290.1 - Changing between 32-bit and 64-bit Word SizesNOTE:732053.1 - Avoid Datafile Conversion during Transportable DatabaseNOTE:1503653.1 - Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1)

Frequently Asked Questions about Restoring Or Duplicating Between Different Versions And Platforms (文档 ID 369644.1)

In this Document

Purpose

Questions and Answers

1) Can I restore or duplicate my previous version database using a later version of Oracle?

2) Can I restore or duplicate between two different patchset levels?

3) Can I restore or duplicate between two different versions of the same operating system?

4) Is it possible to restore or duplicate when the bit level (32 bit or 64 bit) of Oracle does not match?

5) Is it possible to restore a later version backup to an earlier version of Oracle?

6) Can I restore or duplicate my RMAN backup between two different platforms such as Solaris to Linux?

References

APPLIES TO:

Oracle Database - Standard Edition - Version 9.2.0.1 and later
Oracle Database - Enterprise Edition - Version 9.2.0.1 and later
Information in this document applies to any platform.

PURPOSE

This note answers common questions relating to how RMAN can be used to restore backups from older releases and from systems with a different word size. These are scenarios that are often related to Oracle software upgrades.

In case you may want or need more about your current topic - please also access the Backup & Recover Community of Customers and Oracle Specialists directly via:
https://community.oracle.com/community/support/oracle_database/database_backup_and_recovery

QUESTIONS AND ANSWERS

Note: Restore in the following sections refers to either a user managed (non-RMAN) or a RMAN restore. Duplicate is a function of RMAN only but where duplicate is mentioned it also applies to user managed database cloning.

1) Can I restore or duplicate my previous version database using a later version of Oracle?

RMAN can restore a backup taken on an older database release into a newer release. The older backups must be taken on 9.2 or later release.

This method can be used as part of an out-of-place database upgrade, in which the older backups are restored to the newer release database and then the upgrade scripts are run as normal. Since the older database can remain online during the upgrade, this may be preferable to an in-place upgrade, where the database must remain offline.

For example, I want to upgrade a 10.2 database to 11.2, using backups taken on the 10.2 database. The 11.2 database will reside on a new host.

The steps are:

1. Install 11.2 binaries and latest patch sets on new host and prepare the 11.2 Oracle home per following Documentation - Database Upgrade Guide

2. Allow disk and/or tape backups to be accessible from the new host.

3. Restore backups to the 11.2 database and recover the database to a consistent point-in-time per this doc.

    Database Backup and Recovery User's Guide
       20 Performing RMAN Recovery: Advanced Scenarios
          ... Restoring a Database on a New Host'

Do not open the database at this time.

4. Manually upgrade the 10.2 database to 11.2 per the instructions in this documentation

  Database Upgrade Guide
   2 Preparing to Upgrade Oracle Database
   ... Manual Upgrade

starting from the point immediately after the 11.2 software has been installed.

Please ensure that you complete pre-upgrade / post-upgrade procedures for various database components as listed under the upgrade docs for example:
Note 837570.1 Complete Checklist for Manual Upgrades to 11gR2
Note 1503653.1 Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1)

Note: the above procedure is for restoring a 10.2 database that had never been upgraded to 11.2. If the database has already been upgraded, and you need to restore a backup that was created while the database was running as 10.2, you just need to restore and recover it, and media recovery will replay everything done by the upgrade.

RMAN "duplicate" is not supported as it will fail attempting to automatically open the database after recovery (step #3).

Starting from RDBMS 12c there is a new option available with the DUPLICATE TARGET DATABASE -> the NOOPEN-clause,
which is than suitable for restoring and recovering the database.
.
NOOPEN
Specifies that the duplicate database must not be opened after it is created.
By default, RMAN creates a duplicate database and then opens it in RESETLOGS mode.
.

Reference:
http://docs.oracle.com/database/121/RCMRF/rcmsynta020.htm#i1011578
Oracle? Database Backup and Recovery Reference
12c Release 1 (12.1)
E50791-03
.
DUPLICATE
.
dupOptionList

2) Can I restore or duplicate between two different patchset levels?

As you can restore between different Oracle version, you can also do so between two different patchset levels. See question #1 for details.

Note, you must follow the instructions in the appropriate readme file. If resetlogs is required, you can execute:

SQL> alter database open resetlogs upgrade;
OR
SQL> alter database open resetlogs downgrade;

As needed before executing the required scripts to either upgrade or downgrade to a patch level.

Because RMAN "duplicate" attempts to automatically open the database you may not use RMAN duplicate for this case, only RMAN restore.

3) Can I restore or duplicate between two different versions of the same operating system?

For example, can I restore my 9.2.0.1.0 RMAN backup taken against a host running Solaris 9 to a different machine where 9.2.0.1.0 is installed but where that host is running Solaris 10?

If the same Oracle Server installation CDs (media pack) can be used to install 9.2.0.1.0 on Solaris 9 and Solaris 10, this type of restore is supportable.

4) Is it possible to restore or duplicate when the bit level (32 bit or 64 bit) of Oracle does not match?

For example, is it possible to restore or duplicate my 9.2. 64-bit database to a 9.2.32-bit installation?

It is preferable to keep the same bit version when performing a restore/recovery. However, excluding the use of duplicate command, the use of the same operating system platform should allow for a restore/recovery between bit levels (32 bit or 64 bit) of Oracle. Note, this may be specific to the particular operating system and any problems with this should be reported to Oracle Support.

If you will be running the 64-bit database against the 32-bit binary files or vice versa, after the recovery has ended the database bit version must be converted using utlirp.sql.

See this note for details on switching between bit sizes:

Note 62290.1 Changing between 32-bit and 64-bit Word Sizes

If you do not run utlirp.sql you will see errors including but not limited to:

ORA-06553: PLS-801: INTERNAL ERROR [56319]

5) Is it possible to restore a later version backup to an earlier version of Oracle?

Say for example you are preparing to upgrade to 11.2 from 10.2. After a successful upgrade and running on 11.2 for a few days you take a new backup of the 11.2 database. You want to know if run into a problem with 11.2 if you could restore the 11.2 backup to 10.2 on another host (or reinstall 10.2 on the same host then restore the 11.2 backup).

Such a restore is possible if the COMPATIBLE parameter had never been increased after the upgrade. In this example, if the 11.2 database had always been run with COMPATIBLE=10.2 then it is possible to restore a backup of the 11.2 database into a 10.2 instance, then perform the downgrade procedures.

If the 11.2 database has ever been opened with COMPATIBLE = 11.2, then this is not possible. Another good way for maintaining HA and the old version database (if you need to fall back) is to use the Data Guard rolling upgrade method which involves a transient logical standby database (a primary that temporarily becomes a logical standby just during the upgrade period). After upgrading the standby to new version (and primary still running on old version), you can switchover and verify that upgraded database is working well. If it is not, you can switchback to primary old version.

6) Can I restore or duplicate my RMAN backup between two different platforms such as Solaris to Linux?

In general, you cannot restore or duplicate between two different platforms.

Note: Refer to Note 1079563.1 which lists supported mixed platforms and Oracle versions for duplicate/restore/recover.

In versions previous to 10g the only option to migrate from one platform to another was using export / import. With 10g, using the RMAN convert commands, you can cross between platforms using the 10g Cross-Platform Transportable Tablespaces option. For more details review this note:

Note 243304.1 Transportable Tablespaces Across Different Platforms

In version 10.2 and later if the source and target OS are the same endian you may issue a "CONVERT DATABASE" so that datafiles are converted and ready for transport to the destination machine. For more details about "CONVERT DATABASE" see:

Oracle Database Backup and Recovery Advanced User's Guide
10g Release 2 (10.2)
Chapter 15, RMAN Cross-Platform Transportable Databases and Tablespaces

Note: Refer to Note 732053.1 for 10.2 and 11.1 procedure to skip non-UNDO containing datafiles during transportable database. This can significantly reduce the overall completion time. Also, note that 11.2 offers SKIP UNNECESSARY DATAFILES option for CONVERT DATABASE, to accomplish this.

If going from 32bit to 64bit, you must also change the wordsize per note 62290.1.

There are also 3rd party applications for migration between platforms such as VERITAS Storage Foundation portable data containers:

http://eval.veritas.com/mktginfo/products/White_Papers/Storage_Server_Management/Portable_Data_Containers_for_Oracle.pdf

(Contact Veritas for information about VERITAS Storage Foundation portable data containers)

Community Discussion

You can directly participate in the Discussion about this article below. The Frame is the interactive live Discussion - not a Screenshot ;-)

REFERENCES

NOTE:73431.1 - RMAN Compatibility Matrix
NOTE:62290.1 - Changing between 32-bit and 64-bit Word Sizes
NOTE:1079563.1 - RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support

NOTE:732053.1 - Avoid Datafile Conversion during Transportable Database
NOTE:560417.1 - Recovery Through Upgrade returns ORA-1092 on Open
NOTE:558408.1 - RMAN DUPLICATE / RESTORE a database to a higher patchset
NOTE:1503653.1 - Complete Checklist for Manual Upgrades to Oracle Database 12c Release 1 (12.1)

Changing between 32-bit and 64-bit Word Sizes (文档 ID 62290.1)

SCOPE & APPLICATION
-------------------

This document is created to provide all the details for changing word size from
32bit to 64bit. This document is a "cut/paste" of applicable sections from the 
Oracle9i Database Migration guide (A96530-02), to quickly provide the needed 
details and steps to change the word-size. 

This note is applicable to Oracle 8.0.x, Oracle8i, Oracle9i and Oracle10g.

LIMITATIONS OF USE
------------------
This note is not applicable for:

- databases having JVM installed in an Oracle8i environment, or 
- Oracle Applications installed in an Oracle8i environment
- databases using native compilation.  This assumes that PL/SQL is set to interpreted.
 
To migrate these types of database, please check Note:183649.1 CHANGING WORD-SIZE
------------------
You can change the word-size of your Oracle database server during a migration,
upgrade, or downgrade operation. A change in word-size includes the following 
scenarios: 

You have 32-bit Oracle software installed on 64-bit hardware and want to 
change to 64-bit Oracle software. 

You have 64-bit Oracle software installed on 64-bit hardware and want to 
change to 32-bit Oracle software. 

If you are changing word-size during a migration, upgrade, or downgrade 
operation then no additional action is required. The word-size is changed 
automatically during any of these operations. However, if you want to change 
the word-size within the same major release, then follow the instructions in
"Changing the Word-Size of Your Current Release" below. For example, if you 
have the 32-bit version of Oracle release 9.0.1 and you want to switch to the
64-bit version of Oracle release 9.0.1, then you must complete this procedure. 
The following information applies if you are changing your 
hardware from 32-bit to 64-bit or from 64-bit to 32-bit: 

If you want to change your hardware wordsize, then you should be able to switch 
from 32-bit hardware to 64-bit hardware and still use your existing
32-bit Oracle software without encountering any problems, except on Linux
systems (32-bit Oracle on 64-bit Linux is not supported).  Always check to be
sure the combination is certified to run Oracle before proceeding with any 
changes.

If you want to change your hardware from 64-bit to 32-bit, then you 
must first change your Oracle software to 32-bit software before
changing your hardware wordsize. 

The on-disk format for database data, redo, and undo is identical for the 
32-bit and 64-bit installations of Oracle. The only internal structural 
differences between the 32-bit and 64-bit Oracle installations are the 
following: 

The compiled format of PL/SQL is different. The instructions for how and 
when to recompile PL/SQL are provided in the appropriate chapters of
the Migration book. The storage format of user-defined types is based on the 
release of Oracle that created the database. The existing storage format will 
be converted to the correct format transparently when necessary. User-defined 
types include object types, REFs, varrays, and nested tables.

Note: For Oracle 9.2 

In the first release of the migration guide it is said that changing the 
wordsize during upgrade or migration is not supported.  This is incorrect
a documentation bug has been logged for this.  Bug 2590998 explains the
error in the documentation.  This has been fixed in the second release of 
Oracle 9I release 2 (9.2) Migration guide where it is correctly written
that changing wordsize during the migration or the upgrade is supported.

It is recomended to apply the latest patchset BEFORE the wordsize conversion.
This would avoid some bugs and also some steps in this note during the wordsize
conversion, like Bug:1867501 and Bug:1926809.

CONSIDERATIONS BEFORE PROCEEDING WITH THE ACTIONS BELOW
-------------------------------------------------------
1) It is necessary to reload OLAP when converting word size due to its dependency 
on plsql as documented in Note 386990.1. 

2) Normally an upgrade to a newer release will automatically take care of
a word size change from 32-bit to 64-bit. However, upgrading 10gR1 to 10gR2 is 
an exception.

Please refer to
Oracle Database Upgrade Guide
10g Release 2 (10.2)
Part Number B14238-01
http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/intro.htm#i1008703

Converting Databases to 64-bit Oracle Database Software

If you are installing 64-bit Oracle Database 10g software but were previously 
using a 32-bit Oracle Database installation, then the databases will automatically 
be converted to 64-bit during the upgrade to Oracle Database 10g except when 
upgrading from Release 1 (10.1) to Release 2 (10.2).

Note:
The process is not automatic for the release 1 to release 2 upgrade, but is 
automatic for all other upgrades. This is because the utlip.sql script is not 
run during the release 1 to release 2 upgrade to invalidate all PL/SQL objects. 
You must run the utlip.sql script with the database in UPGRADE / MIGRATE mode 
as the last step in the release 10.1 environment, before upgrading to 
release 10.2.

3) Bug 5079213: ORA-6544 [56319] DURING UPGRADE FROM 10.1.0.5 32BIT TO 10.2.0.2 64BIT
 -- For patch upgrades that are changing word size, utlip.sql must be run 
    manually as it is not automatically run as part of the upgrade.

CHANGING THE WORD-SIZE OF YOUR CURRENT RELEASE
----------------------------------------------

The instructions in this section guide you through changing the word-size of 
your current release (switching from 32-bit software to 64-bit software or
vice versa). 

Complete the following steps to change the word-size of your current release: 

1. Start SQL*Plus. 

2. Connect to the database instance AS SYSDBA. 

3. Run SHUTDOWN IMMEDIATE on the database: 

   SQL> SHUTDOWN IMMEDIATE

   Issue the command for all instances if you are running Oracle Parallel
   Server.

=============================================================================
   Note: 

   NCHAR columns in user tables are not changed during the upgrade. 
   To change NCHAR columns in user tables, see "Upgrade User NCHAR 
   Columns" in the Migration guide.  

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

4. Perform a full backup of the database (optional, but highly recommended)

   See Also: 

   Oracle9i User-Managed Backup and Recovery Guide for more information.  

5. If you are using the same Oracle home for your current release and the 
   release to which you are switching, then deinstall your current release
   using the Oracle Installer. You do not need to deinstall your current 
   release if you are using separate Oracle home directories. 

6. If you currently have a 32-bit installation, then install the 64-bit 
   version of the same release. Or, if you currently have a 64-bit 
   installation, then install the 32-bit version of the same release. 

=============================================================================
   Note: 

   Installation and deinstallation are operating system-specific. For
   installation and deinstallation instructions, see your
   Oracle9i operating system-specific installation documentation and 
   the Oracle9i README for your operating system. 

   Installation documentation can also be found at technet.oracle.com
 
=============================================================================

7. Copy configuration files to a location outside of the old Oracle home: 

   a. If your initialization parameter file resides within the old 
      environment's Oracle home, then copy it to a location outside of the 
      old environment's Oracle home. The initialization parameter file can 
      reside anywhere you wish, but it should not reside in the old
      environment's Oracle home after you switch to the new release. 

   b. If your initialization parameter file has an IFILE (include file) 
      entry and the file specified in the IFILE entry resides within the 
      old environment's Oracle home, then copy the file specified by the 
      IFILE entry to a location outside of the old environment's Oracle 
      home.  The file specified in the IFILE entry has additional 
      initialization parameters. After you copy this file, edit the IFILE 
      entry in the initialization parameter file to point to its new 
      location. 

   c. If you have a password file that resides within the old Oracle home, 
      then move or copy the password file to the Oracle9i Oracle home.
      The name and location of the password file are operating 
      system-specific; for example, on UNIX operating systems, the default
      password file is ORACLE_HOME/dbs/orapwsid, but on Windows platforms, 
      the default password file is ORACLE_HOME\database\pwdsid.ora. 
      In both cases, sid is your Oracle instance ID. 

=============================================================================
      Note: 

      For Oracle9i Real Application Clusters, perform this step on 
      all nodes. Also, if your initdb_name.ora file resides within 
      the old environment's Oracle home, then move or copy the 
      initdb_name.ora file to a location outside of the old 
      environment's Oracle home.  

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

8. Change your environment to point at the new 64Bit ORACLE_HOME.

     Note: Check with platform specific documentation if other env variables 
           need to be changed e.g. LD_LIBRARY_PATH 

9. If you are changing the wordsize of an Oracle 8.0, Oracle8i or Oracle9i 9.0.x database
   then please make the following changes in the 64-bit ORACLE_HOME/dbs 
   init$ORACLE_SID.ora file to prepare for the wordsize change:

    aq_tm_processes=0    
    job_queue_processes=0
    _system_trig_enabled= false

    Changing the first two parameters will avoid the problems detailed in 
    Bug 1421476 and Bug 1816609

    The last parameter should be set to FALSE for scripts which perform 
    dictionary operations as the objects on which the triggers depend may 
    become invalid or be dropped, causing the triggers to fail and thus 
    preventing the scripts from running successfully. 

    See note 149948.1 'IMPORTANT: Set "_SYSTEM_TRIG_ENABLED=FALSE" When 
    Upgrading / Downgrading / Applying Patch Sets' for more info.

   If you are changing the wordsize of an Oracle9i 9.2.0.x or Oracle10g
   database, go to step 10.

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'

11. At a system prompt, change to the ORACLE_HOME/rdbms/admin directory. 

12. Start SQL*Plus. 

13. Connect to the database instance AS SYSDBA. 

14. If you are changing the wordsize of an Oracle 8.0, Oracle8i or Oracle9i 9.0.x database,
    run STARTUP RESTRICT: 

    SQL> STARTUP RESTRICT

    You may need to use the PFILE option to specify the location of your 
    initialization parameter file. 

    If you are changing the wordsize of an Oracle9i 9.2.0.x database, run STARTUP MIGRATE:

    SQL> STARTUP MIGRATE

    If you are changing the wordsize of an Oracle10g database, run STARTUP UPGRADE:

    SQL> STARTUP UPGRADE

15. Set the system to spool results to a log file for later verification of 
    success: 

    SQL> SPOOL catoutw.log

    If you want to see the output of the script you will run on your screen, 
    then you can also issue a SET ECHO ON statement: 

    SQL> SET ECHO ON


16. Run utlirp.sql: 

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

    The utlirp.sql script recompiles existing PL/SQL modules in the format 
    required by the new database. If the version does not include a call to 
    utlrp, then you must manually run utlrp.sql to recompile invalid objects.
    This script first alters certain dictionary tables. Then, it reloads 
    package STANDARD and DBMS_STANDARD, which are necessary for using PL/SQL. 
    Finally, it triggers a recompile of all PL/SQL modules, such as packages, 
    procedures, types, and so on. 

   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   Additional Actions for Java:

When migrating a database from 32 to 64bit (or vice versa) additional actions
are required for java.  In theory the format of java shared data objects (SRO)
is not compatible between 32 and 64 bit and so these objects need to be dropped
and regenerated.  In practice it may be the case prior to release 11 such
objects could interoperate but if so this would only be by chance and should
not be relied upon.

The steps to do the regeneration are as follows.  These should be done
immediately before running utlirp.  They may take several minutes to complete.
They must be done connected as SYS.

begin
  update obj$ set status=5 where obj#=(select obj# from obj$,javasnm$ 
    where owner#=0 and type#=29 and short(+)=name and 
    nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
  commit;
  declare
    cursor C1 is select
       'DROP JAVA DATA "' || u.name || '"."' || o.name || '"'
       from obj$ o,user$ u where o.type#=56 and u.user#=o.owner#;
  
    ddl_statement varchar2(200);
    iterations number;
    previous_iterations number;
    loop_count number;
    my_err     number;
  begin
    previous_iterations := 10000000;
    loop
      -- To make sure we eventually stop, pick a max number of iterations
      select count(*) into iterations from obj$ where type#=56;
      exit when iterations=0 or iterations >= previous_iterations;
      previous_iterations := iterations;
      loop_count := 0;
      open C1;
      loop
        begin
          fetch C1 into ddl_statement;
          exit when C1%NOTFOUND or loop_count > iterations;
        exception when others then
           my_err := sqlcode;
           if my_err = -1555 then -- snapshot too old, re-execute fetch query
             exit;
           else
             raise;
           end if;
        end;
        initjvmaux.exec(ddl_statement);
        loop_count := loop_count + 1;
      end loop;
      close C1;
    end loop;
  end;
  commit;
  initjvmaux.drp('delete from java$policy$shared$table');
  update obj$ set status=1 where obj#=(select obj# from obj$,javasnm$ 
    where owner#=0 and type#=29 and short(+)=name and 
    nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');
  commit;
end;
/

create or replace java system
/


   ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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.

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

18. Check the validity of the DBMS_STANDARD package:

    SQL> select status from dba_objects
    where object_name='DBMS_STANDARD'
    and object_type='PACKAGE'
    and owner='SYS';

19. If the package is invalid, recompile it:

    SQL> alter package dbms_standard compile;

20. If you are changing the wordsize of an Oracle 8.0, Oracle8i or Oracle 9i 9.0.x database,
    run the following script:

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

    If you are changing the wordsize of an Oracle9i 9.2.0.x or Oracle10g  database, no other
    script needs to be run.

21. Run the following SQL statement to check for invalid objects:

    SQL> select owner, object_name, object_type from dba_objects
    where status <> 'VALID';

22. Turn off the spooling of script results to the log file: 

    SQL> SPOOL OFF

    Then, check the spool file and verify that the packages and procedures 
    compiled successfully. You named the spool file in Step 15; the suggested 
    name was catoutw.log. Correct any problems you find in this file (for
    example, compile any invalid objects)

    If you specified SET ECHO ON, then you may want to SET ECHO OFF now: 

    SQL> SET ECHO OFF

23. If you are changing the wordsize of an Oracle 8.0, Oracle8i or Oracle9i 9.0.x database,
    disable the restriction on sessions: 

    SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;

24. Shutdown the database. If you are changing the wordsize of an Oracle 8.0, Oracle8i or 
    Oracle9i 9.0.x database, remove the following parameter from init.ora

    aq_tm_processes=0
    job_queue_processes=0
    _system_trig_enabled=false


The word-size of your database is now changed. 

You can open the database for normal use.

RELATED DOCUMENTS
----------------- Note:214242.1 ORA-600 [17069] while running utlirp.sql converting to 8.1.7.4 64-Bit Note 565773.1 Invalid Objects After Removing OLAP or Migration of a  Database to 64 Bit Note 341880.1 How to Convert a 32-bit Database to 64-bit Database on Linux Note 752986.1 Database Migration With OS Upgrade On Windows Platform Note 757245.1 Can you / How to Upgrade RDBMS and Convert From 32-bit to 64-bit Binaries Directly on Linux or Windows based Intel Platforms Using the Database Upgrade Assistant (DBUA) Note 548978.1 How To Change Oracle 11g Wordsize from 32-bit to 64-bit.

Bug 5079213: ORA-6544 [56319] DURING UPGRADE FROM 10.1.0.5 32BIT TO 10.2.0.2 64BIT
 -- For patch upgrades that are changing word size, utlip.sql must be run 
    manually as it is not automatically run as part of the upgrade.

Oracle 9i Database Migration Release 2 (9.2) Part Number A96530-01 (HTML) -
   http://download.oracle.com/docs/cd/B10501_01/server.920/a96530/toc.htm

Oracle 9i Database Migration Release 1 (9.0.1) Part Number A90191-02 (HTML) -
   http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90191/toc.htm

Oracle8i Migration Release 3 (8.1.7) Part Number A86632-01 (HTML) -
   http://download.oracle.com/docs/cd/A87860_01/doc/server.817/a86632/toc.htm

Oracle8 Migration Release 8.0 Part Number A58243-01 (HTML) -
   http://download.oracle.com/docs/cd/A64702_01/doc/server.805/a58243/toc.htm

Oracle Documentation Master Index -
   http://www.oracle.com/technology/documentation/index.html


Modificaton History
--------------------
18-Nov-2004: Added affected product versions in header and documentation links.
06-Oct-2006: Updated this note for Oracle10g
25-Jul-2007: Updated this note to state that utlirp.sql needs to be run first

REFERENCES

BUG:1867501   - UNCONTROLLED INTERNAL CONNECTION MAKES PLS-00907, PLS-213 AND VARIOUS

NOTE:149948.1   - IMPORTANT: Set "_SYSTEM_TRIG_ENABLED=FALSE" When Upgrading / Downgrading / Applying Patch Sets
NOTE:183649.1   - How to Migrate 8.1.7.3 RDBMS from a 32-bit to a 64-bit database with Java installed

NOTE:209766.1   - Memory Requirements of Databases Migrated from 32-bit to 64-bit
BUG:1816609   - CONVERTING 32 BIT TO 64 BIT RUNNING UTLIRP.SQL FAILS
NOTE:214242.1   - ORA-600 [17069] While Running utlirp.sql Converting to 8.1.7.4 64-Bit
NOTE:757245.1   - Can you / How to Upgrade RDBMS and Convert From 32-bit to 64-bit Binaries Directly on Linux or Windows based Intel Platforms Using the Database Upgrade Assistant (DBUA)
NOTE:341880.1   - How to Convert a 32-bit Database to 64-bit Database on Linux?
NOTE:386990.1   - DB Conversion: 32 bit --&gt64 Bit Broke OLAP Option
NOTE:548978.1   - How To Change Oracle 11g Wordsize from 32-bit to 64-bit.
NOTE:565773.1   - Remove Invalid OLAP Objects From SYS And OLAPSYS Schemas
NOTE:752986.1   - Database Migration With OS Upgrade On Windows Platform

RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support (文档 ID 1079563.1)

In this Document

Abstract

History

Details

Summary

References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 10.2.0.1 and later
Oracle Database - Standard Edition - Version 11.2.0.4 to 11.2.0.4 [Release 11.2]
Information in this document applies to any platform.

ABSTRACT

This note covers RMAN DUPLICATE, RESTORE, and RECOVER mixed platform support.

HISTORY

Author: Tim Chien
Create Date 31-MAR-2010
Update Date 09-JUN-2010

DETAILS

Mixed platforms are supported for:

+ Active Database DUPLICATE
+ Backup-based DUPLICATE using image copies or backup sets
+ RESTORE and RECOVER using image copies or backup sets

Note that the following platform combinations assume that the source database is created at the same version as the destination database (i.e. was not upgraded from a version prior to that listed in the heading for that combination).
An upgraded database can still have blocks which are dependent on old formats and can elicit compatibility issues. Thus, the database is required to be created at the same version as the destination database and not upgraded from a prior version.

These RMAN commands are ONLY supported for the platform combinations listed in this note and are ONLY relevant for same endian combinations.
If a particular combination is not listed below, you must use other supported migration procedures, such as transportable tablespace/database or Data Pump import/export.

For Oracle Database 10g Release 2 and above releases:

Solaris x86-64 Linux x86-64

HP-PA HP-IA

Windows IA (64-bit) / Windows (64-bit Itanium) Windows 64-bit for AMD / Windows (x86-64)

For Oracle Database 11g Release 1 and above releases (requires minimum 11.1 compatible setting):

Linux Windows

Note: Backup must be cold/consistent backup. I.e. cannot apply redo between Windows and Linux, see:
Restore From Windows To Linux using RMAN Fails ( Note 2003327.1)

NOTE: If you need to rollback a PSU already installed, you may need the rollback files from the source system if the source and target are of different platforms.

For Oracle Database 12g Release 2 and above releases:

New functionality with RMAN backup "for transport" allows transport with backupsets. See the following for details:

Steps to Transport a Database to a Different Platform Using Backup Sets in Chapter 28 of the Database Backup and Recovery User's Guide:
http://docs.oracle.com/database/121/BRADV/rcmxplat.htm#BRADV724

12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets (Note 2013271.1)

REFERENCES

NOTE:2003327.1   - Restore From Windows To Linux using RMAN Fails
NOTE:1508375.1   - Duplicate from Windows to Linux ORA-600 [KTBRCL:CDLC NOT IN CR]
NOTE:13335722.8   - Bug 13335722 - Enhancement to allow RMAN conversion of backups cross-endian cross-platform
NOTE:2013271.1   - 12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets