>> Under what condition will a query generate redo?
>
> When there's delayed blocked cleanout.

> And a select for update

My test in 10.2.0.4 shows that a select for update itself does not generate redo (as seen in 
v$mystat or v$sesstat). But a subsequent rollback or commit does.

In contrast, the first time you establish a remote transaction (including a remote query, e.g. 
select * from dual@remotedb), your session's redo size statistic increases. Subsequent queries 
using the same DB link will not generate redo. In fact, it's really the recursive SQL modifying 
data dictionary tables that generates redo. But it *appears* to be generated by your query in the 
user-level SQL.

In addition, if you turned on audit of select, a query appears to generate redo.

A query on dba_extents will take at least one TT (tablespace) lock. But this query will *not* 
generate redo.

(http://www.itpub.net/thread-1300346-1-1.html)