Refreshable PDB Clone Lag and Source FRA Pressure
CDB PRODCDB runs 19c with 45 PDBs, local undo, and ARCHIVELOG enabled. PDB_APP is a 2.5 TB read/write PDB. A separate CDB, REPORTCDB, must host a near-real-time copy for reporting; the business accepts up to 30 minutes of lag. You create a database link PROD_LINK from REPORTCDB to PRODCDB and issue CREATE PLUGGABLE DATABASE PDB_APP_REP FROM PDB_APP@PROD_LINK REFRESH MODE EVERY 30 MINUTES. The source-side user is a common user with CREATE SESSION only. The clone is created, but the first scheduled refresh fails with an ORA-17500-series error. Meanwhile, archived redo generation on PRODCDB rises and its FRA, sized at 4 TB, reaches 90% within two days. The source PDB must remain read/write, and the clone must not lag more than 30 minutes.
1. What prerequisites and privileges would you verify before changing anything?
Read the worked answer
Verify the source PDB is in ARCHIVELOG mode and that the database link connects to the source CDB (not a PDB) as a common user with CREATE SESSION; for the initial remote clone, the source user also needs the privileges Oracle requires for cloning (typically CREATE PLUGGABLE DATABASE), and the local user needs CREATE PLUGGABLE DATABASE. Confirm the clone was created with a valid refresh mode (DBA_PDBS.REFRESH_MODE) and that its current open mode is read-only when not refreshing. Check DBA_DB_LINKS, V$PDBS, and the alert logs on both CDBs; ORA-17500 is an OCI/ASM wrapper, so read the accompanying error and the refresh history. Also confirm the source and target use compatible endianness/platform and that PDB_FILE_NAME_CONVERT/FILE_NAME_CONVERT is set correctly. Do not grant SYS unless a specific documented requirement exists.
2. Why is the source FRA filling, and what would you change?
Read the worked answer
A refreshable clone consumes archived redo from the source until the changes are applied. If the clone is slow or refreshes less often than redo is generated, the source must retain more archived logs, and the FRA grows. 2.5 TB of data plus a high redo rate can produce hundreds of GB per day. Check V$ARCHIVED_LOG retention and the refresh history on the clone. On the source, RMAN does not know about the clone, so the normal deletion policy may either delete logs too early or retain too many. Increase db_recovery_file_dest_size or move archives to a separate destination; monitor V$RECOVERY_AREA_USAGE. If the clone lags, increase network bandwidth, reduce refresh interval only if bandwidth allows, or use REFRESH MODE MANUAL and refresh during a window. Do not blindly set a shorter retention; the clone needs the logs.
3. Is a refreshable clone the right architecture here? What alternative would you propose?
Read the worked answer
A refreshable clone is designed for read-only reporting and periodic refresh, not for HA or strict 30-minute freshness at 2.5 TB scale. It adds redo apply overhead, depends on the source retaining logs, and can fall behind under network or apply pressure. For near-real-time reporting with a 30-minute lag and a read/write source, a physical standby with Active Data Guard is usually a better fit: it ships and applies redo continuously, supports read-only queries on the standby, and has mature monitoring and switchover. If the reporting workload needs a writable copy, use a separate ETL/CDC pipeline. If you keep the refreshable clone, document that it is not a DR solution, set lag alerts on the refresh history, and capacity-plan the source FRA for the worst-case lag.