Re: Raw partitions vs. file system

S V <sv1_at_mindspring.com> wrote in article <01bce5a5$896cba60$585c0c26_at_sfinance3>...

> 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.
 <snip>
> Backup time = 5 1/2 hours (run as 6 parallel processes).

Hmmm.. I'll pass this info on to our Unix Admin.

> Isn't it cool?

Yeah - I piss ice cubes too. :-)

> 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.

I'll stand and raise you. :-) With raw devices there are also overheads. From a 2GB raw slice I can get a 1.8GB datafile. OPS complains if it's any higher.

> how often one would shuffle datafiles on a production system?

Rephrase that to how often one would shuffles datafiles around on a brand new production system that caters for 6+ databases, batch and online processing, and has not been properly sized ito users and transactions. So you monitor the disks and filesystems to see which files are hammered where and when from which databases to design an optimal distribution of datafiles across filesystems and spindles. And as soon as you have everything humming ok, a new application is rolled out to a 100 users (without telling you) and suddenly a sar shows you that some disks are 100% busy and the CPU usage is peaking at over 90%. That's to say if a manager doesn't phone you first, screaming that their application's response times have more than trippled and you must fix it in the next 10 minutes or he escalates it to the IT director because the response times are totally unacceptable....

Don't we just LOVE the corporate life and the users! :-)

> The original problem was in using SQL*Loader to load
> data into Oracle.

<snip>

Exact same problems that we had. But FTP -> pipe -> DD -> pipe -> SQL*Loader solved it. Some months later I had this sales guy visiting me trying to sell me a data load/flow management tool. After I showed him how fast we get the data from the mainframe into Oracle with good ol' Unix commands, he left quitely. ;-)

regards,
Billy Received on Tue Nov 04 1997 - 00:00:00 CST