BEFORE YOU BEGIN
Check before you begin
This guide covers the inspected Linux SQL → Oracle / lin_oracle agent workflow. Instance identity, SID and DB unique name are distinct. RMAN, archive-log/PITR, RAC, Data Guard, PDB/CDB and TDE recovery were not validated end to end in this inspection; generic SQL or VM backup does not establish the same support.
Visual/acceptance limit: this guide is based on local Agent Policy and restore templates plus available technical documentation. The ongoing Firefox page-reading issue prevented new SQL Server/Oracle captures in this inspection; PostgreSQL or another engine’s screenshot was not substituted. No instance/policy was created and no backup/restore or log-finalization operation was executed. The installed release and end-to-end data acceptance require separate validation.
- Engine, agent/master releases and instance identity
- Database scope, method and access privileges
- Full base, log chain and repository access
- Isolated destination, collisions and application acceptance
011. Find the correct engine and database record
Find the Oracle job under Home → Backups → Backup List. Compare source host, instance/database, method and Last Backup. A Not Yet Backup entry is not a usable point. Do not treat a VM image or another SQL engine’s catalog as the same restore path.
Expected resultThe selection and relevant acceptance evidence are recorded.
022. Validate the point and dependent chain
In Action → Restore, open the correct instance/database and Full point. Where applicable, match differential/log/incremental pieces by method and time. All files required for the requested time and repository access must be available. Calendar selection alone is not PITR; automatic log replay or point-in-time recovery was not executed in this inspection.
Expected resultThe selection and relevant acceptance evidence are recorded.
033. Check destination options in the installed release
The inspected Oracle target template offers only Original Location and Instance selection; submission carries orig_oracle_instance. A new SID/database or different-host restore form was not verified. Do not test against the live source; validate an approved isolated instance and release-specific destination behavior with the technical team.
Expected resultThe selection and relevant acceptance evidence are recorded.
044. Prepare the isolated target and encryption dependencies
With the DBA, compare destination Oracle release, SID/DB unique name, ORACLE_HOME, control file/SPFILE, datafile paths and capacity. Where required, prepare wallet/TDE keys and archive-log chains through the secure recovery process. A generic instance form does not establish automatic RAC/Data Guard or CDB/PDB orchestration.
Expected resultThe selection and relevant acceptance evidence are recorded.
055. Review Summary and the final action
Compare source database, backup ID, method/time, selected instance and destination name. Stop for missing chains, conflicting names or unclear overwrite behavior. Execute final Restore only in a test plan with validated scope and data effects. No Restore was submitted while preparing this guide; a form preview is not proof of successful recovery.
Expected resultThe selection and relevant acceptance evidence are recorded.
066. Check engine state and recovery finalization
Compare EraBackup task results with the Oracle alert log, instance/database and datafile state. The DBA must manage MOUNT/OPEN, recovery and RESETLOGS decisions through a validated method; this guide does not provide generic ALTER DATABASE or RMAN commands. Inspect partial-restore state before writing to the same target again.
Expected resultThe selection and relevant acceptance evidence are recorded.
077. Document data and application acceptance
With the data owner, compare test queries, schema, sample rows, consistency and application connections. Record actual recovery time and data loss, releases, backup chain and destination identity. Separate standalone-database acceptance from cluster/HA failover acceptance. No production connection or DNS cutover was performed while preparing this guide.
Expected resultThe selection and relevant acceptance evidence are recorded.
COMMON QUESTIONS
Does a successful task mean the application is ready?
Not by itself. Engine integrity, required log chains, data queries and application access need separate validation; HA/topology acceptance is assessed separately.