Usage
Throughput_workload can provide a view of resource consumption by user or application. This view is most useful if you have first created WLM workloads corresponding to users or applications of interest.
Source
The data in throughput_workload comes from the table function mon_get_workload. Data is aggregated across all members for DPF and PureScale databases.
Columns
As with all repository views, the columns marked Y in the “Delta” column are actually two columns. For example, the metric described here as “rows_read” is actually a pair of columns “rows_read” which is a counter of how many rows have been read by activities assigned to this workload since the data server was activated and “rows_read_delta”, which tells how many rows have been read by activities assigned to this workload in the collection interval. For most purposes, the _delta version of the metrics is the most useful. The raw counter version is provided for completeness.
|
Column Name |
Delta |
Type |
Description |
|
dbconn_int |
n |
integer |
The internal ID for connection name. Included for completeness. |
|
dbconn_id |
n |
varchar(255) |
The string version of the connection name. When the user configures a database to be monitored, this is the name they specified for the connection. |
|
prev_collected |
n |
timestamp |
Timestamp of the start of the collection interval |
|
collected |
n |
timestamp |
Timestamp of the end of the collection interval |
|
delta_msec |
n |
bigint |
Number of milliseconds in the collection interval |
|
workload_name |
n |
varchar(128) |
Workload name serves as the row ID for this view. |
|
evaluationorder |
n |
smallint |
Connections are assigned to a WLM workload by evaluating each workload in order. This number is where this workload is positioned in the evaluation order. |
|
total_cpu_usec |
Y |
bigint |
Microseconds of CPU time consumed by the data server. Divide by 1,000,000 to scale this as seconds.
CPU consumption is a good indication of how much work is being done. All activities, including the overhead such as compiling queries and utility work are reflected in CPU consumption. Inefficiencies that increase the cost of doing business, such as excessive recompilation or lock contention can sometimes be seen by observing that CPU consumption has risen disproportionately to the amount of useful work that is being accomplished. |
|
act_completed_total |
Y |
bigint |
Activities completed by the data server. Activities typically correspond to a query. The number of activities completed is a measure of work accomplished. |
|
rows_read |
Y |
bigint |
Rows read is a good indication of how much work is being done by queries. Non-query work such as utilities and overhead for internal activities of the data server is largely excluded from rows read. So it is a better measure than CPU time for evaluating how much useful work is being accomplished. |
|
rows_modified |
Y |
bigint |
Rows modified includes updates and deletes of table data. Modifying data is much more expensive than reading it. |
|
rows_returned |
Y |
bigint |
This is the number of rows returned to the client by queries. Excessive amounts of data returned to the client can indicate a run-away query (cross product, missing filters) or abuse (people in the process of making unauthorized copies of the data) or even bad practices such as mis-guided attempts to pull large portions of the data into a spreadsheet or an application for post processing that could be better done inside the server. |
|
logical_reads |
Y |
bigint |
|
|
direct_reads |
Y |
bigint |
Direct reads are physical IO. In a well-tuned data server, most reads should be satisfied from the buffer pool, without the need of physical IO. Excessive direct reads is a common symptom of many performance problems. |
|
direct_writes |
Y |
bigint |
Direct writes are physical IO. In conjunction with direct reads, this gives a more complete picture of IO activity. In a well-tuned system, the data server will be able to accumulate multiple updates to a page to be written later as a single IO and will be able to spread write activity to minimize its impact. Some subtle problems might be visible as spikes in the rate of direct writes or as usually high levels of direct writes compared to the number of rows written. |
|
total_sorts |
Y |
bigint |
|
|
total_app_commits |
Y |
bigint |
|
|
total_commit_time |
Y |
bigint |
|
|
total_app_rollbacks |
Y |
bigint |
|
|
ext_table_send_volume |
Y |
bigint |
Relevant only for Big SQL |
|
ext_table_recv_volume |
Y |
bigint |
Relevant only for Big SQL |