Re: corrupt sysaux file - best way to fix

SG wrote:
> Hi all.
> I posted some time ago about corrupt redo logs and still am working
on
> finding the cause. I did find that the sysaux datafile also has
corrupt data
> per the logs. What is the best way to correct this without backups?
> Dbrepair? I ask this because the original dba setup a routing to
purge
> backups older than 7 days since the data is not needed after so many
days.
> This is more of a dynamic database application and not for historical

> purposes. However, if the sysaux datafile is corrupt, we are most
likely
> skipping or backing up a corrupt sysaux file, correct? Any insights?
This is
> on Redhat v3, 10g Standard v10.1.0.2. Can this be at all linked to
having
> random corrupt redo logs? Do we need to rebuild the database from
scratch as
> a best approach to fixing the sysaux corruption, which we did once
with a 1
> month success time frame, only to start getting corrupt redo logs
again? Any
> ideas are greatly appreciated. TIA.
>
> SG

I can safely presume this is the post to which you refer, posted two weeks ago and, apparently, without benefit as you didn't follow the same advice given you then (that, or you expect a different answer for the same problem because the last one didn't suit you):

• Hi all. *
• I am new to Oracle so would appreciate any insight as to what are main
• reasons based on your experience that cause corrupt redo log files and data
• files? We had a corrupt sysaux.dbf file and constant corrupt redo logs that
• would stop our application since it was in archive mode and we'd get
• archiver errors. We tried creating new log groups and that didn't help. We
• had to constantly clear unarchived log groups,etc. to get it working. We
• rebuilt the database and used a dmp from the "suspect" dbase to import our
• custom talbles in our newly created db and tablespace. All had been fine for
• a month, but now it's happening again. I looked in the alert logs and see
• that now we have a corrupt system.dbf file. Has anyone had this type of
• experience? We are running Oracle 10g on Redhat ES 3.0. The kernel version
• on the system is 2.4.21.4. An identical system with no problems, same
• hardware, is running kernel version 2.4.21-15.0.3. Seems to point to a
• hardware issue maybe? Any ideas would be grealty appreciate. TIA. *
• SG

Let's look at one statement you made in that post:

• The kernel version
• on the system is 2.4.21.4. An identical system with no problems, same
• hardware, is running kernel version 2.4.21-15.0.3.

The kernels are obviously different, yet you contend this is a HARDWARE issue. How can that be, really, when you've said the hardware is the same between the two systems. My guess is it's a kernel issue, and the kernel needs to be patched to the same level as your working system. Had you mentioned both kernels were at the same patch level then I might be persuaded to believe suspect hardware. At the moment I'm expecting it's a kernel problem, not a hardware problem, as that is where the two systems differ. Patch your kernel on the errant system to the same level as your working one and see what happens. Should that NOT correct the issue THEN investigate the hardware.

David Fitzjarrell Received on Tue Mar 29 2005 - 23:36:12 CST