Re: High number of created consistent read blocks when inserting into a LOB column from dblink

Hi Stefan,

Now it makes sense, thanks for the explanation. If I find out anything useful/interesting I'll post it.

Regards,
Jure Bratina

On Fri, Jan 13, 2017 at 9:59 AM, Stefan Koehler <contact_at_soocs.de> wrote:

> Hey Jure,
> at first you need to know how a fast C stack looks like (usually from
> opiodr() in your case) - this is why i suggested to insert only one row and
> capture this execution with SystemTap. Afterwards you can run your huge
> INSERT and wait until it burns up CPU - then you capture one row processing
> out of that huge INSERT with SystemTap and compare. Does this make sense
> to you?
>
> I am pretty sure that you may see several CR C function calls from one
> base C function - this would be the reason for your "CR blocks created"
> then.
> If you have the base C function, you can check for a specific tracing
> event of this (in Oracle code). You can get all of this from the Oracle C
> kernel
> code, but i am not allowed to post an instruction about this here (due to
> official Oracle licensing terms and conditions).
>
> Best Regards
> Stefan Koehler
>
> Independent Oracle performance consultant and researcher
> Homepage: http://www.soocs.de
> Twitter: _at_OracleSK
>
> > Jure Bratina <jure.bratina_at_gmail.com> hat am 12. Januar 2017 um 23:45
> geschrieben:
> >
> > Thanks for the feedback Stefan.
> >
> > One question though:
> > > P.S.: For isolating the issue it might be easier to insert only one
> row and check the difference.
> > The problem is that the issue of the INSERT slowing down and becoming
> more and more CPU intensive manifests gradually. At the beginning, things
> run
> > smoothly, CPU usage is low, the deltas of "CR blocks created" are
> relatively low. As the INSERT progresses, CPU usage rises, as do deltas for
> "CR
> > blocks created" among other statistics. I might be missing the point,
> but if I try to insert a single row and observe the difference, I'll do that
> > at the beginning of the transaction, i.e. when the process won't be
> heavily on CPU, so I wonder if I'll see why the process is so heavily on
> CPU and
> > building consistent read images of blocks?
> >
> > Regards,
> > Jure Bratina
>
>
>

--
http://www.freelists.org/webpage/oracle-l