Jeremiah, I think Rich and I were maily addressing the SPoF question: When architectured properly, ONames in itself can be quite reliable, and has adequate fallback. Some of your other questions such as chopping up access from segments and "cells" can be achieved using multiple TNS handles to the same DB using different port numbers, etc (you point this out and we concede). You handled this by creating _different_ contents in TNSNAMES.ORA for different "cells", and have essentially tricked the system. So what is to prevent a newbie from replacing all the TNSNAMES.ORA with a 'standard' one? (apart from strict access controls?) And I do have a question - have you tried pushing out TNSNAMES.ORA to 3000-4000 PC clients, all in the space of an hour when a DB migration/server upgrade occurs? ONS is *the* man for the job at such a time. As I said before, it was impossible for us to have upgraded a major Apps 10.7 database without ONS. Another one is the addition of new databases - it is a cinch with ONS... When you push out TNSNAMES.ORA, you need to be sure that you have captured _all_ changes and nuances in the client's file. This can be a major pain if you allow users to change the TNSNAMES.ORA files. If ONS is being used, then you don't really care what they put into the local files. If they change the TNS order, then they are responsible for connection failures. This indeed has shown up on our screens as 'consultants' who fiddle around without knowing what they were doing, and serves as red flags...
As to fat-fingering, it can occur anywhere, and I bet both of us have fat-fingered an important piece sometime in our lives :) Actually, ONS changes can also be scripted and tested. I have a dev/test ONS setup and create/test my change scripts therein. And as I said before, maintenance and cleanup as well as h/w switch of the ONS servers (via DNS aliases) is simple, quick and easy to rectify. I cannot comment on the original 'dispatchers re-read tnsnames.ora' - I would then use local, limited entry TNSNAMES.ORA as a special case, with the search order redefined to (TNSNAMES, ONAMES) in this case. As with everything in Life: YMMV! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 I don't know what the future holds for me, but I do know who holds my future! ** The opinions and statements above are entirely my own and not those of my employer or clients ** > -----Original Message----- > From: Jeremiah Wilton [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 30, 2003 4:30 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Making dispatchers re-read tnsnames.ora? > > > Well, my first objection to ONames was just in the context of solving > my problem. Dispatchers cache addresses for outgoing connections, > whether they cache them from tnsnames.ora or ofrom Oracle Names. Or > so I understand it. If someone knows differently about Names then I > would like to hear about it. > > As for the limitations of names... Yes, you can have the local host > caching of directory entries. My objection is more to adding a new > service with added equipment and expense where flat files actually do > a better job. > > Sitations with very high connection rates pose a problem. Using a > pool of application servers, there may be a need for multiple > listeners to handle the load if a connection pooling technology is not > in the picture. In such a situation it is helpful for purpises of > scalability and availability to segregate a large number of app > servers into "cells" of, say, 10 or 20 servers each. You want each of > these cells to be inidividually maintainable, and to be able to be put > in and taken out of service independently, so that overall aailability > for the application base is always maintained. > > In the cell model, a listener or set of listeners is created FOR EACH > CELL. The TNS entries vary from cell to cell for that one service, > because they specify different listeners. The advantages to doing > this are many. With a cell out of service, you can take down a > listener for whatever reason with no impact to the running > application. And if a listener or set of listeners becomes saturated, > the majority of inbound connections are unaffected by the problem, > thus limiting the scope of a fault. AFAIK, you can't really do this > in ONames without making up a different service name for every cell's > listeners. > > Now, say your service is so important that you don't want all the > back-office Duke Nukem and Doom sessions saturating the network and > interfering with the application traffic. In reaction, you create a > totally separate dedicated network for the most important systems in > the company to communicate with the database server. You add a > network interface card with its own IP addfress, but you leave the old > one there so that the back office people can make occasional database > queries. Naturally you will want separate listeners servicing the > "importantnet" than service the old office LAN. In ONames, you would > again have to name the same database's services on different networks > differently. > > So then I ask, what advantage is there to Names? You can change > things in a central location. There are no files to push around. > Well, pushing files isn't really bad once you have a good set of > scripts to do it. And flat files are a really reliable sevice. If > you screw up a tnsnames.ora file change, you can catch the mistake by > just testing with TNS_ADMIN, rather than taking down the whole company > by fatfingering an ONames change. > > So in short, why again do I want yet another service that needs to be > available (or the local caching up to date) to keep people connecting > to my databases (especialy if I have to set up a separate service name > for every little special situation)? > > -- > Jeremiah Wilton > http://www.speakeasy.net/~jwilton > > On Thu, 30 Jan 2003, Jesse, Rich wrote: > > > Not that ONames doesn't have it's shortcomings, but I'm not > sure how ONames > > is a single point of failure. Even in our little 35-alias > ONames repository > > with only the root region, we have a secondary Names > Server. With local > > checkpoint files, the repository is not required for > continuous access, so > > there's no SPoF there. > > > > Could you expound a bit on that, Jeremiah? > > > > Thanks, > > Rich > > > > > > Rich Jesse System/Database Administrator > > [EMAIL PROTECTED] Quad/Tech > International, Sussex, WI USA > > > > > > -----Original Message----- > > Sent: Thursday, January 30, 2003 10:10 AM > > To: Multiple recipients of list ORACLE-L > > > > > > On Thu, 30 Jan 2003, Gogala, Mladen wrote: > > > > > Yeah! Put it in Oracle*Names. > > > > Will it make a difference? Does a dispatcher really re-query Names > > every time it tries to make a connection? No caching of service > > addresses? You promise? > > > > Off I go to convert my 300-instance organization to rely on a single > > point of failure and make a bunch more calls for every connect... > > > > YEEHAW! Oh wait. Names can't handle multiple interface and or > > distinct allocation of certain clients to certain > > listeners/interfaces. Oh well, and I thought I was going to have an > > exciting weekend. Guess its back to that Rubik's cube. > > > > -- > > Jeremiah Wilton > > http://www.speakeasy.net/~jwilton > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jesse, Rich > > 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: Jeremiah Wilton > 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: John Kanagaraj 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).
