Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Checking free memory space

In order to adapt the stored data to the modified schema or modified storage structure, BALTER requires additional free memory space

  • in order to create new tables, hash areas or DBTTs

  • in order to re-store records, tables, hash areas or DBTTs.

If the free memory space in the realms is not large enough to do this, BALTER automatically extends the realms concerned, provided this is possible (requirement: secondary allocation for memory space > 0). For details, please see "Database Operation" manual, Automatic realm extension by means of utility routines.

If automatic realm extension is not possible (secondary allocation for memory space = 0 or no more disk storage is available), BALTER aborts restructuring! As a result your database is inconsistent and you must revert to the status before restructuring began and start again from the beginning.

Realms without automatic realm extension

When one or more realms with a secondary allocation = 0 are configured, e.g. because you do not want automatic realm extension, you must ensure that the available space is sufficient before you begin restructuring. For this purpose you must use BSTATUS to display how much memory space is still free in the various realms of your database and estimate whether the free space is sufficient for the planned restructuring.

This should be done as early as possible, since BREORG can no longer enlarge the realms of the database once BCHANGE has processed the database for restructuring purposes.You can also make use of the analysis report for this purpose (see section "Description of the analysis report (REPORT phase)").

BALTER selects the processing sequence in such a way that it first deletes those elements from the database which are no longer contained in the new schema. The space released can then later be used in the course of other activities, such as the creation of new tables, the creation of new hash areas, the re-storing of records etc. In the same way the space released after re-storage of a record type can be used again. Unfavorable configurations may however lead to a situation in which space which is free at the end of a realm is allocated first of all, leaving gaps at the beginning of the realm. If this is the case, it is possible, by means of the BREORG utility routine, to relocate hash areas and tables to the free pages at the beginning of the realm:

  • hash areas with REORGANIZE-CALC

  • tables with REORGANIZE-SET.

You can then reduce the realm by deleting the pages released at the end of the realm.

The overviews on the following pages are intended to help you estimate the size of the free memory space which must be available for restructuring purposes in the realms of the database. If insufficient free space is found in a realm, it must be extended using BREORG before BCHANGE is started for purposes of preparing restructuring. 

DBTT

BALTER lists in an analysis listing the free memory space it needs to restore a DBTT or to create a new DBTT.

The new size of a DBTT can also be determined using the formulas specified in the table.


Modification in
the database

R e a s o n

Memory requirement

Formula
(see section
"Calculation formulas")

SSL clause
specifying size

Standard
size

Creating a new
DBTT

new record type defined

1

DBTT clause

1 page

Re-storing
DBTT

Number of DBTT columns changed (only in owner record) by

  • modified linkage method in MODE clause

  • addition or omission of SEARCH key (set level)

  • changing the number of sets in which this record type is owner

DBTT relocated by

  • new realm-name-1 in the WIHTIN clause of the DDLL
    (record type level)

  • new realm-name-1 in the DBTT clause of the SSL
    (record type level)



2



-



Orignal
number of
DBTT
entries

Table 29: Memory requirement for DBTT modifications

Hash areas

The number of pages which BALTER needs to create a hash area is given in the analysis listing.

The size of the hash areas can also be determined with the aid of formulas.A hash area always occupies contiguous pages of a realm.

Modification in
the database

R e a s o n

Memory requirement

Formula
(see section
"Calculation formulas")

SSL clause
specifying size

Standard
size

Creating a direct or
indirect hash area
(primary key)

  • New record type defined with LOCATION CALC

  • LOCATION MODE changed to CALC

  • hash routine or CALC key changed in LOCATION CALC

  • record type with LOCATION CALC lengthened/shortened

3

or

4

POPULATION
clause

1 page

Creating an indirect
hash area
(secondary key)

  • new SEARCH key defined with using CALC

  • definition of a SEARCH key changed in USING CALC

  • CALC key or hash routine of a SE ARCH key changed

  • indirect hash area relocated to another realm


4

DBTT clause

1 page

Converting a direct
into an indirect
hash area
(primary key)

A record type defined with LOCATION CALC

  • is owner or member in a set for which
    PLACEMENT OPTIMIZATION has been for first time

  • has become a member in a list

  • has been stored for the first time in compressed form in the new schema


4

POPULATION
clause

1 page

Converting an indirect
into a direct hash area
(primary key)

In a record type defined with LOCATION CALC

  • PLACEMENT OPTIMIZATION is omitted in all sets in which this record type is a member

  • compressed storage is cancelled

  • the MODE clause of a set in which this record type is a member is changed from MODE IS LIST to POINTER-ARRAY/CHAIN


3

Table 30: Memory requirement for modifications affecting hash areas

Tables

Relocating tables

BALTER can relocate only single-level tables in their entirety. If it relocates tables to another realm, the space required in that realm is equal to the space originally occupied by the table.

Creating new tables:

  • SYSTEM set or TYPE IS DATABASE-KEY-LIST:
    each set occurrence table occupies at least one page.

    Non-singular set and not TYPE IS DATABASE-KEY-LIST:
    each set occurrence table takes up only as much space as it needs.

BALTER stores tables for the same set using a space-saving strategy such that there may be a number of tables in the same page, if the tables are stored DETACHED.


Table

Change in Schema DDL
or in SSL

Change in DB        

Memory requirement

Create new
table(s)    

Relocate
table(s)

Indexed

SEARCH
key table

(record
type
level)

new SEARCH key defined
with USING INDEX

X

-

min. 1 page

max. refer to formula 5

Key item changed

X

-

Table type changed
REPEATED-KEY <-->
DATABASE-KEY-LIST

X

-

Definition of a SEARCH key
changed to USING INDEX

X

-

SEARCH key table relocated
to another realm

X

-

Indexed

SEARCH
key
table

(set
level)

Table type changed
REPEATED-KEY -->
DATABASE-KEY-LIST
or
key item modified in type
DATABASE-KEY-LIST

X

-

min. 1 page per set occurrence table

with SYSTEM set:
min. 1 page
max. refer to formula 5

New SEARCH key defined
with USING INDEX

X

-

with SYSTEM set:

min. 1 page
max. refer to formula 5



with non-singular set:

minimum not specifiable.
BALTER stores several set occurrence tables together, provided they are small enough and intended to go in the same realm.


max. size of a single set occurrence table:
refer to formula 5

Key item changed

X

-

Table type changed
DATABASE-KEY-LIST -->
REPEATED-KEY

X

-

Definition of a SEARCH key
changed to USING INDEX

X

-

SEARCH key table relocated
to another realm

X

-

Indexed

pointer
array

MODE clause changed to
POINTER ARRAY

X

-

ASC/DSC key changed

X

-

Pointer array relocated
to another realm

X

-

New set defined with
MODE IS POINTER-ARRAY

X

-

Indexed

sort
key table

(MODE IS
CHAIN)

New set defined with MODE
IS CHAIN and ORDER
SORTED
INDEXED

X

-

Definition of a set
changed to MODE IS and
ORDER SORTED INDEXED

X

-

ASC/DESC key changed

X

-

Table relocated to
another realm

X

-

Non-indexed
pointer
array

Pointer array relocated
to another realm

-

X

Original size

Indexed

list

MODE clause changed to
LIST

X

-

with SYSTEM set:
min. 1 page
max. refer to formula 5

with non-singular set:
minimum not specifiable.
BALTER stores several set occurrence tables together, provided they are small enough and intended to go in the same realm.

max. size of a single set occurrence table:
refer to formula 5

ASC/DESC key changed

X

-

New set defined with MODE
IS LIST

X

-

Table 32: Memory requirements for table changes 

If a pointer array, list or chain is added SORTED INDEXED to an empty SYSTEM set, BALTER creates an empty table for it one page in size.

The following changes are allowed only when there are no member records:

  • creation of a single-level list or a single-level pointer array (caused e.g. by MODE definition, changed ORDER clause)

  • relocation of a single-level list in the same realm (e.g. by record lengthening)

  • relocation of a list to another realm

Record reallocation

When records are reallocated, a distinction is made by BALTER between a partial and a complete reallocation:

  • A complete reallocation

    occurs when the new schema prescribes a special form of storage. This is the case with
    LOCATION MODE IS CALC for direct hash areas and record types stored in a list.

    A complete reallocation is carried out by BALTER when:

    • you use a hash routine other than the standard routine in the new schema

    • you change the CALC key for a direct hash area in the new schema

    • you do not specify the reason for indirect storage in the new schema

    • you introduce LOCATION MODE IS CALC in the new schema

    • you change the ASC/DESC key of a list in the new schema

    • you redefine MODE IS LIST in the new schema.

    In the case of a complete reallocation, BALTER relocates all records to new pages and releases the old pages. This means, however, that during the BALTER run double the storage space required for storing the records must be available.

    If a record type with a special form of storage is lengthened, a complete reallocation is automatically initiated, even if there is no change in the form of storage itself.

  • A partial reallocation

    occurs when either the user or system part of the records is lengthened, thus making more pages necessary for storage purposes.

    In the case of a partial reallocation, as many records as possible are kept in their original pages, and the rest are relocated by BALTER to new pages.

  • Shortening records

    If a record type with a special form of storage is shortened, a complete reallocation is automatically initiated as for the lengthening of records, even if there is no change in the form of storage.

    If a record type without a special form of storage is shortened, BALTER pushes all the records within a page together. This releases space within the individual pages. BALTER does not relocate the records to other pages, however, so no whole pages are released.

BALTER does not indicate the amount of space required to relocate records in the analysis listing. It is, however, possible to estimate the required storage space with the help of table 33 of and the calculation formulas which follow. 

Modification

R e a s o n

Memory requirement

Formula
(see section
"Calculation formulas")

SSL clause
specifying size

Standard
size

Complete
reallocation

Direct
hash
area

LOCATION MODE changed to CALC

3

POPULATION
clause

1 page

Hash routine/CALC key
changed key

Hash area converted
from indirect to direct
(see table 30)

Indexed
list

New set defined with MODE IS LIST

with SYSTEM set: min. 1 page
max. refer to formula 5

with non-singular set: minimum not specifiable.
BALTER stores several set occurrence tables together, provided they are small
enough and intended to go in the same realm.

max. size of a single set occurrence table:
refer to formula 5

MODE clause changed to LIST

ASC/DESC key changed


Partial
reallocation
(record
type
lengthened)

User part lengthened


BALTER enters as many records as possible in the previous pages and
relocates the remaining records to other pages.


Since most of the records are dispersed throughout the storage space, it is
impossible to estimate the memory requirement (other than for record types
with a special form of storage).

System
part
lengthened

Record type compressed

Owner linked to its table

Member linked to its owner

MODE IS CHAIN introduced
(see table 28 in chapter
"Modifying the Schema DDL")

Owner/member record type:
new set with MODE IS CHAIN added

LINKED TO PRIOR or to MODE IS CHAIN
(see table 28 in chapter
"Modifying the Schema DDL")

Member record type: new set added


(no
reallocation)

Record
type
shortened

User part shortened


BALTER pushes together the records in a page (except for record type with special
form of storage).


Additional free memory space is not required (except for record type with
special form of storage).

System
part
shortened

Record type decompressed

Linkage of owner to its table cancelled

Linkage of member to its owner cancelled

Sets defined with MODE IS CHAIN deleted

LINKED TO PRIOR and
ORDER IS LAST omitted from
MODE IS CHAIN
(see table 28 in chapter
"Modifying the Schema DDL")

MODE clause changed from
MODE IS CHAIN to POINTER
ARRAY / LIST
(see table 28 in chapter
"Modifying the Schema DDL")

Set in which record type was
member deleted

Table 33: Memory requirements for record reallocation

Calculation formulas

The calculation formulas indicated below can be used to calculate the following values:

  • DBTT size for a new DBTT

  • DBTT size for a re-stored DBTT

  • size of a direct hash area

  • size of an indirect hash area

  • size of a multi-level SEARCH key table on record type level

  1. Calculating the DBTT size for a new DBTT:

    2044 / LENGTH = entries-per-page 1) (for 2048-byte page length)

    3980 / LENGTH = entries-per-page 1) (for 4000-byte page length)

    8076 / LENGTH = entries-per-page 1) (for 8096-byte page length)

    integer / entries-per-page = number-of-pages 2)

    1)  The result must be rounded down to an integer
    2)  The result must be rounded up to an integer

    number-of-pages

    Number of DBTT pages

    entries-per-page

    Number of DBTT entries per page

    integer

    Number of planned records as in DBTT clause

    LENGTH

    Length of a DBTT entry; is contained in the BGSIA report under the heading: ’DBTT-INFORMATION’ (see the "Recovery, Information and Reorganization" manual) 

  2. Calculating the DBTT size for a re-stored DBTT:

    2044 / LENGTH-new = entries-per-page-new 1) (for 2048-byte page length)

    3980 / LENGTH-new = entries-per-page-new 1) (for 4000-byte page length)

    8076 / LENGTH-new = entries-per-page-new 1) (for 8096-byte page length)

    prev.-total-no.-of-entries / entries-per-page-new = number-of-pages 2)

    1) The result must be rounded down to an integer
    2) The result must be rounded up to an integer

    number-of-pages

    Number of DBTT pages

    prev.-total-no.-of-entries

    Number of entries in the original DBTT; this value can be determined using BSTATUS

    entries-per-page-new

    Number of DBTT entries per page in the new DBTT

    LENGTH-new

    Length of an entry in the new DBTT

    LENGTH-new = 4 x ( n + 1)

    n
    Number of all the tables of the sets in which the record type is the owner record type

  3. Calculating the size of a direct hash area:

    No allowance is made for the number of overflow pages which BALTER must also create.

    (page-length - 30) / (record-length + calc-key-length + 15) = entries-per-page 1)

    (integer - 1) / entries-per-page + 1 = number-of-pages 2)

    1 The result must be rounded up to an integer
    2 The result must be rounded up to the next-higher prime number if no prime number is obtained 

    page-length

    Page length of the database (2048/4000/8096 bytes)

    number-of-pages

    Number of pages in the hash area

    calc-key-length

    Length of CALC key; is given in the BGSIA report under the heading ’CALC-INFORMATION’ in the LENGTH column (see the "Recovery, Information and Reorganization" manual).

    integer

    Number of records to be stored according to the POPULATION clause (record type level).

    record-length

    Length of record type including SCD; is given in the BGSIA report under the heading ’RECORD-INFORMATION’ in the LENGTH column (see the "Recovery, Information and Reorganization" manual).

    entries-per-page

    Number of entries (records or CALC index entries) per page.  

  4. Calculating the size of an indirect hash area:

    No allowance is made for the number of overflow pages which BALTER must also create.

    (page-length - 30) / (calc-key-length + 7) = entries-per-page 1)

    (integer - 1 ) / entries-per-page = number-of-pages 2)

    1)  The result must be rounded up to an integer
    2)  The result must be rounded up to the next-higher prime number if no prime number is obtained

    integer
    Number of records to be stored

          • according to POPULATION clause (primary key)

          • according to DBTT clause (secondary key).

    For other meanings, see the previous formula. 

  5. Calculating the size of a multi-level SEARCH key table (record type level)

    This formula is based on slightly simplified assumptions and therefore produces an estimate, not the exact numerical value.


    For a 2048-byte page length:

    • if an occupancy level was specified:

             no.-of-search-keys                 2002 - a

      -------------------------------------- * ---------- = no.-of-pages

      max(1, (2002 / a * occ. level / 100)) 1)  2002 - 2a

      1) The result of the first division and the result of the first multiplication must each be rounded down to an integer

    • If no occupancy level was specified:

      no.-of-search-keys   2002 - a

      ------------------ * ---------- = no.-of-pages

      (2002 / a ) -1) 2)   2002 - 2a

      2) The result of the division must be rounded down to an integer

    where: a = search-key-l + 7

    For a 4000-byte page length:

    • if an occupancy level was specified:

             no.-of-search-keys                 3950 - b
      -------------------------------------- * ---------- = no.-of-pages

      max(1, (3950 / b * occ. level / 100)) 1)  3950 - 2b

      1) The result of the first division and the result of the first multiplication must each be rounded down to an integer

    • If no occupancy level was specified:

      no.-of-search-keys    3950 - b
      ------------------ * ---------- = no.-of-pages
      (3950 / b ) -1) 2)    3950 - 2b

      2) The result of the division must be rounded down to an integer

    where: b = search-key-l + 10


    For an 8096-byte page length:

    • if an occupancy level was specified:

             no.-of-search-keys                 8046 - b

      -------------------------------------- * ---------- = no.-of-pages

      max(1, (8046 / b * occ. level / 100)) 1)  8046 - 2b

      1) The result of the first division and the result of the first multiplication must each be rounded down to an integer

    • If no occupancy level was specified:

      no.-of-search-keys    8046 - b

      ------------------ * ---------- = no.-of-pages

      (8046 / b ) -1) 2)    8046 - 2b

      2) The result of the division must be rounded down to an integer

    where: b = search-key-l + 10

    no.-of-pages

    Number of pages required for the whole set occurrence table

    no.-of-search-keys

    Number of keys in the table

    occ. level

    Percentage occupancy level (see the FILLING clause, "BALTER statements")

    search-key-l(ength)

    Length of the SEARCH key; is given in the BGSIA report under the heading ’KEY-INFORMATION’ (NO CALC SEARCH KEY’S)’ in the LENGTH column (see the "Recovery, Information and Reorganization" manual).

Powered by Atlassian Confluence and Scroll Viewport.