2. Manage the Transaction Log Files
All
data that is written to a database is first recorded in transaction log
files. Each set of logs files is unique to a database. On disk,
transaction log files are 1 MB files that are stored in the same
location. Figure 6 shows a typical folder containing transaction logs.
In addition to log
files, the database uses a checkpoint file, which records the last
transaction that was successfully written to the database. The
checkpoint file ends in the .CHK extension and is stored with the log files.
The log files are kept on disk
until a backup is completed. After the logs are successfully backed up,
they can be safely deleted from the server. If a database needs to be
restored, the last full backup of the database and any log files that
were created since the full backup are restored. When the database
starts, the transactions inside the logs will be applied to the
database.
2.1. Move the Transaction Logs to a Different Location
In previous versions of
Exchange, it was always a good idea to separate transaction logs and the
database onto different hard disks. There were two primary reasons for
this. First, the input/output (I/O) patterns are different for
transaction log data than for database data. When transaction logs are
written to the disk, the data is written sequentially because the data
is written in contiguous blocks as it is streamed in from memory. This
means that the disk head on the drive moves very little. On the other
hand, when database data is written, the I/O is random and the disk head
moves frequently across the disk because it is writing data in
different places. Therefore, putting transaction logs on the same disks
as the database means that you will lose some disk performance as that
disk head moves back and forth.
The second reason for
separating transaction logs involves recovery. If you lose the disks
that the database is on, the transaction logs are still intact if they
are on different disks. You can restore the last full backup and any
transaction logs with it. Along with the transaction logs that are
already on the server, you have a full set of data that you can restore.
|
In most cases, the
database performance enhancements in Exchange 2010 obviate the need to
separate logs from the database for performance reasons. If you have
multiple copies of the database on different servers, you may not be
concerned about losing the disks with the transaction logs. Therefore,
in many scenarios it will be better to keep the database and log files
on the same set of hard disks in Exchange 2010.
|
|
If you didn't move the
transaction logs when you created the database, you can still do it
afterward. To move the transaction logs using the EMC. When you are prompted for the new location of
the files, only change the location of the log folder. This will move
only the transaction logs.
You can also move the logs with the EMS using the Move-DatabasePath cmdlet. You can specify that you want to move the transaction logs by including the LogFolderPath parameter, as in this example:
Move-DatabasePath -Identity DB01 -LogFolderPath T:\Logs
2.2. Reuse Transaction Logs
Exchange gives you the option of reusing transaction logs that have already been committed to the database. This is called circular logging.
In previous versions of Exchange, it was a best practice to minimize
the use of circular logging in production environments. You usually
wanted to keep transaction logs until the database or the logs had been
backed up so that the data could be recovered. If you lost a database
and didn't have the logs, all the data since the last backup was gone.
In Exchange Server 2010,
circular logging plays a more integral role. If you decide to use a
backup-less configuration, then you must use circular
logging to ensure that transaction logs are regularly truncated.
However, there may be other
circumstances where you might want to use circular logging. If your
transaction log drive is filling up quickly and you can't provision
additional space, circular logging is a possible solution to ensure that
the drive doesn't fill up, which would cause the database to shut down.
Some organizations will enable circular logging for periods of time,
such as during a large mailbox migration. Of course, there is a period
of risk during the time that circular logging is enabled. But if you
make a full backup after you turn circular logging off, the risk is
minimized.
2.2.1. Set Up Circular Logging Using the Exchange Management Console
You can enable or disable circular logging through the EMC:
Open the EMC and browse to the Organization Configuration => Mailbox node in the Console tree.
Click the Database Management tab to bring up a list of databases.
Select
the database that you want to enable circular logging on and choose
Properties from the database's Action menu in the Actions pane.
In the properties dialog box for the database, click the Maintenance tab.
Select the Enable Circular Logging check box, as shown in Figure 7.
If
the database is mounted, you will receive a warning informing you that
the database must be remounted before the circular logging setting will
take effect. Click OK at this warning window.
When back in the properties dialog box, click OK to save the changes and close the dialog box.
You
will need to dismount and remount the database in order for circular
logging to take effect. When back in the EMC, make sure that you have
the database selected and click the Dismount Database option in the
database's Action menu in the Actions pane.
When you are prompted to continue, click Yes.
After the database is dismounted, click the Mount Database option in the database's Action menu. This will remount the database.
2.2.2. Set Up Circular Logging Using the Exchange Management Shell
To configure circular logging through the EMS, use the Set-MailboxDatabase cmdlet with the CircularLoggingEnabled parameter, as shown in the following example. Set the parameter to $True to enable circular logging or $False to disable it:
Set-MailboxDatabase DB01 -CircularLoggingEnabled $True
