Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2003

    Unanswered: DMS on raw question

    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.

  2. #2
    Join Date
    Sep 2003
    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

  3. #3
    Join Date
    May 2003
    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.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  4. #4
    Join Date
    Mar 2003
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts