What log size is too large?

We have a system with logs sized at 200MB. We are rolling through 6 or more of those every hour. We are considering go to 500MB. Does anyone have logs that large out there? -- Will chat again soon, Kate katedarts@gmail.com --001a114b10f4b1d3e20540e50899

Kate, Smaller logs give you better recoverability, larger logs are better performance. My recommendation for OLTP systems is to setup a logs so you are going through one log every 5 to 10 minutes, which it sounds about like what you have , so if you lost your system and the current log, you could recover from a log backup about 5 to 10 minutes ago. If you don't need to worry about recoverability, then the bigger logs will be faster and I have use 500MB logs. Regards - Lester On 11/9/16 4:35 PM, Kate Tomchik wrote: > We have a system with logs sized at 200MB. We are rolling through 6 or > more of those every hour. We are considering go to 500MB. Does anyone > have logs that large out there? > -- ______________________________________________________________________ Lester Knutsen lester@advancedatatools.com Advanced DataTools Corporation Voice: 703-256-0267 x102 Visit our Web page: http://www.advancedatatools.com ______________________________________________________________________

Kate: The answer to your question is the answer to this question: How much data are you willing to lose or have to recreate from other sources if the system crashes hard one log page short of completing a logical log file and backing it up and the drives are completely unrecoverable (say a bomb takes out your data center)? That's the largest log you want to have. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Nov 9, 2016 at 4:35 PM, Kate Tomchik <katedarts@gmail.com> wrote: > We have a system with logs sized at 200MB. We are rolling through 6 or > more of those every hour. We are considering go to 500MB. Does anyone > have logs that large out there? > > -- > Will chat again soon, > Kate > katedarts@gmail.com > > --001a114b10f4b1d3e20540e50899 > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a114b7e0cc3bb6c0540e5f447

I totally agree with Art's answer and I don't understand how bigger logs will give you better performance apart that if you change logs very quickly the overhead of onbar handshake with the storage manager may become an issue. But this would be a thing to consider if you chnage logs every few seconds... Also note that the discussion about "how long can you afford to loose" is not an easy discussion within customers. The natural answer is "nothing" which can't be done unless you have a replica and that replica is synchronous. And in reality I've never faced a situation where "a bomb hit the datacenter completely destroying the machine". And also not that in that catastrofic situation, a local replica would not be very useful... and a remote synchronous replica could have serious performance implications. I guess that what I'm trying to say is that there will always be margin for data loss... unless you're willing to pay a very costly price for something that really would never happen, and honestly, if it ever happened people would have a lot more to be concerned with. So... the discussion is not easy. But normally people accept a very reduced risk for a couple of minutes. Actually I'll have a discussion like this tomorrow... so I think I'm preparing myself for it ;) Regards On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen <lester@advancedatatools.com> wrote: > Kate, > > Smaller logs give you better recoverability, larger logs are better > performance. My recommendation for OLTP systems is to setup a logs so you > are > going through one log every 5 to 10 minutes, which it sounds about like > what > you have , so if you lost your system and the current log, you could > recover > from a log backup about 5 to 10 minutes ago. If you don't need to worry > about > recoverability, then the bigger logs will be faster and I have use 500MB > logs. > > Regards - Lester > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > We have a system with logs sized at 200MB. We are rolling through 6 or > > more of those every hour. We are considering go to 500MB. Does anyone > > have logs that large out there? > > > > -- > ______________________________________________________________________ > Lester Knutsen lester@advancedatatools.com > Advanced DataTools Corporation Voice: 703-256-0267 x102 > Visit our Web page: http://www.advancedatatools.com > ______________________________________________________________________ > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a11446e8629eb800540f04396

Just to add up... at least one of our competitors can do something interesting.... they can create a "replica" which doesn't have data, but works to receive the logical logs. It's a relatively easy way to have a remote copy of the logs which can be used for recover of a catastrophic situation on the primary site. It would be a bit like if we setup a secondary server, without dbspaces and with "STOP_APPLY" active. the logs would be cached on a directory... this would be a nice RFE if someone feels the need. Regards. On Thu, Nov 10, 2016 at 10:59 AM, Fernando Nunes <domusonline@gmail.com> wrote: > I totally agree with Art's answer and I don't understand how bigger logs > will give you better performance apart that if you change logs very quickly > the overhead of onbar handshake with the storage manager may become an > issue. But this would be a thing to consider if you chnage logs every few > seconds... > > Also note that the discussion about "how long can you afford to loose" is > not an easy discussion within customers. The natural answer is "nothing" > which can't be done unless you have a replica and that replica is > synchronous. And in reality I've never faced a situation where "a bomb hit > the datacenter completely destroying the machine". And also not that in > that catastrofic situation, a local replica would not be very useful... and > a remote synchronous replica could have serious performance implications. > > I guess that what I'm trying to say is that there will always be margin for > data loss... unless you're willing to pay a very costly price for something > that really would never happen, and honestly, if it ever happened people > would have a lot more to be concerned with. So... the discussion is not > easy. But normally people accept a very reduced risk for a couple of > minutes. Actually I'll have a discussion like this tomorrow... so I think > I'm preparing myself for it ;) > > Regards > > On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen < > lester@advancedatatools.com> > wrote: > > > Kate, > > > > Smaller logs give you better recoverability, larger logs are better > > performance. My recommendation for OLTP systems is to setup a logs so you > > are > > going through one log every 5 to 10 minutes, which it sounds about like > > what > > you have , so if you lost your system and the current log, you could > > recover > > from a log backup about 5 to 10 minutes ago. If you don't need to worry > > about > > recoverability, then the bigger logs will be faster and I have use 500MB > > logs. > > > > Regards - Lester > > > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > > We have a system with logs sized at 200MB. We are rolling through 6 or > > > more of those every hour. We are considering go to 500MB. Does anyone > > > have logs that large out there? > > > > > > > -- > > ______________________________________________________________________ > > Lester Knutsen lester@advancedatatools.com > > Advanced DataTools Corporation Voice: 703-256-0267 x102 > > Visit our Web page: http://www.advancedatatools.com > > ______________________________________________________________________ > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > --001a11446e8629eb800540f04396 > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --001a113fbb5ac398f10540f05521

Fernando I have to take issue with your statement " and a remote synchronous replica could have serious performance implications.". Surely this is for which HDR is designed ? I have a 1.5 Tb database (IDS 9.4 on AIX 6.1) (no over-large I know, but sufficient OLTP transactions to prove the point) running synchronous HDR over a 3rd party WAN infrastructure between 2 sites some 100 miles apart. I'm also running Synchronous ER to a local server and another server, on a different WAN to a 3rd location, again about 100 miles away. I see no impact on the OLTP application, HDR is so quick to update I cannot ever find anything out of step and ER only gets delayed on large transactions due to the target servers being of significantly lower specs and needing slightly longer to apply, even so they catch up within minutes. Keith On 10 November 2016 at 10:59, Fernando Nunes <domusonline@gmail.com> wrote: > I totally agree with Art's answer and I don't understand how bigger logs > will give you better performance apart that if you change logs very quickly > the overhead of onbar handshake with the storage manager may become an > issue. But this would be a thing to consider if you chnage logs every few > seconds... > > Also note that the discussion about "how long can you afford to loose" is > not an easy discussion within customers. The natural answer is "nothing" > which can't be done unless you have a replica and that replica is > synchronous. And in reality I've never faced a situation where "a bomb hit > the datacenter completely destroying the machine". And also not that in > that catastrofic situation, a local replica would not be very useful... and > a remote synchronous replica could have serious performance implications. > > I guess that what I'm trying to say is that there will always be margin for > data loss... unless you're willing to pay a very costly price for something > that really would never happen, and honestly, if it ever happened people > would have a lot more to be concerned with. So... the discussion is not > easy. But normally people accept a very reduced risk for a couple of > minutes. Actually I'll have a discussion like this tomorrow... so I think > I'm preparing myself for it ;) > > Regards > > On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen < > lester@advancedatatools.com> > wrote: > > > Kate, > > > > Smaller logs give you better recoverability, larger logs are better > > performance. My recommendation for OLTP systems is to setup a logs so you > > are > > going through one log every 5 to 10 minutes, which it sounds about like > > what > > you have , so if you lost your system and the current log, you could > > recover > > from a log backup about 5 to 10 minutes ago. If you don't need to worry > > about > > recoverability, then the bigger logs will be faster and I have use 500MB > > logs. > > > > Regards - Lester > > > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > > We have a system with logs sized at 200MB. We are rolling through 6 or > > > more of those every hour. We are considering go to 500MB. Does anyone > > > have logs that large out there? > > > > > > > -- > > ______________________________________________________________________ > > Lester Knutsen lester@advancedatatools.com > > Advanced DataTools Corporation Voice: 703-256-0267 x102 > > Visit our Web page: http://www.advancedatatools.com > > ______________________________________________________________________ > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > --001a11446e8629eb800540f04396 > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11469f6a15cfc70540f08be7

Fernando: Whenever I set up an alarmprogram to backup the logical logs to disk (so not using a storage manager) I also copy the log back up file to another machine for immediate safety. Often that's the HDR secondary's machine but some clients prefer that the remote copy go elsewhere. If you are using onbar and a storage manager for log backups, that is the same thing, just more formalized. Either way this is essentially the kind of log only replica you are talking about. So we can do it with Informix too. It's just so obvious that like many things that the "other guy" thinks are cool features, we just do and don't talk about. Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Thu, Nov 10, 2016 at 6:04 AM, Fernando Nunes <domusonline@gmail.com> wrote: > Just to add up... at least one of our competitors can do something > interesting.... they can create a "replica" which doesn't have data, but > works to receive the logical logs. > It's a relatively easy way to have a remote copy of the logs which can be > used for recover of a catastrophic situation on the primary site. > It would be a bit like if we setup a secondary server, without dbspaces and > with "STOP_APPLY" active. the logs would be cached on a directory... this > would be a nice RFE if someone feels the need. > > Regards. > > On Thu, Nov 10, 2016 at 10:59 AM, Fernando Nunes <domusonline@gmail.com> > wrote: > > > I totally agree with Art's answer and I don't understand how bigger logs > > will give you better performance apart that if you change logs very > quickly > > the overhead of onbar handshake with the storage manager may become an > > issue. But this would be a thing to consider if you chnage logs every few > > seconds... > > > > Also note that the discussion about "how long can you afford to loose" is > > not an easy discussion within customers. The natural answer is "nothing" > > which can't be done unless you have a replica and that replica is > > synchronous. And in reality I've never faced a situation where "a bomb > hit > > the datacenter completely destroying the machine". And also not that in > > that catastrofic situation, a local replica would not be very useful... > and > > a remote synchronous replica could have serious performance implications. > > > > I guess that what I'm trying to say is that there will always be margin > for > > data loss... unless you're willing to pay a very costly price for > something > > that really would never happen, and honestly, if it ever happened people > > would have a lot more to be concerned with. So... the discussion is not > > easy. But normally people accept a very reduced risk for a couple of > > minutes. Actually I'll have a discussion like this tomorrow... so I think > > I'm preparing myself for it ;) > > > > Regards > > > > On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen < > > lester@advancedatatools.com> > > wrote: > > > > > Kate, > > > > > > Smaller logs give you better recoverability, larger logs are better > > > performance. My recommendation for OLTP systems is to setup a logs so > you > > > are > > > going through one log every 5 to 10 minutes, which it sounds about like > > > what > > > you have , so if you lost your system and the current log, you could > > > recover > > > from a log backup about 5 to 10 minutes ago. If you don't need to worry > > > about > > > recoverability, then the bigger logs will be faster and I have use > 500MB > > > logs. > > > > > > Regards - Lester > > > > > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > > > We have a system with logs sized at 200MB. We are rolling through 6 > or > > > > more of those every hour. We are considering go to 500MB. Does anyone > > > > have logs that large out there? > > > > > > > > > > -- > > > ______________________________________________________________________ > > > Lester Knutsen lester@advancedatatools.com > > > Advanced DataTools Corporation Voice: 703-256-0267 x102 > > > Visit our Web page: http://www.advancedatatools.com > > > ______________________________________________________________________ > > > > > > > > > ************************************************************ > > > ******************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > -- > > Fernando Nunes > > Portugal > > > > http://informix-technology.blogspot.com > > My email works... but I don't check it frequently... > > > > --001a11446e8629eb800540f04396 > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... > > --001a113fbb5ac398f10540f05521 > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --bcaec508f4bceb75250540f0b73b

Appreciated... There's nothing better than a customer stating that "we use this and it works great" :) I may have been too cautious in my statement. And this could easily lead to previous discussions about the log flush methods... in some very high rate OLTP systems you can see some delays in the form of "G" flags in onstat -u. And when this happens your primary sessions will have to wait for a free logical log buffer. Recent versions (12.10) introduced some improvements. but that's somehow a natural consequence of doing more stuff, and the fact that some of that stuff is remote and we can't really work around the light speed. As an example, some local customers have remote sites on the second largest city in the country which is located 300Km from the main site. Just the lightspeed will require around 2ms of round-trip (add something else for equipment delay)... If you don't feel that pain that's great, and by no means I was saying we didn't do a good job... we do. But besides the improvements in recent versions we could also improve it by implementing what others call "group commit" which basically delays the "commit answer" to the application so that we can reduce the disk flush (and consequently the number of times we send a package to secondary servers). The issues here are usually the round-trip as opposed to the bandwidth. Thanks for the feedback. On Thu, Nov 10, 2016 at 11:19 AM, Keith Simmons <smiley73@gmail.com> wrote: > Fernando > > I have to take issue with your statement " and a remote synchronous replica > could have serious performance implications.". > > Surely this is for which HDR is designed ? > I have a 1.5 Tb database (IDS 9.4 on AIX 6.1) (no over-large I know, but > sufficient OLTP transactions to prove the point) running synchronous HDR > over a 3rd party WAN infrastructure between 2 sites some 100 miles apart. > I'm also running Synchronous ER to a local server and another server, on a > different WAN to a 3rd location, again about 100 miles away. > I see no impact on the OLTP application, HDR is so quick to update I cannot > ever find anything out of step and ER only gets delayed on large > transactions due to the target servers being of significantly lower specs > and needing slightly longer to apply, even so they catch up within minutes. > > Keith > > On 10 November 2016 at 10:59, Fernando Nunes <domusonline@gmail.com> > wrote: > > > I totally agree with Art's answer and I don't understand how bigger logs > > will give you better performance apart that if you change logs very > quickly > > the overhead of onbar handshake with the storage manager may become an > > issue. But this would be a thing to consider if you chnage logs every few > > seconds... > > > > Also note that the discussion about "how long can you afford to loose" is > > not an easy discussion within customers. The natural answer is "nothing" > > which can't be done unless you have a replica and that replica is > > synchronous. And in reality I've never faced a situation where "a bomb > hit > > the datacenter completely destroying the machine". And also not that in > > that catastrofic situation, a local replica would not be very useful... > and > > a remote synchronous replica could have serious performance implications. > > > > I guess that what I'm trying to say is that there will always be margin > for > > data loss... unless you're willing to pay a very costly price for > something > > that really would never happen, and honestly, if it ever happened people > > would have a lot more to be concerned with. So... the discussion is not > > easy. But normally people accept a very reduced risk for a couple of > > minutes. Actually I'll have a discussion like this tomorrow... so I think > > I'm preparing myself for it ;) > > > > Regards > > > > On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen < > > lester@advancedatatools.com> > > wrote: > > > > > Kate, > > > > > > Smaller logs give you better recoverability, larger logs are better > > > performance. My recommendation for OLTP systems is to setup a logs so > you > > > are > > > going through one log every 5 to 10 minutes, which it sounds about like > > > what > > > you have , so if you lost your system and the current log, you could > > > recover > > > from a log backup about 5 to 10 minutes ago. If you don't need to worry > > > about > > > recoverability, then the bigger logs will be faster and I have use > 500MB > > > logs. > > > > > > Regards - Lester > > > > > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > > > We have a system with logs sized at 200MB. We are rolling through 6 > or > > > > more of those every hour. We are considering go to 500MB. Does anyone > > > > have logs that large out there? > > > > > > > > > > -- > > > ______________________________________________________________________ > > > Lester Knutsen lester@advancedatatools.com > > > Advanced DataTools Corporation Voice: 703-256-0267 x102 > > > Visit our Web page: http://www.advancedatatools.com > > > ______________________________________________________________________ > > > > > > > > > ************************************************************ > > > ******************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > -- > > Fernando Nunes > > Portugal > > > > http://informix-technology.blogspot.com > > My email works... but I don't check it frequently... > > > > --001a11446e8629eb800540f04396 > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --001a11469f6a15cfc70540f08be7 > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --94eb2c0651e20077da0540f0c9fa

No Art. As you say you do it when you backup the log. That's in the "end of the log". What I'm taling about (and we do with HDR synchronous) it to replicate each transaction. We don't wait for the end of log. It's the difference between being able to recover on a logical log based unit, or on a transaction based unit. Completely different. Regards. On Thu, Nov 10, 2016 at 11:31 AM, Art Kagel <art.kagel@gmail.com> wrote: > Fernando: > > Whenever I set up an alarmprogram to backup the logical logs to disk (so > not using a storage manager) I also copy the log back up file to another > machine for immediate safety. Often that's the HDR secondary's machine but > some clients prefer that the remote copy go elsewhere. If you are using > onbar and a storage manager for log backups, that is the same thing, just > more formalized. Either way this is essentially the kind of log only > replica you are talking about. So we can do it with Informix too. It's just > so obvious that like many things that the "other guy" thinks are cool > features, we just do and don't talk about. > > Art > > Art S. Kagel, President and Principal Consultant > ASK Database Management > www.askdbmgt.com > > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on the IIUG, nor any other organization with which I am > associated either explicitly, implicitly, or by inference. Neither do > those opinions reflect those of other individuals affiliated with any > entity with which I am affiliated nor those of the entities themselves. > > On Thu, Nov 10, 2016 at 6:04 AM, Fernando Nunes <domusonline@gmail.com> > wrote: > > > Just to add up... at least one of our competitors can do something > > interesting.... they can create a "replica" which doesn't have data, but > > works to receive the logical logs. > > It's a relatively easy way to have a remote copy of the logs which can be > > used for recover of a catastrophic situation on the primary site. > > It would be a bit like if we setup a secondary server, without dbspaces > and > > with "STOP_APPLY" active. the logs would be cached on a directory... this > > would be a nice RFE if someone feels the need. > > > > Regards. > > > > On Thu, Nov 10, 2016 at 10:59 AM, Fernando Nunes <domusonline@gmail.com> > > wrote: > > > > > I totally agree with Art's answer and I don't understand how bigger > logs > > > will give you better performance apart that if you change logs very > > quickly > > > the overhead of onbar handshake with the storage manager may become an > > > issue. But this would be a thing to consider if you chnage logs every > few > > > seconds... > > > > > > Also note that the discussion about "how long can you afford to loose" > is > > > not an easy discussion within customers. The natural answer is > "nothing" > > > which can't be done unless you have a replica and that replica is > > > synchronous. And in reality I've never faced a situation where "a bomb > > hit > > > the datacenter completely destroying the machine". And also not that in > > > that catastrofic situation, a local replica would not be very useful... > > and > > > a remote synchronous replica could have serious performance > implications. > > > > > > I guess that what I'm trying to say is that there will always be margin > > for > > > data loss... unless you're willing to pay a very costly price for > > something > > > that really would never happen, and honestly, if it ever happened > people > > > would have a lot more to be concerned with. So... the discussion is not > > > easy. But normally people accept a very reduced risk for a couple of > > > minutes. Actually I'll have a discussion like this tomorrow... so I > think > > > I'm preparing myself for it ;) > > > > > > Regards > > > > > > On Wed, Nov 9, 2016 at 9:58 PM, Lester Knutsen < > > > lester@advancedatatools.com> > > > wrote: > > > > > > > Kate, > > > > > > > > Smaller logs give you better recoverability, larger logs are better > > > > performance. My recommendation for OLTP systems is to setup a logs so > > you > > > > are > > > > going through one log every 5 to 10 minutes, which it sounds about > like > > > > what > > > > you have , so if you lost your system and the current log, you could > > > > recover > > > > from a log backup about 5 to 10 minutes ago. If you don't need to > worry > > > > about > > > > recoverability, then the bigger logs will be faster and I have use > > 500MB > > > > logs. > > > > > > > > Regards - Lester > > > > > > > > On 11/9/16 4:35 PM, Kate Tomchik wrote: > > > > > We have a system with logs sized at 200MB. We are rolling through 6 > > or > > > > > more of those every hour. We are considering go to 500MB. Does > anyone > > > > > have logs that large out there? > > > > > > > > > > > > > -- > > > > ____________________________________________________________ > __________ > > > > Lester Knutsen lester@advancedatatools.com > > > > Advanced DataTools Corporation Voice: 703-256-0267 x102 > > > > Visit our Web page: http://www.advancedatatools.com > > > > ____________________________________________________________ > __________ > > > > > > > > > > > > ************************************************************ > > > > ******************* > > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > > > > > -- > > > Fernando Nunes > > > Portugal > > > > > > http://informix-technology.blogspot.com > > > My email works... but I don't check it frequently... > > > > > > --001a11446e8629eb800540f04396 > > > > > > > > > ************************************************************ > > > ******************* > > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > > > > > -- > > Fernando Nunes > > Portugal > > > > http://informix-technology.blogspot.com > > My email works... but I don't check it frequently... > > > > --001a113fbb5ac398f10540f05521 > > > > > > ************************************************************ > > ******************* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > > --bcaec508f4bceb75250540f0b73b > > > ************************************************************ > ******************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently... --94eb2c0651e27c9c1a0540f0d3a5

Back in the day, I would tell clients that for ER larger is better, but that was long ago. I don't believe that matters now but someone can chime in if needed. But students would ask what the recommendation was, and we'd saying "medium number of logs of medium size", we'd laugh and then start the detailed discussions around log switches, what you can afford to lose, etc... I have a client with 2TB engine, and 200MB logs. Obscene number of logs to babysit Golden Gate, so I won't even mention that number. What I see typically is: ------------------------------------- Logical Log Usage Summary ------------------------------------- Logical Logs used 11/11/16: 67 Daily Average This Month: 118.047 High Day: 433 01/01/16 Low Day : 21 01/29/16 ------------------------------------- MONTH END SUMMARY ------------------------------------- (4 days measured) 419 11/01/16 110 11/02/16 119 11/03/16 102 11/04/16 TOTAL ME LOGS = 750 AVERAGE ME LOGS = 187.5 ** ME = month-end A question I've always had for the group ... the "Performance Advisories" we see in the msg log - do you follow them or feel they're accurate? Over the years as this client has grown, phys log and logical log advisories come around every so often (logical log msgs mostly now), ie: "logical log size not large enough to complete checkpoint" (or similar). Your take? Thanks - Mark Scranton