| Lesson 4 | Schedule a backup in Enterprise Manager |
| Objective | Describe the requirements to schedule a backup with an Enterprise Manager job. |
Schedule Oracle 26ai Backups with Enterprise Manager 24ai
A recurring backup job needs a verified database target, usable execution credentials, a reviewed RMAN operation, accessible backup storage, and a schedule that supports the recovery plan. Enterprise Manager 24ai Cloud Control coordinates the work for Oracle AI Database 26ai. RMAN performs the database backup through the configured execution environment. Before enabling recurrence, establish that the same operation can run successfully and that its output can support the intended recovery.
The previous lesson introduced submitting a one-time RMAN job. This lesson explains the requirements for scheduling that work reliably. A saved schedule, a completed execution, and a tested recovery are different milestones. Each provides evidence for the next. Treat a recurring job as an operational service with an owner, monitoring, capacity planning, and a procedure for handling missed runs.
1. Establish a supported management and execution environment
Use the organization's browser-based Enterprise Manager Cloud Control console. Confirm that the target database is discovered and that its identity, host, role, and container information are correct. A similarly named clone or standby can be an inappropriate target even when it appears healthy. Verify the installed Enterprise Manager release update, database plug-in, Management Agent, database release, and host platform against the applicable certification information.
Check the job execution method used by that deployment. In a conventional local-agent arrangement, the Management Agent on the database host starts the required work and reports its results through the management system. Other supported arrangements have their own requirements. Do not assume that monitoring visibility guarantees execution readiness. Establish that the selected environment can find the intended Oracle software, connect to the target, and access its backup destination.
Oracle Enterprise Manager Database Express is desupported in Oracle 26ai. Cloud Control is a separately deployed management product. The old desktop console, Schema Manager, Storage Manager, and Oracle8 Backup Wizard instructions do not describe the current workflow. Use the installed console's Help for its exact pages and available features. Check any licensing requirements for optional functionality rather than assuming that an old management-pack label grants access.
2. Define the recovery requirements before choosing times
The recovery point objective, or RPO, describes the acceptable amount of lost work. The recovery time objective, or RTO, describes the acceptable time to restore service. Those requirements determine how frequently data and redo need protection, how much history to retain, and how quickly backup material must be retrieved. Choosing a convenient nightly start time does not establish that either objective can be met.
Record the protected scope, expected backup size, required retention, and proposed recovery method. Decide whether the plan uses full backups, incremental backups, disk image copies, or a combination. A level 0 incremental provides the base for later incrementals; a full backup is not automatically that incremental base. Detailed strategy choices belong in the next lesson, but the scheduler needs a specific, reviewed operation rather than an undefined request to back up everything.
For example, a database with a short RPO may need archived redo protected much more frequently than its datafiles. A nightly datafile backup alone cannot meet that requirement. Likewise, a small backup can have an unacceptable recovery time if retrieving media, locating keys, reconstructing configuration, or applying redo takes too long. Base the schedule on measured backup and recovery behavior.
3. Separate the credentials and permissions
Enterprise Manager permissions determine who can access a target, create or edit a job, use credentials, and inspect results. Host credentials determine whether the execution account can start the required software and reach its resources. Database credentials determine whether RMAN can perform the selected operation. An optional recovery catalog uses its own connection and authorization. Review each boundary independently.
Oracle documents RMAN connections using the SYSBACKUP or SYSDBA privilege. Use an appropriately authorized account with the dedicated SYSBACKUP privilege when the chosen operation supports it. Granting that privilege does not require routinely using the built-in account of the same name. Avoid prescribing blanket administrative Enterprise Manager roles or routine use of SYS when narrower permissions meet the task.
Use the supported credential facilities for the deployment, including named credentials where appropriate. Check how a recurring job obtains credentials when the submitting administrator is absent. Test credential changes through the same execution path. Do not place passwords in lesson examples, job names, backup tags, or handoff notes. Where encryption or media access requires additional secrets, verify their availability during recovery as well as during backup.
4. Verify container scope, database state, and redo coverage
A whole multitenant container database, its root, selected pluggable databases, individual tablespaces, and datafiles are different backup scopes. Identify the intended CDB and PDBs explicitly. A backup of one PDB does not protect the entire CDB. Review any excluded tablespaces and unusual target types before describing an operation as complete protection.
For an online backup of an open database, establish that the database is in ARCHIVELOG mode and that the required archived redo is protected. A backup in NOARCHIVELOG mode requires a consistent database state and a different availability and recovery plan. A scheduling-prerequisites review should identify that difference before submission; it should not silently add shutdown operations to an otherwise online job.
Protect archived redo through a suitable CDB-level plan when scheduling selected-PDB backups. The ability to select a PDB in a wizard does not establish that every log needed for its recovery will be retained and accessible. Confirm the required log coverage, retention, and retrieval path. In RAC or Data Guard environments, review execution placement, database role, log access, and the backup metadata needed by the planned recovery procedure.
The following illustrative RMAN operation includes a database backup and archived redo. It changes the backup environment when executed and is not a command to run merely to check readiness. Its scope depends on the target connection and configuration:
BACKUP DATABASE PLUS ARCHIVELOG
TAG 'EM_SCHEDULED_BACKUP';Review the actual generated script rather than assuming that it matches this example. A bare BACKUP DATABASE does not, by itself, express the same archived-log inclusion. This lesson does not automatically run either command or delete any backup or log.
5. Review persistent RMAN settings and backup storage
Inspect the target's current RMAN configuration before approving the job. The read-only configuration report below shows persistent settings; it does not prove that credentials or storage work:
SHOW ALL;Compare the report with the submitted script. Commands can override persistent settings, while unspecified choices can use configured values or defaults. Review device type, channel allocation and parallelism, backup set or image-copy output, retention, control file and server parameter file protection, and encryption where applicable. A channel or compression setting that was suitable for an earlier workload may consume too much CPU, memory, network bandwidth, or storage I/O today.
For DISK backups, verify the chosen file system or ASM destination and any fast recovery area configuration. Check free capacity, expected growth, permissions, throughput, and access from the actual execution host. A destination visible in the administrator's browser is not necessarily writable by the job. A fast recovery area also serves other recovery-related files; size it for the combined demand rather than only one backup run.
For SBT backups, verify the required media-management or supported cloud module, channel parameters, service access, and restore procedure. Do not treat a generic cloud bucket as an ordinary disk path. Recovery may require libraries, credentials, networking, or media retrieval that are unavailable after the original host is lost. Test that dependency chain before accepting the destination.
Account for simultaneous operations and retained generations when estimating capacity. Repeated backups can exhaust storage even when each execution succeeds. Coordinate the retention policy and any separately approved cleanup work. Reporting a backup as obsolete and actually deleting it are distinct actions; a recurring backup schedule should not introduce deletion simply because space is becoming scarce.
6. Protect backup metadata and recovery dependencies
RMAN records backup information in the target control file and, when used, an external recovery catalog. The catalog is optional for many operations, but it can support the organization's metadata and recovery requirements. The Enterprise Manager management repository holds management and job information. It is not the RMAN recovery catalog and does not replace actual backup pieces or image copies.
Verify the plan for recovering the control file and server parameter file. Review control file autobackup settings and how the recovery team will locate the required material without relying on a functioning management console. Protect an optional catalog independently. Retain the database identity and configuration details needed to connect to the correct recovery environment.
Include encryption-key access, media-module installation information, and necessary host configuration in the recovery plan. RMAN protects database material within its supported scope; other host files require suitable protection. A backup record that exists only in a management interface cannot compensate for missing backup storage, unavailable keys, or an undocumented recovery dependency.
Prerequisites to check before enabling recurrence
| Requirement | Evidence to review |
|---|---|
| Correct supported target | Database identity, container scope, role, plug-in, agent, and execution placement. |
| Usable authorization | Target/job permissions and tested host, database, and optional catalog credentials. |
| Recoverable backup scope | Reviewed RMAN script, database state, required redo, and configuration protection. |
| Accessible sufficient storage | Destination access, capacity, channel settings, retrieval method, and key access. |
| Operationally suitable timing | Time zone, start time, repeat behavior, expected duration, and overlap handling. |
| Accountable monitoring | Job owner, notification route, missed-run checks, and recovery-test evidence. |
7. Coordinate timing, maintenance, and notifications
Specify the start time, time zone, recurrence, and any end condition. Establish how the installed scheduler handles daylight-saving changes and delayed executions. Compare the expected run duration with the repeat interval and with other work, including imports, batch updates, storage maintenance, and other backups. Recurrence alone does not guarantee that two executions cannot overlap.
Review the deployment's blackout and job behavior explicitly. A monitoring blackout should not be assumed to prevent every scheduled operation. Determine what happens when the execution agent, management service, target database, or destination is unavailable. Document whether work is skipped, delayed, or retried and how the owner detects a missed protection interval.
Assign an owner and a response route for failures, warnings, and absent executions. A completion notification is useful, but someone also needs to notice that an expected job never started. Check notification delivery and the on-call handoff. Changes to target role, credentials, storage, Oracle software, or maintenance windows should trigger review of the schedule and its recovery assumptions.
8. Review and submit the backup schedule
Oracle's documented Cloud Control path begins at the intended database's home page: Availability > Backup & Recovery > Schedule Backup. The console may request Named or New database credentials. Scope-specific options and the remaining wizard pages depend on the installed environment. Consult their Help rather than reusing historical desktop-console instructions.
- Confirm the database identity and the required CDB, root, PDB, or file selection.
- Select a supported suggested strategy if it fits the approved plan, or configure a customized backup with explicit scope and output choices.
- Review destination, channels, credentials, and the generated RMAN script, including any configuration overrides or cleanup actions.
- Set the reviewed timing and recurrence. Give the job a meaningful name and assign ownership and notifications.
- Submit only after resolving prerequisite failures, then inspect the saved definition and its next execution information.
An Oracle-suggested strategy is an available starting point when presented by the console. It does not eliminate the need to evaluate scope, capacity, redo protection, retention, and recovery time. A customized operation gives more control but also makes the operator responsible for understanding each choice. Preserve the final script and job definition so a colleague can explain what will run.
Perform a representative test before enabling a production recurrence. Verify full RMAN output, the actual destination, elapsed time, and the expected backup records. Resolve warnings instead of accepting a green status alone. If a representative test overruns the available window, adjust the plan or resources and repeat the relevant test before committing to repeated execution.
9. Validate the result and maintain recovery readiness
Inspect job history and the complete execution output after each important run. Confirm that the expected files and logs are protected, that backup records are available, and that destination access remains usable. RMAN LIST reports help identify recorded material; they do not themselves read every backup block or demonstrate a complete recovery.
Use appropriate RMAN validation to check files and backup material. For example, RESTORE ... VALIDATE examines the backups selected for a restore without restoring datafiles. Validation has resource costs and needs planned scope. It complements a controlled restore and recovery exercise, which also tests retrieval, keys, configuration, redo application, and the time needed to restore service.
Rehearse recovery in an isolated environment with clearly identified targets. Record the recovered point, elapsed time, dependencies, and any gaps. Review the schedule after material changes and as data grows. A reliable recurring backup plan combines appropriate timing with evidence that the resulting material can meet the business's recovery requirements.
Flashback Query, Flashback Table, and Flashback Database address different supported logical-error scenarios and have different prerequisites and retained-history requirements. They complement physical backup protection. Data Recovery Advisor is desupported in 26ai, and Oracle identifies no replacement feature for it. The validation and recovery-planning practices in the diagram should not be mistaken for a renamed advisor or automatic repair service.
Oracle documentation
- Backing Up the Database: backup scope, output choices, and Cloud Control scheduling.
- Configuring the RMAN Environment: persistent settings and recovery storage.
- Validating Database Files and Backups: validation methods and their purpose.
- 26ai Changes, Desupports, and Deprecations: Data Recovery Advisor and EM Express status.
- Flashback and Database Point-in-Time Recovery: supported logical-error recovery approaches.
The next lesson examines backup strategies and options, using these scheduling prerequisites as the foundation.