Exchange Server Operations Management 02: How the mailbox database is stored

Again, the purpose of this series of articles is to strengthen operational management capabilities, i.e. not deployment or general configuration, which requires some basic theoretical knowledge. If you have friends who need to understand the deployment of exchange or basic operations, you can refer to other resources, or see my previous Exchange series articles.

This article will learn about the storage principle of Exchage 2010 database files, possibly after the Exchange deployment configuration is complete, the customer seldom cares about the storage format of the underlying database files, as long as the DAG copy can be replicated normally, the user mailbox is normal to use, of course, this is the ideal state, However, in the event of a database failure requiring a database repair or restoration, knowledge of database storage is required.

First, Exchange version supports up to five databases. Exchange Enterprise Edition supports up to 100 databases. However, it is important to note that this refers to the maximum number of databases supported on a single server, including the active database and the passive database.

Storage content:

The contents of the mailbox database and the shared folder are primarily stored in Exchange Server 2010, and the mailbox database is the most accessible, and as for public folders, it's easy to understand that in versions prior to Outlook 2007, for things like free/busy information and offline Address Book (OAB) Download and other functions, you need to use the public folder. This means that if the enterprise is using the Outlook2007 version, you can say goodbye to the public folder. Therefore, our focus today is to introduce the contents of the mailbox database.

Mailbox database:

If you've ever learned any database system, it's as simple as learning an Exchange mailbox database. The Exchange mailbox database is divided into database files and transaction log files, of course, in addition to the checkpoint file, we will describe below:

650) this.width=650; "Width=" 719 "height=" 553 "title=" image "style=" Padding-top:0px;padding-right:0px;padding-left : 0px;border-top-width:0px;border-right-width:0px;border-bottom-width:0px;background-image:none; "alt=" image "src = "Http://s3.51cto.com/wyfs02/M02/6E/4A/wKioL1V4V1zDspZHAAL6lBdFNF0347.jpg" border= "0"/>

Database file: (. edb) This file is the most heavy-weight, used to store real data, as long as this file is in, there is no big deal. Exchange versions Each upgrade claims that the IO requirements for storage are getting lower and the need for professional storage support is no longer required, which is very much related to the design of this file structure. With its exchange 2010来, the B-tree structure allows users to access arbitrary data pages within an I/O loop, up to four times times faster than earlier 2007.

The transaction log file (. log) log file does not store real data, but acts on the database, such as creating, deleting, modifying, and so on. Its main purpose is to ensure the integrity and the nature of the data, for the committed operations, will be written to the database file. The current use is the E04.log file, which is used to hold the most recent message change information, after reaching the log file target size, will be renamed to the next log file with a lgeneration sequence of numbers, such as from E0000000001.log to E000000000E.log, the number here is 16 binary. After the renaming is complete, a new E0x.log file is created.

There is also a e04tmp.log file that, whenever the E0x.log file is filled, the temporary E0xtmp.log file will be used to receive new content and will eventually be renamed to the new E0x.log.

What are some of the Jrs files in this? the. jrs file is called a reserved log file that can be used to reserve extra log file space if the current log file is full. When the disk is about to be full, the data that has been written to the log can not be submitted to the EDB database, which may result in the loss of files, with the reserved files, when the disk is about to be full, the system will automatically use the. Jrs as the next new log file, to ensure that the previous transaction data can be written correctly. The database is then automatically unloaded to ensure data consistency. That is, when the database is mounted, the system has set aside 10MB of space to prevent data loss.

Always come to say a database, up to 100 million log files can be reached.

Checkpoint file: the (. chk) chk file is known as a checkpoint file, and the importance of this file is that Exchange will mark through the checkpoint file which logs have been written to the database file and which have not yet been written. If, at some point, the system fails and exchange resumes normally, the extended storage engine (ESE) instance will open the last unread data to mom and automatically replay the log files into the inconsistent database, guaranteeing the consistency and integrity of the data. It is actually used to check which logs write the data file and which are not written. Exchange updates the checkpoint file every 30 seconds. The. chk file is placed in the same log location as the. log file.

In theory, creating a mailbox database requires at least 50MB of disk space, and the files used by the database occupy at least 23MB, but in the process of creation, additional space is required to complete the read and write operations of the data. In addition, in subfolders, there are also. ci. wid. Dir. 000 index files.

Transaction log records:

Instead of writing all the log information to a single large file, Exchange uses a series of log files, each of which is exactly 1 MB (or 1,024 KB) in size. If the log file is full, Exchange closes the file and uses an ordinal to rename the file. The first full log ends with the name Enn00000001.log. The nn represents a two-digit number, called the base name or log prefix. Log files for each database are prefixed with a number (for example, E00, E01, E02, E03 、...... E09, e0a) are distinguished by their filenames. The log file that is currently open to the database is named Enn. log. The file will not have an ordinal number until it is populated and closed.

The checkpoint file (Enn. chk) tracks the progress that Exchange writes logged information to the database file. Each database has its own log stream, and each log stream has a checkpoint file.

Next, let's look at the log file header, the first 4KB page of each log file contains header information that describes and identifies the log file and the database to which it belongs. You can use the command:eseutil/ml [log file name] to view the file header information, but note that if it is Exchange SP1 you may see the hint shown:

650) this.width=650; "height=" 258 "title=" image "style=" Border:0px;padding-top:0px;padding-right:0px;padding-left : 0px;background-image:none; "alt=" image "src=" http://s3.51cto.com/wyfs02/M00/6E/4A/ Wkiol1v4v1zqa7neaaf0khfkqoe139.jpg "border=" 0 "/>

I am here to upgrade directly to SP3 and then reboot and run this command eseutil/ml log file name as shown in:

650) this.width=650; "height=" 387 "title=" image "style=" Border:0px;padding-top:0px;padding-right:0px;padding-left : 0px;background-image:none; "alt=" image "src=" http://s3.51cto.com/wyfs02/M01/6E/4A/ Wkiol1v4v1yibmsbaaimohypgs0102.jpg "border=" 0 "/>

Below, let's look at a specific view, focusing on the first four rows,

These lines of the

Log file header indicate that the log file is the current log file, and the lGeneration line indicates that when the log is populated and closed, its ordinal number will be 49 , corresponding to the decimal value . The base name is E01 , so the final log file name will be E0100000049.log. The Checkpoint value is not actually read from the log file header, but it appears to be read from the log file header. Eseutil.exe reads the Checkpoint value directly from the E nn . chk, so that you do not have to enter a separate command to understand the location of the checkpoint file. If the checkpoint file has been corrupted, the Checkpoint value is displayed as not AVAILABLE . In this example, the checkpoint is in the current log file ( 0x50 ), the number ffff and FFFF Indicates the location of the checkpoint in the log file. In general, we seldom use checkpoint information when repairing or restoring a data file. If the checkpoint file is corrupted, Exchange can still correctly recover and replay the log files. Only exchange will scan the log files from the beginning, starting with the earliest available files, rather than starting from the checkpoint log. Exchange skips data that has been applied to the database (data written to the database), and processes the log sequentially until it encounters the data that must be applied. Typically, an Exchange scan takes only two seconds to log files that have been applied to the database. If the log file contains operations that must be written to the database, the application operation may take from 10 seconds to a few minutes. On average, the contents of a log file can be written to the database in 30 seconds or less.

When the Exchange database shuts down gracefully, all data that is not processed is written to the database file. After a graceful shutdown, the database file set is considered consistent, and Exchange separates it from the log stream. This indicates that the database file is now a self-contained file (up-to-date). You do not need a transaction log to start the database file. Although you can delete a log file after you close all the databases, doing so will affect the ability to restore an earlier backup and roll forward. Existing log files are no longer required for the current database, but they may be required if you have to restore an earlier database.

By running the ESEUTIL/MH command and checking the database file header, you can tell if the database is closed properly if the display state is Cleanshutdown. is displayed as normal shutdown, otherwise, congratulations, just fix it ... A painful and lengthy process. If the database is in a dirty shutdown state, all existing transaction logs after the checkpoint must be provided before the database can be mounted again. If these logs are not available, you must run the eseutil/p command to repair the database so that the database is in a consistent state and can be started. Repair the database, there will be lost data. Although the amount of data loss is usually very small, it can be catastrophic. After you run eseutil/p on the database, you should run eseutil/d to defragment the database. This operation discards and rebuilds all database indexes and the spatial tree as shown in:

650) this.width=650; "height=" 507 "title=" image "style=" Border:0px;padding-top:0px;padding-right:0px;padding-left : 0px;background-image:none; "alt=" image "src=" http://s3.51cto.com/wyfs02/M02/6E/4A/ Wkiol1v4v1zg-rpaaaltdzdxbkg978.jpg "border=" 0 "/>

Circular Logging

Many administrators like to enable circular logging for a database in order to conserve disk space, or the space will generate very large log information until the disk space is exhausted, affecting normal use. In Exchange 2010, circular logging is disabled by default. By enabling circular logging, you can reduce the requirement for drive storage space. However, if you do not have a complete set of transaction log files, you cannot recover any data that is later than the last full backup. In a normal production environment, it is recommended that circular logging not be enabled:

650) this.width=650; "height=" 463 "title=" image "style=" Border:0px;padding-top:0px;padding-right:0px;padding-left : 0px;background-image:none; "alt=" image "src=" http://s3.51cto.com/wyfs02/M00/6E/4A/ Wkiol1v4v12twyxnaaeos4ogj7a634.jpg "border=" 0 "/>

If Exchange 2010 uses standard transaction logging, each database transaction is written to the log file and then written to the database. If the log file size reaches 1 MB, the file is renamed and a new log file is created. Over time, a set of log files is generated. If Exchange stops unexpectedly, you can recover the transaction by replaying the data in these log files into the database. Circular logging allows Exchange to overwrite these transaction log files after the data contained in the transaction log file is committed to the database. However, if circular logging is enabled, you can restore data to only the previous full backup. Therefore, when you typically do not have a dedicated backup of the Exchange database, you can enable circular logging, which is required to prevent too many log files from affecting the normal application. Therefore, effective backup of the database is an effective way to control the growth of log files.

This article is from the "Duffy" blog, make sure to keep this source http://dufei.blog.51cto.com/382644/1660635

Exchange Server Operations Management 02: How the mailbox database is stored