Database setup

Edit online

To perform our performance tests, we had to setup our database. Our database was spread across two different devices, each with its own file system.

Database layout

The database layout on the DB2® on z/OS® LPAR was inherited from previous tests. We found that it differed in some areas from the layout used on the database on Linux®.

We found that there were several differences between some of the Trade 6 database settings on DB2 on Linux versus the settings for DB2 on z/OS. We made the changes described below because we expected them to improve the performance.

The following items were changed on the database on z/OS to make it comparable to the database on Linux on System z™:
  • There is a difference in the database table structure between z/OS and Linux. The ORDEREJB table on z/OS has three additional indexes defined that are not defined on Linux DB2. (The extra indexes are: ORDERCLOSX, ORDER EXACTIDX, and ORDERETYPIDX.)

    This difference could be expected to cause higher processor utilization for operations that cause changes to the indexes as well as longer overall response times due to the hardening of the additional indexes at commit times. Because the updated indexes are serialized until they are committed, this could increase overall response times.

    We created the indexes so that they were the same on z/OS as they were on Linux.

  • The 'varchar()' data types default to padded versus not padded on z/OS. This can affect processor utilization and latency by causing additional table accesses. We changed them to be unpadded on z/OS.
  • The database on z/OS is stored in EBCDIC while on Linux it is stored in UTF-8.

    This causes data translation on the database on DB2 on z/OS. On Linux, however, the data is stored in UTF-8, which requires less translation overhead. The translation on the z/OS system uses additional processor. For head-to-head comparisons we changed the z/OS database to also use UTF-8.

  • The database on z/OS defaults to non-volatile. Under some cases this could cause a sequential search of the entire file instead of the use of an index to access the information in the file. We changed the default to "Volatile," which always causes the index to be used.

After making the changes described above, the databases were comparable and represented a standard setup for the Trade 6 workload.

Logging setup

On Linux we used one dedicated file system on a 3390 mod3 DASD for the DB2 logs. The DB2 log files were set as shown below:
  • eight 128M logs or three 512M logs
On z/OS, DB2 is using two logs on two volumes with 3300 cylinders each.
  • FEPDB2.LOGCOPY1.DS0A on volume DB9C37
  • FEPDB2.LOGCOPY1.DS0B on volume DB9C38