Re: Oracle instance startup user on Unix
- From: Jared Still <jkstill@xxxxxxxxx>
- To: Oracle-L Freelists <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 15 Jul 2005 20:38:31 +0100
While playing around with TCP.VALIDNODE_CHECKING it became apparent
that there is another reason for more than one listener.
If you have 2+ databases on a single server, need to use
TCP.VALIDNODE_CHECKING
(SarbOx ya know), and the databases have different requirements as to what
IP
addresses will be allowed to connect, you need a different listener for
each.
Though the TCP.* parameters reside in sqlnet.ora, they are controlled by the
listener.
Any service connections made through the listener will not be possible for
an
excluded node, regardless of which database instance the connection is
intended for.
This also implies that each database will need a separate ORACLE_HOME.
Jared
On 7/14/05, Jared Still <jkstill@xxxxxxxxx> wrote:
>
> I would have to disagree with that, but for perhaps a slightly different
> reason
> that others have.
>
> Jeremiah Wilton makes a compelling case for 2 listeners, just for the
> purpose
> of minimizing downtime for maintenance.
>
> Setup the tns entries for failover to 2 ports, allowing one listener to be
> taken down for maintenance while the other still serves requests
>
> ora-600.net/articles/stayinalive.pdf<http://ora-600.net/articles/stayinalive.pdf>
>
> Jared
>
>
> On 7/13/05, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
> >
> > I vote for one listener per box - been running this way on several
> > different hardware/OS/Oracle combinations for several years and can't
> > remember ever having a problem. More listeners just equals more maintenance
> > in my opinion.
> >
> > Never had to shutdown SQL*Net access (can just put the specific database
> > in restricted mode if that's what you really want), but if you had to
> > couldn't you just remove the desired service from your listener.ora and
> > then do a reload?
> >
> >
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx
> > [mailto: oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Aragon, Gabriel (GE
> > Commercial Finance)
> > Sent: Wednesday, July 13, 2005 1:03 PM
> > To: Les.Hollis@xxxxxx; Thomas.Mercadante@xxxxxxxxxxxxxxxxx;
> > rob.langmuir@xxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> > Subject: RE: Oracle instance startup user on Unix
> >
> >
> > I've been through many headaches to say that is much better to have
> > separated listeners.. when you have problems on one of them, you will love
> > not to have all your db's under it..
> >
> > GAP
> >
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx
> > [mailto: oracle-l-bounce@xxxxxxxxxxxxx]
> > Sent: Miércoles, 13 de Julio de 2005 08:29 a.m.
> > To: Thomas.Mercadante@xxxxxxxxxxxxxxxxx; rob.langmuir@xxxxxxxxxxxxxxx;
> > oracle-l@xxxxxxxxxxxxx
> > Subject: RE: Oracle instance startup user on Unix
> >
> >
> > Disagree with the "There should be one listener process
> > per server. Period. " We have multiple oracle/servers running on the
> > same UNIX server. If all of them are running on one listener, then I
> > have to drop the listener for all if I need to shutdown SQL*NET access
> > to one.
> >
> > Each database has it's own listener running on a different port...PLUS
> > we have one listener running for all databases that is on a NATTED IP
> > for administrative access through a VPN.
> >
> > And none of them are on default 1521
> >
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx
> > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mercadante, Thomas F
> >
> > (LABOR)
> > Sent: Wednesday, July 13, 2005 7:46 AM
> > To: rob.langmuir@xxxxxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> > Subject: RE: Oracle instance startup user on Unix
> >
> > Bob,
> >
> > My concerns are management and security.
> >
> > Let's tackle the easy one first:
> >
> > Security.
> > Who will have access to the unix account where the database resides?
> > I'm assuming you have a DBA group. Will you have exclusive access to
> > this unix account? If everybody and his brother has the password for
> > this account, then the security of the database is non-existant. You
> > will have no control over who can update anything.
> >
> > Management.
> >
> > Who is managing the server? And who is managing Oracle on that server?
> > Zhu Chao makes a reasonable point about multiple Oracle homes and
> > accounts for different database instances. But I would argue that
> > having them all in an Oracle unix account is much easier to manage.
> >
> > And finally the listener issue. There should be one listener process
> > per server. Period. They should not be managing their own listener.
> > Just plain dumb.
> >
> > My little 2 cents.
> >
> > Tom
> >
> > -----Original Message-----
> > From: oracle-l-bounce@xxxxxxxxxxxxx
> > [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of RSL
> > Sent: Wednesday, July 13, 2005 1:27 AM
> > To: oracle-l@xxxxxxxxxxxxx
> > Subject: Oracle instance startup user on Unix
> >
> > We have a third-party application, which as part of installation
> > process,
> > uses it's own Unix account to create/startup Oracle database/instance.
> > They
> > also want to start a listener with this account.
> >
> > In the future we plan to add our own instances/databases, and these will
> > all
> > be started/created using Oracle account.
> >
> >
> > I don't much like the idea of having two separate unix accounts involved
> >
> > in
> > creating database(s) and starting instances.
> >
> > Although there is no practical reason why this can't be done, can you
> > please
> > offer any reasons why you wouldn't /shouldn't do this.
> >
> > Thanks..../Bob
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> > Privileged/Confidential Information may be contained in this message or
> > attachments hereto. Please advise immediately if you or your employer do
> > not
> > consent to Internet email for messages of this kind. Opinions, conclusions
> > and other information in this message that do not relate to the official
> > business of this company shall be understood as neither given nor endorsed
> > by it.
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> >
>
>
>
> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>
>
--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
Other related posts:
