469,287 Members | 2,453 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,287 developers. It's quick & easy.

What effects size of incremental delta backup?


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
2 3608
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
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.

Similar topics

1 post views Thread by jane | last post: by
3 posts views Thread by Peter Postlbauer | last post: by
3 posts views Thread by apple | last post: by
reply views Thread by Skyline | last post: by
5 posts views Thread by Joel Matthew | last post: by
4 posts views Thread by shenanwei | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.