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.
Share this
You May Also Like
These Related Stories
No Comments Yet
Let us know what you think