中国.网管联盟
有人可能会问，假如数据库文档和日志文档同时损坏怎么办？答案是这样的：避免这种情况发生。首先，数据库文档损坏的概率要远远大于日志文档，另外，微软推荐的做法是把数据库文档和日志文档分别放置在不同的磁盘上。我们会在下一期的文章中着重讨论这个问题。
管理员针对日志文档的抱怨是，这些文档会每天不断的增长，大量消耗硬盘空间。对于这个问题，唯一合理的解决办法是：定期的做针对Storage Group的全备份或增量备份。因为Exchange Server会在全备份或增量备份完成后把这次备份之前产生的Log文档全部删除。很多管理员手动的删除日志文档，或启动“循环日志”来减少对硬盘空间的消耗，这都是不正确的做法。残缺不全的日志文档会使系统在进行备份恢复的时候无法还原到最近的状态。假如您的系统是一周做一次全备份，而您碰巧又在备份后删除了一些日志文档，那么您就有可能在需要恢复的时候丢失备份以后的数据。记住，数据总是比磁盘空间更宝贵。
ESE数据库引擎连同Information Store服务的启动和关闭
www_bitscn_com
在ESE引擎加载数据库文档时，他会检查数据库文档的一个特别标志位。这个标志位保存了数据库文档上次是否被正常关闭。这个状态由“ Consistent”或“ Inconsistent”来表示。对于一个正常关闭的数据库文档，任何在Log文档和内存中的内容都应该已提交到数据库文档中，只有在这个时候，数据库才会被标记为“ Consistent”。有一点需要注意，在运行中的数据库，他的状态一定是“ Inconsistent”，因为在Log文档中肯定更有没提交到数据库文档内容。对于一个已关闭并且状态被标示为“ Inconsistent”的数据库，并不意味着这个数据库库文档损坏了，“ Inconsistent”只是表示，更有未曾写入到数据库文档的内容保存在Log文档中。 www_bitscn_com
使用命令 ESEUTIL /MH能够查常看数据库的关闭状态。
C:\...\Exchsrvr\BIN> ESEUtil /mh “C:\...\Exchsrvr\mdbdata\priv1.edb” Microsoft(R) Exchange Server(TM) Database Utilities Version 6.0 Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved. Initiating FILE DUMP mode... Database: C:\program files\exchsrvr\mdbdata\priv1.edb File Type: Database Format ulMagic: 0x89abcdef Engine ulMagic: 0x89abcdef Format ulVersion: 0x620,9 Engine ulVersion: 0x620,9 Created ulVersion: 0x620,9 DB Signature: Create time:03/28/2004 20:26:24 Rand:6536656 Computer: cbDbPage: 4096 dbtime: 63139 (0-63139) State: Clean Shutdown <-----表示数据库关闭时的状态 Log Required: 0-0 Streaming File: Yes 中国.网管联盟 Shadowed: Yes Last Objid: 574 …<略> … Operation completed successfully in 1.391 seconds. |
State字段的“Clean Shutdown”表示数据库处在Consistent状态。
当ESE加载数据库文档时，对于“Consistent”的数据库文档，他直接Mount其中的Store；对于“In consistent”的数据库文档，ESE将执行称之为“Soft Recovery”的过程，在这个过程中，未及时提交进数据库文档的日志内容将被写入数据库。当任何的日志都写入完毕，数据库才会被标记为“ Consistent”状态，然后正常加载。
Soft Recovery开始的时候，ESE会根据check point文档所指向的位置来进行Log文档的写入(假如check point文档也损坏或不存在，那么数据库就从最旧的Log文档开始)。当ESE从Log文档向Store写入数据时，他会根据dbTime这个时间戳来决定是否需要把Log文档写入到数据库。 www.bitsCN.com
在这个过程中，Event Log中会有如下的记录
Event Type: Information Event Source: ESE98 Event Category: Logging and Recovery Event ID: 301 Date: 10/17/2001 Time: 5:52:11 AM User: N/A Computer: <server_name> Description: Information Store (XXXX) The database engine has begun replaying logfile ..\..\E0014553.log. |
我们也能够针对已“Dis-mount”的并且是处在“Inconsistent”的数据库手工地进行“Soft Recovery”。
bitscn.com
具体的命令是“eseutil /r”，后跟数据库文档的路径。（推荐在掉电重启以后执行此命令，能够先运行eseutil /mh确定数据库状态，假如是“Inconsistent”，再执行此命令）
由此我们能够发现，Exchange Server有能力对未正常关闭的
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
