To release disk allocation to a used area, follow the procedure described below.

Procedure

1. Use the pdfstatfs -d command to check whether disk allocation to the used area can be released.^#
2. Use the pdfzeroinit command to write zeros in the used area.
3. Use the HDP facility to discard the zero data.

#

The execution result of the pdfstatfs -d command follows:

user area capacity 262129[kB] remain user area capacity 262129[kB] peak capacity 131072[kB] ...1 available file size 262129[kB] available file count 20 current file count 0 remain file count 20 free area count 0 available expand count 20 current expand count 0 ...........2 initialize area kind WORK initialize user id hirman initialize time Wed Nov 11 15:41:26 2009 area auto expand NOUSE

Explanation

1. Confirm that the user's current maximum usage is greater than the allocation unit. For example, if the allocation unit is assumed to be 32 MB, disk allocation can be released since the user's current maximum usage is 128 MB.
2. Confirm that the HiRDB file count is 0.
   

   Note

   1. Executing the pdfzeroinit command writes zeros on the entire HiRDB file system area currently being used. Therefore, when you execute this command, take its impact on the online job into consideration.
   2. There is a difference between the user's maximum usage and the amount of disk space allocated in the DP pool. If you execute the pdfzeroinit command when the amount of disk space allocated in the DP pool is smaller than the user's maximum usage, initialization increases the amount of disk space allocated in the DP pool to the value obtained by adding the DP pool allocation unit to the user's maximum usage. Therefore, monitor the DP pool capacity to prevent a shortage, and execute the pdfzeroinit command only when the remaining capacity in the DP pool is sufficiently greater than the difference between the user's maximum usage and the amount of disk space allocated in the DP pool.
   3. The pdfzeroinit command's write process might take a long time, depending on the size of the area to be initialized. Do not execute the pdfzeroinit command on a HiRDB file system area being accessed by a job. Executing this command might adversely impact the job.
   4. If you need to execute the pdfzeroinit command on a HiRDB file system area whose type is WORK, execute the command with HiRDB stopped. If you execute the command while HiRDB is running, it might adversely impact SQL statements and utilities that require work table files.
   5. Do not execute the pdfstatfs-c command on an area that is to be initialized. If you execute this command, you will not be able to use the pdfzeroinit command to initialize used areas.

When a job temporarily uses a large HiRDB file system area, releasing the disk space allocated to used areas is effective because it allows efficient use of storage. For successful release of disk space allocated to used areas, the following conditions must be satisfied.

For RDAREAs, shared RDAREAs, system files, and list RDAREAs

A single HiRDB file has been created in each HiRDB file system area.

For RDAREAs and shared RDAREAs

Only a single table or index is defined in each RDAREA.

The following table shows the operations for which releasing the disk space allocated to used areas are recommended.

Table 10-4 Operations for which releasing the disk space allocated to used areas is recommended

Value specified for the -k option of pdfmkfs	Type of HiRDB file system area targeted for operation	Operation	Referencing destination
DB and SDB	RDAREAs and shared RDAREAs	RDAREA deletion	(a)
		RDAREA re-initialization	(b)
		Deletion of all rows from a table	(c)
		Table and index deletion	(d)
		Table reorganization	(e)
SYS	System files	System log file deletion	(f)
WORK	Work table files	Batch processing accompanied by, for example, combine processing that uses a large work table	(g)
	List RDAREAs	RDAREA deletion	(a)
		RDAREA re-initialization	(b)

(a) Releasing the disk space allocated to used areas when deleting an RDAREA

The following figure shows the procedure for releasing the disk space allocated to used areas when deleting an RDAREA.

Figure 10-3 Procedure for releasing the disk space allocated to used areas (when deleting an RDAREA)

#

If HiRDB is running, this step must be performed while other processes are not accessing the HiRDB file system area. Therefore, we recommend that you first refresh the server process (by executing the pdpfresh command).

(b) Releasing the disk space allocated to used areas when re-initializing an RDAREA

The following figure shows the procedure for releasing the disk space allocated to used areas when re-initializing an RDAREA.

Figure 10-4 Procedure for releasing the disk space allocated to used areas (when re-initializing an RDAREA)

#1

This is the backup to be used for recovery in case an error occurs during the period between HiRDB file deletion and RDAREA reinitialization. Acquisition of this backup is optional.

#2

If HiRDB is running, this step must be performed while other processes are not accessing the HiRDB file system area. Therefore, we recommend that you first refresh the server process (by executing the pdpfresh command).

#3

Zero data discarding can be performed when the following two conditions are satisfied:

• The applicable disk area is not being accessed.
• HiRDB is stopped or the RDAREA is closed.

(c) Releasing the disk space allocated to used areas when deleting all rows from a table

To release the disk space allocated to used areas when deleting all rows from a table, delete all rows from the table (using the PURGE TABLE statement), and then take the steps described in (b) Releasing the disk space allocated to used areas when re-initializing an RDAREA.

(d) Releasing the disk space allocated to used areas when deleting a table or index

The following is the procedure for releasing the disk space allocated to used areas when deleting a table or index.

Procedure

1. Take the steps described in (b) Releasing the disk space allocated to used areas when re-initializing an RDAREA.
2. Delete the table or index.
   

   Reference note

   Deleting a table or index first does not cause an error. However, re-initializing the RDAREA first can reduce the amount of resources (locked resources and system logs) HiRDB uses to delete the table or index.

(e) Releasing the disk space allocated to used areas when reorganizing a table

The following figure shows the procedure for releasing the disk space allocated to used areas when reorganizing a table.

Figure 10-5 Procedure for releasing the disk space allocated to used areas (when reorganizing a table)

#1

This is the backup to be used for recovery in case an error occurs in the period between HiRDB file deletion and RDAREA reinitialization. Acquisition of this backup is optional.

#2

If HiRDB is running, this step must be performed while other processes are not accessing the HiRDB file system area. Therefore, we recommend that you first refresh the server process (by executing the pdpfresh command).

#3

Zero data discarding can be performed when the following two conditions are satisfied:

• The applicable disk area is not being accessed.
• HiRDB is stopped or the RDAREA is closed.

(f) Releasing the disk space allocated to used areas when deleting a system log file

The following figure shows the procedure for releasing the disk space allocated to used areas when deleting a system log file.

Figure 10-6 Procedure for releasing the disk space allocated to used areas (when deleting a system log file)

(g) Releasing the disk space allocated to used areas after the execution of an SQL statement or a utility that creates a work table file

The following figure shows the procedure for releasing the disk space allocated to used areas after the execution of an SQL statement or a utility that creates a work table file.

Figure 10-7 Procedure for releasing the disk space allocated to used areas (after the execution of an SQL statement or a utility that creates a work table file)

Note:

If the system switchover facility is being used and HiRDB file system areas for work table files have been created on both the primary and secondary server machines, follow steps 2 through 4 on the standby system after system switchover.