Tim McMichael

Navigating the world of high availability...and occasionally sticking my head in the cloud...

My LCR / CCR / SCR / DAG database copy is in dirty shutdown state…

My LCR / CCR / SCR / DAG database copy is in dirty shutdown state…

  • Comments 4
  • Likes

In recent weeks I’ve had several peers and customers present with concerns that when using Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), Standby Continuous Replication (SCR), of the Database Availability Group (DAG)  passive database copies appear in a dirty shutdown state.

 

In general a database has two states – Clean Shutdown and Dirty Shutdown.  A clean shutdown state indicates that the database has had all outstanding transaction logs committed to it and the database can now stand on its own.  A dirty shutdown database indicates that the database requires additional transaction logs to be committed in order for the database to stand on its own.

 

Here is a eseutil /mh dump of a database that has been dismounted and therefore should be in a clean shutdown state.

 


Extensible Storage Engine Utilities for Microsoft(R) Exchange Server

Version 08.03

Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: MBX-1-SG1-DB1.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/30/2010 09:18:04 Rand:205158 Computer:
         cbDbPage: 8192
           dbtime: 49856 (0xc2c0)
            State: Clean Shutdown
     Log Required: 0-0 (0x0-0x0)
    Log Committed: 0-0 (0x0-0x0)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 135
     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: (0x30,102,19E)  12/05/2010 11:33:55
      Last Attach: (0x2F,9,86)  12/05/2010 09:23:20
      Last Detach: (0x30,102,19E)  12/05/2010 11:33:55
             Dbid: 1
    Log Signature: Create time:06/30/2010 09:18:03 Rand:202227 Computer:
       OS Version: (6.0.6002 SP 2 NLS 500100.50100)

Previous Full Backup:
        Log Gen: 15-32 (0xf-0x20) - OSSnapshot
           Mark: (0x21,8,16)
           Mark: 07/06/2010 21:08:21

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.15 seconds.

This particular database is enabled for LCR.  With the source database mounted and with storage group copy suspended, here is an eseutil /mh dump of the database.  (We should expect the same for a CCR passive, SCR passive, or DAG passive database)

 


Extensible Storage Engine Utilities for Microsoft(R) Exchange Server

Version 08.03

Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: MBX-1-SG1-DB1.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/30/2010 09:18:04 Rand:205158 Computer:
         cbDbPage: 8192
           dbtime: 49856 (0xc2c0)
            State: Dirty Shutdown
     Log Required: 50-50 (0x32-0x32)
    Log Committed: 0-50 (0x0-0x32)
   Streaming File: No
         Shadowed: Yes
       Last Objid: 135
     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: (0x30,102,19E)  12/05/2010 11:33:56
      Last Attach: (0x32,9,86)  12/05/2010 11:38:05
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:06/30/2010 09:18:03 Rand:202227 Computer:
       OS Version: (6.0.6002 SP 2 NLS 500100.50100)

Previous Full Backup:
        Log Gen: 15-32 (0xf-0x20) - OSSnapshot
           Mark: (0x21,8,16)
           Mark: 07/06/2010 21:08:21

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.

In this case a state of dirty shutdown is expected.  When a database is enabled for replication we utilize a special replay process called Replay Without Undo.  Essentially we know that if the source database is mounted, and that there is a copy, we will encounter incomplete transactions in a log stream that will eventually be completed in logs that are either being generated or in the process of copying to the target.  With this in mind we do not want to undo these logical transactions, but rather hold them open and wait for subsequent logs that will complete them.

 

With this in mind administrators should not be immediately concerned that their passive database copies show a state of dirty shutdown.

Comments
  • Hi ,

    Its a very nice article. Thank you for sharing your knowledge.I have a couple of queries related to backup.

    If I backup passive node database that is part of DAG when the copy status SUSPENDED, will backup succeed?

    If it succeeds, will the logs get purged on active or passive node?

    When the copy status is SUSPENDED, if i backup from Active node, will it succeed and logs on active node  will get purged?

    Thank you once again.

  • @Sukum:

    You should not be able to backup a passive database copy that is suspended.  Only copies with a status of healthy should be eligable for backup.

    If any copy of a database does not have a healthy status, and a backup of another copy or the active is successful, log files will not purge.

    TIMMCMIC

  • It was quick.Appreciate your help.Thank you.

  • In our testing in Windows 2008/Exchange 2007 CCR, it is found like diagnostics logging enabled on the active node does not remain as we failover CMS to other node ? Is it by design ? Is it because of Windows 2008 Cluster ? Is it the same behaviour in Windows 2003 Cluster ? What is the technical reason behind this behaviour? Thanks

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment