Re: Raw partitions vs. file system

Billy Verreynne <vslabs_at_onwe.co.za> wrote in article <01bce501$56493ea0$f3040059_at_billyv.vslabs.co.za>...
> S V <sv1_at_mindspring.com> wrote in article
> <01bce47d$a431bfe0$c85c0c26_at_sfinance3>...
>
> > > What about backups? To backup raw devices in Unix (when you don't
 have
> > > any special backup software) you need to use dd - and I won't rely on
 dd
> > > backups for a database.
> >
> > what's wrong with "dd" ???
>
> To my knowledge there are no verification with dd and it is very slow -
> especially if you have to back GB's every month.

dd is indeed slow if used with its default bs=512 or less. If used with bs=4k or larger multiple of OS block sizes it blows away any other disk/file read command.

I'm backing 90Gb data warehouse, almost all sitting on a raw logical volumes using dd and compressing backup files on the fly so the cold backup takes only about 20-25 Gb of disk space.
Backup time = 5 1/2 hours (run as 6 parallel processes). I'm doing it every weekend in fully automated mode. System = RS6000 with 6x604e CPUs.

Isn't it cool?

> And having to run dd
> backups for over 24 hours gets to be a problem in a production
 environment.
>
> > I would rather rely on dd which is absolutely
> > reliable piece of soft furniture, tested over generations than on some
> > third-party tools full of bugs.
>
> We're using a 3rd party X-based tool. Works great! - and it outperforms
 dd
> by far.
>
> > well, this is simply NOT TRUE.
> > All it takes
> > to move a datafile from /dev/rlv01 to /dev/rlv02
> > is
> > ALTER TABLESPACE AAA OFFLINE;
> > dd if=/dev/rlv01 of=/dev/rlv02 bs=4k skip=1 seek=1
> > ALTER TABLESPACE AAA RENAME DATAFILE '/dev/rlv01' TO '/dev/rlv02';
> > ALTER TABLESPACE AAA ONLINE;
>
> Ah ok - I retract that it's not impossible. :-) But what you fail to
> mention that you must make sure that the raw slices should be the same
 size
> or else you'll waste space.

I'm afraid you would have to retract that one too.. Consider this: any time you create a filesystem you already wasted _at least 5% of disk space. And this is considering you utilize all available space on that filesystem for database files, which never happens in normal circumstances. As is well known the filesystem's perfomance starts sucking rocks if it gets over 90% full.
So you _must waste at least 15-20% of disk space if you're using cooked files and want a good perfomance.

> With file systems you have more flexibility.
> You can have multiple variable size datafiles per file system. With raw
> devices it is a single fixed size datafile per raw slice. Shuffling data
> files around on file systems are much easier.

how often one would shuffle datafiles on a production system?

> The biggest problem IMHO is that you require solid Unix skills to
> administer and maintain raw devices - and this is usally outside the
 scope
> of knowledge required by an Oracle DBA.

fortunately or not, our personnel had to learn dd even before I moved database to raw devices.
The original problem was in using SQL*Loader to load data into Oracle. The amount of data to be loaded is humongous and it comes on tapes so the offloaded from tapes data files can be as big as 6Gb and it's all ebcdic. Oracle 7.3 on AIX DOES NOT handle files larger than 2Gb. In fact SQL*loader cannot even open such files. So "dd" is a real saviour here. Not only it reads files > 2 Gb it can convert them from ebcdic to ascii and feed them via named pipe to SQL*loader.

Regards,
Serge

> > to delete raw device it takes _at least root access to the box.
> > I would never use root account for running a database.
> > To delete a cooked file, it suffices to be only oracle,
> > which is a step lower level of security.
>
> Agreed, but only the DBA should have oracle access. But too often
 security
> is lax and developers have root and/or oracle access. I don't think that
> security should be a factor when it comes to raw vs cooked files.
>
> regards,
> Billy
>
>
>
Received on Fri Oct 31 1997 - 00:00:00 CST