Oracle Exadata Cloud at Customer Optimization (Cost and Licensing)
Oracle Exadata Cloud@Customer (ExaC@C) provides the power of Exadata databases in an on-premises cloud model. While it delivers exceptional performance, it can also come with substantial costs if not managed well.
This article focuses on practical strategies to optimize cost and licensing for Exadata Cloud@Customer. These include tuning resource usage (OCPUs), managing services to avoid idle waste, choosing the right licensing mix (BYOL vs. included), and best practices for monitoring and compliance.
We’ll finish with an actionable checklist that database administrators (DBAs) and architects can use to ensure they get the most value from Exadata Cloud@Customer.
1. Right-Size OCPU Allocation
Oracle charges for Exadata Cloud@Customer compute usage by the OCPU hour, so one of the most effective cost optimizations is to right-size the number of OCPUs you have running:
- Start with the Minimum OCPUs: Each Exadata Cloud@Customer has a minimum OCPU requirement (typically 8 OCPUs per database VM as a minimum). Use that as a baseline for each database VM and only increase if needed. Don’t allocate more if you have a small workload because the system has capacity. Unused OCPUs still cost money if allocated.
- Scale OCPUs Based on Workload Patterns: Take advantage of the fact that OCPUs (or ECPUs on X8M/X9M/X10M generations) can be scaled up or down dynamically. For instance, if you have heavy batch processing at quarter-end, you might run 32 OCPUs during those days, but scale down to 16 OCPUs during normal days. Oracle’s billing is per-second after a short minimum, so you will save costs by reducing OCPUs during idle periods.
- Use Resource Manager and Instance Caging: Within the databases, use Oracle Resource Manager to prioritize critical workloads so you don’t feel the need to over-provision OCPUs “just in case.” If multiple databases share the Exadata instance, caging can limit each DB’s CPU usage to a certain count. This ensures one database doesn’t unexpectedly consume extra OCPUs that you then get billed for. It effectively caps usage where appropriate.
- Leverage Auto-Scaling (if available): Oracle’s Autonomous Database on Exadata Cloud@Customer supports auto-scaling of OCPUs (up to 3x when needed, by default). If using Autonomous, enable auto-scaling – it will add OCPUs during spikes and drop them after. You only pay for the extra OCPUs while they are used. On Exadata Cloud@Customer for user-managed databases, Oracle doesn’t have an “auto-scale” feature. Still, you can script something: e.g., a job that monitors CPU and adds OCPUs via API when usage is high and removes them when low.
2. Eliminate Idle Resources
Idle databases or services can silently accumulate costs. It’s important to stop or deallocate resources when they’re not in use:
- Shut Down Non-Prod Databases Off-Hours: For development, testing, or batch environments on Exadata Cloud@Customer, consider shutting those databases down during nights or weekends. When unnecessary, Oracle allows you to stop a DB VM or even the entire VM cluster. When an Exadata VM cluster is stopped (no databases up), the OCPU billing can be set to zero. For example, if a QA database is only used M-F, 9 am-5 pm, script it to start Monday morning and stop Friday night – you could save ~64% of that DB’s OCPU cost weekly.
- Use Minimum OCPUs when Idle: If you cannot shut down a database (maybe it must be online for occasional use), at least scale it down to at least 8 OCPUs when it’s mostly idle. Suppose a reporting database is only busy at the end of the month—run it at 2 OCPUs (if allowed) or 8 OCPUs for most days, then increase to the needed cores for the heavy days.
- Consolidate Low-Usage Databases: If you have multiple small databases, each on separate VM clusters on the Exadata, see if they can be consolidated to share OCPUs on one cluster. This way, the baseline 8 OCPU minimum applies to a bunch of databases collectively instead of each one. Oracle Exadata’s performance can handle mixed workloads, especially small ones. Fewer VM clusters = fewer mandatory minimum OCPU blocks.
- Delete Unused Environments: It sounds obvious, but the cloud makes it easy to spin up extra environments. Perform a monthly review of all databases on the Exadata Cloud@Customer. If some are no longer in use (that pilot project finished, or a proof-of-concept done), properly terminate them to stop all charges. Unlike on physical hardware, where an idle database sits, on Exadata C@C, an idle running DB still incurs at least the minimum OCPU billing. Housekeep aggressively.
Read Which Oracle Software Can You Run on Oracle Cloud at Customer?.
3. Optimize Storage and Backup Costs
While OCPU is a big part of the cost, storage can also contribute, especially if you over-provision expensive Exadata storage:
- Use Compression: Exadata supports advanced compression (HCC, Oracle Advanced Compression option). Compress data to reduce storage usage – this saves on $/TB-month costs and improves performance (less I/O). If you have the Advanced Compression license (or if using Autonomous, which includes it), ensure it’s enabled for large tables.
- Tier Older Data to Object Storage: Exadata Cloud@Customer allows integration with OCI Object Storage (which can also be part of your Cloud@Customer). Store older archive data or backups in Object Storage (at ~$25.50/TB-month for standard or even less for archive tier) rather than keeping everything on Exadata high-performance storage (which is more expensive). Identify data that can be offloaded – e.g., export infrequently accessed historical data to files and put in object storage, or use Database backup to Object Storage and then delete local copies.
- Manage Exadata Storage Allocation: Don’t allocate more Exadata disk group space than needed. If you have a lot of free space, note that you paid for that capacity in your infrastructure fee. For cost optimization, if you consistently only use 10% of the storage, maybe you subscribed to too large a configuration. At renewal time, consider a smaller storage configuration or a different Exadata base that fits your needs (or fill it with more workloads to get value).
- Backup and DR Licensing: If you maintain a Disaster Recovery standby on the Exadata Cloud@Customer, consider the licensing implications. A Data Guard standby that is open read-only may require licensing; if it’s purely idle apply, Oracle’s 10-day rule permits it without a full license. Ensure you configure DR appropriately to avoid double-paying for licenses. Possibly keep standby in mount mode except when needed, to avoid incurring extra licensing (and on the OCPU side, a mounted standby uses very few resources).
4. Use BYOL Wisely to Lower Costs
One of the biggest cost levers is whether you use Bring Your Own License (BYOL) or Oracle’s included licenses for the databases on Exadata Cloud@Customer:
- Maximize BYOL for Steady Workloads: If your company already owns Oracle Database licenses, use them on Exadata Cloud@Customer – the hourly rate for BYOL OCPUs is significantly lower (Oracle’s price list shows BYOL DB on Exadata is about 1/5 of the cost of license-included per hour). For long-running production databases, BYOL will save a lot. Make sure to count your licenses properly – e.g., if you enable 20 OCPUs on Exadata C@C, that would typically consume 10 processor licenses (20 OCPUs / 2 per license for Intel). Verify you have at least that many free licenses in your pool.
- Use License-Included for Short-Term or Burst: There are cases where license-included can be useful in Exadata Cloud@Customer. For example, if you want to spin up a temporary database for 2 months and you don’t have spare licenses, you can just pay the higher rate for those OCPUs for 2 months and then turn it off – effectively “renting” licenses short-term. Another case: you occasionally need extra OCPUs beyond your licenses (maybe end-of-quarter processing). Oracle allows mixing BYOL and license-included on the same Exadata Cloud@Customer by using separate databases or services. You could keep your base workload on BYOL OCPUs, and for the extra push, spin up an Autonomous Database (which is always license-included) or another CDB with license-included for just that period. Tip: Be careful to segregate these so you know what you’re paying for; Oracle’s billing will differentiate the BYOL vs included hours.
- Track Your License Utilization: It’s easy to lose track if you use BYOL licenses spread across on-prem and Cloud@Customer. Use Oracle LMS tools or third-party license management software to monitor how many licenses are allocated to the Exadata Cloud@Customer at any time. Compare that to your entitlement. If you decommission a cloud database using BYOL, note that those licenses can return to the pool for other use. It’s a good practice to maintain a simple spreadsheet or dashboard: “Licenses owned: X, Assigned to Prod ExaC@C: Y, Assigned to other: Z, remaining: …” This avoids accidental over-provisioning beyond your license count.
- Audit Your Feature Usage (BYOL): If you’re on BYOL, ensure you’re not inadvertently using Oracle options or packs you didn’t license. Exadata comes with many features (like In-Memory, RAC, etc.). If you did not license Database In-Memory on-prem and turn it on in the Cloud@Customer database under BYOL, you would be out of compliance (or you need to license that option separately). Oracle’s Autonomous DB service on Cloud@Customer includes all needed licenses, but for BYOL databases, the responsibility is yours. Use the Oracle DB feature usage tool (dba_feature_usage_statistics) to check if any extra-cost features are in use, and disable those if not licensed. This avoids a nasty surprise in an audit and indicates if license-included would be cheaper (for example, if you need an option for a short time, maybe switch that DB to license-included for that duration instead of buying a full license).
5. Monitor and Tune Performance (to Save Cost)
Optimizing cost isn’t just about turning things off – it’s also about making your databases run efficiently on fewer resources:
- Performance Tuning to Reduce OCPU Needs: Review AWR reports, SQL performance, and instance statistics regularly. High CPU usage could sometimes be cut by query optimization or adding an index. If you can reduce the CPU consumption of your workload by 20% through tuning, that directly translates to 20% lower OCPU hours needed (and 20% cost savings on the usage). Exadata has many performance features (Smart Scans, storage indexes, etc.); ensure your workloads are exploiting them. Often, proper partitioning or using Smart Scan-friendly queries can offload work to storage cells, reducing DB server CPU usage.
- Utilize Exadata Resource Management: Exadata isolates workloads via resource groups and IORM (for I/O). By containing certain workloads, you can avoid one workload causing you to scale up OCPUs for the whole system. For instance, limit a lower-priority reporting job to use at most two cores, so it doesn’t saturate all eight and force you to add more cores to handle interactive users. This way, you meet SLAs without brute-force adding OCPUs.
- Review Workload Scheduling: Perhaps batch jobs are running in prime hours, spiking usage (and thus costs if you had to allocate more OCPUs). See if they can be rescheduled to off-peak when other usage is low, so the overall peak concurrent OCPU requirement is lower. Flattening peaks means you can provision fewer total OCPUs.
- Keep Software Up-to-date: Oracle continuously improves performance through patches and new versions. Apply quarterly Exadata and database patches (as permitted by your change window)—sometimes, performance bug fixes can reduce CPU usage. Also, new features in 19c/21c may help performance (just ensure you’re licensed for any, for that matter).
Read Licensing Oracle Cloud at Customer vs Oracle OCI.
6. Manage Support and Renewals Smartly
In addition to runtime optimizations, look at your contracts and support costs:
- Revisit License Support When Shifting to Cloud: If you moved a lot of workloads to Exadata Cloud@Customer and are using license-included for them, you might have some on-prem licenses that are now unused. It could be possible to drop support on those unused licenses (to save yearly costs) or re-purpose them elsewhere. Be cautious: you don’t want to give up licenses you might need later, and Oracle doesn’t refund support easily. But at the next renewal, you could reduce your support footprint to only the licenses still in use (including BYOL usage).
- Leverage Oracle Account Team for Savings: Talk to Oracle about your Cloud@Customer usage. Sometimes they offer promotions or extra credits if you commit to using more services. For example, negotiating a higher Universal Credit commitment could also get you better rates for Exadata usage if you ramp up usage. Or if you’re considering moving something back on-prem (off cloud) due to cost, Oracle might provide additional discounts to retain the workload on Cloud@Customer.
- Consider Multi-Year and Bundling: If your initial Cloud@Customer term ends, you can negotiate a renewal that bundles in some benefits – e.g., additional cloud services or a slight infrastructure discount. Align this with your license strategy: maybe you can trade in some old licenses as part of a deal, etc. This is more of a procurement strategy, but it can significantly impact cost. The key is to plan early before renewal, assess if you need all your hardware and licenses, and then determine the right size for the next term.
- Third-Party Support (last resort): Some companies consider third-party support providers for Oracle to save costs. Be aware: if you go with third-party support for Oracle Database, you typically lose the right to upgrade and may void BYOL usage on Cloud@Customer (since Oracle requires active support for BYOL). And Oracle won’t allow third-party support to patch Exadata systems. So this route is usually incompatible with Cloud@Customer, which relies on Oracle’s support. It’s mentioned here mainly to note that Cloud@Customer essentially commits you to Oracle support – you should factor that in your cost calculations (which you likely did as part of license-included vs BYOL decisions).
7. Implement Robust Monitoring and Governance
To continuously optimize, you need visibility and policies:
- Enable Cloud Monitoring and Alerts: Oracle Cloud@Customer provides metrics (through OCI console or Enterprise Manager) on OCPU usage, storage utilization, etc. Set up alerts for when OCPU usage stays high for a sustained period, or when you approach a certain OCPU count. For instance, alert if average OCPU usage in the last 24h exceeds 80% of the current allocation, indicating you might soon need to scale up (or tune). Also, alert if usage is very low for a period, which might suggest an opportunity to scale down.
- Monthly Cost Reports: Even though Cloud@Customer is on-prem, the OCI control plane will generate usage and cost reports for the services (just like a regular OCI region). Review these reports every month. If possible, have a cost breakdown by database or department. Show teams their usage costs to encourage optimization. If one dev team left something on that incurred $X, make it visible—internal chargeback or at least awareness can drive behavior.
- Governance Policies: Establish policies for deploying new databases or workloads on Exadata C@C. For example, you may need an estimate of the needed OCPUs and licenses before provisioning to plan capacity and license allocation. You might say, “Any non-production database must be shut down when not in use” as a policy, and automation should be used to enforce it. Another policy could be “use BYOL unless there’s a clear reason to use license-included” to ensure cost efficiency. When deploying, this is a checklist item: Did we assign a license from our pool or intentionally decide to pay Oracle for this?
- License Compliance Checks: Schedule a quarterly internal license compliance check for your Exadata Cloud@Customer. This means verifying the number of OCPUs used vs. licenses, verifying option usage vs. what’s licensed, etc. Correcting the course quarter by quarter is easier than dealing with an audit after a year of drift. Cloud@Customer does not magically prevent compliance issues – Oracle can still audit and ask for details. Being proactive not only avoids financial risk but often reveals inefficiencies (like “oh, we left partitioning on for that DB but aren’t using it, let’s turn it off – and maybe we could downgrade that DB to Standard Edition if it doesn’t need EE features, moving it off Exadata to a cheaper platform” – such decisions come from knowing your usage).
Read Oracle Dedicated Region Cost Optimization..
Exadata Cloud@Customer Optimization Checklist
DBAs and architects can use this quick checklist to ensure they are optimizing cost and license usage on Exadata Cloud@Customer:
- ☑ OCPU Right-Sizing: Regularly review OCPU allocation vs. actual usage. Scale down any consistently underused OCPUs.
- ☑ Idle Shutdown Plan: Implement automated start/stop schedules for non-production databases. Verify that no dev/test system is left running 24/7 by default.
- ☑ BYOL License Tracking: Maintain an up-to-date inventory of Oracle Database licenses and track how many are assigned to Cloud@Customer. Ensure total OCPUs (for BYOL) don’t exceed what licenses can cover.
- ☑ License-Included Rationalization: For any database running license-included, document why (no available license, short-term need, specific option usage, etc.). Reevaluate periodically if that still makes sense.
- ☑ Feature Usage Auditing: Run Oracle’s feature usage reports and option usage scripts on all databases. Address any use of unlicensed features (license or disable them, or switch that DB to a license-included service that covers it).
- ☑ Performance Tuning Tasks: Continuously tune SQL and schemas to improve efficiency. Aim to keep CPU utilization in an optimal range so you’re not paying for wasted cycles. Check AWR for top CPU consumers and tune them.
- ☑ Compression & Tiering: Use compression on Exadata (HCC, etc.). Offload old data or large archives to cheaper storage tiers (object storage or less expensive databases) to minimize Exadata storage usage.
- ☑ Monitoring & Alerts: Enable OCPU utilization monitoring. Set up alerts for abnormal spikes or sustained low utilization. Also, monitor storage and IO to catch inefficiencies (e.g., compress a table that exploded in size).
- ☑ Regular Cost Reviews: Every month/quarter, review the Cloud@Customer usage costs (OCPU hours, storage, etc.). Identify the biggest cost centers and investigate if optimization is possible (e.g., one DB using 50% of OCPUs—can we tune it, or does it need those?).
- ☑ Compliance Review: Every quarter, conduct an internal “license audit” for Cloud@Customer: verify that support contracts are active for all BYOL licenses, verify that license counts match usage, and ensure that DR or test instances aren’t accidentally incurring extra license needs.
- ☑ Update Stakeholders: Communicate with application owners about the cost of their databases on the Exadata. Sometimes, simply making teams aware of the cost (especially chargeback) drives them to optimize queries or schedule jobs in a cost-friendly way.
- ☑ Plan for Growth: Use capacity planning to predict when you need more OCPUs or storage. If you foresee needing to burst, talk to Oracle – perhaps enable bursting via license-included for that period, or plan a hardware expansion. It’s better to schedule these than to reactively overspend or run out of capacity.
By following these strategies and checklist items, organizations can run Exadata Cloud@Customer at peak efficiency, gaining Exadata’s performance and availability benefits while keeping costs as low as possible and staying compliant with Oracle licensing.
The goal is to treat Cloud@Customer like a cloud (elastic, monitored, cost-tracked) and an on-prem investment (fully utilized, controlled, and justified). With diligent management, Exadata Cloud@Customer can be a cost-effective solution for critical workloads.
