title: OID IS A PIG link: https://onemoretech.wordpress.com/2009/05/19/oid-is-a-pig/ author: lembobro description: post_id: 322 created: 2009/05/19 21:00:34 created_gmt: 2009/05/19 21:00:34 comment_status: open post_name: oid-is-a-pig status: publish post_type: post

OID IS A PIG

Came across this while searching for something else, and just had to share it:

Oracle have dropped support for Oracle Names. It’s no longer a product. It’s been replaced by Oracle Internet Directory (OID) which is an ldap server, but with enough Oracle initial data to make it slightly difficult to use a vanilla ldap server.

OID is a pig. It’s unreliable and corrupts your TNS data. Also, the redundancy features in the sqlnet client part don’t work with some application servers, coldfusion in particular. So your limited to a single point of faliure. i.e. you can only point your client at one TNS server (like having one DNS server) , so when you want to do maintanance on your TNS server it a big deal. And believe me you’ll want to do maintenance.

Regularly.

You would have to be career-suicidal to want to use it for servers, there may be some value in having people’s PCs point to an OID server, especially if you have a lot of them, but for the machines that your databases run on, stick with a good old fashioned tnsnames.ora file.

The original question was about using an Oracle Names Server instead of tnsnames.ora (TNS data) files. As indicated in this response, Oracle phased out ONS with the introduction of Oracle Internet Directory (OID).

While most of the problems the author had with OID can be attributed to the early version (circa 2005) he was running, and a lack of LDAP expertise, the point that OID makes a lousy “vanilla LDAP server” is well taken.

Which is precisely why I’m now in the process of testing Sun Directory Server as an Oracle name server.

Of course since Oracle is buying Sun, and has no particular reason for continuing to market the Sun server, that option may not be open in the future.

Dave Kearns has an article over on his blog where he serves up the opinion of various luminaries regarding how Oracle’s purchase of Sun will impact the IdM (Identity Management) space.

While it’s becoming clear to most of us in the field that there will be a major realignment of products to fit within the Fusion framework, it was interesting to see that a few people think that the Sun Directory Server will not only survive but also be re-engineered to accept an Oracle RDBMS backend. Hopefully this isn’t just wishful thinking (I suspect it very well could be). Since LDAP directories were first invented one of their major advantages was the reliability, performance and flexibility that came with a relative simplicity of design: a simplicity that included the rock solid but simple core hash table manager backend.

If I thought anyone at Oracle was listening, my own suggestion would be that they continue to develop the Sun Directory product. Keep the Berkeley DB backend as the default. The built-in DSML gateway is another feature that should be retained. I’d also recommend they not mess with the access control, schema and configuration architectures (if you can’t help changing something, go ahead and rename “o=NetscapeRoot” to “o=OracleRoot” or something like it). I’ve got no problem with them adding an OracleContext node someplace, just don’t make anything in the directory system dependent on it. Leave the directory configuration under “cn=config”, for the love of Pete. As far as new features are concerned, some expanded protocol support, like Simple Paged Results Control, would be nice.

But I know they’re not listening, so I won’t belabor the point.

Copyright 2004-2019 Phil Lembo