Re: Checkpoint Question - need feedback

Superboer wrote: > Hello Madison, > > sorry have not looked for it yet.... > what is the max size for the phys log nowadays; it used to be 2 GB > eq the size of a chunk....that is i guess to small. > > >>So - basic question --- Is the cost of the increased physical log file >>(maybe 3-4 times larger in some cases) totally outweigh the benefit of >>non-blocking checkpoints? > > > Yes. > > however if one is loading a truck load of data, page cleaners may not > keep > up at all. In such a case blocking checkpoint may be welcome. Why not do a flush to disk without doing the check point. You can use onmode -B. This command uses the same disk flushing code that the checkpoint code does without doing any user blocking. > or generate our own checkpoint whenever the buffer cache is 75% dirty > start a checkpoint which does big buffer writes... > > i rather run a checkpoint when the buffer cache is 75 % dirty then when > the phys > log is 75% full; at least resources are used the best way and i have > some control > over it and most important, it's fast... If you are in a logging database and you have not dropped a table since the last checkpoint and you are inserting rows at the end of the table, no physical logging is done. FYI, John > > So do not take them away completely please. > > See you > > Superboer. >

Thanks John, i know but if rows are added how does one make sure it is inserted in uninialized pages (without rebuilding a table that is...) i know HPL does in express mode; it adds an extent; but simple inserts will put data where there is room i guess. Superboer. John Miller schreef: > Superboer wrote: > > > Hello Madison, > > > > sorry have not looked for it yet.... > > what is the max size for the phys log nowadays; it used to be 2 GB > > eq the size of a chunk....that is i guess to small. > > > > > >>So - basic question --- Is the cost of the increased physical log file > >>(maybe 3-4 times larger in some cases) totally outweigh the benefit of > >>non-blocking checkpoints? > > > > > > Yes. > > > > however if one is loading a truck load of data, page cleaners may not > > keep > > up at all. In such a case blocking checkpoint may be welcome. > > Why not do a flush to disk without doing the check point. You can > use onmode -B. This command uses the same disk flushing code that > the checkpoint code does without doing any user blocking. > > > or generate our own checkpoint whenever the buffer cache is 75% dirty > > start a checkpoint which does big buffer writes... > > > > i rather run a checkpoint when the buffer cache is 75 % dirty then when > > the phys > > log is 75% full; at least resources are used the best way and i have > > some control > > over it and most important, it's fast... > > If you are in a logging database and you have not dropped a table since > the last checkpoint and you are inserting rows at the end of the table, > no physical logging is done. > > > FYI, > John > > > > > > So do not take them away completely please. > > > > See you > > > > Superboer. > >

John Miller wrote: > > Why not do a flush to disk without doing the check point. You can > use onmode -B. This command uses the same disk flushing code that > the checkpoint code does without doing any user blocking. > Because it is undocumented and unsupported? Or did the support position on that change? David.