Use RMAN to downgrade Oracle10G64 bit to 32 bit

Because the project needs to test the environment, the original database is ORACLE10.2.0.464-bit, and the environment needs to be migrated to a 32-bit machine. There are many articles on the Internet that upgrade 32-bit to 64-bit. In fact, 64

Because the project needs to test the environment, the original database is ORACLE 10.2.0.4 64-bit, the environment needs to be migrated to a 32-bit machine, there are many articles on the Internet to update 32-bit to 64-bit, in fact 64

Because the project needs to test the environment, the original database is Oracle 10.2.0.4 64-bit, and the environment needs to be migrated to a 32-bit machine. There are many articles on the Internet that upgrade 32-bit to 64-bit, in fact, the 64-bit downgrade is similar to the 32-bit downgrade, and the data dictionary changes. You can use the cold backup RMAN and other methods for migration. This article uses RMAN for migration. The RMAN backup can be referred to in the following article.

Basic Oracle tutorial-copying a database through RMAN

Reference for RMAN backup policy formulation

RMAN backup learning notes

Oracle Database Backup encryption RMAN Encryption

The procedure is as follows.
1. Stop delete all input in the RMAN script one day before migration to stop deleting archived log files.
2. Use V $ LOG to determine the current LOG serial number before full backup.
3. Create a directory on the current server to save the RMAN backup file.
4. Use the RMAN full backup script to complete the RMAN backup and specify the directory to the new directory. At the same time, The RMAN backup log is saved to determine the backup part of the Backup set where the ORACLE control file is located.
5. Use create pfile from spfile in the original database to update PFILE.
6. Create a database on the target server. The database name is the same as that of the original database.
7. After creation, all data files, log files, control files, and spfiles are deleted.
8. Create a directory on the target server, which is the same as the directory on the original server.
9. Transmit all backup sets to the directory created on the target server through FTP.
10. Modify the PFILE of the database on the target server, which must be the same as the PFILE of the original database.
11. Start the database to the NOMOUNT status.
12. Create a directory on the target server to store the recovered control file. For details, refer to the configuration in PFILE.
13. Restore the control file.
14. Start the database to the MOUNT status.
15. Create a directory on the target server to store database files, and create an archive directory to store archived logs,
Create various TRACE file directories at the same time.
16. Use RESOTRE to restore data files.
The preparation is complete. The following steps are the steps for data recovery.
17. Extract the object information of the original database to facilitate comparison after migration.
18. Close the application and make sure no new data will be written to the database.
19. perform multiple log switching to ensure that all changed data has been written to the archive log. If there are three log files, perform four switching.
20. Check the V $ LOG in the original database to determine the current LOG sequence and determine the archive LOG files to be copied. For the sake of security, you can obtain more logs before the earliest archive.
21. Copy the archived logs of the original server to the corresponding directory of the target server through FTP.
22. Use recover database until for restoration.
23. Use alter database open resetlogs to OPEN the DATABASE.
24. Run the shutdown immediate command to shut down the database.
25. Run the startup migrate command to start the database.
26. Run the script utlirp. SQL.
27. Use the command shutdown immediate to shut down the database.
28. Run the STARTUP command to start the database.
29. Run the script utlrp. SQL.
30. Use the command shutdown immediate to shut down the database.
31. Run the STARTUP command to start the database.
32. Extract the object information of the database and compare it with the object information of the original database.
Now the data migration is complete.

Create a directory and copy all the backups to the same directory as the original database. My files are/u01/app/oracle/backup.

[Root @ itspf ~] # Su-oracle
[Oracle @ itspf ~] $ Cd/u01/app/oracle/
[Oracle @ itspf oracle] $ ls
OraInventory product
[Oracle @ itspf oracle] $ mkdir admin
[Oracle @ itspf oracle] $ ls
Admin oraInventory product
[Oracle @ itspf oracle] $ mkdir flash_recovery_area
[Oracle @ itspf oracle] $ mkdir archivelog
[Oracle @ itspf oracle] $ mkdir backup
[Oracle @ itspf oracle] $ mkdir oradata
[Oracle @ itspf oracle] $ cd admin
[Oracle @ itspf admin] $ mkdir itspfdb
[Oracle @ itspf admin] $ cd itspfdb/
[Oracle @ itspf itspfdb] $ mkdir adump
[Oracle @ itspf itspfdb] $ mkdir bdump
[Oracle @ itspf itspfdb] $ mkdir cdump
[Oracle @ itspf itspfdb] $ mkdir dpdump
[Oracle @ itspf itspfdb] $ mkdir pfile
[Oracle @ itspf itspfdb] $ mkdir udump
[Oracle @ itspf itspfdb] $ cd ..
[Oracle @ itspf admin] $ cd ..
[Oracle @ itspf oracle] $ cd ora
Oradata/oraInventory/
[Oracle @ itspf oracle] $ cd oradata/
[Oracle @ itspf oradata] $ mkdir itspfdb

For more details, please continue to read the highlights on the next page: