Thanks for the demonstration. I’ve often wished that Oracle would introduce a “fetch count” statistic to match the parse count and execute count. (Splitting recursive calls into sys-recursive and user-recursive would be nice as well).

To answer that question indirectly – which is the higher load: 1,000 transactions that update one row each, or 100 transactions that update 10 rows each ?

What if each type of transaction does a 10MB tablescan, what if the smaller transaction maintains 10 indexes per row, while the large transaction doesn’t maintain any indexes ?

There are four or five key resources and measures that have different significance to different people. The same single measure will not be appropriate for everyone.

[oracle@DB1 ~]$ cat tst.sql 
define row_cnt = &1
define opt_lvl = &2

exec dbms_workload_repository.create_snapshot;

alter session set plsql_optimize_level = &opt_lvl;

begin
  for rec in (with a as (select null from dual connect by level <= 1e5) select null from a,a where rownum <= &row_cnt) loop
    null;
  end loop; 
end;
/

exec dbms_workload_repository.create_snapshot;

define num_days = 1;
define  report_type  = 'text';
define  report_name  = '';

column inst_num   new_value inst_num  format 99999;
column inst_name  new_value inst_name format a12;
column db_name    new_value db_name   format a12;
column dbid       new_value dbid      format 9999999999;

select d.dbid            dbid
     , d.name            db_name
     , i.instance_number inst_num
     , i.instance_name   inst_name
  from v$database d,
       v$instance i;

column begin_snap new_value begin_snap  format 99999;
column end_snap   new_value end_snap    format 99999;

select max(snap_id) end_snap, max(snap_id)-1 begin_snap from dba_hist_snapshot;

@@?/rdbms/admin/awrrpti

exit

[oracle@DB1 ~]$ sqlplus / as sysdba @tst 1000000 0 | grep recursive
recursive calls                           1,001,075      156,736.3      91,006.8
recursive cpu usage                             467           73.1          42.5
[oracle@DB1 ~]$ sqlplus / as sysdba @tst 1000000 2 | grep recursive
recursive calls                              11,053        9,264.9       1,004.8
recursive cpu usage                              92           77.1           8.4
[oracle@DB1 ~]$ sqlplus / as sysdba @tst 0 0 | grep recursive
recursive calls                               1,084        1,358.4          98.6
recursive cpu usage                              58           72.7           5.3
[oracle@DB1 ~]$

I am glad you touched on this topic since I was looking at my AWR last week and wondering what is my peak load in my system….so my question to you is …..can I use these stats ” Transactions per sec.” to determined when the peak load is on my production system?

That is : for commits, we can trust the statistics user_commits but for rollbacks we had better to trust rollback changes – undo records applied

I got there in the end (and even got the . changed to a ,).
I’ve take the ceiling() of the lower and floor() of the higher value, though.

I can’t quote names and versions off the top of my head, but various middle-tier tools handling connection pooling will (or used to) “isolate” the work done by each request by issuing a rollback extremely frequently.

Great, isn’t it.
You can spend an awful lot of your time deliberately rolling back – but not quite far enough – and the “obvious” statistics tells you nothing about it. As Valentin points out, you have to cross-check with “rollback changes – undo records applied” to get an idea of how much work you are doing while rolling back. (And, of course, the rolling back from “write consistency” – as well as various other things – shows up in that statistic as well.)