DB2 UDB 7.2 fp 7 on AIX 5.1

We are contemplating moving to DMS tablespaces and the question came up of whether they should be raw or cooked. One question about raw, we will be obliged if anyone can share is, can we use the same device for multiple tablespaces? We currently have 5 containers per tbsp, SMS and are considering 6 or 8 containers per tablespace DMS.

Also what are your thoughts on raw vs cooked.

You divide one disk drive into PhysicalPartions(PP) of 32 or64Meg etc. size; you can create muliple LogicalVoluMes(LVM) by allocating different number of PPs. Each LVM is a raw partition; AFAIK you cannot use 2
containers in ONE LVM(DB2 does not allow an offset to indicate the start of a tablespace container). If you use Filesystem, when db2 requests I/O, it comes to AIX cache and then it is tranferred(memory to memory)to db2 bufferpool.With raw,NO AIX I/O cache ;You can allocate almost all your memory to DB2; very little to AIX. Performance improvement is said to be 5-50% depending on the pattern of I/O. Direct I/O feature,
allows JFS to be accessed as 'raw' without the AIX file cache. JFS very easy to handle; with familiarity, raw is not that difficult to manage

If you have an OLTP database or small/medium size IW database, raw may not be have much benefit, especially if you have large buffer pools. Large and very large databases can benefit from raw, especially when doing lots of tablespace scans.

Thank you for your insights. We have a multi TB system(~10) and growing. However, that includes data and indexes. About 4TB of raw data.

As far as memory goes, 32-bit db2 can only address a max of 1.6 GB so we are good there. However, I have heard that there is a Direct I/O mounting option for DMS filesystems - this is supposed to reduce the OS OH. Any insights on this?

Also, one of the SANs under consideration round robins data and mirror on (2+2) disks on a raid 1+0 system. That it my mind raises the question of what is contiguity and how it can be achieved in such a scenario.