:: Blog List ::
Exchange 日志最大流水号的问题
钉子 发表于 2008-7-3 10:28:57
好久没有上Winmag论坛，今天上去看到一个问题：
这位网友真细心，说实话可能很少有Exchange的管理员会想到这个问题。据我个人所知，这个问题只发生在Exchange 2000的版本上，并且微软已发布了相关的补丁(请看KB896001).
但讨论到日志的文件个数的问题，以下摘自最新Exchange Server 2007技术问答的内容应该完整解答了这个的问题。值得大家一看：
另外，再延续来谈日志文件。Exchange Server 2007前的日志文件是5M一个，而在Exchange Server 2007中已更改为1M。为什么要做这个改变？同样是这个问题集中也有精彩的回答，各位看官请看：
exchange 2003 日志有最大流水号的问题?
最近看到《网管员世界》杂志的一篇文章， 说exchange 2003 日志有最大流水号的问题， 详细如下扫描件。 我在网上找了，没有这方面的资料， 大家谁有经历过类似的经历， 谢谢！
最近看到《网管员世界》杂志的一篇文章， 说exchange 2003 日志有最大流水号的问题， 详细如下扫描件。 我在网上找了，没有这方面的资料， 大家谁有经历过类似的经历， 谢谢！
这位网友真细心，说实话可能很少有Exchange的管理员会想到这个问题。据我个人所知，这个问题只发生在Exchange 2000的版本上，并且微软已发布了相关的补丁(请看KB896001).
但讨论到日志的文件个数的问题，以下摘自最新Exchange Server 2007技术问答的内容应该完整解答了这个的问题。值得大家一看：
问：既然事务日志变短了，我们会不会很快就将事务日志“用完”?
答：在说到 Exchange 时，“用完”指的是事务日志名称。在 Exchange Server 2003 中，事务日志按如下方式命名：
E nn fffff.log
其中 nn 是在各 SG 间不断改变的前缀。由于 nn 在 SG 的生命周期中保持不变，因此，可为存储组创建的以唯一方式命名的事务日志的数量基本上为“fffff”值，大概是一百万个日志(记录自我：将小手指放在嘴角开始狂笑)。我们有一些客户在繁忙的邮件服务器上已经达到了此限制。
从 Exchange Server 2000 开始，我们提供了一个在接近此限制时会在应用程序日志中显示一个事件的修补程序。(有关此修补程序的详细信息，请参阅 support.microsoft.com/kb/896001。)
OK，我们有点扯远了，那么 Exchange 2007 中到底有哪些变化?我们刚刚说过，事务日志大小从 5MB(早期版本 Exchange 中的大小)降到了 1MB (Exchange 2007 中的大小)。这是不是意味着只需五分之一的数据就能用完唯一事务日志名称?
答案是否定的。在 Exchange 2007 中，事务日志名称的格式如下：
E nn ffffffff.log
请注意，现在我们可使用“ffffffff”个日志，而不只是早期版本 Exchange 中“fffff”个日志。由于内部的“可扩展存储引擎”(ESE) 数学运算，Exchange 2007 无法创建所有“ffffffff”个日志。它会改为创建“7fffffec”个日志，这个数目仍然相当大。(如果您不相信我们，可将此数字从十六进制转换为十进制!)
在现实生活中，这意味着什么?在现实生活中，这意味着使用 Exchange 2007 可以创建的日志数大约比早期版本 Exchange 多出 2048 倍。现在，让我们将五分之一大小的日志作为因素计入在内：
2048 / 5 = 409.6
正如您所看见的，新的日志命名模式所处理的数据要比旧模式处理的多出 409 倍!而且请切记，是每个 SG 而不是每个服务器，因为每个存储组都将有一个不同的日志文件前缀(如 e00、e01 等等)。我们是否提过在 Enterprise 版本的 Exchange 2007 中，可为每个服务器创建 50 个 SG?我们认为，不太可能有人随时很快就用完事务日志!
答：在说到 Exchange 时，“用完”指的是事务日志名称。在 Exchange Server 2003 中，事务日志按如下方式命名：
E nn fffff.log
其中 nn 是在各 SG 间不断改变的前缀。由于 nn 在 SG 的生命周期中保持不变，因此，可为存储组创建的以唯一方式命名的事务日志的数量基本上为“fffff”值，大概是一百万个日志(记录自我：将小手指放在嘴角开始狂笑)。我们有一些客户在繁忙的邮件服务器上已经达到了此限制。
从 Exchange Server 2000 开始，我们提供了一个在接近此限制时会在应用程序日志中显示一个事件的修补程序。(有关此修补程序的详细信息，请参阅 support.microsoft.com/kb/896001。)
OK，我们有点扯远了，那么 Exchange 2007 中到底有哪些变化?我们刚刚说过，事务日志大小从 5MB(早期版本 Exchange 中的大小)降到了 1MB (Exchange 2007 中的大小)。这是不是意味着只需五分之一的数据就能用完唯一事务日志名称?
答案是否定的。在 Exchange 2007 中，事务日志名称的格式如下：
E nn ffffffff.log
请注意，现在我们可使用“ffffffff”个日志，而不只是早期版本 Exchange 中“fffff”个日志。由于内部的“可扩展存储引擎”(ESE) 数学运算，Exchange 2007 无法创建所有“ffffffff”个日志。它会改为创建“7fffffec”个日志，这个数目仍然相当大。(如果您不相信我们，可将此数字从十六进制转换为十进制!)
在现实生活中，这意味着什么?在现实生活中，这意味着使用 Exchange 2007 可以创建的日志数大约比早期版本 Exchange 多出 2048 倍。现在，让我们将五分之一大小的日志作为因素计入在内：
2048 / 5 = 409.6
正如您所看见的，新的日志命名模式所处理的数据要比旧模式处理的多出 409 倍!而且请切记，是每个 SG 而不是每个服务器，因为每个存储组都将有一个不同的日志文件前缀(如 e00、e01 等等)。我们是否提过在 Enterprise 版本的 Exchange 2007 中，可为每个服务器创建 50 个 SG?我们认为，不太可能有人随时很快就用完事务日志!
另外，再延续来谈日志文件。Exchange Server 2007前的日志文件是5M一个，而在Exchange Server 2007中已更改为1M。为什么要做这个改变？同样是这个问题集中也有精彩的回答，各位看官请看：
问：你们为什么在 Microsoft® Exchange Server 2007 中将事务日志大小降到了 1MB？
答：噢，在 Exchange 2007 中，我们增加了这项称为日志传送的酷炫技术，这项技术也是被称为本地连续复制 (LCR) 和群集连续复制 (CCR) 这两个新功能的强大后盾。当在存储组 (SG) 级启用此技术时，会将 SG 事务日志从运行的生产 SG 复制到副本 SG。然后，副本 SG 上的事务日志会重播到数据库中，以使数据库保持最新。这么解释此过程显然简单了些，但您可以获得一个大概印象。
难题在于，除非事务日志在生产 SG 上关闭，否则无法将其发送给副本 SG。换句话说，直到 e00 日志（第一个存储组中的当前日志）填满、关闭和重命名之后才能将其发送。另外，还有一些设置可以控制在此过程中可以有多少个后台日志，因为在可用性与性能之间要有一个权衡抉择。（在 Exchange 管理外壳中运行 Set-MailboxServer cmdlet，即可以使用这些设置。帮助文件提供了关于所需确切参数的详细信息。）
长话短说，为了将超出存储组两个副本间同步范围的数据量降到最低，我们降低了事务日志大小。假设在生产数据库硬盘驱动器崩溃并且您需要采取行动从副本启动 SG 时，这就开始起作用了。事务日志越小，就越有可能减少丢失的数据。
这并不表示我们可以保证您只丢失 1MB 数据。举例来说，既然这些好像是事务日志，因此有可能丢失的 1MB 日志文件中会含有用于提交 5MB 数据的 COMMIT 事务。在这种情况下，副本中就会缺失这 5MB 的数据 - 即使您可能已收到含有数据其本身的五个日志，但含有少量数据和那个必需的 COMMIT 事务的最后一个日志也是必不可少的。
最终还是由您自己根据业务需求来衡量是否可以接受这个风险。与花费数小时才能完成的还原工作相比，只需几分钟时间来恢复少量丢失的数据也许是完全可接受的。我们将来肯定还会讨论更多关于这个主题的内容！
cndgm发表评论于2009-2-27 15:48:05
下面的KB有介绍重置办法：
Store databases are dismounted without warning or users cannot log on to their mailboxes in Exchange Server 2003 or in Exchange 2000 Server
| 更多分享链接
发表评论：
Best view with 1024 x 768 pixel & IE 6.0.
About Me
Archives Categories
Replies List
My FriendLinks
Blog Info
