I once got the following from Oracle Tech support to deal with a corrupted
tablespace.
In the init.ora file add the following:
# This was used to ignore a corrupt tablespace
_allow_resetlogs_corruption=true
--
Terry Dykstra [TeamPS]
Canadian Forest Oil Ltd.
brian duart wrote in message <3598EB77.5D959AD8_at_mindspring.com>...
>Gentle People,
>
>We are attempting to salvage most of the data in this database. Oracle 7.2
on
>OpenVMS 6.1
>
>(1) we inherited a nearly non-documented oracle database in the throes of
>death, so we have very little information currently about the nature of the
>database configuration (ie. what tables exist in which tablespaces, and
what
>each of the datafiles are related to).
>
>(2) we lost an 8GB hard drive which contained three datafiles (which we are
>willing to sacrifice to the gods in order to bring the db back online). The
HD
>was restored, and a back-up of the three datafiles was restored as well
from tape.
>
>(3) when starting Oracle, it requests media recovery on the three files.
>
>(4) we have not been able to complete the media recovery process. The
database
>is in noarchivelog mode, AND there are no online redo log files to be found
>anywhere on the system. Thus, we can only cancel out of the recovery
process.
>
>(5) we tried dropping the datafiles offline and restarting the db, but in
this
>scenario oracle would not start, due to a missing table needed for
dml/query.
>Presumably this table is in one of the three datafiles, and judging from
the
>datafile names, I would guess it is an index.
>
>What we would like to do is: force the database to startup and mount,
>regardless of the state of those 3 datafiles, as we will be exporting one
main
>table and starting over on a different environment. We have poured through
all
>the scenarios in the Server Admin guide, but there is little guidance if
>recovery is not successful. We need concrete instructions to give to the db
to
>either drop the datafiles and have the db 'forget' them, or to make the
>recovery proceed without online redo logs.
>
>Hope someone can help.
>
>Regards,
>
>Brian
>
>____________________________________
>Brian Duart
>vox: (510) 649-4503 days
>mailto:bduart_at_mindspring.com
Received on Thu Jul 02 1998 - 13:35:07 CDT
