A primary rule of thumb is to separate sequential and random I/O. An Exchange 2000 Server database consists of multiple file types and access patterns, depending on the type of clients that your implementation supports. Messaging API (MAPI) protocol clients don't utilize the streaming store; for Internet protocol clients (i.e., IMAP, POP3, SMTP), the streaming store is the primary storage location. Also, each Exchange Server storage group (SG) has one set of shared database transaction logs, and you can configure each SG with multiple database files (i.e., combined property store.edband streaming store.stmfiles). Because the Exchange Server database engine accesses the transaction log (.log) files in a strictly sequential manner, each SG should have a dedicated disk volume (preferably RAID 1 or RAID 0+1) in which to store the files. Depending on the supported clients, you might also choose to separate the property store and the streaming store on separate physical volumes. However, because of the cost of such a configuration and a lack of performance data justifying separation, most deployments choose to place both stores on the same volume and configure that volume as RAID 5 or RAID 0+1 for maximum performance and data protection. Table A shows some general storage guidelines.
End of Article
You must be a registered user or online subscriber to comment on this article. Please log on before posting a comment. Are you a new visitor?
Register now
While Microsoft is still investigating a notebook battery life issue that was supposedly caused by Windows 7, some interesting trends have emerged. ...
Microsoft on Monday issued a lengthy statement about the recent Windows 7 battery controversy, echoing my assessment from earlier in the day, but backing it up with hard, cold evidence. ...
Should Your Email Live in the Cloud? This Forrester report shows how-to calculate your on-premise email costs and compare with cloud-based alternatives and offers best practices for reducing email costs.
New from Left-Brain.com - Manage VMware with PowerShell Learn how to perform everything from simple ad-hoc reporting at the command-line to complex scripts that automate a massive deployment of hundreds of virtual machines. Solve your old problems using less code than you thought possible!