Linear Log Archive Consumes the Production LUN
PROD.QM runs on RHEL 7 with linear logging. Its log directory is a 100 GB LUN; message data is on a separate volume. The queue manager carries persistent order traffic, about 3,000 messages per second at peak, and 40 sender/receiver channels. At 02:15 monitoring reports /var/mqm/log at 92% and rising. Channels to the payments system have begun ending intermittently, and the batch window starts at 06:00. The last media image was taken six days ago. The backup team's policy says archive logs must be kept for 14 days, but they also require that PROD.QM remain recoverable to the latest committed transaction. A platform engineer proposes deleting every archive log extent to free space immediately. You cannot stop the queue manager, and no committed messages may be lost. The queue manager is still running, but new log extents cannot be created reliably. The SAN team can add space, but not before 09:00.
1. What is the safest immediate sequence to reclaim space, and what must you verify before deleting any archive extent?
Read the worked answer
- Do not delete active logs or the whole archive. First confirm the queue manager is still running and that channels are not in a log-full loop:
DIS QMSTATUSandDIS CHSTATUS(*) STATUS. - Record a media image while PROD.QM is running:
rcdmqimg -m PROD.QM -t all. This writes a consistent image of all objects into the log stream. - Identify the archive extent that contains the start of the completed media image. Only extents wholly older than that point are candidates for deletion. Delete the oldest archive extents first, in small batches, until usage is below the agreed threshold (for example 70%). Never touch
active. - Re-check
DIS QL(*) CURDEPTHand channel status, and put a persistent test message to confirm logging still works.
Reasoning: until a media image exists, every archive extent may be needed to replay committed transactions. After the image, recovery starts from the image, so older extents are no longer needed. The safety margin covers in-flight transactions and image-recording time.
2. The 14-day archive retention policy conflicts with the recovery requirement. How do you redesign image scheduling and archive pruning without simply adding disk?
Read the worked answer
Set the media-image interval from the recovery objective, not from the backup team's fixed archive retention. If the requirement is recovery to the latest committed transaction, the archive only needs to bridge from the most recent media image to the current log. A practical design is: schedule rcdmqimg every 6 hours (or at least once per day), prune archive extents immediately after each successful image, and keep one extra image generation plus a margin. If the fix pack supports MQ linear-logging archive management attributes (for example MAXARCHLOGS/MAXLOGSIZE), use them as a backstop; otherwise automate the rcdmqimg-plus-prune job and monitor it. Separate the log LUN from message data, alarm at 70% and 85%, and revise the backup policy to 'latest media image + retained logs' rather than a fixed 14 days. Increasing the LUN alone only postpones the problem.
3. How would you prove that pruning has not made PROD.QM unrecoverable?
Read the worked answer
Build a recovery test on a separate queue manager, not on PROD.QM. Copy the retained media image and all log extents from the image onward to a test system with the same MQ version and object definitions. Start the test queue manager in recovery mode, let it replay the logs, and check that the last committed persistent message is present and that no queue has an unexpected depth. Also confirm that the oldest retained archive extent is not newer than the media image start; a gap makes recovery impossible. Only after that test should the production archive be pruned further. If a test restore is not possible, keep at least one full image generation of logs and record the oldest required extent in the runbook.