| Lesson 3 | Run RMAN from Enterprise Manager |
| Objective | Open Cloud Control and run a reviewed RMAN job against the intended Oracle 26ai target |
Run Oracle 26ai RMAN Jobs from Enterprise Manager 24ai
Oracle Enterprise Manager Cloud Control provides a browser interface for submitting and monitoring Recovery Manager (RMAN) work. To run a backup through Enterprise Manager, open the management console, select the intended database, review the operation and its credentials, and submit a job. RMAN performs the database work through the configured execution environment. The console then provides a place to examine the job's progress and results.
This lesson uses Enterprise Manager 24ai Cloud Control with Oracle AI Database 26ai. Cloud Control is a separate management deployment with its own services, repository, agents, and plug-ins. You do not start it by launching the historical OEM Java desktop console. The database's RMAN executable and the Cloud Control interface are related access paths with different responsibilities.
The objective is to follow one job from console access through execution evidence. The preceding lesson covered configuration prerequisites; this lesson uses those prerequisites to review and run a controlled operation. Recurring schedules come later. Establishing a successful one-time execution makes it easier to distinguish a scheduling problem from a connection, storage, or RMAN problem.
What changed from the legacy console procedure?
The old lesson described a desktop console, a fixed default administrator password, and a Navigator tree with a Backup Management menu. Those instructions belong to an earlier Enterprise Manager architecture. For current Cloud Control, obtain the organization's console address and use an authorized account. Follow the installed product's pages and help rather than assuming that a historical menu or password rule still applies.
Oracle Enterprise Manager Database Express (EM Express) is desupported in Oracle Database 26ai. This change does not desupport RMAN or the separately deployed Cloud Control product. Oracle documents the distinction in its 26ai desupport guide. Identify the management product before using instructions for a database home page.
Cloud Control provides a graphical front end and scheduling facilities for RMAN, as explained in Oracle's backup and recovery introduction. Opening a wizard prepares an operation; submitting it requests execution. A completed job supplies execution evidence. These are separate events, and none should be substituted for a tested recovery procedure.
1. Open Cloud Control and select the database
Use the console address provided by your Enterprise Manager administrator. Sign in with your own approved management account. From Targets > Databases, open the intended database's home page. Compare the displayed target identity with the protection plan before choosing a backup action. Similar names, cloned targets, and recently changed services can make a convenient selection the wrong selection.
Confirm the host, database identity, role, and container scope. For a whole-CDB operation, establish that the job targets the CDB and includes the intended files and PDBs. For a selected-PDB operation, verify the PDB selection explicitly. A dashboard showing a database as Up demonstrates monitoring visibility; it does not establish that an execution account can run RMAN or write backup files.
In RAC or Data Guard environments, review where execution will occur and how the selected role affects backup access and recovery metadata. The protection plan should explain the intended target and destination. Do not choose a different host or standby merely because the original target is inconvenient to reach; such a change can alter privileges, storage access, and operational assumptions.
2. Confirm the credentials used by the job
Console authorization and database authentication are different. Your Enterprise Manager account controls what you can view and submit. Database credentials authorize the target connection. Host credentials, where required, authorize work in the execution environment. The monitoring account that keeps the target dashboard healthy may differ from the account used by a backup job.
Use the named or preferred credentials approved for the target and task. Review any explicit credential choice in the job definition. A preferred credential is a convenience and policy mechanism, not proof that the submitted operation will use the expected account. Test the selected connection and verify the database privilege appropriate to the installed workflow.
Use backup-specific privileges where supported and required by your access policy. Do not assume every operation requires a shared super-administrator account. Keep credentials out of screenshots, command-line examples, and job descriptions. Follow the organization's current password and credential-management policies rather than the legacy eight-character restriction or a published default password.
If a connection fails, record the actual error and identify which connection failed. A console login failure, host execution failure, target database login failure, and recovery catalog login failure require different investigation. Repeatedly entering unrelated passwords can obscure the evidence without addressing the failing layer.
3. Open the backup workflow and choose its scope
Oracle's database backup guide documents Availability > Backup & Recovery > Schedule Backup from the Database Home page, including a customized backup workflow for selected PDBs. Use the available operation appropriate to your target. Screen details depend on the Enterprise Manager release update, database plug-in, target type, and permissions.
Choose a one-time execution for the initial test. Review whether the operation covers the whole database, selected PDBs, tablespaces, or another supported scope. The fact that an interface offers several choices does not make them interchangeable. A backup of one PDB may be useful while leaving other PDBs outside that operation's protection.
Before proceeding, review the destination, backup format, channels, compression, encryption where configured, and catalog connection if used. Confirm that the execution account can access the destination and that capacity is sufficient. For an online backup strategy, review ARCHIVELOG mode and the archived redo needed to recover the chosen datafile backups.
Do not treat the wizard's current defaults as a reviewed policy. A generated job can use persistent RMAN settings or explicit options that change their effect. For example, explicit channel allocation can override configured channel behavior. Read the proposed instructions and summary to understand the actual target, destination, and operation.
4. Review the proposed RMAN work
The historical five-item Backup Management menu is not a current specification of RMAN capabilities. Think instead in terms of tasks: create backups, inspect configuration and metadata, restore files, recover them, and maintain the backup environment. This lesson concentrates on reviewed execution and reporting. Restore and recovery require their own scope, prerequisites, and operational plan.
Compare the proposed backup with the recovery objective. Confirm that the selected operation produces the intended recovery material and that its destination is accessible after the failures you plan to survive. Review control file protection and any encryption-key dependency. A job that completes quickly but omits necessary files or redo does not provide the desired recovery capability.
The following reporting commands illustrate how an authorized RMAN session can inspect configuration and backup metadata. They do not create backups or delete files. The examples are instructional text, not output from a database used in this lesson.
SHOW ALL;
LIST BACKUP SUMMARY;
REPORT NEED BACKUP;SHOW ALL displays persistent configuration. LIST BACKUP SUMMARY summarizes recorded backups. REPORT NEED BACKUP evaluates backup needs using the applicable configured retention policy; ensure that the policy is meaningful before interpreting the report. These commands read repository information and cannot prove that every recorded backup remains accessible and usable.
For an authorized, properly configured ARCHIVELOG database, this fragment illustrates a tagged one-time backup:
BACKUP DATABASE PLUS ARCHIVELOG
TAG 'EM_ONE_TIME_TEST';This command creates backups and consumes resources. Review scope, channels, destination, credentials, and capacity before running it. The fragment is not a promise that every wizard generates identical instructions, and it contains no automatic deletion. Evaluate cleanup separately against retention, archived log policy, and the complete recovery plan.
5. Submit the job and inspect execution
After reviewing the proposal, submit the one-time job through the supported interface. Record its job identifier, target, selected scope, intended execution time, and owner. Use the job details to track progress. A submitted or scheduled status records acceptance or planned work; it does not mean RMAN has completed the backup.
When execution finishes, inspect both the final status and the available RMAN output. Check the actual start and finish times, connected target, channels, destination information, and any errors or warnings. Read enough context around an error to determine whether failure occurred before the target connection, during backup creation, or during a later action.
Compare the output with the reviewed scope. Confirm that the expected datafiles or PDBs and required archived redo were included. Inspect recorded backup pieces and their completion information. Save the relevant evidence where another operator can find it. A job name alone is not an adequate description of what happened.
If the job fails, determine whether any backup pieces were created before resubmitting. Correct the identified prerequisite and review the new proposal. Repeated submission can create overlapping work or consume additional storage, so distinguish a configuration failure from a transient event and coordinate the response with the job owner.
6. Verify backup coverage and recovery readiness
Keep the distinction between a request and its result visible in the handoff. A colleague reading the job record should be able to tell whether work is waiting to start, currently running, completed with the expected scope, or awaiting further investigation. Include the relevant output and destination references rather than a screenshot of the status icon alone. If the execution crossed a maintenance window or used a different host than expected, record that fact and assess its effect. This makes the evidence useful for both routine operations and a later recovery incident.
Successful execution is an intermediate result. Confirm that the expected files are recorded and accessible through the intended recovery path. Review redo coverage, control file protection, storage availability, and encryption-key access. Use appropriate RMAN validation and a controlled recovery exercise to test the material and procedure rather than relying solely on the console status.
For example, a team submits a backup of a customer PDB and sees a completed job. Before accepting the result, it checks the selected PDB identity, the actual backup records, and the required redo. It then rehearses retrieval and recovery in an isolated environment. If recovery cannot reach the required point or takes too long, the backup plan needs adjustment despite the completed job.
Keep the recovery point objective and recovery time objective separate. The first concerns acceptable lost work; the second concerns restoring service within an acceptable interval. Backup frequency, redo protection, storage retrieval, and recovery procedures all influence those outcomes. A one-time job provides evidence for planning a schedule, not a substitute for those objectives.
What RMAN connects to and records
The RMAN client interprets commands and directs database server sessions to perform backup and recovery work. The target database is the database being protected. RMAN maintains its repository metadata in the target control file and can also use a recovery catalog. The Enterprise Manager Management Repository holds management information, including job-related data; it is not the RMAN recovery catalog.
A recovery catalog is a separate schema for RMAN metadata and related capabilities. It can retain history beyond the control file, but its contents still need administration and protection. Avoid the blanket claim that catalog records persist forever. Check catalog requirements for the particular environment, especially when coordinating primary and standby databases.
The fast recovery area is a configured location for recovery-related files. Its location and size are controlled by DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE. It is not automatically an independent failure domain or an unlimited destination. Capacity, retention, and recovery dependencies still need review.
Other supported destinations can involve disk or SBT integrations. The execution environment must have the required access and backup module configuration. Backup payload remains at those destinations; neither a management job record nor catalog metadata recreates a missing backup piece. Protect the catalog and management platform through their own recovery plans.
Using the RMAN command-line client when appropriate
RMAN can also be started directly from an authorized operating-system environment. Oracle's RMAN client guide explains startup and connection choices. This is an alternative way to access RMAN, not a command for opening the Cloud Control browser console.
The following example assumes the correct Oracle environment and authorized local operating-system administrative authentication. It commonly connects with SYSDBA privileges by default; it should not be presented as a least-privilege connection that works for every host account. Select the connection method and supported client, target, and catalog combination appropriate to your environment.
rman TARGET /After connecting, an authorized operator can inspect configuration and metadata using reporting commands. To end the RMAN session, enter:
EXIT;Exiting the client does not shut down the target database. Likewise, closing a browser tab is not evidence that a submitted Enterprise Manager job stopped. If a running job needs intervention, inspect its current state and use the supported job controls and operational procedure.
Oracle 26ai recovery guidance and troubleshooting
Data Recovery Advisor is desupported in Oracle Database 26ai. This includes LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE. Do not carry those commands forward from an old repair tutorial. Supported RMAN reporting, validation, restore, and recovery procedures remain relevant, but they are not a replacement Data Recovery Advisor feature.
Investigate the failed layer using the actual error. If console access fails, check the management account and service. If the target is visible but the job cannot connect, review the selected execution and database credentials. If backup creation fails, inspect storage, channels, permissions, and capacity. If later recovery testing fails, inspect missing files, redo, metadata, and keys.
Finish with a reviewable job record: target identity, scope, job identifier, execution times, outcome, relevant output, backup records, and remaining recovery tests. The next lesson explains preparations for scheduling backups in Enterprise Manager. Carry this evidence into that step so that recurring work is based on a verified execution path.