DBFS: What, When, Why? A DBA’s Framework for Evaluating Oracle DBFS with Read Metrics

As DBAs, we’re often asked to solve a business problem that, on the surface, appears to be a storage problem. An application stores documents on a filesystem. The database stores references to those files. Disaster recovery requirements emerge. High availability becomes a priority. Suddenly, the conversation shifts to replication technologies, shared storage, file synchronization, backup strategies, and Data Guard.

The instinctive response is usually to ask:

“How do we replicate the filesystem?”

But in many cases, that’s the wrong first question. The better question is:

“Should the filesystem exist outside the database at all?”

This is where Oracle Database File System (DBFS) enters the conversation.

DBFS has been part of Oracle Database for years, yet it remains one of the most misunderstood and underutilized features in the Oracle ecosystem. Some DBAs dismiss it because “files don’t belong in a database.” Others embrace it without fully understanding its operational implications. In reality, neither approach is particularly useful.

Like most architectural decisions, the answer is not found in opinions, it is found in data.

Recently, I was involved in evaluating the disaster recovery architecture for a critical Oracle APEX application. The application stored millions of image and PDF files on a traditional Linux filesystem while the database itself was protected by Oracle Data Guard.

At first glance, the proposed solution seemed simple:

Database
    |
    +-- Data Guard

Filesystem
    |
    +-- rsync

This is a common design, and for many applications it works perfectly well. However, it introduces an important question:

What happens if the database transaction reaches the standby database, but the corresponding file has not yet been replicated?

Suddenly, the discussion is no longer about storage. It becomes a discussion about consistency, recoverability, operational complexity, and risk.

During our analysis, I resisted the temptation to jump directly to a solution. Instead, I collected real metrics from the environment:

• Repository size
• Annual growth
• Number of files
• Average file size
• Daily file modifications
• Daily data churn
• Read activity
• Current redo generation
• Disaster recovery requirements

Those numbers ultimately told me far more than any architectural diagram could. What made this exercise particularly interesting was that some of my initial assumptions turned out to be wrong. The repository contained millions of files, which sounded intimidating at first. The actual daily change rate, however, was remarkably small. Once I analyzed the facts, the architecture recommendation became obvious.

That experience inspired this article.

This is not a step-by-step guide for creating a DBFS filesystem. There are already plenty of articles that explain how to run dbfs_client, create tablespaces, and mount filesystems.

Instead, this article focuses on a more important question:

How do you determine whether DBFS is the right solution before you build it?

We’ll look at:

• What DBFS actually is
• The problems it was designed to solve
• When it is a good fit
• When it is not a good fit
• What metrics you should collect before making a decision
• SQL and Linux commands you can use to gather those metrics
• A real-world evaluation framework that replaces assumptions with facts

By the end of this article, you’ll have a practical methodology you can use to evaluate any application repository and answer one of the most common architecture questions facing DBAs and infrastructure teams:

Should this data live on a traditional filesystem, or should it become part of the database itself?

Let’s start by understanding what Oracle DBFS actually is; and just as importantly, what it is not.

What Is DBFS?

When most people hear the term Oracle Database File System (DBFS), they immediately think of “storing files in the database.” While that’s technically true, it’s an oversimplification that often leads to misconceptions about what DBFS actually is and the problems it was designed to solve.

At its core, DBFS provides a filesystem interface to content that is physically stored inside an Oracle database.

Instead of files residing on a traditional filesystem such as ext4, XFS, ASM Cluster File System (ACFS), or NFS, they are stored as Oracle SecureFiles LOBs within database tables. DBFS then exposes those database objects through a standard filesystem interface, allowing applications and users to interact with them as if they were ordinary files and directories.

Conceptually, the architecture looks like this:

Application
     |
     v
DBFS Mount Point
     |
     v
dbfs_client (FUSE)
     |
     v
SecureFiles LOBs
     |
     v
Oracle Database

From the application’s perspective, it is simply reading and writing files.

From Oracle’s perspective, those files are database objects protected by the same mechanisms that protect the rest of the database.

More Than Just a Filesystem

This distinction is important because DBFS should not be viewed as a storage technology. It is more accurately described as an availability, recoverability, and manageability technology.

Traditional filesystems solve the problem of file storage:

Need a place to store files? Use a filesystem.

DBFS solves a different problem:

How do I ensure that files and database records remain synchronized and recoverable together?

Consider a common application architecture:

Database
    |
    +-- Customer Records

Filesystem
    |
    +-- Customer Documents

The database and the documents are logically related, but physically separated. As soon as disaster recovery requirements are introduced, two independent replication streams are typically required:

Database
    |
    +-- Data Guard

Filesystem
    |
    +-- rsync / storage replication

This architecture works, but it also introduces a risk of inconsistency. Imagine the following sequence of events:

1. A user uploads a PDF.
2. The application commits a database transaction.
3. Data Guard ships the redo to the standby database.
4. The filesystem replication has not yet copied the PDF.
5. The primary server fails.

After failover, the standby database contains a reference to the document, but the document itself may not yet exist on the standby filesystem. The result is a data consistency problem that can be extremely difficult to troubleshoot.

DBFS addresses this challenge by bringing the file content into the database itself. When documents are stored in DBFS:

Database Records
+
File Content
=
Single Protection Domain

Both the structured data and unstructured file content are protected by the same Oracle technologies, including:

• Oracle Data Guard
• RMAN Backups
• Oracle Recovery Manager
• Flashback Database
• Point-in-Time Recovery
• Active Data Guard

Instead of managing separate recovery procedures for database data and filesystem data, everything becomes part of the same recovery workflow.

DBFS Is Not a Replacement for Every Filesystem

One of the biggest mistakes I see is treating DBFS as a general-purpose replacement for traditional storage. That is not what it was designed for.

DBFS excels when:

• Files are closely tied to database records.
• Consistency between files and database data is critical.
• Data Guard is part of the architecture.
• Recovery and failover procedures must include both data and documents.
• File access patterns are moderate and predictable.

On the other hand, DBFS is usually not the right choice for workloads such as:

• Media streaming platforms
• Video hosting solutions
• High-throughput content distribution systems
• Large-scale analytics repositories
• Workloads generating terabytes of new files daily

In other words, DBFS should be viewed as a database-integrated file repository rather than a general-purpose storage platform.

Why DBAs Should Care About DBFS

For many DBAs, the immediate reaction to DBFS is skepticism. After all, we’ve spent years hearing advice such as:

Don’t store files in the database.

Like many pieces of technology guidance, that statement is highly dependent on context. The real question is not whether files belong in the database. The real question is:

What problem are we trying to solve?

If the primary challenge is maximizing file-serving performance for millions of users, DBFS may be the wrong tool.

If the primary challenge is ensuring that critical application documents remain synchronized with database transactions during backups, switchovers, failovers, and disaster recovery events, DBFS becomes much more compelling.

Understanding that distinction is the first step toward making an informed architecture decision.

Before deciding whether DBFS is a good fit for a particular application, however, we need to understand why organizations deploy it in the first place and the specific problems it is intended to solve. In the next section, we’ll examine those problems and explore the scenarios where DBFS can provide significant operational and disaster recovery benefits.

Why DBFS Exists

To understand why DBFS exists, we need to step back and look at a problem that many enterprise applications face.

Most business applications manage two different types of data:

Structured Data

Information stored inside the database, such as:

• Customers
• Work orders
• Contracts
• Invoices
• Employee records
• Application metadata

Unstructured Data

Files stored outside the database, such as:

• PDFs
• Images
• Scanned documents
• Engineering drawings
• Spreadsheets
• Attachments

A typical architecture looks something like this:

Application
    |
    +-- Oracle Database
    |
    +-- Linux Filesystem

The database stores information about the files, while the filesystem stores the files themselves.

For years, this has been the standard approach because filesystems are designed to store files efficiently and databases are designed to store structured data. There is nothing inherently wrong with this design. In fact, for many applications it remains the right solution. The challenge begins when availability, disaster recovery, and recoverability requirements are introduced.

A Single Protection Domain

DBFS changes the architecture by storing file content inside the database.

Instead of:

Database
+
Filesystem

you get:

Database
+
Documents
+
Images
+
Attachments
=
Oracle Database

This fundamentally changes how the environment is protected. When a user uploads a document:

Document Contents
+
Metadata
+
Business Transaction

all become part of the same database transaction. As a result:

Same Redo Stream
Same Backup Strategy
Same Recovery Process
Same Data Guard Protection

The file and its associated database record now share the same recovery point. From a disaster recovery perspective, they become inseparable. This concept is often referred to as a single protection domain.

Simplifying High Availability and Disaster Recovery

One of the biggest operational benefits of DBFS is that it allows DBAs to leverage technologies they are already using. Without DBFS, a typical DR strategy may require:

• Oracle Data Guard
• Filesystem Replication
• Filesystem Snapshots
• Separate Backup Procedures
• Multiple Recovery Processes

With DBFS Oracle Data Guard and RMAN can protect both structured and unstructured data. This means:

• Backups are unified.
• Recovery procedures are simplified.
• Switchover planning is simplified.
• Failover testing becomes easier.
• Operational complexity is reduced.

The storage itself becomes part of the database ecosystem rather than requiring its own independent disaster recovery strategy.

DBFS Is About Consistency, Not Storage

This is perhaps the most important takeaway from this article. Most discussions about DBFS focus on where files are stored. In reality, that’s the least interesting thing about it.

DBFS is not primarily a storage solution. It is a recoverability and consistency solution.

The real question is not whether DBFS can store my files – of course it can!

The real question is:

Would my application benefit from having its files and database records protected, replicated, backed up, and recovered together?

If the answer is yes, DBFS may deserve serious consideration.

The next question, however, is equally important:

How do we determine whether a particular application is actually a good fit for DBFS?

Before making any architectural decision, we need data, not assumptions. In the next section, we’ll build a practical evaluation framework and identify the metrics every DBA should collect before recommending DBFS.

The Evaluation Framework

At this point we’ve discussed what DBFS is and the problems it was designed to solve. The next logical question is:

How do we determine whether DBFS is actually a good fit for a particular application?

This is where many architecture discussions go wrong. A common pattern looks something like this:

Application Team:
"We have 5 million files."

DBA:
"That's too many for DBFS."

Application Team:
"The repository is only 500 GB."

DBA:
"Then DBFS should be fine."

Neither conclusion is based on evidence. Repository size alone tells us almost nothing about whether DBFS is appropriate. What matters is how the repository behaves.

In this section, we’ll build a practical evaluation framework based on measurable characteristics of the workload. By collecting a small number of metrics from both the operating system and the database, you can make a data-driven recommendation rather than relying on assumptions, opinions, or outdated rules of thumb.

Step 1: Establish the Baseline

Before evaluating DBFS, document the current architecture. Capture answers to the following questions:

Where are the files stored?

Examples:

• Local Filesystem
• NFS
• SAN Storage
• ASM
• ACFS
• Object Storage

How are files accessed?

Examples:

• Oracle DIRECTORY Objects
• APEX
• PL/SQL
• Web Applications
• Middleware
• Direct OS Access

How are files protected?

Examples:

• Data Guard + rsync
• Storage Replication
• Snapshots
• Backup Software
• Manual Copy Procedures

What disaster recovery requirements exist?

Determine:

• Recovery Time Objective (RTO)
• Recovery Point Objective (RPO)
• Business impact of missing documents

This context is critical because DBFS is primarily a recoverability and consistency solution rather than a storage solution.

Step 2: Measure Repository Size and Growth

Current Repository Size

While size alone does not determine success or failure, it impacts:

• Storage planning
• RMAN backups
• Recovery times
• Data Guard storage requirements

Annual Growth Rate

If filesystem growth history is not available, compare current size to historical backups or snapshots.

Document:

• Current Size
• Previous Year’s Size
• Annual Growth

Example:

• Current Size 1.4 TB
• Previous Size 1.35 TB
• Growth 50 GB/year

A repository growing by 50 GB per year presents a very different challenge than one growing by 5 TB per year.

Step 3: Count the Files

Understanding file count helps identify repository characteristics. Many people become alarmed by large file counts. Resist that temptation.

File count is interesting, but by itself it rarely determines whether DBFS is appropriate. More important questions include:

• How large are the files?
• How often are they accessed?
• How often do they change?

Step 4: Measure File Size Characteristics

Average File Size

find /filesyste-to-evaluate -type f -printf '%s\n' \
| awk '
{
    total+=$1
    count++
}
END {
    printf("files=%d\n",count)
    printf("avgMB=%.2f\n",total/count/1024/1024)
}'

find /filesyste-to-evaluate -type f -printf '%s\n' \
| awk '
{
    total+=$1
    count++
}
END {
    printf("files=%d\n",count)
    printf("avgMB=%.2f\n",total/count/1024/1024)
}'

Applications storing:

• PDFs
• Images
• Scanned Forms
• Office Documents

often have averages measured in KB or MB and tend to be stronger DBFS candidates.

Largest Files

find /filesyste-to-evaluate -type f -printf '%s %p\n' \
| sort -nr \
| head -10

find /filesyste-to-evaluate -type f -printf '%s %p\n' \
| sort -nr \
| head -10

Extreme file sizes should be investigated because they may indicate specialized storage requirements.

Determine size distribution:

find /prod/appl/iviewer -type f -printf '%s\n' \
| awk '
{
if ($1 < 1048576) a++
else if ($1 < 5242880) b++
else if ($1 < 10485760) c++
else d++
}
END {
print "<1MB      :",a
print "1-5MB     :",b
print "5-10MB    :",c
print ">10MB     :",d
}'

find /prod/appl/iviewer -type f -printf '%s\n' \
| awk '
{
if ($1 < 1048576) a++
else if ($1 < 5242880) b++
else if ($1 < 10485760) c++
else d++
}
END {
print "<1MB      :",a
print "1-5MB     :",b
print "5-10MB    :",c
print ">10MB     :",d
}'

Example output:

<1MB      : 8336510
1-5MB     : 369557
5-10MB    : 14734
>10MB     : 3958

This is important because DBFS performs much better when most files are small-to-medium.

Step 5: Measure Daily Churn

This is the most important metric in the entire evaluation. Many repositories appear large because they contain years of historical content. The real question is:

How much of the repository changes each day?

Data Guard replicates changes, not repository size.

Daily Data Modified

find /filesyste-to-evaluate -type f -mtime -1 -printf '%s\n' \
| awk '{total+=$1}
END{
printf("%.2f GB changed today\n",
total/1024/1024/1024)
}'

find /filesyste-to-evaluate -type f -mtime -1 -printf '%s\n' \
| awk '{total+=$1}
END{
printf("%.2f GB changed today\n",
total/1024/1024/1024)
}'

Example output:

1.28 GB changed today

This number often surprises people. A multi-terabyte repository may only change by a few hundred MB per day. That makes a massive difference when estimating:

• Redo generation
• Data Guard impact
• Backup growth

Number of Files Modified Per Day

find /filesyste-to-evaluate -type f -mtime -30 -printf '%TY-%Tm-%Td\n' | 
    awk '{count[$1]++} END {for (date in count) print date, count[date]}' | 
    sort

find /filesyste-to-evaluate -type f -mtime -30 -printf '%TY-%Tm-%Td\n' | 
    awk '{count[$1]++} END {for (date in count) print date, count[date]}' | 
    sort

You should see an output like:

Day 	   Files Changed
2026-06-15 267
2026-06-16 304
2026-06-17 331
2026-06-18 303
2026-06-19 200
2026-06-20 10
2026-06-21 12
2026-06-22 309

This helps quantify the write workload.

Step 6: Measure Read Activity

Read activity is often overlooked. A repository may contain millions of files but only receive a few thousand reads per day. Understanding access frequency helps determine whether a traditional filesystem’s performance advantages are actually needed.

Depending on the environment, you may use:

• Filesystem Statistics
• Application Logs
• Audit Records
• APEX Activity Logs
• Web Server Logs

You would want to document the files read per day.

If filesystem uses atime, Check:

mount | grep <filesystem>

Look for: relatime or atime

Then:

find /filesyste-to-evaluate -type f -atime -1 | wc -l

find /filesyste-to-evaluate -type f -atime -1 | wc -l

For example, 2900 reads/day translates into only a few reads per minutes during business hours!

Step 7: Measure Current Redo Generation

Before estimating DBFS impact, understand what the database already generates.

Run the following query to get an average redo generated in the past 30 days

SELECT
    trunc(completion_time) day,
    round(sum(blocks*block_size)/1024/1024/1024,2) gb
FROM v$archived_log
WHERE completion_time > sysdate-30
GROUP BY trunc(completion_time)
ORDER BY 1;

SELECT
    trunc(completion_time) day,
    round(sum(blocks*block_size)/1024/1024/1024,2) gb
FROM v$archived_log
WHERE completion_time > sysdate-30
GROUP BY trunc(completion_time)
ORDER BY 1;

Example output:

DAY                         GB
------------------- ----------
2026-06-15 00:00:00       5.47
2026-06-16 00:00:00      10.52
2026-06-17 00:00:00       6.61
2026-06-18 00:00:00       6.59
2026-06-19 00:00:00       6.44
2026-06-20 00:00:00      12.08
2026-06-21 00:00:00       6.02
2026-06-22 00:00:00       6.62
2026-06-23 00:00:00       8.57
2026-06-24 00:00:00       6.65
2026-06-25 00:00:00       6.49
2026-06-26 00:00:00       1.62
2026-06-27 00:00:00      11.76
2026-06-28 00:00:00       6.61
2026-06-29 00:00:00       6.49
2026-06-30 00:00:00      10.66
2026-07-01 00:00:00       6.17
2026-07-02 00:00:00       6.44
2026-07-03 00:00:00        6.3
2026-07-04 00:00:00      10.73
2026-07-05 00:00:00       5.96
2026-07-06 00:00:00       6.56
2026-07-07 00:00:00       8.99
2026-07-08 00:00:00        6.5
2026-07-09 00:00:00       6.49
2026-07-10 00:00:00       1.38
2026-07-11 00:00:00        5.9
2026-07-12 00:00:00       6.38
2026-07-13 00:00:00       6.58
2026-07-14 00:00:00       6.58
2026-07-15 00:00:00       3.06

You would want to capture

• Average Redo Per Day
• Peak Redo Per Day

Now you have a baseline for estimating DBFS-generated redo.

Step 9: Determine if SecureFiles compression would make sense

To understand whether the files in the repositoy can benefit from compression being turned on at the DBFS storage level, run:

find /prod/appl/iviewer -type f -mtime -1 -size +0 -print0 | awk '
BEGIN {
    RS="\0";
    total_orig = 0;
    total_comp = 0;
}
{
    file = $0;
    # Get original size
    "stat -c %s \"" file "\"" | getline orig_size;
    close("stat -c %s \"" file "\"");
    
    # Stream to gzip to get compressed size without writing to disk
    cmd = "gzip -c \"" file "\" | wc -c";
    cmd | getline comp_size;
    close(cmd);
    
    total_orig += orig_size;
    total_comp += comp_size;
}
END {
    if (total_orig > 0) {
        savings = ((total_orig - total_comp) / total_orig) * 100;
        printf "Total Uncompressed Bytes: %d\n", total_orig;
        printf "Total Compressed Bytes:   %d\n", total_comp;
        printf "Average Space Savings:    %.2f%%\n", savings;
    } else {
        print "No files changed in the past 24 hours.";
    }
}'

find /prod/appl/iviewer -type f -mtime -1 -size +0 -print0 | awk '
BEGIN {
    RS="\0";
    total_orig = 0;
    total_comp = 0;
}
{
    file = $0;
    # Get original size
    "stat -c %s \"" file "\"" | getline orig_size;
    close("stat -c %s \"" file "\"");
    
    # Stream to gzip to get compressed size without writing to disk
    cmd = "gzip -c \"" file "\" | wc -c";
    cmd | getline comp_size;
    close(cmd);
    
    total_orig += orig_size;
    total_comp += comp_size;
}
END {
    if (total_orig > 0) {
        savings = ((total_orig - total_comp) / total_orig) * 100;
        printf "Total Uncompressed Bytes: %d\n", total_orig;
        printf "Total Compressed Bytes:   %d\n", total_comp;
        printf "Average Space Savings:    %.2f%%\n", savings;
    } else {
        print "No files changed in the past 24 hours.";
    }
}'

Sample output:

Total Uncompressed Bytes: 290838967
Total Compressed Bytes:   272893675
Average Space Savings:    6.17%

If compression is less than 10% the compress off might be best… no need to waste CPU. But we can determine that with actual testing later.

Step 8: Calculate the Impact

Once all metrics have been collected, build a simple scorecard.

Example:

Repository Size         1.4 TB
Annual Growth           50 GB/year

File Count              8,724,341
Average File Size       0.35 MB
Largest File            100 MB

Files Modified/Day      254
Data Modified/Day       0.5 GB

Files Read/Day          2,900

Current Redo/Day        6.88 GB
Peak Redo/Day           12.08 GB

At this stage, patterns begin to emerge. In this example:

• Growth is very low
• Daily churn is extremely low
• Read workload is modest
• File sizes are relatively small
• Existing redo generation is already low

These characteristics strongly suggest that the repository is a viable DBFS candidate.

Step 9: Validate the Non-Technical Requirements

Before making a final recommendation, ask a few business and architectural questions:

Are files tightly coupled to database records?

If yes, DBFS becomes more attractive.

Would missing documents after a failover be unacceptable?

If yes, DBFS becomes more attractive.

Are files primarily accessed through Oracle?

Examples:

• APEX
• PL/SQL
• DIRECTORY Objects

If yes, DBFS becomes more attractive.

Do external systems depend on the current filesystem structure?

Examples:

• Batch Jobs
• OCR Systems
• FTP Transfers
• Third-Party Integrations

These may influence the design.

The Key Principle

The purpose of this framework is not to prove that DBFS is the right answer. The purpose is to replace opinions with evidence. I’ve seen organizations reject DBFS because they had “too many files.” I’ve seen others embrace DBFS simply because Oracle supports it. Both approaches are flawed.

A sound architectural decision should be based on measurable characteristics of the workload:

• How much data exists?
• How fast is it growing?
• How often does it change?
• How is it accessed?
• What problem are we trying to solve?

Only after answering those questions can we determine whether DBFS is the right solution, or whether a traditional filesystem remains the better choice.

A Practical Rule of Thumb

When evaluating a potential DBFS migration, I ask five simple questions:

1. Are the files business-critical?
2. Is Data Guard already being used?
3. Are the files tightly coupled to database records?
4. Is daily change volume relatively low?
5. Is recovery consistency more important than raw filesystem performance?

If the answer to most of those questions is yes, DBFS deserves serious consideration. If the answer to most of them is no, a traditional filesystem with a separate replication strategy may remain the better choice.

The key takeaway is that DBFS should not be selected because Oracle provides it, nor should it be rejected because it stores files in the database. Like any architectural decision, it should be evaluated objectively using measurable characteristics of the workload and the business requirements of the application.

What’s Next?

In this article we’ve focused exclusively on evaluation and decision-making:

• What DBFS is
• Why it exists
• When it makes sense
• How to analyze a workload
• How to make a data-driven recommendation

In a future article, we’ll move from theory to implementation and walk through the complete deployment of a highly available DBFS environment integrated with Oracle Data Guard, including:

• SecureFiles tablespace design
• DBFS content store creation
• Wallet-based authentication
• Mount automation
• CRS integration
• Data Guard role-transition automation
• Switchover and failover considerations
• Operational best practices
• Lessons learned from production deployments

By combining the evaluation framework from this article with a properly designed implementation, you’ll have everything needed to determine not only whether DBFS is the right solution, but also how to deploy it successfully in a production environment.