Oracle load testing: service name, bind variables and query latency

Albiferro Yazılım ve Sistem Limited Şirketi (Albiferro Software & System Limited Company) · Published 1 November 2026

Detailed documentation →

On Oracle, latency under load usually comes from the few queries run most often and from the number of sessions. Sending the application's queries straight to the database with bind variables, realistic values and the target concurrency separates the bottleneck from the application. The general method is in the database load testing guide; this page covers the Oracle-specific part.

The Oracle connection

1. Click Connections → Add connection, pick Oracle as the Type and give it a name (e.g. orders-db).
2. Enter Host, Port (empty means 1521), Database / service, Username and Password. If you can, use a separate user with SELECT only on the tables you need; the password is stored encrypted and the test names only the connection.
3. Max open connections (per runner): 50 by default. Total connections ≈ number of runners × this value; set it so the database's connection limit is not exceeded.
4. Save, then Test. If the database can only be reached through a bastion, add an SSH tunnel to the connection.

A SQL step for Oracle

Write the query in Query as fixed text; give the values with the :1 placeholder under Parameters. Parameters can contain {{__VU}}, {{$randInt 1 100000}}, extracted variables or values from a CSV data file; templates cannot go inside the query text, so there is no SQL injection. In the Checks tab add e.g. Row count = 1, run one iteration with Try it to see the rows returned, then Save.

{"id": "ora", "name": "Oracle", "protocol": "sql", "connection": "oracle-db",
 "sql": {"query": "SELECT id, status FROM orders WHERE customer_id = :1 FETCH FIRST 10 ROWS ONLY", "params": ["{{__VU}}"]}}

A read's duration covers the wait for a pooled connection, the query and fetching every row. Rows go to checks and extraction as an array of JSON objects (such as $[0].status). Errors are told apart by kind: timeout, refused connection, permission, missing table, constraint violation, syntax and read-only violation.

Protecting the data

Spitfire works out whether a query reads or writes and counts anything it cannot recognise as a read as a write. Writes cannot be saved without an explicit approval on the step, and once approved the test asks for confirmation again every time it starts, recorded in the audit log (security statement).

This database has no read-only transaction; only Spitfire's statement check protects reads, and the SQL step's form shows a warning saying so. So give the connection a user that can only read.

Which queries to load?

Oracle's shared SQL statistics (V$SQL) tell which queries to load: they keep each query's execution count and elapsed time. The few queries run most often and taking the most time in total are the test's skeleton.

Instead of writing the queries by hand, you can have them suggested from the database's own schema (installation admins; query suggestions from the schema). The privileges needed on Oracle: CREATE SESSION, SELECT on the application schema's tables and SELECT_CATALOG_ROLE. Every suggestion is checked with EXPLAIN PLAN: only the plan is fetched, the query never runs; every suggestion has a row limit (FETCH FIRST).

Then pick the load model: a steady load at the expected concurrency, or a stepped breaking point test to find the limit. Read the results with p95 and p99, not the average.

Common errors

• ORA-12514: listener does not currently know of service: the service name is wrong. Write the service name, not the SID, in Database / service (e.g. FREEPDB1).
• ORA-01017: the username or password is wrong, or the user has no access. Type the password again and save.
• Connection limit errors: the number of runners × Max open connections (per runner) is more sessions than the database accepts; lower the value or raise the limit.

Frequently asked questions