Planning/Implementation Advice

Posted on 2004-09-06
Last Modified: 2008-03-06
Hey all,

I Am about to set up a DB2 server and wanted to get a critique of what I plan to do. Please feel free to rip this to shreds

Win2k Server
IBM Netfinity
Xeon 2.4GHz
RAID-5 (6 disks, stripesize 16k)
HDD 4.7 avg seek, 10,000 rotation TR 320

The database will be combined OLTP/Queries (Its a financial services system for a small/mid sized company, 70 users using a Java/Browser based front end). Reporting will also be done off this server (mostly out of hours).
I will have 2 massive fact tables which make up about 1/3 of overall data.

I have turned on DB2_STRIPED_CONTAINERS and set DB2_PARALLEL_IO=*

The area I am mainly interested in planning at the moment is physical layout (altho I welcome tips on any relevent area).

Here are my plans:
Put most tables in the userspace1, assigning most of the bufferpool to that space.
Create a DMS tablespace for the 2 big tables, giving eact one 3 containers of about 3GB each.
I intend to make the extent=16 and the prefetch=64.

I am using, does multiple containers give any benefit? Taking RAID into account etc. am I making the right chioce for tablespace/extent/prefetch sizes?
Any feedback on what I have so far? Am I totally deluded?
Cheers in advance.
Question by:meehange
  • 2
  • 2
LVL 18

Expert Comment

ID: 11991116
After some years, my general (means for every dbms) rules of thumb are:
-Raid 5 (or 0+1 when possible because it's really faster) for all logical volumes (+hotswap, hotplug and a spare disk in the bay)
-The db Log files dedicated on a volume (many writes rare read)
-Application + System + db Temp on a volume (some big chunk read&write)
-Index on a small very fast volume (Lowest seek time)
-Data on a large volume (Highest bandwidth)
==> If I can not afford that many volumes :
-step 1 : share db Logs with application-system-temp
-step 2 : share Data and Index

With DB2, the fact that tablespaces are linked to memory cache (bufferpools) make it slightly different because you may imagine having as many tablespaces as pagesize you use...but in fact you don't really care.
Try having prefetch/extent adjusted on your physical page size (means use a medium multiple of your 16K stripesize).
==> Next step is : Monitor your db using the excellent freeware below instead of those terrible db2 "tools"

Hope this helps.
LVL 13

Expert Comment

ID: 11999497
what version of db2 are you going to use?
is this an ee setup or an eee setup?
what growth rate do you anticipate for the large tables?
how many indexes do you plan to have on the large tables?
are the users connecting via internet? intranet?

Author Comment

ID: 12002504
>what version of db2 are you going to use?
Currently 7.2 moving to 8.1 this week

>is this an ee setup or an eee setup?
Workgroup Server Edition

>what growth rate do you anticipate for the large tables?
Hard to say, I'd guess the whole thing will grow by about 1GB per year

>how many indexes do you plan to have on the large tables?
Will depend on tuning efforts once the application is finished

>are the users connecting via internet? intranet?
LVL 13

Accepted Solution

ghp7000 earned 125 total points
ID: 12009758
I would say that in the scenario you have, there is no real benefit to DMS tablespaces, I would go with SMS, it is easier to manage. Set the DB2_PARALLEL_IO variable according to the scenario listed here:
I would put all the tables in the same tablespace, I would put the indexes in another tablespace.
I would mirror the logs (available in v8).
In version 8, DB2_STRIPED_CONTAINERS has no effect.


Author Comment

ID: 12050768
Thanks for the info, I found out this week that we'll be moving to Blades using SAN. So I guess I'll be doing some more research on that now :P

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

November 2009 Recently, a question came up in the DB2 forum regarding the date format in DB2 UDB for AS/400.  Apparently in UDB LUW (Linux/Unix/Windows), the date format is a system-wide setting, and is not controlled at the session level.  I'm n…
Recursive SQL in UDB/LUW (it really isn't that hard to do) Recursive SQL is most often used to convert columns to rows or rows to columns.  A previous article described the process of converting rows to columns.  This article will build off of th…

821 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question