Dela via

How to Activate the Passive Copy of a Database

  • Artikel

Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

 

Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3

This topic explains how to recover data when an active database and its log files that are enabled for local continuous replication (LCR) become corrupt.

Before You Begin

To perform this procedure, the account you use must be delegated the following:

  • Exchange Server Administrator role and local Administrators group for the target server

For more information about permissions, delegating roles, and the rights that are required to administer Microsoft Exchange Server 2007, see Permission Considerations.

Although the following procedure uses the ReplaceLocations parameter of the Restore-StorageGroupCopy cmdlet, we recommend that you instead change drive assignments or perform some other lower-level operation. Drive assignments can be changed with the Disk Management Microsoft Management Console (MMC) snap-in or the Diskpart tool that is included with Microsoft Windows Server 2003. The reason for this recommendation is to guarantee that active storage group and database files continue to have meaningful file names that represent that they are active production copies. The ReplaceLocations parameter guarantees that the active copies of the database and logs are contained in the directories normally reserved for the passive copies of these files. Operating in this configuration might lead to future confusion in distinguishing the active copy of the data from the passive copy of the data.

Procedure

To recover from corruption of the active copy of a database that is enabled for LCR

  1. Verify that the corruption is not the result of an offline log drive, offline database drive, or a disk volume configuration error. If the log volume of the production storage group is not available (and could be available) at the time of the failover, more data may be lost than necessary.

  2. Assess if the data in the passive copy of the database is acceptable. For guidance about how to make this determination, see How to View the Status of a Local Continuous Replication Copy. Typically, the system should be able to recover with all data from the active copy of the database. Thus, the assessment should show that all necessary log files are available. If this is not the case, you should investigate why some or all log files are unavailable.

  3. Dismount the corrupt database. You can use the Dismount-Database cmdlet in the Exchange Management Shell or the Dismount shortcut menu option for the database in the Exchange Management Console.

  4. Use the Restore-StorageGroupCopy cmdlet as follows to activate the copy of the database. This can be done in one of two ways:

    Note

    The LCR copy is automatically disabled as part of running the Restore-StorageGroupCopy cmdlet.

    1. To activate the copy and leave the production storage group and database paths unchanged, run the following cmdlet:

      Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

      Note

      The preferred way is to activate the copy in its current location, move the files, change drive letters, or mount point assignments to get the copy files positioned under the production paths. Through this strategy, the production database is maintained in its expected location.

    2. To activate the copy and update the production storage group and database paths with those of the LCR copy, run the Restore-StorageGroupCopy cmdlet with the -ReplaceLocations option as follows:

      Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -ReplaceLocations:$true

      Note

      An administrator could be subsequently surprised by this if left in place for an extended period. The deciding factor should be whether the copy's files can be relocated in minutes, and thus permitting the desired rapid recovery.

  5. At the confirmation prompt, type Y and then press ENTER.

  6. Perform this step if you performed Step 4a where the production paths were unchanged (-ReplaceLocations was not specified in the Restore-StorageGroupCopy cmdlet). The passive copy's files must be relocated into the production storage group and database paths. Use the appropriate file system or volume management tool to move the logs, system files, and database of the LCR copy to these locations.

  7. The database can now be mounted.

  8. The Restore-StorageGroupCopy cmdlet automatically disables LCR for the storage group. LCR must be enabled after the recovery is complete. For detailed steps about how to enable LCR for the storage group, see How to Enable Local Continuous Replication for an Existing Storage Group.

For More Information

For detailed syntax and parameter information, see Restore-StorageGroupCopy.

For more information about managing your LCR environment, see Managing Local Continuous Replication.