The Hermit Hacker wrote:
>
> On Mon, 27 Dec 1999, Karel Zak - Zakkr wrote:
>
> > - raw i/o device storage manager
>
> I can't see this ever happening, since it would require having to write
> low-level device drivers, vs using what the OS already has ...
>
> One thing someone *did* mention though was that Linux(?) now has (or is
> working on?) low level functions to do this...I'm not sure what would be
> involved to use this functionatilty though...anyone in the Linux camp able
> to respond?
>
> Basically, if "low_level_read()" was found by configure, add in the
> functionality? Something like that?
>
I haven't used raw partitions on ORACLE, but I believe its
something like:
CREATE TABLESPACE ADD DATAFILE '/dev/sda1';
instead of:
CREATE TABLESPACE ADD DATAFILE
'/home/oracle7/dbs/moredata.dbs';
so all ORACLE is doing is maintaining its own "filesystem"
on top of either block special devices or filesystem files
using read(), write(), fcntl() and ioctl(). Since you have
to specify before-hand how much data to allocate, ORACLE
will preallocate '/home/oracle/dbs/moredata.dbs' as 100M, or
whatever. In the case of a special block device, it uses the
entire partition. This allows you to put your "HOT" data on,
say a mirrored RAID0+1 partition, and leave the rarely
accessed stuff lie around as files on the filesystem.
> Just curious though...how do you monitor something like that? Say I do
> this on a 4gig file system, and it fills up? Then what?
You had to SELECT from a system catalogue under version 6.0
- or use monitoring tools. I think ORACLE added
automatically extensible tablespaces in version 7, although
I suppose RAW partitions couldn't work that way. When it
filled up, you would log into SQL*DBA and do a:
ALTER TABLESPACE ADD DATAFILE '/dev/sda2';
to add another partition. That's why DBA's get the big
bucks....right?
Mike Mascari
