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.

5.1.1 Per<strong>for</strong>mance<br />

MB as default. The FLA design consists of one log read task per recover job and one or more<br />

log apply tasks employing the use of multitasking whenever possible. It takes advantage of list<br />

prefetch and nearly eliminates duplicate synchronous read operations <strong>for</strong> the same page. It<br />

achieves these efficiencies by sorting groups of log records together that pertain to the same<br />

table space be<strong>for</strong>e applying those changes; it then applies those records in parallel using<br />

several log apply tasks, up to 99.<br />

When LOGAPSTG=0 is specified, <strong>DB2</strong> restart will still use a minimum buffer size of 100 MB<br />

<strong>for</strong> FLA during the <strong>for</strong>ward log recovery phase. RESTORE SYSTEM and RECOVER will not<br />

use FLA.<br />

When LOGAPSTG> 0 is specified then:<br />

► <strong>DB2</strong> will use that value <strong>for</strong> the FLA buffer at restart time with a default of 100 MB.<br />

► RESTORE SYSTEM will use FLA during the log apply phase. RESTORE, with APAR<br />

PQ95164, will always try to allocate a FLA buffer of 500 MB. If it cannot get the storage, it<br />

retries with 250 MB, 125 MB, and so on.<br />

► Each concurrent recover utility will use a buffer of 10 MB out of the storage defined by<br />

LOGAPSTG. If no more storage is available, the next concurrent recover utility will execute<br />

without FLA. This means that the maximum value of 100 MB <strong>for</strong> LOGAPSTG allows <strong>for</strong> 10<br />

concurrent recover utilities executing with FLA, the 11th recover will execute without FLA.<br />

For a detailed description on Point-in-Time Recovery, and other disaster recovery functions,<br />

see Disaster Recovery with <strong>DB2</strong> <strong>UDB</strong> <strong>for</strong> z/<strong>OS</strong>, SG24-6370.<br />

In this section we describe the System Level point-in-time recovery per<strong>for</strong>mance<br />

measurement.<br />

Per<strong>for</strong>mance measurement description<br />

For this measurement we used:<br />

► z/<strong>OS</strong> V1R5 with DFSMS, DFSMSdss, and DFSMShsm V1R5<br />

► <strong>DB2</strong> V8<br />

► zSeries 2084 Model 316<br />

► ESS 2105-800, FlashCopy V2<br />

► Copy pool:<br />

– Database copy pool either 67 (27% full) or 195 volumes (10% full)<br />

– Log copy pool 13 volumes<br />

► Copy pool backup:<br />

– 211 volumes <strong>for</strong> the database copy pool<br />

Up to 3 versions available to the 67-volume copy pool<br />

One version only <strong>for</strong> the 195-volume copy pool<br />

– 13 volumes <strong>for</strong> the log copy pool<br />

1 version <strong>for</strong> the 13-volume log copy pool<br />

Per<strong>for</strong>mance measurement results<br />

In this section we present the System Level point-in-time recovery per<strong>for</strong>mance measurement<br />

results.<br />

FRBACKUP PREPARE measurements<br />

See Figure 5-1 <strong>for</strong> the measurement results of FRBACKUP PREPARE. The results show a<br />

non-linear behavior between elapsed time to prepare and the number of volumes in the pools.<br />

Chapter 5. Availability and capacity enhancements 221

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

Saved successfully!

Ooh no, something went wrong!