'checkpoint speed' is an application choice, but far too many installations allow default parameters or age old file sizes to determine this.
I think 10 seconds is too fast except for extreme cases where the archived logs are shipped to a remote system to keep it up to date within 10 seconds.
Why not aim for 10 minutes or so?
Oracle allows you to set it by time, and space. Relevant init.ora params:
#LOG_CHECKPOINT_INTERVAL
#LOG_CHECKPOINT_TIMEOUT
#LOG_CHECKPOINTS_TO_ALERT
and with 9i, more interesting perhaps: MTTR= mean time to recover. Read all about it!
Often overlooked is the REDO file size.
Once it is full, a checkpoint will occur, and a new archive created.
Your choice there depends on the log block write speed. Let's say you write at 1mb/sec, and you accept my goal of 10 minutes. That would mean your redo log file needs to be sized at 10*60*1=600MB. If your redo log write speed was 10MB/sec (a mighty busy system!), you'd need 6GB redo logs for them not to control checkpointing.
For benchmarks we often play with 2 - 10 GB redolog to make sure they do not control the checkpoints, but we do with other means.
For production sites I suppose something in the 200MB - 1GB range often works, but 5MB or 10MB does not work well.
Anyway, this is really all Oracle stuff. Nothing much to do with Tru64. Just google for +oracle +"checkpoint interval" or such and you'll find tons of advice, some better than other. Or just check the Oracle Concepts or Tuning books? (What a concept!)
Hope this helps some,
Hein.
