Re: Mach11 questions

On Thu, Sep 9, 2010 at 5:29 PM, shorti <lbryan21@juno.com> wrote: > > And your question: "-How UPDATE commands are routed if coming through an > SDS > > node" made me think you understood that. > > > The updates are transparently sent to the primary node. Only the primary > > node will effectively write to the disk. > > The buffer on the secondary nodes has exactly the same role an in the > > primary. It's used for caching disk pages for speeding up access times > (just > > like in any RDBMS system) > > > Regards. > > > -- > > Fernando Nunes > > Portugal > > No..I was thinking of the topology where you have two nodes (primary > and SDS) where there is an application processes running on each that > wants to read/write to the database. If the reads on the SDS > retrieves data from its own bufferpool and updates were not allowed > (or so I thought at the time) I was wondering how updates were routed > because I assumed they had to go to the primary. Before V11.50 this > was done manually but the user some how? > > Now, you state that UPDATEs are allowed on the SDS but are actually > rerouted through the Primary, so it must really be the same as before > except there is some sort of automatic rerouting. > Before UPDATABLE_SECONDARY the application code would have to explicitly reference the primary server: INSERT INTO database@primary_informix_server:table (....) VALUES (...)as oposite to INSERT INTO table (....) VALUES (...). It had to be done as any other distributed query in Informix (a query where you reference an external engine) > One thing that is confusing with this reroute to the primary is one of > the slides stated the following: > > "Uses optimistic concurrency to avoid updating a stale copy of the > row" > "If it is determined that the before image on the secondary is > different than the current image on the primary, then the write > operation is not allowed and an EVERCONFLICT (-7350) error is > returned" > > This leads me to believe that updates are not just rerouted to the > primary...its saying there is a possibility of a "stale" copy on the > SDS. If the update is merely rerouted to the primary for the update > wouldnt it just look like any other update to a server where if > another process/thread is updating the row, the update request > coming from the SDS would just have wait until that update finishes? > An update requires the server to locate the row(s). This is done on the secondary. After that it asks the primary to write the new value(s). When the primary gets this requests it has to read the data from disk (direct access since it will not need a query plan) or eventually use the row image already in it's cache. Since there is a possibilty that the SDS didn't keep up with the LSN sent by the primary (there is a parameter to limit this - if exceed the SDS will be disconnected), the image from the SDS and the primary is compared. If equal the update is done. If not it raises the error. The comparison can be optimized if you use VERCOLS. > > This concept of versioning of each row is interesting...and is > centered around my original question on how READs work on the SDS. > But I see in the slides that the reads on the SDS only supports > committed reads so this must mot apply to read operations. > Can you share those slides? -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Fernando thanks so much for your time on this. The slides were in one of the links from the first poster, fv_it: https://www.ibm.com/developerworks/wikis/display/IDS101/Home The specific slide I pasted the above is in the IDS_Rep_Avail_Overview presentation.

On Thu, Sep 9, 2010 at 8:48 PM, shorti <lbryan21@juno.com> wrote: > Fernando thanks so much for your time on this. The slides were in one > of the links from the first poster, fv_it: > > https://www.ibm.com/developerworks/wikis/display/IDS101/Home > > The specific slide I pasted the above is in the IDS_Rep_Avail_Overview > presentation. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > Ok.... The reason why I wanted to see the slides is this paragraph: "This concept of versioning of each row is interesting...and is centered around my original question on how READs work on the SDS. But I see in the slides that the reads on the SDS only supports committed reads so this must mot apply to read operations." On slide 14 you can see that dirty reads are also supported (most people with experience in other technologies don't want to use them). The whole concept of row versioning is what I called as VERCOLS (which can also be used without MACH 11 to implement what we call optimistic concurrency). But again, it you don't use them, the primary can check that the data that was located and read on the secondary is up to date and as such can be changed. If not it will raise the error like it's stated in slide 18. I'm not sure if this answers all your questions (I suppose it doesn't because the subject is complex). If not please send the new questions. Note that due to the nature of SDS, it's more likely that they are up to date than an HDR or specially an RSS. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

On Sep 9, 1:58 pm, Fernando Nunes <domusonl...@gmail.com> wrote: > On Thu, Sep 9, 2010 at 8:48 PM, shorti <lbrya...@juno.com> wrote: > > Fernando thanks so much for your time on this.  The slides were in one > > of the links from the first poster, fv_it: > > >https://www.ibm.com/developerworks/wikis/display/IDS101/Home > > > The specific slide I pasted the above is in the IDS_Rep_Avail_Overview > > presentation. > > > _______________________________________________ > > Informix-list mailing list > > Informix-l...@iiug.org > >http://www.iiug.org/mailman/listinfo/informix-list > > Ok.... The reason why I wanted to see the slides is this paragraph: > > "This concept of versioning of each row is interesting...and is > centered around my original question on how READs work on the SDS. > But I see in the slides that the reads on the SDS only supports > committed reads so this must mot apply to read operations." > > On slide 14 you can see that dirty reads are also supported (most people > with experience in other technologies don't want to use them). > The whole concept of row versioning is what I called as VERCOLS (which can > also be used without MACH 11 to implement what we call optimistic > concurrency). > But again, it you don't use them, the primary can check that the data that > was located and read on the secondary is up to date and as such can be > changed. > If not it will raise the error like it's stated in slide 18. > > I'm not sure if this answers all your questions (I suppose it doesn't > because the subject is complex). If not please send the new questions. > > Note that due to the nature of SDS, it's more likely that they are up to > date than an HDR or specially an RSS. > Regards. > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... I think the slides are confusing because on slide 19 it says differently: "The secondary node supports ‘Committed Read’ and ‘Last Committed Read’ isolation levels." "This is implemented as a locally committed read, not a globally committed read. The Read on the secondary node will not return an uncommitted read However the row could be in the process of being updated" Here it states specifically that the secondary will not return uncommitted reads. In prior database implementations I have not hesitated in doing dirty reads as long as it applies to the situation. This is not the only item confusing in this presentation...slide 8 also specifically says "Secondary available for Read-only queries" for HDR but later on the other slide does states that updates are allowed.

On Fri, Sep 10, 2010 at 1:50 AM, shorti <lbryan21@juno.com> wrote: > On Sep 9, 1:58 pm, Fernando Nunes <domusonl...@gmail.com> wrote: > > On Thu, Sep 9, 2010 at 8:48 PM, shorti <lbrya...@juno.com> wrote: > > > Fernando thanks so much for your time on this. The slides were in one > > > of the links from the first poster, fv_it: > > > > >https://www.ibm.com/developerworks/wikis/display/IDS101/Home > > > > > The specific slide I pasted the above is in the IDS_Rep_Avail_Overview > > > presentation. > > > > > _______________________________________________ > > > Informix-list mailing list > > > Informix-l...@iiug.org > > >http://www.iiug.org/mailman/listinfo/informix-list > > > > Ok.... The reason why I wanted to see the slides is this paragraph: > > > > "This concept of versioning of each row is interesting...and is > > centered around my original question on how READs work on the SDS. > > But I see in the slides that the reads on the SDS only supports > > committed reads so this must mot apply to read operations." > > > > On slide 14 you can see that dirty reads are also supported (most people > > with experience in other technologies don't want to use them). > > The whole concept of row versioning is what I called as VERCOLS (which > can > > also be used without MACH 11 to implement what we call optimistic > > concurrency). > > But again, it you don't use them, the primary can check that the data > that > > was located and read on the secondary is up to date and as such can be > > changed. > > If not it will raise the error like it's stated in slide 18. > > > > I'm not sure if this answers all your questions (I suppose it doesn't > > because the subject is complex). If not please send the new questions. > > > > Note that due to the nature of SDS, it's more likely that they are up to > > date than an HDR or specially an RSS. > > Regards. > > > > -- > > Fernando Nunes > > Portugal > > > > http://informix-technology.blogspot.com > > My email works... but I don't check it frequently... > > I think the slides are confusing because on slide 19 it says > differently: > > "The secondary node supports ‘Committed Read’ and ‘Last Committed > Read’ isolation levels." > > "This is implemented as a locally committed read, not a globally > committed read. > The Read on the secondary node will not return an uncommitted read > However the row could be in the process of being updated" > > ... when using committed read isolation level... > Here it states specifically that the secondary will not return > uncommitted reads. In prior database implementations I have not > hesitated in doing dirty reads as long as it applies to the > situation. > That slide referrers to Committed Reads on Secondary. It's not correct to assume that a slide that talks about Committed reads means that dirty reads are not possible. > > This is not the only item confusing in this presentation...slide 8 > also specifically says "Secondary available for Read-only queries" for > HDR but later on the other slide does states that updates are > allowed. > Yes... That can be confusing.... Maybe it referrers to what HDR used to provide before 11.50.... I think somebody already suggested: You can access a virtual machine with a complete MACH 11 setup (all nodes on the same machine). It's a perfect way to make some tests. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

OK, Optimistic protocols on MACH11 secondaries... Here's the scoop: - The application on a secondary can read the row LONG before it tries to update the row. - When the application tries to update the row, the update is shipped to the primary, - The primary will do one of two things to verify that the row was not modified by another application on the primary or on another secondary: - If the table was created WITH VERCOLS, the primary will compare the two hidden columns that WITH VERCOLS adds to the row, if the value on the primary is different than the pre-modified version returned by the secondary as part of the update, then the update will fail with an error indicating that the row was modified by another user - If the table was NOT created WITH VERCOLS, then the secondary will ship a complete pre-update copy of the row along with the update statement to the primary and the primary will use that copy to verify that the row was not modified by another process after the secondary server's application fetched it and prior to the update statement being received by the primary. This is how the primary makes sure that you do not update a row with stale values. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, 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, Sep 9, 2010 at 3:48 PM, shorti <lbryan21@juno.com> wrote: > Fernando thanks so much for your time on this. The slides were in one > of the links from the first poster, fv_it: > > https://www.ibm.com/developerworks/wikis/display/IDS101/Home > > The specific slide I pasted the above is in the IDS_Rep_Avail_Overview > presentation. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > On Thu, Sep 9, 2010 at 3:48 PM, shorti <lbryan21@juno.com> wrote: > Fernando thanks so much for your time on this. The slides were in one > of the links from the first poster, fv_it: > > https://www.ibm.com/developerworks/wikis/display/IDS101/Home > > The specific slide I pasted the above is in the IDS_Rep_Avail_Overview > presentation. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > don't want to use myschemart