Re: Multiplexing Datafiles?

"Adrian Shepherd" <theshepherds_at_ozemail.com.au> wrote in message news:jyRl5.88176$N4.2136496_at_ozemail.com.au...
> What if I want to multiplex datafiles in my database but not run in
> ARCHIVELOG mode for some reason, perhaps because the database would
 generate
> too much archive or if the database is a warehouse that isn't suited for
> ARCHIVELOG mode ?
>
> Multiplexing datafiles seem's a good enough request for me, and more to
 the
> point , redo logs DO NOT supply all the protection you need, perhaps you
> meant archived redo ?
>

You'll have to explain why providing all the redo since the time of the last backup doesn't provide you with all the protection you require. I made no distinction between on-line or archived redo in that statement, and rightly so. I also talked about 'mirroring your redo'. Loose terminology, I guess -but since Oracle 8, it's been possible not only to mirror your on-line logs, but also to 'mirror' your archives -log_archive_duplex_dest for example. Again, I make no distinction between online and archived logs -the fact is, protecting ALL your redo is all you need to ensure total data recovery.

Since it remains a fact that providing all required redo since the time of the last backup guarantees that you will never lose a single committed transaction, I don't quite see what extra protection you'd need or want.

Your proposed solution seems perverse. Instead of generating gigabytes of redo each day, you want to mirror tens or hundreds of gigabytes of datafile. I know which I would prefer to do if disk space was tight.

Whatever. The fact remains, wishlists notwithstanding, there is no facility in Oracle to mirror datafiles within a single database (standby databases etc are a different sort of technology entirely, and are designed to solve different problems), and neither does there need to be.

You are of course entirely free to put the database back into noarchivelog mode, and use external hardware mirroring to protect your datafiles.

Regards
HJR
>
> "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> news:3995df0c$1_at_news.iprimus.com.au...
> >
> > "Rob Jolliffe" <rjolliffe_at_my-deja.com> wrote in message
> > news:8n4295$mqp$1_at_nnrp1.deja.com...
> > > Hi,
> > >
> > > I'm just beginning to learn Oracle, and I was reviewing some Email
> > > regarding Raid5 vs Raid0 performance. It seems Raid 0 is
 significantly
> > > better for performance - but you lose the redundancy of Raid 5 (or
 even
> > > Raid 1).
> > >
> > > I was trying to also determine if in a data tablespace it is possible
 to
> > > multiplex (mirror) datafiles the same way you can with a Redo log
 group.
> > > I was totally unable to determine if you are or are not.
> > >
> >
> > Absolutely not. Never has been, and there never will be -because it is
> > entirely pointless. The reason for duplexing your data files is,
> > presumably, to avoid complete disaster in the event that one of them
 dies,
> > gets deleted, corrupted etc. That is precisely what the Redo Logs are
 there
> > for. Provided you've kept all your redo since the time of the last
 backup,
> > you can reconstruct any given data file up to the precise time of
 failure.
> >
> > So if you're mirroring your Redo, you have provided all the protection
 your
> > data files ever need.
> >
> > (Conceivably, you can use external, hardware mirroring of data files to
> > enable recovery to take place *faster* -you just break the mirror and
 use
> > the good copy. No need to wait for all that Redo to be re-played. But
> > that's a mean-time-to-recovery issue. It's certainly not necessary).
> >
> > > Can anyone tell me? I know you can stripe tablespaces - but can you
> > > mirror them? Perhaps this requires creating two tablespaces and
 somehow
> > > matching them?
> > >
> >
> > Forget it. There's no such concept in Oracle, because the Redo does all
 the
> > protection work we need.
> >
> > Regards
> > HJR
> >
> >
> >
> > > Thanks very much
> > >
> > > -Rob
> > >
> > >
> > > =============
> > > From the desk of Rob Jolliffe
> > >
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> >
>
>
Received on Tue Aug 15 2000 - 04:29:34 CDT