db2ckbkp - Check backup command
This utility can be used to display the metadata stored in the backup header. It can also be used to test the integrity of a backup image and to determine whether or not the image can be restored. The validation performed by this tool is capable of identifying many types of structural integrity problems, including data, index, and XML object page checksum validation failures, as well as anomalies in meta information of these pages.
- Whether the version of a data page reflects what Db2 last wrote to the table space container file on disk (that is, a lost I/O write) is not identified.
- Any logical discontinuity between data on a page and the objects correlated to this data, such as indexes, constraints, or MQTs, is not identified.
- Whether the version of a data page resides in the location within the table space container file on disk where Db2 wrote it (that is, a misplaced I/O write), will not be detected if the misplaced data page resides in a different table space in a location where a page of the same objectID is expected.
- The integrity of LOB or Long Field data pages are not validated.
- For SMS table spaces, integrity validation is limited to assuring page counts are correct per object, no further validation is performed.
Authorization
Anyone can access the utility, but users must have read permissions on image backups in order to execute this utility against them.
Required connection
None
Command syntax
Command parameters
- -a
- Displays all available information.
- -c
- Displays results of checkbits and checksums.
- -d
- Displays meta information from the headers of DMS and Automatic Storage tablespace data pages.
- -e
- Extracts pages from an image to a file. To extract pages, you will need an input and an output
file. The default input file is called extractPage.in. You can override the
default input file name by setting the DB2LISTFILE environment variable to a
full path. The format of the input file is as follows:
For SMS table spaces:
S <tbspID> <objID> <objType> <startPage> <numPages>
Note:For DMS table spaces:- <startPage> is a page number for the given object type within the specified table. It represents a 0-based offset from the start of that object.
D <tbspID> <objType> <startPage> <numPages>
Note:For log files:- <objType> is only needed if verifying DMS load copy images.
- <startPage> is a page number that represents a 0-based offset from the start of the table space.
For other data (for example, initial data):L <log num> <startPos> <numPages>
O <objType> <startPos> <numBytes>
The default output file is extractPage.out. You can override the default output file name by setting the DB2EXTRACTFILE environment variable to a full path.
- -h
- Displays media header information including the name and path of the image expected by the restore utility.
- -l
- Displays log file header (LFH) and mirror log file header (MFH) data.
- -n
- Prompt for tape mount. Assume one tape per device.
- -o
- Displays detailed information from the object headers.
- -p
- Displays the number of pages of each object type. This option
will not show the number of pages for all different object types if
the backup was done for DMS table spaces data. It only shows the total
of all pages as
SQLUDMSTABLESPACEDATA
. The object types forSQLUDMSLOBDATA
andSQLUDMSLONGDATA
will be zero for DMS table spaces. - -s
- Displays the automatic storage paths in the image.
- -t
- Displays table space details, including container information, for the table spaces in the image.
- -v
- Performs extended page validation of DMS and Automatic Storage tablespace data pages. This
option is not implied or enabled by the -a (all) option.
Along with the basic checksum and structural validation performed on the data pages, extended validation will attempt to validate if meta information within the page headers appear valid and reflect normal operating bounds.
- -cl decompressionLib
- Indicates the name of the library to be used to perform the decompression. The name must be a fully qualified path referring to a file on the server. If this parameter is not specified, Db2 will attempt to use the library stored in the image. If the backup was not compressed, the value of this parameter will be ignored. If the specified library cannot be loaded, the operation will fail.
- -co decompressionOpts
- Describes a block of binary data that will be passed to the initialization routine in the decompression library. Db2 will pass this string directly from the client to the server, so any issues of byte reversal or code page conversion will have to be handled by the decompression library. If the first character of the data block is '@', the remainder of the data will be interpreted by Db2 as the name of a file residing on the server. Db2 will then replace the contents of string with the contents of this file and will pass this new value to the initialization routine instead. The maximum length for string is 1024 bytes.
- -kspassword password
- Specifies the password to use when opening the keystore.
- -kspassarg fd:file_descriptor | filename:file_name
- Specifies the keystore password arguments. The file_descriptor parameter specifies a file descriptor that identifies an open and readable file or pipe that contains the password to use. The file_name parameter specifies the name of the file that contains the password to use.
- -ksprompt
- Specifies that the user is to be prompted for a password.
- -H
- Displays the same information as -h but only reads the 4K media header information from the beginning of the image. It does not validate the image. This option cannot be used in combination with any other options.
- -S
- Displays the same information as -s but does not validate the image. This option cannot be used in combination with any other options.
- -T
- Displays the same information as -t but does not validate the image. This option cannot be used in combination with any other options.
- filename
- The name of the backup image file. One or more files can be checked
at a time. Note:
- If the complete backup consists of multiple objects, the validation will only succeed if db2ckbkp is used to validate all of the objects at the same time.
- When checking multiple parts of an image, the first backup image object (.001) must be specified first.
Examples
db2ckbkp SAMPLE.0.krodger.DBPART000.19990817150714.001
SAMPLE.0.krodger.DBPART000.19990817150714.002
SAMPLE.0.krodger.DBPART000.19990817150714.003
[1] Buffers processed: ##
[2] Buffers processed: ##
[3] Buffers processed: ##
Image Verification Complete - successful.
db2ckbkp -h SAMPLE2.0.krodger.NODE0000.CATN0000.19990818122909.001
=====================
MEDIA HEADER REACHED:
=====================
Server Database Name -- SAMPLE2
Server Database Alias -- SAMPLE2
Client Database Alias -- SAMPLE2
Timestamp -- 19990818122909
Database Partition Number -- 0
Instance -- krodger
Sequence Number -- 1
Release ID -- 900
Database Seed -- 65E0B395
DB Comment's Codepage (Volume) -- 0
DB Comment (Volume) --
DB Comment's Codepage (System) -- 0
DB Comment (System) --
Authentication Value -- 255
Backup Mode -- 0
Include Logs -- 0
Compression -- 0
Backup Type -- 0
Backup Gran. -- 0
Status Flags -- 11
System Cats inc -- 1
Catalog Database Partition No. -- 0
DB Codeset -- ISO8859-1
DB Territory --
LogID -- 1074717952
LogPath -- /home/krodger/krodger/NODE0000/
SQL00001/LOGSTREAM0000
Backup Buffer Size -- 4194304
Number of Sessions -- 1
Platform -- 0
The proper image file name would be:
SAMPLE2.0.krodger.NODE0000.CATN0000.19990818122909.001
[1] Buffers processed: ####
Image Verification Complete - successful.
BufAddr MemberNum PoolID Token Type Offset FileSize ...
-------- --------- ------ ----- ---- ------ -------- ...
00000000: 0 0 0 19 0 268 ...
Output
(continued):... ObjectSize OrigSize Object Name
... ---------- -------- -----------
... 268 0 "BACKUP.START.RECORD.MARKER"
numTbspsInDB : 3
numTbspsInImg : 3
Total members : 3
Member numbers: 0,1,2
Usage notes
- If a backup image was created using multiple sessions, db2ckbkp can
examine all of the files at the same time. Users are responsible for
ensuring that the session with sequence number
001
is the first file specified. - This utility can also verify backup images that are stored on
tape (except images that were created with a variable block size).
This is done by preparing the tape as for a restore operation, and
then invoking the utility, specifying the tape device name. For example,
on Linux® and UNIX operating systems:
and on Windows:db2ckbkp -h /dev/rmt0
db2ckbkp -d \\.\tape1
- If the image is on a tape device, specify the tape device path.
You will be prompted to ensure it is mounted, unless option -n is
given. If there are multiple tapes, the first tape must be mounted
on the first device path given. (That is the tape with sequence 001
in the header). The default when a tape device is detected is to prompt the user to mount the tape. The user has the choice on the prompt. Here is the prompt and options: (where the device I specified is on device path
/dev/rmt0
)
The user will be prompted for each device specified, and when the device reaches the end of tape.Please mount the source media on device /dev/rmt0. Continue(c), terminate only this device(d), or abort this tool(t)? (c/d/t)
- This utility can also verify backup images that are stored on remote storage. This is done by
specifying the location of the backup images. For
example:
db2ckbkp -H DB2REMOTE://ibmcos/db2-bkp-test/images/SAMPLE.0.db2inst1.DBPART000.20210804193955.001
- When running db2ckbkp
-e on SMS and DMS table spaces, you may receive the following error message:
The error message is caused by the following reasons:Could not find the specified page range in the image
- The specified page does not exist in the database at the time of backup.
- The backup image is an incremental or delta image, and the specified page exists in the database
but has not been changed since the last backup.
You can run db2ckbkp -o to figure out what pages are in the image and then re-run db2ckbkp -e with the correct
startPage
.