I'm planning to bring up a new oracle 9.2.0.5 (solaris 10) instance
using the backup of an existing oracle instance, on the same network but
on a different machine/ip address.

So there will be two physical machines on the same subnet, both running
a listener configured with the same SID and have the same datafiles. As
long as clients are still using the original IP address this shouldn't
present a problem should it ? I'm told that it's possible the 2nd
listener will interfere with the primary machine listener because it
uses the same database/SID. Is this possible ?

--
Michael

On Jun 26, 5:36 am, Michael Pye <mich...@ulimit.org> wrote:
> I'm planning to bring up a new oracle 9.2.0.5 (solaris 10) instance
> using the backup of an existing oracle instance, on the same network but
> on a different machine/ip address.
>
> So there will be two physical machines on the same subnet, both running
> a listener configured with the same SID and have the same datafiles. As
> long as clients are still using the original IP address this shouldn't
> present a problem should it ? I'm told that it's possible the 2nd
> listener will interfere with the primary machine listener because it
> uses the same database/SID. Is this possible ?
>
> --
> Michael

Why would it? The ADDRESS specifies where the listener is located and
where it is listening; since the IP addresses are not the same this
won't be a problem. If it were Data Guard wouldn't function.


David Fitzjarrell

On Jun 26, 5:36 am, Michael Pye <mich...@ulimit.org> wrote:
> I'm planning to bring up a new oracle 9.2.0.5 (solaris 10) instance
> using the backup of an existing oracle instance, on the same network but
> on a different machine/ip address.
>
> So there will be two physical machines on the same subnet, both running
> a listener configured with the same SID and have the same datafiles. As
> long as clients are still using the original IP address this shouldn't
> present a problem should it ? I'm told that it's possible the 2nd
> listener will interfere with the primary machine listener because it
> uses the same database/SID. Is this possible ?
>
> --
> Michael

yes, and as long as you are careful with your name resolution
(tnsnames) it poses no real problem. In a default, out of the box
installation the LISTENER section of your listener.ora file specifies
which host the listener is listening.

Now, while it is possible, is it desireable? That's a bit more of a
religious issue, which I'll not address here

On Jun 26, 8:10 am, EdStevens <quetico_...@yahoo.com> wrote:
> On Jun 26, 5:36 am, Michael Pye <mich...@ulimit.org> wrote:
>
> > I'm planning to bring up a new oracle 9.2.0.5 (solaris 10) instance
> > using the backup of an existing oracle instance, on the same network but
> > on a different machine/ip address.
>
> > So there will be two physical machines on the same subnet, both running
> > a listener configured with the same SID and have the same datafiles. As
> > long as clients are still using the original IP address this shouldn't
> > present a problem should it ? I'm told that it's possible the 2nd
> > listener will interfere with the primary machine listener because it
> > uses the same database/SID. Is this possible ?
>
> > --
> > Michael
>
> yes, and as long as you are careful with your name resolution
> (tnsnames) it poses no real problem. In a default, out of the box
> installation the LISTENER section of your listener.ora file specifies
> which host the listener is listening.
>
> Now, while it is possible, is it desireable? That's a bit more of a
> religious issue, which I'll not address here

Michael, you should really be using service names instead of SID's but
you can have the same SID name used on more than one location. If is
probably not a great idea but it will work. It is also likely to
cause confusion down the line as someone tries to connect to the right
SID at the wrong address.

HTH -- Mark D Powell --

Thanks for all the responses everyone. I suspected it wouldn't be a
problem but I had been informed otherwise . It is only to be a short
term test so we won't be keeping it up after the test.

--
Michael