Section 20.2. Storage Groups


20.2. Storage Groups

Storage groups are used to house one or more groups of stores. Exchange Server 2000 and 2003 can have up to four separate storage groups, and each can contain up to five stores. Storage groups are used to reduce the management of the number of logfiles and thereby also the amount of transactions on those files that would be necessary if each store had individual logfiles. Additionally, by grouping stores together, they not only share the same set of logfiles but they can be managed in the same way. This includes sharing backup settings or backup schedules. Storage groups consist of many elements, including transaction logfiles, checkpoint files, reserve logfiles, and temporary files.

20.2.1. Transaction Logfiles

The transaction logfile maintains a history of every operation occurring in a specific storage group. Transactions are stored sequentially in the logfiles and concurrently in memory. Transactions are simply appended to the log for simplicity and speed, and then replayed into the database at a later time. This has the added benefit of not only being fast, but providing a recovery mechanism if the server should fail. If you lose the transaction in memory, you have a record stored in the logfile.

Exchange transaction logfiles are always 5 MB. Having fixed-sized logfiles offers a performance benefit over growing logfiles because the overhead associated with having to grow or shrink a file is eliminated.

When Exchange starts, it creates one 5 MB transaction logfile named E<xx>.log where <xx> is a sequential number starting at 00 referred to as the base name or log prefix. For instance, the default storage group that is created with every Exchange Server installation is called, cleverly, First Storage Group and its logfile is named E00. log. If you were to create a second storage group, its logfile would be named E01.log, and so on. Figure 20-4 shows the default storage location and log prefix in Exchange Server 2000 and 2003.

Figure 20-4. Default storage location and log prefix


Eventually, this file fills and ESE renames it to E<xxyyyyy>.log and creates a new file with the same name as the original E<xx>.log. Logfile numbering is hexadecimal starting at 00001, so in staying with the naming used in previous examples, the first logfile created would be E0000001.log. This process is repeated each time a logfile fills up until one of two events occur: either you reach the maximum number of logfiles allowed, the server logs an error in the event log, and the store is gracefully dismounted; or you make a backup using one of the backup methods that purge unnecessary transaction logfiles.

20.2.2. Checkpoint Files

Checkpoint files are important because they keep track of how far Exchange has progressed through the process of writing the transaction logfiles to the database. Without this record, there would be no way to know where to start replaying transactions during a restore or recovery. This would mean having to replay every single transaction since your last backup.

Checkpoint files are named in a similar manner to the primary transaction logfile; they inherit the base name/log prefix and are named E<xx>.chk. The name of the checkpoint file for the First Storage Group would be E00.chk. There is never more than one checkpoint file per storage group, and it is always 8 K.

The checkpoint file maintains a pointer to the oldest logfile in the storage group that has all transactions successfully committed to the database. When all transactions in a logfile are written successfully to the database, the checkpoint advances to the next logfile in the series that contains the next unwritten entry.

If there is a server or database failure, ESE reads the checkpoint file on startup to find the correct transaction logfile to recover any lost transactions. ESE recovers the lost transactions by writing to the database all transactions that are newer than the checkpoint file. Any uncommitted transactions are discarded.

As mentioned previously, the E<xx>.log file is not required to replay transactions. ESE can determine which transactions are already written by examining the transaction logfiles, in sequence, one at a time. Using the checkpoint saves ESE from starting at the first logfile and possibly having to progress through hundreds or thousands of files to find the proper point at which to start replaying transactions.

20.2.3. Reserve Logfiles

For each storage group, ESE reserves two logfiles named res1.log and res2.log. These files are used as placeholders in the event that the server runs out of disk space and can't create any more transaction logfiles. These logfiles have the same size and function as normal logfiles; they are simply held in reserve. They are called into use only if the Exchange Server has less than 5 MB of disk space available and can't create a new logfile. At this point, ESE would then use one of these reserved logfiles instead of creating a new logfile. Operations currently in memory are recorded to the reserved logfile starting with res2.log, and then the databases in the storage group are dismounted. Of course at this point, there is no access for users, and you'll be able to track the problem from the errors in the Event Log.

20.2.4. General Logfile Info

Logfiles can have the same name in different storage groups. To track which storage group each logfile belongs to, ESE adds a header to each file series with a unique signature to differentiate between different series. These signatures do not change after the E<xx>000001.log file is created, to maintain consistency. In general, the rotation of logfiles works like this: the current E<xx>.log reaches capacity; at this point, the E<xx>temp.log file is started. The original logfile is renamed to its hexadecimal number and then finally the E<xx>temp.log file becomes E<xx>.log. This process is repeated on an as-needed basis.

20.2.5. Circular Logging

Circular logging allows transaction logfiles to be overwritten by new logfiles after the transactions contained within are committed to the database. This is a great feature for frontend-pass through type servers, where no information is actually stored, because it maximizes disk space usage. The main disadvantage to using circular logging is that if the database fails, recovery can't replay transaction logs, so your restore is limited to only the information contained in the most recent full backup. Also, with this type of logging, you are limited to full backups; differential or incremental aren't supported.

Circular logging works by not maintaining previous transaction logs for a long period of time. In contrast to noncircular logging in which transaction logs continue to accumulate until a full backup (or the maximum number of files permitted is hit), only a few transaction logs are maintained at any one timeusually four. Circular logging continually overwrites the oldest logfile when a new transaction logfile is needed, unless the size of the transactions in the logfile exceed 5 MB. If that happens, a new file is created until the checkpoint can be advanced. After the checkpoint has been advanced, these extra logfiles are generally not used and are deleted during the next backup.

It should be reiterated that this type of configuration should not be used for any Exchange Server in which you are storing user data. This type of arrangement works best for frontend-pass through type servers where no mailbox or public folders reside or for NNTP servers where it is expected that the data is short-lived. Basically, use this configuration only in places where recovery isn't important to you.


20.2.6. Other Files

In the interest of completeness, you may see some other files in your Exchange directory from time to time. These are temporary files and are a normal function of the Exchange Server.


E00tmp.log

This file is created by ESE for temporary storage as the transaction logfile is being renamed and a new transaction logfile is generated.


tmp.edb

This file is created when the Exchange Server needs temporary storage during maintenance times, for temporary tables, sorting, or index creating.


stf files

These temporary files are created by the IMAIL process during content conversion.


IFS files

These temporary files are created by ExIFS and contain cached directory lists of the ExIFS.

Figure 20-5 is an excellent representation of file sizes for a low-volume Exchange Server. Here we have a sampling of almost everything covered. Notice that the transaction logfiles have incremented since the last full backup (E0000335.log and E0000336.log) and that the file sizes are consistent with what was discussed. The checkpoint file is 8 K, and the transaction and reserve logfiles are all 5 MB.

Figure 20-5. Transaction logs in Exchange Server


20.2.7. Single Instance Storage

Exchange employs a great storage savings feature called single instance storage. When a message is sent to multiple mailboxes that reside in the same store, only one instance of the message is stored in one mailbox; other mailboxes will contain a pointer to the stored message. This feature is maintained on a per-store basis. It is important to remember that if the message is sent to mailboxes that are in different stores, storage groups, or servers, it is stored once per store, storage group, and server. For example, if a message is sent to two mailboxes on two servers, it is stored twice. If it is sent to two mailboxes that are in different stores or storage groups on the same server, it is stored twice. But if it is sent to two mailboxes that are part of the same store, it is stored only once.

20.2.8. Automatic Database Maintenance

Automatic database maintenance occurs every night at intervals designated in the Database tab. While a great deal of maintenance can go on during this time, we do not cover it in detail since we are only interested in how it applies to, or interacts with, backups. The important thing to note about automatic database maintenance is its scheduling. Automatic maintenance can be CPU-intensive and therefore should be scheduled at a time when backups aren't running. Additionally, this maintenance window should occur when the fewest users are online. Finally, if there are multiple storage groups on the same server, stagger the time in which each runs so as to avoid overlap.

20.2.9. Storage Limits

Exchange 2003 Standard Edition can have one storage group that contains one mailbox store and one public folder store. The maximum size of a store prior to Exchange 2000 and 2003 Service Pack 2 is 16 GB. In Service Pack 2, this limit is 75 GB.

With Exchange Server 2003 Enterprise Edition, you can have up to four storage groups, each of which can contain up to five databases, either mailbox stores or public folder stores. The maximum size of each store is 16 TB.




Backup & Recovery
Backup & Recovery: Inexpensive Backup Solutions for Open Systems
ISBN: 0596102461
EAN: 2147483647
Year: 2006
Pages: 237

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net