Shedlock, George writes:
> We are conducting a proof of concept for one of our divisions. This includes
> DB/2 9.7 and Suse 10 SP 3 with CKD dasd.
>
> The first opportunity is the defines of tablespaces. In our x86 environment,
> this runs in less that 3-4 minutes (yes, there are a lot of tables). In our
> z/Linux guest that same set of defined runs in about 3-4 HOURS!. The only
> thing we have seen as far as activity is a very large number of disk I/O's to
> dasd. The tables define approx. 800-900 GB. What we think we are seeing is
> that the table spaces are being formatted.
>
> We have tried the "no file system caching" option on the define, but is
> flagged as an invalid option. IBM is saying that this is the default, but
> after the tables are defined and we look at the tables, we see that the
> option is turned on. If we then try to turn it off, it is again flagged as an
> invalid option.
Unless things have changed recently, DB2 V9 for LUW on Linux for
System z only supports "no file system caching" (i.e. direct I/O)
when using FCP SCSI disk access, not with ECKD disk access. I find
this documented in Table 16 ("Supported configuration for table
spaces without file system caching") on pp160-161 of the DB2 V9
"Administration Guide: Implementation" manual (SC10-4221-00). My
copy of the manual is from quite a while back so a newer may have
some changes. Assuming the restriction is still in place, I share
your pain.
Within the constraints of doing without direct I/O, you can at least
try to ensure that your DB2 data is spread and striped across a large
enough number of device numbers (virtual and real, possibly including
PAV devices of various flavours if appropriate) and across enough
channels, back-end disks, ranks and whatever other objects your
back-end DASD subsystem needs to ensure good performance. There are
presentations around which describe the various configuration issues
you need to cover. Without one of those and/or the help of someone
else who knows where to look, you can easily run into bottlenecks due
to configuration rather than fundamental hardware or software.
--Malcolm
--
Malcolm Beattie
Mainframe Systems and Software Business, Europe
IBM UK
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
