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