Missing archives and or corrupt archives
We are unable to run Dbvisit Standby on the DR because the 1_659978.dbf.gz is corrupted (0 bytes)
[oracle@ora1-idb CLIENTID]$ ls -al | more
-rw-r----- 1 oracle oracle 9146653 Aug 8 09:40 1_659968.dbf.gz
-rw-r----- 1 oracle oracle 8443809 Aug 8 09:42 1_659969.dbf.gz
-rw-rw---- 1 oracle oracle 6006003 Aug 8 09:44 1_659970.dbf.gz
-rw-rw---- 1 oracle oracle 9538276 Aug 8 09:46 1_659971.dbf.gz
-rw-r----- 1 oracle oracle 9501391 Aug 8 09:48 1_659972.dbf.gz
-rw-r----- 1 oracle oracle 7663412 Aug 8 09:50 1_659973.dbf.gz
-rw-r----- 1 oracle oracle 7878424 Aug 8 09:52 1_659974.dbf.gz
-rw-rw---- 1 oracle oracle 7193908 Aug 8 09:54 1_659975.dbf.gz
-rw-rw---- 1 oracle oracle 6615136 Aug 8 09:56 1_659976.dbf.gz
-rw-r----- 1 oracle oracle 9174960 Aug 8 09:58 1_659977.dbf.gz
-rw-rw---- 1 oracle oracle 0 Aug 8 10:07 1_659978.dbf.gz
-rw-rw---- 1 oracle oracle 19790353 Aug 8 12:00 1_659979.dbf.gz
-rw-r----- 1 oracle oracle 6378389 Aug 8 12:04 1_659980.dbf.gz
-rw-rw---- 1 oracle oracle 19870939 Aug 8 12:11 1_659981.dbf.gz
And, because this archivelog was deleted from primary server, I am afraid our DR database is completely lost now, and we will have to rebuild it.
If you do not have a copy of this archivelog on a backup then there is something else you can try before going through and recreating that standby database - and this is an RMAN incremental backup.
We have outlined this process in the following 2 blog posts - and we would also encourage you to sign up to the blog if you have not done so already:
This incremental backup (or resynching) functionality is also available in Dbvisit Standby 6.0.34. The whole process has been completely automated.
You do not have to have RMAN backups in place to use this method. It is able to use RMAN - behind the scenes - to incrementally bring the standby database up to date with the primary outside of the archive log mechanism.
There are some restrictions around this - based on things like the Oracle version in use - and we mention those in the articles. But it is worth bringing to your attention in the case that it might be something you could try before proceeding to recreate the standby database. If nothing else this is an option that may be available to you for now (potentially) and in the future.
It is difficult to say exactly what has happened with the log file - but there are checks in place in our application around file size (which look to have passed) so maybe the file itself has been delivered to the DR site - but corruption has occurred with the network outage occurring during this process. The checks are quantitative - so that the file appears to be intact and the correct size - but not qualitative - which will not be able to be determined until the apply process itself is run.
|Thread Tools||Search this Thread|