IBM Support

Recovering Records from Damaged Files

Troubleshooting


Problem

This document describes how to copy good records out of a damaged file.

Resolving The Problem

Before attempting to recover records from damaged files, ensure the cause is isolated and corrected. Also, ensure that the damage symptom is not caused by a software bug.
 
Caution: If the file or table is part of an application, the application provider must be contacted for recovery instructions.

If assistance is needed finding all possible objects that could be damaged, please refer to appropriate sections of the Backup and Recovery Guide for guidance.

There are sections in the Backup and Recovery Guide that apply to each type of recovery.

In addition you can refer to TechNote  Check Damage on Physical Files (CHKPF)

It describes a way to locate all damaged records within files.

You can also refer to Information APAR II10690 for more information.

This document describes an alternative method to recover files that were not journaled and have damaged records.

To recover as many undamaged records as possible, do the following:

NOTE: This example uses library name of liba and file name of X. Replace this with the actual library name and file name that is damaged. 
NOTE: This example uses library libb as a working area to contain the newly created file.  Replace libb with any library name you prefer.  If the damaged file contains a primary key constraint, QTEMP should not be used for libb.
1. On the operating system command line, type the following:

OVRDBF FILE(x) SEQONLY(*YES 1)

Press the Enter key. The OVRDBF command ensures that the file to be copied is processed sequentially, one record at a time, without the use of an access path.
2. On the operating system command line, type the following:

CPYF FROMFILE(liba/x) TOFILE(libb/x) CRTFILE(*YES) FROMRCD(1) ERRLVL(999) COMPRESS(*YES)

Press the Enter key.

Notes:
a Save libb/x to a SAVF or tape as a backup in case library libb is lost.
b If there are problems with the copied from file, consider manually creating the file that you are going to copy to. For example, the CPYF command would use CRTFILE(*NO) rather than CRTFILE(*YES). In addition, the SQL statement CREATE TABLE could also be used.
3. On the operating system command line, type the following:

Note: Find all logical file (LF, SQL Indexes, SQL Views) with DSPDBR of the physical file (SQL term: Table) then save the LF's to a SAVF without access paths and then delete them. When the new PF is moved back, then they can be restored. You may also have the DDS source, SQL source, Generate SQL

DLTF liba/x

If the file cannot be deleted because of logical files, rename the original file to another name in the same library. Press the Enter key.
 
4. On the operating system command line, type the following:

MOVOBJ OBJ(libb/x) OBJTYPE(*FILE) TOLIB(liba)

Press the Enter key. If the original had logical files, rebuild the same logicals over the new copy of the file.
5. Did you rename the original file in Step 3? If you did not rename the original file in Step 3, omit this step. If you did rename the file in Step 3, on the operating system command line type the following:

DLTF liba/all_logicals_over_renamed_physical and DLTF liba/renamed_physical

The CPYF command creates a new copy of the file that contains all of the records that could be accessed. The damaged records are noted in the job log. The value indicated for the ERRLVL parameter should be considered a threshold value to be set by the user to indicate how many damaged records of data are to be tolerated before replacement from a backup copy is deemed necessary. Exceeding this threshold limit terminates the CPYF command.

After the CPYF command has completed, the user should compare the total number of records found in the new version of the file with that of the old. If this value is the same for both files, there appears to have been no loss of data. If this value is found to differ between the two files, it might be necessary to recover those records missing from the new version of the file through data entry, backups, and so on.

If it is necessary that the file be processed as a direct file, the deleted records must also be copied to the new file. This is accomplished by changing the value of the COMPRESS parameter to *NO.
The CPYF command uses the parameter FROMRCD(1) to avoid possible damage in the access path.

Note: There may be other things that need to be added back to physical file, such as triggers and constraints.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"Db2 for i","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]

Historical Number

N1010721

Document Information

Modified date:
04 March 2021

UID

nas8N1010721