|
|
|
|
|
OAM stores objects in DB2 in two separate tables:
Usually, Control‑D and Control‑V files are stored as large objects. To maximize space utilization with the OAM databases in DB2, object size should be as close as possible to multiples of 32KB. This can be achieved by setting the number of blocks per object by the OBJSIZE parameter.
For example, with BLKSIZE set to 27998, setting OBJSIZE to 7 provides good space utilization, as indicated by the following computation:
(27998 * 7) = 195986 = (6*32*1024) – 622.
When OBJSIZE is set to 7, only 622 bytes are wasted.
In OAM installation, you must be familiar with the following parameters to calculate database sizes:
Table 83 Parameters for calculating database sizes
Parameter |
Description |
|---|---|
Average object size |
This parameter is calculated by multiplying the OBJSIZE parameter value by the CDAM file block size, and rounding it to the next higher multiple of 32KB. |
Total number of objects within an object storage group |
This number is calculated by multiplying the number of objects created per day by the number of days you want to keep the objects. BMC recommends that you add 20% to the result as a safety margin. |
Number of small objects |
This number is usually zero. |
Number of large objects |
This number is usually equal to the total number of objects in an object storage group. |
An OAM collection is created for each Control‑V migrated file. Each collection is defined both in DB2 and in an ICF catalog. BMC recommends that you define a separate catalog for Control‑V migrated files. You should ensure that the catalog is large enough for the needs of your site. The DSNPREF and SECPREF parameters in the IOASPRM member of the IOA.PARM library are used to direct the migrated files to the designated catalog. Due to OAM and DB2 limitations, collections are not deleted when Control‑V migrated files reach the end of their normal retention period. Only the objects in the collections containing the actual data are deleted.
Parent Topic |