ORA-19665: Size in File Header Does Not Match Actual File Size of String

I received the above message related to an ORA-7445 on my 11.2.0.4 database: ORA-07445: exception encountered: core dump [kcflfi()+1016] [SIGFPE] [Integer divide by zero] [0x10053AD10] [] []

Situation

After some checks, I noticed the following:

SQL> select file_name, bytes from dba_data_files where file_id=106;

FILE_NAME                                         BYTES 
------------------------------------------------ --------------
+DATA/MYDB/DATAFILE/DATAFILE_XX.558.1015447173   14529069056

SQL> select name, bytes from v$datafile where file#= 106;

NAME                                             BYTES 
------------------------------------------------ --------------
+DATA/MYDB/DATAFILE/DATAFILE_XX.558.1015447173   14529067281

Does this mean  the database dictionary has different sizes for the data file?

I’d expect to have the same size for both queries, as the dba_data_files should be based on v$datafile.

Looking at MOS (My Oracle Support), it seems to be a match to ORA-07445: Exception Encountered (Doc ID 1958870.1).

So, what did resolve my case? After following  the MOS Doc, dropping and restoring the datafile fixed the views:

SQL> alter database datafile 106 offline to drop;
RMAN> restore datafile 106;
RMAN> recover datafile 106;
SQL> alter database datafile 106 online;

Result

This process actually fixed the inconsistency in my views:

SQL> select file_name, bytes from dba_data_files where file_id=106;

FILE_NAME                                         BYTES 
------------------------------------------------ --------------
+DATA/MYDB/DATAFILE/DATAFILE_XX.558.1015447173   14529069056

SQL> select name, bytes from v$datafile where file#= 106;

NAME                                             BYTES 
------------------------------------------------ --------------
+DATA/MYDB/DATAFILE/DATAFILE_XX.558.1904729421   14529069056

There are a few things you should be careful with when using this method:

• Make sure you have a backup before dropping the data file.
• Make sure you can put the data file offline or proceed during non-business hours.
• And of course, follow change procedures for production; things could get wild!

What if you don’t have a backup?

1. First of all, you may want to create one. The backup may fail however, considering the original mismatch.
2. Consider using Export/Import logically (Data Pump is recommended):

• Export the data from the related tablespace (Data Pump or Legacy Export—check for limitations and data types).
• Drop the tablespace and recreate it
• Import the data back.

I hope this helps—if you have any questions or thoughts, please leave them in the comments.

Make sure to sign up for more updates here.

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?