WebSphere MQ 事务日志文件系统已满

发布于 2024-11-06 07:10:43 字数 378 浏览 2 评论 0原文

事务日志文件系统 (/var/mqm/log) 已满,并且在尝试客户端连接到此队列管理器时,我遇到了队列管理器的 MQRC 2102 资源问题。我们可以采取什么行动来解决这个问题?

LogPrimaryFiles=2  
LogSecondaryFiles=8 
LogFilePages=16384 
LogType=CIRCULAR 
LogBufferPages=0 
LogPath=/var/mqm/log/QMGRA/ 
LogWriteIntegrity=TripleWrite

向 /var/mqm/log 添加额外的磁盘空间是唯一的解决方案吗?

我有几个队列已满,但队列存储文件系统仅使用了 60%。

请给我一些对此的想法。

Transactional log file system(/var/mqm/log) become full and i am getting MQRC 2102 resource problem with Queue Manager while attempting client connection to this queue manager. What course of action we can do to resolve this?

LogPrimaryFiles=2  
LogSecondaryFiles=8 
LogFilePages=16384 
LogType=CIRCULAR 
LogBufferPages=0 
LogPath=/var/mqm/log/QMGRA/ 
LogWriteIntegrity=TripleWrite

Is adding additional disk space to /var/mqm/log is the only solution?

I have few queues that were full,but queue storage file system were only 60% used.

Please give me some ideas on this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

歌枕肩 2024-11-13 07:10:43

每个日志文件页为 4096 字节,因此 LogFilePages=16384 设置会导致每个日志文件页大小为 64MB。通过设置 LogPrimaryFiles=2LogSecondaryFiles=8,最多可以有 10 个日志文件,总大小为 640MB。如果循环日志所在的文件系统小于此数量,则可能会填满。

这里的最佳解决方案是将日志文件磁盘分配的大小增加到略大于日志文件范围所需的大小。如果这是不可能的或者您需要临时修复,则需要通过减少扩展区数量并重新启动 QMgr 来更改日志文件要求的大小。请注意,您可以调整日志范围的数量,但不能调整范围的大小。如果需要更改 LogFilePages=16384 参数,则需要重建 QMgr。

范围的数量和大小代表同步点下可以同时处理的数据总量,但在大多数情况下 640MB 就足够了。就时间而言,它还限制了活动 QMgr 上工作单元的最长可能持续时间。这是因为如果日志文件中的头指针超过了尾指针,则未完成的事务将被回滚。例如,假设一个通道进入重试状态。这将在同步点下保存一批消息并保持该日志范围处于活动状态。当应用程序和其他通道执行其正常操作时,额外的事务会驱动头指针向前移动。最终,所有范围都将被使用,尽管可能只有很少的未完成事务,但最旧的事务将被回滚以释放该范围并将尾指针向前推进。如果错误日志显示许多事务已回滚到可用日志空间,那么您确实需要为日志文件分区分配更多空间并增加扩展区数量。

Log file pages are 4096 bytes each so a setting of LogFilePages=16384 results in log files extents of 64MB each. With a setting of LogPrimaryFiles=2 and LogSecondaryFiles=8 there can be up to 10 log files for a total of 640MB. If the file system that the circular logs resides on is less than this amount, it may fill up.

The optimum solution here is to increase the size of the log file disk allocation to something a little larger than the log file extents require. If that is not possible or you need a temporary fix then it is necessary to change the size of the log file requirement by reducing the number of extents and restarting the QMgr. Note that you can adjust the number of log extents but not the size of the extents. If it becomes necessary to change the LogFilePages=16384 parameter then it is necessary to rebuild the QMgr.

The number and size of of extents represents the total amount of data that can be under syncpoint at once but 640MB is generous in most cases. In terms of time, it also limits the longest possible duration of a unit of work on an active QMgr. This is because an outstanding transaction will be rolled back if it happens that the head pointer in the log file ever overtakes the tail pointer. For example, suppose a channel goes into retry. This holds a batch of messages under syncpoint and holds that log extent active. As applications and other channels perform their normal operations, additional transactions drive the head pointer forward. Eventually all extents will be used, and although there may be very few outstanding transactions the oldest one will be rolled back to free up that extent and advance the tail pointer forward. If the error log shows many transactions are rolled back to free log space then you really would need to allocate more space to the log file partition and bump the number of extents.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文