Exchange Server Forums

SCR database is still dirty after eseutil /r

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [Microsoft Exchange 2007] >> High Availability >> SCR database is still dirty after eseutil /r

Page: [1]

Message

<< Older Topic Newer Topic >>

SCR database is still dirty after eseutil /r - 12.Jun.2008 12:22:36 PM

pri3257

Posts: 3
Joined: 12.Jun.2008
Status: offline

I am trying to finish testing and documenting recovery using SCR. After failing the live database I restore the scr copy database and run eseutil /mh to check the status. It is in dirty shutdown as expected. After running eseutil /r most of the time it remains in dirty shutdown. Here is the output of /mh.

Initiating FILE DUMP mode...
Database: c:\usersabc\usersabc.edb

        File Type: Database
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,12
Engine ulVersion: 0x620,12
Created ulVersion: 0x620,12
    DB Signature: Create time:06/12/2008 10:37:10
        cbDbPage: 8192
          dbtime: 186 (0xba)
           State: Dirty Shutdown
    Log Required: 26-28 (0x1a-0x1c)
   Log Committed: 0-28 (0x0-0x1c)
Streaming File: No
        Shadowed: Yes
      Last Objid: 5
    Scrub Dbtime: 0 (0x0)
      Scrub Date: 00/00/1900 00:00:00
    Repair Count: 0
     Repair Date: 00/00/1900 00:00:00
Old Repair Count: 0
Last Consistent: (0x0,0,0) 00/00/1900 00:00:00
     Last Attach: (0x1,9,6C) 06/12/2008 11:15:36
     Last Detach: (0x0,0,0) 00/00/1900 00:00:00
            Dbid: 1
   Log Signature: Create time:06/12/2008 10:37:10
      OS Version: (0.0.0 SP 0)

Previous Full Backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

Previous Incremental Backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

Previous Copy Backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

Previous Differential Backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

Current Full Backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

Current Shadow copy backup:
       Log Gen: 0-0 (0x0-0x0)
          Mark: (0x0,0,0)
          Mark: 00/00/1900 00:00:00

cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0

       ECC Fix Success Count: none
Old ECC Fix Success Count: none
        ECC Fix Error Count: none
    Old ECC Fix Error Count: none
   Bad Checksum Error Count: none
Old bad Checksum Error Count: none

Operation completed successfully in 0.63 seconds.

I can get it mountable using eseutil /p but I am trying to figure out what is going wrong so the /p is not necessary.

If I check the directory on the scr server the log files are all there, from e00 to e0049

I am posting my documentation here, possibly someone could look at it and see a step I am missing.

The part I am having problems with is under disaster recovery step 3

Post #: 1

Featured Links*

RE: SCR database is still dirty after eseutil /r - 12.Jun.2008 12:23:27 PM

pri3257

Posts: 3
Joined: 12.Jun.2008
Status: offline

Using this documentation

Disaster Recovery

If production database fails the SCR target must be made mountable

1.    Restore-storagegroupcopy Exchange\storagegroup �standbymachine SCR

This command will report the status of the log replication
Must use �force command if the server was not able to copy the last log from the source server.

Recovery databases in E:\recoverytempdb directory should be in a dirty shutdown state

2.    Use eseutil to check the state of the database

Eseutil /mh E:\recoverytempdb\%database.edb% | findstr state

To get the database to a clean shutdown state, run the following:
Note* E01 refers to the log file prefix, they may be E01, E02, etc�
You can find the log file prefix by looking at the logs or by looking at the database properties in exchange management console

Note** /mh parameter shows header information. You can use this output to show the log required if the database is in a dirty shutdown state.
http://exchangeis.com/blogs/exchangeis/archive/2007/05/28/using-eseutil-how-to-check-which-transaction-log-files-are-not-committed.aspx

3.    Use ESEutil to put database in clean state

Eseutil /r E00 /L %logpath% /d   %database% /s   %systemfilepath%

If there is data loss you may be required to use the /a switch
Eseutil /r /a E01 /L E:\recoverytempdb\%databasepath% /d   E:\recoverytempdb\%databasepath% /s   E:\recoverytempdb\%databasepath%

Check database again to verify clean shutdown state
Eseutil /mh %database.edb% | findstr state

4.    Move the paths of the recovery storage groups to the location of the SCR replicated data- Uses the configurationonly parameter to only update AD information.

Move-StorageGroupPath %scr server%\%storagegroup% -SystemFolderPath %storagegrouppath% -LogFolderPath %storagegrouppath% -ConfigurationOnly

5.    Move the paths of the recovery storage group database to the location of the SCR replicated data- Uses the configurationonly parameter to only update AD information.

Move-DatabasePath %scr server%\%storagegroup%\%database% -EdbFilePath %database%.EDB -ConfigurationOnly

**Note the edb file is the name of the replicated edb file**

6.    Set the DB to be overwritten this can be done in the gui or from EMS
Set-mailboxdatabase %scrserver\%storagegroup%\%database% -allowfilerestore:$true

7.    Mount recovery database
Mount-database ctc-scr\%recoverystoragegroup%\%database%

8.    Rehome User mailboxes to SCR server in AD

Get-Mailbox -Database ctc-scr\%recoverystoragegroup%\%database% � where {$_.ObjectClass -NotMatch '(SystemAttendantMailboxExOleDbSystemMailbox)'} � Move-Mailbox -ConfigurationOnly -TargetDatabase ctc-scr\%recoverystoragegroup%\%database%

Verify server properties for user mailboxes in the exchange console to make sure they were re-homed.

Depending on the following factors client should now be able to access mailboxes:

Active Directory replication latency
CAS server has been updated with the correct information
OL 2007 will use autodiscover to find the mbx
However OL 2003 will not automatically configure the client unless the old server is still online and can be contacted.

(in reply to pri3257)

Post #: 2

RE: SCR database is still dirty after eseutil /r - 12.Jun.2008 12:31:29 PM

ismail.mohammed

Posts: 2286
Joined: 9.May2007
From: India
Status: offline

hi mate,

I don't know what is the exact step you have followed but you can refer this below link to confirm the steps you have taken. so far....
http://exchangeserverinfo.com/2008/02/21/exchange-2007--high-availability-solution--standby-continuous-replication.aspx

(in reply to pri3257)

Post #: 3