What you will learn
Backup-based duplication can create a test database without connecting to the source. You will build DEMOCLN from disk backups and inspect production dependencies. The old notes removed existing ASM files first; this example uses a new destination so failure does not require deleting the previous copy.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Use a single-instance 19c non-CDB training database. CDB/PDB duplication needs the corresponding multitenant procedure. On host2.sample.com prepare an unused +LABDATA ASM destination and stage datafile, control-file, and archived-log backups under /u02/backups/DEMO. Supply required encryption keys securely.
1. Prepare the auxiliary
Set ORACLE_SID=DEMOCLN on host2 and create a reviewed PFILE with db_name=DEMOCLN, db_unique_name=DEMOCLN, cluster_database=false, job_queue_processes=0, adequate memory, and db_create_file_dest=+LABDATA. Configure dedicated control-file and recovery destinations and valid audit directories. Block outbound production integrations.
STARTUP NOMOUNT PFILE='/u01/app/oracle/admin/DEMOCLN/pfile/initDEMOCLN.ora';
2. Duplicate from staged backups
rman auxiliary /
DUPLICATE DATABASE TO DEMOCLN
BACKUP LOCATION '/u02/backups/DEMO';
Run from the auxiliary host with the correct environment. This is the no-target, no-catalog form: DATABASE rather than TARGET DATABASE. Specify a recovery point if required and retain all redo needed to reach it. Do not use NOFILENAMECHECK as a generic fix for destination uncertainty.
3. Review the clone before release
SELECT name,dbid,db_unique_name,open_mode FROM v$database;
SELECT name FROM v$datafile;
SELECT name FROM v$tempfile;
SELECT name FROM dba_services;
SELECT owner,db_link,host FROM dba_db_links;
SELECT owner,job_name,enabled FROM dba_scheduler_jobs;
A normal duplicate gets a new DBID, unlike a standby. Review links, jobs, external credentials, directories, services, and endpoints. Mask sensitive data before broader access. Replace only identified production dependencies, rather than deleting every service.
4. Establish independent recovery
Read a known fixture at the backup boundary and verify schema objects, tempfiles, and recovery-area capacity. Configure clone-specific backups and catalog registration where applicable. Enable only reviewed lab jobs. Add RAC configuration only after a single-instance clone has passed its checks.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
Database name: DEMOCLN
DBID: different from source
Files: isolated destination only
Production integrations: blocked
Fixture comparison: passed
This is an illustrative acceptance record, not an RMAN transcript.
Verify the result
Confirm completed recovery, expected open mode, a different DBID, and data matching the recovery point. Test a clone backup and restore before relying on the environment.
Troubleshooting
Missing archived logs mean the requested boundary is not reachable with supplied media. Diagnose the backup set instead of forcing the clone open. Connection errors can reflect the wrong ORACLE_SID or auxiliary configuration.
Recovery and next steps
Keep the previous test environment until acceptance. Preserve failure logs and clean up only identified auxiliary resources for a retry. Never delete shared ASM directories to clear an ambiguous error.