"kksfbc child completion"

I've run into the wait "kksfbc child completion" a few times over the past but found very little written about it. I don't have an explanation, but I have something that might be as good - a way to reproduce it. By being able to reproduce I at least test theories about it.
I ran a tight loop of

insert into t value(1);

See anything strange? I put "value" instead of "values" so the insert errored out. Thus causing parsing every execute. So this wait seems to be related to parsing. Could run further tests by correcting and adding a different litteral value to the insert to see what kind of waits might result.

Another tell tale sign that there was an error was that I also recieved "SQL*Net break/reset to client" which is a sign of an error in the sql statements that the application is attempting to execute.

Concurrency Testing

One complaint I've heard of a number times is how code gets tested with one user and it runs fine and then gets put into production and only to hit a huge performance snafu.

I'm putting together a demo on this kind of situation and was thinking of some examples. One example that came to mind is a Nesedt Loops join that hammers the root node of an index. Might work fine for one user, but when multiple users start running it, the query runs into cache buffers chains latch issues with the high concurrency access to the index's root block which might be resolved by doing a hash join or moving the lookup table to a hash cluster for example.

Will put together demos of other examples.

Here is the first example of commiting every loop in a 100 row insert loop verses commiting once:

http://www.youtube.com/watch?v=2UUizGbjCkw

To Pie Chart or not to Pie Chart

I've always had a natural aversion to pie charts. Pie charts seem all the less apealing when compared to bar charts.  I've wondered if it was just my preference or if there was some objective basis for this bias. Well, turns out there is a basis. Here are 4 reasons that I want to expand on in this blog:

   1. More dificult to order sizes with a pie chart verses a bar chart

   2. The Pie Chart  shows relative values but on absolute

   3. Messy to correlate anything but simplest lables to pie slices

   4. If there is an "other" group, it often looks like the largest when it's just a grouping of the smallest slices.

http://en.wikipedia.org/wiki/Pie_chart

http://sites.google.com/site/embtdbo/graphics/pie-charts

   

SQL*Net break/reset to client

Another problematic wait event in Oracle is "SQL*Net break/reset to client". This wait event typically happens when there is something syntactically wrong with an SQL statement but can happen when there are errors such as a constraint violation.

The problem with analyzing this wait event is that since the query had an error the associated SQL is not kept by Oracle. It's thrown away so it can't be looked up in v$SQL for example.

The only way to find out the SQL statement is to trace the problem session before the wait occurs. We'll that's easier said than done. Mostly I want to investigate after a problem and I certainly want to avoid tracing sessions willy nilly on my system.

One idea, which I have to investigate is getting the

  PREV_SQL_ADDR                                    

 PREV_HASH_VALUE

and tracking down this SQL. If that is successful then it maybe a means at least to see where the application was just before the error/wait occured, with the idea being that the next SQL statement in the applicaiton is the problem.

Of course this is not of much use if the application has no syncronisity between which statements are called, but first I want to investigate whether this is an option or not at all.