If you are wondering why are you getting this error *and* all the following prerequisite conditions apply to you:
USE_SHARED_SOCKET can be either an environment variable or a windows registry value.
I preferred the former option and i defined it as a system variable, in My computer's properties/advanced tab/environmental variables.
If you look up ORA-12170 in the Oracle error message list for Oracle 10G, then you are confronted with an explanation where either network delays or a denial-of-service attacks are the most probable causes.
Well, in my humble opinion, is also very likely that you are trying to access a database behind a firewall and the only open port is 1521 (or a non-standard port if that's the case).
Opening port 1521 is not enough because the listener is only accepting initial requests through that port, but once the dedicated server process is started, the connection between client and server is moved to a different port, typically a randomly chosen port, if i am not wrong.
In view of this fact, you can't just open up all the ports of the firewall and here's where this USE_SHARED_SOCKET=TRUE comes in handy, because it forces the connection to occur on the same initial port.
- You are trying to connect to a remote database through the internet;
- tnsping net_service_name is working telling you that the remote listener is up and running;
- the remote database is running on a Windows platform;
- server parameter USE_SHARED_SOCKET is not set or is set to FALSE;
- your client is attempting to connect in dedicated server mode;
- you get ORA-12170:TNS:Connect timeout occurred (or TNS-12170 on versions earlier than 10g), when you try to open a connection from SQL*Plus or from another client program;
USE_SHARED_SOCKET can be either an environment variable or a windows registry value.
I preferred the former option and i defined it as a system variable, in My computer's properties/advanced tab/environmental variables.
If you look up ORA-12170 in the Oracle error message list for Oracle 10G, then you are confronted with an explanation where either network delays or a denial-of-service attacks are the most probable causes.
Well, in my humble opinion, is also very likely that you are trying to access a database behind a firewall and the only open port is 1521 (or a non-standard port if that's the case).
Opening port 1521 is not enough because the listener is only accepting initial requests through that port, but once the dedicated server process is started, the connection between client and server is moved to a different port, typically a randomly chosen port, if i am not wrong.
In view of this fact, you can't just open up all the ports of the firewall and here's where this USE_SHARED_SOCKET=TRUE comes in handy, because it forces the connection to occur on the same initial port.
Please post comments about your experience.
No comments:
Post a Comment