Comments on: A-Rows and DML Statements http://www.antognini.ch/2009/07/a-rows-and-dml-statements/ Thu, 17 May 2012 06:56:24 +0000 hourly 1 By: Blogroll Report 24/07/2009 – 31/07/2009 « Coskan’s Approach to Oracle http://www.antognini.ch/2009/07/a-rows-and-dml-statements/#comment-218 Blogroll Report 24/07/2009 – 31/07/2009 « Coskan’s Approach to Oracle Sat, 01 Aug 2009 01:54:05 +0000 http://antognini.ch/?p=444#comment-218 [...] Christian Antognini -A-Rows and DML Statements [...] [...] Christian Antognini -A-Rows and DML Statements [...]

]]> By: Timur Akhmadeev http://www.antognini.ch/2009/07/a-rows-and-dml-statements/#comment-217 Timur Akhmadeev Fri, 31 Jul 2009 13:26:55 +0000 http://antognini.ch/?p=444#comment-217 >I mean, neither an average nor a sum would be good… Well, sum or sum and avg would be better than nothing. >I mean, neither an average nor a sum would be good…
Well, sum or sum and avg would be better than nothing.

]]> By: Christian Antognini http://www.antognini.ch/2009/07/a-rows-and-dml-statements/#comment-216 Christian Antognini Fri, 31 Jul 2009 12:37:02 +0000 http://antognini.ch/?p=444#comment-216 Hi Timur Yep, execution plans with PX are even worse ;-) But, honestly, aggregating execution statistics coming from several processes is also not always easy or even meaningful. For example, while it is not a problem to provide the total number of rows returned by a given PX operation (a sum would be ok), what to do with statistics like “A-Time”? I mean, neither an average nor a sum would be good... Cheers, Chris Hi Timur

Yep, execution plans with PX are even worse ;-) But, honestly, aggregating execution statistics coming from several processes is also not always easy or even meaningful. For example, while it is not a problem to provide the total number of rows returned by a given PX operation (a sum would be ok), what to do with statistics like “A-Time”? I mean, neither an average nor a sum would be good…

Cheers,
Chris

]]> By: Timur Akhmadeev http://www.antognini.ch/2009/07/a-rows-and-dml-statements/#comment-215 Timur Akhmadeev Fri, 31 Jul 2009 11:13:49 +0000 http://antognini.ch/?p=444#comment-215 Christian, thanks for the info. I guess the most difficult part associated with the change was handling statement restarts. Since restarts might happen during UPDATE which result in partial rollbacks one or more times per execution, it is no longer possible to do just an increment of associated runtime statistic in fixed views on call to update subroutine. One more critical case where Oracle does not provide runtime execution statistics is PX: <pre> -------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------------------------------- | 1 | SORT AGGREGATE | | 1 | 1 | 1 |00:00:04.57 | | 2 | PX COORDINATOR | | 1 | | 2 |00:00:04.55 | | 3 | PX SEND QC (RANDOM) | :TQ10001 | 0 | 1 | 0 |00:00:00.01 | | 4 | SORT AGGREGATE | | 0 | 1 | 0 |00:00:00.01 | |* 5 | HASH JOIN | | 0 | 10M| 0 |00:00:00.01 | | 6 | PX BLOCK ITERATOR | | 0 | 10000 | 0 |00:00:00.01 | |* 7 | TABLE ACCESS FULL | T | 0 | 10000 | 0 |00:00:00.01 | | 8 | PX RECEIVE | | 0 | 10000 | 0 |00:00:00.01 | | 9 | PX SEND BROADCAST | :TQ10000 | 0 | 10000 | 0 |00:00:00.01 | | 10 | PX BLOCK ITERATOR | | 0 | 10000 | 0 |00:00:00.01 | |* 11 | TABLE ACCESS FULL| T | 0 | 10000 | 0 |00:00:00.01 | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - access("T1"."ID"="T2"."ID") 7 - access(:Z>=:Z AND :Z<=:Z) 11 - access(:Z>=:Z AND :Z<=:Z) </pre> Christian,

thanks for the info. I guess the most difficult part associated with the change was handling statement restarts. Since restarts might happen during UPDATE which result in partial rollbacks one or more times per execution, it is no longer possible to do just an increment of associated runtime statistic in fixed views on call to update subroutine.
One more critical case where Oracle does not provide runtime execution statistics is PX:

--------------------------------------------------------------------------------------
| Id  | Operation                 | Name     | Starts | E-Rows | A-Rows |   A-Time   |
--------------------------------------------------------------------------------------
|   1 |  SORT AGGREGATE           |          |      1 |      1 |      1 |00:00:04.57 |
|   2 |   PX COORDINATOR          |          |      1 |        |      2 |00:00:04.55 |
|   3 |    PX SEND QC (RANDOM)    | :TQ10001 |      0 |      1 |      0 |00:00:00.01 |
|   4 |     SORT AGGREGATE        |          |      0 |      1 |      0 |00:00:00.01 |
|*  5 |      HASH JOIN            |          |      0 |     10M|      0 |00:00:00.01 |
|   6 |       PX BLOCK ITERATOR   |          |      0 |  10000 |      0 |00:00:00.01 |
|*  7 |        TABLE ACCESS FULL  | T        |      0 |  10000 |      0 |00:00:00.01 |
|   8 |       PX RECEIVE          |          |      0 |  10000 |      0 |00:00:00.01 |
|   9 |        PX SEND BROADCAST  | :TQ10000 |      0 |  10000 |      0 |00:00:00.01 |
|  10 |         PX BLOCK ITERATOR |          |      0 |  10000 |      0 |00:00:00.01 |
|* 11 |          TABLE ACCESS FULL| T        |      0 |  10000 |      0 |00:00:00.01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("T1"."ID"="T2"."ID")
   7 - access(:Z>=:Z AND :Z< =:Z)
  11 - access(:Z>=:Z AND :Z< =:Z)
]]>