Re: Can't get INSERT /*+ APPEND */ to indicate direct load in execution plan.....
Date: Wed, 02 Nov 2011 16:47:26 +0100
this is quite useful bit of information.
So now we know that Mark's insert was performed in serial :)
P.S. What's SQL Monitor and does it require a separate license?
On 02/11/2011 15:47, Greg Rahn wrote:
> The way to tell if the insert is using PDML or not is by the placement
> of the LOAD row source: If it is above the PX COORDINATOR line, its
> all done by the QC. If below the PX COORDINATOR row source, its done
> by the PX servers. SQL Monitor will show this nicely on the Parallel
> tab, just expand the tree/nodes and look at the amount of work done.
> On Wed, Nov 2, 2011 at 12:38 AM, Radoulov, Dimitre
> <cichomitiko_at_gmail.com> wrote:
>> Thanks Greg,
>> could you please clarify the following:
>>>> It's still using PX ...
>> Yes, I see that parallel execution is involved.
>> I wanted to know if the *insert* part of the statement
>> was executed in parallel and where is the evidence for that.
>> I believe that only the select part execution mode is visible
>> in the plan output, but I may be wrong, of course.
>> My point was that as far as Mark's first mail is concerned,
>> we see that conventional load is used, but we can only guess
>> if the insert into table TEST is in serial mode or not,
>> am I missing something?
>> On Wed, Nov 2, 2011 at 7:58 AM, Greg Rahn<greg_at_structureddata.org> wrote:
>>> The reason you see the NO_PARALLEL in the outline because you have not
>>> calibrated your IO for auto DOP to work as shown by the Notes section.
>>> After doing so you should see the SHARED directive show up in its
>>> place. It's still using PX and you can see this from looking at
>>> v$pq_tqstat from the same session you ran the query. One can also
>>> look at the SQL Monitor Report as well.
>>> Using scott.emp might be a poor example because there is only 1
>>> granule for the table scan so only 1 PX server gets work.