Go to the FreeLists Home Page Home Signup Help Login
 



[oracle-l] || [Date Prev] [03-2007 Date Index] [Date Next] || [Thread Prev] [03-2007 Thread Index] [Thread Next]

Re: LDAP used for database connect string resolution: best practices

  • From: Mary Elizabeth McNeely <mary_mcneely@xxxxxxxxx>
  • To: Oracle-L@xxxxxxxxxxxxx
  • Date: Fri, 2 Mar 2007 10:11:57 -0800 (PST)
I haven't received much response, so I'll broaden the scope to "anyone using 
OID".  Hope to hear from you!

Thanks - 
Mary Elizabeth

----- Original Message ----
From: Mary Elizabeth McNeely <mary_mcneely@xxxxxxxxx>
To: Oracle-L@xxxxxxxxxxxxx
Sent: Tuesday, February 27, 2007 12:00:08 PM
Subject: LDAP used for database connect string resolution: best practices


Good afternoon, all,

I'd like to learn how others in the field are using Oracle's OID/LDAP 
implementation to resolve database connect strings:

What LDAP server do you use in the background and how is that working for you?  
What version?

Do you have more than one OID server?  If so, do you have them configured to 
automatically replicate the entries to each other?  Any gotchas with that?

How have you chosen to implement failover between the two?  Primary/secondary 
entries in a sqlnet.ora?  Single entry in sqlnet.ora, and an IP address with 
round-robin DNS?  Other?  How has it worked for you?  

How many non-OID databases do you have?  What versions?  At what level of 
transactional/resolution load do you find you need a secondary OID server?  

Any words of wisdom or things you'd wished you'd known sooner?  

If you will reply to me privately, I'd be glad to post a follow-up message with 
a summary of the responses received.  

Thanks much - woo hoo!, my first oracle-l post! -
Mary Elizabeth McNeely
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l






[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.