Madison,

Thank You very much for the clarification.

My understanding was that 'choosing the page as a victim'
is the same as 'choosing the page for modification',
and that 'page is forced to disk' means that the page MUST
be flushed before the further modification

Even if the page flushing can be delayed, the affect of
forcing the page to disk should be similar to setting
LRU_MIN/LRU_MAX to 0/0 with Informix (this setting dramatically
increases write activity)

If this relates only to cases when buffer pool if full
of modified pages (similar to Informix FG writes) -
then it's OK. But still not clear from the Manual.

I think this chapter of DB2 documentation need to be
written more clearly


------------------------------------------
Alexey Sonkin


> -----Original Message-----
> From: Madison Pruet [mailto:mpruet@comcast.net]
>
> See below...
>
> "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
> news:caj34l$lpd$1@news.xmission.com...
> >
> >
> >
> > > -----Original Message-----
> > > From: Madison Pruet [mailto:mpruet@comcast.net]
> > >
> > > What is described by the 'victim' in the Admin Guide is the same as a
> > > forground write in IDS. This does not mean that every dirty page must
> > > be flushed to disk before it can be used again. It means that if the
> > > buffer pool is so tight that there are no clean buffers available,
> > > then a page will be forced to disk, just as with the IDS forground
> > > write.
> > >
> > > Normally the dirty buffers will be flushed to disk by the page
> > > cleaners when the parameter of chngpgs_thresh is reached, or if the
> > > distance between the oldest dirty page and the current log position
> > > reaches a set percentage as defined by the 'softmax' parameter.
> > > Therefor, recovery time is based on a set percentage of the total log
> > > file size. If you want to minimize the recovery time, you can set
> > > 'softmax' to 1 and thus ensure that the recovery
> > > process will only need to process 1% of the logs.
> > >
> > >
> > > t
> > >
> >
> > Madison,
> >
> > I can just give a bigger fragment of DB2 documentation.
> > There is a chance that my understanding of that fragment is wrong
> (English
> > is not my native language).
> > May be, this fragment is written incorrectly
> >
> > As for myself, I can't understand the necessity of that additional dirty
> > page flush. Unfortunately, I don't have any access to any additional
> > information on DB2 architecture except the official manual.
> >
> > ........................
> > Administration Guide: Performance
> > Chapter 2. Architecture and processes ->
> > -> Processes -> Update process
> >
> > "When an agent updates a page, the database manager uses the following
> > protocol to minimize the I/O required by the transaction and ensure
> > recoverability. 1. The page to be updated is pinned and latched with an
> > exclusive lock. A log record is written to the log buffer describing how
> to
> > redo and undo the change. As part of this action, a log sequence number
> > (LSN) is obtained and is stored in the page header of the page being
> > updated. 2. The change is made to the page. 3. The page is unlatched and
> > unfixed. The page is considered to be "dirty" because changes to the
> page
> > have not been written out to disk. 4. The log buffer is updated. Both
> the
> > data in the log buffer and the "dirty" data page are forced to disk.
> >
> > For better performance, these I/Os are delayed until a convenient point,
> > such as during a lull in the system load, or until necessary to ensure
> > recoverability, or to limit recovery time. Specifically, a "dirty" page
> is
> > forced to disk at the following times:
> > - When another agent chooses it as a victim.
>
> Same as a forground write.
>
>
> > - When a page cleaner acts on the page as the result of:
> > - Another agent choosing it as a victim.
>
> Same as a forground write
>
> > - The chngpgs_thresh database configuration parameter percentage value
> is
> > exceeded. When this value is exceeded, asynchronous page cleaners
> > wake up and write changed pages to disk.
>
> In essence, the same as LRU_MIN/LRU_MAX
>
> > - The softmax database configuration parameter percentage value is
> > exceeded. Once exceeded, asynchronous page cleaners wake up and
> > write changed pages to disk.
>
> In essence, flush the page when not flushing it would cause recovery to
> have
> to start too far back in the logs.
>
> > - When the page was updated as part of a table which has the NOT LOGGED
> > INITIALLY clause invoked and a COMMIT statement is issued. When the
> COMMIT
> > statement is executed, all changed pages are flushed to disk to ensure
> > recoverability."
>
> Well --- that makes sense. If you have an unlogged database, how else can
> you guarentee consistancy?
>
> >
> >
> > Best regards,
> > Alexey
> > sending to informix-list
>

sending to informix-list

"Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
news:cakm7m$sjd$1@news.xmission.com...
>
> Madison,
>
> Thank You very much for the clarification.
>
> My understanding was that 'choosing the page as a victim'
> is the same as 'choosing the page for modification',
> and that 'page is forced to disk' means that the page MUST
> be flushed before the further modification

Not quite, the victim page is a forground write.
>
> Even if the page flushing can be delayed, the affect of
> forcing the page to disk should be similar to setting
> LRU_MIN/LRU_MAX to 0/0 with Informix (this setting dramatically
> increases write activity)

This would be the case only if chngpgs_thresh is set to zero.

>
> If this relates only to cases when buffer pool if full
> of modified pages (similar to Informix FG writes) -
> then it's OK. But still not clear from the Manual.
>
> I think this chapter of DB2 documentation need to be
> written more clearly

Yep - same with Oracle documentation, Microsoft documentation, and IDS
documentation. ;-)

>
>
> ------------------------------------------
> Alexey Sonkin
>
>
> > -----Original Message-----
> > From: Madison Pruet [mailto:mpruet@comcast.net]
> >
> > See below...
> >
> > "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
> > news:caj34l$lpd$1@news.xmission.com...
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Madison Pruet [mailto:mpruet@comcast.net]
> > > >
> > > > What is described by the 'victim' in the Admin Guide is the same as
a
> > > > forground write in IDS. This does not mean that every dirty page
must
> > > > be flushed to disk before it can be used again. It means that if
the
> > > > buffer pool is so tight that there are no clean buffers available,
> > > > then a page will be forced to disk, just as with the IDS forground
> > > > write.
> > > >
> > > > Normally the dirty buffers will be flushed to disk by the page
> > > > cleaners when the parameter of chngpgs_thresh is reached, or if the
> > > > distance between the oldest dirty page and the current log position
> > > > reaches a set percentage as defined by the 'softmax' parameter.
> > > > Therefor, recovery time is based on a set percentage of the total
log
> > > > file size. If you want to minimize the recovery time, you can set
> > > > 'softmax' to 1 and thus ensure that the recovery
> > > > process will only need to process 1% of the logs.
> > > >
> > > >
> > > > t
> > > >
> > >
> > > Madison,
> > >
> > > I can just give a bigger fragment of DB2 documentation.
> > > There is a chance that my understanding of that fragment is wrong
> > (English
> > > is not my native language).
> > > May be, this fragment is written incorrectly
> > >
> > > As for myself, I can't understand the necessity of that additional
dirty
> > > page flush. Unfortunately, I don't have any access to any additional
> > > information on DB2 architecture except the official manual.
> > >
> > > ........................
> > > Administration Guide: Performance
> > > Chapter 2. Architecture and processes ->
> > > -> Processes -> Update process
> > >
> > > "When an agent updates a page, the database manager uses the following
> > > protocol to minimize the I/O required by the transaction and ensure
> > > recoverability. 1. The page to be updated is pinned and latched with
an
> > > exclusive lock. A log record is written to the log buffer describing
how
> > to
> > > redo and undo the change. As part of this action, a log sequence
number
> > > (LSN) is obtained and is stored in the page header of the page being
> > > updated. 2. The change is made to the page. 3. The page is unlatched
and
> > > unfixed. The page is considered to be "dirty" because changes to the
> > page
> > > have not been written out to disk. 4. The log buffer is updated. Both
> > the
> > > data in the log buffer and the "dirty" data page are forced to disk.
> > >
> > > For better performance, these I/Os are delayed until a convenient
point,
> > > such as during a lull in the system load, or until necessary to ensure
> > > recoverability, or to limit recovery time. Specifically, a "dirty"
page
> > is
> > > forced to disk at the following times:
> > > - When another agent chooses it as a victim.
> >
> > Same as a forground write.
> >
> >
> > > - When a page cleaner acts on the page as the result of:
> > > - Another agent choosing it as a victim.
> >
> > Same as a forground write
> >
> > > - The chngpgs_thresh database configuration parameter percentage
value
> > is
> > > exceeded. When this value is exceeded, asynchronous page cleaners
> > > wake up and write changed pages to disk.
> >
> > In essence, the same as LRU_MIN/LRU_MAX
> >
> > > - The softmax database configuration parameter percentage value is
> > > exceeded. Once exceeded, asynchronous page cleaners wake up and
> > > write changed pages to disk.
> >
> > In essence, flush the page when not flushing it would cause recovery to
> > have
> > to start too far back in the logs.
> >
> > > - When the page was updated as part of a table which has the NOT
LOGGED
> > > INITIALLY clause invoked and a COMMIT statement is issued. When the
> > COMMIT
> > > statement is executed, all changed pages are flushed to disk to ensure
> > > recoverability."
> >
> > Well --- that makes sense. If you have an unlogged database, how else
can
> > you guarentee consistancy?
> >
> > >
> > >
> > > Best regards,
> > > Alexey
> > > sending to informix-list
> >
>
> sending to informix-list

"Madison Pruet" <mpruet@comcast.net> wrote in message news:Cglzc.34817$eu.25445@attbi_s02...
>
> "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
> news:cakm7m$sjd$1@news.xmission.com...
> >
> > Madison,
> >
> > Thank You very much for the clarification.
> >
> > My understanding was that 'choosing the page as a victim'
> > is the same as 'choosing the page for modification',
> > and that 'page is forced to disk' means that the page MUST
> > be flushed before the further modification
>
> Not quite, the victim page is a forground write.
> >
> > Even if the page flushing can be delayed, the affect of
> > forcing the page to disk should be similar to setting
> > LRU_MIN/LRU_MAX to 0/0 with Informix (this setting dramatically
> > increases write activity)
>
> This would be the case only if chngpgs_thresh is set to zero.
>
> >
> > If this relates only to cases when buffer pool if full
> > of modified pages (similar to Informix FG writes) -
> > then it's OK. But still not clear from the Manual.
> >
> > I think this chapter of DB2 documentation need to be
> > written more clearly
>
> Yep - same with Oracle documentation, Microsoft documentation, and IDS
> documentation. ;-)

Thanks Madison. Your explantion was quite informative. I got to agree with
Alexey. DB2 documentation isn't clear on this.

Yea - trying to read documentation is always difficult and tricky at best.
;-)

M.P.


"rkusenet" <rkusenet@sympatico.ca> wrote in message
news:2j676lFtqpqtU1@uni-berlin.de...
>
> "Madison Pruet" <mpruet@comcast.net> wrote in message
news:Cglzc.34817$eu.25445@attbi_s02...
> >
> > "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message
> > news:cakm7m$sjd$1@news.xmission.com...
> > >
> > > Madison,
> > >
> > > Thank You very much for the clarification.
> > >
> > > My understanding was that 'choosing the page as a victim'
> > > is the same as 'choosing the page for modification',
> > > and that 'page is forced to disk' means that the page MUST
> > > be flushed before the further modification
> >
> > Not quite, the victim page is a forground write.
> > >
> > > Even if the page flushing can be delayed, the affect of
> > > forcing the page to disk should be similar to setting
> > > LRU_MIN/LRU_MAX to 0/0 with Informix (this setting dramatically
> > > increases write activity)
> >
> > This would be the case only if chngpgs_thresh is set to zero.
> >
> > >
> > > If this relates only to cases when buffer pool if full
> > > of modified pages (similar to Informix FG writes) -
> > > then it's OK. But still not clear from the Manual.
> > >
> > > I think this chapter of DB2 documentation need to be
> > > written more clearly
> >
> > Yep - same with Oracle documentation, Microsoft documentation, and IDS
> > documentation. ;-)
>
> Thanks Madison. Your explantion was quite informative. I got to agree with
> Alexey. DB2 documentation isn't clear on this.
>
>
>