19.06.2013 Views

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

spring cleaning of the directory: Be<strong>for</strong>e migrating it would be very appropriate to free all the<br />

packages that are not being used, reduce SPT01, and migrate faster.<br />

SPT01 is used to store skeleton package tables (SKPTs). These tables store the access<br />

paths to <strong>DB2</strong> data. When a package is executed, <strong>DB2</strong> uses this in<strong>for</strong>mation to access the<br />

data it needs. Because a single SKPT can be longer than the maximum record length that<br />

can be used in <strong>DB2</strong>, SKPTs are stored as a sequence of SKPT sections. The skeleton<br />

package table parent record (SPTR) contains as much of the SKPT section as the record can<br />

fit. The entire SKPT section is stored in this record if it fits; if it does not fit, it is stored in one or<br />

more SPTRs. Each SPTR is identified by a unique section and sequence number.<br />

How long will it take to migrate?<br />

Based on the measurements, you can estimate the migration time first to CM, and then to<br />

NFM.<br />

When migrating to V8 CM, if your catalog is less than 30 GB, your per<strong>for</strong>mance can be<br />

predicted using Figure 9-6. Assuming that the catalog has no major anomalies, the most<br />

important structure to influence the duration of CATMAINT is SYSDBASE, because<br />

CATMAINT does a scan on that structure.<br />

The elapsed time migrating to V8 is certainly longer than it was when migrating to V7 because<br />

<strong>DB2</strong> has to prepare the data <strong>for</strong> later conversion to Unicode at ENFM time. This is the step<br />

that involves a scan of SYSDBASE. <strong>DB2</strong> is not updating every page, as was done in the past,<br />

but it still scans the SYSDBASE.<br />

Estimation based on this graph is only valid <strong>for</strong> a particular CPU and DASD model upon which<br />

this measurement was done.<br />

Seconds<br />

800<br />

700<br />

600<br />

500<br />

400<br />

300<br />

200<br />

100<br />

0<br />

Figure 9-6 Migration times to CM<br />

<strong>DB2</strong> Catalog Migration V7 - V8 CM<br />

0 5 10 15<br />

Gigabytes<br />

20 25 30<br />

CPU time<br />

Elapsed time<br />

Note: The measurements in data sharing showed no difference with non-data sharing and<br />

in the case of migrating from V7 to V8 CM, data sharing was a little bit better in CPU.<br />

Chapter 9. Installation and migration 357

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!