6. RESULTADOS Y VALORACIÓN GLOBAL
6.3 Intervención docente
The reason you put LCR into operation in the first place is to allow you to very quickly bring online a backup copy of the database. You would only need to do this if the production database has become corrupted. Database corruption is a tough topic to try to address in just a few lines, but we should state clearly here that as long as the production database is on a separate physical disk from the transaction logs, the LCR transaction logs, and the LCR copy of the database, the corruption should not extend to the LCR copy of the database.
How will you know that your production database is corrupted? We can think of a couple of situations:
◆ Normal or full backups of the production database fail. Online backups of the database using Exchange-aware backup software will perform a page-by-page check of the database
as it backs it up. If a page-level error is detected, the backup halts, the error is logged to the backup log, and the error is logged to the Application event log.
◆ If corruption is detected during normal operations (for example, if the database engine reads a page of data that is corrupted), Exchange confirms that the page in the database is bad and logs an event to the Event Viewer.
◆ The database will not mount or reports errors when you try to mount it.
Figure 6.18 Errors found when Exchange Server reads a corrupted page from the database
Monitoring for potential errors in your production databases is something you should do regularly, or you should configure your monitoring system to monitor for specific errors in either the Application event log (such as the one shown in Figure 6.18) or the backup logs such as the one shown here:
Backup started on 12/11/2006 at 8:47 PM.
The ’Microsoft Information Store’ returned ’Error returned from an ESE function call (d).
’ from a call to ’HrESEBackupRead()’ additional data ’-’The ’Microsoft Information Store’ returned ’Error returned from an ESE function call
(d).
’ from a call to ’HrESEBackupRead()’ additional data ’-’ The operation was ended.
Backup completed on 12/11/2006 at 8:47 PM. Directories: 0
Note in the case of the error shown in Figure 6.18 that the database was mounted and func- tioning. The error did not interfere with the normal functioning of the database but was rather a single page in the database that could not be read properly. This error was probably due to the disk subsystem, device driver, or firmware. It is unlikely that the problem would extend to the LCR copy of the database.
If you realize that your production database is corrupted, you can manually switch the LCR database into production. This is done using theRestore-StorageGroupCopycmdlet. Before we do an example, let’s look at the current location of the live database and logs as well as the locations of the LCR files. Here are two quick ways to retrieve this information using the EMS:
[PS] C:\>Get-StorageGroup ”Engineering Mailboxes SG” | FL name,*path* Name : Engineering Mailboxes SG
LogFolderPath : D:\EngineersSG SystemFolderPath : D:\EngineersSG CopyLogFolderPath : D:\EngineersSG-LCR CopySystemFolderPath : D:\EngineersSG-LCR
[PS] C:\>Get-MailboxDatabase ”Engineering Mailboxes” | FL name,*path* Name : Engineering Mailboxes
CopyEdbFilePath : D:\Engineers-Mailboxes-LCR\Engineering Mailboxes.edb EdbFilePath : D:\EngineersSG\Engineering Mailboxes.edb
There are two steps to switching over to using an LCR database instead of the original pro- duction database. The production database must be dismounted and then the LCR database/log locations are swapped out. There are two approaches to ‘‘swapping out’’ the database. The first (and desired) approach is to copy the LCR database to the production database location. Here is an example:
[PS] C:\>Dismount-Database ”engineering mailboxes” -Confirm:$False [PS] C:\>Restore-StorageGroupCopy ”Engineering Mailboxes SG”
Base name: e02
Log file: D:\EngineersSG\E0200000774.log
Csv file: D:\EngineersSG-LCR\IgnoredLogs\q5cfbb2m.koe Base name: e02
Log file: D:\EngineersSG-LCR\E0200000774.log
Csv file: D:\EngineersSG-LCR\IgnoredLogs\5p52d1ni.kxz
Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E0200000775.log Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E0200000776.log
Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E0200000777.log Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E0200000778.log Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E0200000779.log Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E02.log
WARNING: Restore-StorageGroupCopy on Engineering Mailboxes SG was successful. All logs were successfully copied.
Once this is executed, you must manually copy it into the production location. You can do this by just copying the files, or if the paths are the same but the drive letters are unique, you could sim- ply reassign the drive letters. For example, if the production database is on
D:\EngineeringMailboxesand the LCR database is onE:\EngineeringMailboxes, you could simply tell the server that the D: drive is now the E: drive. The advantage to this approach is that the documented locations of all of the database and storage group files remains the same. The downside to this is that the only Exchange data that could be on the D: and E: drives in this example would be that one database that is being swapped out.
The other way to swap out the database files is simply to swap out the locations; this is done with theRestore-StorageGroupCopycmdlet and the-ReplaceLocationsoption. Here is an example:
[PS] C:\>Restore-StorageGroupCopy ”Engineering Mailboxes SG” -ReplaceLocations Base name: e02
Log file: D:\EngineersSG\E020000001F.log
Csv file: D:\EngineersSG-LCR\IgnoredLogs\raobyk4o.lqt Base name: e02
Log file: D:\EngineersSG-LCR\E020000001F.log
Csv file: D:\EngineersSG-LCR\IgnoredLogs\hosrmoec.5v1
Integrity check passed for log file: D:\EngineersSG-LCR\inspector\E02.log WARNING: The Restore-StorageGroupCopy operation for storage group copy Engineering Mailboxes SG was successful, and production paths
were updated. All logs were successfully copied.
The database can now be remounted, but it is now in use in a different location. We can confirm this with theGet-StorageGroupand theGet-MailboxDatabasecmdlets. Notice also that LCR has been disabled for this storage group after theRestore-StorageGroupCopycmdlet was run:
[PS] C:\>Get-StorageGroup ”Engineering Mailboxes SG” | FL Name,*path*,HasLocalCopy Name : Engineering Mailboxes SG
LogFolderPath : D:\EngineersSG-LCR SystemFolderPath : D:\EngineersSG-LCR CopyLogFolderPath :
CopySystemFolderPath : HasLocalCopy : False
Name : Engineering Mailboxes HasLocalCopy : False
CopyEdbFilePath :
EdbFilePath : D:\Engineers-Mailboxes-LCR\Engineering Mailboxes.edb The Microsoft online documentation makes a very good point that if you use the — ReplaceLocationsparameter, you should make an effort to update your documentation to reflect the new database location or move the database back to the original location. Otherwise, your documentation will now be out-of-date and other administrators may be confused as to why the production databases are in folders that have LCR in their name.
Summary
Scaling upward and outward is a necessary evil for organizations with more than a few hundred users. While a single machine can easily support all the necessary server roles for a few hundred mailboxes, if it is not properly configured, it may experience performance problems. Recognizing potential performance bottleneck points and how to correct them is an essential skill for Exchange administrators.
As more mailboxes are supported on a single Exchange Mailbox server, scaling the server upward to support more storage is also an important configuration item. Creating more storage groups and mailbox databases will help you to support larger mailboxes and more data while preventing any single database from growing too large.
Local continuous replication is a new feature of Exchange 2007 that also allows you to grow and scale your organization. This feature allows you to support larger mailboxes but still have low recoverability times for mailbox databases. By allowing important mailbox databases (or all mailbox databases) to be configured to use LCR, you can have a nearly perfectly synchronized copy of the production database that can be swapped in to production in a moment’s notice.