Exchange传输队列queue数据库越来越大怎么办?

简介:

        大家好,今天为大家分享一下日常管理中Exchange数据库的一些维护操作。我们知道当我发送邮件时邮件都是先到一个Exchange的临时的队列数据库中,然后再提交到用户邮箱中。随着时间的推移队列数据库大小会不断的增加(查看传输队列数据库位置可以查看EdgeTransport.exe.config文件中的QueueDatabasePath和QueueDatabaseLoggingPath指向的路径即为队列数据库和日志所在位置),此时就需要管理员对传输队列数据库进行维护,减小传输队列数据库的大小或者将传输队列数据库移动到其他磁盘。通常引起传输队列数据库大小不断增加的原因可能是发送大量的邮件或存在发送大附件的邮件。

   首先,来看看队列数据库的文件结构。其中mail.que存放的是队列消息文件,也就是队列数据库。由于队列数据库是可扩展存储引擎 (ESE) 数据库,所有有日志检查点文件.chk。.log为日志文件。传输队列数据库设计的时候就自动开启了循环日志,已经写入到数据库的日志会自动清除。

image

    当传输队列数据库文件过大有哪些措施:

方法一、重新生成新的传输队列数据库。

方法二、对传输队列数据库进行整理,释放传输队列数据库空白空间。(此方法也适用于传输队列数据库因为大量邮件投递被迫停止,无法启动)

 

方法一我相信很多人都试过,就是首先将Exchange传输服务停止,然后将目录C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data下的Queue重命名为一个其他名字(例如:Queue.old),然后重新启动传输服务器,这样会重新生成一个信息队列数据库。这样操作之前要保证当前服务器的传输队列中没有还未投递的邮件,为了防止丢失邮件可以使用命令Get-Queue查看一下邮件队列情况。

image

 

下面着重分享一下方法二,在进行方法二操作之前首先要明确此方法可以应用于哪些场景:

1)、当传输队列数据库中堆积大量未发送的邮件,导致传输服务无法正常启动。

方法二的具体操作思路是,首先将传输队列数据库复制粘贴到其他备用位置(此时传输服务应处于停止状态),然后对传输队列数据库进行日志重播、磁盘碎片整理和修复等操作,最好将修复完成的队列数据库复制拷贝到队列数据库对应位置替换现有队列数据库文件(对应生产服务器上如果出现问题的服务器传输服务无法启动,又要及时恢复正常邮件收发,又要保证数据不要丢失;此时我们可以先按照方法一恢复正常邮件收发,然后将恢复后的队列数据库复制到另外的Exchange服务器的传输队列数据库,由其他Exchange服务器来负责将未发送的邮件发送出去。此时需要注意的是新Exchange服务器必须和源Exchange服务器的版本保持一致)

     下面我分享一个我之前测试的步骤

1、将传输队列数据库复制到临时目录。

2、打开Powershell,使用命令eseutil.exe /mh  “队列数据库完整路径”,查看数据库的状态,如果State: Dirty Shutdown,说明数据库处于异常关闭状态,需要进行日志重播和数据库修复。

image

 

3、接下来使用命令: esetuil  /r trn /d “队列数据库路径” /I  “日志文件路径”  对数据库进行日志重播,如果失败,则进行第四步操作。

image

4、对传输队列数据库进行日志重播失败后(软修复),只能进行硬修复了。使用命令 :  eseutil.exe /p “数据库完整路径”  /t “临时文件存放目录”

image

5、接下来使用命令: eseutil.exe /d “数据库路径” /t “临时文件存放路径”    对传输队列数据库进行数据整理,释放空白空间。

image

6、再次停止传输服务器,将修复后的队列数据库覆盖现有传输队列数据库,然后启动传输服务。(如果传输服务无法启动,需要将C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\queue目录下的其余文件剪切出去,只保留mail.que文件,然后启动传输服务。这样进行此步操作时要保证当前服务器的传输队列中没有未投递的邮件)

 

     我在执行过程中遇到如下问题,我的解决方法是将队列数据库文件复制到其他空目录中,然后再次运行命令进行修复。

image



本文转自 jialt 51CTO博客,原文链接:http://blog.51cto.com/jialt/1957429

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
8月前
|
关系型数据库 测试技术 分布式数据库
PolarDB | PostgreSQL 高并发队列处理业务的数据库性能优化实践
在电商业务中可能涉及这样的场景, 由于有上下游关系的存在, 1、用户下单后, 上下游厂商会在自己系统中生成一笔订单记录并反馈给对方, 2、在收到反馈订单后, 本地会先缓存反馈的订单记录队列, 3、然后后台再从缓存取出订单并进行处理. 如果是高并发的处理, 因为大家都按一个顺序获取, 容易产生热点, 可能遇到取出队列遇到锁冲突瓶颈、IO扫描浪费、CPU计算浪费的瓶颈. 以及在清除已处理订单后, 索引版本未及时清理导致的回表版本判断带来的IO浪费和CPU运算浪费瓶颈等. 本文将给出“队列处理业务的数据库性能优化”优化方法和demo演示. 性能提升10到20倍.
595 4
|
9月前
|
关系型数据库 MySQL PHP
php使用webSocket实现Echarts长连接自动刷新的解决方案(3):获取读取数据库数据队列进行实时刷新
php使用webSocket实现Echarts长连接自动刷新的解决方案(3):获取读取数据库数据队列进行实时刷新
122 0
|
11月前
|
Oracle 关系型数据库 数据库
使用日志传输的方法在两个数据库之间同步数据
源 oracle18:oracle18c-standby 192.168.17.26 目标 oracle18-2:oracle18c-primary 192.168.17.109
110 0
|
缓存 运维 负载均衡
Redis连环炮:内存淘汰?事务?分布式锁?分步式限流?异步队列?延时队列?高可用?如何部署?哈希槽?数据库和缓存的数据一致性?
Redis连环炮:内存淘汰?事务?分布式锁?分步式限流?异步队列?延时队列?高可用?如何部署?哈希槽?数据库和缓存的数据一致性?
184 0
Redis连环炮:内存淘汰?事务?分布式锁?分步式限流?异步队列?延时队列?高可用?如何部署?哈希槽?数据库和缓存的数据一致性?