By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,924 Members | 1,727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,924 IT Pros & Developers. It's quick & easy.

What effects size of incremental delta backup?

P: n/a

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

Feb 13 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
Feb 13 '07 #2

P: n/a
On Feb 13, 4:40 pm, Phil Sherman <psher...@ameritech.netwrote:
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.
Thanks Phil, I'll look into this.

/Lennart
Feb 13 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.