sysmaster:sysptnhdr
User questioned whether sysmaster:sysptnhdr should return identical values across primary, HDR, and RSS nodes in an Informix cluster, noting they differ for ninserts/nupdates/ndeletes. Responders clarified sysptnhdr is a view over partition headers, not a real table. Statistics stored in partition headers can differ between nodes due to how pages are accessed during updates, and differences persist until checkpoint time when headers flush.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Hi, Could anyone given an opinion on whether I should expect sysmaster:sysptnhdr to return the same values on all nodes in an Informix HDR/RSS cluster? I notice that the primary, HDR and RSS servers in a cluster all return different values for ninserts, nupdates, ndeletes even though only the primary can handle data changes. As far as I can tell, sysptnhdr is real table in sysmaster and not part of the SMI interface into shared memory and so faithful replication of this should be a reasonable expectation. Ben.
Check in $INFORMIXDIR/etc/sysmaster.sql if sysptnhdr is dropped and so not a real table. Regards, David. > On 22 March 2018 at 13:36 BENJAMIN THOMPSON <benjamin.thompson@skybettingandgaming.com> wrote: > > > Hi, > > Could anyone given an opinion on whether I should expect sysmaster:sysptnhdr > to return the same values on all nodes in an Informix HDR/RSS cluster? I > notice that the primary, HDR and RSS servers in a cluster all return different > values for ninserts, nupdates, ndeletes even though only the primary can > handle data changes. > > As far as I can tell, sysptnhdr is real table in sysmaster and not part of the > SMI interface into shared memory and so faithful replication of this should be > a reasonable expectation. > > Ben. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Interesting question, and I'm just thinking out loud... I don't think sysmaster:sysptnhdr is a real table. It should be a view over the tablespace.tablespace. And the numbers of INSERTs/UPDATEs/DELETEs is stored in the partition header. If that's the case, they would be different depending on the "lag" of the secondary servers.... Do you see the numbers changing? Are they completely different in PRI and secondary servers? Regards. On Thu, Mar 22, 2018 at 2:36 PM, BENJAMIN THOMPSON < benjamin.thompson@skybettingandgaming.com> wrote: > Hi, > > Could anyone given an opinion on whether I should expect > sysmaster:sysptnhdr > to return the same values on all nodes in an Informix HDR/RSS cluster? I > notice that the primary, HDR and RSS servers in a cluster all return > different > values for ninserts, nupdates, ndeletes even though only the primary can > handle data changes. > > As far as I can tell, sysptnhdr is real table in sysmaster and not part of > the > SMI interface into shared memory and so faithful replication of this > should be > a reasonable expectation. > > Ben. > > > ************************************************************ > ******************* > 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...
I should think that they approximate one another not mirror one another. One server might have to pull a page twice to update two rows while the other might sometimes get them both in one. j. > On Mar 22, 2018, at 10:06 AM, Fernando Nunes <domusonline@gmail.com> wrote: > > Interesting question, and I'm just thinking out loud... > I don't think sysmaster:sysptnhdr is a real table. It should be a view over > the tablespace.tablespace. And the numbers of INSERTs/UPDATEs/DELETEs is > stored in the partition header. > > If that's the case, they would be different depending on the "lag" of the > secondary servers.... Do you see the numbers changing? Are they completely > different in PRI and secondary servers? > > Regards. > > On Thu, Mar 22, 2018 at 2:36 PM, BENJAMIN THOMPSON < > benjamin.thompson@skybettingandgaming.com> wrote: > >> Hi, >> >> Could anyone given an opinion on whether I should expect >> sysmaster:sysptnhdr >> to return the same values on all nodes in an Informix HDR/RSS cluster? I >> notice that the primary, HDR and RSS servers in a cluster all return >> different >> values for ninserts, nupdates, ndeletes even though only the primary can >> handle data changes. >> >> As far as I can tell, sysptnhdr is real table in sysmaster and not part of >> the >> SMI interface into shared memory and so faithful replication of this >> should be >> a reasonable expectation. >> >> Ben. >> >> >> ************************************************************ >> ******************* >> 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... > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Hi Fernando, I am pretty sure the differences I am seeing are reasonably persistent and definitely not caused by replication lag. For now it is not that important provided I can trust the statistics on the primary. Thanks for replying, Ben.
The partition headers are flushed at checkpoint time... that's when the difference should become minimal... On Fri, Mar 23, 2018 at 1:06 PM, BENJAMIN THOMPSON < benjamin.thompson@skybettingandgaming.com> wrote: > Hi Fernando, > > I am pretty sure the differences I am seeing are reasonably persistent and > definitely not caused by replication lag. > > For now it is not that important provided I can trust the statistics on the > primary. > > Thanks for replying, Ben. > > > ************************************************************ > ******************* > 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...