|
When using names, always have more than one nameserver
and add these 2 lines to sqlnet.ora. It sure helps when one fails.
Been there :)
NAMES.INITIAL_RETRY_TIMEOUT = 5 #Wait num seconds before
going to next nameserver,def=15
NAMES.REQUEST_RETRIES =
2 #Number of retries for
nameserver,def=5
Gene
>>> [EMAIL PROTECTED] 06/12/03 03:42PM >>> Re pushing the tnsnames.ora out to desktops: I considered that, but there were too many versions of it out there, and the users may have ODBC DSN' s dependent on the contents of their tnsnames.ora. Re the share drive: Considered that too, but it's too easy for net admins to re-arrange drives without advance warning. ( it has happened ) I compromised. The tnsnames.ora stays on the desktops. The sqlnet.ora has this line: NAMES.DIRECTORY_PATH = (ONAMES, TNSNAMES) so that their tnsnames will still work, but I can make changes in the name servers without worrying about their tnsnames files. Updating the names servers is pretty simple, and I don't have to schedule a change to all the desktops. Works for me anyway. Jared Stephen Lee <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 06/12/2003 12:01 PM Please respond to ORACLE-L To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject: RE: Oracle Names I never liked names, but that's just me. I thought keeping the names servers up to date, and making sure every client was configured to use the name servers, was a pain in the butt. You can have multiple names servers to eliminate a single point of failure. The method I liked the best was to have the PC admin people push a new tnsnames.ora out to client machines using push software. Let THEM fuss with it! Another method that works is to have the tnsnames.ora on a share and stick a shortcut on the client desktop that will update the local tnsnames.ora when the user clicks on it. > -----Original Message----- > > 1. Are any of you using the Oracle Names? > 2. Is it as easy to configure as Oracle makes it sound, or is > it difficult? > 3. Is Names reasonably robust? I can see this as yet another > single point of > failure. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephen Lee INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). |
- RE: Oracle Names Mercadante, Thomas F
- RE: Oracle Names Stephen Lee
- RE: Oracle Names Jacques Kilchoer
- RE: Oracle Names Jared . Still
- RE: Oracle Names Odland, Brad
- RE: Oracle Names Richard Ji
- RE: Oracle Names Gogala, Mladen
- RE: Oracle Names Jesse, Rich
- RE: Oracle Names Jacques Kilchoer
- RE: Oracle Names Goulet, Dick
- RE: Oracle Names Gene Sais
- RE: Oracle Names John Kanagaraj
- RE: Oracle Names Jesse, Rich
- RE: Oracle Names Ravi Kulkarni
- Re: Oracle Names DEEDSD
- RE: Oracle Names DENNIS WILLIAMS
- RE: Oracle Names Paul Baumgartel
- RE: Oracle Names Jacques Kilchoer
- RE: Oracle Names M Rafiq
- RE: Oracle Names Goulet, Dick
- RE: Oracle Names Gogala, Mladen
