| Author |
Message
|
| rammer |
 Posted: Sun Jan 27, 2013 11:02 am Post subject: Reason for Secondary Log Files |
 |
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Ive got a question that has puzzled me for a while. What is the point of Secondary Logs? From what I read and see Secondary Logs are used only if required however why not just add more Prmiary in the first instance?
My scenario is I have 180 Primary log files set at 65535 and 10 Secondary at the same pagefile. The logs are stored on the SAN in a allocation of 50Gig.
Why not just have 190 Primary as in essence its the same amount that will be used.
I know there must be some logical answer to secondary's but I just can not think of it at the moment. So what is the real reason for needing these dynamic logs?
Thanks |
|
| Back to top |
|
 |
| SAFraser |
| Posted: Sun Jan 27, 2013 12:33 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| Because they are dynamic. Primary files grab disk footprint when the queue manager is created. Secondary log files come and go as needed. I think of them as a safety net. |
|
| Back to top |
|
|
| rammer |
| Posted: Sun Jan 27, 2013 12:40 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
Hi SAFRaser I undrstand that they take footprint up , but if you set the logs up to use a dedicated filesystem with a set volume eg 50gig then it makes no point at all having dynamic ones as that space is already allocated to MQ logs, thus to me gives no safety net.
Still puzzles me! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2013 12:48 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Secondary logs are allocated, formatted and used. when all primaries contain active units of work.
However unlikely this might be, some application(s) might create units of work that span all primaries. This is where secondaries have value.
When no longer needed, secondaries are deleted. If secondaries are never allocated, you have lost nothing.
_________________
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: Sun Jan 27, 2013 4:03 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I think rammer's line of thinking is, if I must reserve say 3 GB of disk space for my secondary logs, why not just create extra primary logs to use up that 3 GB when you create the QM? The primaries will be made ahead of time and so you won't take the performance hit of waiting for the secondaries being allocated.
I've wondered the same thing myself...
I came to the conclusion that it allows for some bit of thin provisioning where if I plan for 3 GB of secondary logs, that 3 GB of disk space could be used for other reasons at other times. I'm not really happy with that answer, since you can't predict when you'll need the secondaries, so therefore you must always have the disk space reserved for them, which brings us back to why bother making 3 GB of secondaries if you have the disk space - just add 3 GB more of primaries.
In my mind the question is a good one and still remains open - why bother making x GB of secondary logs instead of just making that many more GB of primary logs to begin with?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 27, 2013 4:59 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
The bigger issue for me is: GET MORE DISK. IT'S CHEAP.
_________________
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: Sun Jan 27, 2013 5:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Done.
You have 2 TB for your logs.
Why have any secondaries?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ramires |
| Posted: Sun Jan 27, 2013 6:26 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jan 28, 2013 9:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Yes, I'm aware of that. The discussion is why is that requirement there? What benefit do 3 (for example) secondary logs have over just building the QM with 3 extra primary logs?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Andyh |
| Posted: Mon Jan 28, 2013 9:48 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
Why have you allocated 45GB of active log space in the first place ?
Having 45GB of log space could allow you to have a long running transaction, however have you considered how long it might take the queue manager to restart if there is up to 45GB of log space to replay ! |
|
| Back to top |
|
|
| ramires |
| Posted: Mon Jan 28, 2013 12:53 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| PeterPotkay wrote: |
| Yes, I'm aware of that. The discussion is why is that requirement there? What benefit do 3 (for example) secondary logs have over just building the QM with 3 extra primary logs? |
I though that. I see secondary logs as a buffer for unexpected load. Maybe there is an historical reason for that, not sure. VSAM files have extents, DB2 has secondary logs.
_________________
Obrigado / Thanks you |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 28, 2013 3:03 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
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? |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jan 29, 2013 2:29 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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!
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Jan 29, 2013 3:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| 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? |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Jan 29, 2013 4:26 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
I've always wondered about a few things. One, as mentioned earlier by another poster, is the time it takes to read the logs at startup. Another is whether there is a runtime performance hit if there are many logs to traverse. Finally, is management of white space (disk fragmentation) improved with just the right number and size of primary logs.
Many years ago, a level 2 guy gave me guidelines about how to size logs for good performance-- how to balance the page size and the number of logs according to the projected use pattern of the queue manager. Maybe I still have those notes someplace, I'll look.
This is an interesting discussion! |
|
| Back to top |
|
|
|
|
