Creeping snapshots

One of the things I have noticed with Statspack is that the timing of the snapshots is not always what is intended. This is the result of the interval logic of dbms_job. The 'next' time a job is submitted is the 'interval' time from the end of the job, not from the beginning. So a snapshot that is scheduled to run at the top of each hour may begin to be scheduled to run later and later past the hour as the snapshot begins to take more time.

Here is a small example where a level 10 snapshot started running longer than 1 minute.

3192 12/05/06 11:00:06
3200 12/05/06 15:00:33
3208 12/05/06 19:00:57
3216 12/05/06 23:01:16
3224 12/06/06 03:01:38
3232 12/06/06 07:01:59
3240 12/06/06 11:02:27
3248 12/06/06 15:02:55
3256 12/06/06 19:03:19
3264 12/06/06 23:03:37
3272 12/07/06 03:03:58
3280 12/07/06 07:04:21
3284 12/07/06 09:04:32 <== In less than 2 days, the time had creeped by over 4 minutes
3285 12/07/06 09:30:04 <== Interval logic changed
3286 12/07/06 10:00:02
3287 12/07/06 10:30:06
3288 12/07/06 11:00:04
3297 12/07/06 15:00:06
3305 12/07/06 19:00:02
3313 12/07/06 23:00:03
3321 12/08/06 03:00:02
3329 12/08/06 07:00:04
3337 12/08/06 11:00:02

Here is a small example where a level 10 snapshot started running longer than 1 minute. The interval logic was changed to round the next time to the nearest 1/2 hour.
interval=>'trunc(sysdate, ''HH24'') + ((floor(to_number(to_char(sysdate, ''MI''))/30)+1)*30) / (24*60)'