Oracle Enterprise Manager Cloud Control gives database administrators a central place to organize targets, schedule maintenance, inspect job execution, and respond to incidents. For backup and recovery, its role is to coordinate Recovery Manager (RMAN). You choose a database, supply authorized credentials, review backup options, and schedule work through a browser. RMAN then performs the database operations using the configured channels and backup destinations.
This module introduces that management workflow for Oracle AI Database 26ai using Enterprise Manager 24ai Cloud Control. The database and management products have separate release numbers. Installing a 26ai database does not install or upgrade Cloud Control, and opening a management dashboard does not establish a working backup strategy. You need compatible management components, reachable targets, suitable privileges, usable storage, and a recovery plan that can be tested.
By the end of this lesson, you should be able to explain which components participate in an Enterprise Manager backup job and what must be checked before scheduling one. The following lessons develop the configuration, execution, strategy, and scheduling details. The aim is to make the graphical workflow understandable enough that you can examine its RMAN work and judge whether it protects the intended database.
Enterprise Manager coordinates RMAN
Cloud Control provides a graphical front end and scheduling facilities for RMAN. Oracle's Oracle 26ai backup and recovery introduction describes how job parameters and schedules lead to RMAN execution. The same underlying concepts apply whether you use a wizard or the RMAN command-line client: backup scope, backup sets or image copies, archived redo, channels, retention, and recovery metadata still matter.
For example, a wizard can help assemble a database backup, but it cannot decide the organization's acceptable data loss. A recurring schedule can submit work at a chosen interval, but storage capacity and job duration determine whether the work completes. A successful execution can demonstrate that a backup operation ran, while a recovery rehearsal demonstrates whether the available files and procedures can restore service within the required time.
Keep three layers of evidence separate. A schedule records intended future work. Job output records what an execution attempted and its result. Backup and recovery checks examine the material available for a restore. A DBA uses all three when deciding whether a database is protected. A green dashboard indicator is useful, but it does not replace inspection of backup coverage or a tested recovery procedure.
A browser console and a management platform
The older OEM version 2 description used a Java console and a simplified three-tier model. Current Cloud Control is administered through a browser, with management services, a repository, agents, and plug-ins working behind it. Oracle's Enterprise Manager architecture documentation describes these components. The table identifies their responsibilities in a backup workflow.
| Component | Responsibility | Planning question |
|---|---|---|
| Cloud Control console | Provides the browser interface for selecting targets, configuring work, and reviewing results. | Can the operator access the intended target and task? |
| Oracle Management Service (OMS) | Processes management requests and coordinates communication and job services. | Is the management service available and able to communicate with the execution environment? |
| Management Repository | Stores Enterprise Manager management information, including collected data and job information. | Is this repository independently protected and recoverable? |
| Management Agent and plug-ins | Support discovery, monitoring, and management operations for supported targets. | Are the deployment and plug-in versions suitable for this database and operation? |
| RMAN and target database | Perform database backup, restore, and recovery operations using database server sessions. | Do the selected scope, privileges, channels, and recovery files meet the plan? |
| Backup storage | Holds the backup payload and other required recovery files at configured destinations. | Can the recovery environment retrieve the files after a failure? |
The Management Repository is different from an RMAN recovery catalog. The former supports Enterprise Manager itself. A recovery catalog is an optional database schema used to maintain RMAN metadata beyond the target control file. Backup pieces belong in their configured backup destinations; neither a dashboard entry nor a repository record is a substitute for those files. Document each component's purpose so that an operator knows what must be restored after a failure.
Agent arrangements and availability designs vary. Enterprise Manager 24ai includes remote-agent capabilities, but that does not mean every database operation works through every remote arrangement. Validate the supported topology for the actual task. Similarly, multiple management services, load balancing, and repository protection require deliberate configuration; the architecture alone does not guarantee uninterrupted management.
Choose the correct product and target scope
Use the Cloud Control address supplied by your management administrator and sign in with your own Enterprise Manager account. Oracle documents the database selection path as Targets > Databases, followed by the target's Database Home page. Database operations may then require a separate database login or stored credentials. Access to the console and authorization to perform a database backup are distinct requirements.
Oracle Enterprise Manager Database Express, often called EM Express, is desupported in Oracle Database 26ai. Oracle lists this change in its 26ai desupport documentation. Instructions for an old local EM Express screen should therefore not be treated as current Cloud Control instructions. Establish which management product you are using before following a menu sequence.
For a container database, decide whether the job protects the whole CDB or selected pluggable databases. The Oracle 26ai database backup guide describes a Cloud Control PDB workflow under Availability > Backup & Recovery > Schedule Backup, with pluggable databases selected for a customized backup. A PDB selection is a deliberate scope choice, not proof that every other PDB is protected.
In a RAC or Data Guard environment, also identify the intended execution location, storage access, and database role. The target displayed in the console should agree with the database described in the recovery plan. Similar database names, cloned targets, or a changed host can make an apparently reasonable schedule operate on the wrong resource. Confirm identity before examining detailed backup options.
Establish credentials and connectivity
Separate the Enterprise Manager operator's permissions from the credentials used by the job. A console role controls what the operator can view and submit. Database credentials authorize database operations. Host credentials, where required by the workflow, authorize work in the host execution environment. Correct credentials at one layer do not automatically satisfy the others.
Named credentials let administrators manage credential use centrally, while preferred credentials can supply approved defaults for supported targets and tasks. Decide who may use or modify them, how they are maintained, and how a password or account change reaches recurring jobs. Avoid depending on a person's temporary login for a production schedule whose ownership must survive staffing changes.
Oracle's Enterprise Manager 24ai release-update notes identify preferred SYSBACKUP credentials for database instances as an RU7 feature. SYSBACKUP is a purpose-specific administrative privilege for backup and recovery; use it where the supported workflow and your access policy permit it. Check the installed release update and task requirements instead of prescribing SYSDBA for every operation.
Connectivity includes more than reaching the console in a browser. The management service, execution agent, database, and storage must communicate through the paths required by the selected topology. Confirm target monitoring health, credential tests, host access, and destination permissions before scheduling unattended work. If a prerequisite fails, resolve that specific failure rather than repeatedly submitting the same job.
Define protection before choosing a schedule
Begin with the recovery point objective (RPO), the acceptable amount of lost work, and the recovery time objective (RTO), the acceptable time to restore service. These objectives guide backup frequency, redo protection, storage choices, and recovery procedures. A daily backup may be adequate for one workload and insufficient for another. A fast backup also does not imply a fast restore.
For an online RMAN backup strategy, review ARCHIVELOG mode and the archived redo needed to recover the chosen backups. Identify where those logs are stored and when they can be removed. A datafile backup without the required recovery material may not reach the intended recovery point. Consider how a storage failure could affect the backup files and the archived redo together.
Choose full or incremental backups, destinations, retention policy, and validation work as parts of one plan. Retention expresses recovery requirements or redundancy; it should not be reduced to deleting files because their names look old. Coordinate cleanup with RMAN metadata and the recovery needs of all affected databases. A centrally scheduled job still needs adequate capacity and a storage lifecycle that preserves required files.
Include control file and server parameter file protection. Oracle documents control file autobackups and manual control file backup choices in the database backup guide. Review the configuration explicitly, including where an autobackup can be found during disaster recovery. Protect any credentials, encryption keys, and external dependencies needed to access the backup, according to the environment's recovery procedure.
Review, run, inspect, and test
A useful workflow starts with a reviewable proposal. Select the target, scope, destination, credentials, and timing, then inspect the available job summary and RMAN instructions before submission. Confirm that the proposal matches the recovery plan. Later lessons explain the configuration and wizard options in more detail; this introduction establishes the checks that should accompany them.
- Review the job: Confirm the database identity, selected files or PDBs, backup destination, and execution credentials.
- Choose execution timing: Account for maintenance windows, workload peaks, storage throughput, and other scheduled jobs.
- Inspect execution: Read the job status and RMAN output, including errors, warnings, completion times, and the actual backup scope.
- Inspect backup records: Confirm that expected backup pieces and archived redo are recorded and accessible through the intended recovery path.
- Validate and rehearse: Check backup usability and perform a controlled recovery exercise appropriate to the recovery objectives.
Consider a teaching example: a team wants to protect a customer PDB with an RPO of fifteen minutes and an RTO of two hours. These are planning assumptions, not measurements or Oracle defaults. A nightly database backup alone does not establish fifteen-minute data-loss protection. The team must design redo protection, measure retrieval and restore time, and determine what happens if the normal backup destination is unavailable.
The administrator first confirms the CDB and customer PDB identities, then reviews the proposed backup scope and credentials. After a controlled execution, the team examines RMAN output and the available backup records. It rehearses recovery in an isolated environment and compares the measured result with the two-hour objective. If retrieval is too slow or redo coverage is incomplete, the plan changes before the schedule is accepted as adequate protection.
This example also explains why job overlap matters. When a backup regularly takes longer than its repeat interval, investigate throughput and scheduling behavior before increasing frequency. Record the owner, notification route, and response procedure for a missed execution. The objective is a dependable recovery capability, with scheduling serving that objective.
Monitor centrally and protect the management system
Cloud Control can organize many databases into administrative groups, collect monitoring information, expose incidents, and coordinate recurring work. These capabilities help a team notice missed jobs or resource problems across an estate. Group membership and shared schedules should reflect meaningful operational responsibilities, while individual targets retain their own recovery requirements and execution evidence.
Broader diagnosis, tuning, patching, and fleet-management features remain useful Enterprise Manager capabilities, but they do not replace backup planning. Check the prerequisites and entitlements for each feature you use. Also read release-update notes at the feature level: the RU9 announcement of Oracle 26ai support for Fleet Maintenance and database cloning should not be interpreted as a universal minimum for every monitoring or backup operation.
A separate plan must protect Enterprise Manager itself. Oracle's management-system backup and recovery guide covers components such as the OMS, Management Repository, agents, and Software Library. Backing up an application database does not automatically preserve the console's configuration, job definitions, or management repository.
Prepare for recovery when the management interface is unavailable. Maintain an authorized procedure for locating recovery material and using the necessary tools without depending entirely on the dashboard. Document where the plan is stored, who can execute it, and how credentials and storage become available. Rehearse the management-system recovery procedure separately from the application's database recovery exercise.
The practical test of this architecture is whether an operator can explain a job from selection through recovery: which target was chosen, which credentials authorized it, where RMAN placed the files, which redo is required, and how the results were verified. Once those responsibilities are clear, Cloud Control becomes an effective way to coordinate repeatable backup work across many databases.