Recently, when running Dbvisit with Oracle 11g, we encountered the following error under certain circumstances with one of our standby databases:

 ORA-27048: skgfifi: file header information is invalid

This error suggests that Oracle is possibly trying to use a non-database file as a database file. However we were pretty sure that this was not the case.

As part of normal Dbvisit processing, Dbvisit can issue the statement “SQL>recover standby database …” to bring the standby database up to date. It was at this point that the error was occurring. Our thanks goes to one our team members, Vit Spinka who determined the cause of the error:

When the “recover standby database …” SQL statement is issued in 11g, Oracle scans the entire archive log:
/oracle/app/oracle/flash_recovery_area/<dbname>/archivelog
directory when Flash Recover Area (FRA) is used.

Any files that are not Oracle related will cause the ORA-27048 error. So any archive files that are compressed will cause this error, even if it is an old archive log that is completely irrelevant.
So this error is occurring because there are archives in FRA that are compressed. Uncompressing those archives will stop the error.

With Dbvisit this error only occurs once Graceful Switchover has been initiated twice. It is only at this point that there will be compressed archive logs in FRA on the standby server. Before switchover has occurred, the standby database will not have any archive files in its FRA as the standby database does not produce archive log files. After switchover the new primary (old standby) will start producing archive log files.  Then when another switchover occurs to bring the configuration back to its orginal state, the original standby will have archive log files in its FRA. If those archives are compressed then the ORA-27048 error will occur.

So, what is the solution?
There are several options to solve this issue:

  1. Stop Oracle from scanning the FRA by setting the following command in the Dbvisit Database configuration (DDC) file: 
     _SQL_ALTER_SESSION_1 = set logsource "/oracle/oraarch/xxxx"

    (It does not really matter what logsource is set to)
    You can add this to the end of the DDC file. Setting this does not have any impact, nor do you lose any Dbvisit functionality. Remember to alway edit the DDC file on the primary server only. Dbvisit will replicate the DDC file to the standby server when changes are detected.

  2. Leave the archives uncompressed on the servers. The archives will be still be compressed before transfer.
    Update the DDC file and set the following:

     LEAVE_COMPRESS_SOURCE = No
     LEAVE_COMPRESS_DEST = No

It is always interesting to see how Oracle can modify its behaviour between different releases, and sobering to consider how changes like this really have the potential to catch you out. One of the great benefits of having a team like Dbvisit Support on your side is that they keep up to date with the latest Oracle changes, and are committed to ensuring that Dbvisit functions seamlessly with the database – maintaining the same great high level of protection and continuity for your systems. And this safety net equals peace of mind, for you, the customer.