Re: Raw Devices: Increased Performance?

On 29 Jun 1996, Christoph Torlinsky wrote:

> I dont mean to sound too ignorant..but what exactly is a cooked and
> raw database (?). We are talking about Logical volume manager databases
> correct? The only one I have seen on svm is the one that is used also
> with raw device vols (which are not newfsed, my understanding)and regular
> filesystem type vols. These are usually placed in slice 11 (for us) as
> partition type 6, which I assume is always raw ? no?

Actually, I believe that they are talking about raw/cooked databases, as in Oracle or Informix. The basic difference is as follows:

Raw: DB engine manages /dev/rdsk/qdX or qdXsX directly, handles buffers

     itself, buffers being similar to DOS's smartdrv (yeah, whatever...)
     Covered in System Administration 1.
Cooked: OS manages partition, and actually has a filesystem on it.  The
        database engine just has a BIG file sitting on it that hold data.
        The OS manages the buffers.

This is why when you run a system with Oracle or whatever you have to carefully decide what BUFPCT to use. If you use raw partitions, you want to give more memory to Oracle for buffering, which does a much better job that the OS, because it understands the structure of the database a helluva lot better than the OS does.

With a low BUFPCT, the database can allocate more memory for it's buffers. If you use cooked databases, the OS needs a higher BUFPCT so it can do the buffering itself.

> ps: I have never hosed an svm database myself, I did get them out of
> synch, say if a pbay went down , and it didnt come on during bootup,
> but I always have two good database which make for the error
> (usually placed on qcic 0) which my understanding svm does an rdcp
> to replicate those db's, which means that they are always raw? no?

Under SVM 1.x, databases are on a partition of type 6. I'm not sure of the particulars of those versions, but I believe that the database sits on a partition autonomously. I know that in the next version it distributes it across private sectors intelligently, so if there's a failure it always has copies of it floating around. For all I know, 1.x does the same. I certainly hope so... ;-)

But the real issue is the difference between raw and cooked. Basically, raw partitions are where the application (either Oracle, Informix, etc., or SVM) accesses the partition/disk directly, via the /dev/rdsk entry. The OS doesn't care what it does. With cooked partitions, the OS sits there and translates the traffic back and forth.

> : FUD: Fear, Uncertainty, and Doubt

Quite a useful thing, I'd think... ;-)

> : >Personally, I think the one time that someone unthinkingly writes over
> : >the raw system will more than make up for any increase. In other words,
> : >it requires greater control over administration than any place can be
> : >expected to have over a long period of time.

Wait a minute... I thought that when a program takes over control of a partition it locks it somehow. I don't know the specifics, but I know that such things are possible (what exactly I probably shouldn't say, just one of those Sequent internal things...) Nonetheless, I know it is possible to lock a partition from anything else touching it, especially if it's the disk itself. I know that when you have a VTOC on a disk and run devbuild it, you can't rdcp -z to the /dev/rdsk/qdX, and if you have a partition newfs'd and mounted, you can't write to the /dev/rdsk/qdXsX.

> : Yet I have taken four calls (that I can remember) in the past six
> : years from customers who have accidentally blown away their cooked
> : database.

From what I understand of cooked databases, this seems quite easy. After all, the DB engine just puts a big file on the filesystem and plays around with it. If the DB engine hasn't been started, it seems quite easy to "accidentally" remove that file, especially if it's an incompetent at the controls...

  __ Erik Walthinsen - Programmer, webmaster, 3D artist  / \
| | M E G A Teleport ISP: omega_at_teleport.com _\ /_ Sequent Computers: omega_at_sequent.com

Sequent Symmetry Archive: http://www.teleport.com/~omega/sequent (temp loc.) Received on Sun Jun 30 1996 - 00:00:00 CEST