| Author |
Message
|
| mq_population |
 Posted: Tue Jul 26, 2016 4:16 am Post subject: MQ Active Logs - are they cleared automatically |
 |
|
Apprentice
Joined: 14 Jul 2009
Posts: 26
|
Hi
I have a situation where the MQ logs are taking up a lot of space and need to reduce consumption . The logging is already "CIRCULAR" , but the number of primary and secondary logs are very high - 30 and 15 . I am planning to reduce them to 10 and 5 , and restart queue manager.
However I am not sure whether any of the active logs (S-******* Files) will be automatically removed by MQ ? If not , are there any ways to figure out which of them are not used . I am aware of a procedure for LINEAR logging but not for CIRCULAR logging.
Any suggestions ? |
|
| Back to top |
|
 |
| Andyh |
| Posted: Tue Jul 26, 2016 4:27 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
You MUST not manually delete any of the Snnnnnn.LOG files in a circular logging environment.
If you reduce the number of primaries and secondaries in the qm.ini and restart the queue manager then these changes will be reflected over time (not immediately) as the queue manager notices that the space isn't needed.
However if your current log usage requires the full amount of currently configured log space then changing this configuration won't result in any change in the number of log extents actually allocated as the queue manager will never find that the log space is no longer required. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 26, 2016 4:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you reduce the logs and they are needed you may run into some strange behavior when you run out of log space.
What you are planning to do is reduce your total log space from 45 files to 15 files (i.e. 1/3 of the original available space...).
What I would suggest is try it in 2 steps.
First keeping the global log space: i.e. 10 primaries and 35 secondaries.
Observe and see how many files are really being used over time. You have reduced the number of files that will always be allocated, but kept the global log space at the same level. If indeed it is not needed you can then reduce the number of secondaries...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mq_population |
| Posted: Tue Jul 26, 2016 4:39 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2009
Posts: 26
|
So you mean to say that the setting in the ini file can actually be over-ridden by MQ if it needs more log space ?
I would think it will throw errors / FDCs , or maybe even stop , rather than over-riding the setting in the ini files .. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 26, 2016 4:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mq_population wrote: |
So you mean to say that the setting in the ini file can actually be over-ridden by MQ if it needs more log space ?
I would think it will throw errors / FDCs , or maybe even stop , rather than over-riding the setting in the ini files .. |
No, what you will see is that transactions you thought were ok, may get rolled back because you are running out of "allocated" log space...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 26, 2016 5:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The important point is, whatever strategy you elect to size the logs, NEVER delete any manually because you've determined that the queue manager is not using them. Always wait for the queue manager to notice it doesn't need them, and remember that primary logs are always allocated even if they're not needed.
As to the point my worthy associate is making, you do need to be very careful during this exercise. Reducing the number of logs because you don't always need them will not help when you have that one transaction that is the reason so much log was defined originally.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mq_population |
| Posted: Tue Jul 26, 2016 5:46 am Post subject: |
|
|
Apprentice
Joined: 14 Jul 2009
Posts: 26
|
| Quote: |
What I would suggest is try it in 2 steps.
First keeping the global log space: i.e. 10 primaries and 35 secondaries.
Observe and see how many files are really being used over time. You have reduced the number of files that will always be allocated, but kept the global log space at the same level. If indeed it is not needed you can then reduce the number of secondaries...
Hi - The suggestion makes sense I will try that .
Thanks All for your suggestions ...
 |
|
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 27, 2016 4:00 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| The important point is, whatever strategy you elect to size the logs, NEVER delete any manually because you've determined that the queue manager is not using them. |
If any of the circular log files are deleted, the queue manager will fail to start. From there you can 1) restore the missing log file(s), 2) create a temp qmgr with same log sizing and copy them in (this is documented somewhere  ), 3) recreate the qmgr from scratch.
_________________
Glenn |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 27, 2016 4:06 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
If you are seeing secondary log files come into use, the sizing / number of primary log files may not be sufficient for app message processing needs. It may also indicate badly behaved apps, such as unnecessary long running units of work. In the error logs, are there any UOW's being backed out?
On a busy production qmgr its not unusual to have 10's - 100's GB allocated to 100's of circular primary logs.
_________________
Glenn |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jul 27, 2016 4:09 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
If you are seeing secondary log files come into use, the sizing / number of primary log files may not be sufficient for app message processing needs. It may also indicate badly behaved apps, such as unnecessary long running units of work. In the error logs, are there any UOW's being backed out?
On a busy production qmgr its not unusual to have 10's - 100's GB allocated to 100's of circular primary logs.
_________________
Glenn |
|
| Back to top |
|
|
| Andyh |
| Posted: Wed Jul 27, 2016 11:29 pm Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
It may not be "unusual" to have multi-gigabyte circular logs, but it should be avoided wherever possible.
If you have a 100GB circular log, you are accepting that your longest running transaction might be active throughout the time taken to write to the entire log. One implication of this is that a queue manager crash restart could (hypothetically) need to read the entire 100GB of log data, an action that could take quite some time (during which the queue manager would be unavailable to applications).
I appreciate it's easy for me to say, and much harder for you to do, but when a log space issue is discovered it is far preferable to identify why there are long running transactions and to reduce the duration of those transactions than to increase the size of the active log to these kinds on sizes.
More recent MQ releases make it much easier to identify these transactions, for example the UOWLOGTI/UOWLOGDA fields on runmqsc DIS CONN output and the dspmqtrn command with the -a option. |
|
| Back to top |
|
|
|
|
