Try sending the archive log again, it may have been corrupted in transit. If the redo log that generated this archive log has not been overwritten, make a copy of it and try to apply it to the standby. *Do this quickly if it is not too late...
Aside from that, you have a bigger problem. Obviously, your standby database is now stopped at a point in time and cannot be moved forward. However, if the archive log is corrupted at the primary site, your database is now unrecoverable at that time the archive log needs to be applied. If you had a failure and needed to apply that log, you are in the same situation. There is a known bug (see note 50581.1 on metalink) that causes archive log corruption. If you have different settings for async_read and async_write, you can corrupt the archive logs. The metalink note indicates that it is corrected in 7.3.4.1, but I recall seeing it in later versions on the solaris platform. The command to verify the ability to read the archive log is ALTER SYSTEM DUMP LOGFILE 'filename'. It uses the same algorithm as the recovery process. Daniel W. Fink Sr. Oracle DBA MICROMEDEX 303.486.6456 -----Original Message----- Sent: Thursday, June 20, 2002 10:23 AM To: Multiple recipients of list ORACLE-L Dear list, we have a stand by database in prod where we apply archive logs. one of the redologs got a corruption and generated a trace file. is there a way to fix this redolog or find where the problem is thanks in advance. Sarath. ----------------------- Oracle7 Server Release 7.3.4.0.1 - Production With the distributed and parallel query options PL/SQL Release 2.3.4.0.0 - Production ORACLE_HOME = /opt/oracle/product/7.3.4 System name: SunOS Node name: oraprod Release: 5.6 Version: Generic_105181-31 Machine: sun4d Instance name: vision Redo thread mounted by this instance: 1 Oracle process number: 9 Unix process pid: 10366, image: oracleRPT *** SESSION ID:(10.4355) 2002.06.19.02.54.54.000 *** Corrupt block dba: 0x28400001 file=74. blocknum=1. found during data file header read on disk type:108. ver:108. dba: 0x6c6c6c6c inc:0x6c6c6c6c seq:0x6c6c6c6c incseq: 0x00010002 on disk checksum=0x6c6c, calculated checksum=0xffcd on disk type=108., expected type=11. "oa" [Read only] 24 lines, 817 charactersm=1. found same corupted data ------------------------------ __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: sarath kumar INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Fink, Dan INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
