📅 Last Updated: August 2026

This guide explains the Oracle Data Pump/Classic Export warning EXP-00091: Exporting questionable statistics, its common causes, how to diagnose it, and why the warning should not automatically be treated as a failed export.

EXP-00091: Exporting Questionable Statistics – Causes, Diagnosis and Solutions in Oracle Database

EXP-00091: Exporting questionable statistics is a warning that can appear while performing an Oracle Classic Export using the legacy exp utility.

The message can be confusing because the export may continue and complete successfully even though Oracle reports questionable optimizer statistics.

This is particularly important when working with older Oracle Database environments where the traditional exp and imp utilities are still used for migration, backup, or data-transfer activities.

Important:

EXP-00091 does not automatically mean that the exported table data is corrupt or that the entire export has failed. It specifically indicates that Oracle considers some exported optimizer statistics questionable.

Original Problem

The original article documented an EXP-00091 warning encountered while performing an Oracle export.

The reported environment was:

Component	Environment
Operating System	Oracle Enterprise Linux 7
Oracle Database	Oracle Database 11.2.0.4
Previous Database Version	Oracle Database 11.2.0.1.0
Export Utility	Classic Export (`exp`)
Problem	EXP-00091: Exporting questionable statistics

The warning appeared after the database environment had been upgraded from an earlier Oracle Database 11g release.

The original workaround was to perform the export with:

STATISTICS=NONE

While this can be a practical solution in the appropriate situation, it is important to understand why the warning occurs before simply suppressing statistics.

What Does EXP-00091 Mean?

The Oracle message is:

EXP-00091: Exporting questionable statistics

The message relates to optimizer statistics being exported by the Classic Export utility.

Oracle uses optimizer statistics to help the Cost-Based Optimizer estimate the cost of different execution plans.

Statistics can contain information such as:

Number of rows.
Number of blocks.
Number of distinct values.
Column distribution information.
Index-related statistics.
Other optimizer-related information.

When Oracle determines that statistics may not remain valid or meaningful in the target environment, it can report them as questionable during export.

Does EXP-00091 Mean the Export Failed?

Not necessarily.

This is one of the most important points to understand when troubleshooting the message.

An export log can contain EXP-00091 while the export continues and eventually reports a successful completion.

For example, a log may contain:

. . exporting table                      EMP
EXP-00091: Exporting questionable statistics
. . exporting table                      DEPT
. . exporting table                      BONUS
...
Export terminated successfully without warnings.

The exact output varies by Oracle version and export options.

Therefore, the DBA should always examine the complete export log rather than assuming that one warning means the entire export is unusable.

Why Does Oracle Report Questionable Statistics?

There are several circumstances that can cause Oracle Classic Export to consider statistics questionable.

Common causes include:

Client and database character-set differences.
Client and database national character-set differences.
Use of a QUERY clause during export.
Exporting only part of a partitioned table.
Errors encountered while processing a table.
Statistics that may not be valid after import into another environment.

The exact cause should be determined from the export log and environment rather than assuming that one particular cause applies to every occurrence of EXP-00091.

Classic Export and Optimizer Statistics

Oracle's traditional Export utility can export database objects and associated metadata, including optimizer statistics.

When the export is imported into another database, those statistics may be restored along with the objects depending on the export/import configuration.

However, statistics that were accurate in the source environment may not necessarily be appropriate in the target environment.

For example, if the target database has significantly different:

Data distribution.
Character-set configuration.
Object structures.
Storage characteristics.
Optimizer environment.

then the imported statistics may not accurately represent the target environment.

Character Set and EXP-00091

One important cause of questionable statistics is a difference between the character set used by the export client and the database environment.

This is particularly relevant when Classic Export is executed from a client whose Oracle character-set configuration differs from that of the database.

The DBA should therefore inspect both the database character-set configuration and the client-side NLS_LANG setting.

Important distinction:

The database character set and the client character set are not necessarily required to be identical.

Oracle can perform character-set conversion between compatible client and database character sets. Therefore, a difference alone does not prove that the database configuration is incorrect.

Check the Database Character Set

Connect to the database using SQL*Plus:

sqlplus / as sysdba

Then execute:

SELECT parameter,
       value
FROM nls_database_parameters
WHERE parameter IN (
    'NLS_CHARACTERSET',
    'NLS_NCHAR_CHARACTERSET'
);

The result distinguishes the database character set from the national character set.

For example:

PARAMETER              VALUE
---------------------- ----------
NLS_CHARACTERSET       AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16

The actual values will depend on the database.

Why Check NLS_NCHAR_CHARACTERSET?

A common source of confusion is assuming that every character-set value displayed by Oracle represents the main database character set.

Oracle maintains both:

Database character set – used by character data types such as CHAR and VARCHAR2.
National character set – used by national character data types such as NCHAR, NVARCHAR2, and NCLOB.

Therefore, always identify which parameter contains the reported character set.

Check NLS_LANG on the Export Client

If the Classic Export command is being executed from a Linux server, check the NLS_LANG environment variable.

Run:

echo $NLS_LANG

For example:

AMERICAN_AMERICA.AL32UTF8

The value consists of:

LANGUAGE_TERRITORY.CHARACTER_SET

The character-set component tells Oracle client software which character set the client environment uses for communication and character conversion.

Check Whether NLS_LANG Is Set

On Linux:

env | grep NLS_LANG

or:

echo $NLS_LANG

If the variable is not defined, Oracle Client behavior may depend on the operating-system locale and Oracle client configuration.

Do not randomly assign an NLS_LANG value simply to make the warning disappear. The value should reflect the actual client encoding requirements.

Why Did the Problem Appear After a Database Upgrade?

In the original case, the environment had been upgraded from Oracle Database 11.2.0.1.0 to 11.2.0.4.

When an Oracle environment is upgraded, changes in software behavior, client libraries, NLS configuration, statistics handling, or surrounding environment can expose conditions that were not previously visible.

This does not necessarily mean that the upgrade itself corrupted the statistics.

Instead, the upgrade may have changed the conditions under which the export utility evaluates the statistics.

For this reason, a DBA should compare the pre-upgrade and post-upgrade environments rather than immediately modifying database data or character-set parameters.

Check the Export Command

Review the exact exp command used.

For example:

exp system/password@ORCL \
    owner=SCOTT \
    directory=/backup

The actual syntax depends on the export requirements and Oracle version.

Look for options that can influence the statistics being exported.

In particular, investigate whether the command uses:

STATISTICS
QUERY
Table-specific exports
Partition-specific exports
Other filtering options

QUERY Clause and Questionable Statistics

A QUERY clause can cause the export to include only a subset of the rows from a table.

For example:

QUERY="WHERE STATUS='ACTIVE'"

The optimizer statistics from the complete source table may not accurately describe the subset of rows being exported.

This is one reason Oracle can regard statistics associated with a filtered export as questionable.

Partial Partition Exports

Partitioned tables require additional consideration.

If only part of a partitioned table is exported, statistics representing the complete table may no longer correspond to the exported data.

Therefore, an export involving individual partitions can also produce questionable-statistics warnings.

Check the Complete Export Log

Never troubleshoot EXP-00091 from the message alone.

Review the complete export log and look for other errors immediately before or after the warning.

For example:

EXP-00091: Exporting questionable statistics
ORA-xxxxx: ...
EXP-00000: Export terminated successfully

An accompanying Oracle error may provide much more information about the real cause.

Do Not Confuse EXP-00091 with Data Corruption

The wording "questionable statistics" can sound alarming.

However, the warning specifically concerns statistics.

It should not automatically be interpreted as:

Table corruption.
Database corruption.
Lost rows.
Invalid data.
Failed export.

The DBA should verify the actual export result and inspect the complete log.

Should You Immediately Use STATISTICS=NONE?

The short answer is: sometimes, but understand what you are doing first.

The Classic Export utility provides the STATISTICS parameter, and using:

STATISTICS=NONE

prevents statistics from being exported.

This can be appropriate when the statistics are not required in the target database and you intend to gather fresh optimizer statistics after import.

However, simply suppressing statistics without understanding the underlying issue is not always the best approach.

Why Fresh Statistics Can Be Better After Import

When data is migrated to another Oracle environment, optimizer statistics from the source database may not accurately represent the target environment.

After migration, the DBA may prefer to gather fresh statistics on the target database once the data has been imported and validated.

This can provide statistics based on the actual target data and environment.

The exact statistics-gathering strategy should be designed according to the database version, application requirements, and migration procedure.

Detailed Diagnosis of EXP-00091

Before applying any workaround, it is important to determine why Oracle considers the exported statistics questionable.

The following diagnostic procedure can be used when troubleshooting EXP-00091 in Oracle Database 11g and other environments that still use the legacy Classic Export utility.

Step 1 – Capture the Exact Export Command

Start by recording the exact exp command that generated the warning.

For example:

exp system@ORCL owner=SCOTT file=/backup/scott.dmp log=/backup/scott.log

Do not troubleshoot only from memory. Export parameters can significantly affect whether statistics are considered questionable.

Record at least:

Oracle username used for export.
Database service or connect identifier.
Export mode.
Export file.
Log file.
STATISTICS parameter.
QUERY parameter, if used.
Any table or partition filtering.

Step 2 – Check the Export Utility Version

The Classic Export utility is part of the Oracle Client/Oracle Database software installation.

Check its version:

exp help=y

The output identifies the Export utility version and displays the supported parameters.

You can also verify the Oracle environment from the shell:

echo $ORACLE_HOME
echo $ORACLE_SID
which exp

If multiple Oracle installations exist, make sure the intended exp executable is being used.

Step 3 – Check for Multiple Oracle Homes

Multiple Oracle Homes can cause unexpected behavior because the export executable and Oracle libraries may come from different installations.

Run:

which exp

Then:

exp help=y | head

Compare the utility with the Oracle Home from which the database administration tools are being executed.

This is particularly important after an Oracle Database upgrade where an older Oracle Home may still exist on the server.

Step 4 – Check NLS_LANG

One of the first environment variables to check is NLS_LANG.

Run:

echo $NLS_LANG

For example:

AMERICAN_AMERICA.AL32UTF8

The character-set component is especially relevant when investigating character-set-related export warnings.

Do not change this value blindly. First establish the operating-system locale and the character encoding actually required by the client environment.

Step 5 – Check the Operating-System Locale

On Linux, check the current locale:

locale

You may see output similar to:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

Compare the operating-system locale with the Oracle client character-set configuration.

Step 6 – Check the Database Character Set

Connect to the database:

sqlplus / as sysdba

Then execute:

SELECT parameter,
       value
FROM nls_database_parameters
WHERE parameter IN (
    'NLS_CHARACTERSET',
    'NLS_NCHAR_CHARACTERSET'
)
ORDER BY parameter;

Example:

PARAMETER              VALUE
---------------------- ----------
NLS_CHARACTERSET       AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16

The actual values will depend on your database.

Step 7 – Understand the Two Character Sets

Do not combine the two parameters.

Parameter	Purpose
`NLS_CHARACTERSET`	Main database character set used by character data types such as VARCHAR2 and CHAR.
`NLS_NCHAR_CHARACTERSET`	National character set used by NCHAR, NVARCHAR2 and NCLOB.

This distinction is important because an administrator may see a value such as AL16UTF16 and incorrectly assume that it is the database character set when it is actually the national character set.

Step 8 – Check the Database NLS Parameters

You can obtain additional NLS information using:

SELECT parameter,
       value
FROM nls_database_parameters
ORDER BY parameter;

This can help establish the database's configured NLS environment.

Step 9 – Check the Current Session NLS Parameters

After connecting with the same Oracle client that runs the export, execute:

SELECT parameter,
       value
FROM nls_session_parameters
ORDER BY parameter;

Compare the session settings with the database settings.

Remember that session NLS parameters and database character-set parameters represent different layers of Oracle's globalization configuration.

Step 10 – Check Whether QUERY Was Used

Review the export command for the QUERY parameter.

For example:

QUERY="WHERE STATUS='ACTIVE'"

A filtered export does not necessarily contain all rows represented by the original table statistics.

Consequently, the statistics associated with the complete table may not accurately describe the exported subset.

If QUERY is being used, investigate this possibility before changing character-set configuration.

Step 11 – Check Whether Partition Filtering Was Used

If the source database contains partitioned tables, determine whether the export includes complete tables or only selected partitions.

Partial exports can result in statistics that do not accurately represent the data contained in the export file.

Check the export log for table and partition information.

Step 12 – Review the Export Log Carefully

Open the export log and search for:

EXP-
ORA-

Pay particular attention to messages appearing immediately before or after:

EXP-00091: Exporting questionable statistics

If another error occurs at the same time, it may provide the actual reason for the warning.

Step 13 – Determine Whether the Export Completed

Check the end of the export log.

A successful Classic Export normally ends with an export completion message.

Do not determine success solely by looking at whether EXP-00091 appeared.

Instead verify:

Export process exit status.
Export log completion message.
Dump file existence.
Dump file size.
Any accompanying errors.
Whether all required objects were exported.

Step 14 – Check the Dump File

After the export, verify that the dump file exists and has a reasonable size.

For example:

ls -lh /backup/scott.dmp

The file size by itself does not prove that the export is valid, but it is a useful basic verification step.

Step 15 – Understand the STATISTICS Parameter

Classic Export provides the STATISTICS parameter for controlling whether optimizer statistics are included in the export.

Depending on the Oracle version, supported values can include:

STATISTICS=ALWAYS
STATISTICS=SAFE
STATISTICS=NONE

The exact behavior and available values should be verified using the exp help=y output for the Oracle version being used.

STATISTICS=NONE

The most commonly used workaround for EXP-00091 is:

STATISTICS=NONE

This tells Classic Export not to export optimizer statistics.

For example:

exp system@ORCL \
    owner=SCOTT \
    file=/backup/scott.dmp \
    log=/backup/scott.log \
    statistics=none

The exact command should be adapted to the requirements of your environment.

What Happens When STATISTICS=NONE Is Used?

The export still contains the database objects and data selected by the export operation, but optimizer statistics are not exported.

After importing the data into the target database, the DBA can gather fresh statistics appropriate for the target environment.

This can be a sensible strategy when the target database will have significantly different data distribution or execution characteristics.

When Is STATISTICS=NONE a Good Option?

Consider STATISTICS=NONE when:

The target database will have statistics gathered after import.
Source statistics are not required.
The export warning is specifically related to questionable statistics.
You are performing a migration where fresh target statistics are part of the migration plan.
The application has a defined post-import statistics-gathering procedure.

When Should You Investigate Further Instead?

Do not simply suppress statistics when:

The export contains other Oracle errors.
The export itself is incomplete.
Data rows are missing.
There are character conversion errors.
The export is being filtered unexpectedly.
The target system specifically requires preserved statistics.
The cause of the warning is still unknown.

Step 16 – Test the Export with STATISTICS=NONE

If your analysis indicates that statistics are not required, perform a controlled test.

For example:

exp system@ORCL \
    owner=SCOTT \
    file=/backup/scott_no_stats.dmp \
    log=/backup/scott_no_stats.log \
    statistics=none

Then inspect the new log.

Check whether:

EXP-00091 is no longer reported.
All required objects were exported.
The export completed successfully.
No new errors were introduced.

Step 17 – Compare the Two Export Logs

If possible, compare the original export with the export performed using STATISTICS=NONE.

Check	Original Export	STATISTICS=NONE
Export completed	Verify	Verify
EXP-00091	Possibly present	Should not be generated because statistics are not exported
Other ORA errors	Check	Check
Required tables	Verify	Verify
Dump file	Verify	Verify

Step 18 – Import into a Test Database

A successful export should ideally be validated by importing it into a non-production test database.

For a Classic Import:

imp system@TEST \
    file=/backup/scott_no_stats.dmp \
    log=/backup/scott_import.log

Use an appropriate test environment and adapt the command to your Oracle version and migration requirements.

Step 19 – Validate Imported Objects

After importing, verify:

Tables exist.
Expected row counts are present.
Indexes exist.
Constraints exist.
Sequences and other required objects exist.
Application queries work correctly.
No unexpected import errors occurred.

For important migrations, compare source and target row counts for critical tables.

Step 20 – Gather Fresh Statistics After Import

If statistics were intentionally excluded from the export, gather appropriate statistics after the import.

For example, on supported Oracle releases:

EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
    ownname => 'SCOTT'
);

For production environments, do not blindly execute schema-wide statistics gathering without considering the application's maintenance strategy, workload, object size, and existing statistics preferences.

Classic Export vs Data Pump Export

Another important consideration is the age of the Classic Export utility.

Oracle provides two major generations of export technology:

Technology	Utility	Typical Use
Classic Export	`exp`	Legacy Oracle environments
Data Pump Export	`expdp`	Modern Oracle Database export/migration operations

For Oracle Database versions that support Data Pump, DBAs should generally evaluate whether expdp/impdp is the more appropriate migration technology.

However, legacy Oracle EBS environments and older database versions may have application-specific requirements that must be considered before changing migration technology.

Do Not Mix exp and expdp Dump Files

Classic Export and Data Pump Export are different technologies.

A dump file created by:

exp

is not the same format as a dump file created by:

expdp

Likewise, the corresponding import utilities are different:

imp
impdp

Always use the appropriate import utility for the export technology that produced the dump file.

Part 2 Summary

A reliable investigation of EXP-00091 should begin with the export command, Oracle utility version, Oracle Home, client NLS configuration, database character sets, export filters, and the complete export log.

If statistics are not required in the target environment, using:

STATISTICS=NONE

can be an appropriate solution.

However, the DBA should understand that this removes optimizer statistics from the export. Fresh statistics may then need to be gathered after import.

Next: Part 3

Part 3 will provide the final recommended solutions, production-safe export procedure, validation checklist, troubleshooting matrix, common mistakes, FAQs, and final Oracle DBA recommendations for EXP-00091.

Solution 1 – Correct the Client Character-Set Configuration

If investigation shows that the export client is using an inappropriate character-set configuration, correct the client environment rather than modifying the database character set.

First identify the current value:

echo $NLS_LANG

Then compare it with:

SELECT parameter,
       value
FROM nls_database_parameters
WHERE parameter IN (
    'NLS_CHARACTERSET',
    'NLS_NCHAR_CHARACTERSET'
);

The objective is not necessarily to make the values identical. The objective is to ensure that the Oracle client is configured correctly for the operating-system locale and the data being processed.

Important:

Do not change NLS_CHARACTERSET simply because NLS_LANG differs. Client/server character-set differences are normal when Oracle can perform the required conversion.

Solution 2 – Remove an Unnecessary QUERY Filter

If the export uses a QUERY clause and the filter is not required, consider performing a complete table export.

For example, instead of:

QUERY="WHERE STATUS='ACTIVE'"

perform a normal table/schema export when the business requirement allows it.

This allows the exported data and statistics to represent the complete table rather than a filtered subset.

Solution 3 – Avoid Unnecessary Partial Partition Exports

If the warning is associated with a partitioned table, verify whether only selected partitions are being exported.

If the migration requires the entire table, export the complete table rather than an arbitrary subset of partitions.

If a partial partition export is intentional, document that the optimizer statistics associated with the complete source table may not be appropriate for the exported subset.

Solution 4 – Use STATISTICS=NONE

When the statistics themselves are not required, the simplest practical solution is:

STATISTICS=NONE

For example:

exp system@ORCL \
    owner=SCOTT \
    file=/backup/scott.dmp \
    log=/backup/scott.log \
    statistics=none

This prevents Classic Export from exporting optimizer statistics.

After importing the objects and data into the target database, the DBA can gather fresh statistics as part of the post-migration process.

Why STATISTICS=NONE Can Be a Good Migration Strategy

Optimizer statistics are environment-dependent.

The source database and target database may have different:

Hardware.
Storage systems.
Data volumes.
Data distributions.
Indexes.
Optimizer parameters.
Database versions.
Workloads.

Consequently, preserving source statistics is not always desirable.

In a controlled migration, it can be preferable to import the objects and data and then gather statistics specifically for the target environment.

Production-Safe Export Procedure

When running a production export, use a controlled procedure rather than executing a command and assuming that the dump file is valid.

1. Record the Environment

Document:

Oracle Database version.
Oracle Home.
Operating-system version.
Oracle Client version.
Database service.
Character sets.
Export utility version.

2. Record the Export Scope

Document:

Schema(s).
Tables.
Partitions.
Filters.
Expected data volume.
Required metadata.

3. Verify Disk Space

Before starting the export, verify that sufficient space is available for the dump file and log.

df -h

4. Run the Export

Use the appropriate export command for the Oracle version and migration requirements.

5. Monitor the Log

Do not wait until the export finishes to discover errors.

Monitor the export log for:

EXP- messages.
ORA- errors.
Unexpected table errors.
Connection failures.
Permission errors.

6. Verify Completion

Confirm that the export process completed successfully.

7. Validate the Dump

Where possible, import the dump into a non-production environment.

Post-Import Validation

If STATISTICS=NONE was used, the post-import validation should include statistics management.

First confirm that the expected objects were imported.

Then check row counts for important tables.

For example:

SELECT COUNT(*) FROM important_table;

Compare the result with the source environment where appropriate.

Gathering Statistics After Import

If the migration strategy intentionally excludes optimizer statistics, gather fresh statistics after the data has been imported and validated.

For example:

EXEC DBMS_STATS.GATHER_SCHEMA_STATS(
    ownname => 'SCOTT'
);

For large production databases, statistics gathering should be planned carefully.

Consider:

Maintenance windows.
Table size.
Existing statistics.
Application workload.
Incremental statistics requirements.
Histograms.
Partitioning.
Oracle version.

Verify the Statistics After Import

You can inspect table statistics using:

SELECT owner,
       table_name,
       num_rows,
       blocks,
       last_analyzed
FROM dba_tables
WHERE owner = 'SCOTT'
ORDER BY table_name;

If you do not have access to DBA_TABLES, use ALL_TABLES or USER_TABLES according to your privileges.

Do Not Modify the Database Character Set to Fix EXP-00091

Production Warning

Do not change the database character set merely to eliminate an EXP-00091 warning.

A database character-set migration is a major database operation and can have consequences for existing data and applications.

Always identify whether the problem actually originates from the client character-set configuration before considering any database-wide character-set change.

Common Mistakes

1. Assuming EXP-00091 Means the Dump Is Corrupt

The warning concerns questionable optimizer statistics. It does not by itself prove that the exported data is corrupt.

2. Changing the Database Character Set Immediately

This is an unnecessarily invasive response to a warning that may be caused by the client or export configuration.

3. Ignoring the Export Log

An accompanying ORA- or EXP- error may reveal the actual problem.

4. Changing NLS_LANG Randomly

Do not choose an NLS_LANG value simply because it removes an error.

The setting must reflect the client environment and required character encoding.

5. Using Classic Export for New Migration Projects Without Evaluation

For supported Oracle Database versions, evaluate whether Data Pump is more appropriate for the migration.

6. Treating STATISTICS=NONE as a Universal Fix

Suppressing statistics can remove the warning, but it does not explain why the statistics were questionable.

If statistics are important to the migration, investigate the underlying cause instead.

Troubleshooting Matrix

Symptom	Possible Cause	Recommended Action
EXP-00091 only	Questionable optimizer statistics	Review statistics requirements and consider `STATISTICS=NONE`.
EXP-00091 with character conversion errors	Client/server character-set configuration	Check `NLS_LANG`, database character sets, and client configuration.
EXP-00091 with QUERY clause	Statistics do not represent filtered data	Review or remove the filter where appropriate.
EXP-00091 on partitioned data	Partial partition export	Review partition scope and statistics requirements.
Export terminates with additional errors	Underlying export/database problem	Investigate the additional errors first.
Export completes but target performance is poor	Inappropriate or missing target statistics	Gather appropriate statistics after import.
Multiple Oracle installations	Wrong client utility	Check `which exp`, `ORACLE_HOME`, and utility version.

Frequently Asked Questions

What is EXP-00091?

EXP-00091: Exporting questionable statistics is a warning generated by Oracle's Classic Export utility when optimizer statistics being exported are considered questionable.

Does EXP-00091 mean that my export failed?

No. The warning does not by itself mean that the export failed. Always check the complete export log and completion status.

Can I ignore EXP-00091?

It depends on the migration requirements. If the export data is complete and source optimizer statistics are not required, the warning may be acceptable. If statistics are important, investigate why Oracle considers them questionable.

Does STATISTICS=NONE fix EXP-00091?

It can prevent the warning because optimizer statistics are not exported. However, it is better to understand the reason for the warning before choosing this approach.

Will STATISTICS=NONE remove my table data?

No. The parameter controls optimizer statistics; it does not mean that the table data itself is excluded from the export.

Should I gather statistics after using STATISTICS=NONE?

If the target database requires optimizer statistics, gathering fresh statistics after import is generally the appropriate approach.

Can NLS_LANG cause EXP-00091?

Yes. Client/server character-set configuration can be one cause of questionable statistics. However, an NLS_LANG difference does not automatically indicate an incorrect configuration.

Should NLS_LANG match NLS_CHARACTERSET exactly?

Not necessarily. They represent different layers of Oracle's globalization architecture. The client character set should correctly represent the client environment and the required character conversion.

Should I change NLS_CHARACTERSET to fix this warning?

No—not as a routine troubleshooting step. Database character-set changes require careful assessment because they can affect existing data and applications.

Is Classic Export still recommended?

Classic Export is a legacy technology. For supported Oracle Database versions, evaluate Oracle Data Pump (expdp/impdp) for modern export and migration requirements.

Final DBA Checklist

☐ Record the exact exp command.
☐ Check the Classic Export utility version.
☐ Check ORACLE_HOME.
☐ Check which exp executable is being used.
☐ Check NLS_LANG.
☐ Check the operating-system locale.
☐ Check NLS_CHARACTERSET.
☐ Check NLS_NCHAR_CHARACTERSET.
☐ Review the complete export log.
☐ Look for additional ORA- or EXP- errors.
☐ Check whether QUERY was used.
☐ Check whether partial partitions were exported.
☐ Confirm that the export completed successfully.
☐ Verify the dump file.
☐ Determine whether source statistics are actually required.
☐ Consider STATISTICS=NONE when appropriate.
☐ Test the dump in a non-production environment.
☐ Validate imported objects and row counts.
☐ Gather fresh statistics when required.
☐ Avoid unnecessary database character-set changes.
☐ Evaluate Data Pump for supported modern environments.

Key Lessons for Oracle DBAs

The most important lesson from EXP-00091 is that a warning about optimizer statistics should not automatically be treated as a data-export failure.

The correct troubleshooting approach is to determine whether the statistics are questionable because of:

Client character-set configuration.
Export filtering.
Partial table or partition exports.
Other export conditions.

Once the cause is understood, the DBA can decide whether to preserve the statistics or deliberately exclude them and regenerate statistics in the target environment.

This is especially important during Oracle database migrations. Optimizer statistics that were appropriate for the source database may not necessarily be appropriate for the target database.

Recommended Approach for the Original Case

For the original Oracle Database 11.2.0.4 case documented in this article, the practical workaround was:

STATISTICS=NONE

This remains a useful option when the migration does not require source optimizer statistics and fresh statistics can be gathered after import.

However, the modern DBA approach should go one step further: determine why Oracle reported the statistics as questionable, verify the client and database NLS configuration, review the complete export log, and then make an informed decision.

Final Recommendation

Do not blindly suppress the warning and do not change the database character set just to make EXP-00091 disappear. First identify the cause, verify that the exported data is complete, decide whether optimizer statistics are required, and then either correct the underlying configuration or deliberately export without statistics and gather fresh statistics after import.

About the Author

Rana Abdul Wahid is a seasoned Oracle DBA Consultant with more than 15 years of Oracle Database experience.

His expertise includes:

Oracle Database Administration
Oracle E-Business Suite Application DBA
Oracle OCI Cloud DBA
MySQL
Microsoft SQL Server
PostgreSQL
Odoo ERP
Linux / Unix / Ubuntu / Windows Administration

His blog focuses on practical Oracle Database, Oracle E-Business Suite, Linux, troubleshooting, administration, backup and recovery, performance, and enterprise infrastructure solutions.

Learn more about the author →

Conclusion

EXP-00091: Exporting questionable statistics is a warning that deserves investigation, but it should not immediately be interpreted as a failed export or corrupted database.

Start by reviewing the complete export log and identifying the exact export environment. Check the Classic Export utility version, Oracle Home, client character-set configuration, database character sets, export filters, and partition scope.

If the statistics are not required in the target environment, STATISTICS=NONE can be a practical and controlled solution. After importing the data, fresh optimizer statistics can be gathered for the target environment.

Most importantly, avoid making unnecessary database-wide changes to solve a client-side or export-configuration problem.

A good Oracle DBA does not simply remove the error message—the DBA identifies the underlying cause, evaluates the impact, applies the smallest appropriate change, and validates the result.

Technical Note: Oracle Classic Export (exp) is a legacy export technology. Oracle Database versions and supported migration procedures differ. Always verify the applicable Oracle documentation for your exact database release before performing production export/import operations.

Disclaimer: Oracle, Oracle Database, Oracle E-Business Suite, SQL*Plus, Data Pump, and related product names are trademarks of Oracle Corporation. The procedures shown here are provided for technical guidance. Always test changes in a non-production environment and consult the applicable Oracle documentation and My Oracle Support resources for your specific Oracle Database version and application environment.

Oracle Database Error Solutions & DBA Knowledge Base