Don't let improperly managed deleted records slow down system performance.

When records are deleted or marked for deletion, they may remain as part of the physical file. It is a good practice to run the RGZPFM command to remove deleted records and free up DASD. Removing deleted records can improve performance of programs that read a file sequentially. It can also help reduce the paging of data in from DASD to memory. The recommendation is to run RGZPFM if the number of deleted records exceeds 20 percent of the total number of records in the file.

Tip: You can use DSPFD to verify the number of deleted records and the total number of records in a file. 

Question #1: Will the File Be Corrupt if I Cancel a RGZPFM Before It Completes?

Answer: It depends.

It depends on which phase the RGZPFM was canceled in, and it depends on which parameters were used with the RGZPFM command. You can learn more about the different parameters with RGZPFM at the IBM Infocenter.

Based on the parameters used, three or four phases may be associated with RGZPFM:

Phase #1: All access paths (logical files and indexes) associated with the physical file will be invalidated. This phase should be completed fairly quickly.

Note: This phase will only happen if you take the default value RBDACCPTH(*YES). If you take RBDACCPTH(*NO), the access paths will be maintained during the execution of the RGZPFM command.

Tip: RGZPFM will complete faster if you choose *YES for Rebuild Access Paths. If you choose *YES for Rebuild Access Paths, you may see CPF3135 message:

Message ID . . . . . . . . . :   CPF3135

Message file . . . . . . . . :   QCPFMSG

Library  . . . . . . . . . :     QSYS

Message . . . . :   Access path for member &2 already in use.

CPF3135 will prevent RGZPFM from running successfully because an exclusive lock is needed for access paths to be rebuilt. To circumvent this message, specify RBDACCPTH(*NO).

Phase #2: During this phase, the records will be compressed. The non-deleted records will be copied into the deleted records space. At the end of this phase, there will be freed-up space (deleted records space).

Note: If you take the default value for KEYFILE (*NONE), the system will compress the records in no specific order. If you specify a value for KEYFILE other than *NONE, the reorganized physical file will have its arrival sequence changed to match the keyed sequence of this key file.

Phase #3: All access paths (logical files and indexes) will be rebuilt.

Tip: The access paths (dependencies) associated with a physical file can be verified via DSPDBR command.

Tip: The rule of thumb for the access path rebuild is an average of 10,000 records per minute.

Tip: Make sure sufficient memory is allocated to *BASE (Memory pool 2) before the access path rebuild to help speed up the access path rebuild.

Phase #4: The freed up-space (deleted records space) will be deallocated.

Note: In order for this to happen, the system needs to have an exclusive lock on the physical file. If the parameter LOCK is set to *EXCL or if during the time the system is ready to execute phase #4 the file is not being used, then the system will be able to complete the removal of deleted records and reclaim storage. If an exclusive lock was not specified with RGZPFM, you may see message CPF5729:

Message ID . . . . . . . . . :   CPF5729                

Message file . . . . . . . . :   QCPFMSG                

  Library  . . . . . . . . . :     QSYS                 

Message . . . . :   Not able to allocate object &1.  

This message will not prevent RGZPFM from completing. This message only indicates that RGZPFM was unable to complete the removal of the deleted records space—i.e., truncation could not be performed because other users were active to the file. To free up storage allocated by deleted records, run RGZPFM again when the file is not in use by others.

So, what happens if RGZPFM is canceled before the end of any phase?

Phase #1: The file will not be compressed. The access paths will be invalid.

Phase #2: The deleted records space will not be reclaimed. The file will be partially organized, and if you specified RBDACCPTH(*YES), the access paths will be invalid.

Phase #3: The file will be organized (compressed), and if you have specified RBDACCPTH(*YES), the access paths will be invalid.

For phases #1, 2, and 3, you can list the invalid access paths with the Edit Rebuild of Access Paths (EDTRBDAP) command. Each access path will be rebuilt at first touch, which may have a performance impact on your users. See question #3 below for additional recommendations.

Phase #4: The file will be organized (compressed), and the freed-up space would still be allocated. In order to free up the deleted records space, the system will need an exclusive lock on the file. If that is not possible, the deleted records space will be left allocated.

Question #2: How Can I Speed Up the RGZPFM?

Answer: As mentioned above, using the option to RBDACCPTH(*YES) will render a faster RGZPFM, but the rebuild will be very CPU-intensive. The best you can do to speed up the rebuild is to allocate as much memory as possible to memory pool *BASE and to leave as much CPU as possible for this task.

Tip: For a quicker reorganization of the physical file, consider using the KEYFILE(*RPLDLTRCD) option with RGZPFM. With this option, the deleted records space in the beginning of the file will be replaced with valid records from the end of the file.

Note: If the records in the physical file must exactly match the current arrival sequence, do not use *RPLDLTRCD.                                      

Question #3: How Can I Rebuild the Invalid Access Paths and Avoid Performance Problems for Users?

Answer: When you cancel a RGZPFM that was set to rebuild the access path, you will be left with a list of access paths that need to be rebuilt. The system will rebuild the access paths at first touch; however, that may render some performance impact on your users. The following steps can be used to rebuild the invalid access paths in a controlled manner.

1. EDTRBDAP will provide a list of access paths that were marked as invalid. Change each access path to *HLD.


Figure 1: Mark invalid access paths as *HLD. (Click images to enlarge.)

2. Add memory to *BASE memory pool (batch jobs normally run in this pool).

3. Submit individual batch jobs with the OPNDBF command for each access path above.

    Example:

   SBMJOB CMD(OPNDBF FILE(QUSRSYS/CGMEMA4J) OPTION(*INP)) JOB(JOB1)

Note: Each access path will be rebuilt under a separate batch job. You can have several submitted jobs in the queue; however, make sure there are no concurrent batch jobs running to avoid resource contention during the access path rebuild. It is faster to rebuild one at a time than rebuild many concurrently.

4. EDTRBDAP changes the access paths to *OPN. Each access path will be rebuilt under a different batch user job.

 

Figure 2: EDTRBDAP changes the access paths to *OPN.

Question #4: How Can I Verify the Progress of the RGZPFM?

Answer: You can use System i Navigator to verify which phase of the RGZPFM the system is at. On Navigator, open the Database container, drill down to the schema (library) where the file is located, and right-click on the file (table) that is currently being reorganized.

Figure 3: System i Navigator verifies the phase of the RGZPFM. 

When you choose Reorganize, you will be presented with the following:

Figure 4: Manage the reorganization.

Make the proper selections, and the following will be presented:

Figure 5: The reorganization is complete.

Want More Information About RGZPFM?

IBM Infocenter:

http://publib.boulder.ibm.com/iseries/

IBM Software Knowledge Base:

http://www-912.ibm.com/s_dir/slkbase.nsf/slkbase

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

Sandra Cabral

• Email
• Site

Sandra Cabral is a Staff Software Engineer who has been working with various areas of the System i (AS/400) platform since 1992. She has been with IBM Rochester since 1999 and focuses on database and journaling technologies on System i and is currently part of the IBM Support Center Database team.

 

In August of 2009, she got involved with the IBM i 7.1 Early Ship Program, helping to coordinate resources—development, customers, and Support Center reps—through the entire alpha and beta programs and now in GA. She authored the eServer iSeries: File and Print Serving Redbook and has appeared in several other publications from the IBM Software Knowledge Base site.

 

Sandra holds a master’s degree in Management from the University of Concordia, St. Paul, Minnesota, and bachelor's degrees in Civil Engineering and Computer Science from Universidade Federal do Ceara, Brazil, and Universidade Estadual do Ceara, Brazil.