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).
