Order management database: HA, reporting offload, and cost correction
Acme Ordering runs a customer order service on Oracle Database 19c in OCI. The primary is an 8 TB two-node RAC VM DB system in one availability domain; reporting queries run on the same database and cause latency spikes at month-end. The application vendor requires SYSDBA access for a legacy agent and cannot be certified on Autonomous Database. Business requires 99.95% availability, RPO 5 minutes, RTO 30 minutes for an AD failure, and read-only reporting must not affect order throughput. Current backups run nightly to local disk; monitoring is limited to CPU alarms; the monthly database bill grew 40% after storage was expanded to 20 TB but only 8 TB is used. The team has not tested failover and has no performance baseline. Licensing includes Oracle Active Data Guard.
1. Choose the database deployment and high-availability topology. Justify why Autonomous Database is not selected and how the design meets the AD-failure RTO and RPO.
Read the worked answer
Select OCI Base Database Service, not Autonomous Database, because the vendor requires SYSDBA access and OS-level access for a legacy agent, and the application is not certified on Autonomous Database. A two-node RAC VM DB system improves local availability within one AD, but RAC alone does not survive an AD failure. The AD-failure requirement therefore needs a Data Guard standby in a second availability domain, with broker-managed fast-start failover.
Use Active Data Guard so the standby is open read-only and can serve month-end reporting. That removes reporting from the primary and uses the license already owned. Configure redo transport for an RPO of 5 minutes or better. If cross-AD latency permits, Maximum Availability with SYNC gives zero data loss; otherwise FASTSYNC or async transport can meet 5 minutes, but the trade-off must be tested. RTO 30 minutes is achievable only if the standby is pre-provisioned, the broker is configured, application connection strings or DNS can be repointed quickly, and failover is rehearsed.
Do not claim 99.95 percent from RAC alone. The availability target depends on Data Guard, tested failover, backup restore validation, and application reconnect behavior. Autonomous Database would simplify patching and scaling, but it fails the vendor constraint, so it is not a valid option here.
2. Design the observability and reporting-offload solution. What would you measure, and how do you prove reporting no longer affects order throughput?
Read the worked answer
Use Active Data Guard on the standby for read-only reporting, with a separate reporting service name and resource manager plan so reports cannot consume all standby resources. Direct BI tools and month-end extracts to the standby, not the primary. Confirm that reporting connections use the read-only service and that no reporting job writes.
For observability, enable OCI Database Management and Operations Insights against the DB system using a private endpoint. Collect wait-event and SQL performance data, top SQL by elapsed time, ADDM-style findings, tablespace and storage growth, and Data Guard apply lag. In OCI Monitoring, alarm on primary CPU, redo transport lag, apply lag, tablespace usage, backup failures, and failover readiness. Send database and listener logs to OCI Logging, and instrument the order application with APM so database time can be correlated with user-facing latency.
To prove reporting is offloaded, establish a baseline: order transactions per second, p95 order latency, primary CPU, and wait events during month-end before the change. After moving reports, compare the same window. If primary latency still spikes, check for reports bypassing the standby, shared storage contention, or backup overlap. Also run a failover test and measure actual RTO and data loss; an untested Data Guard configuration is only a design intention.
3. The database bill is 40 percent higher after storage grew to 20 TB while only 8 TB is used. What cost actions are safe, and which are risky?
Read the worked answer
The safe actions start with visibility: tag the DB system and backups by application, environment, and cost center; enable budgets and cost reports; and identify whether the 20 TB includes unused volume, backup copies, or archive logs. Review backup retention and move long-term backups to Object Storage with lifecycle rules rather than keeping everything on local disk. Right-size the RAC nodes if CPU and memory are overprovisioned, using performance data rather than guesswork.
The risky action is assuming OCI Block Volume can be shrunk in place. Block volume and DB system storage are generally expanded, not reduced. Shrinking requires creating a new smaller DB system or volume, migrating with Data Guard or backup/restore, and cutting over. That is a project, not a console change. Do not delete the standby or backups to save money; they are required for the RTO and RPO.
A safer medium-term plan is to leave the current primary for the migration window, build the right-sized target, use Data Guard to migrate, validate performance, then decommission the old system. Keep Active Data Guard for reporting because it absorbs month-end load without adding a separate reporting database. Finally, set quotas and budget alarms so storage growth is reviewed before it reaches 20 TB again.