A practical, repeatable recipe for turning OCI workload requirements into architecture options, measurable validation, and evidence-backed decisions.
Important clarification “OCI Workload Planner” is the title used for this blog and the approach described here. It is not a new OCI product, service, or separately deployed tool. The recipe shows customers how to recreate the planning and validation workflow themselves using OCI capabilities, documentation, SQL, AI assistance, APEX, and OCI Cloud Shell.
In 2024, I wrote Unimagined Disk Speed for Your Servers, to demonstrate what OCI compute and storage could deliver for demanding workloads. Alongside the performance story, I introduced OCI Plan & Proof: a framework for translating workload requirements into an architecture, generating a validation plan, and proving the result in a real OCI environment.
The idea was simple: move beyond sizing spreadsheets and theoretical performance calculations. Customers need a repeatable way to design, test, measure, compare, and explain infrastructure choices.
Since then, OCI has continued to evolve. Compute shapes, storage capabilities, limits, best practices, and workload patterns change. That creates a practical challenge: the planning method should evolve too.
The Challenge with static intelligence
Plan & Proof created value by capturing OCI workload expertise and turning it into repeatable guidance. The limitation was not the concept; it was the maintenance model. New compute shapes, changing performance characteristics, updated service limits, new deployment patterns, and changing customer requirements can all affect an architecture recommendation.
The answer is not to treat a recommendation as a permanent artifact. Instead, make the workflow repeatable: use current OCI documentation and pricing inputs, generate the analysis, validate the architecture in the customer tenancy, and preserve the evidence.
What this blog calls “OCI Workload Planner”
OCI Workload Planner represents the next evolution of OCI Plan & Proof.
The name describes the workflow, not a new service. The workflow combines the planning and proof ideas from the original Plan & Proof work into a recipe customers can rerun as OCI changes.
| 1 | 2 | 3 | 4 | 5 | 6 |
| PLAN | GENERATE | MEASURE | VALIDATE | PROVE | OPTIMIZE |
| Capture workload requirements, cost assumptions, and targets. | Use AI-assisted prompts to create SQL and validation assets. | Run the generated queries and collect OCI performance data. | Execute controlled fio benchmarks in OCI Cloud Shell. | Compare promised versus measured performance and report results. | Adjust shape, volumes, VPU, or throughput assumptions and repeat. |
Step 1 – Generate the analysis plan
Start with the workload requirements. The purpose of the first prompt is to ask an AI tool to generate Oracle 19c SQL that enumerates viable VM and BM combinations, using current OCI compute bandwidth, Block Volume performance characteristics, and pricing inputs.
WHAT THE QUERY SHOULD RETURN
- Total monthly price, compute price, storage capacity price, and storage VPU price.
- Compute shape, OCPU count, storage performance level, volume count, capacity per volume, and VPU.
- Instance IOPS and throughput, ordered from least expensive to most expensive.
KEY ASSUMPTIONS
- Use 730 hours per month and only shapes with available pricing.
- Use OCI Compute Shape “Max Network Bandwidth” and current Block Volume performance documentation as inputs.
- Do not cap IOPS by NIC bandwidth; cap promised throughput/IOPS for validation reporting where the compute shape network capability is the limiting factor.
- Use 1 MB block-size values for Block Volume maximum throughput.
- Treat Ultra High Performance as available only for VM/BM configurations with 16 or more OCPUs.
- Use bind variables and one plain SELECT with inline views; avoid CTEs, substitution variables, SQL*Plus commands, and APEX-hostile script constructs.
The goal is not to hard-code a single answer. The SQL should generate all viable combinations so the customer can compare price, shape, capacity, VPU, IOPS, and throughput.
PROMPT 1 – CONDENSED, REUSABLE VERSION
You are generating an Oracle Database 19c SQL statement for OCI workload planning.
Inputs: storage_capacity_gb, throughput_mbps_per_instance, iops_per_instance, volume_count, and percent_of_nic_throughput_capacity.
Use current OCI documentation for compute shape Max Network Bandwidth and Block Volume performance levels (Lower Cost, Balanced Performance, Higher Performance, Ultra High Performance), plus current Oracle Cloud pricing.
Return every viable VM and BM combination, including: total monthly price; compute shape; OCPUs; compute monthly price; storage performance level; number of volumes; capacity per volume; VPU; storage capacity monthly price; storage VPU monthly price; instance IOPS; instance throughput in MBps.
Order from lowest total monthly price to highest.
Constraints: 730 hours/month; use only shapes with pricing; IOPS is not capped by NIC bandwidth; use Block Volume max throughput values for 1 MB block size; Ultra High Performance only for VM/BM configurations with 16+ OCPUs; use minimum memory where needed; do not put OCPU count into the shape-name column; use bind variables; one plain Oracle SELECT with inline views only; no WITH clauses, substitution variables, SQL*Plus SET commands, or other APEX SQL Workshop script constructs.
Produce two scripts: oci_block_storage_VM_performance_query.sql and oci_block_storage_BM_performance_query.sql.
Step 2 – Run the generated SQL and build the comparison
Execute the generated VM and BM queries through Oracle APEX SQL Workshop using the configurable inputs. Export the results as CSV. The CSV becomes the planning baseline for the proof phase: it tells you which shape and storage combinations are worth testing and what performance and cost you expect before you deploy anything.
PLANNING INPUTS AND OUTPUTS
| Input | Example | Why it matters |
| Storage capacity | 1,024 GB | Defines the capacity/cost envelope. |
| Throughput / instance | 125 MBps | Target for architecture selection. |
| IOPS / instance | 25,000 | Target for storage performance selection. |
| Volume count | 1 | Lets the planner compare striping/scale-out options. |
| NIC utilization | 100% | Makes network limits visible in promised-throughput calculations. |
Step 3 – Generate the validation framework
The second prompt turns the selected architecture into a repeatable OCI Cloud Shell demonstration. The intent is to automate the full lifecycle: provision, attach, format, benchmark, evaluate, report, detach, and clean up.
THE VALIDATION RECIPE
- Create the required temporary resources, including a compute instance and block volumes.
- Attach up to 32 block volumes to one instance and span a single filesystem across them for the benchmark.
- Detect devices, prepare the filesystem, install fio, and run the configured tests.
- Measure IOPS, throughput, and latency, then compare results with promised targets.
- Generate CSV data, an HTML report, the “Promised by SLA vs. Measured on OCI” chart, optimization recommendations, and a management-ready summary.
- Clean up resources safely, retrying transient OCI state/conflict errors and waiting for dependent network resources to be released.
PROMPT 2 – CONDENSED, REUSABLE VERSION
Create a complete OCI Block Storage Performance demo that can be run from OCI Cloud Shell.
Automate the lifecycle: create temporary compute and block-volume resources; attach volumes; detect devices; format them before each benchmark; install fio; run tests; collect results; evaluate performance; create CSV + HTML reports; produce a management-ready summary; and clean up all resources safely.
Config inputs: compartment_ocid, region, compute_instance_shape, compute_instance_ocpu, compute_instance_memory, total_capacity_gb, volume_count (1..32), vpu_levels, and keep_on_failure. Default example values: VM.Standard.E5.Flex, 32 OCPUs, 256 GB memory, 3,000 GB total capacity, 2 volumes, VPU 120.
Run Oracle Linux 9. Use paravirtualized block-volume attachments and SR-IOV networking (networkType VFIO). Retry SSH readiness for up to 5 minutes, retry OCI 409/IncorrectState cleanup failures, avoid deleting resources already gone, and delete network resources in a safe dependency order.
Run six fio benchmarks sequentially: random read IOPS, random write IOPS, mixed random IOPS (60/40 read/write), read throughput, write throughput, and mixed read/write throughput. Use direct I/O, a 30-second ramp, 100-second runtime, group reporting, libaio, iodepth 128, 10G test files, 4K blocks for IOPS tests, and 1M blocks for throughput tests.
Run each benchmark with –numjobs equal to the configured OCPU count. Report IOPS, throughput, and latency. Limit the promised IOPS/throughput shown in the report by the OCI compute shape network capability where NIC bandwidth is the limiting factor. Explain this limitation in the documentation.
Produce: the demo package, usage documentation, customer expectations/guidance, a downloadable last-run ZIP, optimization advice for IOPS and throughput, benchmark-specific report sections, and a fix for the tarfile extraction warning associated with CVE-2007-4559 hardening.
Name the generated package oci-block-storage-performance-demo.zip and the last-run results package oci-block-storage-performance-demo-last-run.zip.
Step 4 – Execute the six performance tests
The benchmark matrix is intentionally simple enough to reproduce, but rich enough to expose the difference between a theoretical configuration and observed behavior. Keep the tests consistent so that VM/BM and VPU comparisons remain meaningful.
BENCHMARK MATRIX
| Test | Workload | Block size | Primary metrics |
| IOPS.read | randread | 4K | IOPS, latency |
| IOPS.write | randwrite | 4K | IOPS, latency |
| IOPS.read.and.write | randrw 60/40 | 4K | IOPS, latency |
| throughput.read | randread | 1M | MBps, latency |
| throughput.write | randwrite | 1M | MBps, latency |
| throughput.read.and.write | randrw 60/40 | 1M | MBps, latency |
Important test detail
Use –filename=<mounted filesystem> and –numjobs=<number of configured OCPUs>. Re-format the block volumes before each benchmark so previous test data does not bias the next run.
Step 5 – Report promised versus measured performance
The most important output is not a single benchmark number. It is the relationship between what the architecture was expected to deliver and what the OCI environment actually measured.
The report should separate the six benchmark configurations, show IOPS and throughput against their promised targets, and document latency. When a compute shape NIC becomes the throughput bottleneck, the report should make the limit explicit rather than presenting an unattainable storage-only target.
The proof point
“Promised by SLA vs. Measured on OCI” turns a sizing recommendation into evidence. It provides a concrete basis for deciding whether to keep the architecture, change the shape, add or resize volumes, adjust VPU, or repeat the test with different assumptions.
Step 6 – Optimize and repeat
The workflow is deliberately iterative. A customer can use the first run to identify the bottleneck, update the analysis inputs, regenerate options, and repeat the proof phase.
- If throughput is constrained, examine the compute shape NIC limit before increasing storage performance settings.
- If IOPS are below target, compare shape capacity, volume count, VPU, queue depth, and OCPU parallelism.
- If the cost is too high, use the generated SQL to compare alternative shapes and storage performance levels before deploying again.
- Use the measured results and latency profile to refine the next workload-specific test rather than relying on a generic benchmark result.
What customers can reproduce from this blog
The value of this approach is that it is a recipe, not a black box. A customer can take the prompts, replace the example inputs with workload-specific requirements, generate the SQL and automation, run the tests in a real OCI tenancy, and retain the resulting CSV/HTML/ZIP artifacts as evidence.
CUSTOMER CHECKLIST
| Phase | Customer action |
| Plan | Define storage capacity, throughput, IOPS, volume count, and acceptable NIC utilization. |
| Generate | Run Prompt 1 to create VM/BM SQL and enumerate architecture/cost options. |
| Select | Choose one or more candidate configurations from the ordered results. |
| Validate | Run Prompt 2 to generate the Cloud Shell demo and benchmark automation. |
| Measure | Execute the six fio tests and collect IOPS, throughput, and latency. |
| Prove | Review promised vs. measured results and document the limiting factor. |
| Optimize | Change the bottlenecked parameter and repeat. |
Looking forward
Cloud infrastructure continues to evolve, and with it the expectations placed on architecture planning. Success is no longer just selecting a compute shape or storage configuration. It is making an informed decision with current platform knowledge and a way to verify the outcome.
That is the role of the approach described in this blog: build on Plan & Proof, use AI assistance to accelerate the generation of planning and validation assets, run the proof in the customer environment, and carry the evidence into the next decision.
The future of workload planning is not just about predicting performance. It is about proving it.
Reference inputs used by the recipe
The original blog referenced OCI Compute shape documentation, Block Volume performance documentation, Oracle Cloud pricing, volume attachment guidance, and compute network launch-type guidance. Customers should use the current versions of those OCI pages when regenerating the SQL or automation because platform capabilities and pricing can change.
- https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm
- https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/blockvolumelowercost.htm
- https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/blockvolumebalancedperformance.htm
- https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/blockvolumehigherperformance.htm
- https://docs.oracle.com/en-us/iaas/Content/Block/Concepts/blockvolumeultrahighperformance.htm
- https://www.oracle.com/cloud/price-list/