Physical Log Size
Posted in 2014
Topics: Logging & Checkpoints
IDS 11.70.FC8 AIX 1 6 00CC96664C00 I received the following message in the online.log file ..... is it something to be concerned about ? Based on the current workload, the physical log might be too small to accommodate the time it takes to flush the buffer pool during checkpoint processing. The server might block transactions during checkpoints. If the server blocks transactions, increase the physical log size to at least 4005820 KB. ________________________________ NOTE: This e-mail message is subject to the MTN Group disclaimer see https://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
Dirk
This is advisory and can (usually) be ignored (not too sure how it is
calcuulated but 4Gb phys log seems a bit excessive !!).
Best to just monitor phys log usage (onstat -l |head -10, %used) and try to
keep it below 25%. I've got a 900 Gb database with 450 concurrent OLTP
sessions and have a physlog of 488 Mb (IDS 9.4) but am pushing to 1 Gb on
IDS 11.7 after upgrade. (no idea if this is reasonable till after we get
some users on it !!)
Keith
On 22 July 2014 11:43, Dirk Moolma.... <Dirk.Moolman@mtn.co.za> wrote:
> IDS 11.70.FC8
>
> AIX 1 6 00CC96664C00
>
> I received the following message in the online.log file ..... is it
> something
> to be concerned about ?
>
> Based on the current workload, the physical log might be too small
> to accommodate the time it takes to flush the buffer pool during
> checkpoint processing. The server might block transactions during
> checkpoints.
> If the server blocks transactions, increase the physical log size to
> at least 4005820 KB.
>
> ________________________________
>
> NOTE: This e-mail message is subject to the MTN Group disclaimer see
> https://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--20cf303345d755ad0304fec62a4b
Dirk: It indicates that during some period of time the transaction workload was such that if it continues/continued would likely cause physical log overflows and so early checkpoints. You should monitor the physical log and look at your checkpoint history. If you are not getting any PLOG checkpoints and you do not see the physical log getting close to 75% full shortly before a scheduled checkpoint then don't worry about it, this was probably triggered by a brief transaction spike and not a problem. If you are getting PLOG checkpoints or physical log usage is getting close to causing one during peak load times, then you probably should increase the size of the physical log at some point. Art Art S. Kagel, Principal Consultant ASK Database Management Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on 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 Tue, Jul 22, 2014 at 6:43 AM, Dirk Moolma.... <Dirk.Moolman@mtn.co.za> wrote: > IDS 11.70.FC8 > > AIX 1 6 00CC96664C00 > > I received the following message in the online.log file ..... is it > something > to be concerned about ? > > Based on the current workload, the physical log might be too small > to accommodate the time it takes to flush the buffer pool during > checkpoint processing. The server might block transactions during > checkpoints. > If the server blocks transactions, increase the physical log size to > at least 4005820 KB. > > ________________________________ > > NOTE: This e-mail message is subject to the MTN Group disclaimer see > https://www.mtn.co.za/SUPPORT/LEGAL/Pages/EmailDisclaimer.aspx > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c35704726de304fec640bf