Hi,

I am working a benchmarking project wherein we have to do performance & volume testing with 18TB of DB2 database (version 9.7) with AIX 5.3 (p series) as database servers with OLTP applications.I am not sure whether to define containers as raw device or filesystem.

I have always learned that raw devices are better than filesystem when it comes to performance but I recently read in the following link that its better to have filesystem containers over raw devices (please note that the link was recently updated in Oct,09 which means the ideas suggested in the link are not old ones).

IBM developerWorks : Best Practices: Database Storage

I am confused..Please suggest because the tablespace design would highly impact benchmarking results.

Times have changed. I doubt whether you still have local disks on your server. It will be SAN/LUN's right? That means that the times of raw-disks are over. No big deal: you can override the file-system caching in you tablespace definition and that equals out your performance loss.

At one time there was a performance benefit to raw devices because there was no file system caching by the OS (which is redundant to bufferpool caching) if one used raw devices.

However, you can now define all your DMS tablespaces with no file system caching, so there is no measurable performance benefit for raw devices anymore. However, remember to put your LOB objects in a separate Long tablespace when the table is created, and you should use file system caching for these tablespaces since LOB's do not use bufferpools (except with Version 9.7 we now have inline LOB's up to 32K if a so-defined).

The file system caching was actually one of the main reasons to use raw devices. The caching done by the operating system was just adding another caching layer, robbing memory from the DBMS and providing useless double-buffering. With direct I/O, these times are over and it is generally preferable to have a simpler administration over squeezing out another 1% of performance.

Typically, more severe performance problems exist in other places like missing proper indexes, misconfigured memory heaps, crappy SQL statements, applications that don't treat a DBMS as a DBMS but rather as a dump file system, ... If you want to do real performance testing going to the high-end (e.g. TPC-x), you should get in touch with the IBM labs to get dedicated support. There are people who are working full-time on performance tuning and performance improvements in DB2.

Btw, you could have up to 32K "inlined" LOBs in DB2 V7 already if you wrapped them into structured types. That made accessing those LOBs rather messy, but it did and still does work. :-)

That is what is said in my post above. Please read it again.

Right - we agree. What's the problem?

(You just posted a few minutes before me, and I needed some time to write, too. So I did see your post before I klicked on "Submit". I just edited my post and added the comment about the option to inlining short LOBs afterwards.)

Thanks Guys!!!