Prev: Exec statement
Next: CBO influences
From: Stan Brown on 9 Sep 2005 10:41
Oracle version 7.3.4.5.0 on HP-UX 10.20 (yes I know it's ancient :-)

Last night (perhaps during a hot backup, I'm not certain yet), our Oracle
instance came to a halt. The trace file has this, and:

ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900],
[], [], []
ORA-00447: fatal error in background process
ORA-00600: internal error code, arguments: [2103], [0], [0], [1], [900],
[], [], []

In it. I managed to connect with svrmgrl, and do a "shutdown abort" Now,
I'm working on getting a complete set of cold backups of the system as is.

I've looked at the hardware, and I cannot find any problems with it. The
hot backup, and a subsequent dump are sent to a remote machine which is
mounted via NFS.I see errors in dmesg out NFS server timeouts, so I strongly
suspect this is the root cause of the disaster.

I've got several questions for the gurus here.

1. Besides a complete set of backups, is there anything else I should do to
prepare for a recovery attempt?

2. What steps should I plan on taking for the recovery attempt?

3. Is their any _safe_ way to find out if any tablespaces were left in
backup mode, prior to getting the backups? I ask this because it's likely
to take 2 to 3 days to get the backups using the methodology I'm familiar
with, and I really don't think this is the time to depend on an untested
backup technique.

I welcome any suggestions.

Thanks.

--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
From: jkstill on 9 Sep 2005 11:31
To answer question #3:

You may startup the database in mount mode and run the following SQL
to generate SQL that may be used to take datafiles out of backup mode.

select 'alter database datafile ' || '''' || f.name || '''' || ' end
backup;'
from v$datafile f, v$backup b
where b.status = 'ACTIVE'
and f.file# = b.file#;

This can be done before or after the backup.

From: Stan Brown on 9 Sep 2005 12:28
In <1126279871.743116.258320(a)g49g2000cwa.googlegroups.com> jkstill(a)gmail.com writes:

>To answer question #3:

>You may startup the database in mount mode and run the following SQL
>to generate SQL that may be used to take datafiles out of backup mode.

>select 'alter database datafile ' || '''' || f.name || '''' || ' end
>backup;'
>from v$datafile f, v$backup b
>where b.status = 'ACTIVE'
>and f.file# = b.file#;

>This can be done before or after the backup.


Thanks, and 2 follwoup questions.

1, Is it safe to do this before making the backups?
2. Since I only dealy with DBA'ing every couple of years, when something
goes wrong, I am very weak on this side of thisgs :-(. So, having admited
my ignorance :-), How do I "startup the database in mount mode" ?

Thanks for bbeing patient with me.
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
From: Stan Brown on 9 Sep 2005 12:39
In <1126279871.743116.258320(a)g49g2000cwa.googlegroups.com> jkstill(a)gmail.com writes:

>To answer question #3:

>You may startup the database in mount mode and run the following SQL
>to generate SQL that may be used to take datafiles out of backup mode.

>select 'alter database datafile ' || '''' || f.name || '''' || ' end
>backup;'
>from v$datafile f, v$backup b
>where b.status = 'ACTIVE'
>and f.file# = b.file#;

>This can be done before or after the backup.

I figured out how to get the DB mounted :-)

Then I rna the query above. It retruned zero rows. So I'm interpeting this
to mean that no tablespaces on this instance were in BACKUP mode when the
instance came down. Is this correct?

And if it is, would it be safe to try and startup the instance? I am in the
process of heading twoard a complete set of cold backups, but this will
take (at least) a couple of days.


--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
From: jkstill on 9 Sep 2005 12:52
1. yes, no rows returned shows that no tablespaces were in backup
mode.
2. starting the database should be fine.
3. you should probably make a good backup, for your own peace of mind.
A hot backup will be fine.

There appears to be a lot of information on that particular ORA-600.

The suggestions given seem like a good place to start.

You may want to take a look at IO contention, but the fact that your
control file was unavailable for 15 minutes and caused the instance to
crash suggests you may want to discuss this with the system
administrator as well.

Faulty HW could cause this. As you are on 7.3.4 there is reason to
suspect that this may be old HW as well. Is that the case?

 |  Next  |  Last
Pages: 1 2
Prev: Exec statement
Next: CBO influences