|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
Reason for Secondary Log Files |
« View previous topic :: View next topic » |
Author |
Message
|
exerk |
Posted: Tue Jan 29, 2013 5:17 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
mqjeff wrote: |
exerk wrote: |
mqjeff wrote: |
So, again, why make them all primaries? |
Because analysis and sizing is done using the information provided by the system architects or applications people, and we all know that:
a. System architects generally can't tell their posterior from their elbow and give you the wrong figures at the outset;
b. Developers are lying offspring of a she-dog and don't dare give you the real figures because it'll impact delivery and budget (which organisation do you know that gets Middleware people engaged at project definition time and doesn't consider us to be little more than an extension of Cat5e cable?); or
c. Both of the above.
* I don't really hate system architects and developers - they'll be keeping me in a job for years to come! |
Again, how does making them all primaries help that situation, versus using some secondaries? |
Because If I'm going to allocate space because I don't trust their figures I'm most probably going to define the largest logs possible, and the maximum number possible, rather than allocate the space to allow for growth to maxlogs-of-maxsize but only use a percentage of it and then have to increase the number of logs later - lazy I know, but also (in a way) less maangement. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
mvic |
Posted: Tue Jan 29, 2013 5:48 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
SAFraser wrote: |
... the time it takes to read the logs at startup. |
Remember that automatic checkpoints help to restrict this to a sensible amount, even when you have a "large" log size.
"When WebSphere MQ restarts, it finds the latest checkpoint record in the log." ... "The checkpoint record represents the most recent point of consistency between the log and the data. All the operations that have taken place since the checkpoint are replayed forward."
( From http://publib.boulder.ibm.com/infocenter/wmqv7/v7r1/topic/com.ibm.mq.doc/fa14540_.htm ) |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Jan 29, 2013 7:48 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9475 Location: US: west coast, almost. Otherwise, enroute.
|
WMQ posts an amq..... message when it allocates a secondary log. This might be your only silent indicator that your primaries are nearing their max limit.
One of my clients created an automation task that notifies their admin when secondaries are created. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jan 29, 2013 5:11 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
mqjeff wrote: |
The flip side is this.
You do your analysis, and you determine you need 2TB of log space. You've determined that you will never use more than 1.5TB of total log space, but you allocate 2TB for diskspace "just in case". You then allocate it all to primary logs, and absolutely none to secondary, because magically the product now allows you to specify zero secondary log files.
What value does that give you over having 1.5TB of primary and .5TB of secondary?
Using it all as primary saves you the time needed to allocate secondaries. But you've already determined you're never going to use those secondaries at all, even in really unexpected situations.
So, again, why make them all primaries? |
In this case the secondaries are completely useless. They'll never be used. There's no need for them.
If I have determined I need X GB of logs, and I can provide X GB of disk space for logs, why does MQ allow me to allocate X GB of primary logs, but then forces us to allocate at least one additional secondary? There must be some internal reason, maybe no longer valid in current versions of MQ, that acted as an internal 'safety buffer', allowing your primaries to fill, allowing MQ time to roll back that transaction, and during this I'm-Full-I'm-Rolling-Back mode it relies on that secondary? Just guessing.
Inquiring minds want to know... _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Jan 29, 2013 8:19 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20763 Location: LI,NY
|
Think about practical file size management.
Having secondaries defined allows you to see when they are getting used and take it as an incentive on reviewing the size of your qmgr's log files and the number of it. I.e. due to new traffic you may be using up all your log space and need more...
You'd never realize this until you get the log full message in the errorlog if you only use primaries...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Jan 30, 2013 8:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
PeterPotkay wrote: |
mqjeff wrote: |
The flip side is this.
You do your analysis, and you determine you need 2TB of log space. You've determined that you will never use more than 1.5TB of total log space, but you allocate 2TB for diskspace "just in case". You then allocate it all to primary logs, and absolutely none to secondary, because magically the product now allows you to specify zero secondary log files.
What value does that give you over having 1.5TB of primary and .5TB of secondary?
Using it all as primary saves you the time needed to allocate secondaries. But you've already determined you're never going to use those secondaries at all, even in really unexpected situations.
So, again, why make them all primaries? |
In this case the secondaries are completely useless. They'll never be used. There's no need for them. |
My point is that there's likewise no reason to allocate primaries, either.
So given that the decision is made to allocate *any* log files at all, what reasons are there to make those logs PRIMARY or SECONDARY?
My hunch is that it comes down to personal preference on the part of the admin creating the queue manager. But it's been a long time since I've been personally and directly responsible for the health of a specific queue manager. So I'm curious from those who are doing that every day, as to what informs those personal preferences.
Exerk says "I like primaries because they don't take any extra time to allocate when needed".
My response to that is - well, yes, but if the sizing team has lied and these files do get used, then shouldn't it cause them to take a hit in performance, at least temporarily, when they go over it? Otherwise, their failure goes unnoticed and can not be reasonably addressed or fed back to them to update their estimation process. |
|
Back to top |
|
 |
exerk |
Posted: Wed Jan 30, 2013 8:34 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
mqjeff wrote: |
PeterPotkay wrote: |
mqjeff wrote: |
The flip side is this.
You do your analysis, and you determine you need 2TB of log space. You've determined that you will never use more than 1.5TB of total log space, but you allocate 2TB for diskspace "just in case". You then allocate it all to primary logs, and absolutely none to secondary, because magically the product now allows you to specify zero secondary log files.
What value does that give you over having 1.5TB of primary and .5TB of secondary?
Using it all as primary saves you the time needed to allocate secondaries. But you've already determined you're never going to use those secondaries at all, even in really unexpected situations.
So, again, why make them all primaries? |
In this case the secondaries are completely useless. They'll never be used. There's no need for them. |
My point is that there's likewise no reason to allocate primaries, either.
So given that the decision is made to allocate *any* log files at all, what reasons are there to make those logs PRIMARY or SECONDARY?
My hunch is that it comes down to personal preference on the part of the admin creating the queue manager. But it's been a long time since I've been personally and directly responsible for the health of a specific queue manager. So I'm curious from those who are doing that every day, as to what informs those personal preferences.
Exerk says "I like primaries because they don't take any extra time to allocate when needed".
My response to that is - well, yes, but if the sizing team has lied and these files do get used, then shouldn't it cause them to take a hit in performance, at least temporarily, when they go over it? Otherwise, their failure goes unnoticed and can not be reasonably addressed or fed back to them to update their estimation process. |
If I don't get any figures (the norm) then I make clear that the only reasonable option to try and ensure no or minimal impact is to size the logs to the largest possible size and use the maximum number of logs that can be allocated - primary and secondary; I also point out that if there are problems due to logging, such that no more can be defined (circular) that the only option is to go linear. If it gets to that point in the discussion I really talk up the issues with management and archiving (I always push it back on the 'data' owners as copies of messages are in the logs, therefore the 'data' belongs to them) and any other horror story I can think of at the time - a good one for any Windows-based solution is usually along the lines of "...sorry mate, you're on the wrong platform if we use circular logging and you need to increase the number of logs past what we can allocate - we can re-platform on Unix though as we can allocate a greater number of logs on that, but it'll cost you, or we delete and redefine your queue manager with linear logs...". A few crocodile tears etc., and then wait for more accurate figures that never arrive. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|