Re: Re[4]: Long checkpoints (LRU_xxx_DIRTY/LRUS)--NETTYPE va

Hi, > Thanks already for your recommendations ! Further details follow : > > PHYSICAL LOG OVERFLOW : > ------------------------ > We never have checkpoints caused by the physical log being 75% full as > our physical log is so big (250M). Physical log overflows can happen > and can be very dangerous when the checkpoint generated at 75% of the > physical log is not completed yet by the time the physical log is 100% > filled (this can happen as threads in a critical section can continue > at the moment the 75% threshold is reached, so before the checkpoint > starts). I was last week on the "Internal Architecture and Advanced > Administration" course and this briefly described which unpleasant > things can happen if you encounter such a physical overflow situation. OK. I've never heard of it happening before, but I haven't really worked on that size and type of system before either! > AFF_NPROCS/AFF_SPROCS both 0 : > ------------------------------ > I've never tried to use affinity although it is supported on our SUN > platform. Apparently, affinity does not stop other processes to use > these processors to which I have bound the CPU VPs (oninits). Do you > think the benifits are bigger than the drawbacks ? I could give it a > try ! Do you suggest to bind all 16 CPUVPs or only a subset of them ? Defnitely worth a try. Start with one and increase it over time. See what happens. But I guess you could also just bang the whole lot in. :-) Regarding the LOGBUFF, what kind of logging mode are you using? -- "I'll Be Back" Obnoxio ************************************************ Sane? Hell, if I was sane, why would I be here? Get Your Private, Free Email at http://www.hotmail.com