Exchange存储子系统简介(1): Information Store和Extensible Storage Engine的层次关系 -->见下图:
Exchange存储子系统简介(2): Atomic(原子的): 事务必需是全有或者全无的操作. 要么全部都成功的得到更新,要么全部都成功的得到更新,要么全部都不被更新. Consistent(一致的): 一个成功提交(commit)的事务必需使数据库处在一个一致的状态.(数据库结构正确,所有的约束和关联都得到满足) Isolated(孤立的): 所有未提交的更改都必需能够和其他事务孤立,即其他事务无法看到其他事务中正在进行的更改. Durable(持久的): 当事务一旦提交,所做的更改必须存放到稳定的存储介质上,防止系统失败而引起数据库不一致.
Exchange存储子系统简介(3): Exchange Server 2000/2003存储系统的新特点: 从ESE引擎的角度来看,在如下方面得到了改进: I/O性能得到进一步的优化和提高 对日志文件增加了计算校验和操作,进一步降低了数据库出错的可能性 提高了ESEUtil等维护工具的速度 Information Store方面的更新,例如: 在每台Server上提供多个Storage Group和Store的支持,这是区别于5.5的最大特征之一 数据库中stm流文件格式的引入,提高了操作Internet邮件的性能 Web Storage System的引入,用户可以使用多种协议访问数据库
EDB文件和STM文件的关系(1) -->见下图:
EDB文件和STM文件的关系(2) -->见下图:
log文件的作用(1) Exchange log文件的特征 为什么需要日志文件? 作为一个企业级的邮件数据库系统,必需做到数据安全和完整性的万无一失.必需能够面对随时可能发生的崩溃和宕机,What happens if we crash? 要能够把数据的损失减少到最新程度. 必需提供高性能的邮件吞吐能力,对数据库中的邮件的事务操作在完成后必需马上被记录到存储介质上(事务的持久性). 当灾难发生时,使用数据库的备份恢复必需要返回到灾难发生前一该的数据库状态.
log文件的作用(2) 如何通过日志文件来达到上述的要求??? -->见下图:
log文件的作用(3) 建议和忠告: 永远不要删除日志文件 万不得已不要启动循环日志 日志和数据库放在不同的磁盘阵列上
ESE数据库以及Information Store服务的启动和关闭: Exchange Server数据库的状态: "Consistent"或"Inconsistent" ESEUTIL/MH可以查常看数据库的关闭状态 未正常关闭数据库的恢复: Soft Recovery(eseutil/r) Exchange会自动执行此操作 结论: 掉电/宕机,不会使Exchange数据库损坏
M盘的来龙去脉(1) Web Storage System: 文件系统/IFS Http WebDAV ExOLEDB/ADO CDO Dir:\\.\BackOfficeStorage\domain.con\MBX 更改虚拟盘的盘符名称: HLKM\System\CurrentControlSet\Services\ExIFS\Parameters Name: DriveLetter Data Type: REG_SZ Value: Drive letter for IFS(盘符,不需要跟冒号)
M盘的来龙去脉(2) 一定不要让文件级的防病毒软件扫描M盘 M盘的手工映射: Subst X: \\.\BackOfficeStorage 注释: 把Exchange Store映射到X盘 Subst /d M: 注释: 删除对M盘的映射
本文转自 叶俊生 51CTO博客，原文链接:http://blog.51cto.com/yejunsheng/162384