Re: [SPAM] Re: 12170/ORA-12535/12537
- From: Jack van Zanen <jack@xxxxxxxxxxxx>
- To: kjped1313@xxxxxxxxx
- Date: Thu, 14 Oct 2010 16:16:33 +1100
Sounds like a network problem indeed.
Log a call with the helpdesk that you have been disconnected from your putty
session several times for no apparent reason. That should take some of the
heat of oracle and you get more cloud to deal with the network people.
Our firewall automagically disconnects sessions after a couple of minutes of
no activity so maybe turning down the value for sqlnet_expire_time might
help (we have set it to 1) as it forces communication (abusing DCD :-) )
The firewall rule in our case was not going to be changed, but it would be
better to have this disconnection rule removed if not required.
Good luck geting the info from your network guys though, but if they have
been copping it lately for network issues than most likely they have been
tweaking stuff to fix ,or attempt to fix, something.
Jack van Zanen
-------------------------
This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.
Thank you for your cooperation
On Thu, Oct 14, 2010 at 8:25 AM, Kellyn Pedersen <kjped1313@xxxxxxxxx>wrote:
> The network guys are a bit "gun shy" right now after their network
> being targeted for quiet some time now. Due to this, I am not getting any
> information on what changes might have been done to the network and I have
> no visibility into it myself... :(
>
>
> Kellyn
>
>
> ------------------------------
> *From:* "rajendra.pande@xxxxxxx" <rajendra.pande@xxxxxxx>
> *To:* kjped1313@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> *Sent:* Wed, October 13, 2010 2:11:47 PM
> *Subject:* RE: 12170/ORA-12535/12537
>
> Everything that I read here – to me indicates a network item.
>
> Have they introduced anything that has a timeout feature – powerbroker, any
> other pam module
>
> But that still does not explain these parameters and the values
>
> But then I am not fully conversant with how these work really to affect any
> timeouts
>
>
> ------------------------------
>
> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Kellyn Pedersen
> *Sent:* Wednesday, October 13, 2010 3:45 PM
> *To:* oracle Freelists
> *Subject:* 12170/ORA-12535/12537
>
>
>
> I am officially stuck and looking for some help, (please, please, please...
> )
>
>
>
> We have specific configurations in our sqlnet.ora files on all our database
> servers that have been present since the inception of Oracle at my company-
>
> SQLNET.EXPIRE_TIME =10
> SQLNET.INBOUND_CONNECT_TIMEOUT = 300
>
> INBOUND_CONNECT_TIMEOUT_LISTENER=300
> SQLNET.SEND_TIMEOUT = 300
> SQLNET.RECV_TIMEOUT = 300
>
> About five weeks ago, People started to complain about disconnects, (errors
> codes seen in the subject line above...) from two of our main dblinked
> databases and one of our duplicates failed due to 12170 errors, both in the
> 10.2.0.4 and 11.1.0.7 databases. I dug in and ended up having to put in the
> oddest values to get the disconnects to stop in the sqlnet.log and log.xml,
> along with making the users content with no more failures. It took another
> turn for the worse this last week and I had to "tweak" the numbers just a
> bit more to get a duplicate to complete from one production server to
> another. Here is the current configuration for the SQLNET.ORA files:
>
> SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF
> SQLNET.EXPIRE_TIME =100000000
> SQLNET.INBOUND_CONNECT_TIMEOUT = 300000
> SQLNET.SEND_TIMEOUT = 300000000
> SQLNET.RECV_TIMEOUT = 300000000
> DEFAULT_SDU_SIZE=8832
> INBOUND_CONNECT_TIMEOUT_LISTENER=0
>
>
>
> OK, we can all be honest here, the numbers I've used are outrageous, but
> they are the only thing that's stopped system processes from failing, where
> for the first week, it was 24X7 with complaints... and we all know the
> database is guilty until proven innocent!
>
> I have tested just about every app we have, traced back every disconnect,
> gone through every log back to user and even used my own connections as
> guinea pigs, testing out each parameter and each value with different system
> processes to come up with the final values.
>
>
>
> Since putting this into place, we continue to have one or two disconnects
> at the client side in the office per day. The disconnects do not calculate
> to what I have in the timeouts, which makes me wonder if I'm just fighting a
> losing battle here. It's not consistent across the client base, ether. I
> have only two developers that are losing connectivity consistently,from
> PL/SQL Developer, we're talking just a minute or so after they have gone
> inactive and many of them do not show up in the logs at all. They are using
> the network client TNS and SQLNet files, so they are using the files
> configured to match what I have on the server, nothing local that could be
> tripping them up. I myself was disconnected from every SSH session I had
> open just yesterday morning and no one seems to understand *HOW* it happened
> or what went wrong, but that they were putty sessions and that this has
> happened to these two users for their diconnects from time to time, (they do
> not use Putty sessions often...) makes me wonder some more...
>
>
>
> The network guys are saying they have changed nothing, but we just had a
> multi-server MySQL farm go in 5 weeks ago and the way we move and how much
> data we move, I have a hard time believing someone didn't sneak something in
> on them...
>
>
>
>
>
> Anybody have any ideas or recommendations? I'm pulling my hair out here
> and honestly, other than a small change recommended by Oracle, personally
> I've always felt that this type of tweaking was either a problem with the
> network or a problem with code that needed to be tuned so the waits were not
> so severe to cause connectivity loss...
>
>
>
> Kellyn Pedersen
>
> Sr. Database Administrator
>
> I-Behavior Inc.
>
> http://www.linkedin.com/in/kellynpedersen
>
> www.dbakevlar.blogspot.com
>
>
>
> "Go away before I replace you with a very small and efficient shell
> script..."
>
>
>
>
Other related posts:
- » Re: [SPAM] Re: 12170/ORA-12535/12537 - Jack van Zanen
