1Z0-184-25 Practice Questions

IVF (Inverted File) indexes in Oracle 23ai partition vectors into clusters, probing a subset during

queries for efficiency. Incomplete results suggest insufficient partitions are probed, reducing recall.

The TARGET_ACCURACY clause (A) allows users to specify a desired accuracy percentage (e.g., 90%),

dynamically increasing the number of probed partitions to meet this target, thus improving accuracy

at the cost of latency. Switching to HNSW (B) offers higher accuracy but requires re-indexing and may

not be necessary if IVF tuning suffices. Increasing VECTOR_MEMORY_SIZE (C) allocates more

memory for vector operations but doesn’t directly affect probe count. EFCONSTRUCTION (D) is an

HNSW parameter, irrelevant to IVF. Oracle’s IVF documentation highlights TARGET_ACCURACY as the

recommended tuning mechanism.

Reference:Oracle Database 23ai AI Vector Search Guide, Section on IVF Index Tuning.

When vector embeddings are generated outside the database, the storage choice must balance

efficiency, scalability, and usability for similarity search. A CSV file (A) is simple and human-readable

but inefficient for large-scale vector operations due to text parsing overhead and lack of indexing

support. A binary FVEC file (B) offers a compact format for vectors, reducing storage size and

improving read performance, but separating relational data into a CSV complicates integration and

querying, making it suboptimal for unified workflows. Storing embeddings as BLOBs in a relational

database (C) integrates well with structured data and supports SQL access, but it lacks the specialized

indexing (e.g., HNSW, IVF) and query optimizations that dedicated vector databases provide. A

dedicated vector database (D), such as Milvus or Pinecone (or Oracle 23ai’s vector capabilities if

internal), is purpose-built for high-dimensional vectors, offering efficient storage, advanced indexing,

and fast approximate nearest neighbor (ANN) searches. For external generation scenarios, where

embeddings are not immediately integrated into Oracle 23ai, a dedicated vector database is the

most suitable due to its performance and scalability advantages. Oracle’s AI Vector Search

documentation indirectly supports this by emphasizing optimized vector storage for search

efficiency, though it focuses on in-database solutions.

Reference:Oracle Database 23ai AI Vector Search Guide, Chapter on Vector Storage and Indexing.

The VECTOR_DISTANCE function in Oracle 23ai (D) computes the distance between two vectors using

a specified metric (e.g., COSINE, EUCLIDEAN), enabling similarity search by quantifying proximity. It

doesn’t fetch exact matches (A); it measures similarity. Index creation (B) is handled by CREATE

INDEX, not this function. Grouping (C) requires additional SQL (e.g., GROUP BY), not

VECTOR_DISTANCE’s role. Oracle’s SQL reference defines it as the core tool for distance calculation in

vector queries.

Reference:Oracle Database 23ai SQL Language Reference, Section on VECTOR_DISTANCE.

In Oracle Database 23ai, the DBMS_VECTOR_CHAIN package supports Retrieval Augmented

Generation (RAG) workflows by providing utilities for vector processing. The UTL_TO_CHUNKS

function specifically splits large documents into smaller, manageable text chunks. This is critical in

RAG applications because embedding models (e.g., BERT, ONNX models) have token limits (e.g., 512

tokens). Splitting text minimizes token truncation, ensuring that each chunk retains full semantic

meaning, which improves the quality of subsequent vector embeddings and search accuracy.

Generating embeddings (A) is handled by functions like VECTOR_EMBEDDING, not UTL_TO_CHUNKS.

Loading documents (B) is a separate process (e.g., via SQL*Loader). Converting to a single text string

(D) contradicts the chunking purpose and risks truncation. Oracle’s documentation on

DBMS_VECTOR_CHAIN emphasizes chunking for optimizing vector quality in RAG.

Reference:Oracle Database 23ai PL/SQL Packages and Types Reference, DBMS_VECTOR_CHAIN.

In Oracle Database 23ai’s Select AI, security between the Autonomous Database and OCI Generative

AI is managed using Resource Principals (B). This mechanism allows the database instance to

authenticate itself to OCI services without hardcoding credentials, enhancing security by avoiding

exposure of sensitive keys. TLS/SSL encryption (A) is used for data-in-transit security, but it’s a

complementary layer, not the primary management method. A VPN tunnel (C) is unnecessary within

OCI’s secure infrastructure and not specified for Select AI. Manual API key entry (D) is impractical and

insecure for automated database interactions. Oracle’s documentation on Select AI highlights

Resource Principals as the secure, scalable authentication method.

Reference:Oracle Database 23ai New Features Guide, Section on Select AI Security.

Select AI in Oracle Database 23ai enables natural language queries by integrating with OCI

Generative AI services. The first step in setting up the practice environment is to optionally create an

OCI compartment (A), which organizes and isolates resources in Oracle Cloud Infrastructure (OCI).

This is foundational because subsequent steps—like defining policies or configuring the Autonomous

Database—depend on a compartment structure, though an existing compartment can be reused,

making it optional. Creating a policy (B) is a subsequent step to grant access to OCIGenerative AI,

requiring a compartment first. Dropping compartments (C) is irrelevant and disruptive. Creating a

user account (D) is not specified as the initial step in Select AI setup. Oracle’s Select AI

documentation lists compartment setup as the starting point in OCI configuration.

Reference:Oracle Database 23ai New Features Guide, Section on Select AI Setup.

The Vector Pool in Oracle 23ai is a dedicated SGA memory region (controlled by

VECTOR_MEMORY_SIZE) for vector operations, specifically storing HNSW indexes (graph structures)

and IVF index metadata (e.g., centroids) (B). This optimizes memory usage for vector search, keeping

critical index data accessible for fast queries. Partitioning (A) is unrelated; that’s a tablespace feature.

Longer SQL execution (C) might benefit indirectly from memory efficiency, but it’s not the purpose.

Non-vector data (D) resides elsewhere (e.g., PGA, buffer cache). Oracle allocates the Vector Pool to

enhance AI workloads, ensuring indexes don’t compete with other memory, a design choice

reflecting vector search’s growing importance.

Reference:Oracle Database 23ai AI Vector Search Guide, Section on Vector Memory Management.

SQLLoader in Oracle 23ai supports loading VECTOR data from CSV files, requiring vectors to be

formatted as text. A critical consideration is enclosing components in curly braces (A), e.g., {1.2, 3.4,

5.6}, to match the VECTOR type’s expected syntax (parsed into FLOAT32, etc.). FVEC (B) is a binary

format, not compatible with CSV text input; SQLLoader expects readable text, not fixed offsets.

Sparse format (C) isn’t supported for VECTOR columns, which require dense arrays. SQLLoader

doesn’t normalize vectors automatically (D); formatting must be explicit. Oracle’s documentation

specifies curly braces for CSV-loaded vectors.

Reference:Oracle Database 23ai Utilities Guide, Section on SQLLoader for Vectors.

To add a new column to an existing table, Oracle uses the ALTER TABLE statement with the ADD

clause. Option B, ALTER TABLE my_table ADD (v VECTOR(4, FLOAT32)), correctly specifies the column

name "v", the VECTOR type, and its attributes (4 dimensions, FLOAT32 precision) within parentheses,

aligning with Oracle’s DDL syntax for VECTOR columns. Option A uses MODIFY, which alters existing

columns, not adds new ones, making it incorrect here. Option C uses UPDATE, a DML statement for

updating data, not a DDL operation for schema changes. Option D omits parentheses around the

VECTOR specification, which is syntactically invalid as Oracle requires dimensions and format to be

enclosed. The SQL Language Reference confirms this syntax for adding VECTOR columns.

Reference:Oracle Database 23ai SQL Language Reference, Section on ALTER TABLE.

In Oracle 23ai, tables with VECTOR columns support standard DML operations: SELECT (A) retrieves

data, UPDATE (B) modifies rows, and DELETE (C) removes rows. However, JOIN ON VECTOR columns

(D) is not permitted because VECTOR isn’t a relational type for equality comparison; it’s for similarity

search (e.g., via VECTOR_DISTANCE). Joins must use non-VECTOR columns. Oracle’s SQL reference

restricts VECTOR to specific operations, excluding direct joins.

Reference:Oracle Database 23ai SQL Language Reference, Section on VECTOR Restrictions.