Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Dan saw bursts of many checkpoints per second each night on IDS 11.70.FC7 (Linux), with 'onstat -g ckp' showing trigger IPL, which he couldn't find documented. Answers: IPL means index page logging, typically caused by index builds/rebuilds or the B-tree scanner compressing mostly empty index pages with index logging enabled; Madison Pruet added that during index transfer to an HDR/secondary server the engine issues several non-blocking checkpoints to keep the secondary's buffer pool from getting too dirty. A follow-up question about the same transaction ID repeating in onlog was answered: transaction IDs are only unique among currently open transactions, so reuse is normal.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
DAN MUELLER — — source: IIUG Forums & Mailing Lists
Morn'n Folks,
IDS 11.70.FC7
Linux
On one of my systems at a certain time each nithe I get checkpoint after
checkpoint. This goes on for about a minute or two and results in several
checkpoints per second. In onstat -g ckp, the trigger is IPL. I do not see
this doc'd and the system is not being rebooted nor is Informix being bounced.
Can someone please explain this trigger to me?
Thanx,
Dan
↪ replying to DAN MUELLER
Paul Watson — — source: IIUG Forums & Mailing Lists
IPL is index page logging - what is running at the time?
Cheers
Paul
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAN
> MUELLER
> Sent: Wednesday, August 28, 2013 9:58 AM
> To: ids@iiug.org
> Subject: onstat -g ckp Question [31282]
>
> Morn'n Folks,
>
> IDS 11.70.FC7
> Linux
>
> On one of my systems at a certain time each nithe I get checkpoint after
> checkpoint. This goes on for about a minute or two and results in several
> checkpoints per second. In onstat -g ckp, the trigger is IPL. I do not see
> this doc'd and the system is not being rebooted nor is Informix being
> bounced.
> Can someone please explain this trigger to me?
>
> Thanx,
> Dan
>
>
> **********************************************************
> *********************
> Forum Note: Use "Reply" to post a response in the discussion forum.
↪ replying to Paul Watson
DAN MUELLER — — source: IIUG Forums & Mailing Lists
Index Page Logging which could be caused by scheduled index rebuilds or by
the Btree Scanner compressing adjacent index pages that are mostly empty
with index logging enabled.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.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 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 Wed, Aug 28, 2013 at 10:57 AM, DAN MUELLER <ddmueller@intercall.com>wrote:
> Morn'n Folks,
>
> IDS 11.70.FC7
> Linux
>
> On one of my systems at a certain time each nithe I get checkpoint after
> checkpoint. This goes on for about a minute or two and results in several
> checkpoints per second. In onstat -g ckp, the trigger is IPL. I do not see
> this doc'd and the system is not being rebooted nor is Informix being
> bounced.
> Can someone please explain this trigger to me?
>
> Thanx,
> Dan
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11c352aa74ace604e5036f81
↪ replying to DAN MUELLER
Madison Pruet — — source: IIUG Forums & Mailing Lists
When we are transferring an index from the primary to the secondary we =
have
a problem. All the work and maintain a clean buffer pool on the primary=
is
done all the index is being built. However on the secondary there is no=
way
to keep the buffer pool clean. If we do not keep the buffer pool and th=
at
will cause problems with the apply on the secondary. To prevent the buf=
fer
pool on the secondary from becoming too dirty and thus affecting apply
performance, and indirectly causing a backflow which would affect
performance on the primary, we issue several non-blocking checkpoints
during the index transfer.
Sent from my iPad
On Aug 28, 2013, at 8:58 AM, "DAN MUELLER" <ddmueller@intercall.com> wr=
ote:
> Morn'n Folks,
>
> IDS 11.70.FC7
> Linux
>
> On one of my systems at a certain time each nithe I get checkpoint af=
ter
> checkpoint. This goes on for about a minute or two and results in sev=
eral
> checkpoints per second. In onstat -g ckp, the trigger is IPL. I do no=
t
see
> this doc'd and the system is not being rebooted nor is Informix being=
bounced.
> Can someone please explain this trigger to me?
>
> Thanx,
> Dan
>
>
>
***********************************************************************=
********
> Forum Note: Use "Reply" to post a response in the discussion forum.=
=
↪ replying to DAN MUELLER
DAN MUELLER — — source: IIUG Forums & Mailing Lists
After some more digging through onlog, I can see the same transaction id being
used over and over (ie... begin, commit, begin, commit, etc... all with the
same transaction id and user id of informix). They are also predominantly
hdelete and delitem. Looks like a purge process however I am confused about
the reuse of the transaction id/
Any thoughts on that part?
Thanx,
Dan
↪ replying to DAN MUELLER
Paul Watson — — source: IIUG Forums & Mailing Lists
The transaction is NOT unique in the logical logs, it is only unique with
the current open transactions
> -----Original Message-----
> From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of DAN
> MUELLER
> Sent: Wednesday, August 28, 2013 11:17 AM
> To: ids@iiug.org
> Subject: Re: onstat -g ckp Question [31287]
>
> After some more digging through onlog, I can see the same transaction id
> being
> used over and over (ie... begin, commit, begin, commit, etc... all with
the
> same transaction id and user id of informix). They are also predominantly
> hdelete and delitem. Looks like a purge process however I am confused
> about
> the reuse of the transaction id/
>
> Any thoughts on that part?
>
> Thanx,
> Dan
>
>
> **********************************************************
> *********************
> Forum Note: Use "Reply" to post a response in the discussion forum.
Normal.... it has to be unique during the lifespan of a transaction. only
that.
On Aug 28, 2013 5:17 PM, "DAN MUELLER" <ddmueller@intercall.com> wrote:
> After some more digging through onlog, I can see the same transaction id
> being
> used over and over (ie... begin, commit, begin, commit, etc... all with the
> same transaction id and user id of informix). They are also predominantly
> hdelete and delitem. Looks like a purge process however I am confused about
> the reuse of the transaction id/
>
> Any thoughts on that part?
>
> Thanx,
> Dan
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001a11c2c1ea7f357304e504e8c0
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.