crashed Database! 
Author Message
 crashed Database!
Hi,
We have a big problem. There is a database without a actual checkpoint
etc.....
This database crashed, no chance to activate it again.
There is a backup of the files in the data-directory and a very old
checkpoint.
how can i restore some tables? is there a tool or methode to recover some
data from the files in the data-directory or is there a commecial service
which can recover such a crashed database?
every hit are very welcome
thanks
Paul


Sun, 18 Jul 2004 21:03:43 GMT
 crashed Database!

the OS is WINT!!
 Paul


Sun, 18 Jul 2004 23:43:08 GMT
 crashed Database!
Hi Paul,

Quote:

> Hi,
> We have a big problem. There is a database without a actual checkpoint
> etc.....
> This database crashed, no chance to activate it again.

    What makes you say that? Has the data disk exploded?

Quote:
> There is a backup of the files in the data-directory and a very old
> checkpoint.

    Hmmm,  How old is very old?

Quote:
> how can i restore some tables? is there a tool or methode to recover some
> data from the files in the data-directory or is there a commecial service
> which can recover such a crashed database?
> every hit are very welcome

    Given you have a dump of the files in the data directory then with some
    luck you should be able to restore the database. With high quality - you
    lucky bastard - sort of luck the database may even be consistent.

    The complications that can arise are:
    1. Was the database active during the dump of the database area?
        If not then your dump will accuratly repesent the database at the time
        of the dump. You got real lucky!

        If it was active then their is a very good chance that you'll lose
        referential integrity through the database. In which case, ask
        yourself if the very old checkpoint may be a preferable recovery
        option.

    2. Was the database active at the time of the crash?
        If so there may be records in the DMF cache that just CANT be applied to
        the database. Furthermore, the log file records the database as being
        opened.

    Assuming you decide to go ahead with the daatabase backup recovery
    option...
    Before you start the recovery of the lost database I would suggest you:
    Back up every other database in the installation!
        Note that a ckpdb forces a CP through the DMF cache. The CP may
        struggle with any pages for the lost database. This wont effect any of
        the good databases - I think. The errlog may get fairly{*filter*}with DMF
        errors at this point.

        Furthermore it will drain journals relevant to each database from the
        LOG file. This will be useful as you'll see later.

    Now we should be able to restore the database backup to its correct
    location.

    Part of the database backup is the data area configuration file:
        'aaaaaaaa.cnf'
    There should be a dump area configuration file, also called
    'aaaaaaaa.cnf'. This will not be in your database backup, with luck it is
    on disk.
    If so:
        Move the dump area config file aside and copy the database area
        config file into the dump area.
    If not - and the dump directory for this database exists:
        Copy the database area config file into the dump area.

    We should now have a config file that represents the database at the time
    the backup was taken. Verify this by doing an: infodb <dbname>
    However, it has probably lost sync with the log file in which case it will
    be marked inconsistent.

    So...

    Shutdown the installation. Reformat the log file and restart the
    installation.

    Check for inconsistent databases in the installation using:
    1. logstat
    2. verifydb -mreport -sinstallation -oaccess_check

    Hopefully only your lost database is marked inconsistent. At this point I
    dont think it matters to just force it consistent with:
        verifydb -mrun -sdbname <dbname> -u<dbowner> -oforce_consistent

    You should now be able to connect to your database. Try a simple SQL
    connection.

    Assuming all of this has worked, you can now checkpoint the database
    properly.

    Having completed that, you can now satrt the fun task of working out
    exactly how bad the data loss in the database has been. There, you are
    probably on your own.

Quote:
> thanks
> Paul

    Best of luck,

    Martin Bowes

    PS. I should probably state this is just my opinion, not my employers, and
    even so don't hold me to it!

--
Random Earthworm Jim Quote #17:
Bob(The Killer GoldFish) -
    If you want something done right, hire a guy with a monkey for a head.
    Thats what I always say.



Mon, 19 Jul 2004 06:53:36 GMT
 
 [ 3 post ] 

 Relevant Pages 

1. Help with crashed database

2. Restart a crashed database

3. Help restore a tablespace from crashed database

4. HELP with Crashed Database

5. start a crashed database?

6. ora-1172 on personal oracle - crashed database.

7. update statistics crashes database server

8. findany crashes database, Why???

9. Recovering a connection pool from a crashed database

10. Trigger crashes database ! Please Help !

11. Can we use .ldf file to restore a crashed database?

12. ODBC database crashing accessing progam going for an access database


 
Powered by phpBB® Forum Software