Re: Too-frequent checkpoints [resolution]

I'm indebted to the half dozen of you folks who took the time to respond and offered excellent advice! Using their combined insights, here's the way I was able to resolve the problem... CKPTINTVL was fine at 300 I increased PHYSFILE from 1000 to 4000 after finally figuring out that the physical log filling to 75% was the main cause of the frequent checkpoints [but see below]. This decreased the frequency of checkpoints...though the checkpoints tended to last longer. LRU_MAX_DIRTY was then decreased from 60 to 20, along with LRU_MIN_DIRTY from 50 to 10. This decreased some of the work that had to be done during each checkpoint, shortening the checkpoint durations. Those changes were all necessary, but--as several folks urged--I also needed to look what program(s) were doing which cause the problem in the first place. As it turned out, the problem was triggered by a "cleanup" program deleting older records from the database once an hour....typically removing 20,000 to 30,000 records from each of two tables every hour. [The data base itself is a real-time billing application; both those tables are constantly rows inserted at a rate of 5 to 10 records per second, 24 hours/day. Running that cleanup program at regular intervals is a necessary evil.] I wasn't able to do much with the cleanup program itself. But... since the tables were not clustered, I clustered them by time stamp. Why? David Henseler reminded me that physical logs are written in complete pages. Deleting 30,000 or so records throughout these large tables was generating large numbers of physical log page writes...many perhaps involving only one record per page. Clustering the tables in the order the records arrive essentially means that the cleanup program ends up deleting pages full of old records, minimizing physical log page writes. Thanks again to all those who kindly shared their expertise with me!