Talking about Exchange Server mail storage System-Principles (1)

From the perspective of database fundamentals, this article explores the workings and maintenance skills of the Exchange Server mail storage system through an analysis of the Exchange Server store module. This article is intended for professional IT staff with a certain Exchange Server management experience, and is designed to enable readers to know and know what to do when maintaining an Exchange Server messaging system. The hierarchical relationship between the information store and the extensible Storage Engine is well known, in Exchange Server, information store Service is of paramount importance. This service controls the operation requests for mailboxes and public folder databases. Further, the fact that the database system for Exchange Server is managed by the database engine named Extensible Storage Engine (ESE). This ESE engine is developed by Microsoft specifically for the preservation of non relational data, and is applied in many Microsoft systems: for example, the database for AD (Ntds.dit files), Windows DHCP, Windows WINS, SRS, and so on, and the backend is supported by the ESE database.

As we know, the database for Exchange server consists of the EDB file, the STM file, and numerous log files. Within these files, Microsoft uses an internal data structure called "B + Tree", one of the tasks of the ESE engine is to translate these requests into read and write access to the internal data structure when the information Store service requests access to the database. B + trees are characterized by the ability to provide fast access to data stored on disk. One reason Microsoft chooses the B + tree as the ESE background structure is to maximize I/O performance when accessing data. The structure of these B + trees is transparent to the Exchange Server Store service, and the store simply sends the request to ESE, which the ESE operates on. In addition, as a database system, ESE is responsible for providing support for transaction (Transaction) level operations and maintaining the integrity and consistency of the entire database. For modern database systems, when we refer to transactions, we typically use an abbreviation such as acid to describe the characteristics of a transaction:

We will discuss in detail how Exchange Server and ESE achieve the above requirements in a later space. For the Information Store Service, ESE encapsulates all the details of the database operation, which is only invoked based on the interface provided by ESE. In Exchange Server 2000, the IS service corresponds to a process that is store.exe, and each storage group produces an instance of the ESE engine in the Store.exe process.

new features of the Exchange Server 2000/2003 storage System When Microsoft publishes Exchange Server 2000, Exchange Server's storage systems are greatly updated and improved. From the ESE engine's point of view, the version of ESE is upgraded from ESE97 in 5.5 to ESE98 and is improved in the following ways: 1.I/O performance is further optimized and increased by 2. The log file is added to compute checksums, further reducing the likelihood of database errors by 3. Increased the speed of maintenance tools such as Eseutil the Information store update is more noticeable than the one behind the scenes of the ESE engine, for example: 1. Provide support for multiple storage group and store on each server, This is one of the biggest features that distinguish it from 5.5.2. The introduction of STM streaming file format in database enhances the introduction of 3.Web Storage system, which can access the relationship between database EDB files and STM files using multiple protocols. in Exchange Server 5.5, the database has only files with the extension EDB. At the time of Exchange Server 5.5, Microsoft focused on the enterprise's internal messaging system, where the main push was the MAPI protocol, the Microsoft Private Mail protocol, which was specifically optimized for this protocol in the EDB format. Therefore, in order to support Internet-standard SMTP message formats, Exchange Server 5.5 has a huge performance penalty for translating Internet mail into a format that EDB can recognize each time it is processed.

In Exchange Server 2000, Microsoft has increased its support for Internet Standard protocol SMTP. As a result, the storage that applies to Internet-formatted messages comes into being: This is the STM file. Messages in MAPI format are based on Microsoft's RPC and binary standards, whereas Internet-formatted messages consist of plain-text headers and MIME-encoded character streams. The nature of the two determines that they cannot share a file in a database structure. Therefore, in Exchange Server 2000, Microsoft uses both the EDB file and the STM file to save messages in both formats, and establishes associations and references between the EDB and the STM files. For the user, his mailbox content is actually made up of content that spans both the EDB and STM files. It is worth mentioning that in addition to the actual letter information in the EDB file, information such as the mailbox structure of each user, the contents list and view of each folder is saved. This is the difference between the only character streams that are stored in the STM. We discuss the use of the EDB and STM files in the following situations: 1. Users use Outlook as a MAPI protocol and send and Access message 2. Users use Internet protocols such as SMTP/POP3 to access Exchange Server. Scenario One: When a message is submitted to a database from a client of a MAPI protocol (usually outlook in Microsoft Office), the content of the message is saved in the EDB file. When a user accesses a message in a mailbox through a MAPI-protocol client, if the requested message is saved in the EDB file, the letter is opened directly and returned to the user. If the requested letter is saved in an STM file (this letter is in SMTP format), the Exchange server database engine first converts the data format in the STM file to a MAPI-recognizable format and then sends it to the client. This process is called "On-demand conversion". Scenario Two: Users use SMTP/POP3 clients (such as Outlook Express, Foxmail, etc.) to connect to the mailbox. When the SMTP protocol submits mail to Exchange Server, the contents of the message are saved in the STM file. As mentioned earlier, the EDB file contains a list of folder and letter contents for the user's mailbox. Therefore, when the message is saved to the STM file, the database engine extracts some important information about the message (usually the contents of the message header and the location of the letter in the STM file) and saves it to the EDB file. This process is called "Property promotion". It is with this process that users can get the full contents of the mailboxList, a MAPI client needs to access a message in an STM file to get the correct location of the letters in the STM file. When a user uses the POP3 protocol to read a message, if the message being accessed is in the EDB file, a transformation from MAPI to the Internet format ("On-demand conversion") is also silently occurring in the background.

From the above description, we know that in the actual Exchange Server environment, these two files are closely related. Do not operate these two files individually at any time, always treat them as a whole. The EDB file contains a list of contents for each mailbox (store tables), and requests must be made to the EDB file when the client needs to get the contents of the folder. Files in both formats provide support for the two types of protocols, effectively reducing the occurrence of unnecessary format conversions.

Article source Http://bbs.5dmail.net (Chinese name: 5dmail Mail Information Network)