• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1194
  • Last Modified:

Exchange 2000 DB has "dirty shutdown" state, then use ESEUTIL to repaire but corrupted, and event 9175

Hello subject matter experts,
It's very urgent case to be completed before coming business days. The problematic server is Exchange 2000 SP3 on Windows 2000 Server SP4 in FE/BE architechture, three operational databases.  On the mounted database has been experiencing event ID 9175 every minute. The server IS was terminated unexpectedly. When I discovered the problem and failed to restart IS service, the all three databases could not be mounted.  I use ESEUTIL to trying to detect and repair them individually, but now only one database could not be repaired. To serve service continuity for those two recovered databases, I started Exchange services for user access without problem (but yet event 9175 every minute). This problem happened two-three times during this seven days back.

The following are steps and result for the problematic database:
1- Stop Exchange services

2- ESEUTIL /mh
result...
Initiating FILE DUMP mode...
       Database: N:\Exchsrvr\MDBDATA\SAN Users Mailbox Store.edb

        File Type: Database
   ...
     DB Signature: Create time:05/13/2006 17:52:15 Rand:225904354 Computer:
         cbDbPage: 4096
           dbtime: 2 (0-2)
            State: Dirty Shutdown
     Log Required: 0-0
   Streaming File: Yes
         Shadowed: Yes
       Last Objid: 1
     Scrub Dbtime: 0 (0-0)
       Scrub Date: 00/00/1900 00:00:00
     Repair Count: 7
      Repair Date: 05/13/2006 17:52:15
  Last Consistent: (0x0,0,0)  00/00/1900 00:00:00
      Last Attach: (0x0,0,0)  05/13/2006 17:52:15
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:00/00/1900 00:00:00 Rand:0 Computer:
       OS Version: (5.0.2195 SP 4)
...
Operation completed successfully in 1.31 seconds.

3- ESEUTIL /r E01
Initiating RECOVERY mode...
    Logfile base name: E01
            Log files: <current directory>
         System files: <current directory>
   Database Directory: N:\Exchsrvr\MDBDATA

Performing soft recovery...

Operation completed successfully in 7.47 seconds.

4- ESEUTIL /g
result...
                     Scanning Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ..
Operation terminated with error -4001 (JET_errFileIOBeyondEOF, a read was issued
 to a location beyond EOF (writes will expand the file)) after 40.265 seconds.

5- ESEUTIL /p
result...
Checking database integrity.
Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API para
meter)

I've researched and followed so many Microsoft's and experts-exchange's ariticles, but seems no luck.
Regards,
Tanin_no
0
tanin_no
Asked:
tanin_no
1 Solution
 
amaheshwariCommented:
Hi,

Did you completetly clear all the transaction logs? simply rename the transaction log folder and create a new one with the same name. ten try eseutil /p priv1.edb. If this does not work, you'll HAVE to restore from the most recent backup.
0
 
tanin_noAuthor Commented:
Hi Amaheshwari,

Thanks for your suggestion. That was one of the way I tried, but didn't work. I also moved the EDB out and ran against it in a newly created folder. Also, I tried to delete worth of huge STM file and used "eseutil /p priv1.edb /createstm", but no luck at all.  I couldn't retrieve backup from a Veritas backup exec since its agent was primary suspect to be the culprit for the OS crash/BOD, Exchange unreliable and serveral dismounted. Besides the useless online backup of data (because it doesn't support redirect restore location), I  almost retreat and went finding alternative recovery tools and ways to alleviate chaos situation by creating new hundreds of mailboxes for use in Monday morning first and then hope that we could find some data recovery for further mitigation. Meanwhile, we desperately spent last hours searching for old copies of trust and stable EDB+STM+Logs from other SAN disks and network computers. Guess what? we found one!

Luckily, it was a two-week old copies in a location no one could recall.  So I managed to get all EDB+STM+Logs back to the problematic server and ran through the procedure above again and yes, it worked out!  There were some other continuous issues on offline restore recovery and when got back into the Exchange IS. There must be defragment by using "eseutil /d" to salvage unused pages and re-indexing, and the magic of a few use of "isinteg -fix -test alltests".  And then, for your information to those in need, you may deal with mounting problem and issues of recovering the old database and so on. Check these KB: 251403, 328674, 896143, 294318, 292509.

I hope this could help others in need as well.  Good luck.
Tanin_no
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now