2 Replies Latest reply on Apr 6, 2010 8:14 PM by 637288

    Recovery failure


      I saw this problem in some other threads, but didn't find a solution though.
      I'm working with DBXML 2.5.16/BDB 4.8. I somehow corrupted environment or a DB XML container. When I'm running recovery (from a command line) I get these errors:

      db_recover: Log sequence error: page LSN 69 2353362; previous LSN 69 2363102
      db_recover: Recovery function for LSN 69 2363150 failed on forward pass
      db_recover: PANIC: Invalid argument
      db_recover: PANIC: fatal region error detected; run recovery
      db_recover: xml_content.dbxml: write failed for page 2226
      db_recover: xml_content.dbxml: unable to flush page: 2226
      db_recover: process-private: unable to find environment
      db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery

      Is there any way how to recover it, assuming that I don't have a backup?

        • 1. Re: Recovery failure
          "Oracle, Sandra Whitman-Oracle"

          A log sequence error is generated by the recovery code when a log record references a database
          page but the Log Sequence Number on the page is less than the LSN that is recorded in the log record.

          In your case the LSN in the log record: previous LSN 69 2363102

          is greater than the LSN of the actual record: page LSN 69 2353362

          This situation indicates that the database is inconsistent with the information in the log.

          You can try using db_dump/db_load to restore the database. You could try using
          db_load with -r lsn flag to reset the LSNs in the file.


          Are you using DB_PRIVATE? If so is there any way you could have more than one process
          accessing the same database and log files?

          • 2. Re: Recovery failure
            Hi Sandra,

            thanks for your reply. Indeed, dumping and loading solved the problem. Good to know. Although I would rather prefer that recovery would be able to handle such situations :)

            Concerning your questions: when such a failure happened, I didn't use the PRIVATE environment. Then, however, I tried to recover it with DB_PRIVATE and no other processes were accessing the environment or database files. Just doing db_load -r lsn db.file didn't solve my issue.