oracle 10g installation on raw file system and backup

[A. Clay Stephenson]

I'll also add one of the major problems with raw i/o --- especially if LVM or VxVM is bypassed but even if not. It is trivially easy to overwrite "unused" space. Documentation is extremely important when raw devices are in play.

The only time I would consider using raw i/o for databases is with Oracle RAC (or OPS) but now that the Cluster File System (CFS) is available for 11.23 then even Oracle RAC can use fully-cooked files.

[Chan 007]

Hi Shiv,

I totally agree with Clay's comments, also I am pretty sure that Oracle 9 and upwards will provide equal performance on RAW or cooked file system.

Data Protector will take a complete rlvol for backing up if you choose. e.g you have a /dev/vg01/rlv_oracle of 1GB, the it will take a complete snapshot of 1GB.

Whereas if you have a File system backed up, if your FS is only 700 MB /1GB then only 700MB will be back-uped.

Chan

Chan

[Hein van den Heuvel]

>> I was told by some DBAs that control files, data files, and redologs should be installed on raw file systems for better performance and excellent i/o.


At best it is a minor effect positive effect, at worst raw devices give a major negative effect (poor sga tuning).
I would not worry about raw untill you see the application is exhausting CPU and IO resources. It really needs to be a very IO intense applications to 'see' the potential benefit from raw. Don't start there unless you must (RAC, and then it is a moot question).

two remarks though.

1) "Cold OS backups are out of the question on raw." and similar comments...
I beg to differ. Of course you can use OS commands (notably dd) to make backups from raw devices. It's just more tricky to get it right. I used to use a (perl :-) script which would query Oracle for all the db file names and sizes. It would parse the sqlplust output and fork multiple (dd if=xxx bs=yyy count=zzz | gzip > backupfile) commands which would run concurrently. Real easy, once the hard work is done :-). Oh yeah... restore worked fine also, and it had an option to restore into a file based structure.

2) if performance becomes a problem and your application is IO intense, then you may find that the bulk of the critical IO is to REDO, UNDO and TEMP. Those are all easy re-created as RAW at any point in time.
Further more, they could be flipped to small & fiebased just before a backup, and recreated large and raw just after a backup.

Cheers,
Hein.