This content has been marked as final. Show 4 replies
I notice a pattern above.
12170, 00000, "TNS:Connect timeout occurred" // *Cause: The server shut down because connection establishment or // communication with a client failed to complete within the allotted time // interval. This may be a result of network or system delays; or this may // indicate that a malicious client is trying to cause a Denial of Service // attack on the server. // *Action: If the error occurred because of a slow network or system, // reconfigure one or all of the parameters SQLNET.INBOUND_CONNECT_TIMEOUT, // SQLNET.SEND_TIMEOUT, SQLNET.RECV_TIMEOUT in sqlnet.ora to larger values. // If a malicious client is suspected, use the address in sqlnet.log to // identify the source and restrict access. Note that logged addresses may // not be reliable as they can be forged (e.g. in TCP/IP). bcm@bcm-laptop:~$ oerr ora 12535 12535, 00000, "TNS:operation timed out" // *Cause: The requested operation could not be completed within the time out // period. // *Action: Look at the documentation on the secondary errors for possible // remedy. See SQLNET.LOG to find secondary error if not provided explicitly. // Turn on tracing to gather more information. bcm@bcm-laptop:~$ oerr ora 12560 12560, 00000, "TNS:protocol adapter error" // *Cause: A generic protocol adapter error occurred. // *Action: Check addresses used for proper protocol specification. Before // reporting this error, look at the error stack and check for lower level // transport errors. For further details, turn on tracing and reexecute the // operation. Turn off tracing when the operation is complete.
Site is afflicted with network gremlins.
I expect that your Network folks won't embrace the follow,
but I believe that Oracle is victim; not culprit.
By "cluster" do you mean RAC? If so state that explicitly.1 person found this helpful
But for now runt this query.
Also check CPU utilization and cache fusion interconnect traffic.
SELECT dbms_utility.current_instance, TO_CHAR(begin_time, 'HH:MI') time, 60 * (select value from v$osstat where stat_name = 'NUM_CPUS') total, 60 * (select value from v$parameter where name = 'cpu_count') db_total, SUM(cpu_consumed_time) / 1000 consumed, SUM(cpu_wait_time) / 1000 throttled FROM v$rsrcmgrmetric_history GROUP BY begin_time ORDER BY begin_time;
I have had a similar issue with an 126.96.36.199 and am far from enamored of RM.
Yes . I have a RAC ! I have a machine to be the storage. I have two machines as database.
I reported this bug that is being described in the alerts database more than 50 times per day.
In the beginning I thought it was a deadlock but the alert does not show me the deadlock occurrence of more than 45 days
The query did not bring me any result row. ran the query connected with sys. what can it be?
thank you very much for your help.
i dont have a solution.Thank to the help.