The forum will be down for maintenance over the weekend of August 18-20, 2017. The forum will be shut down on the evening (EDT) of Friday, August 18. Downtime is unknown but may be up to two days. The forum will be restarted as soon as maintenance is complete.

The following evidence indicates that a checkpoint in SQL Anywhere Network Server Version 11.0.1.2276 will block a scheduled event from firing... either that, or it blocks the INSERT performed as the first statement inside that event.

Here are some snippets of code...

First, the debug_watch table used to record the event,

Second, the CREATE EVENT and INSERT statements,

Third, the rows in debug_watch showing the sudden five-second delay between inserts, and

Finally, the output from sa_server_messages() showing that the delay encompassed the Starting/Finished checkpoint timestamps.

When an event (or any connection) needs to run its sequence of statements, it must first be assigned to a server worker (aka a thread in the server) and that worker needs to acquire a connection to the database. By this I mean that the worker must be granted access to the database so that it can read and update the database data.

During the critical point of a checkpoint - the time in which the server is taking a consistent snapshot of the database and writing that snapshot data to disk - all workers are forbidden access to the database so that they do not make any changes to the in-memory contents while the snapshot is being taken.

So during the time that the checkpoint snapshot is being taken on a busy database - one with lots of on-going updates - the checkpoint can take several seconds (exact amount of time will depend on the number of recent updates and the speed of your I/O system) and all workers, including events, will momentarily stop what they are doing and wait until the checkpoint snapshot is complete.

In your particular example the checkpoint appears to have taken a little over five seconds and during that time you event will not have been allowed to run.

There are periods during any checkpoint in which no other operations are permitted; however, the durations of those periods are not predictable. Idle checkpoints are also different from explicit checkpoints since idle checkpoints allow new modifications to the database while all of the dirty pages are written out of the cache but explicit checkpoints do not. Idle checkpoints is actually a bad name and doesn't really mean that the server is idle -- they are the checkpoints that occur due to checkpoint urgency and max recovery time settings.

There can also be a lot of delays associated with a checkpoint before the "Starting checkpoint" ever shows up. See http://sqlanywhere-forum.sap.com/questions/1293/what-are-all-the-bad-things-which-happen-when-a-checkpoint-occurs/. However, it would seem that you are interested in delays occurring between the Starting & Finishing messages. Do you know if the long checkpoints you are having problems with are idle checkpoints or explicit ones? If they are idle, is the server unresponsive the whole time? If they are explicit, does the duration of the checkpoint approximately match the time it would take to write out the expected number of dirty pages in the cache?