Re: Changing to Raw Redo

Uh, remapping devices and things would be a problem; but more to the point, why do redo in raw partitions? Redos are written to serially, till they're filled, then a log switch, etc. Have you done some analysis that would lead you to conclude that putting your redo log files on raw partitions would alleviate a particular problem?

As far as propagation by (I assume you mean) Oracle Standby, I'm not sure whether it supports raw partitions but I'd be surprised if it did not; you never know, though...

And what kind of link are you referring to, and what is your platform?

I always get a creepy feeling when primary and failover systems diverge in their physical and logical configurations, the same way I get when "TEST1", "DEV1", and "PROD1" are divergent.

One think I've not seen in any system since PLATO, years ago, was a systematic file nomenclature and the most simple and elegant way to solve many dev/test matters [for the system software] (on unspeakably expensive CYBER mainframes); system files had "n", [no prefix], and "o" versions; ie n(ew), current production, and o[ld]; at startup, the entire system could be brought up on the n (development/test/new command invented) level, production, or retreated a layer back to o[ld]. None of this would apply to pure 24x7 ops; most everybody writing code on PLATO were testers of system software as well; one would never make guinea pigs out of real customers.

The really hairy development went on on a separate machine before entering our world, but at $2-$4 million a pop, the notion of a mirrored test and development environment with identical platforms would mean about a $20 million plus setup. The ability to take production down at 11 PM, and 'reboot' it into n-version mode, running on the same hardware, everything, was a great boon for system software developers.

You could do similar things with different instances of Oracle on the same box, more or less; but it wouldn't be as nifty as pushing a different key, and popping development into production, for testing and experimentation. Besides which, I doubt customers would like that.

Returning to the base question before I began yarning, I put everything I can in raw i/o except of course code, scripts, filesystems for incoming / outgoing feeds, UNIX itself and of course all the $ORACLE_HOME subtending directories. But I never did really exhaustive tests to prove that REDOs on raw partitions were superior to those in file systems; of course raw i/o saves memory any way you look at it; and with OPS, you have to have it, period.

To make a long story longer, yes, you could rig it somehow, I believe, though the more divergent the two systems are, the more of a pain it will be and the more meticulous you must be able every single init.ora file, script, etc are checked over 3 times and all are perfect. The question would be, to me, is it worth all that?

RSH.

--
R. S. Hunter
Senior DBA / Architect
VLDB/DW-DM & HA Systems
Great Falls, MT

"Bass Chorng" <bchorng_at_yahoo.com> wrote in message
news:bd9a9a76.0202271552.16bfd2d0_at_posting.google.com...


> I plan to change production redo to raw. But the question is how does this

> affect my standby database ?

>

> I would assume this change would propagate to standby. But on the standby

> I do not necessarily have the same device path. I will face problem when

> I need to activate the standby database, as the redo paths do not exist,

> and Oracle will not be able to create redo logs.

>

> I can use link on production so that the devices are flexible,

> assuming link is transparent to Oracle (?). But does anyone know

> when I need to activate standby, can I create my own controlfiles

> so that I can modify redo paths using local file system paths (not raw)

> and recover database using backup controlfile and then open database

> resetlogs ? (meaning, I will not alter database activate standby

database).


> Would this work ?

>

> Thanks for your answers in advance.