Production Machine OS down, RMAN disaster recovery

My friend's database system has a problem. The following is his solution process, which is helpful for me to learn RMAN:

The following is a case:

Production Machine OS down, RMAN disaster recovery

When I was learning rman, I suddenly encountered a golden "good opportunity" to learn RMAN. Because it is a production machine, the following operation objective is to restore data in the shortest time, there is no particular research on the reason for all the operations, but it is still worth mentioning here, hoping to have a reference value for beginners of RMAN.

Scenario Description:
Production machines cannot be started because of virus infection or malicious attacks. Xin Hao performed a full database backup using RMAN (catalog mode) a few days ago,
Backup files and the generated logs are stored on other machines. How can I restore the OS and oracle after the OS and Oracle are reinstalled?
Currently, the Catalog Database works normally.

Solution:
My full-database backup script is as follows:
RMAN> run {
2> allocate channel D1 type disk maxpiecesize = 500 m;
3> Backup full database
4> Format 'C:/Oracle/RMAN/DB _ % d _ % S _ % P _ % T ';
5> release channel D1;
6>}

1. Check the dbid of the target database:
C:/> sqlplus RMAN/RMAN @ RMAN

SQL * Plus: Release 9.2.0.1.0-production on Thursday April 7 14:26:57 2005

Copyright (c) 1982,200 2, Oracle Corporation. All rights reserved.

Connect:
Oracle9i Enterprise Edition Release 9.2.0.1.0-Production
With the partitioning, OLAP and Oracle Data Mining options
Jserver release 9.2.0.1.0-Production

SQL> select * From dB;

Db_key db_id high_conf_recid last_kccdivts curr_dbinc_key
--------------------------------------------------------------
45 1729098935 0 554810295 46

2. Set dbid
C:/> RMAN

Recovery MANAGER: Version 9.2.0.1.0-Production

Copyright (c) 1995,200 2, Oracle Corporation. All rights reserved.

RMAN> set dbid 1729098935

Executing command: Set dbid
3. register the instance on the newly installed machine and start it to nomount (pfile backed up previously)
C:/> oradim-New-Sid cnpl-pfile C:/Oracle/RMAN/initcnpl. ora-intpwd cnpl515

4. Start listening and prepare tnsname. ora
C:/> sqlplus "sys/cnpl515 @ cnpl as sysdba"

SQL * Plus: Release 9.2.0.1.0-production on 4 8 14:43:06 2005

Copyright (c) 1982,200 2, Oracle Corporation. All rights reserved.

Connected to idle routine
SQL> startup nomount pfile = C:/Oracle/RMAN/initcnpl. ora (you can write one pfile at will, or copy the original file back for reuse, but you must unregister the parameters in the regular file)
Oracle
The routine has been started.
Total system global area 135338868 bytes
Fixed size 453492 bytes
Variable Size 109051904 bytes
Database buffers 25165824 bytes
Redo buffers 667648 bytes

5. Return to RMAN to restore controlfile
(In this step, you must create the same directory on the new machine. RMAN will not automatically create the directory,
In this example, C:/Oracle/oradata/cnpl)
C:/> RMAN catalog RMAN/RMAN @ RMAN

Recovery MANAGER: Version 9.2.0.1.0-Production

Copyright (c) 1995,200 2, Oracle Corporation. All rights reserved.

Connect to recover directory database

RMAN> set dbid 1729098935

Executing command: Set dbid

RMAN> connect target sys/cnpl515 @ cnpltsd

Connect to the target database: cnpl (not installed)

RMAN> restore controlfile;

Start restore from-05

Allocated channel: ora_disk_1
Channel ora_disk_1: SID = 10 devtype = Disk
Channel ora_disk_1: Recovering data file backup set
Channel ora_disk_1: restoring the control file
Output file name = C:/Oracle/oradata/cnpl/control01.ctl
Channel ora_disk_1: recovered backup segment 1
Segment handle = C:/Oracle/RMAN/db_cnpl_1_555085654 tag = tag20050408t143003 Params = NUL
L
Channel ora_disk_1: Recovery complete
Copying Control File
Output file name = C:/Oracle/oradata/cnpl/control01.ctl
Output file name = C:/Oracle/oradata/cnpl/control02.ctl
Output file name = C:/Oracle/oradata/cnpl/control03.ctl
The restore is completed from month 4 to month 05.

RMAN>

6. Start the new database on the new machine to mount
SQL>
SQL> alter database Mount;

SQL>
7. Return to RMAN for Restore database;

RMAN> Restore database;

Start restore from-05

Allocated channel: ora_disk_1
Channel ora_disk_1: SID = 12 devtype = Disk
Channel ora_disk_1: Recovering data file backup set
Channel ora_disk_1: Specifies the data file to be recovered from the backup set.
Restoring data file 00001 to C:/Oracle/oradata/cnpl/system01.dbf
Restoring data file 00002 to C:/Oracle/oradata/cnpl/undotbs01.dbf
Restoring data file 00003 to C:/Oracle/oradata/cnpl/cwmlite01.dbf
Restoring data file 00004 to C:/Oracle/oradata/cnpl/drsys01.dbf
Restoring data file 00005 to C:/Oracle/oradata/cnpl/example01.dbf
Restoring data file 00006 to C:/Oracle/oradata/cnpl/indx01.dbf
Restoring data file 00007 to C:/Oracle/oradata/cnpl/odm01.dbf
Restoring data file 00008 to C:/Oracle/oradata/cnpl/tools01.dbf
Restoring data file 00009 to C:/Oracle/oradata/cnpl/users01.dbf
Restoring data file 00010 to C:/Oracle/oradata/cnpl/xdb01.dbf
Channel ora_disk_1: recovered backup segment 1
Segment handle = C:/Oracle/RMAN/db_cnpl_8_425554919188 tag = tag20050406t161533 Params = NUL
L
Channel ora_disk_1: recovered backup Segment 2
Segment handle = C:/Oracle/RMAN/db_cnpl_8_2_554919188 tag = tag20050406t161533 Params = NUL
L
Channel ora_disk_1: Recovery complete
The restore is completed from month 4 to month 05.

8. Perform the recover operation

RMAN> recover database;

Start recover from month 4 to month 05
Use channel ora_disk_1

Restoring media...

The archive log thread 1 Series 12 has been used as the file C:/Oracle/ora92/rdbms/arc00012.001 on the disk.
Upper
Archive log file name = C:/Oracle/ora92/rdbms/arc00012.001 thread = 1 sequence = 12
The archived log cannot be found.
Archiving log thread = 1 sequence = 13
RMAN-00571: ========================================================== ==============================
RMAN-00569: ==================== error message stack follows ==========================
RMAN-00571: ========================================================== ==============================
RMAN-03002: failure of recover command at 09:11:33
RMAN-06054: Media recovery requesting unknown log: thread 1 SCN 523585

An error occurred. Try to copy the original redo02.log, redo01.log, and redo03.log back to the directory of the new instance,
Then perform the recover operation.
RMAN> recover database;

Start recover from month 4 to month 05
Use channel ora_disk_1

Restoring media...

The archive log thread 1 sequence 3 is stored on the disk as the file C:/Oracle/oradata/cnpl/redo02.log
Archive log thread 1 sequence 4 already exists on disk as file C:/Oracle/oradata/cnpl/redo03.log
The archive log thread 1 sequence 5 is stored on the disk as the file C:/Oracle/oradata/cnpl/redo01.log.
Archive log file name = C:/Oracle/oradata/cnpl/redo02.log thread = 1 sequence = 3
Archive log file name = C:/Oracle/oradata/cnpl/redo03.log thread = 1 sequence = 4
Archive log file name = C:/Oracle/oradata/cnpl/redo01.log thread = 1 sequence = 5
Restore Media
Completed the recover in month-05

RMAN> run {
2> SQL 'alter database open resetlogs ';
3>}

SQL statement: Alter database open resetlogs
RMAN>
RMAN>
9. Verify data
The results are satisfactory, and all data is restored.

10. perform a full-database backup, change it to the archive mode, and put it into operation again.

Note: All operations are performed on the windowns 2000 Server Platform and oracle9.2.0.1. I wonder whether redo physical copy is cross-platform in the last step,
Cannot be tested due to environment limitations. Is there a good way to disable this redo physical copy. because the probability of such OS downtime still exists. Which of the following prawns can provide a more comprehensive restoration strategy to cope with such OS downtime.

I have made some suggestions for my friend cases:

I think we should modify the full-database backup script and add the statement for backing up the archived logs:

RMAN> run {
2> allocate channel D1 type disk maxpiecesize = 500 m;
3> Backup full database
4> Format 'C:/Oracle/RMAN/DB _ % d _ % S _ % P _ % T ';
5> SQL 'alter system archive log current ';
6> Backup filesperset 3 archivelog all Delete input;
7> release channel D1;
8>}

In this way, even if there is no original redolog backup, the database can be restored by using the archive log.