Re: Mach11 questions

I not sure if this help to clarify any doubt... What the manual says (the last paragraph): http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.sqls.doc/ids_sqs_2012.htm Isolation Levels for Secondary Data Replication Servers If the UPDATABLE_SECONDARY configuration parameter is disabled (by being unset or by being set to zero), a secondary data replication server is read-only. In this case, only the Dirty Read or Read Uncommitted transaction isolation levels are available on High-Availability Data Replication (HDR) and Remote Standalone Secondary (RSS) servers. If the UPDATABLE_SECONDARY parameter is enabled (by being set to a valid number of connections greater than zero), a secondary data replication server can support the Read Committed, Committed Read, or Committed Read Last Committed transaction isolation level, with or without the USELASTCOMMITTED session environment variable of the SET ENVIRONMENT statement. Only DML statements of SQL (the INSERT, UPDATE, and DELETE statements) can support write operations on anupdatable secondary server. Shared Disk Secondary (SDS) servers, however, can support the Read Committed, Committed Read, Committed Read Last Committed isolation levels, regardless of their UPDATABLE_SECONDARY setting. For more information about the UPDATABLE_SECONDARY configuration parameter, see the IBM® Informix® Administrator's Reference. --- Em qui, 9/9/10, Fernando Nunes <domusonline@gmail.com> escreveu: De: Fernando Nunes <domusonline@gmail.com> Assunto: Re: Mach11 questions Para: informix-list@iiug.org Data: Quinta-feira, 9 de Setembro de 2010, 15:17 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... -----Anexo incorporado----- _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list