Exchange 2007队列数据库、队列事务日志文件超过临界值(阈值)导致无法接受

Exchange 2007队列数据库、队列事务日志文件超过临界值(阈值)导致无法接受邮件解决方案

前天,客户Exchange 2007邮件系统突然出问题了。具体表现如下:

只能发邮件,不能收邮件。OUTLOOK中点击“发送和接收”测试,只有正在发送,没有正在接收状态。

查看日志发现如下提示:

The Microsoft Exchange Transport service is rejecting message submissions because the available disk space has dropped below the configured threshold

Resource utilization of the following resources exceed the normal level:

Queue database and disk space ("C:"Program Files"Microsoft"Exchange Server"TransportRoles"data"Queue"mail.que") = 98% [High] [Normal=93% Medium=95% High=97%]

Queue database logging disk space ("C:"Program Files"Microsoft"Exchange Server"TransportRoles"data"Queue"") = 98% [High] [Normal=93% Medium=95% High=97%]

No components were disabled because of back pressure.

The following resources are in the normal state:

Version buckets = 0 [Normal] [Normal=40 Medium=60 High=100]

Private bytes = 0% [Normal] [Normal=71% Medium=73% High=75%]

Physical memory load = 25% [limit is 94% before message dehydration occurs.]

1、确认问题是否由于磁盘空间引起

翻阅资料,发现确实是由于队列及队列日志引起的问题,在微软Technet资料中发现如下说明:“为防止数据丢失,存在 Exchange 可能停止接受邮件的情况。如果 队列数据库的事务日志与数据库位于不同的驱动器上,则这可能是可用磁盘资源不足导致的,此问题表明驱动器太小。”同时,该文中指出解决方案:“通过将队 列数据库移动到较大的驱动器,解决了该问题。”。

参考资料:

http://technet.microsoft.com/zh-cn/library/bb397220.aspx

https://www.igotitworking.com/problem/view/47/

时间: 2024-10-26 22:38:25

Exchange 2007队列数据库、队列事务日志文件超过临界值(阈值)导致无法接受的相关文章

如何防止SQL Server数据库的事务日志异常增长

server|数据|数据库 当事务日志扩展到无法接受的限度时您必须执行的步骤.事务日志的扩展会导致 Microsoft SQL Server 数据库无法使用. 在 SQL Server 2000 中,每个数据库都至少包含一个数据文件和一个事务日志文件.SQL Server 2000 在该数据文件中以物理方式存储数据.事务日志文件存储您对 SQL Server 数据库执行的所有修改的详细信息,以及执行每个修改的事务的详细信息.由于事务完整性被视为 SQL Server 的一个基本而固有的特点,因此

SQL Server 2008 R2 清空数据库中ldf日志文件

/************************************************************  * Sql Server 2008 R2 清空数据库中ldf日志文件  * 将Whir_InternalSystem替换为您要操作的数据库即可  ************************************************************/ USE [master] ALTER DATABASE [Whir_InternalSystem]  S

删除SQL数据库中事务日志方法

  DUMP TRANSACTION [数据库名] WITH NO_LOG BACKUP LOG [数据库名] WITH NO_LOG DBCC SHRINKDATABASE([数据库名])

数据库日志文件丢失时的恢复步骤

恢复|数据|数据库 The information in this article applies to: - Microsoft SQL Server 7.0,2000      数据库日志文件丢失时的恢复步骤Revision History:Version Date Creator Description 1.0.0.1 2003-3-25 郑昀 草稿        Implementation Scope:本文是用于向Microsoft SQL Server维护人员描述我误删除了数据库的事

sql点滴39—解决数据库日志文件过大的问题

原文:sql点滴39-解决数据库日志文件过大的问题 随着数据库使用时间增长,日志文件也在不停的增大,这里介绍几种方法减小这个文件的方法. 1.直接删除log文件 分离数据库.分离数据库之前一定要做好数据库的全备份,选择数据库--右键--任务--分离,如下图 将日志文件和数据文件复制粘贴到另外一个文件夹中以防万一.删除链接,如下图 直接删除日志文件,然后再附加数据库,如下图 附加的时候会自动将ldf文件和mdf文件都附加上,但是会提示找不到ldf文件,没关系,选中ldf文件这一行,点击下面的删除按

sql server日志文件总结及日志满的处理办法

server     交易日志(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分.由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志. 交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中.对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态.从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录.每

sqlserver日志文件总结及充满处理

交易日志(Transaction logs)是数据库结构中非常重要但又经常被忽略的部分.由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志. 交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中.对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态.从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录.每个数据库都拥有至少一个

恢复MySQL数据库的日志文件

恢复MySQL数据库教程的日志文件 如果MySQL服务器启用了二进制日志,你可以使用mysql教程binlog工具来恢复从指定的时间点开始 (例如,从你最后一次备份)直到现在或另一个指定的时间点的数据."mysqlbinlog:用于处理二进制日志文件的实用工具". 要想从二进制日志恢复数据,你需要知道当前二进制日志文件的路径和文件名.一般可以从选项文件(即my.cnf or my.ini,取决于你的系统)中找到路径.如果未包含在选项文件中,当服务器启动时,可以在命令行中以选项的形式给出

SQLServer数据库中开启CDC导致事务日志空间被占满的原因

SQLServer中开启CDC之后,在某些情况下会导致事务日志空间被占满的现象为: 在执行增删改语句(产生事务日志)的过程中提示,The transaction log for database '***' is full due to 'REPLICATION'(数据库"***"的事务日志已满,原因为"REPLICATION"). CDC以及复制的基本原理粗略地讲,对于日志的使用步骤如下: 1,每当基础表(开启了CDC或者replication的表)产生事务性操作