السلام عليكم
لو سمحتم ياجماعة انا شغلت كمبيوتر وهمى ونزلت عليه ويندوز اكس بى على الكمبيوتر بتاعه واللى الويندوز بتاع ويندوز 7
ونزلت الداتا بيز 10 جى على الجهاز بتاعى الحقيقى(ويندوز 7) والديفولبرا 10جى على الوهمى وعملت الشبكه تمام
بس كل لما اشغل الديفولبر بيدينى الرسالة دى
ora-12353:tns:operations timed out
منتظر الرد

Here's what I got on Metalink
-------------------------------------
Troubleshooting Guide TNS-12535 or ORA-12535 or ORA-12170 Errors [iD 119706.1]

--------------------------------------------------------------------------------

Modified 23-DEC-2009 Type BULLETIN Status PUBLISHED


Applies to:
Oracle Net Services - Version: 8.1.7.0.0 to 10.2.0.3.0
Information in this document applies to any platform.

Purpose
This bulletin is designed to assist in determining what steps to take to troubleshoot and correct ORA-12535/TNS-12535 errors.

This document is based on reported errors and fixes. Where possible, the note numbers are included as a cross reference to reduce duplication. It also includes some information on why the error may have occurred as well as why the fix would work.



Scope and Application
This is intended to assist all levels of engineers and customers and is in addition to any troubleshooting guides written specifically in Oracle Docs.
Troubleshooting Guide TNS-12535 or ORA-12535 or ORA-12170 Errors
Brief notes:
~~~~~~~~
- In essence, the ORA-12535/TNS-12535 is a timing issue between the client and server.

- The TNS-12535 or ORA-12535 error is commonly a timeout error associated with Firewalls or slow Networks.

- It can also be due to an incorrect "timeout" parameter setting for the following files:

listener.ora -->
CONNECT_TIMEOUT_<listener_name> (8.1.x and lower only)
or
INBOUND_CONNECT_TIMEOUT_<listener_name> (9.2 and above)

sqlnet.ora -->
SQLNET.INBOUND_CONNECT_TIMEOUT (9.2 and up).

- Please be sure to also read documentation on other troubleshooting guides contained within the Oracle Admin Guides


Quick Checks:
~~~~~~~~~~
- Ensure that your Client and Server platforms and versions are supported and within Oracle's recommended guidelines (see Note:207303.1).

- Make sure that any non-supported settings or potential causes, such as Soft links, shared configuration files, etc., are removed before looking into this document.

- If you are running Oracle Names Server (9i and prior), then setup a temporary tnsnames.ora file and edit the sqlnet.ora file to have NAMES.DIRECTORY_PATH = (TNSNAMES)

- If you are running Shared Server (formerly Multi Threaded Server or MTS), then try the same connection with (SERVER=DEDICATED) in the tnsnames.ora alias.


Diagnosing Common Errors:
~~~~~~~~~~~~~~~~~~~

From Note:21469.1
-------------------
Error: ORA-12535 / TNS-12535
Text: TNS:operation timed out
---------------------------------------------------------------------------
Cause: The requested connection could not be completed within the timeout
period specified by the CONNECT_TIMEOUT parameter in listener.ora. This
error arises from the tnslsnr.
Action: Either reconfigure CONNECT_TIMEOUT to be 0, which means wait
indefinitely, or reconfigure CONNECT_TIMEOUT to be some higher value.
Or, if the timeout is unacceptably long, turn on tracing for further
information.


1. Find out if you are going through any Firewalls or Routers. If you are, then see Note A below.

2. Try to "ping" the ip address or hostname from the client.
Check the timing response and see if it is acceptable.
If it is not, then you need to request assistance from your System or Network Administrator.

With 8i and earlier, you can increase the listener.ora file parameter CONNECT_TIMEOUT_<listener_name> and make it a higher value.
Doing this, however, will correct the connectivity problem but will be masking the real problem of the physical network.
(See the Sqlnet / Net8 Administrators guide for details on how to make these changes)

With 9i and higher, the CONNECT_TIMEOUT_<listener_name> parameter is obsoleted. You should consult the Net Services Administrator's Guide for your version to find out what connection timeout parameters are available.

3. With 10.1 and 10.2, an ORA-12535 or ORA-12170 can be received by the client if the time to connect is too slow. This can be true if the listener's parameter INBOUND_CONNECT_TIMEOUT_<listener_name> and/or Server's sqlnet.ora parameter SQLNET.INBOUND_CONNECT_TIMEOUT are set too low. This is especially true for 10.2 (see Note:345197.1).
The corresponding error on the Server side may be an ORA-3136 in the alert log and the sqlnet.log may contain an ORA-12170.

4. With 11g the database alert log may also contain a combination of 12535 and/or 12170 errors. Check to see what problems are being experienced by the CLIENT end of communications as these errors can be caused by excessive connections and the database not being able to handle such storms in the time allowed.


Note A - Firewall Restrictions
------------------------------
1a. If you are going through a Firewall, and your server platforms are UNIX, then you must ensure that the port being listened on is open, unless you are running the Firewall vendor's Proxy Server, in which case this will allow connectivity.

1b. If you are not running the Firewall vendor's Proxy, and the port is not open, then you will have a refusal from the outside into the Firewall zone.
An ORA-12535 / TNS-12535 is the usual error received by the client.

1c. If you are going through a Firewall connecting to a RAC Database, and your Server platforms are UNIX, then you must ensure that the port being listened on by the listeners in the nodes is open, as well as the long and short versions of all possible hostnames (VIP and physical) are allowed by the Firewall.


2. For 9.2 and lower, if you are going through a Firewall, and your server platforms are NT, then you must ensure that the port being listened on is open as well as setting up a SQL*Net/Net8 Proxy, such as Net8 Connection Manager, if none is provided by the Firewall vendor.
The reason is that, even though the port is open, the TCP layer will REDIRECT the port to another port.
This is due to Winsock2 workings under Microsoft.
Note that this does NOT occur with 10g or 11g as there is no port redirection.

3. If you are getting either of these errors going through a firewall, then please get the System Administrator to make certain that the following settings are disabled and then test:
- SQLNet fixup protocol
- Deep Packet Inspection (DPI)
- SQLNet packet inspection
- SQL Fixup
- SQL ALG (Juniper firewall)

The wording and features can vary by vendor but all the above have some impact on some packets (not all packets are affected) Some firewalls can have an adverse effect on certain SQL packets transported across them (again, some not all)
Please see Note:742535.1 as an example.

4. If the errors are reported in the alert log, then the problem is most likely one or more clients not being able to establish their connection in the connection time allowed. Make certain there is not an abnormal number of connections being made to the Database, such as when other conditions occur and the call volume increases extraordinarily (for example, an Application attempting too many connections simultaneously). Resolve this at the front-end.

5. If you are getting either of these errors intermittently and going through a firewall, and your backend Database is in a RAC environment, then please ensure you check the possible causes and conditions given in the following notes:

Note:333159.1 "Ora-12545 Frequent Client Connection Failure - 10g Standard Rac"
Note:364855.1 "RAC Connection Redirected To Wrong Host/IP ORA-12545"
Note:291175.1 "Clients Failing to Connect Due to Intermittent ORA-12545 in RAC Environment"

Even though the older "redirection" to another port does not occur, redirection to another HOST may occur without the LOCAL_LISTENER set to the correct listener address.

Additional on firewalls:
- Please see the following notes on Firewalls and related errors - Note:68652.1
- Various other documents and White Papers detailing Oracle and firewall communication



Generating & Interpreting Trace Files:
~~~~~~~~~~~~~~~~~~~~~~~~~
A tracing technique that can be incorporated to try and determine what is happening, can be outlined as below.

- Set-up client sqlnet tracing and listener tracing, both set to level 16 or support (see Note:219968.1).
- What you should find is that a SEND request with the client's address will be sent out but, instead of a receive packet being returned with a confirmation address, the 12535 error will be thrown.
- The client trace will look similar to the following:



nspsend: packet dump
nspsend:00 7D 00 00 01 00 00 00 |.}......|
nspsend:01 36 01 2C 00 00 08 00 |.6.,....|
nspsend:7F FF 7F 08 00 00 00 01 |........|
nspsend:00 43 00 3A 00 00 08 00 |.C.:....|
nspsend:00 00 00 00 00 00 00 00 |........|
nspsend:00 00 00 00 4C 16 00 00 |....L...|
nspsend:2C 7A 00 00 00 00 00 00 |,z......|
nspsend:00 00 28 44 45 53 43 52 |..(DESCR|
nspsend:49 50 54 49 4F 4E 3D 28 |IPTION=(|
nspsend:41 44 44 52 45 53 53 3D |ADDRESS=|
nspsend:28 50 52 4F 54 4F 43 4F |(PROTOCO|
nspsend:4C 3D 74 63 70 29 28 48 |L=tcp)(H|
nspsend:4F 53 54 3D 31 30 2E 32 |OST=xx.x|
nspsend:2E 32 31 30 2E 32 32 29 |.xxx.yy)|
nspsend:28 50 4F 52 54 3D 37 37 |(PORT=77|
nspsend:37 30 29 29 29 00 00 00 |77)))...|
nspsend: normal exit
nscon: exit (0)
nsdo: nsctxrnk=0
nsdo: normal exit
nsmal: entry
nsmal: 2048 bytes at 0x405985e0
nsmal: normal exit
nsdo: entry
nsdo: cid=3, opcode=68, *bl=2048, *what=9, uflgs=0x0, cflgs=0x3
nsdo: rank=64, nsctxrnk=0
nsdo: nsctx: state=2, flg=0x4205, mvd=0
nsdo: gtn=0, gtc=0, ptn=10, ptc=2047
nscon: entry
nscon: recving a packet
nsprcvs: entry
nsbal: entry
nsbgetfl: entry
nsbgetfl: normal exit
nsbal: normal exit
nsprcvs: transport read error
nsprcvs: error exit
nserror: entry
nserror: nsres: id=3, op=68, ns=12535, ns2=12560; nt[0]=505, nt[1]=0, nt[2]=0
nscon: error exit
nsdo: nsctxrnk=0
nsdo: error exit
nsmfr: entry
nsmfr: 2048 bytes at 0x405985e0
nsmfr: normal exit
nscall: unexpected response
nsclose: entry
nstimarmed: entry
nstimarmed: no timer allocated
nstimarmed: normal exit
nsdo: entry
nsdo: cid=3, opcode=98, *bl=0, *what=0, uflgs=0x40, cflgs=0x2
nsdo: rank=64, nsctxrnk=0
nsdo: nsctx: state=2, flg=0x4201, mvd=0
nsbfr: entry
nsbaddfl: entry
nsbaddfl: normal exit
nsbfr: normal exit
nsbfr: entry
nsbaddfl: entry
nsbaddfl: normal exit
nsbfr: normal exit
nsdo: nsctxrnk=0
nsdo: normal exit
nsclose: closing transport
nttdisc: entry
nttdisc: Closed socket 27
nttdisc: exit
nsclose: global context check-out (from slot 3) complete
nsnadisc: entry
nsbfr: entry
nsbaddfl: entry
nsbaddfl: normal exit
nsbfr: normal exit
nsmfr: entry
nsmfr: 1668 bytes at 0x40597f50
nsmfr: normal exit
nsmfr: entry
nsmfr: 416 bytes at 0x4041fbf0
nsmfr: normal exit
nsclose: normal exit
nscall: error exit
nricdt: Call failed.


- On the listener side, there may be a few different traces.

1. If the Server is on NT and the Firewall has it's port open, then the following happens:
- The client connection request is received by the listener.
- The listener (from TCP stack) will send a redirect of the port.
- No other client information will be seen and the listener will eventually shut down the connection request, also with a timeout or client gone away.

2. If the firewall does not have the valid port open, then the following happens:
- No client information can be seen in the listener trace and the listener will be waiting on any new connections.

3. Another possibility is that the firewall has a setting that is affecting the SQL*Net packets and might be supressing them.
What you might see here with a matching client and server SQL*Net trace, is that packets are being sent by the Database to the client as requested by the client, but the packets do not arrive.
If this occurs for some packets but not all, then there is a chance that the firewall has the "fixup" feature enabled or some type of "packet inspection" is taking place. For example, a SELECT from a client
on a table might work, but a DESCRIBE by the same client off the same Database might not be received.



References
NOTE:207303.1 - Client / Server / Interoperability Support Between Different Oracle Versions
NOTE:21469.1 - OERR: ORA-12535 TNS:operation timed out
NOTE:345197.1 - Connections that Used to Work in Oracle 10.1 Now Intermittently Fail with ORA-3113,ORA-3106 or ORA-3136 in 10.2
NOTE:68652.1 - Solving Firewall Problems on Windows
NOTE:219968.1 - SQL*Net & Oracle Net Services - Tracing and Logging at a Glance
NOTE:742535.1 - INSERT INTO TABLE AS SELECT FROM DBLINK OVER VPN TUNNEL HANGS ON LARGE NUMBER OF ROWS
NOTE:333159.1 - Ora-12545 Frequent Client Connection Failure - 10g Standard Rac
NOTE:364855.1 - RAC Connection Redirected To Wrong Host/IP ORA-12545
NOTE:291175.1 - Clients Failing to Connect Due to Intermittent ORA-12545 in RAC Environment

Related



--------------------------------------------------------------------------------
Products
--------------------------------------------------------------------------------

•Oracle Database Products > Oracle Database > Net Services > Oracle Net Services

OERR: ORA-12535 TNS:operation timed out [iD 21469.1]

--------------------------------------------------------------------------------

Modified 09-JUN-1999 Type REFERENCE Status PUBLISHED


Error: ORA-12535 / TNS-12535
Text: TNS:operation timed out
---------------------------------------------------------------------------
Cause: The requested connection could not be completed within the timeout
period specified by the CONNECT_TIMEOUT parameter in listener.ora. This
error arises from the tnslsnr.
Action: Either reconfigure CONNECT_TIMEOUT to be 0, which means wait
indefinitely, or reconfigure CONNECT_TIMEOUT to be some higher value.
Or, if the timeout is unacceptably long, turn on tracing for further
information.

السلام عليكم
جزاك الله خيرا على ردك
بس لوسمحتى ممكن تلخصيلى اعمل ايه بالظبط لانى مبتدى لسه

ياريت حد من الخبرا يساعدنى جزاكم الله خيرا