ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Reason for Secondary Log Files

Post new topic  Reply to topic Goto page Previous  1, 2
 Reason for Secondary Log Files « View previous topic :: View next topic » 
Author Message
exerk
PostPosted: Tue Jan 29, 2013 5:17 am    Post subject: Reply with quote

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
View user's profile Send private message
mvic
PostPosted: Tue Jan 29, 2013 5:48 am    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Tue Jan 29, 2013 7:48 am    Post subject: Reply with quote

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
View user's profile Send private message
PeterPotkay
PostPosted: Tue Jan 29, 2013 5:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue Jan 29, 2013 8:19 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Wed Jan 30, 2013 8:04 am    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Wed Jan 30, 2013 8:34 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Reason for Secondary Log Files
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.