After a data file is lost, recovery starts from a usable backup and the redo that records later changes. Turn the recovery targets into an inventory another operator can use after the database host is gone. This part inspects the environment. Creating the backup is the next part.
Oracle DBA Lesson 31A — What must survive a database failure?
Recovery targets
RPO (recovery point objective) is the acceptable data loss, usually stated as time. RTO (recovery time objective) is the maximum downtime for the business process. Count restore, database recovery, service access, and application checks. See Oracle 19c availability requirements.
Planning example used in the lesson:
| Input | Assumption |
|---|---|
| Failure | Database host and its local storage lost at 12:00 |
| Usable physical backup | Recovery chain anchored at 02:00 |
| Redo | Continuous usable redo from the backup through 11:55, stored independently |
| After 11:55 | No usable redo survives |
| RPO target | At most 15 minutes of potential loss |
| RTO target | Service usable within 2 hours |
Lost interval: 12:00 minus 11:55 is 5 minutes. That is inside a 15-minute RPO. The RTO deadline is 14:00. The timeline in the video shows event order, not a proportional clock. Oracle restores file contents from physical backups and applies the required redo. Keep the whole redo interval: the redo that makes an online backup consistent, and the later redo that reaches the target. See RMAN backup concepts.
What the inventory protects
| Dependency | Why it matters | Record, without secrets |
|---|---|---|
| Data-file backups | Starting physical contents | Database identity, backup time, storage location, operator |
| Required archived redo | Advances restored files to the target | Destinations, coverage, gaps, and independent copies |
| Control file and recovery records | Database structure and the RMAN repository | Locations and recovery copies |
| SPFILE or text PFILE | Startup settings | Which file is in use, location, and how it is protected |
| DBID | Identifies the database, including autobackup discovery | Exact DBID in records kept outside the database |
| Recovery catalog, when used | Extra RMAN metadata | Catalog identity, owner, and how the catalog itself is protected |
| Password file and network configuration | Access and connections on the recovered host | Locations, ownership, and the restore procedure |
| Encryption material, when required | Decrypts data or backups | Escrow location and the authorized custodian |
| Application dependencies | Usable service, not just an open database | External files and services, and who runs the application check |
RMAN backs up data files, control files, the server parameter file, and archived redo. Password files, network configuration, a text PFILE, Oracle software, external files, and a required keystore need their own copies. See files RMAN backs up. Record the DBID before an incident. See DBID and complete recovery.
Independent storage means the copy survives the failure you are planning for. Two directories on the same disk are one failure domain. Record the host, the storage system, and who can reach the copy. A path name alone does not prove independence.
Check readiness
Use a disposable Oracle 19c single-instance CDB on Linux. Connect to CDB$ROOT as an authorized administrator. Record the RU, edition, storage layout, and whether encryption is in use. Inspection only: no shutdown, no mode change, no backup, no restore, no delete. Keep credentials and key material out of the notes.
Confirm identity and container:
SHOW USER
SHOW CON_NAME
SELECT dbid, name, db_unique_name, log_mode, open_mode
FROM v$database;Record the DBID and both names. Confirm CDB$ROOT. LOG_MODE is the archiving mode. OPEN_MODE is how the database is open now. See V$DATABASE.
ARCHIVELOG supports an online backup plus the archived redo that backup needs. Check destinations for errors and a recent successful archive. NOARCHIVELOG needs a consistent closed backup: shut down cleanly, then mount, then back up. Recovery of that backup returns to the backup's state. See closed backups in NOARCHIVELOG.
Recovery storage and startup files:
SELECT name, space_limit, space_used, space_reclaimable
FROM v$recovery_file_dest;
SHOW PARAMETER control_files
SHOW PARAMETER spfileFRA numbers are bytes. SPACE_RECLAIMABLE is space Oracle can reclaim under its own rules. It is not a license to delete files by hand. An empty result means no fast recovery area is configured. Find the real archive and backup destinations. An empty spfile value means the instance started from a text PFILE. Record that file and where its copy lives. See V$RECOVERY_FILE_DEST and initialization parameters.
Archive destinations:
SELECT dest_id, status, destination, error,
archived_thread#, archived_seq#
FROM v$archive_dest_status
WHERE status <> 'INACTIVE';Record errors and the last archived sequence on the destination you depend on. ARCHIVELOG alone does not prove the redo chain is complete. See V$ARCHIVE_DEST_STATUS.
From the lab host, with the approved RMAN connection (OS authentication by the Oracle software owner):
rman target /At the RMAN prompt:
SHOW ALL;
REPORT SCHEMA;
EXITSHOW ALL is the persistent RMAN configuration: control-file autobackup, destinations, and retention. Defaults follow the configuration, so record what this database actually shows. REPORT SCHEMA lists registered permanent and temporary files and tablespaces. It does not create a backup. See SHOW and REPORT.
Write the inventory outside the database. For each row in the table, name the copy, the owner, and the next action if something is missing.
Pass criterion
Hand the inventory and a paper scenario to a second operator: the host is gone. They must name the database, the physical backups, the redo, the recovery metadata, the startup file, external access, encryption if it is in use, the owners, and the application check, without using the failed host. They should also say why restarting an instance whose files are still there is not the same as media recovery of lost files. No files are moved or deleted.
A nightly export does not recover a CDB after its files are lost. An export keeps logical objects. Physical recovery uses database backups and the required redo. See physical and logical backups.
Recap
Agree the acceptable loss and the downtime. Check log mode and archive health before you choose an online backup. Keep the physical files, recovery records, and external dependencies on storage that does not die with the host. Keep the inventory where you can read it after the failure.
No comments:
Post a Comment