Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: physical standby database managed/non-managed

Re: physical standby database managed/non-managed

From: Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl>
Date: Wed, 25 Jan 2006 21:51:24 +0100
Message-Id: <1138222284.15763.36.camel@dbalert199.dbalert.nl>


David, Sandeep,

I've several clients that have implemented several security layers. As I just learned from Jared through another information source SQL*Net is not particularly the safest protocol on earth. If it weren't the network boys, probably the DBA should take care of not opening a SQL*Net port.

I agree that port forwarding makes the system more dependent from more stuff that can fail. Alas, these days one has to take care of security. I do not know the exact topography of Sandeeps network. Maybe he has to go through a network that is more public than one would like to have for sending over database stuff.
Of course there is the argument that damagement should allow for a dedicated connection. At least, if one wants to protect the data, one should invest some money in a proper configuration. What's the standby database worth when it cannot be reached when it needs to become the primary database? What's the cost of a serious outage or data loss? What is the insurance premium they pay for the building? How does that correlate to the potential damage data-loss incurs to the company? Investing in redundancy is paying an insurance premium.

But now I'm getting way off-topic. The question is: how to connect to systems through a couple of hops and firewalls? Answer: create a tunnel, using ssh or whatever VPN technology available. Proper monitoring, redundant firewalls an proper setup can take care of most problems when a connection disappears and restore it automagically. I wouldn't advocate a MAXIMUM PROTECTION setup in these circumstances. Using the LGWR ASYNC or ARCH option in the log_acrhive_dest parameter value is the best you can get. It seems not to be a problem, because Sandeep is already in the phase of considering unmanaged standby by rsync'ing the archives to the standby.

Sandeep, go to the business or manager or whoevers concern the data availbility is and ask: how much data-loss is acceptable? How much recovery time is acceptable? These questions guide you to the proper requirements for the network connection. It's the business' responsibility to give you the budget for dark fiber between your database servers if needed, or whatever infrastructure you need. You're databases serve data needs for applications and users, and the network guys provide the infrastructure for your database (and applications and users). The 'raison d'etre' of the network is it's plain existence self. There are some guys around who need to learn that when the phone rings, their food is calling. Respect their concern about network security. Do not ask for a solution, but call them on their pride: they are the guys that can solve network problems. You have a network problem, a challenge. Ask them to cooperate in finding a solution for the challenge you are facing.
(apologies, ending off-topic again)

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Wed, 2006-01-25 at 15:46 +0000, David Sharples wrote:
> the trouble with that is that you are then reliant on middle servers
> being up and working all the time.
>
> I still don't see the reason for this doing in this case apart from
> 'network guy said no sqlnet' which is hardly a good reason
>
>
> On 1/25/06, Carel-Jan Engel <cjpengel.dbalert_at_xs4all.nl> wrote:
>
> Sandeep,
>
> ssh allows for port-forwarding, if your network guys didn't
> diable this.
> I it is possible to create a so-called tunnel through
> portforwarding, even
> when several hops are involved.

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 25 2006 - 14:51:24 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US