Comments on: Wrong Information about Temporary Space Usage in V$SQL_PLAN_STATISTICS_ALL and DBMS_XPLAN Output

By: PGA Memory – The Developer’s Secret Weapon for Stealing All of the Memory in the Server « Charles Hooper's Oracle Notes

Mon, 18 Jan 2010 06:15:37 +0000

[...] Let’s see, almost 25 minutes to execute the SQL statement, a total of roughly 425MB of memory was used during one pass workarea executions (but from our earlier output, not all of that memory was in use at the same time) and the SORT ORDER BY operation used 11M of TEMP tablespace space… but is that 11MB, or is it 11 million KB, or is it 11,534,336 KB (2^20 * 11 KB)? Remember earlier we found “that the temporary segment size in the TEMP tablespace is about 11.14GB”, so that 11M means 11,534,336 KB, or about 11GB. OK, that was slightly confusing, but we are not done yet. (Side note: the author of the book “Troubleshooting Oracle Performance” commented on the Used-Tmp column here.) [...]

By: Christian Antognini

Christian Antognini — Fri, 29 May 2009 18:33:01 +0000

Rachid

Please notice that TempSpc is “only” the estimated amount of temporary space used by an operation. For this reason, I find it not very interesting…

Cheers,
Chris

By: Rachid

Rachid — Thu, 28 May 2009 07:55:20 +0000

Good news ;-) The autotrace command shows correct values

Execution Plan
----------------------------------------------------------
Plan hash value: 961378228

-----------------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |  1000 |   980K|       |   247   (1)| 00:00:03 |
|   1 |  SORT ORDER BY     |      |  1000 |   980K|  2008K|   247   (1)| 00:00:03 |
|   2 |   TABLE ACCESS FULL| T    |  1000 |   980K|       |    33   (0)| 00:00:01 |
-----------------------------------------------------------------------------------

Rachid

By: Tanel Poder

Tanel Poder — Sat, 09 May 2009 18:20:34 +0000

Well all this keeps us busy, doesn’t it

By: Christian Antognini

Christian Antognini — Wed, 06 May 2009 07:53:58 +0000

Ciao Alberto

It goes without saying that I fully agree with you. They have a problem with the quality of the support… I hope that they will adress it soon or later. In the mean time, we have to struggle with it.

Cheers
Chris

By: Alberto Dell'Era

Alberto Dell'Era — Wed, 06 May 2009 07:39:05 +0000

Ciao Chris,

great to know, but a sane process would not need to open a bug AND then blog about it AND then have an “Oracle employee” notice it … … it should be enough to open a bug, and frankly, I would also expect a “thank you!” note from Support for taking the time to log a bug “for the benefit of Oracle and its community”.

By: Christian Antognini

Christian Antognini — Tue, 05 May 2009 09:23:53 +0000

Ciao Alberto

I try to not give up!

An example: right now the oldest SR I have in Metalink, ups… My Oracle Support (and the name explicitly says that they provide support), is dated “05-SEP-07 18:49:03″. The associated bug spent the whole 2008 hibernated and, who knows why, they resumed it in 2009. Few minutes ago when I checked the date I looked at the bug and I saw “*** 05/04/09 10:37 am *** (CHG: FixBy->11.2) “. Yeah! I’m looking forward to get the next beta release to check the fix. BTW, this is also a bug with V$SQL_PLAN_STATISTICS_ALL… the one that I mention at page 233 in TOP. So, expect a post to explain the problem and says that it has been fixed

Cheers,
Chris

By: Alberto Dell'Era

Alberto Dell'Era — Tue, 05 May 2009 09:00:48 +0000

I feel your pain – I did quit submitting bug reports to Support such as the one you are describing, that I used to submit in an attempt to be “nice to the Oracle ecosystem”, several years ago, since I’ve noticed that they are not liked by them – they are almost always closed or ignored (at least mine). It is sad since that means that a lot of inconsistencies are left in the product – this one is a good example, it would take a few minutes to be fixed, with almost zero risk, for the benefit of everyone. Amen.