When performing incremental backups, DB2 keeps track of whether table spaces have been modified  since the last backup. If a table space has not been modified since the last backup, the scanning of  that table space can be skipped. However, if even one page has been modified in a table space,  every page in the table space must be scanned to find the modified page. This can result in the  db2med  EDU being idle for a long time, and can potentially cause storage managers to think that the  backup is hung and to close down the connection to the  db2vend  process. This results in a failed  backup. Make sure to set idle timeout values with the storage manager appropriately. Incremental and delta backups are designed to be smaller than full database backups, not faster. If  the incremental or delta backup can skip the scanning of some table spaces, the backup might be  faster than a full database backup. If all table spaces must be scanned, the extra scanning of the  page headers to determine whether a page belongs in the backup image might cause the backup to  take longer than a full database backup. Consider several items to maximize the performance of database backups: DB2 automatically picks an optimized value for the number and size of the backup buffers. The  buffers are allocated from the utility heap, which is controlled by the  util_heap_sz  database  configuration setting. The minimum buffer size is 8 (4 KB) pages and the maximum buffer size is  16384 (4 KB) pages. The ideal size of all combined buffers is 90% of the utility heap for offline  backups, and 50% of available space in the utility heap for online backups. The number of buffers is  dependent on the number of  db2bm  and  db2med  EDUs selected for the backup. Default values for  the number of buffers and the size of buffers can be overwritten by specifying  'WITH  num-buffers BUFFERS'  and  'BUFFER  buffer-size '  in the  BACKUP DATABASE  command. The size of the  backup buffer is +1 of a multiple of the extent size. This plus one page is to accommodate the object  header that precedes each block of user data in the backup image. At the start of the backup, each  db2bm  EDU is assigned to back up an individual table space. The  table spaces are backed up in order of decreasing size. The size is determined by multiplying page  size by the number of used pages. When a  db2bm  has completed one table space, it processes the  next largest table space in the list. If there are no remaining table spaces, the  db2bm  is idle until the  backup is completed. The number of  db2bm  EDUs created is based on the number of processors  (CPUs) available, and can be manually adjusted using the  PARALLELISM  parameter of the  BACKUP  DATABASE  command. At the start of the backup, one or more  db2med  EDUs are started. If the database is being backed up  to disk, the number of  db2med  EDUs is based on the number of output directories that are listed in  the  TO  clause of the  BACKUP DATABASE  command. If the database is being backed up to a storage  manager, the number of  db2med  EDUs is based on the  'OPEN <N> SESSIONS'  option of the  BACKUP DATABASE  command. Each  db2med  EDU writes to its own output device. When a table space has a single container, the reads for the table space are performed directly by the  db2bm  EDU. When a table space has multiple containers, the read operations are performed by the  db2pfchr  (prefetcher) EDU instead of directly by the  db2bm . This can enable faster reads because  parallel I/Os can be issued across multiple containers at the same time.  Prefetching z Parallelism z Buffer size and number of buffers z Backup performance considerations Maximizing Performance of IBM DB2 Backups 3