Results 1 to 6 of 6
  1. #1
    Join Date
    Apr 2004

    Unhappy Unanswered: lost database on an old system...

    The system is NT 4, both the database dumps and the master are on the D drive. The transaction log for the database resides on that drive as well.

    The drive was lost, but the drive where the database resides was not. After restoring the D drive (the tape was several days old) we cannot bring the database online.

    00:2004/04/13 09:55:51.46 server Recovering database 'main'.
    00:2004/04/13 09:58:41.84 server Error: 3401, Severity: 21, State: 1
    00:2004/04/13 09:58:41.84 server Rec_init: getnext SCAN_RID of last checkpoint failed on Rid from sysdatabases. Rid pageid = 0x297c16; row num = 0xf.
    00:2004/04/13 09:58:41.90 server Error: 3414, Severity: 21, State: 1
    00:2004/04/13 09:58:41.90 server Database 'main' (dbid 5): Recovery failed. Check the SQL Server errorlog for further information as to the cause.

    I've looked up the error and I see that basically gives me the option of loading from backups (which are 8 days old due to a failure in the backup system).

    I was hoping there was some way of making sybase work without loosing 8 days of work. Is there anyway of working around this?

  2. #2
    Join Date
    Nov 2002
    You said after restoring the tape. Is it that you loaded the database dump from 8 days old and you are getting this error OR you did something else. Pls. provide more info.

  3. #3
    Join Date
    Apr 2004
    Originally posted by mkalsi
    You said after restoring the tape. Is it that you loaded the database dump from 8 days old and you are getting this error OR you did something else. Pls. provide more info.
    The master database is from 8 days ago. The files that make up the database we are trying to access are intact and from yesterday.

    The drive that had the dumps and the master database was lost and restored from backup.

  4. #4
    Join Date
    Apr 2004
    This is one of madamos's co-workers...

    Here's the scoop on this problem.

    A database server that we support running Sybase had a drive failure yesterday afternoon. Below is the drive layout for the system

    C: OS and Sybase install files

    D: Master.dat, database transaction segments, database dump files

    E: database segments

    The database server's D drive had a hardware failure yesterday. The drive has now been replaced, but it appears that there are no good tape backups for this drive (The enterprise backup solution has not run properly since the 4th). In addition, any tape backups prior to the 4th of April do not appear to have valid dump files on them (wesuspect that the backup was run while the database was dumping, so the backups are invalid)

    Just to add injury to insult, it appears that something happened to the mirrors of master.dat and the transaction segment that we had placed on the C drive, and we cannot use those to restore the segment.

    We do have the database segments, but it appears that the transaction segments have been lost. Does anybody know if there is a way to recover the databases from this loss?

    Thanks in advance for your help

  5. #5
    Join Date
    May 2004
    If you know the layout of the databases with aspect to segments and devices you could recreate the server and create those databases empty.
    Before you do that you need to save the data files that the database devices consist of.
    Once you have the server up with the empty databases you can just stop it and replace the empy data files with the real ones.
    This works only if you can recreate the databases so that sysdevices is consistent between new and old.
    If you have a valid master dump you should be able to use it even if it's older than the databases provided no alter database command have been done between.

  6. #6
    Join Date
    Apr 2004
    As it turns out we used dbcc rebuild_logto recreate a blank log. We found this out on The syntax is dbcc rebuild_log (dbid, 1, 1)

    Somewhat dangerous. If you use it, be sure to run a full set of dbcc checks after.

    Some minor hiccups that had to be ironed out, but the database has been running stable for a while now. Minor disaster averted.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts