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

Exchange 2007 Log replay problems

Hi,

We are having an issue while trying to replay log files into a restored database file. I have restored a database and associated log files from backup (using ARCserve r12 exchange agent) into a recovery storage group. I run an eseutil /mh on the database file and it shows as dirty shutdown and required log file of 0x685a-0x686c. These log files are present in a separate folder called _restoredLogs. I run the following command from the _restoredLogs directory eseutil /r E00 /i /d "d:\...\mailbox database.edb". This command completes successfully however when I query the database file again with an eseutil /mh it is still showing as dirty shutdown. I have managed to get another copy of the database running by using the /p option however have lost some data (as was expected). Does anyone know of a way to get the /r option to replay the logs properly?
0
PulseAdmin
Asked:
PulseAdmin
  • 3
  • 2
1 Solution
 
consultkhanCommented:
you should typically run esuutil /r without specifying E00 or any other switches.This should be run from the directory where log files are copied by the backup programme.The system will automatically play those log files which are ok.

You could also check if there is any log file corruption by running eseutil /ml against the log files,and remove any found corrupt.If you do remove any log files,rename the last log file to E00.

thanks,
consultkhan
0
 
PulseAdminAuthor Commented:
Hi Consultkhan,

I tried running the eseutil /r command however this didn't work. Result as follows:

E:\Microsoft Exchange Server\Testing Storage Group\Logging\_restoredLogs>eseutil /r

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Usage Error: Missing logfile base name specification.

Operation terminated with error -1003 (JET_errInvalidParameter, Invalid API parameter) after 0.47 seconds.

I have also run the eseutil /ml on all of the required log files. The test completed successfully on all of the log files. One thing I did notice though is that the database field in the log files is pointing to the original database location not the restored database location. Is this a problem?

Below is the output from the eseutil /r command when I run with the E00 and /d switches:

E:\Microsoft Exchange Server\Testing Storage Group\Logging\_restoredLogs>eseutil
 /r E00 /d "d:\Program Files\Microsoft\Exchange Server\Mailbox\Testing Storage G
roup\Mailbox Database.edb"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: E00
            Log files: <current directory>
         System files: <current directory>
   Database Directory: d:\Program Files\Microsoft\Exchange Server\Mailbox\Testin
g Storage Group\Mailbox Database.edb

Performing soft recovery...
                      Restore Status (% complete)

          0    10   20   30   40   50   60   70   80   90  100
          |-----|-----|-----|-----|-----|-----|-----|-----|----|-----|
          .........................................................................



Operation completed successfully in 35.907 seconds.

Any ideas?
0
 
consultkhanCommented:
log files is pointing to the original database location not the restored database location. Is this a problem?
NO.Its not a problem.
pls also run isinteg with fixall opiton.

thanks,
consultkhan
0
 
PulseAdminAuthor Commented:
Hi Consultkhan,

Unfortunately you can't run isinteg on a dirty shutdown database.
0
 
PulseAdminAuthor Commented:
I have managed to get the log files to replay into the database. I had to do the following to get it to work.

1. I created a clone of the Exchange Server and Domain Controller on a separate Network
2. Restored the database and Log files to the original location on the cloned Exchange Server.
3. Ran eseutil /r E00 from the log file directory.

After this the database was clean shutdown. Not sure why the files had to be in the exact location that they were backed up from for the repair to work??
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

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