Choosing an Autonomous Database target when the DBAs depend on OS-level automation
A payments company runs Oracle Database 19c on a two-node RAC VM DB System with a physical standby in a second availability domain. Average load is 30% but quadruples for the four days around quarter close, when nightly batch also runs. The DBA team has three people and no Exadata experience. They depend on OS-level monitoring agents, custom shell scripts scheduled by cron, and wallet-based connections from 40 application servers. Leadership wants cross-region DR with RPO under 5 minutes and RTO under 30 minutes, and wants to stop patching operating systems. Budget approval requires the quarter-close peak to be handled without paying for it year-round.
1. Recommend Autonomous Transaction Processing Serverless, ATP Dedicated, or staying on Base Database Service. Justify against each constraint, and name the blocker you must clear first.
Read the worked answer
The blocker is the cron/agent dependency, not the database. Autonomous Database gives no OS access, no SYSDBA, and no way to install agents or run shell. That is exactly why it removes patching, but it also means the operational model must change before migration, not after.
Recommendation: ATP Serverless, conditional on two refactors.
- Refactor 1: convert cron-driven shell jobs to
DBMS_SCHEDULERjobs inside the database. Anything that shells out to the OS or reads files from the filesystem must be rewritten - identify these first, because they are the migration's real cost. - Refactor 2: replace host monitoring agents with database metrics plus OCI Monitoring alarms on the ADB resource. This is usually easier than teams expect.
- Elasticity: Serverless bills for provisioned ECPU with auto-scaling up to roughly three times the base, so you size for the 30% steady state and let quarter-close bursts scale out for four days. That directly satisfies the budget requirement; a fixed DB system sized for peak would not.
- Connections: 40 wallet-based clients work unchanged against a private endpoint in the VCN; keep TCPS and rotate the wallets centrally.
- Why not Dedicated: it solves isolation and compliance optics, not the elasticity or the OS access problem, and it carries a higher floor cost. Consider it only if a regulator requires dedicated infrastructure.
- Why not stay on Base Database Service: it preserves OS access but keeps RAC complexity and OS patching - the two things leadership asked to eliminate.
Check before committing: feature compatibility. Confirm the application does not use features unsupported on ADB, and run a schema conversion with Data Pump or OCI Database Migration before quoting dates.
2. How do you meet RPO under 5 minutes and RTO under 30 minutes across regions, and what is commonly missed when teams claim they have met it?
Read the worked answer
Replication. Use Autonomous Data Guard with the standby in the second region. Redo transport is asynchronous but typically seconds behind, comfortably inside a 5-minute RPO. Test the RPO by measuring apply lag during a quarter-close batch, not on an idle Tuesday.
The RTO is not a database problem. Failover itself completes in minutes. What breaks 30-minute targets is everything around it:
- Endpoint switching. The standby has its own private endpoint. Forty application servers must be pointed at it. Either put a load balancer / DNS name with a short TTL in front, or plan an automated connection-string update. A 3600-second TTL alone consumes an hour of your 30-minute budget.
- Network readiness in the DR region. The VCN, private endpoint subnet, route tables, service gateway and security rules must already exist and be tested - not created during an incident.
- Identity and secrets in the DR region. Policies, dynamic groups, wallets and vault keys must be reachable there. Teams routinely discover at failover time that a dynamic group rule references a compartment that does not exist in the DR region.
- Dependent services. If the payment app tier also fails over, its compute, images and load balancer configuration must be pre-staged.
Prove it, do not assert it. Run a planned switchover (the reversible operation) during a maintenance window, time each step from decision to first successful transaction, then switch back. Repeat quarterly. A DR plan that has never been executed is a hypothesis; the exam-relevant judgement is to treat the endpoint-switching step, not the database, as the risk.