471,582 Members | 1,354 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,582 software developers and data experts.

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 3755
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
reply views Thread by XIAOLAOHU | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by lumer26 | last post: by
1 post views Thread by lumer26 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.