X$KSFQP is the X$ table that the V$BACKUP_SYNC_IO and V$BACKUP_ASYNC_IO views are based on. It holds one row per file involved in a current or recent RMAN backup or restore operation, and an aggregate row for each operation. The latch of the same name is of course used to protect the data structure.

The very poor performance of this latch in your case is clearly due to the longholds at ksfqpcln. The most likely explanation is that the holder is having difficulty obtaining a higher level latch, probably the shared pool or large memory latch. If you are not already doing so, use the large pool for I/O buffers. If you are backing up large numbers of small datafiles, try using FILESPERSET to limit concurrent demand for the X$KSFQP latch.

Our RMAN process is getting latch free wait events. I have deteremined that the latch X$KSFQP is the latch that is always being waited on. From V$LATCH I get the following information:

    SQL> select gets,misses,spin_gets,sleeps from v$latch where name = 'X$KSFQP';

	  GETS     MISSES      SPIN GETS     SLEEPS
    ---------- ---------- -------------- ----------
	 18347       1396             13      14837

    PARENT_NA WHERE      NWFAIL_COUNT SLEEP_COUNT WTR_SLP_COUNT LONGHOLD_COUNT
    --------- ---------- ------------ ----------- ------------- --------------
    X$KSFQP   ksfqpaa               0           0            50              0
    X$KSFQP   ksfqpax               0          15            82             11
    X$KSFQP   ksfqpu                0          13           146             13
    X$KSFQP   ksfqpcln              0       14858         14608           9327