From an online infocenter lookup of "delta backup":
Note:
If a table space contains long field or large object data and an
incremental backup is taken, all of the long field or large object data
will be copied into the backup image if any of the pages in that table
space have been modified since the previous backup.
This reads that if one page has been modified; then ALL long data will
be backed up. Long binary data may not compress well, especially if it's
already compressed (ie. jpeg images).
You could move the tables containing LOB type things to another
tablespace. I don't see this as an answer, however, because, unless
there's no updating of them, you will still need to backup the tables
containing the LOB data.
LOBs can also be stored in their own tablespace. This may be a better
solution for your needs. You'll need to verify how incremental backups
handle LOB only tablespaces to see if this will decrease the size of
your backups.
Phil Sherman
Lennart wrote:
We have recently moved a ClearQuest database to db2 V8 on linux. We
take a full compressed backup on sundays (~400Mb) and compressed
incremental/incremental delta other weekdays. What puzzles me is that
despite low activity in the database, the delta backups are the same
size as the full backups.
Using db2look I've found that there is a number of tables with BLOBS
in them. Would it help to move theses tables to a separate tablespace
(currently all tables located in userspace1)?
Any suggestions welcome
/Lennart
