After setting the scene in the previous articles detailing the various components of the Modern AI Development Stack with Oracle AI Database at the centre, let’s put this environment to good use. Here’s a reference to the posts added for your convenience:

• Oracle Agent Skills, MCP, and the Modern AI Development Stack
• Installing & Updating Oracle’s Agent Skills, the easy way

Coding agents are surprisingly good at analysing technical artefacts, not just writing software. In this article you can see how the Codex terminal app analyses two Automatic Workload Repository (AWR) reports from the same Oracle database running the same workload under different levels of load. And comes back with respectable findings!

More precisely, I ran 2 Swingbench benchmarks for roughly 15 minutes, first a baseline with moderate load and 16 sessions, then pushing it with 24 sessions.

Health & Safety First

Before using AI coding agents with database diagnostics or operational data, ensure your usage complies with your organisation’s security, privacy, and data governance policies. AWR reports can contain sensitive information, including database object names, SQL statements, host details, and workload characteristics that may be considered confidential.

Verify that the AI service you are using is approved for your environment, understand how prompts and uploaded content are handled, and sanitise or redact sensitive information where required. Oracle Agent Skills and similar tools can greatly improve productivity, but they should always be used within the security and compliance framework established by your organisation.

Prerequisites

I created a new directory and downloaded the AWR reports in HTML format. I already configured codex with chatgpt 5.5 and medium reasoning as well as codex. The SQLcl MCP server is configured, but won’t be needed just yet.

Refer to the earlier articles mentioned above for more details how to set these up.

Baseline

The first AWR report covers what you could call a “quiet” period. Here’s the annotated transcript of this chat. Rather than attempting to interpret the report using only its general reasoning abilities, codex automatically invoked the Oracle Agent Skills, giving it a workflow tailored to Oracle performance analysis. This is what it told me:

This is Oracle AWR analysis, so I’m using the local db skill briefly for its workflow guidance, then I’ll extract the comparable AWR sections.

To keep the length of this article manageable, parts of the conversation have been left out

User (that’s me 👋)

Review AWRReport_2026-06-24-08-09-01-+0000_2026-06-24-08-26-42-+0000.html and explain the database workload to me.

Assistant (here codex/chatgpt respond 🤖)

I reviewed AWRReport_2026-06-24-08-09-01-+0000_2026-06-24-08-26-42-+0000.html

Bottom Line

The database was running an SOE order-entry workload through JDBC against service nnnn_BLOGPOST_tp.adb.. The main activity was high-frequency order browsing and order creation, not a storage or locking incident.

Window: 2026-06-24 08:09:01 to 08:26:41 UTC, about 17.66 minutes. DB Time was 18.98 minutes, so average active sessions were only about 1.07. That is active, but not a saturated database by itself.

Main Activity

Most DB time came from CPU and commit waits:

• DB CPU: 803.6s, 70.6% of DB time.
• log file sync: 304.4s, 26.7% of DB time, from 131,930 waits at 2.31ms average.
• User I/O was small: only 1.4% of DB time, with sub-millisecond read waits.
• Concurrency and application waits were negligible.

This means the workload was CPU-heavy with many commits. The commit latency itself was not terrible, but there were many commits: 131,918 user commits, about 124.5 commits/sec.

This is a pretty solid summary, and it matches my observations performance hub and my understanding of Swingbench’s Order Entry benchmark. So far so good, the app seems to have run acceptably. Note this is an Oracle AI Autonomous Database 26ai, but the small, developer shape (4 EPUs).

Workload Shape

The workload was concentrated in package SOE.ORDERENTRY:

• orderentry.neworder: SQL ID 3n4tadqgd9b9r, 79,633 executions, 424.77s elapsed, 37.3% of DB time.
• orderentry.browseproducts: SQL ID 7yhuvsmwggtqn, 99,479 executions, 186.08s elapsed.
• Product lookup SQL 0y1prvxqc2ra9: 1,192,322 executions, 92.31s elapsed.
• INSERT INTO ORDER_ITEMS: SQL ID f7rxuxzt64k87, 244,071 executions.
• Product/category inventory lookup c13sma6rkr27c: 474,605 executions, flagged by ADDM for SQL tuning.

The top PL/SQL activity confirms this: SOE.ORDERENTRY.NEWORDER accounts for about 42% of sampled activity, and SOE.ORDERENTRY.BROWSEPRODUCTS about 13.45%.

I agree with the summary, it matches my observations gathered via Performance Hub and my understanding of Swingbench’s Order Entry benchmark. It’s good to see that, the app appears to have run acceptably. Note this is an Oracle AI Autonomous Database 26ai, but the small, developer shape (4 EPUs).

Interpretation

This looks like a Swingbench-style SOE workload or similar benchmark/app simulation: many short JDBC calls, lots of product browsing, many order inserts, and one commit per transaction. The main tuning levers would be application call volume, commit frequency, and the SQL inside SOE.ORDERENTRY.NEWORDER / BROWSEPRODUCTS, especially c13sma6rkr27c and 0y1prvxqc2ra9.

I would not chase storage first. The report points much more strongly to CPU plus high transaction/commit rate.

Again, a sound assessment. At this point the workload looks healthy, so let’s see what changes under heavier load.

Busy Period

After an encouraging first review, I took it a step further and ran more users with tighter think time. Here’s what codex told me.

User

Contrast this to AWRReport_2026-06-26-15-14-33-+0000_2026-06-26-15-30-15-+0000.html

Assistant

Compared with AWRReport_2026-06-24-08-09-01...html, the 2026-06-26 15:14..15:30 UTC report is the same workload running much harder.

Metric	Jun 24	Jun 26	Change
Elapsed	17.66 min	15.69 min	shorter sample
DB Time	18.98 min	62.01 min	3.3x higher
Avg active sessions	1.1	4.0	3.7x higher
DB CPU/sec	0.8	2.0	2.5x higher
Transactions/sec	124.5	382.0	3.1x higher
Executes/sec	3,771	11,590	3.1x higher
Redo/sec	799 KB	2.31 MB	2.9x higher
Logical reads/sec	67k	170k	2.5x higher

I really like this comparison table. Rather than focusing on individual wait events, Codex identified the change in workload characteristics between the two reports. Such a comparison is very helpful as it does some of the hard work for you. Remember this is a developer shape ADB-S instance, so 4 ECPUs, which explains the average active number of sessions (AAS) of 4. Everything over and above will be reigned in by resource management. The move from 16 to 24 sessions caused a massive increase in throughput, much larger than the 50% increase in workers suggests.

The biggest qualitative difference is resmgr:cpu quantum. On Jun 24 it was minor: 17.7s, 1.6% DB time. On Jun 26 it became a top wait: 987.6s, 26.5% DB time. That means the database was not just busier; foreground work was being throttled by Resource Manager / CPU scheduling.

Yes, that’s expected due to the maximum number of 4 ECPUs.

log file sync remains important in both reports. It scales almost exactly with throughput: 131,930 waits / 304s on Jun 24 versus 359,504 waits / 942s on Jun 26. Average wait only rises from 2.31ms to 2.62ms, so this looks more like many commits under higher TPS than a newly-bad redo device.

Nope, the underlying hardware is Exadata, which is anything but a slow platform.

Top SQL is also the same family: orderentry.neworde..., orderentry.browsep..., product lookups, and order/customer DML. The Jun 26 report mostly shows higher execution volume, not a different bad statement. Example: SQL ID 3n4tadqgd9b9r goes from 79,633 executions / 424.77s to 222,969 executions / 874.91s.

As a former OPS person I very much appreciate the increased throughput

Bottom line: Jun 24 is a lower-load CPU/commit workload. Jun 26 is the same workload at roughly 3x throughput, with CPU capacity/resource-manager throttling becoming co-equal with commit waits. IO is not the main story in either report.

Summary

You read about a performance story in this article, something we used to put together, pouring over a series of AWR reports back in the day. Using the Codex terminal application together with Oracle Agent Skills this has been greatly simplified and streamlined. What could have taken hours now takes a lot less time – provided of course that you have permission to share that data with an AI service.

The results of the analysis were good. Codex correctly identified the overall workload characteristics (even the load driver, Swingbench), highlighted the dominant CPU and commit activity, and recognised that the second benchmark represented the same workload running at significantly higher throughput. It also detected the impact of Database Resource Manager throttling as the database reached its CPU limits, while correctly concluding that storage performance was not the primary bottleneck.

If you have been granted permission to enlist help from coding agents, analysing AWR reports becomes a much easier task.