April 2008

I’m somewhat surprised to see a lack of Oracle blogging reaction to the recent post on The Daily WTF which goes into great detail on a case of SQL injection.  Maybe we’ve either become tired of it or we assume that “my systems don’t do that!”.

So, how do you audit or track if your system is being hit by injection?  How would you detect it?  Assume you’re “just a DBA” — and no one tells you about applications being deployed that talk to the database.  Is there a way you could tell just by looking from within the database?  What kind of assumptions would you make?

There was a question in Oracle-L mailinglist recently, regarding excessive SQL*Net break/reset to client waiting by a session.

A quote is below:

We are seeing an insert statement reporting SQL*Net break/reset to client as over 33% of its time.

On the face of it this event suggests network issues but nothing else backs this up as the cause.

So I looked at the Java code in question and a trace of one of the sessions.

What is happening is that an attempt is made to insert a row, most of the time a duplicate error results, the code catches this exception and does an update.

I was wondering if its the duplicate error and the exception handling which results in this wait event showing up.

My answer to that was following:

There was a question in Oracle-L mailinglist recently, regarding excessive SQL*Net break/reset to client waiting by a session.

A quote is below:

We are seeing an insert statement reporting SQL*Net break/reset to client as over 33% of its time.

On the face of it this event suggests network issues but nothing else backs this up as the cause.

So I looked at the Java code in question and a trace of one of the sessions.

What is happening is that an attempt is made to insert a row, most of the time a duplicate error results, the code catches this exception and does an update.

I was wondering if its the duplicate error and the exception handling which results in this wait event showing up.

My answer to that was following: