persec

NAME
DECLARATION
COLUMNS
NOTES
COPYRIGHT
SEE ALSO

NAME

rwlman − RWP*Load Simulator persec table and persec_a view

DECLARATION

The persec table and associated view save information about the count of executions of each procedure per second since the common start time.

create table persec
( runnumber number not null
, procno    number not null
, vname     varchar2(30) not null
, second    number not null
, scount    number
, wtime     number
, etime     number
, atime     number
, dtime     number
, constraint persec_pk primary key(runnumber, procno, vname, second)
)

create view persec_a
( runnumber
, pcount
, vname
, second
, scount
, wtime
, etime
, atime
, dtime
)

COLUMNS

runnumber

This is the number that uniquely identifies a run.

procno pcount

In single process runs, procno is zero, in multi-process runs, it gets its value from the Operating System process number of from the -p option to rwloadsim. In the aggregate view, persec_a, the total process count is in the pcount column.

vname

This is the name of the procedure being executed.

second

This is the whole second after the common start time.

scount

Total number of executions of the procedure in the latest second until the value of the second column. In the persec_a view the value is aggregated over all processes.

wtime

Total time spent getting a session from a pool for all executions of the procedure in the latest second until the value of the second column. In the persec_a view the value is aggregated over all processes. If not using a pool, the value is 0.

etime

Total time spent executing the procedure in the latest second until the value of the second column. In the persec_a view the value is aggregated over all processes.

atime, dtime

Application and database time spent executing the procedure in the latest second until the value of the second column. In the persec_a view the values are aggregated over all processes.

See runres(1rwl) for details about these two columns.

NOTES

The per second counts and times are like all other statistics held in memory buffers, and is flushed to the repository database just before rwloadsim termination. If the --flush-every option is used, the per second values will be flushed every so often, which can e.g. be used to show a running graph of the throughput. Note that --flush-every has overheads as mutexes are needed to protect the buffers and due to the execution of a sql statement against the repository database. If the value for the --flush-every option is larger than 1, each update to the repository will contain per second counts for multiple seconds.

COPYRIGHT

Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl