Friday, December 30, 2005

Networked Database Naming

The organisation I work for has a large number of sites (literaly hundreds) all connected via a WAN. Whilst for some applications everyone who uses that app are in the same office (or two or three offices) for others the users are widely disperesed, so making maintenence when a database changes name or moves to a different machine very difficult and time consuming. In one case we have a thick client application (i.e. there's a connection directly from the desktop to the database, not going through an application server) where the database is due to move in the near future, this application is used by hundreds of users accross almost as many sites. I was asked to come up with a list of options for providing a centrally administered naming service. One key piece of information is that in this organisation most applications (and their databases) are managed by a departmental support team, hence there is currently no central repository of database names.


Oracle Names Server
Pros
  • Oracle supported solution
  • Will not impact on existing directory servers
  • Graphical and command line management tools
  • Well documented


Cons
  • Have to set up at least one Oracle Names Server
  • Have to visit every desktop to configure them to use the Oracle Names Server
  • Oracel Names is supported in Oracle 8/8i, deprecated (i.e. still there but Oracle advise not to use it) in Oracle 9i and Obsolete (i.e. not there anymore, the code has been removed) in Oracle 10g and later



Oracle Internet Directory
Pros
  • Oracle supported solution
  • Will not impact on existing directory servers
  • LDAP version 3 compliant
  • Support for Enterprise Roles and Single Sign On (could be useful where one user access a number of databases with the same username.
  • Graphical and command line management tools
  • Well documented


Cons
  • Have to set up Oracle Internet Directory Server
  • Have to visit every desktop to configure them to use Oracle Internet Directory server
  • Not fully supported on pre-9i databases



Microsoft Active Directory (the Meta Directory)
Pros
  • Oracle supported solution
  • Already have the servers set up
  • Can be configured to be LDAP version 3 compliant
  • Graphical management tools


Cons
  • Have to visit each desktop to configure them to use the Microsoft Active Directory server
  • Would add objects to the meta directory
  • Not guaranteed to be supported in future releases (Novell NDS/eDirectory has already been deprecated and obsoleted as a compatible directory)



Other LDAP version 3 compliant directory
Pros
  • Will not impact on existing directory servers
  • LDAP version 3 compliant
  • Depending on directory selected could use open source
  • Not tied into to one vendor's product, can just export settings and import them into another compliant product.


Cons
  • Not Oracle supported solution
  • Only works with Oracle 9i and 10g, may work with later versions but isn't guaranteed
  • Would have to set up a server with the appropriate directory software on
  • Depending on OS and directory software used might not have much by way of management tools
  • Have to visit every desktop to configure them to use an LDAP directory


Use environment variable "TNS_ADMIN" to point to location of TNSNAMES.ORA file on a network drive
Pros
  • In use in a lot of Oracle shops worldwide and has been working for some time.
  • Pretty much version independant (TNS_ADMIN was introduced in Oracle 7 and is still used in Oracle 10g)
  • May be able to set in profile or login script so removing need to visit every PC
  • Will not impact existing directory servers
  • Oracle supported solution
  • Simplifies trouble shooting for connectivity problems, If the file works fine for other people then we know that it's not the file causing the problem. Similarly for all Oracle Net8 configuration files that live in that location.
  • Easier to stop users meddling, can make the file read only for non admin users


Cons
  • Will need co-ordination between sections as all databases that every user needs to access via a thick client that connects to the database will need to be in one file at one central location
  • May run into issues where PC has multiple different versions of Oracle client installed
  • File would have to be read only for non-admin users to prevent a user who thinks they know what they're doing going in and stripping out the entries they don't need (but other people who use that file do)


Use login script to copy TNSNAMES.ORA in from a network drive to %ORACLE_HOME%\network\admin
Pros
  • In use in a lot of Oracle shops worldwide
  • Pretty much version independant
  • Will not impact existing directory servers


Cons
  • Will need co-ordination between sections as all databases that every user needs to access via a thick client that connects to the database will need to be in one file atr one central location
  • May run into issues where PC has multiple different versions of the Oracle client installed
  • Not an Oracle supported solution
    Updates only propergate when users logs on
  • Users can update their local file but the updates are wiped out when they login.

No comments: