[sclug] Writing files to 2 places at once?

[Sapan Ganguly]

On 3/4/06, Keith Edmunds <keith at midnighthax.com> wrote:
>
> Sapan Ganguly wrote:
> > I've set myself the task of moving the Oracle datafiles (about 90 files
> > 2.0Gb or more each) to the new disk array without any down time...or
> > maybe a small amount of down time, certainly no more than 1 hour.
> .
> > So, what do you think?  Am I being silly?
>
> You need to answer one question: what is more important, the length of
> downtime or the integrity of the data? I don't know your situation, but
> I'd suspect the latter. If that's the case, imposing arbitrary downtime
> limits won't help at all. If it were me, I'd investigate the possibility
> of getting more time to do the job properly. If this system is vital for
> business, what steps are taken to provide a hot standby system? Maybe
> you can link into that to get a copy of the data. If there is no hot
> standby then that tells you something about how vital this system really
> is.
>
> Sorry to sound negative, but trying a fancy and complex solution to a
> very simple problem (copying data from one disk to another) is likely to
> result in problems.
>

Hi Keith, there is one thing I haven't mentioned yet.  Whoever designed this
whole setup did think about fault tolerance/resilience but I think they were
in rush.  The live database server is in Germany, the hot standby is in the
UK at the other end of a 2Mbps VPN.  There is no local resilience, only
geographical.  Shipping a redo log down the VPN every 20 minutes to the
standby is fine but sending huge amounts of data (as I would have to when I
switch back from standby to live) would take a very long time.  Our DBA
hasn't suggested switching to the standby for a period of time and then
switching back and I suspect this is the reason why.  Also they've never
actually tested a failover of just the database on its own with the rest of
the infrastructure running in Germany, it should work but it may run too
slowly to be useable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tmdg.co.uk/pipermail/sclug/attachments/20060304/4f7f6c77/attachment.htm