## 9.4 Backup and RECOVER 

In Db2 12, RECOVER always uses one parallel task to overlap read and write during the RESTORE phase, even if the PARALLEL keyword is not specified. This configuration results in more efficient processing because reading the pages from the image copies and restoring pages to the buffer pool processes can occur asynchronously. 

The use of hardcoded DD statements to pre-allocate the image copy data sets on tape in the RECOVER job step is no longer supported and causes allocation errors. 

## 9.4.1 Performance measurements 

This feature is available in V12R1M100. 

RECOVER performance of a single table space and a list of partitions of a partitioned table space showed up to 27% CPU improvement in the RESTORE phase compared to Db2 11. 

Because of this improvement in the RESTORE phase, RECOVER showed no regression overall. 

## 9.5 Decompression improvement in utilities 

In Db2 11, decompression improvement was introduced to access rows in a compressed table space. This feature substantially reduced CPU usage in Db2 11 when many compressed rows are processed by SQL queries because Db2 partially decompresses only the necessary data and applies software algorithm. In Db2 11, this feature was limited to SQL access and not used by utilities. 

In Db2 12, the software algorithm improvement during decompression is also enabled for utilities. This enablement demonstrated noticeable improvement in utilities under zEC12. This feature is available in V12R1M100. Around the same time, the system z13 processor also provides better compression performance by using hardware improvement. Because z13 improvement applies for Db2 11 and 12, we observed less improvement in DB12 that used z13 compared to the case that used zEC12. 

