# Oracle AI Database 26ai: Performance Tuning Basics

Oracle rebranded the flagship product this cycle (it's Oracle AI Database now, not just Oracle Database), and 26ai is the release that carries that name into GA (it landed for on-prem Linux x86-64 in the January 2026 quarterly release update). Underneath the AI branding, though, the performance tuning methodology DBAs have relied on for the last decade is still intact. If you've tuned 19c or 21c, you already know most of this. Here's what's the same, what's worth re-reading, and the one feature in 26ai that actually changes how I'd approach a specific class of contention problem.

## The methodology hasn't changed, and that's a good thing

Oracle's own guidance still starts in the same place: establish a baseline before you need one. That means capturing normal application throughput, response time, database stats, OS stats, and I/O and network numbers while things are healthy, not scrambling to figure out what "normal" looked like after a war room gets opened. The Automatic Workload Repository (AWR) is still the mechanism: periodic snapshots, with fixed or moving-window baselines built from ranges of those snapshots. None of this works without `STATISTICS_LEVEL` set to `TYPICAL` or `ALL`, so check that first if AWR data looks thin.

From there, the diagnostic chain is the one you already run:

* **ADDM** analyzes the AWR data and tries to hand you a root cause instead of a pile of numbers. It runs in database, instance, or partial mode, and can do real-time trigger-based analysis rather than waiting for the next snapshot window.
* **SQL Tuning Advisor** takes a specific statement and comes back with plan recommendations, SQL profiles, or index suggestions, without you touching the query text.
* **Wait event analysis** is still where most real answers live. `db file sequential read` vs `db file scattered read` vs `log file sync` vs latch or enqueue waits tells you what class of problem you're actually looking at before you start changing configuration.

The pitfall Oracle calls out explicitly, and the one I still see people trip on, is treating a symptom as the cause. Slow physical I/O might be a disk problem, or it might be a completely unindexed query hammering the disk. Latch contention is almost never fixed by touching instance parameters; it's an application design problem wearing a wait-event costume. The improvement loop is still: define the problem, check the host, check Oracle's own stats, make one change, measure again. Boring, but it's boring because it works.

## Where to actually look

Performance Hub is the current front end for all of this: ASH Analytics for session sampling, real-time and historical SQL monitoring with Gantt-chart timelines, graphical explain plans, blocking session views, and Exadata-specific stats if that's your hardware. If you're more of a "give me the V$ views" DBA, those haven't gone anywhere:

```sql
-- buffer cache sizing advice
SELECT * FROM v$db_cache_advice;

-- PGA memory stats
SELECT * FROM v$pgastat;

-- sort/hash work area usage
SELECT * FROM v$sql_workarea_histogram;
```

Memory tuning is still the same four buckets: SGA overall, buffer cache, shared pool/large pool, result cache, and PGA separately. Unless you have a specific reason to hand-size these, Automatic Memory Management or Automatic Shared Memory Management is still the right default. Most of the manual-sizing horror stories I've seen came from someone pinning values years ago and nobody revisiting them since.

## Where to actually start: a first-response checklist

All of the above is the toolkit. Here's the order I actually work in when someone says "the database is slow," before I touch AWR reports or advisors. This is the part I'd hand a newer DBA.

1. **Pin down what's actually slow.** One report, one screen, or everything? Since when? One user or everyone? "Slow" and "hung" are two different investigations, so confirm the transaction actually finishes before you start chasing a performance problem that's really a stuck one.

2. **Check the alert log before anything else.** Five minutes, tops. `tail` it for the time window in question and look for ORA errors, checkpoint messages, or space warnings. Nothing wastes more time than tuning around a problem the alert log already told you about.

3. **Look at who's active right now, or during the window if you have it.** This is the single fastest signal you can get on a live issue.

```sql
SELECT s.sid, s.serial#, s.username, s.status, s.event,
       s.wait_class, s.sql_id, s.blocking_session
FROM v$session s
WHERE s.status = 'ACTIVE'
AND s.username IS NOT NULL
ORDER BY s.logon_time;
```

4. **Rule out blocking before you rule in anything harder.** A blocking lock looks exactly like "the database is slow" from the application side, and it's usually the cheapest fix once you find it.

```sql
SELECT blocking_session, sid, serial#, wait_class, seconds_in_wait
FROM v$session
WHERE blocking_session IS NOT NULL;
```

5. **Pull the top wait events for the window.** Live, use `v$system_event` or `v$session_wait`. Historical, pull an AWR report bracketing the complaint window, or ASH if you need session-level detail across a narrower slice.

6. **Find the worst SQL by elapsed time, not by whoever's complaining loudest.** The query the user blames is often not the one actually eating the resources.

```sql
SELECT sql_id, elapsed_time/1e6 AS elapsed_sec, executions, buffer_gets
FROM v$sql
ORDER BY elapsed_time DESC
FETCH FIRST 10 ROWS ONLY;
```

7. **Only now reach for ADDM or SQL Tuning Advisor.** Once you know the shape of the problem (I/O bound, CPU bound, a lock, one bad statement), the heavier tools confirm why and hand you a fix, instead of you running ADDM cold and hoping it points somewhere useful.

Steps 1 through 6 take a few minutes apiece and usually narrow things down enough that you already know which advisor or report to pull, rather than starting with the big hammer and working backward.

## What's actually new: log buffer space redo prioritization

The one 26ai feature that changes real tuning behavior is **log buffer space redo prioritization**. The database now differentiates OLTP sessions from batch sessions and prioritizes redo log buffer allocation accordingly, so a heavy batch job generating a wall of redo doesn't starve latency-sensitive OLTP transactions of log buffer space. If you've ever had a nightly batch load quietly degrading interactive response time through log buffer contention, and had to work around it with job scheduling gymnastics instead of a real fix, this is aimed directly at that problem.

Everything else "AI" about 26ai lives outside classic instance tuning: Exadata for AI offloading vector search to storage, unified hybrid vector search blending vector predicates with relational/JSON/graph/spatial in a single query, and True Cache as an application-transparent mid-tier cache. Worth knowing if vector or RAG workloads are on your roadmap, but they're a different tuning conversation than buffer cache sizing and wait event chasing.

## Bottom line

If your AWR/ADDM/SQL Tuning Advisor workflow was solid on 19c, it carries forward to 26ai without much translation. The new redo prioritization feature is worth testing if you run mixed OLTP/batch workloads on the same instance. It's a real answer to a contention pattern that used to require workarounds. Beyond that, treat the AI-native features as additive capability for a different kind of workload, not a replacement for the fundamentals.