Module TEST1 and TEST2 will run identical SQL statements
against the same base tables in identical optimizer 
environments, thus both of their execution statistics
will be aggregated under single child cursor and this 
child shall have module set to TEST1 since it was parsed first.

Module TEST3 runs a slightly different statement (with a 
comment), thus will be parsed under different cursor and will
have TEST3 as module name.



SQL> alter system flush shared_pool;

System altered.

SQL>
SQL> exec dbms_application_info.set_module('TEST1',null);

PL/SQL procedure successfully completed.

SQL> select count(*) from t;

  COUNT(*)
----------
     48288

SQL> exec dbms_application_info.set_module('TEST2',null);

PL/SQL procedure successfully completed.

SQL> select count(*) from t;

  COUNT(*)
----------
     48288

SQL> exec dbms_application_info.set_module('TEST3',null);

PL/SQL procedure successfully completed.

SQL> select /* blah */ count(*) from t;

  COUNT(*)
----------
     48288

SQL> exec dbms_application_info.set_module(null,null);

PL/SQL procedure successfully completed.

SQL>
SQL> select module, sum(buffer_gets), sum(disk_reads), sum(cpu_time), sum(elapsed_time)
  2  from v$sql group by module order by 4 desc;

MODULE               SUM(BUFFER_GETS) SUM(DISK_READS) SUM(CPU_TIME) SUM(ELAPSED_TIME)
-------------------- ---------------- --------------- ------------- -----------------
                                 9052             484        990820          10290040
SQL*Plus                         1719             120        345098            953314
TEST1                            1502            1345        120632           3231392
TEST3                             669             664         95953           1962723
TEST2                               0               0          4177              4177
EM_PING                             0               0             0                 0

6 rows selected.

-- As seen from above, TEST1 has roughly 2x more buffer gets than TEST3, so this indicates
-- that TEST2's buffer gets have been aggregated under TEST1 (some extra LIOs are probably because
-- on TEST1 excecution the data dictionary information about table T had to be read to dictionary 
-- cache - TEST2 and TEST3 could use cached information without any further LIOs
-- 
-- There is a library cache object with module TEST2 as well, but it isn't our SQL statement:

SQL> select address, sql_text, module from v$sql where module like 'TEST%' order by module;

ADDRESS  SQL_TEXT                                                               MODULE
-------- ---------------------------------------------------------------------- --------------------
67976270 BEGIN dbms_application_info.set_module('TEST2',null); END;             TEST1
67ECC44C select count(*) from t                                                 TEST1
679859E8 BEGIN dbms_application_info.set_module('TEST3',null); END;             TEST2
68875CC8 select /* blah */ count(*) from t                                      TEST3
67EE5908 BEGIN dbms_application_info.set_module(null,null); END;                TEST3

-- The only object with module as TEST2 is a call to dbms_application_info