I recently had to recover a tablespace and it seemed to run so slow. I simplistically think of a recovery as the reverse of an image copy and that's what puzzles me. The image copy was done at the tablespace level and took 32 minutes and the restore phase of the recovery of the data took 492 minutes. This was followed by the log apply phase and rebuilding the indexes, but my only question is about the length of the restore phase.
Here are the details of the tablespace which is using index based partitioning and contains 34 million pages of data.
CREATE TABLESPACE RAT8A01
USING STOGROUP SATVP000
PRIQTY 720000 SECQTY 720000
FREEPAGE 10 PCTFREE 20
DSSIZE 64 G
The recovery was RECOVER TABLESPACE DAT8P000.RAT8A01 DSNUM ALL REUSE TOLOGPOINT X'C7A97FCF0A94'
The image copy was contained on twenty tapes. I'm also puzzled with the wide variation in the time it took to read each tape. Here are the twenty values in minutes:
26, 44, 29, 5, 4, 4, 8, 18, 24, 35, 5, 5, 3, 48, 43, 42, 48, 58, 5 ,37
I understand that if the image copy was done at the partition level, then the recovery would have been much faster based on the use of parallelism. So what happens internally during the restore phase
of a DB2 tablespace recovery that causes it to run so long ?
Thanks in advance for your help,
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
Register NOW for the IDUG DB2 Tech Conference in Anaheim, May 2-6, 2011!
If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L
is the home of IDUG's Listserv