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

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.