Backup database vs. Backup database at TS-level time differences

Folks -
>
DB21085I Instance "db2inst1" uses "32" bits and DB2 code release
"SQL08022"
with level identifier "03030106".
Informational tokens are "DB2 v8.1.2.88", "s050422", "MI00117", and
FixPak "9".
Product is installed at "/opt/IBM/db2/V8.FP9".
>
Red Hat AS 4 / fastT700 San 4400
>
We're experiencing 'interesting' differences in backup times when we
backup the database (76gb) at the database-level vs. backing-up at the
tablespace level.
>
What happening is that when we did a full offline backup of the
database 'backup database xyz' it stalls at about 96% (according to
'db2 list utilities')...finally it finishes after 1 hr 20 minutes. I
then backed-up the database tablespace-by-tablespace and found that
when we hit a 32k tablespace with 30,000 pages it took 17 minutes or
about 30 pages/second. 4k tablespaces are being backed-up at anywhere
from 2,000 to 5,000 pages per second.
>
Its interesting because when we run the backup, TOP shows that we go
to 99.9% CPU:
>
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32343 db2inst1 25 0 737m 47m 40m R 99.9 1.2 13:27.68 db2sysc
>
>
[db2inst1@dbps01 ~]$ db2 list utilities
>
ID = 18
Type = BACKUP
Database Name = PSFTPROD
Partition Number = 0
Description = offline tablespace PRODDTAT4K...
Start Time = 02/20/2007 07:18:34.115435
Throttling:
Priority = Unthrottled
Progress Monitoring:
Estimated Percentage Complete = 22
>
Why would DB2 peg at 99.9% CPU?
When DB2 backs-up at the database-level in which tablespace-order are
the tablespaces backed-up?
Why would DB2 struggle with a 32k page?
>
Yes we've looked at the SAN configuration, RHat knobs, Network, etc.
but it doesn't make sense that a 32k page could cause such a problem
(IMHO).
>
Has anybody else seen anything like this and if so what was your
solution?
>
Thanks,
>
-B
>