Hi Guys,
I have not entered the forum for several days and that thread became a hit meanwhile :-)

I think we should separate the 2 cases here.
1) The log switch time checkpoint ( which is equal with the checkpoint caused by FAST_START_MTTR_TARGET, LOG_CHECKPOINT_INTERVAL or LOG_CHECKPOINT_TIMEOUT) That one is called incremental checkpoint and is mainly ment for limiting the instance roll forward phase time and hence minimizing the instance recovery time. It is also necessary to guarantee that the redo in an already filled log is no more needed, since the dirty blocks covered by this redo have been written to the disk.
2) The case described here, called "SLOW CHECKPOINT" (actually that's the first time I hear that term, but I like it) occures mainly because your db buffer cache have become too "dirty". When a block is dirty, it cannot be replaced by another block since that will cause lost of the modified immage. When a server process looks for a "clean" block to accure and replace its contents with a block needed from the disk, it cannot use dirty block and skips these blocks. If it happen that a specific number of blocks get scanned and skiped, because they are dirty, a treshold is reached and the DB Writer gets signalled to start writnig the dirty blocks, hence make them clean and let the server process to easily find a clean block to replace. Each time the server process skips a dirty block, this block is put to so called "checkpoint queue" and when the DB Writer is signalled, it writes out the blocks of the checkpoint queue to the disk. I do not know more details here, if DBWR writes the entire queue or just part of it. I belive Tamil have explained some details about that
There is one more event, causing the DB Writer to write. If I remember right it is if a specific percentage of the DB Buffer Cache become dirty but I am not sure about that and the details around it.
The case 2) has no much to deal with the redo. It is driven not by the redo stream, but by the scanned dirty blocks. The redo vectors, covering these blocks maight even not be consequent in the redo log file. I guess the slow checkpoint is somehow mentioned in the controlfile or redo stream or something, but that's not the key idea, since we cannot say that the slow checkpoint has specific position in the redo stream. Again, the redo vecrors could not be consequent at all

Warm Regards
Boris