Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> I'm doomed, right?

I'm doomed, right?

From: broom <broom_at_voicenet.com>
Date: 4 Oct 2001 19:45:37 -0700
Message-ID: <c948eb61.0110041845.282c65e7@posting.google.com>


Sun 450, 3 CPU, Solaris 7, Oracle 7.1.5

Simple select, ie:
select count(*) from ind_0109

Causes:

ksedmp: internal or fatal error
ORA-07445: exception encountered: core dump
[memcpy()+28] [SIGSEGV] [Address not mapped to object]
[0] [] []

This is a 35 million row table.

It is repeatable.
Currently opened a TAR, but hoping someone can shed some light.

We recently had a disk array problem (someone turned off the wrong array, SMACK), which in turned caused me to have Oracle support guide me through an online recovery. We ended up supplying the current active online log as the log to "recover" from. Was interesting.

Note: This instance does not have archivelog mode on, since it is almost strictly data warehousing with huge loads. I use Veritas file level snapshots for backup, which means all or nothing for a restore.

We then shut the base down "normally", and brought it backup up, and it seemed OK. Then we found that a TEMP sort tablespace no longer had files associated with it. Scary.

Now this hit.

Data files live on a Veritas volume, accessed via Veritas Oracle DB Edition "raw" files.

Do I trash the whole system, rebuild the data files, and restore from export (slow). Is there a way to check the integrity of all the files?

We have not bounced the instance (yet). Should I? Should I be scared to?

It actually "feels" OK (the table itself) since I can do an 'exp' of the table (at least I'm about 25% done right now).

I attempted the same select count(*) from another table and got the same abort. Received on Thu Oct 04 2001 - 21:45:37 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US