IDS Forum

Re: New RFE entry needs votes

Posted By: Fernando Nunes
Date: Thursday, 11 January 2018, at 3:37 a.m.

In Response To: RE: New RFE entry needs votes (John Miller)

Trying to argue with two "monsters" (rest assured this is a compliment) is
really a bold move. Please take this as food for thought, and not exactly
as an educated opinion:

Although the message misses some "newline" changes, and I didn't get the
direct reply from Madison, I believe what he's suggesting is that the
suggestion I made on the other RFE (group commit) would be a better
solution.
I was totally convinced about that, but a recent discussion with a person
that was somehow involved with DB2 development (and mentioned that group
commit caused issues...) raised some doubts.

Apart from this, and considering Madison's points are very relevant (and
didn't came to my mind innitially) I wonder if just increasing the number
of buffers wouldn't help.
Taking is example of flushing buffer "5" and how that would require
previous flushes of buffers 1-4, we should not forget that it's the current
situation we have with buffer "2" and "1", with the (big?) difference that
currently we get into this as soon as we trigger a flush on buffer 3. So we
only have one buffer before we get into the situation. With the considered
scenario we would allow applications to "fill/flush" buffers 6-10 before
getting into the issue. I wonder if that wouldn't help....
I do recall an ancient ATLAS case where from the description, a patch was
created for an European customer to add more "HDR" buffers. And apparently
that helped. It's not the same situation, but I wonder if the effect
wouldn't be the same.
But I guess that the folks from HCL reading this may consider that.... as
long as there is a stress test, it shouldn't be too difficult to try...

As to John's statement that "if it was easy, it would have been done
before"... That causes me some "issues". I have a list of things that sound
"easy" and were never implemented. I have two explanations for this:

1- My concept of "easy" doesn't always match reality. So good feedback like
the one provided by Madison helps us, ignorant folks to understand why
sometimes things are not that simple. And that feedback should be provided
through the RFE system/process

2- Many times there's a huge gap between customer requirements and what's
important for them, and the development priorities. This happens for a few
reasons: The user's voice is not loud enough (and that's mainly their
fault, but there's also a communication channel issue...). Development most
of the times is concerned with what big customers want, and with what may
gain us a new customer. I'm not criticizing this, but it has its
disadvantages.

3- Many times, people that deal with big customers (mainly in the USA) have
a privilege access to the development teams and managers, and they
sometimes manage to use some "workarounds" that are "good enough".
This is an obscure point, and a very personal "complaint" but let me
illustrate with an example: What's the use for the common user of the
"onstat -g pqs"? However for internal people the information may be very
relevant.

Regards.

On Thu, Jan 11, 2018 at 7:31 AM, John Miller <jmiller@jfmiii.com> wrote:

> =0AI would agree with my esteemed learned colleague. Increasing the=0Anumb=
> er of log buffers will not help performance at all. If it would
> have=0Athis=
> would be an easy change which would have been done long ago. There=0Aare m=
> any =0Aissues in dealing with the log buffer and Madison bring up one, but=
> =0Athere =0Aare several more.=0A=0A=0AJohn=0A=0A-------- Original Message
> -=
> -------=0ASubject: Re: New RFE entry needs votes [40481]=0AFrom: "Madison
> P=
> ruet" <madison_pruet@yahoo.com>=0ADate: Wed, January 10, 2018 10:09
> pm=0ATo=
> : ids@iiug.org=0A=0AIve been doing some thinking about this and would
> like =
> to make some =0Asuggestions. You can take it for what its worth. =0AIts
> bes=
> t to make a request for change to describe a problem and not so=0Amuch a =
> =0Asolution. I dont think that just having more log buffers will
> resolve=0A=
> any =0Aproblem because the order that any buffer can be reused is
> dependent=
> on=0Athe =0Apreceding buffers being reusable. To explain - suppose that yo=
> u had 10=0Abuffers =0Aand commit log records had been placed in all 10.
> Sin=
> ce the commit log=0Arecord =0Awould have started the log flush of all 10
> lo=
> g buffers, then there would=0Abe no =0Afree log buffers available for any
> s=
> ubsequent log records. This would be=0A=0Aidentical to the situation that
> w=
> e have today. =0AAlso lets suppose that log buffer 5 completed the log
> flus=
> h. Fine, but=0Athe =0Athreads which were attached to log buffer 5 could
> sti=
> ll not complete the=0A=0Acommit until log buffers 1-4 were complete. Why?
> B=
> ecause the=0Atransactions =0Aissueing the commit in log buffer 5 could
> have=
> log records in buffers=0A1-4. If =0Athe system were to be restarted before=
> all of the log buffers 1-5 were=0Afully =0Aflushed, then you would lose th=
> e transaction having the commit log=0Arecord in =0Abuffer 5 and that would
> =
> break the ACID rules of transactions. =0AAlso, if there are a large number
> =
> of log buffers and there is no control=0Aof =0Athe IO execution, then all
> t=
> hat youve done is to increase the IO=0Acontention on =0Athe log files, and
> =
> that would decrease performance. =0ASo the solution is probably not so
> much=
> just increasing the number of=0Alog =0Abuffers, but rather increasing the =
> number of commits per log buffer=0Awhile =0Astill maintaining good
> performa=
> nce and functioning similar to unbuffered=0A=0Alogging. Perhaps not
> allowin=
> g the start of IO on buffer 2 until buffer 1=0Ais =0Acompletely flushed
> AND=
> allowing additional log records to be placed into=0A=0Abuffer 2 until the =
> IO completion of log buffer 1. Yes - those=0Atransactions =0Athat placed a
> =
> commit log record into buffer 2 would have to be suspended=0Auntil =0Athe
> I=
> O completion of the IO on buffer 2 AND the IO would not be=0Ainitiated
> =0Au=
> ntil the completion of the IO on log buffer 1. =0AI dont know the
> solution.=
> I no longer have access to the source code to =0Aexperiment on a good solu=
> tion to the problem. But again, Im not sure=0Athat the =0Aproblem is
> stated=
> in the RFE either. =0A=0ASent from Yahoo Mail for iPad =0A=0AOn Sunday, Ja=
> nuary 7, 2018, 1:00 PM, Art Kagel <art.kagel@gmail.com>=0Awrote:
> =0A=0AFOlk=
> s: =0A=0AI submitted the following RFE to the IBM RFE Community site. If
> yo=
> u have=0Aan =0Ainterest in this feature/enhancement, please add your vote:
> =
> =0A=0A------------------------------------------------------------
> =0A-----=
> --------------------------------------------------------- =0ANotification
> g=
> enerated at: 07 Jan 2018, 02:57 PM Eastern Time (ET) =0A=0AID: 114905
> =0AHe=
> adline: Need the ability to increase =0Athe number of logical log buffers
> f=
> rom 3 to handle peak transaction=0Aloads =0ASubmitted on: 07 Jan 2018,
> 02:5=
> 7 PM Eastern Time =0A(ET) =0ABrand: Analytics Platform =0AProduct:
> Informix=
> Servers =0AComponent: Product functionality =0A=0ALink: http://www.ibm.com
> =
> / =0Adeveloperworks/rfe/execute?use_case=3DviewRfe&CR_ID=3D114905
> =0A------=
> ------------------------------------------------------
> =0A-----------------=
> --------------------------------------------- =0A=0AArt =0A=0AArt S.
> Kagel,=
> President and Principal Consultant =0AASK Database Management =0Awww.askdb=
> mgt.com =0A=0ABlog: http://informix-myview.blogspot.com/
> =0A=0ADisclaimer: =
> Please keep in mind that my own opinions are my own opinions=0A=0Aand do
> no=
> t reflect on the IIUG, nor any other organization with which I=0Aam
> =0Aasso=
> ciated either explicitly, implicitly, or by inference. Neither do =0Athose
> =
> opinions reflect those of other individuals affiliated with any =0Aentity
> w=
> ith which I am affiliated nor those of the entities themselves.
> =0A=0A=0A**=
> ************************************************************
> ***************=
> **=0A=0AForum Note: Use "Reply" to post a response in the discussion
> forum.=
> =0A=0A=0A***************************************************
> **************=
> **************=0A=0A Forum Note: Use "Reply" to post a response in the
> disc=
> ussion forum.
>
>
> ************************************************************
> *******************
> 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...

Messages In This Thread

• New RFE entry needs votes
  Art Kagel -- Sunday, 7 January 2018, at 3:00 p.m.
  • Re: New RFE entry needs votes
    BENJAMIN THOMPSON -- Tuesday, 9 January 2018, at 7:04 a.m.
    • Re: New RFE entry needs votes
      Fernando Nunes -- Tuesday, 9 January 2018, at 8:23 a.m.
      • Re: New RFE entry needs votes
        david@smooth1.co.uk -- Wednesday, 10 January 2018, at 2:49 a.m.
      • Re: New RFE entry needs votes
        BENJAMIN THOMPSON -- Wednesday, 10 January 2018, at 11:00 a.m.
  • Re: New RFE entry needs votes
    Madison Pruet -- Thursday, 11 January 2018, at 1:09 a.m.
    • RE: New RFE entry needs votes
      John Miller -- Thursday, 11 January 2018, at 1:31 a.m.
      • Re: New RFE entry needs votes
        Fernando Nunes -- Thursday, 11 January 2018, at 3:37 a.m.
        • Re: New RFE entry needs votes
          Madison Pruet -- Thursday, 11 January 2018, at 6:31 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.