home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.oracle      Overblown overpriced overengineered SHIT      2,288 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 1,646 of 2,288   
   Frank van Bortel to Christian Eriksson   
   Re: Understanding "lsnrctl status"   
   17 Aug 04 11:40:37   
   
   From: fvanbortel@netscape.net   
      
   Christian Eriksson wrote:   
      
   > Mark.Powell@eds.com (Mark D Powell) wrote in message news:<268   
   bb95.0408161222.78040733@posting.google.com>...   
   >   
   >>c-eriks@algonet.se (Christian Eriksson) wrote in message news:   
   d0d6f67c.0408160550.51f075ab@posting.google.com>...   
   >>   
   >>>Hi!   
   >>>   
   >>>I want to clarify, for myself, some basic facts about Oracle Client   
   >>>Server configuration. I start with the listener configuration on the   
   >>>server side.   
   >>>   
   >>>What block(s) in what configuration file(s) defines the services   
   >>>(shown below)?   
   >>>   
   >>>What causes there to be more than one instance of a service (shown   
   >>>below)?   
   >>>   
   >>>Output from "lsnrctl status" (Oracle 9.2.0.1.0 on Sun Solaris 8):   
   >>>   
   >>>........................   
   >>>   
   >>>Services Summary...   
   >>>Service "PLSExtProc" has 1 instance(s).   
   >>>  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this   
   >>>service...   
   >>>Service "ftgdb" has 2 instance(s).   
   >>>  Instance "ftgdb", status UNKNOWN, has 1 handler(s) for this   
   >>>service...   
   >>>  Instance "ftgdb", status READY, has 1 handler(s) for this service...   
   >>>Service "ftgdbXDB" has 1 instance(s).   
   >>>  Instance "ftgdb", status READY, has 1 handler(s) for this service...   
   >>>The command completed successfully   
   >>>   
   >>>Regards Christian Eriksson   
   >>   
   >>Starting with version 8.1 the Oracle instance and the listener have   
   >>the ability to automatically find each other without listener.ora   
   >>entries being predefinded for the database.  Most listener.ora files   
   >>however would have had SID_DESC entries for the existing databases in   
   >>them since these were requried up to then.  Habit, would result in   
   >>entries being made for new databases.   
   >>   
   >>I believe this is the cause of the double listing for a database   
   >>instance via status.  Unfortunately I am not allowed to change the   
   >>listener.ora and test if removing the now redundant entries and   
   >>bouncing the listener and databases 1- works correctly and 2- cleans   
   >>up the status enties.   
   >>   
   >>As noted this is conjecture, but perhaps you can test it and post back   
   >>the results.   
   >>   
   >>HTH -- Mark D Powell --   
   >   
   >   
   > Thank's for the answer!   
   >   
   > I still can't pinpoint where the services are defined. In the   
   > listener.ora file I can see the following for the LISTENER listener:   
   >   
   > SID_LIST_LISTENER =   
   >   (SID_LIST =   
   >     (SID_DESC =   
   >       (SID_NAME = PLSExtProc)   
   >       (ORACLE_HOME = /opt/oracle/product/9.2.0.1.0)   
   >       (PROGRAM = extproc)   
   >     )   
   >     (SID_DESC =   
   >       (GLOBAL_DBNAME = ftgdb)   
   >       (ORACLE_HOME = /opt/oracle/product/9.2.0.1.0)   
   >       (SID_NAME = ftgdb)   
   >     )   
   >   
   > I guess the SID_NAME entries in the two SID_DESC blocks defines the   
   > services "PLSExtProc" and "ftgdb". My wondering is about the service   
   > "ftgdbXDB". Can someone tell me where that service might be defined?   
   >   
   > Regards Christian Eriksson   
      
   See pfile - there's a Mutli-threaded Server for XDB defined.   
   Try http://localhost:8080 and you should get a log on screen.   
   --   
      
   Regards,   
   Frank van Bortel   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca