Oracle then takes this nonrecursive statement and dynamically creates the SQL necessary to insert rows into the data dictionary tables, such as tab$ and col$. This dynamically created SQL is indeed recursive SQL. However, consider the SQL shown in the following trace file snippet.

The true Oracle definition of recursive SQL is any SQL with a depth greater than zero. Notice the preceding PL/SQL entry has a depth of zero (dep=0) and therefore is officially deemed nonrecursive SQL. However, notice what happens when the select statement is run 500 times:

The depth is one (dep=1), which means Oracle considers this application SQL, recursive SQL. Therefore, all its related CPU time will be recorded as both recursive SQL and server process SQL (statistics CPU used by this session), plus there will be some related parse time CPU consumption. So, as you can see, we cannot simply subdivide total Oracle CPU consumption into the three exclusive categories of parsing, recursive SQL, and everything else. This also provides an answer to why recursive CPU consumption can seem strangely high!