"Checkpoints" screen in promon and no-integrity mode

[George Potemkin (peg)]

Hello,

If a database was started with the -i parameter then promon/R&D/3/4.
Checkpoints shows only one line - no matter how many checkpoints took place.
Timestamp of this "checkpoint" is db startup time.
The same is true for the _Checkpoint VST.

"Activity: Summary" screen shows the real number of checkpoints.
"Status: BI Log" screen shows the correct timestamp of last checkpoint.

Why "Checkpoints" screen is an exception?
Is it a promon's bug or an intentional behavior?

Tested with V10.2B/11.4 on Windows and Unix.

Regards,
George Potemkin
Progress Technologies
S.-Petersburg, Russia
Phone: +7 (812) 438 2757
http://www.progress-tech.ru

[George Potemkin (peg)]

Richard,

Thanks for comments.

> Maybe in this environment with -i set it should be reported as clusters
> closed as opposed to checkpoints?

IMHO, it would be useful at least as the timestamps in the life of
databases.

But it was just a curiosity rather than an enhancement request ;-)
I understand that the no-integrity mode is rarely used in production
environment. In my case it was just a test.

Regards,
George Potemkin
Progress Technologies
S.-Petersburg, Russia
Phone: +7 (812) 438 2757
http://www.progress-tech.ru

--------------------------------------------------
From: "Richard Banville" <ri...@progress.com>
Sent: Tuesday, March 10, 2015 15:57
To: "George Potemkin (peg)" <gpot...@progress-tech.ru>; <d...@peg.com>
Subject: RE: "Checkpoints" screen in promon and no-integrity mode

> Interesting. OpenEdge does not consider it a checkpoint because there is
> no way to actually determine that data written ever makes it to disk and
> that the "checkpoint" was completed. Of course the cluster is considered
> closed and the necessary bi data is written buffered (-B buffer pool is
> not processed so nothing is put on the checkpoint queue). Since the bi is
> written all buffered with no -B processing or file system synch it is
> really not a "checkpoint" in the true meaning of the word.
>
> Maybe in this environment with -i set it should be reported as clusters
> closed as opposed to checkpoints?
>
> _________________________________
> Richard Banville
> Fellow, OpenEdge Development
>
> 14 Oak Park | Bedford, MA 01730 | USA
> DIRECT +1 781 280 4875
> ri...@progress.com

[Gus Bjorklund]

it is entirely intentional behavior.


when you run with -i (and you should not do so), checkpoints are turned
off. this is because you are in /no integrity/ mode and there is no need
for the asynchronous checkpoint mechanism to ensure that modified data
blocks actually got written to disk. they only have be written at
shutdown, though they /may/ be written before that. if you crash, you will
be hosed.

you can still see bi notes being written if you look at the other displays
in promon. they should be written in async mode. clusters are still
opened, filled up, and closed. but there is no need for fdatasync()
operations when a cluster is closed.

-gus


On 3/10/15, 5:13 AM, "George Potemkin (peg)" <gpot...@progress-tech.ru>
wrote:

[George Potemkin (peg)]

Hello Gus,

> it is entirely intentional behavior.

But then it's inconsistent with "Activity: Summary" and "Status: BI Log"
screens that count the checkpoints and report their timestamps.

I suspected it's a matter of the "checkpoint" definition:

> you can still see bi notes being written if you look at the other displays
> in promon. they should be written in async mode. clusters are still
> opened, filled up, and closed. but there is no need for fdatasync()
> operations when a cluster is closed.

... and Progress still creates the RL_INMEM notes. Why not just to report
their timestamps?

We recently run some test in no-integrity mode and at some moments a
database frozen for quite a long time. Db activity was absolutely zero (disk
IO, latches, resources, no waits of any kinds). Even db buffer locks were no
released during the whole interval (30-150 seconds!). My first thought was
it's what is left from the checkpoints in no-integrity mode and I tried to
verify this using the Checkpoints screen. And then I did not find any
checkpoints there. My hypothesis was disproved only by "Activity: Summary"
and "Status: BI Log" screens but only because the monitoring interval was
fortunately short enough.

[Gus Bjorklund]

no, it is not a matter of checkpoint definition. it happens that
checkpoints and bi cluster open/close happen at the same time but that is
not necessary.


anyhow, i never considered what would be displayed when running -i in
multi-user mode since i never thought anyone would be dumb enough to
actually do it. :)

now that you have brought it up, it isnšt something under my control. if
it were, i would make the checkpoint display say *** checkpoints not
enabled in no-integrity mode *** and nothing else. i cannot endorse anyone
using -i in production, no matter how useful it may be. but using -r has
much the same effect but still allows crash recovery if the machine does
not crash.

-gus

On 3/10/15, 12:21 PM, "George Potemkin (peg)" <gpot...@progress-tech.ru>
wrote: