Before Exchange Server can commit a transaction, it must perform a series of operations. You might not think transactions often reference cached pages, but when an inbox receives multiple messages over a short time, the first transaction caches inbox data and subsequent transactions access inbox data in memory.Įxchange Server maintains data integrity by writing every transaction to a log file Exchange Server never commits a transaction to a database unless the transaction is complete. Page caching also improves performance: When a transaction uses an already-cached page, Exchange Server can update the page in memory rather than generating additional disk operations.
When system load permits, Exchange Server commits the pages in the cache to the appropriate store.Įxchange Server manipulates database pages in the cache to adjust the order of transactions and optimize the process of committing transactions to the database. After a transaction occurs, Exchange Server records it in the current log and writes the modified database pages to a memory cache. Exchange Server logs every IS and Directory transaction from every source. Before Exchange Server commits data to one of the stores, it writes the data to a log file. The IS and Directory use a write-ahead transactional model to protect data. The databases' transaction logs (the IS and Directory each have a set) need protection too. But administrators mustn't limit data protection for Exchange Server to the databases. I applaud systems administrators who take these precautions-the IS and Directory need as much protection as possible. Administrators use RAID 5 or RAID 0+1 disk configurations to protect data perform frequent backups and carefully plan the stores' location on their servers' available disk volumes.
Systems administrators expend a great deal of effort to protect these databases. The Information Store (IS) and Directory form the core of Microsoft Exchange Server. Don't lose data-protect your transaction logs
0 kommentar(er)
