He/She is trying to demonstrate a classic issue with performance tuning...
knowing what has happened during the interval that you are trying to
monitor.
If one did not know what oracle was doing ( i.e. offering concurrency etc)
then one might spend a long time trying to work out the reason for the 101
in the fetch.
<zhangguoping_at_boco.com.cn> wrote in message
news:b61k7t$1k2i$1_at_mail.cn99.com...
>
> **
> The next example illustrates the read consistency trap. Without knowing
that
> an
> uncommitted transaction had made a series of updates to the NAME column it
> is
> very difficult to see why so many block visits would be incurred.
>
> Cases like this are not normally repeatable: if the process were run
again,
> it is
> unlikely that another transaction would interact with it in the same way.
> SELECT name_id
> FROM cq_names
> WHERE name = ¡¯FLOOR¡¯;
> call count cpu elapsed disk query current rows
> ---- ----- --- ------- ---- ----- ------- ----
> Parse 1 0.10 0.18 0 0 0 0
> Execute 1 0.00 0.00 0 0 0 0
> Fetch 1 0.11 0.21 2 101 0 1
>
>
> how to explain the example??
>
> thks
>
>
Received on Fri Mar 28 2003 - 08:31:51 CST
