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] [] []
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;
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?
- First of all, you may want to create one. The backup may fail however, considering the original mismatch.
- 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.