How to differentiate between Raw disk or Cooked

[Chris Swecker]

How would you tell if a database instance is using Raw disk space as
opposed to
cooked file space.

The only way that I could tell would be using the 'onstat -d' which
would list out the offsets and size of my dbspace.

If the database was using Raw disk space, then the chunks would have
different offsets (other than all zero)
if more than one dbspace resides on the same chunck.

With cooked files the offsets would all be zero.

The following is Raw disk;

Chunks
address chk/dbs offset size free bpages flags pathname
c9583178 1 1 0 5000 3769 PO-
/usr/informix/dbspaces/foo/primary/ln2/rootdbs
c9583250 1 1 0 5000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln2/rootdbs
c9583408 2 2 0 5000 947 PO-
/usr/informix/dbspaces/foo/primary/ln1/physdbs
c9583ba0 2 2 0 5000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln1/physdbs
c95834e0 3 3 5000 75000 4947 PO-
/usr/informix/dbspaces/foo/primary/ln1/logdbs
c9583c78 3 3 5000 75000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln1/logdbs
c95835b8 4 4 80000 100000 99947 PO-
/usr/informix/dbspaces/foo/primary/ln1/tempdbs
c9583690 5 5 5000 100000 10177 PO-
/usr/informix/dbspaces/foo/primary/ln2/pstable1
c9583d50 5 5 5000 100000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln2/pstable1
c9583768 6 6 0 100000 18077 PO-
/usr/informix/dbspaces/foo/primary/ln3/psindex1
c9583e28 6 6 0 100000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln3/psindex1
c9583840 7 5 105000 12500 12241 PO-
/usr/informix/dbspaces/foo/primary/ln2/pstable2
c9583f00 7 5 105000 12500 0 MO-
/usr/informix/dbspaces/foo/mirror/ln2/pstable2
c9583918 8 6 100000 6000 5527 PO-
/usr/informix/dbspaces/foo/primary/ln3/psindex2
c9583fd8 8 6 100000 6000 0 MO-
/usr/informix/dbspaces/foo/mirror/ln3/psindex2
c95839f0 9 6 106000 12500 12497 PD-
/usr/informix/dbspaces/foo/primary/ln3/psindex3
c95840b0 9 6 106000 12500 0 MO-
/usr/informix/dbspaces/foo/mirror/ln3/psindex3
c9583ac8 10 5 130000 12500 6729 PO-
/usr/informix/dbspaces/foo/primary/ln2/pstable3
c9584188 10 5 130000 12500 0 MO-
/usr/informix/dbspaces/foo/mirror/ln2/pstable3
10 active, 2047 maximum

Also if a database is setup with Raw disk, is it possible to copy these
chunks to another disk-array
as a means of migrating the data to a different volume group ?

My thoughts are that this cannot be done with Raw disk, but you can do
it with Cooked files.

Any info would be helpful.

Thank you.

Christopher Swecker

[Ronald]

On Sat, 18 Aug 2001 10:50:34 -0400, Chris Swecker
<cswe...@netscape.net> wrote:

>How would you tell if a database instance is using Raw disk space as
>opposed to
>cooked file space.

Onstat -d is ok.
then do a ls -al to the chunk path. when the 1st character of the
rights is a - then its a file, else if the 1st character is a c then
its a raw device.

>If the database was using Raw disk space, then the chunks would have
>different offsets (other than all zero)
>if more than one dbspace resides on the same chunck.

Not true. When you would use a volume manager you can also have raw
devices on the same disk and all with a offset of zero.

>Also if a database is setup with Raw disk, is it possible to copy these
>chunks to another disk-array
>as a means of migrating the data to a different volume group ?
>
>My thoughts are that this cannot be done with Raw disk, but you can do
>it with Cooked files.

If you create your dbspaces with a direct link to the disk you will
not be flexible with the chunks.
However its a good thing to do, even if not thinking of needing it to
make a symbolic link to the disk, or volume and then create the
dbspace with the path option to this link.

Ronald

[Paul Watson]

Chris Swecker wrote:
>
> How would you tell if a database instance is using Raw disk space as
> opposed to cooked file space.

Look at the file path and it'll be there in the file permissions

>
> The only way that I could tell would be using the 'onstat -d' which
> would list out the offsets and size of my dbspace.
>
> If the database was using Raw disk space, then the chunks would have
> different offsets (other than all zero) if more than one dbspace
> resides on the same chunck.
>
> With cooked files the offsets would all be zero.

Not necessarily, you can still offset in cooked files

[cutting]

>
> Also if a database is setup with Raw disk, is it possible to copy these
> chunks to another disk-array as a means of migrating the data to a
> different volume group ?

A number of ways, using Informix mirroring, use the LVM or just plain
old dd

>
> My thoughts are that this cannot be done with Raw disk, but you can do
> it with Cooked files.
>
> Any info would be helpful.
>
> Thank you.
>
> Christopher Swecker

--
Paul Watson #
Oninit Ltd # You are only young once
Tel: +44 1436 672201 # but you can be immature
Fax: +44 1436 678693 # for ever
www.oninit.com #

[Chris Swecker]

First I want to thank both Ronald and Paul for setting me straight on
determining what type of
disk is being used ; either Raw or Cooked.

I hadn't thought about the first character using the "ls -al" ---- Thanks

Still not sure about my second question.
If your database instance with no mirroring (either Informix or OS)
is using soft links to the VG on Disk Array (1) and you want to copy this
data to your new Disk Array (2)
How would you go about it ?

I don't think that you could use the "cp" command with Raw disk space.
and Ronald is the "dd" command just a Unix data dump ?

Chris

Chris Swecker wrote:

--

Christopher Swecker
Architect / DBA

[Neil Truby]

> Still not sure about my second question.
> If your database instance with no mirroring (either Informix or OS)
> is using soft links to the VG on Disk Array (1) and you want to copy this
> data to your new Disk Array (2)
> How would you go about it ?

Obviously you don't value my advice, however ... :-)

dd is a UNIX data dump, but that's what you need. If you don't like or
understand dd, you could take a level 0 archive, break the link from the
chunkname to disk array 1, re-create to disk array 2 and restore. Or, you
could set up a load of links to disk array 2, use IDS mirroring to create
mirrors on these chunks, shut down the database, swap the links arounnd so
that the primaries now point to disk array 2 and the mirrors to disk array
1, bring up the server, and drop the mirrors.

If I had the downtime and a small number of chunks I'd use dd. Otherwise
I'd use one of the other methods.

[Paul Watson]

Neil Truby wrote:
>
> > Still not sure about my second question.
> > If your database instance with no mirroring (either Informix or OS)
> > is using soft links to the VG on Disk Array (1) and you want to copy this
> > data to your new Disk Array (2)
> > How would you go about it ?
>
> Obviously you don't value my advice, however ... :-)

Nah, Scottish companies are soooo much better than Surrey ones :-))))

>
> dd is a UNIX data dump, but that's what you need. If you don't like or
> understand dd, you could take a level 0 archive, break the link from the
> chunkname to disk array 1, re-create to disk array 2 and restore. Or, you
> could set up a load of links to disk array 2, use IDS mirroring to create
> mirrors on these chunks, shut down the database, swap the links arounnd so
> that the primaries now point to disk array 2 and the mirrors to disk array
> 1, bring up the server, and drop the mirrors.
>
> If I had the downtime and a small number of chunks I'd use dd. Otherwise
> I'd use one of the other methods.

As Neil [note the credit:-))] playing with the links/mirroring is the
only option if don't want the downtime, even if you can take the
downtime
it's still a nice method and when you have to do it for real on proper
system it's not that scary.

[Chris Swecker]

Neil,

I very much value your advice, I was looking for more detailed information than

what you were willing to give the first time around.

My persistence paid off though, you came through with flying colors on the
second try.
Thank you sir for your help.

Chris