Vector Search Changes the RAC Resource Model
Oracle AI Database 26ai brings vector search into the same transactional platform that already holds relational business data, but an HNSW index behaves differently from a conventional B-tree. A Hierarchical Navigable Small World graph is primarily an in-memory search structure hosted in the Vector Memory Pool, with supporting metadata, journals, and checkpoints on disk. Its capacity, startup behavior, and failure characteristics therefore depend on SGA memory, storage throughput, RAC topology, and the application’s tolerance for approximate results. Treating it as merely another index type produces unpleasant surprises during node restarts, rapid data ingestion, or workload failover.
The first architectural decision is whether approximate search is acceptable for the business operation. HNSW trades exactness for much lower search cost, so its service-level objective must include achieved recall or accuracy as well as latency. A recommendation system can usually tolerate a small difference in the top results; a regulatory matching process may require an exact search or a second-stage exact evaluation. The database can guarantee transactional visibility without guaranteeing that an approximate algorithm returns exactly the same top-K set as a full scan. Application owners must understand that distinction before infrastructure engineers size the platform.
Define the Data and Distance Contract
A production schema should constrain vector dimensions and element format instead of accepting arbitrary vectors. Fixed definitions reject incompatible embeddings early and make capacity planning more deterministic. The distance metric is also part of the application contract: cosine, Euclidean, and dot-product searches are not interchangeable, and the optimizer can only use a vector index when the query metric is compatible with the index definition. Changing embedding models may alter dimensions, normalization assumptions, or semantic behavior even when the SQL remains valid.
CREATE TABLE document_chunks (
chunk_id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
tenant_id NUMBER NOT NULL,
document_id NUMBER NOT NULL,
embedding_ver NUMBER NOT NULL,
chunk_text CLOB NOT NULL,
embedding VECTOR(1536, FLOAT32) NOT NULL,
created_at TIMESTAMP DEFAULT SYSTIMESTAMP NOT NULL
);
CREATE INDEX document_chunks_tenant_ix
ON document_chunks (tenant_id, embedding_ver);Embedding versions should remain explicit. Mixing vectors produced by different models in one similarity population can return syntactically correct but semantically meaningless results. A controlled migration normally writes the new representation alongside the old one, validates result quality, moves application traffic, and only then retires the previous index. Replacing vectors in place eliminates rollback evidence and can create a long period in which old query vectors are compared with new document embeddings.
Choose HNSW Parameters from Measured Workloads
An HNSW index is appropriate when low-latency top-K search justifies keeping a graph in memory. Higher target accuracy and more graph neighbors generally increase memory, build cost, and search work. EFCONSTRUCTION affects graph quality and index creation cost; it should not be increased merely because a larger number looks safer. The correct settings come from representative embeddings and real query vectors, including difficult queries near semantic boundaries, rather than a small demonstration dataset.
CREATE VECTOR INDEX document_chunks_hnsw_ix
ON document_chunks (embedding)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95
PARAMETERS (
TYPE HNSW,
NEIGHBORS 32,
EFCONSTRUCTION 300
)
ONLINE;Online creation is valuable for a table receiving concurrent DML, although a high modification rate can extend the build and increase resource pressure. Engineers should test index creation with production-like ingestion rather than validating it only on a static clone. Parallel DML is not supported for HNSW indexes, which can invalidate assumptions in bulk-loading pipelines. A deployment runbook must therefore define whether ingestion will use conventional DML, pause temporarily, or load into a staging structure before a controlled merge.
The query must explicitly request approximate row limiting if an index-assisted approximate search is intended. It must also use the same distance metric and a compatible expression. An execution plan should be captured during release testing because a legal query can silently use an exact, no-index plan when its shape or metric prevents vector index access.
SELECT chunk_id,
document_id,
VECTOR_DISTANCE(embedding, :query_vector, COSINE) AS distance
FROM document_chunks
WHERE tenant_id = :tenant_id
AND embedding_ver = :embedding_ver
ORDER BY VECTOR_DISTANCE(embedding, :query_vector, COSINE)
FETCH APPROX FIRST 20 ROWS ONLY;Engineer the Vector Memory Pool as a Capacity Boundary
The Vector Memory Pool is part of the database memory architecture, not free host memory waiting to be consumed. At the CDB level, VECTOR_MEMORY_SIZE establishes the pool size; at the PDB level it can limit that PDB’s usage. Increasing it without revisiting SGA_TARGET, huge pages, operating-system memory, and co-located workloads merely moves the failure elsewhere. On consolidated systems, a vector-enabled PDB should have an explicit quota so one index build cannot consume capacity expected by unrelated databases.
ALTER SYSTEM SET vector_memory_size = 24G SCOPE=BOTH;
ALTER SYSTEM SET vector_memory_size = 8G CONTAINER=CURRENT;
SELECT pool,
ROUND(alloc_bytes / 1024 / 1024) AS allocated_mb,
ROUND(used_bytes / 1024 / 1024) AS used_mb
FROM v$vector_memory_pool;Use DBMS_VECTOR.INDEX_VECTOR_MEMORY_ADVISOR before committing the production SGA design, but regard its result as an index estimate rather than complete host sizing. Allow headroom for journals, graph reloads, simultaneous builds, growth, and ordinary database memory demand. Capacity tests should include the maximum expected vector count, dimensions, datatype, index parameters, and RAC placement. Alerting only on host free memory is insufficient; operators need Vector Memory Pool utilization, allocation failures, index state, SGA resizing activity, swap usage, and query latency by plan.
Duplicate or Distribute the Graph on RAC
RAC introduces a deliberate tradeoff between resilience and memory efficiency. With duplicated HNSW, each participating instance maintains a complete graph. Search can remain local and the loss of one instance leaves another full copy, but every instance must provide enough Vector Memory Pool capacity for the entire index. This design is attractive for moderate indexes where predictable failover matters more than memory efficiency.
A distributed HNSW index divides graph slices across instances and merges partial results. It allows the usable vector memory to scale across the cluster and avoids storing the complete graph everywhere. The cost is a stronger dependency on cluster membership and inter-instance work. If an instance holding slices fails, Oracle disables the affected index until slices are reassigned or rebuilt; queries can temporarily fall back to a no-index plan. That preserves correctness, but an exact scan over millions of high-dimensional vectors can turn a node failure into a database-wide CPU and latency event.
CREATE VECTOR INDEX document_chunks_dist_hnsw_ix
ON document_chunks (embedding)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95
PARAMETERS (TYPE HNSW, NEIGHBORS 32, EFCONSTRUCTION 300)
DISTRIBUTE BY ROWID RANGE;Distributed deployment is therefore not automatically the highly available choice. Services must be placed only on instances that participate in the intended vector topology, and every surviving-node scenario must have enough memory to host redistributed slices. If the reduced cluster cannot accommodate them, a rebuild may be required. Test instance eviction under load while observing fallback plans, CPU saturation, cluster traffic, graph redistribution, and recovery time. Traditional RAC validation that stops when the service reconnects is incomplete for this workload.
Account for DML, Persistence, and Restart Recovery
Current Oracle 26ai HNSW transaction support uses private and shared journal structures to reconcile base-table changes with the in-memory graph and provide transactionally consistent query results. This matters because a graph built at one point in time cannot simply ignore later inserts, updates, and deletes. High ingestion or vector-replacement rates can increase journal pressure and eventually drive graph refresh work, so a read-heavy catalog and a continuously rewritten event stream should not inherit the same index design without testing.
HNSW persistence also does not make the graph equivalent to a disk-resident B-tree. Disk checkpoints accelerate reload after an instance restart, while the VECTOR_INDEX_NEIGHBOR_GRAPH_RELOAD parameter controls automatic reload behavior and defaults to RESTART. A recent valid checkpoint enables faster restoration; without one, Oracle may need duplication or reconstruction. Checkpoint storage must consequently deliver adequate throughput during cluster recovery, exactly when other database components may also be reading heavily from shared storage.
Patch testing should measure the interval from instance availability to vector-index availability, not merely database open time. Verify plans immediately after startup and again after graph reload completes. In RAC, also inspect vector index instance mapping and graph checkpoint diagnostics available for the deployed service, because an index reported in the data dictionary does not prove that every required graph is resident and usable on every target instance.
Measure Recall and Protect the Application
Latency without accuracy is an incomplete vector-search metric. Oracle can capture sampled query vectors when VECTOR_QUERY_CAPTURE is enabled and can compare approximate results with exact searches through DBMS_VECTOR accuracy reporting. Run this against production-shaped query populations after model changes, substantial data growth, parameter changes, and index rebuilds. The workload must include tenant filters and actual top-K values because recall observed with synthetic vectors may not represent application behavior.
SELECT DBMS_VECTOR.INDEX_ACCURACY_REPORT(
'APP_OWNER',
'DOCUMENT_CHUNKS_HNSW_IX'
) AS task_id
FROM dual;
SELECT *
FROM dba_vector_index_accuracy_report
WHERE index_name = 'DOCUMENT_CHUNKS_HNSW_IX'
ORDER BY task_id DESC;The application also needs explicit overload behavior. If a distributed graph becomes unavailable and the optimizer selects an exact scan, blindly allowing every request to continue can exhaust CPU and make relational transactions collateral damage. Connection pools should use bounded timeouts, retry budgets, and circuit breaking; services may return degraded results from a cache or temporarily reduce top-K rather than generate a retry storm. Monitor vector-search latency percentiles, exact-versus-approximate plans, achieved accuracy, graph reload state, checkpoint age, journal-related work, pool utilization, and RAC service placement as one service-level model.
A production-ready vector platform is not established when the index builds successfully. It is established when engineers can predict memory at future scale, demonstrate acceptable recall, survive an instance failure without uncontrolled exact scans, and recover graph availability within a measured objective. Oracle 26ai provides the transactional and RAC mechanisms needed to build that platform, but their operational consequences remain architectural decisions. The safest implementation treats vector search as a new database service with its own capacity, quality, and failure budgets rather than an incidental feature attached to an existing RAC cluster.
