Restoring an Oracle database from files

Scheduler agent is part of database Oracle Home. Anyway must be manually deployed; there is no way to use the database as agent. I think that the documentation is misleading on this case. To help you I will write steps to be performed for agent configuration. I suppose that on the central database you have already enabled HTTP port (etc.). On the remote database (the one where agent have to be configure):

cd $ORACLE_HOME\bin
extjobo -createagentzip execution_agent.zip

Unzip the file into a directory under the $ORACLE_HOME\scheduler.

cd $ORACLE_HOME\scheduler
unzip execution_agent.zip

Modify the file named schagent.conf located in the $ORACLE_HOME\scheduler\execution_agent directory setting the Scheduler Agent port number to listen for connections. (the one you should have already set with dbms_xdb.sethttpport() )

PORT=<schagent_port>

You have to run the root.sh to fix the uid. (You can follow the README file in the execution_agent directory and run the root.sh). NOTE Verify a directory named /wallet exists under /execution_agent/data before running root.sh. If not create them manually and then run root.sh.

Register the database with.

set ORACLE_SID=<your sid>
cd $ORACLE_HOME\scheduler\execution_agent\bin
schagent -registerdatabase <db_host> <db_http_port>

You will be asked to input the registration password. Last start manually the agent:

schagent -start

These steps will install and configure the agent. Now you can create credentials on the central database and create the database destination. Database destination can exists along with a remote agent destination.

The control file (or recovery catalog) holds information about the paths to the data files, online redo log files, archived redo log files, and other information RMAN uses during backup and recovery.

Whenever redo log switch occurs, Archiver (ARCn) process copies online redo logs to archive log location specified by LOG_ARCHIVE_DEST_n initialization parameter(s) and adds the appropriate record to the control file (or recovery catalog) which contains the path to the archived log, log sequence number and other related info.

Because the path has changed, you should either update information about existing archived redo log files and their paths in the RMAN recovery repository or ignore the existing archived redo log files and perform full database backup so that you can recover your database in case of media failure.

The first scenario can be accomplished with the following commands in RMAN:

RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;

Now you can add info about existing archived redo log files using CATALOG RMAN command:

RMAN> catalog archivelog '/ora/archivelog/O1_MF_1_1508_8VDHNOLY_.ARC';

Or you can use CATALOG START WITH to catalog multiple files specifying the path to the files:

RMAN> catalog with '/ora/backups/';

Set the LOG_ARCHIVE_DEST_n initialization parameter value correctly so that new archived redo log files are copied to the appropriate locations:

SQL> alter system set log_archive_dest_1 = 
  'LOCATION=USE_DB_RECOVERY_FILE_DEST'
  scope = both;

Manually switch the redo log group to make sure ARCn copies the archived redo log files to the new location:

SQL> alter system switch logfile;

If the new archived redo log files are successfully copied to the destination you specified, you can backup the database including old archived redo log files and new ones in RMAN:

RMAN> backup database plus archivelog delete input;

In the second scenario, you perform the full backup of the database without including the archived redo log files from the now invalid path You just clean up existing records about archived redo log files in RMAN repository and make the full database backup including all subsequent archived redo log files copied to the valid location. The commands used are the same, you just omit the CATALOG command.