Artificial Intelligence is becoming a core capability of Oracle Database, and one of the first concepts you’ll encounter while exploring AI Vector Search is text chunking.
Whether you’re planning to build Retrieval-Augmented Generation (RAG) applications, semantic search solutions, or AI-powered assistants, understanding how Oracle splits documents into smaller pieces are essential.
Instead of simply reading the documentation, I wanted to see how Oracle AI Database 26ai actually performs chunking in a real environment.
In this article, I’ll explain what text chunking is, why it matters, and walk through several hands-on experiments using the DBMS_VECTOR_CHAIN package.
What is Text Chunking?
Imagine you have a large document containing hundreds or even thousands of words. Instead of processing the entire document as one block, Oracle divides it into multiple smaller sections called chunks.
For example, consider the following text.
Oracle RMAN is Oracle‘s backup utility.
RMAN supports incremental backups.
Block Change Tracking improves incremental backup performance.
Oracle can split that document into separate chunks.
Chunk 1
Oracle RMAN is Oracle‘s backup utility.
Chunk 2
RMAN supports incremental backups.
Chunk 3
Block Change Tracking improves incremental backup performance.
Each chunk can later be converted into a vector embedding and indexed for semantic search.
Smaller, meaningful chunks help AI retrieve only the most relevant information instead of scanning an entire document every time.
Why Does Chunking Matter?
Text chunking is the foundation of Oracle AI Vector Search.
Without chunking:
Large documents become difficult to search efficiently.
Embeddings contain too much unrelated information.
Search quality decreases.
With proper chunking:
Documents become easier to search for.
AI retrieves more relevant information.
Embeddings capture focused context.
Semantic search becomes significantly more accurate.
Test Environment
The following environment was used for this experiment.
Oracle AI Database 26ai Enterprise Edition
Single Instance Deployment
SQL*Plus
DBMS_VECTOR_CHAIN Package
Before starting, let’s verify that the required package exists.
COLUMN owner FORMAT A12
COLUMN object_name FORMAT A30
COLUMN object_type FORMAT A20
SELECT owner,
object_name,
object_type
FROM dba_objects
WHERE object_name LIKE ‘DBMS_VECTOR%’
ORDER BY object_name;
The output should include the DBMS_VECTOR_CHAIN package.
Understanding UTL_TO_CHUNKS()
Oracle provides the UTL_TO_CHUNKS() function inside the DBMS_VECTOR_CHAIN package.
It accepts text as input and returns one or more JSON documents describing each generated chunk.
The most used parameters are:
Now let’s see how each option behaves.
Test 1 — Chunking by Words
Let’s begin with word-based chunking.
First, configure SQL*Plus so the JSON output is displayed correctly.
SET LONG 100000
SET LONGCHUNKSIZE 100000
SET LINESIZE 250
COLUMN chunk_json FORMAT A250
Now execute the following query.
SELECT COLUMN_VALUE AS chunk_json
FROM TABLE(
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS(
‘Oracle RMAN is Oracle”s backup utility. RMAN supports incremental backups. Block Change Tracking improves incremental backup performance.’,
JSON(‘{
“by”:“words”,
“max”:“10”,
“split”:“sentence”
}’)
)
);
The output returned three chunks.
{“chunk_id”:1,
“chunk_data”:“Oracle RMAN is Oracle’s backup utility.”}
{“chunk_id”:2,
“chunk_data”:“RMAN supports incremental backups.”}
{“chunk_id”:3,
“chunk_data”:“Block Change Tracking improves incremental backup performance.”}
Notice that Oracle returns each chunk as a JSON document containing the chunk ID, offset, length, and the actual chunk text. These metadata values become useful later during embedding generation and document retrieval.
Oracle respected the sentence boundaries and generated clean, readable chunks.
Test 2 — Increasing the Chunk Size
Next, I increased the maximum chunk size from 10 words to 20 words.
SELECT COLUMN_VALUE AS chunk_json
FROM TABLE(
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS(
‘Oracle RMAN is Oracle”s backup utility. RMAN supports incremental backups. Block Change Tracking improves incremental backup performance.’,
JSON(‘{
“by”:“words”,
“max”:“20”,
“split”:“sentence”
}’)
)
);
The output changed immediately.
Instead of three chunks, Oracle merged the first two sentences.
{“chunk_id”:1,
“chunk_data”:“Oracle RMAN is Oracle’s backup utility. RMAN supports incremental backups.”}
{“chunk_id”:2,
“chunk_data”:“Block Change Tracking improves incremental backup performance.”}
As the maximum chunk size increases, Oracle attempts to preserve more context within each chunk.
Test 3 — Large Chunk Size
Now let’s make the chunk size much larger than the document itself.
SELECT COLUMN_VALUE AS chunk_json
FROM TABLE(
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS(
‘Oracle RMAN is Oracle”s backup utility. RMAN supports incremental backups. Block Change Tracking improves incremental backup performance.’,
JSON(‘{
“by”:“words”,
“max”:“100”,
“split”:“sentence”
}’)
)
);
Since the entire document fits within the configured limit, no additional chunks were created.
Test 4 — Chunking by Characters
Oracle also supports character-based chunking.
Let’s see how that behaves.
SELECT COLUMN_VALUE AS chunk_json
FROM TABLE(
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS(
‘Oracle RMAN is Oracle”s backup utility. RMAN supports incremental backups. Block Change Tracking improves incremental backup performance.’,
JSON(‘{
“by”:“characters”,
“max”:“50”
}’)
)
);
The output looked very different.
{“chunk_id”:1,
“chunk_data”:“Oracle RMAN is Oracle’s backup utility. RMAN”}
{“chunk_id”:2,
“chunk_data”:“supports incremental backups. Block Change”}
{“chunk_id”:3,
“chunk_data”:“Tracking improves incremental backup performance.”}
Unlike word-based chunking, Oracle simply counts characters.
Notice that sentence boundaries are no longer preserved.
An Interesting Discovery
One experiment produced an unexpected result.
I wanted to see how Oracle handled very small chunk sizes.
So I reduced the maximum value below 10.
SELECT COLUMN_VALUE AS chunk_json
FROM TABLE(
DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS(
‘Oracle RMAN is Oracle”s backup utility. RMAN supports incremental backups. Block Change Tracking improves incremental backup performance.’,
JSON(‘{
“by”:“words”,
“max”:“5”,
“split”:“sentence”
}’)
)
);
Instead of generating smaller chunks, Oracle returned the following error.
ORA-30584: invalid text chunking MAXIMUM – ‘5’
I repeated the same test with:
max = 6
max = 7
max = 8
max = 9
All of them produced the same error.
Only when I specified:
“max”:“10”
did Oracle successfully generate chunks.
This was an interesting observation because Oracle appears to enforce a minimum chunk size when using word-based chunking with sentence preservation.
I couldn’t find this behavior clearly documented, but it was consistently reproduced in my Oracle AI Database 26ai lab environment.
What I Observed
After running several experiments, a few observations stood out.
Word-based chunking produced the cleanest output.
Every chunk remained readable because Oracle preserved complete sentence boundaries.
Larger chunk sizes are preserved in more context.
Increasing the MAX value reduced the number of generated chunks while keeping related information together.
Character-based chunking behaved differently.
Instead of respecting sentences, Oracle simply counted characters, which caused words and sentences to be split across chunk boundaries.
Oracle validates chunk size.
Values below 10 were rejected when using word-based chunking with sentence splitting in my environment.
Final Thoughts
Text chunking is one of the first and most important steps in Oracle AI Database’s vector search pipeline. Although it may seem like a simple process of splitting text, my testing showed that the chunking strategy directly affects how information is preserved before generating vector embeddings.
During these tests, I observed how different parameter combinations changed the number and size of the generated chunks, and how word-based and character-based chunking produce very different results. Understanding these options allows DBAs and developers to choose a chunking strategy that best fits their data and AI workloads.
This hands-on exercise gave me a solid understanding of how Oracle AI Database 26ai prepares text for semantic search. In the next article, I’ll explore the next stage of the pipeline — vector embeddings — and see how these chunks are transformed into vectors that power AI search.
