Configure Enterprise Manager 24ai for Oracle 26ai RMAN

Configuring Enterprise Manager to use Recovery Manager means preparing the management system to execute authorized RMAN work against the intended database. It includes discovering the target, establishing credentials, confirming the execution environment, selecting backup storage, and reviewing database backup settings. A working console login is only the starting point. The job must reach the database and its destination with the privileges required for the selected operation.

This lesson uses Enterprise Manager 24ai Cloud Control with Oracle AI Database 26ai. These are separate products with separate release and patch requirements. Confirm the supported combination of OMS, Management Agent, database plug-in, and target database before configuring jobs. The following steps describe a conventional deployment with an agent on the database host; other supported topologies require their own checks.

Understand the job and metadata paths

The Cloud Control console submits the administrator's job definition to the Oracle Management Service (OMS). The job system coordinates execution through the Management Agent environment. RMAN connects to the target database and performs the requested backup work. Execution status and output return to the management system for inspection. Oracle describes these management components in its Enterprise Manager architecture guide.

There are two different repositories to keep straight. The Enterprise Manager Management Repository stores management data. RMAN maintains backup metadata in the target control file and, when configured, a recovery catalog. An RMAN recovery catalog is a separate database schema, not another name for the Enterprise Manager repository. Neither a catalog entry nor a successful job record supplies a missing backup piece.

Use this distinction when troubleshooting. If the console cannot display a job, investigate management services and permissions. If RMAN cannot connect, investigate the target or catalog connection. If it cannot write a backup piece, inspect the execution account, channel configuration, and destination. Following the relevant path avoids changing unrelated components.

Step 1: Confirm the target and execution environment

Open Cloud Control using the address provided by your Enterprise Manager administrator. Select Targets > Databases and open the intended database's home page. Compare the displayed target with the database identity in your protection plan. Confirm its host, Oracle home, service, database role, and container scope. Discovery and an Up status establish monitoring visibility; they do not prove that backup jobs can authenticate or access storage.

For a CDB backup, identify the root and the PDBs included in the proposed operation. For a selected-PDB backup, record which PDBs are included and how their recovery requirements are met. Oracle's 26ai backup guide documents a customized PDB backup workflow from the database home page. Do not assume that selecting one PDB protects every PDB in the container database.

Confirm agent health, plug-in support, and communication between the OMS and execution environment. On the database host, check that the chosen account can use the appropriate Oracle home and required backup libraries. In RAC, verify storage access from the nodes that may execute work. In Data Guard, choose the intended primary or standby role and review the role-specific backup design.

Record these decisions before opening the wizard: target identity, backup scope, execution host, destination, credential owner, and expected recovery point. This short configuration record helps another administrator review the work and distinguishes an intentional target selection from a convenient default.

Step 2: Configure operational credentials

Enterprise Manager permissions, host credentials, and database credentials serve different purposes. Your console account needs permission to view the target and submit the relevant job. Host credentials authorize operations in the execution environment where required. Database credentials authorize RMAN's connection to the target. Monitoring credentials can keep a dashboard healthy while a backup job fails under a different account.

Oracle documents Setup > Security > Preferred Credentials in its target credential guide. Choose the appropriate target type and manage its preferred credentials. Use target-specific settings when a shared default would identify the wrong account. Named credentials can be associated with preferred credentials and controlled through Enterprise Manager privileges.

Verify which credential the submitted job actually uses. A preferred value simplifies selection, but the job may have an explicit credential choice. Test the selected host and database access through the supported workflow, then check the role and target scope. Password rotation must reach recurring jobs and approved credential records; it should not depend on someone remembering a password embedded in an old script.

Enterprise Manager 24ai RU7 added preferred SYSBACKUP credentials for database instances, as described in its release-update feature notes. Use the backup-specific privilege where the installed workflow supports it and your policy permits it. Review the actual requirements before assigning broader privileges. Keep real passwords out of command lines, screenshots, article examples, and job descriptions.

Step 3: Select storage and verify access

Choose a supported destination according to the recovery plan. Disk backups may use a configured file system or ASM location. SBT backups use the supported media-management or cloud backup module and its configuration. Object storage is not interchangeable with a local directory: the selected integration must be installed, configured, and available to the execution environment.

Check free capacity, write permissions, network access where applicable, and the failure domains shared by the target and destination. A backup on the same failing storage as the database may not provide the intended protection. Also check the recovery path: the account and tools used after a failure must be able to retrieve the files, not merely create them during normal operation.

For ASM, use a valid configured destination rather than inventing a directory hierarchy from an example. For SBT, test the appropriate library and channel configuration. For file-system backups, establish the expected mount and permissions on every relevant execution host. In all cases, record where backup pieces, archived redo, and control file autobackups can be found.

Step 4: Inspect persistent RMAN configuration

RMAN persistent settings apply to later operations unless overridden. Inspect them before changing them, using SHOW ALL; in an authorized RMAN session connected to the target. Save the output as configuration evidence and compare it with the intended backup strategy. Oracle's RMAN configuration guide explains device settings, retention, and autobackups.

RMAN> SHOW ALL;

The following configuration is illustrative. It enables control file autobackups, chooses a fourteen-day recovery window, and permits two disk channels. These are example policy choices, not universal defaults. The commands change persistent configuration and should be applied only after the destination, capacity, and recovery requirements have been reviewed.

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;
CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
SHOW ALL;

A recovery window defines a retention requirement; it does not itself schedule backups or ensure that all required redo exists. The archived log deletion policy is a separate setting. Review it with the backup and, where applicable, standby requirements. Do not delete archived logs merely because they exceed a calendar age or because a datafile backup completed.

Parallelism must fit available resources. Two channels can consume more CPU, I/O, and storage bandwidth than one. A job that explicitly allocates channels can override configured channel behavior. Inspect the actual generated instructions, including destinations and formats, before concluding that a wizard uses the settings you reviewed.

Step 5: Decide whether to use a recovery catalog

A basic standalone RMAN workflow can use the target control file without a recovery catalog. A catalog adds centralized metadata and longer history, and particular environments have additional requirements. Check the applicable Data Guard guidance when coordinating metadata across primary and standby databases. Catalog availability and protection should be part of the design rather than an unexamined extra checkbox.

Oracle's recovery catalog guide describes preparation of the catalog database, schema owner, required privileges, catalog creation, and registration. Its schema-owner procedure includes the RECOVERY_CATALOG_OWNER role and the additional privileges granted through dbmsrmansys.sql. Follow the procedure for the actual catalog database and compatible software versions rather than copying a shortened account-creation recipe.

Keep the catalog independently protected. A catalog hosted in the database being protected can become unavailable during the very failure for which it is needed. Register a CDB at the root level; do not treat each PDB as an independently registered target database. Verify catalog connectivity and authentication from the actual RMAN execution environment, then associate the approved catalog configuration with the job.

A network naming test alone is insufficient. For example, a successful tnsping does not demonstrate that the catalog account can authenticate or that RMAN can use the schema. Inspect the real connection result and registration state. Do not expose catalog passwords in a demonstration command or assume the console's stored job results replace catalog metadata.

Step 6: Review compression and encryption deliberately

Compression and encryption are separate configuration decisions. Compression changes resource use and backup size; encryption changes protection and recovery dependencies. Review supported options, licensing, and recovery access before selecting either. Measure behavior on representative data instead of assuming a named algorithm is always the best choice.

Oracle's RMAN backup concepts distinguishes BASIC compression from compression levels that require the Advanced Compression option. Do not adopt MEDIUM simply because an old example calls it a best-practice default. Also inspect whether the job requests compressed backup sets; selecting an algorithm and creating a compressed backup are related but distinct actions.

RMAN backup-set encryption supports transparent, password-based, and dual modes. Database TDE should not be interpreted as automatic encryption of every backup piece. Review RMAN's encryption settings and the actual operation. Oracle's advanced RMAN configuration guide explains encryption prerequisites and keystore handling.

Plan how the recovery environment obtains the necessary keys or approved password handling. Protect and test that dependency alongside the backup. An encrypted backup whose recovery keys are unavailable cannot meet the recovery objective. Check configuration and support for the destination and database edition before enabling encryption in a production job.

Step 7: Review a one-time job before recurring work

Oracle documents Availability > Backup & Recovery > Schedule Backup on the Database Home page. Select the intended backup scope and review destination, credentials, channel choices, and any catalog connection. Screen details vary with the database plug-in, release update, and privileges. Use the installed interface's help rather than relying on an old screenshot for every field name.

Start with a controlled one-time execution that fits the test environment and maintenance plan. The following RMAN fragment illustrates a tagged backup for an authorized, properly configured ARCHIVELOG database. It is instructional text, not a record of commands executed here, and not a promise that every Enterprise Manager wizard generates exactly this script.

BACKUP DATABASE PLUS ARCHIVELOG
  TAG 'OEM_READINESS_TEST';
LIST BACKUP SUMMARY;

This example creates backups and requires adequate space and execution privileges. It deliberately contains no automatic deletion. Cleanup should be reviewed separately against retention, archived log policy, and recovery requirements. First establish that the configuration works and that the resulting files can be inspected.

After execution, examine job output, RMAN errors and warnings, backup scope, elapsed time, and recorded pieces. Check that the expected redo and control file protection are available. A successful submission only means the job was accepted; it does not establish successful execution. A completed backup still needs appropriate validation and recovery testing.

Step 8: Verify readiness and assign ownership

For example, suppose a team discovers a customer database and sees an Up indicator, but its first backup job cannot create a piece. The administrator checks the job output and finds a destination access failure. Changing the database monitoring account would address a different connection. The useful checks are the executing host account, its effective permissions, the selected channel destination, and the availability of the mount. After fixing the specific prerequisite, the team repeats the controlled test and records both the failure and the successful result. This provides reviewable evidence of configuration readiness without confusing monitoring health with backup access.

Prepare a concise handoff record for the next lesson. Include the target identity, execution environment, credential references, reviewed RMAN configuration, destination, catalog decision, and test-job result. Assign an owner for failure response and password rotation. Record how a missed backup is detected and who evaluates its effect on recovery coverage.

Use monitoring and incidents to help identify failures, but verify the notification rules rather than assuming every problem produces a ticket. Target blackouts concern monitoring behavior and should not be treated as a universal backup scheduling control. Review maintenance timing and the job's schedule separately.

Plan an isolated restore rehearsal appropriate to the recovery point and recovery time objectives. Confirm backup retrieval, key availability, redo coverage, and procedural access when the normal console or database host is unavailable. Protect the management platform and optional catalog through their own recovery plans. Application database backups do not automatically preserve OMS configuration or Enterprise Manager job information.

Troubleshoot the failed prerequisite

• Target Up, job fails: Compare job credentials with monitoring credentials, then inspect the RMAN error and execution environment.
• Destination inaccessible: Check the executing account, mount or ASM access, channel configuration, capacity, and supported backup module.
• Catalog failure: Test the actual RMAN connection, compatible schema, service, account, and registration state.
• Settings appear ignored: Compare persistent settings with explicit channel allocations and options in the reviewed job.
• Backup succeeds, recovery cannot proceed: Inspect missing pieces, archived redo, control file metadata, and required encryption keys.

The configuration is ready when these prerequisites are documented and tested through the intended execution path. The next lesson develops running RMAN jobs from Enterprise Manager and interpreting their results. Use the reviewed configuration as its starting point, then introduce recurring schedules only after the execution and recovery evidence supports them.