Re: SQL*NET V2 Craziness

med_at_crash.cts.com (Greg Gehrich - Medimpact) writes:
|> What is this about the listener has to be going before the database.
|> That is from Oracle. It means on our mission critical database that
|> should the listener die (and it has) we need to drop and restart
|> the db. Per Oracle, it MIGHT reconnect if you restart the listener
|> with the db up, mayber 30 - 40 minutes later.

I'll take a guess as to what exactly you are referring to. If you have a requirement that users only connect to the database via a dispatcher/shared server (a.k.a. MTS), the V2 listener needs to be up and running first, so that when the dipatchers come up with the database, they can register their existence with the listener. If the listener isn't up, the dispatchers will get the error and try again later (rather than chew up CPU retrying). I don't know the exact time period they will sleep before retrying but 30-40 minutes might be pessimistic. In the meantime, incoming connections may be given dedicated servers instead.

You might be able to "kick start" the dispatchers to register with the listener without having to shut down the database. There is a ALTER SYSTEM command to change the number of dispatchers you have running. If nobody is currently connected to any of the existing dispatchers, you can ALTER the number to 0 and then back to the original number (or if there are existing connections, ALTER the number to be higher than current). The new dispatcher processes should register with the listener immediately. You may need to adjust some init.ora parameters to gain that flexibility.

And of course, it would be worth pursuing why the listener is dying in the first place.

Hope I've address this correctly.

Roderick Manalac
Oracle Corporation Received on Sun Oct 30 1994 - 22:55:33 CET