A reader, July 23, 2020 - 1:51 pm UTC
thanks Connor,
below is similar query, which actual row is 18, but read requ's is 48M, read byte is 32TB. what's read requ mean at here?
Global Stats
=========================================================================================================
| Elapsed | Cpu | IO | Application | Concurrency | Cluster | Buffer | Read | Read | Cell |
| Time(s) | Time(s) | Waits(s) | Waits(s) | Waits(s) | Waits(s) | Gets | Reqs | Bytes | Offload |
=========================================================================================================
| 27209 | 11167 | 15307 | 29 | 0.00 | 706 | 1G | 48M | 28TB | 71.51% |
=========================================================================================================
SQL Plan Monitoring Details (Plan Hash Value=4181821043)
================================================================================================================================================================================================================================================================
| Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Write | Write | Cell | Mem | Activity | Activity Detail | Progress |
| | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | Reqs | Bytes | Offload | | (%) | (# samples) | |
================================================================================================================================================================================================================================================================
| 0 | SELECT STATEMENT | | | | | | 1 | | | | | | | | | | |
| 1 | TEMP TABLE TRANSFORMATION | | | | | | 1 | | | | | | | | | | |
| 2 | LOAD AS SELECT | | | | 1 | +3 | 1 | 2 | | | 1 | 32768 | | | | | |
| 3 | SORT AGGREGATE | | 1 | | 1 | +3 | 1 | 1 | | | | | | | | | |
| 4 | TABLE ACCESS STORAGE FULL | B_CTL | 1106 | 9 | 1 | +3 | 1 | 663 | | | | | | | | | |
| 5 | SORT ORDER BY | | 2 | 11294 | 21441 | +3 | 1 | 0 | | | | | | 886K | | | |
| 6 | UNION-ALL | | | | 21441 | +3 | 1 | 5237 | | | | | | | | | |
| 7 | FILTER | | | | 21441 | +3 | 1 | 5237 | | | | | | | | | |
| 8 | NESTED LOOPS | | 1 | 3923 | 21441 | +3 | 1 | 5254 | | | | | | | | | |
| 9 | NESTED LOOPS | | 1 | 3923 | 21441 | +3 | 1 | 11634 | | | | | | | | | |
| 10 | MERGE JOIN CARTESIAN | | 1 | 3921 | 21441 | +3 | 1 | 11634 | | | | | | | | | |
| 11 | PARTITION RANGE SINGLE | | 1 | 3919 | 21441 | +3 | 1 | 11635 | | | | | | | | | |
| -> 12 | TABLE ACCESS STORAGE FULL | INS_BAL | 1 | 3919 | 26224 | +3 | 1 | 11635 | 10713 | 10GB | | | 99.98% | 7M | | | |
| 13 | VIEW | | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 14 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D66A4_5019F60F | 1 | 2 | 1 | +3 | 1 | 1 | 1 | 32768 | | | | | | | |
| 15 | BUFFER SORT | | 1 | 2 | 21441 | +3 | 11635 | 11634 | | | | | | | | | |
| 16 | VIEW | | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 17 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D66A4_5019F60F | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 18 | PARTITION RANGE SINGLE | | 1 | 1 | 21441 | +3 | 16516 | 11634 | | | | | | | | | |
| 19 | INDEX UNIQUE SCAN | PK_INS_D | 1 | 1 | 26224 | +3 | 16516 | 11634 | 4670 | 146MB | | | | | 0.01 | gc cr multi block request (1) | |
| | | | | | | | | | | | | | | | | cell list of blocks physical read (1) | |
| 20 | VIEW | | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 21 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D66A4_5019F60F | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 22 | TABLE ACCESS BY LOCAL INDEX ROWID | INS_D | 1 | 2 | 26224 | +3 | 19328 | 5254 | 7521 | 235MB | | | | | 0.21 | gc current grant busy (2) | |
| | | | | | | | | | | | | | | | | log file switch completion (5) | |
| | | | | | | | | | | | | | | | | cell single block physical read (45) | |
| 23 | VIEW | | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 24 | TABLE ACCESS STORAGE FULL | SYS_TEMP_0FD9D66A4_5019F60F | 1 | 2 | 1 | +3 | 1 | 1 | | | | | | | | | |
| 25 | PARTITION RANGE SINGLE | | 1 | 1718 | 18056 | +119 | 5255 | 17 | | | | | | | | | |
| -> 26 | TABLE ACCESS STORAGE FULL FIRST ROWS | SRC_CUST | 1 | 1718 | 26227 | +3 | 5255 | 17 | 48M | 28TB | | | 71.51% | 7M | 99.79 | enq: KO - fast object checkpoint (22) | 100% |
| | | | | | | | | | | | | | | | | gc cr block 2-way (17) | |
| | | | | | | | | | | | | | | | | gc cr disk read (672) | |
| | | | | | | | | | | | | | | | | gc cr request (8) | |
| | | | | | | | | | | | | | | | | Cpu (9233) | |
| | | | | | | | | | | | | | | | | gcs drm freeze in enter server mode (1) | |
| | | | | | | | | | | | | | | | | reliable message (18) | |
| | | | | | | | | | | | | | | | | resmgr:cpu quantum (30) | |
| | | | | | | | | | | | | | | | | cell single block physical read (14130) | |
| | | | | | | | | | | | | | | | | cell single block read request (16) | |
| | | | | | | | | | | | | | | | | cell smart table scan (990) | |
| | | | | | | | | | | | | | | | | read by other session (1) | |
July 24, 2020 - 3:40 am UTC
"Read Requests" 48 million of them.
Activity in SQL Monitoring Report vs ASH
Narendra, July 15, 2024 - 10:25 am UTC
Hello Chris/Connor,
Hope you are doing well.
I am getting somewhat confused about data displayed in SQL Monitoring (Active) report as compared to ASH data for individual SQL executions. I am trying to investigate occasional slow performance of a SQL in a 19c database and started by looking at active SQL Monitoring reports for "Good" and "Bad" executions. Both reports suggested that most of the time is being spent on a specific step in execution plan with 70% value in Activity column.
However, when I queries ASH data for the same SQL execution, it is reporting most data captured for a completely different step in the execution plan.
How is this discrepancy possible? What am I doing wrong?
Thanks in advance,
July 22, 2024 - 1:13 pm UTC
¯\_(ツ)_/¯
There are many ways to get ASH and SQL monitoring reports; so if you are doing something wrong we've got very little to work on here...