【MOS】在不同版本和平臺之間進行還原或複製 (文件 ID 1526162.1)--跨版本恢復

lhrbest發表於2015-04-08
【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 客戶和專家進行討論:

問題和答案

注意:以下部分中的還原是指使用者管理的(非 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 資料庫,並按照本  中的說明將資料庫恢復到一致的時間點。

 

20 Performing RMAN Recovery: Advanced Scenarios
          ... Restoring a Database on a New Host'

此時不要開啟資料庫。
4. 將 10.2 資料庫手動升級至 11.2,參考文件

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方式開啟。

.

參考:

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方式開啟。

.

參考:

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

以及:


在 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 便捷式資料容器:



(有關 VERITAS Storage Foundation 便捷式資料容器的資訊,請聯絡 Veritas)


社群討論

您可以在下面的社群參與對本文的討論。下面的頁面是實時討論頁面- 不是截圖;-)

參考

NOTE:560417.1 - Recovery Through Upgrade returns ORA-1092 on Open
NOTE:558408.1 - RMAN DUPLICATE / RESTORE a database to a higher patchset

NOTE:1079563.1 - RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support
NOTE:73431.1 - RMAN Compatibility Matrix
NOTE:62290.1 - Changing between 32-bit and 64-bit Word Sizes
NOTE:732053.1 - Avoid Datafile Conversion during Transportable Database
NOTE: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:

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 -  

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 .

      
       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

     
       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:

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.



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:

Oracle? Database Backup and Recovery Reference
12c Release 1 (12.1)
E50791-03
.
DUPLICATE
.
dupOptionList

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:



(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  and .

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


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) -
   

Oracle 9i Database Migration Release 1 (9.0.1) Part Number A90191-02 (HTML) -
   

Oracle8i Migration Release 3 (8.1.7) Part Number A86632-01 (HTML) -
   

Oracle8 Migration Release 8.0 Part Number A58243-01 (HTML) -
   

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

 - 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
 - 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:

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









About Me

...............................................................................................................................

● 本文來自MOS

● 本文在itpub(http://blog.itpub.net/26736162)、部落格園(http://www.cnblogs.com/lhrbest)和個人微信公眾號(xiaomaimiaolhr)上有同步更新

● 本文itpub地址:http://blog.itpub.net/26736162/abstract/1/

● 本文部落格園地址:http://www.cnblogs.com/lhrbest

● 本文pdf版及小麥苗雲盤地址:http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答:http://blog.itpub.net/26736162/viewspace-2134706/

● QQ群:230161599     微信群:私聊

● 聯絡我請加QQ好友(646634621),註明新增緣由

● 於 2017-06-02 09:00 ~ 2017-06-30 22:00 在魔都完成

● 文章內容來源於小麥苗的學習筆記,部分整理自網路,若有侵權或不當之處還請諒解

● 版權所有,歡迎分享本文,轉載請保留出處

...............................................................................................................................

拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公眾號:xiaomaimiaolhr,掃描右邊的二維碼加入小麥苗的QQ群,學習最實用的資料庫技術。

【MOS】在不同版本和平臺之間進行還原或複製 (文件 ID 1526162.1)--跨版本恢復
DBA筆試面試講解
歡迎與我聯絡

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26736162/viewspace-1549041/,如需轉載,請註明出處,否則將追究法律責任。

相關文章