Help - Search - Members - Calendar
Full Version: Connection Manager in 10g (again)
Oracle DBA Forums > Oracle > Oracle Forum
Hi all

I posted a query about CMAN a few weeks ago,and I'm still puzzled as to what to put where in the various .ora files.

I am trying to configure a server running W2K x64 and Oracle 10g which will be used by a group of developers, some inhouse and some remote. I want to control the access for the remote developers to the databases running on this machine (hostname <server> for the purposes of this post) via CMAN, which is installed to listen on port 1522 and seems to be working ok. I can start it via CMCTL for example, and telnet in through our firewall to 1522, and get a response. If I shutdown CMAN via CMCTL, then the telnet attempt fails with no connection. I used the example cman.ora as a template for mine, and I believe it has been set up correctly although at present I am not using it to restrict connections - I need to get connections working first.

I have been re-reading the Oracle docs for configuring tnsnames.ora in association with CMAN, and they still confuse me, as the example snippets do not refer to a consistent situation, they simply seem to choose service and host names afresh for each example. It is also not at all clear on which machine (server or client) I am supposed to be making the changes!

My two questions are: If I have a database named <db> running on a server named <server> which also has CMAN running on it listening on port 1522, (1) what do I need in tnsnames.ora on the server and (2) in tnsnames.ora on a client PC in order to ensure that I can connect from the PC to the server via Connection Manager? For information (in case you need it), the tnsnames.ora on my server currently contains an entry for the CMAN listener as shown below:

# Connection Manager listener

The name cman_<server> is the same as that used to define the CMAN instance in cman.ora.

Again, in case it's important to consider, when I installed Oracle it configured the default listener on 1521 and this is currently running. Assuming port 1521 is open, I can therefore happily connect to a database <db> directly using an entry like

<db> =
(ADDRESS = (PROTOCOL = TCP)(HOST = <server>)(PORT = 1521))

I just need two snippets that I can drop the appropriate host name and database name into - and I will be eternally grateful to anyone who can supply them!

Richard Jebb
Helklo Richard,

I do not use CMAN, as ordinary TNS connectivity works fine for most databases.

However, this doc page has some good working exampls of configuring CMAN:
Thanks for replying! I have 2 questions on your answer though, as I am not sure how relevant it is to our situation:

(1) We used to use 9i, and we had trouble through firewalls until we added a tweak to a parameter file somewhere (?use shared server) because the server assigned you a new port number for traffic once you had initiated a connectionon 1521. I thought that's why one needed the connection manager in the first place

(2) The docs you suggest are for 9i not 10g, and the configuration files have changed. The comments in my original post refer to the equivalent manual section for 10g

If the general view is that connection manager is a waste of time, I'd happily go without it, but I was tempted by the ability to restrict access to specific databases based on the source IP range, which is not something a standard firewall can do.

The docs may be for 9i, but they did contain the necessary information- which appears to be completely missing from the 10g docs!

For anyone else puzzling over this, now or in the future, the key is to tell the client to route connection requests through the connection manager using an entry like this, with a double ADDRESS section:


Once I had set this up, I was in.

Thank you again!

"which appears to be completely missing from the 10g docs!"

I wonder if Oracle deprecated CMAN on 11g?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2016 Invision Power Services, Inc.