A mixed cursor is a combination of a keyset-driven cursor and a dynamic cursor. It is used when the result set is too large to reasonably save keys for the entire result set. Mixed cursors are implemented by creating a keyset that is smaller than the entire result set but larger than the rowset (the set of rows returned in a single fetch by a block cursor).
As long as the application scrolls within the keyset, the behavior is keyset-driven. When the application scrolls outside the keyset, the behavior is dynamic: the cursor fetches the requested rows and creates a new keyset. Note that after the new keyset is created, the cursor behavior reverts to keyset-driven within the keyset.
For example, suppose a result set has 1,000 rows and uses a mixed cursor with a keyset size of 100 and a rowset size of 10. When the first rowset is fetched, the cursor creates a keyset consisting of the keys for the first 100 rows. It then returns the first 10 rows, as requested.
Now suppose another application deletes rows 11 and 101. If the cursor attempts to retrieve row 11, it will encounter a hole because it has a key for the row but the row no longer exists. This is typical keyset-driven behavior. If the cursor attempts to retrieve row 101, the cursor will not detect that the row is missing because it does not have a key for the row. Instead, it will retrieve what was previously row 102.
The mixed cursor is difficult to use correctly because the sensitivity to data changes depends on the varying circumstances of keyset-driven and dynamic cursor behavior, as explained above. There is no particular implementing technology for a mixed cursor, and creating one is a difficult task.
If your application needs scrollable access to a very large set of records, and you can programmatically handle the different modes of data sensitivity, the mixed cursor may work for you.