It means even while using dedicated server and if the listener is remote u've to register through and mts_dispatcher.
If listener is not remote then no need of using this parameter.
Am I correct ?

You said

"If the listener were remote, it would not be able to start
the dedicated server, hence the listener must be co-located with the server when using a dedicated server configuration"

Please see

</code> http://download-west.oracle.com/docs/cd/B10501_01/network.920/a96580/listener.htm#490372 <code>

It says "Registration to remote listeners, such as in the case of Oracle9i Real Application Clusters, can be configured for shared server or dedicated server environments

If you want PMON to register with a remote listener, configure the REMOTE_LISTENER parameter in the initialization parameter file to locate the remote listener"

That contradicts with what you said above, doesnt it?

The documentation makes it seem like I can do

lsnrctl start on server1

Go to server2 and set

remote_listener='(address=(host=server1)(port=1521))'

and my Oracle clients out there can request a dedicated server connection with the listener on server1 and it somehow spawns a dedicated server process on server2

Is this correct?

Thanks

This is interesting, how would this be used in a Data Guard physical standby configuration during a planned switchover

Would the following work?

Primary:
service_names=primary,standby
log_archive_dest_2='service=standby'
fal_client=standby
fal_server=primary
remote_listener='(address=(protocol=tcp)(host=standby)(port=1521))'

Standby:
service_names=primary,standby
log_archive_dest_2='service=standby'
fal_client=standby
fal_server=primary
remote_listener='(address=(protocol=tcp)(host=primary)(port=1521))'

This way, both instances are registered with both listeners.

So, without changing my pfile/spfile, I can do the DataGuard switchover and things should continue to work, right?

All my 100s of Oracle clients out there would continue to use a tnsnames.ora entry pointing to (host=primary)(service_name=primary) and it would always connect to the listener on the "primary" server and that would either hand off the connection to the local instance (if it is the primary) or redirect it to the other listener if that is the primary. Does that sound right?

But how would the listener know which instance is the real primary instance?

Thanks

Also, is there a performance impact with using this remote_listener redirect feature vs connecting with the co-located listener directly?

Thanks

Thats why I clarified that I am talking about a planned switchover operation where I intentionally want to switch the roles of the primary and standby databases. In this case, every thing would be up and running, I just want to swap the roles. Thats what the switchover feature is for, right?

Would my configuration work for this?

Regarding performance, what I wanted to know was is there a performance impact due to the redirect? How does it work exactly? The remote listener accepts the connection, realizes that the service request is for some other host, redirects the request there and that listener proceeds to spawn the dedicated server connection. How expensive is all this compared to directly connecting to the co-located listener?

Thanks

Why do you keep saying "the premise is PRIMARY JUST BLEW UP". That is not the premise. This is not a failover, its a planned switchover.

Both the machines are up, both the listeners are up, the roles of the 2 databases are swapped, thats all.

Would my configuration work as seamlessly as I am hoping it will?

Thanks

The reason we would do this kind of switchover would be to simply "exercise" our Disaster Recovery procedures, not just for Oracle but the entire IT infrastructure of which Oracle is just a part. Lets say some crucial Windows servers in the environment failed and we need to switchover parts of the IT server farm (including Oracle) to a remote site. In this case, the scenario I outlined would kick in.

In case of a real failure of the primary server, we would simply modify our internal DNS to make "primary" resolve to the IP address of the standby server. So, no tnsnames.ora changes would be needed, the (host=primary) would seamlessly go to the standby server and since the standby instance has been failed over to primary using the apppriate DataGuard procedures, everything would work seamlessly. Make sense?

Thanks

What "better way" are you referring to? Connect time failover?

Lets see how that would work in both my scenarios

The documentation says CTF is configured by using the following tnsnames.ora entry

primary=
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=off)
(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=primary)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=standby)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=primary)))

1. Switchover: Both databases/listeners are up. I follow DataGuard procedures to switch the roles of the 2 databases.

Now what? My clients are still going to try to connect to "primary" as per the tnsnames.ora above since that listener is up. But the database on that server is now in MOUNTED mode doing managed recovery. So my clients would get the error "database not open".

Also, how would Data Guard's log transport work from the new primary (former standby) to the old primary (current standby)? What log_archive_dest_2 should the new primary specify?

2. Failover: Here, the primary site goes down, database, listener, everything is unavailable. I follow DataGuard failover procedures and bring up the standby as ny mew primary. Connect-time failover would kick in as per the above TNSNAMES entry and all my clients would seamlessly connect to the new primary.

Say it takes me a week to fix whatever hardware/software problems caused the old primary to go down. Now I want to make it the primary again. I would need to backup/restore the new primary back to the newly fixed primary server, put it back in the DataGuard configuration as a standby, then follow DG switchover procedures to make this my primary. Now clients would find the primary listener again and life is back to normal. Sounds ok?

So I guess my only issue is my switchover scenario in (1) above where I have a lot of unanswered questions. Any thoughts?

Thanks

primary=
(DESCRIPTION=
(ADDRESS_LIST=
(LOAD_BALANCE=off)
(FAILOVER=ON)
(ADDRESS=(PROTOCOL=tcp)(HOST=primary)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=standby)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME=primary)))

How long does the SQLNet client layer wait for a response from the (host=primary)'s listener before connecting to (host=standby)'s listener? 1 second, 2 seconds? What determines this?

If primary goes down (as per my failover scenario above), wouldnt this timeout (always try primary then failver to standy) affect performance of my client applications?

Also, even when everything is up and running on the primary, suppose there is a network hiccup that causes the connection to primary listener to take longer than whatever timeout CTF expects? Wouldnt that cause a "false" alarm and make my clients connect to the standby database and get the "database not open" error?

Thanks

Thanks a lot for your comments, I never thought of using a different port number for a listener exclusively for Data Guard purposes. I guess I would need a listener.ora file which I dont currently have because I am using the default LISTENER and dynamic instance registration, but thats ok.

But it would be a much more flexible solution, not require DNS changes and use Oracle's connect-time failover feature.

Thanks again.

Hm, wait a minute. So I would have 2 listeners on each server, a) default LISTENER at port 1521
b) dg_listener at port 1522

How would the instance register with both listeners? When the instance starts up, PMON would register with the default listener at port 1521. What would make it register with the 1522 listener?

Thanks

Well, you said earlier

"You can run the data guard listener on yet another port entirely"

I took that to mean I run my regular listener on 1521, this is the one all my clients connect to. I take this down to activate my planned switchover. But I still need a listener for DataGuard log transport/apply services.

In a multi-node 11gR2 RAC box, the remote_listener value suggested by oracle is scanname.example.com:1521. This works fine. However, we have a "Site to Site" enviroment and replication between these two sites are done at SAN level. The cluster and the SCAN name (IPs) are all different on the other site. If a database failover to the other site, the value of remote_listener will also be copied over (it doesn't change to the SCAN name the other cluster has). Later, when an application tries to connect to the other site, they get TNS connectivity issue.

How to resolve this issue?

Thanks,

Thanks. Regarding Listener challenges, our team came up with an option by defining a tns entry (we just named as SCAN_LISTENER) and used that as the value in REMOTE_LISTENER value. The SCAN_LISTENER entry in the server tnsnames.ora file are different (but this is ok for now).

About your other suggestion of using DG, we are very keen on zero data loss. Can DG promise that? We do have data guard on some servers but the databases are not mission critical. Also about the network traffic, can we measure how much bandwidth data guard is taking to move redo files through the network?

Thanks,

Thank you. The example you have provided about the number of blocks is outstanding. It answered lot of my subconscious question as well.