|
Problem IC65251
|
Status: Closed |
"INCREMENTAL/INCREMENTAL DELTA" BACKUP FOLLOWING AN INTERRUPTED FULL BACKUP WILL SCAN EXTRA TABLE SPACES |
| product: |
DB2 FOR LUW / DB2FORLUW / 950 - DB2 |
| Problem description: |
If you interrupt a full backup, the subsequent
"INCREMENTAL/INCREMENTAL DELTA" backup will scan extra table
spaces that do NOT have eligible data for this backup.
Normally DB2 should not scan data on these table spaces during
"INCREMENTAL/INCREMENTAL DELTA" backup.
However when a full backup is interrupted, DB2 wrongly sets some
internal flags on the table spaces included in the full backup.
As a result, DB2 believes these table spaces have eligible data
for the subsequent "INCREMENTAL DELTA" backup.
This problem only occurs in databases where the configuration
parameter "TRACKMODE" is set to YES.
This issue will bring a big overhead to the "INCREMENTAL DELTA"
backup if the "extra table spaces" are large in size, as the
scan on extra table spaces are time-consuming and totally
unnecessary.
To find out which table spaces are included in an "INCREMENTAL
DELTA" backup, issue "list tablespaces" command when the backup
is running to get the hexadecimal state values of the table
spaces.
You can then use "db2tbst" command to get the state from the
hexadecimal state value and see which table spaces are in state
of "Backup in Progress".
Please note:
Normally, at the beginning of "INCREMENTAL/INCREMENTAL DELTA"
backup there is a short period of time during which you will see
all table spaces are in state of "Backup in Progress". This
because DB2 is checking some meta data on all table spaces to
decide which of them have eligible data and will be included in
the backup image.
The checking on meta data will not last for long as the meta
data is small in size. After it finishes, table spaces that do
not have eligible data will be back to state of "Normal" and
only table spaces that have eligible data will remain in state
of "Backup in Progress".
Therefore, only if a tablespace has been under the "backup in
progress" state for a long time during the backup, should you
consider it's indeeded being backed up. When you see table
spaces in state of "Backup in Progress" at the beinning of
"INCREMENTAL/INCREMENTAL DELTA" backup, they might be in stage
of "checking on meta data".
The wrong internal flags on table spaces will be changed back to
normal after a successful backup on these spaces. And then the
problem will be gone. |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* All users of version 9.5 on Linux, Unix and *
* Windowsplatforms. *
****************************************************************
* PROBLEM DESCRIPTION: *
* If you interrupt a full backup, the *
* subsequent"INCREMENTAL/INCREMENTAL DELTA" backup will scan *
* extra tablespaces that do NOT have eligible data for this *
* backup.Normally DB2 should not scan data on these table *
* spacesduring "INCREMENTAL/INCREMENTAL DELTA" backup.However *
* when a full backup is interrupted, DB2 wrongly setssome *
* internal flags on the table spaces included in the *
* fullbackup. As a result, DB2 believes these table spaces *
* haveeligible data for the subsequent "INCREMENTAL DELTA" *
* backup.This problem only occurs in databases where *
* theconfiguration parameter "TRACKMODE" is set to YES.This *
* issue will bring a big overhead to the "INCREMENTALDELTA" *
* backup if the "extra table spaces" are large in size,as the *
* scan on extra table spaces are time-consuming andtotally *
* unnecessary.To find out which table spaces are included in *
* an"INCREMENTAL DELTA" backup, issue "list tablespaces" *
* commandwhen the backup is running to get the hexadecimal *
* statevalues of the table spaces.You can then use "db2tbst" *
* command to get the state from thehexadecimal state value and *
* see which table spaces are instate of "Backup in *
* Progress".Please note:Normally, at the beginning of *
* "INCREMENTAL/INCREMENTALDELTA" backup there is a short *
* period of time during whichyou will see all table spaces are *
* in state of "Backup inProgress". This because DB2 is *
* checking some meta data onall table spaces to decide which *
* of them have eligible dataand will be included in the backup *
* image.The checking on meta data will not last for long as *
* the metadata is small in size. After it finishes, table *
* spaces thatdo not have eligible data will be back to state *
* of "Normal"and only table spaces that have eligible data *
* will remain instate of "Backup in Progress".Therefore, only *
* if a tablespace has been under the "backupin progress" state *
* for a long time during the backup, shouldyou consider it's *
* indeeded being backed up. When you seetable spaces in state *
* of "Backup in Progress" at thebeinning of *
* "INCREMENTAL/INCREMENTAL DELTA" backup, theymight be in *
* stage of "checking on meta data".The wrong internal flags on *
* table spaces will be changedback to normal after a *
* successful backup on these spaces.And then the problem will *
* be gone. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 UDB Version 9.5 FixPak 6 or higher levels. *
**************************************************************** |
| Local Fix: |
|
| available fix packs: |
DB2 Version 9.5 Fix Pack 6a for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.5 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
First fixed in DB2 UDB Version 9.5 FixPak 6. |
| Workaround |
not known / see Local fix |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 21.12.2009
25.05.2010
25.05.2010 |
| Problem solved at the following versions (IBM BugInfos) |
9.5.
|
| Problem solved according to the fixlist(s) of the following version(s) |
