Regional Health Insurer: Splitting a Mixed Estate Around One Inflexible Vendor
A regional health insurer runs 60 Oracle databases. One is a claims adjudication package from a vendor certified only on Oracle 19c; the support contract requires SYSDBA access, custom OS packages installed on the database host, and a set of initialisation parameters that must not change. The other 45 are reporting schemas, mostly read-only, totalling 8 TB. Compliance requires seven years of backup retention, a cross-region standby with an RPO under 15 minutes for the claims database, TDE with customer-managed keys, and a full audit trail of privileged actions delivered to a SIEM. The security team will not approve any service where Oracle or the cloud provider holds the encryption keys. The DBA team has four people and wants to cut the patching burden wherever it is allowed. Budget covers one architecture review, so the recommendation must be defensible per database rather than a blanket move to Autonomous.
1. Where does the claims adjudication database belong, and why is Autonomous Database excluded?
Read the worked answer
Base Database Service (VM DB System) or Exadata Database Service - not Autonomous. The vendor contract is the binding constraint:
- It requires SYSDBA and OS-level access on the database host. Autonomous Database removes both by design; there is no host.
- It requires custom OS packages. Managed Autonomous patching cycles cannot accommodate a vendor-supplied package on the vendor's schedule.
- It pins initialisation parameters. Autonomous exposes a limited parameter surface and reverts unsupported changes.
Base Database Service gives a co-managed VM where the customer keeps SYSDBA, installs packages and sets parameters, while Oracle handles infrastructure. Choose Exadata Database Service on dedicated infrastructure if the vendor later certifies RAC or smart scan and claims volume needs it; otherwise a VM DB System is cheaper and sufficient.
The argument to defend in the review is that 'Autonomous is better' is not an architecture argument when a support contract forbids it. Document the constraint and set a review trigger for the vendor's next certification.
2. The 45 reporting schemas total 8 TB. What is the target, and how do you meet seven-year retention?
Read the worked answer
Consolidate onto Autonomous Data Warehouse, serverless. Read-only reporting is the workload ADW is built for, it removes patching for 45 databases from a four-person team, and it supports customer-managed TDE keys in OCI Vault - which satisfies the rule that neither Oracle nor the provider holds keys.
Retention is the gap. ADW's automatic backups have a bounded window of up to 60 days, nowhere near seven years. The compliant design is:
- Keep automatic backups for operational recovery.
- Export a monthly, encrypted, immutable copy of each schema with Data Pump to an Object Storage bucket with versioning and a retention rule so it cannot be deleted early.
- Lifecycle those exports to Archive tier after the first year; a restore for an audit becomes a planned, hours-long operation, which is acceptable for seven-year-old reporting data.
- Store the Data Pump encryption keys separately in OCI Vault, and rehearse one full restore before decommissioning the source.
Do not build 45 ADW instances. Consolidate into two or three buckets by data classification and consumer group so cost and patching stay bounded.
3. Design DR and privileged-access auditing across the two platforms.
Read the worked answer
DR. The claims database needs an RPO under 15 minutes on a service you control. Use Data Guard with Maximum Availability and fast-start failover to a cross-region standby on the same co-managed service. Because co-managed means you own the configuration, automate broker setup and alert on transport lag measured against the 15-minute RPO rather than on a green status icon. For the ADW reporting estate, Autonomous Data Guard to a cross-region standby covers the requirement with minimal configuration, and the export path covers the seven-year tail.
Auditing. A full trail of privileged actions delivered to a SIEM is a pipeline, not a database checkbox:
- Enable Unified Auditing on the claims database and capture SYSDBA/SYSOPER activity. With OS access in play, local OS authentication must be audited too, or the vendor's own logins vanish from the trail.
- Consider Database Vault so vendor DBAs cannot read insurer data and separation of duties is demonstrable.
- Ship the unified audit trail to OCI Logging and forward it to the SIEM, writing records outside the database so a compromise cannot erase the evidence.
Finally, verify the customer-managed key claim end to end: backups, the standby and the audit export must all be encrypted under the customer's Vault key, or the security approval rests on a false premise.