Comments on: SQL*Net break/reset to client

By: Tanel Poder

Tanel Poder — Wed, 26 Aug 2009 06:07:02 +0000

Tere Kaido,

Yes, these waits are not idle as these cause extra work to be done inside the database. If wait interface says its significant, then something should be done about it.

Instead of polling queues in a loop – you should poll in waiting mode, so instead of the error you just wait until something appears in the queue. Not sure how well this goes together with your application architecture though.

Another option is, in case you are willing to (and can) change code you could wrap this dequeue operation into a pl/sql block or function which catches the exception if its raised and just returns a different return code (via return or bind variable) when there was nothing in the queue.

This makes the break/reset wait event go away – but it may just shift the bottleneck elsewhere that instead of braking 100 times per second you will have just the PL/SQL call overhead instead.

By: Kaido

Kaido — Tue, 25 Aug 2009 06:27:00 +0000

So, I believe this is not an idle wait? Oracle SOAsuit produces very high amouont of this wait event on my production system. I created the servererror trigger — and within minutes, there was more than 5000 rows in log table. The reason is, that AQ dequeue method, returned an error message, that queue was empty. This means, that SOAsuit (compiled java pcode) does not handle this error. ADDM tells me: “Wait event “SQL*Net break/reset to client” in wait class “Application” was consuming significant database time.” Impact% 30-60. Should I be really worried about this event?

By: Steve

Steve — Mon, 14 Apr 2008 16:07:03 +0000

Thanks Tanel for the suggestion.

Steve.

By: tanelp

tanelp — Mon, 14 Apr 2008 14:57:27 +0000

Thanks Jeremy, you’re right.. I think I’ll write a disclaimer to my blog that I only provide bits and pieces of information – but using it still requires the reader’s brain! :)

By: tanelp

tanelp — Mon, 14 Apr 2008 14:54:49 +0000

Steve, if the table has only one row and everybody is trying to update that row (some kind of locking, right?) then you can’t really split it up to multiple blocks.

Depending on what operations you serialize using that single-row lock, you may be able to break it down to multiple locks (each protecting a different operation or part of the structure) and have higher throughput like that.

I recommend you to check DBMS_LOCK user defined locks, you may be able to do your serialization better using that… or if you need better flexibility, then Advanced Queueing is for you.

By: Jeremy Schneider

Jeremy Schneider — Sat, 12 Apr 2008 16:20:08 +0000

Great post! (Although I hope that nobody reads this and thinks they should start adding “exception when others then null” to their code…)

By: Steve

Steve — Thu, 10 Apr 2008 20:05:37 +0000

We have a similar problem with top 2 wait events being bb waits and sqlnet break/reset to client event. We figured the cause being the sql something like this “select * form table where… for update nowait;” This table has one row in it. sessions not able to get locks returned “resource busy” message back to client triggering sqlnet break/reset event. Handling the exception at stored procedure worked out really well. however, wondering how to reduce the bbw waits on nowait sql. p3 value being 1 and table is in ASSM auto mode, 10gr2. Any ideas would be appreciated.

Steve

By: John Hallas

John Hallas — Thu, 10 Apr 2008 14:56:24 +0000

Very good blog entry, put together quickly as well.

By: tanelp

tanelp — Thu, 10 Apr 2008 13:54:08 +0000

Nice! I guessed right :)

Thanks for the info, Anjo

By: Anjo Kolk

Anjo Kolk — Thu, 10 Apr 2008 13:42:40 +0000

Yep, first the break is done to notify the client side to stop sending data, then the reset is done on both sides to cleanup the state and to resume from there. The next message to client is I think an “Successful completion of the ” of the call. So the client thinks that we are still talking.