[sclug] Writing files to 2 places at once?

[Sapan Ganguly]

On 3/3/06, Sapan Ganguly <sapan.ganguly at gmail.com> wrote:
>
>
> Trying not to top-post, see below.
>

Sorry, getting into a mess anyway, replied directly to Roland.


On 3/3/06, Roland Turner (SCLUG) <raz.fpyht.bet.hx at raz.cx> wrote:
> >
> > On Fri, 2006-03-03 at 15:57 +0000, Sapan Ganguly wrote:
> >
> > > I have a good question.  First of all here is my situation, I have a
> > > RHEL3 machine running Oracle, the server is low on disk space (but not
> > > critical yet) so I've attached a disk array to it.  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.
> >
> > You've not made clear how critical getting this right is. Does the short
> >
> > window reflect a technical challenge that you've taken on voluntarily,
> > or is there a serious impact on the organisation of getting this wrong?
> >
> > In the latter case, you _don't_ want to be experimenting.
> >
> > > I've been thinking along thsese lines, all the filesystems involved
> > > are journalling (ext3), I've also been reading about FAM (File Access
> > > Monitor) and IMON (Inode Monitor).  I may be barking up the wrong tree
> >
> > > but what do you all think?  Should I be able to use both or one of
> > > these tools to let Oracle write to its datafiles in the current
> > > location and to my new location at the same time?
> >
> > I don't have the impression that either of these tools gives you
> > block-level update information, but even if it did, you probably don't
> > want to bet that you can get a synch algorithm working correctly first
> > time.
> >
> > Why not use Oracle's own tablespace replication facilities?
> >
> > > I've tried an rsync whilst the database is running, the first run took
> > > ages as expected...but so did the second run, third etc.  I haven't
> >
> > The time constraint is computational, not I/O. Rsync is calculating a
> > sliding checksum over every block of every source file and every _byte_
> > (-boundary) of every destination file on each run. It's ability to save
> > time on subsequent runs by skipping unchanged files is impaired in this
> > case because even a single byte change in a 2GB file will change the
> > mtime and force rsync to have to process the entire file (both source
> > and destination) to locate the change, if any.
> >
> > Rsync is also designed to work on files that aren't changing during the
> > sync operation.
> >
> > > So, what do you think?  Am I being silly?
> >
> > Yup. Re-inventing Oracle facilities is a time-honoured tradition amongst
> > DBAs, but not a wise one.
> >
> > - Raz
>
>
>
> Alex, the LVM snapshot solutions looks very cool and the new Oracle
> servers will use LVM when they let me buy a new one.
>
> David, will that work the same on Oracle datafiles?   I'll experiement on
> our test system.
>
> Roland, I didn't build the current Oracle server and I'm not a DBA so I'm
> interested in the tablespace replication facilities you mentioned.  We have
> a new DBA, he seems to think that we only have two options -
>
> 1. We take a big downtime hit, shutdown the database copy all the
> datafiles across and start up again
> 2. We do each tablespace seperately, put the tablespace into backup mode,
> copy the datafiles across and the apply the redo logs that build up in the
> mean time.
>
> Both these solutions will end up with the same amount of downtime whether
> it be all in one go or split up over a few days.
>
> Don't worry, we have a long way to go before this is critical and I do all
> my experimenting on a test system.
>
> Oh, and yes, the short window does reflect a technical challenge I have
> taken on voluntarily, although we can probably could get a whole day of
> downtime this wouldn't look good for us techie's and our customers have been
> sold a 24x7x365 service and I would like to do my best to provide this even
> though I don't have the infrastructure for it.....yet.
>
> Thanks for your comments guys.
>
> Sapan
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tmdg.co.uk/pipermail/sclug/attachments/20060303/1b5cced6/attachment-0001.htm