Oracle data guard using crossover cable ok?

I haven't actually done it, but I would think you should be able to do it with just a crossover.

As long as you can get the listener to make connections across it and log shipping to move the logs, it should be fine.

I would think it would be a pretty quick test.  You don't actually have to build the standby, just start the log shipping and make sure they start going across.

Well, yes I think it would work, but I guess what I am really asking is whether Data Guard is subject to the same kind of risks as RAC whereby using crossover cables isn't supported due to some NIC cards which hang when the link goes down (media sensing) on the far end, say due to a reboot, blue screen, etc.

From what I am reading, Data Guard should just pick up where it left off once both servers are back up.

Here's a discussion of what I am referring to. I can see how this is an issue for clusters but I am wondering if this applies to Data Guard use also.

https://forums.oracle.com/forums/thread.jspa?threadID=2243978

Further, the whole reason I am wondering is because the public network I have is a wimpy 10Mb/s (and not easily upgraded) so I need something a lot faster between the two servers.

Would you happen to have a link to where the docs talk about an "optional destination" as you mentioned?

Is there a way I can specify the preferred route for it to use and still have both routes available if one or the other goes down?

Here is the link to the LOG_ARCHIVE_DEST parameter that you would set for log shipping:

http://download.oracle.com/docs/cd/E11882_01/server.112/e24448/initparams122.htm#I1010086

This link is for the section in the Data Guard doc that describes setting up redo transport (aka log shipping):

http://download.oracle.com/docs/cd/E11882_01/server.112/e22491/log_transport.htm#i1148216


The route that will be taken is specified by the service you set up in the tnsnames.ora file.  I would suggest that route rather than specifying the full connect string in the log archive destination.  You would need 2 listeners running on the destination, one on the interconnect and one on the public interface.  If one goes down, simply switching the tnsnames.ora entry would force the connection to the other interface.

Alternately, you could set up 2 log destinations on the standby server.  One through the interconnect and one through the public interface.  If one goes down, the other should continue to function.  You may have to manually move around some files in this case, but everything should get there.

Be aware that in the event of a hung server, neither destination would work.

Thanks a lot for this info! This pretty much answers it I think, just need to try it out when the time comes.

Cheers!