In a nut shell the DB2 Server migration task can be summarized as

1-      Install the DB2 Software

2-      Migrate the existing instances

3-      Migrate the existing DB2 Administration Server

4-      Migrate the existing databases

5-      Additional post migration tasks if applicable

DB2 instances are migrated using the command db2imigr. The fencedID has to be provided along with the Instance name. Below is an example

root@db2dev /opt/IBM/db2/V9.5 ->$DB2DIR/instance/db2imigr -u db2fenc1 ivlm

db2ckmig was successful. Database(s) can be migrated.

DBI1070I  Program db2imigr completed successfully.

A way the fencedID can be checked is while logging in using the instance owner and checking as follows;

ivlm@db2dev /home/ivlm ->ls -l ~/sqllib/adm/.fenced

-r–r–r–    1 db2fenc1 db2fgrp1          0 Mar 13 08:52 /home/ivlm/sqllib/adm/.fenced

Now the DB2 Administration Server can be easily migrated as shown below

root@db2dev /opt/IBM/db2/V9.5 ->$DB2DIR/instance/dasmigr

SQL4410W  The DB2 Administration Server is not active.

SQL4406W  The DB2 Administration Server was started successfully.

DBI1070I  Program dasmigr completed successfully.

Finally the DB2 databases have to be migrated and only then the DB2 databases will have an open status.

ivlm@db2dev /home/ivlm -> db2 MIGRATE DATABASE ILMLOGS USER ivlm USING ivlm123

It is important to note that the user being used should have the SYSADM authority.

Once the database migration is successful the connection can be made to the database for verification

db2 => connect to ILMLOGS

Database Connection Information

Database server        = DB2/AIX64 9.5.1

SQL authorization ID   = IVLM

Local database alias   = ILMLOGS

And then the below query can be executed

db2  "select * from syscat.dbauth"

Alternatively level of db2 can also be checked

ivlm@db2dev /home/ivlm ->db2level

DB21085I  Instance “ivlm” uses “64″ bits and DB2 code release “SQL09051″ with

level identifier “03020107″.

Informational tokens are “DB2 v9.5.0.1″, “s080328″, “U814639″, and Fix Pack

“1″.

Product is installed at “/opt/IBM/db2/V9.5″.

The above contents are only to provide an overview; the IBM documentation has to be followed in order to understand the complete and full steps for migration.

I tried using the same process on an Oracle Database for EBS R12 in no archivelog mode on IBM AIX where I used RMAN to backup and restore.

First the database was restarted and placed in a nomount state.

SQL> shutdown;

SQL> startup nomount;

Copied the controlfiles and redo logs to a backup location.  Brought the database in mount state as;

SQL> alter databse mount;

Connected with RMAN on the source database and  took a backup.

run

{

allocate channel c1 type disk;

allocate channel c2 type disk;

backup as compressed backupset

filesperset 30

format ‘/dev1/backup/%d_%u.bkp’

database;

}

Once backup was completed then the backup files were moved to another server. On the target server the adcfgclone script had to be executed as;

oradev@test /dev2/oracle/proddb/10.2.0/appsutil/clone/bin ->perl adcfgclone.pl dbTechStack

Once script completed the listener would be started.  Now the parameter had to editted with the new location of the controlfiles and the database was mounted and then RMAN backups were cataloged as;

connected to target database: CLONE (DBID=52110679, not open)

RMAN> run
2> {
3> catalog backuppiece ‘/dev5/backup/CLONE_06lpi3e4.bkp’;
4> catalog backuppiece ‘/dev5/backup/CLONE_0glpi5jg.bkp’;
5> catalog backuppiece ‘/dev5/backup/CLONE_0elpi55n.bkp’;
6> catalog backuppiece ‘/dev5a/backup/CLONE_0flpi58h.bkp’;

After cataloging the RMAN backups. The restore process was started. First identiying the new locations, restoring the files and then recovering the files.

RMAN> run
2> {
3> set newname for datafile 396 to ‘/dev10/oracle/proddata/lotus.dbf’;
4> set newname for datafile 380 to ‘/dev10/oracle/proddata/system11.dbf’;
5> set newname for datafile 379 to ‘/dev10/oracle/proddata/system10.dbf’;
6> set newname for datafile 1 to ‘/dev10/oracle/proddata/system01.dbf’;
7> set newname for datafile 2 to ‘/dev10/oracle/proddata/system02.dbf’;
8> set newname for datafile 3 to ‘/dev10/oracle/proddata/system03.dbf’;

450> restore database;
451> switch datafile all;
452> recover database;

453>}

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

executing command: SET NEWNAME

Starting restore at 06-OCT-10
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00204 to /dev11/oracle/proddata/oex01.dbf

Now the database had been restored and recovered. Then the redologs were checked

SQL> SELECT member FROM v$logfile;

MEMBER
——————————————————————————–
/qa11/oracle/proddata/log04a.dbf
/qa11/oracle/proddata/log04b.dbf

They were being shown in the old locations so had to be updated with new ones as;
SQL> ALTER DATABASE RENAME FILE ‘/qa11/oracle/proddata/log04a.dbf’ to ‘/dev11/oracle/proddata/log04a.dbf’;

Database altered.

SQL> ALTER DATABASE RENAME FILE ‘/qa11/oracle/proddata/log04b.dbf’ to ‘/dev11/oracle/proddata/log04b.dbf’;

Database altered.

The old temp files had to be dropped and then recreated again.  After recreating the temp files the database could be opened

SQL> alter database open;

Database altered.

After the database had been opened, a script to update the libarry had to be executed as also mentioned in Doc ID 406982.1

SQL> @/dev2/oracle/proddb/10.2.0/appsutil/install/CLONE_dev/adupdlib.sql so

PL/SQL procedure successfully completed.
SQL> exit

Finally the adcfgclone script had to be executed  along with the database context file as;

oradev@test /dev2/oracle/proddb/10.2.0/appsutil/clone/bin ->perl adfgcloneclone.pl dbconfig /dev2/oracle/proddb/10.2.0/appsutil/CLONE_dev.xml

Once the script completes, the database and listener were started. The complete steps have been documented and listed in Oracle My Support Doc ID: 406982.1 for cloning Oracle EBS.

Oracle 11g Database has been full of new and improved enhancements so it wasn’t a surprise to come across Data Recovery Advisor.
It is an amazing tool that analyzes, proposes and implements solutions for data failures.
It has command line and GUI interface. GUI interface can be accessed through Oracle EM Grid and DB Console while the RMAN command line interface includes DRA commands.
Oracle describes a basic five step process for fixings issues with DRA. These are;

1. List the failures
2. Validate the database (optional)
3. Establish the possible options
4. Consider an option
5. Verify or check for remaining failures

Now I will see how Data Recovery Advisor can perform on critical recoveries. We are considering two scenarios, first scenario is that the system datafile has been lost and the second scenario in which all the controlfiles have been lost. In both cases prior RMAN backups exist.

Scenario: System datafile has been lost

Recovery Manager: Release 11.1.0.6.0 - Production on Fri Jul 11 09:27:14 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved.

RMAN> connect target /

connected to target database: DEV11G (DBID=3891859867, not open)

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
42 CRITICAL OPEN 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSTEM01.DBF’ is missing

Obviously the database could not open at this point. We have used the command LIST FAILURE to review what the failures are.

Going a bit further seeing how this will impact the database we can use LIST FAILURE DETAIL as follows;

RMAN> list failure detail;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
42 CRITICAL OPEN 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSTEM01.DBF’ is missing
Impact: Database cannot be opened

As already mentioned the database cannot be opened which has made this as a CRITICAL priority.

RMAN> advise failure;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
42 CRITICAL OPEN 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTR
ATOR\ORADATA\DEV11G\SYSTEM01.DBF’ is missing
Impact: Database cannot be opened

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=152 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSTEM01.DBF was unintentionally renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
—— ——————
1 Restore and recover datafile 1
Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3619189128.hm

Now I have used ADVISE FAILURE to see as to how can I repair or fix this issue. A list of options have been presented these are MADATORY MANUAL ACTIONS but none are required in this case, OPTIONAL MANUNAL ACTIONS and AUTOMATED REPAIR OPTIONS. We will consider AUTOMATED REPAIR OPTIONS; this includes simply executing the following script;
f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3619189128.hm

RMAN> repair failure preview;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3619189128.hm

contents of repair script:
# restore and recover datafile
restore datafile 1;
recover datafile 1;

Now we have displayed the contents of the script with REPAIR FAILURE PREVIEW command. We are completely aware of the recovery process as it is transparent.

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3619189128hm

contents of repair script:
# restore and recover datafile
restore datafile 1;
recover datafile 1;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 11-JUL-08
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to F:\APP\ADMINISTRATOR\ORADATA\DE
11G\SYSTEM01.DBF
channel ORA_DISK_1: reading from backup piece F:\APP\ADMINISTRATOR\FLASH_RECOVE
Y_AREA\DEV11G\BACKUPSET\2008_07_11\O1_MF_NNNDF_TAG20080711T092430_47H2B04D_.BKP
channel ORA_DISK_1: piece handle=F:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\DEV11
\BACKUPSET\2008_07_11\O1_MF_NNNDF_TAG20080711T092430_47H2B04D_.BKP tag=TAG20080
11T092430
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:16
Finished restore at 11-JUL-08

Starting recover at 11-JUL-08
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:01

Finished recover at 11-JUL-08
repair failure complete

Do you want to open the database (enter YES or NO)? YES
database opened

Finally we executed the fix using REPAIR FAILURE and the repair has been successful.

RMAN> list failure closed;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
42 CRITICAL CLOSED 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTR
ATOR\ORADATA\DEV11G\SYSTEM01.DBF’ is missing

After opening the database we check again for any failures by using LIST FAILURE command. We can see that the STATUS had been changed from OPEN to CLOSED as the issue has been resolved.

Now we see the loss of controlfiles recovery using DRA.

Scenario: All controlfiles have been lost

RMAN> list failure;

using target database control file instead of recovery catalog
List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
113 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL01.CTL is missing
110 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL02.CTL is missing
107 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL03.CTL is missing

This is an additional step only to review that the precise impact is being shown or it could even be considered as part of step one.

RMAN> list failure detail;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
113 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL01.CTL is missing
Impact: Database cannot be mounted

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
110 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL02.CTL is missing
Impact: Database cannot be mounted

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
107 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL03.CTL is missing
Impact: Database cannot be mounted

RMAN> advise failure;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
113 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL01.CTL is missing
Impact: Database cannot be mounted

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
110 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL02.CTL is missing
Impact: Database cannot be mounted

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
107 CRITICAL OPEN 11-JUL-08 Control file F:\APP\ADMINISTRATOR\OR
ADATA\DEV11G\CONTROL03.CTL is missing
Impact: Database cannot be mounted

analyzing automatic repair options; this may take some time
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=152 device type=DISK
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL01.CTL was unintentionally
renamed or moved, restore it
2. If file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL02.CTL was unintentionally
renamed or moved, restore it
3. If file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL03.CTL was unintentionally
renamed or moved, restore it

Automated Repair Options
========================
Option Repair Description
—— ——————
1 Restore a backup control file
Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_4252270918.hm

RMAN> repair failure preview;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_4252270918.
hm

contents of repair script:
# restore control file
restore controlfile from autobackup;
sql ‘alter database mount’;

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_4252270918.hm

contents of repair script:
# restore control file
restore controlfile from autobackup;
sql ‘alter database mount’;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting restore at 11-JUL-08
using channel ORA_DISK_1

recovery area destination: F:\app\Administrator\flash_recovery_area
database name (or database unique name) used for search: DEV11G
channel ORA_DISK_1: AUTOBACKUP F:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\DEV11G\A
UTOBACKUP\2008_07_11\O1_MF_S_659784297_47H2BTVC_.BKP found in the recovery area
AUTOBACKUP search with format “%F” not attempted because DBID was not set
channel ORA_DISK_1: restoring control file from AUTOBACKUP F:\APP\ADMINISTRATOR\
FLASH_RECOVERY_AREA\DEV11G\AUTOBACKUP\2008_07_11\O1_MF_S_659784297_47H2BTVC_.BKP

channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL01.CTL
output file name=F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL02.CTL
output file name=F:\APP\ADMINISTRATOR\ORADATA\DEV11G\CONTROL03.CTL
Finished restore at 11-JUL-08

sql statement: alter database mount
released channel: ORA_DISK_1
repair failure complete

At this point, the control files have been restored and the database reached in mount state.

RMAN> list failure;

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
437 CRITICAL OPEN 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSTEM01.DBF’ needs media recovery
305 CRITICAL OPEN 11-JUL-08 Control file needs media recovery
142 HIGH OPEN 11-JUL-08 One or more on-system datafiles need media recovery

This time new failures have been determined. So again we execute the ADVISE FAILURE.

RMAN> advise failure;

Starting implicit crosscheck backup at 11-JUL-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=152 device type=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 11-JUL-08

Starting implicit crosscheck copy at 11-JUL-08
using channel ORA_DISK_1
Finished implicit crosscheck copy at 11-JUL-08

searching for all files in the recovery area
cataloging files…
cataloging done

List of Cataloged Files
=======================
File Name: F:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\DEV11G\AUTOBACKUP\2008_07_11
\O1_MF_S_659786902_47H4W8C7_.BKP

List of Database Failures
=========================

Failure ID Priority Status Time Detected Summary
———- ——– ——— ————- ——-
437 CRITICAL OPEN 11-JUL-08 System datafile 1: ‘F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSTEM01.DBF’ needs media recovery
305 CRITICAL OPEN 11-JUL-08 Control file needs media recovery
142 HIGH OPEN 11-JUL-08 One or more non-system datafiles need media recovery

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If you restored the wrong version of data file F:\APP\ADMINISTRATOR\ORADATA\D
EV11G\SYSTEM01.DBF, then replace it with the correct one
2. If you have the correct version of the control file, then shutdown the database and replace the old control file
3. If you restored the wrong version of data file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\SYSAUX01.DBF, then replace it with the correct one
4. If you restored the wrong version of data file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\UNDOTBS01.DBF, then replace it with the correct one
5. If you restored the wrong version of data file F:\APP\ADMINISTRATOR\ORADATA\DEV11G\USERS01.DBF, then replace it with the correct one

Automated Repair Options
========================
Option Repair Description
—— ——————
1 Recover database
Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3650007651.hm

A new script has been created which can be reviewed as follows;

RMAN> repair failure preview;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3650007651.hm

contents of repair script:
# recover database
recover database;
alter database open resetlogs;

Finally executing the repair script as follows;

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: f:\app\administrator\diag\rdbms\dev11g\dev11g\hm\reco_3650007651.
hm

contents of repair script:
# recover database
recover database;
alter database open resetlogs;

Do you really want to execute the above repair (enter YES or NO)? YES
executing repair script

Starting recover at 11-JUL-08
using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file F:\APP\ADMI
NISTRATOR\ORADATA\DEV11G\REDO01.LOG
archived log file name=F:\APP\ADMINISTRATOR\ORADATA\DEV11G\REDO01.LOG thread=1 s
equence=1
media recovery complete, elapsed time: 00:00:01
Finished recover at 11-JUL-08

database opened
repair failure complete

Repair has been successful once again.

In conclusion to the control files recovery we have seen that the DRA process was divided into two portions.
First script executed;

1. RESTORE CONTROLFILE FROM AUTOBACKUP
2. ALTER DATABSE MOUNT

Second script executed;

1. RECOVER DATABASE
2. ALTER DATABASE OPEN RESETLOGS

DRA seems to be a reliable and an effective tool for database recovery.

Additional Resources;

http://download.oracle.com/docs/cd/B28359_01/backup.111/b28270/rcmrepai.htm

Introduction

Backup is a very important aspect of any system. Generally when the word backup is expressed in Oracle, it is coincided with an Oracle database. But an appropriate understanding depicts a different picture;

Here the focus is on Oracle E-Business Suite (EBS) and Oracle Applications Server (Oracle AS).

Backup Oracle E-Business Suite (EBS) – The Perspective

Cloning Oracle Applications Release 11i with Rapid Clone: Doc ID:  Note: 230672.1

Cloning Oracle Applications Release 12 with Rapid Clone: Doc ID:  Note: 406982.1

These are some helpful documents while referring to backing up Oracle E-Business Suite (EBS).

Since the intend is to understand backup, we can directly pass on to the cloning portion of the doc for Oracle Applications Release 11i that can be as follows;

• Prepare the Source
  • Run the cloning script on the database tier.
  • Run the cloning script the application tier.
• Copy the files
  • Copy the applications tier file system which includes APPL_TOP, OA_HTML, OA_JAVA, OA_JRE_TOP, COMMON_TOP/util, COMMON_TOP/clone, COMMON_TOP/pages, 806 ORACLE_HOME, iAS ORACLE_HOME).
  • Copy the database tier file system which includes the DBF files and the ORACLE_HOME

• Configure the Target
  • Run the cloning script on the database tier.
  • Run the cloning script on the application tier.

Note: Please see Doc ID:  Note: 230672.1 for complete details.

Here referring to the same process but for Oracle Applications Release 12

• Prepare the Source
  • Run the cloning script on the database tier.
  • Run the cloning script on the applications tier.
• Copy the files
  • Copy the application tier file system which includes APPL_TOP, COMMON_TOP and Tech Stack (AS Tools ORACLE_HOME + AS Web IAS ORACLE_HOME)).
  • Copy the database tier file system which includes the DBF files and the ORACLE_HOME
• Configure the Target
  • Run the cloning script on the database tier.
  • Run the cloning script on the application tier.

Note: Please see Doc ID:  Note: 406982.1 for complete details.

Apparently various details have not been presented; these details would include closing or shutting down the services, the perquisites check, location of the scripts, names of the scripts since process has been reviewed in a glance. The conclusive point is that cloning not only includes database file system but also application file system. Further, cloning Oracle Applications can be constituted as an Oracle Applications backup.

Backup Oracle Application Server (Oracle AS) – The Perspective

Oracle Applications Server (10.1.3)

http://download.oracle.com/docs/cd/B31017_01/core.1013/b28940/br_bkp.htm#BABFJJIG

Oracle Applications Server (10.2.1)

http://download-west.oracle.com/docs/cd/B14099_19/core.1012/b13995/br_bkp.htm#i1010329

These are from the administrator guides.

Oracle AS backup has been suggested as follows;

1. Oracle AS Complete Installation
2. Oracle AS Server Environment
3. Oracle AS Running
4. Instance Backup

Note: Please see the Oracle documentation for complete details.

The first condition for an Oracle AS backup is a complete Oracle Application Server installation. The second condition is an image backup. Under the situation the Oracle AS has been running and some massive, regular or administrative changes have been made, the previous step has to be referred. Lastly the instance backup is to be considered. The conclusive point is there are two types of Oracle Application Server backups; image backup and instance backup.

Summary

Therefore, in both cases (Oracle EBS and Oracle AS) Oracle provides secure methods for backups considering not only the database files but other files as well.

We tend to cover more of Oracle Application Server backups in the coming parts.