Freien Speicherplatz prüfen

Zum Anpassen des Datenbestands an das geänderte Schema bzw. die geänderte Speicherstruktur beansprucht BALTER zusätzlichen freien Speicherplatz

• zum Anlegen neuer Tabellen, Hashbereiche oder DBTTs

• zum Umspeichern von Datensätzen, Tabellen, Hashbereichen oder DBTTs.

Reicht der freie Speicherplatz in den Realms dafür nicht aus, dann erweitert BALTER die betroffenen Realms automatisch, sofern dies möglich ist (Voraussetzung: Sekundärzuweisung für Speicherplatz > 0). Näheres hierzu siehe Handbuch „Datenbankbetrieb“, Automatische Realm-Erweiterung durch Dienstprogramme).

Falls keine automatische Realm-Erweiterung möglich ist (Sekundärzuweisung für Speicherplatz = 0 oder kein Plattenspeicher mehr verfügbar), bricht BALTER die Umstrukturierung ab! Ihre Datenbank ist dadurch inkonsistent und Sie müssen sie auf den Stand vor Beginn der Umstrukturierung zurücksetzen und wieder von vorne beginnen.

Realms ohne automatische Realm-Erweiterung

Wenn ein oder mehrere Realms mit einer Sekundärzuweisung = 0 eingerichtet sind, z.B. weil Sie keine automatische Realm-Erweiterung wünschen, müssen Sie vor dem Umstrukturieren sicherstellen, dass der verfügbare Speicherplatz ausreicht. Dazu müssen Sie sich von BSTATUS ausgeben lassen, wie viel Speicherplatz in den verschiedenen Realms Ihrer Datenbank noch frei ist und abschätzen, ob der freie Platz für die geplante Umstrukturierung ausreicht.

Wichtig ist dabei, dass Sie dies möglichst frühzeitig tun, denn BREORG kann die Realms Ihrer Datenbank nur erweitern, solange BCHANGE die Datenbank noch nicht für die Umstrukturierung vorbereitet hat.
Sie können zu diesem Zweck auch das Analyseprotokoll zu Hilfe nehmen (siehe Abschnitt „Beschreibung des Analyseprotokolls (REPORT-Phase)").

BALTER wählt die Verarbeitungsreihenfolge so, dass er als Erstes die Elemente aus der Datenbank löscht, die im neuen Schema nicht mehr vorhanden sind. Dieser Platz ist somit bei späteren Aktionen (Aufbauen neuer Tabellen, Anlegen neuer Hashbereiche, Umspeichern von Sätzen) wieder nutzbar. Ebenso kann der Platz, der beim Umspeichern einer Satzart frei wird, nach Abschluss des Umspeicherns wieder verwendet werden.
Durch ungünstige Konstellationen kann es jedoch vorkommen, dass zuerst der Platz belegt wird, der hinten im Realm frei ist, und vorne im Realm Lücken bleiben. In so einem Fall können Sie durch Reorganisieren mit dem Dienstprogramm BREORG nach dem Umstrukturieren Hashbereiche und Tabellen in die freien vorderen Seiten verlagern:

• Hashbereiche mit REORGANIZE-CALC

• Tabellen mit REORGANIZE-SET

Anschließend können Sie die Realms um die am Ende frei gewordenen Seiten verkleinern.

Die Übersichten auf den folgenden Seiten sollen Ihnen helfen, die Größe des Speicherplatzes abzuschätzen, der zum Umstrukturieren in den Realms Ihrer Datenbank unbedingt noch frei sein muss. Stellen Sie dabei fest, dass ein Realm zu wenig Speicherplatz frei hat, so müssen Sie ihn mit BREORG erweitern, bevor Sie BCHANGE zum Vorbereiten der Umstrukturierung starten.

DBTT

Den freien Speicherplatz, den BALTER zum Neuanlegen oder Umspeichern einer DBTT benötigt, listet er im Analyseprotokoll auf.

Sie können die neue Größe einer DBTT aber auch anhand der in der Tabelle angegebenen Formeln berechnen.

Änderung in der Datenbank	U r s a c h e	S p e i c h e r b e d a r f
		Formel (siehe "Berechnungs- formeln")	SSL-Klausel, die die Größe bestimmt	Standard- größe
neue DBTT anlegen	neue Satzart definiert	1	DBTT-Klausel	1 Seite
DBTT umspeichern	Anzahl der DBTT-Spalten verändert (nur beim Ownersatz), durch geänderte Verkettungs-Methode in der MODE-Klausel hinzugekommenen/weggelassenen SEARCH-Key (Setebene) ändern der Anzahl der Sets, in denen diese Satzart Owner ist DBTT verlagert durch: neuen <realmname-1> in der WITHIN-Klausel der DDL (Satzartebene) neuen realmname-1 in der DBTT-Klausel der SSL (Satzartebene)	2	-	ursprüngliche Anzahl der DBTT- Einträge

Tabelle 29: Speicherbedarf bei DBTT-Änderungen

Hashbereiche

Die Anzahl der Seiten, die BALTER zum Einrichten eines Hashbereichs benötigt, listet er im Analyseprotokoll auf.

Sie können die Größe der Hashbereiche aber auch anhand von Formeln berechnen! Ein Hashbereich belegt immer zusammenhängende Seiten eines Realm. 

Änderung in der Datenbank	U r s a c h e	S p e i c h e r b e d a r f
		Formel, siehe  "Berech- nungs- formeln"	SSL-Klausel, die die Größe bestimmt	Standard- größe
direkten Hashbereich bzw. indirekten Hashbereich (Primärschlüssel) einrichten	neue Satzart definiert mit LOCATION CALC LOCATION MODE in CALC geändert bei LOCATION CALC die Hashroutine oder den CALC-Key geändert Satzart mit LOCATION CALC verlängert/verkürzt	3 bzw. 4	POPULA-TION- Klausel	1 Seite
indirekten Hashbereich (Sekundärschlüssel) einrichten	neuen SEARCH-Key mit USING CALC definiert Definition eines SEARCH-Key in USING CALC geändert CALC-Key oder Hashroutine eines SEARCH-Key verändert indirekten Hashbereich in einen anderen Realm verlagert	4	DBTT-Klausel	1 Seite
direkten Hashbereich umwandeln in indirekten Hashbereich (Primärschlüssel)	Eine mit LOCATION CALC definierte Satzart ist Owner oder Member in einem Set, für den erstmalig PLACEMENT OPTIMIZATION an gegeben wird wird Member in einer Liste wird im neuen Schema erstmalig komprimiert gespeicher	4	POPULA-TION- Klausel	1 Seite
indirekten Hashbereich umwandeln in direkten Hashbereich (Primärschlüssel)	Bei einer mit LOCATION CALC definierten Satzart wird PLACEMENT OPTIMIZATION weggelassen bei allen Sets, in denen diese Satzart Member ist wird komprimiertes Speichern gestrichen wird die MODE-Klausel eines Set, in dem diese Satzart Member ist, geändert von MODE IS LIST in POINTER-ARRAY/CHAIN	3

Tabelle 30: Speicherbedarf bei Änderungen, die Hashbereiche betreffen

Tabellen

Verlagern von Tabellen

Verlagert BALTER Tabellen - nur einstufige Tabellen kann BALTER als ganzes verlagern - in einen anderen Realm, so entspricht der dort benötigte Platz dem ursprünglich von der Tabelle belegten Platz.

Neuaufbau von Tabellen:

• SYSTEM-Set oder TYPE IS DATABASE-KEY-LIST:
  Jede Set-Occurrence-Tabelle belegt mindestens eine Seite.

  Standard-Set und nicht TYPE IS DATABASE-KEY-LIST:
  Jede Set-Occurrence-Tabelle belegt nur so viel Platz, wie sie benötigt.

  BALTER speichert Tabellen desselben Sets so Platz sparend ab, dass mehrere Tabellen in derselben Seite liegen können.

Tabelle	Änderung in der Schema- DDL bzw. der SSL	Änderung in DBB		S p e i c h e r b e d a r f
		Tabelle(n) neu aufbauen	Tabelle(n) verlagern
indizierte SEARCH- Key-Tabelle (Satzartebene)	neuen SEARCH-Key mit USING INDEX definiert	X	-	min. 1 Seite max. siehe Formel 5
	Schlüsselfeld geändert	X	-
	Typ der Tabelle geändert REPEATED-KEY <--> DATABASE-KEY-LIST	X	-
	Definition eines SEARCH-Key in USING INDEX umgewandelt	X	-
	SEARCH-Key-Tabelle in einen anderen Realm verlagert	X	-
indizierte SEARCH- Key-Tabelle (Setebene)	Typ der Tabelle geändert REPEATED-KEY --> DATABASE-KEY-LIST oder Schlüsselfeld geändert beim Typ DATABASE-KEY-LIST	X	-	min. 1 Seite pro Set-Occurrence-Tabelle bei SYSTEM-Set: min. 1 Seite max. siehe Formel 5
	neuen SEARCH-Key mit USING INDEX definiert	X	-	bei SYSTEM-Set: min. 1 Seite max. siehe Formel 5 bei Standard-Set: Mindestangabe nicht möglich; BALTER speichert mehrere Set-Occurrence-Tabellen zusammen, wenn sie klein genug sind,und in denselben Realm kommen sollen. max. Größe für eine einzelne Set-Occurrence-Tabelle siehe Formel 5
	Schlüsselfeld geändert	X	-
	Typ der Tabelle geändert DATABASE-KEY-LIST --> REPEATED-KEY	X	-
	Definition eines SEARCH-Key in USING INDEX umgewandelt	X	-
	SEARCH-Key-Tabelle in einen anderen Realm verlagert	X	-
indizierte Adressliste	MODE-Klausel in POINTER-ARRAY geändert	X	-
	ASC/DSC-Key geändert	X	-
	Adressliste in einen anderen Realm verlagert	X	-
	neuen Set mit MODE IS POINTER-ARRAY definiert	X	-
indizierte Sort- Key- Tabelle (MODE IS CHAIN)	neuen Set definiert mit MODE IS CHAIN und ORDER SORTED INDEXED	X	-
	Definition eines Sets geändert in MODE IS CHAIN und ORDER SORTED INDEXED	X	-
	ASC-/DESC-Key geändert	X	-
	Tabelle in einen anderen Realm verlagert	X	-
nicht indizierte Adressliste	Adressliste in einen anderen Realm verlagert	-	X	ursprüngliche Größe
indizierte Liste	MODE-Klausel in LIST geändert	X	-	bei SYSTEM-Set: min. 1 Seite max. siehe Formel 5 bei Standard-Set: Mindestangabe nicht möglich; BALTER speichert mehrere Set-Occurrence-Tabellen zusammen, wenn sie klein genug sind, und in enselben Realm kommen sollen. max. Größe für eine einzelne Set-Occurrence-Tabelle siehe Formel 5
	ASC-/DESC-Key geändert	X	-
	neuen Set mit MODE IS LIST definiert	X	-

Tabelle 32: Speicherbedarf bei Tabellenänderungen

Wird in einem leeren SYSTEM-Set eine Adressliste, Liste oder Kette SORTED INDEXED neu definiert, so legt BALTER eine leere Tabelle in der Größe einer Seite dafür an.

Folgende Änderungen sind nur dann zulässig, wenn keine Membersätze vorliegen:

• Neuaufbau einer einstufigen Liste oder einer einstufigen Adressliste (bewirkt z.B. durch MODE-Definition, Änderung ORDER-Klausel)

• Verlagern einer einstufigen Liste in demselben Realm (z.B. durch Satzverlängerung)

• Verlagern einer Liste in einen anderen Realm

Umspeichern von Sätzen

BALTER unterscheidet beim Umspeichern von Sätzen zwischen teilweiser und vollständiger Verlagerung:

• Vollständige Verlagerung

  liegt vor, wenn das neue Schema eine besondere Ablageform zwingend vorschreibt. Dies ist der Fall bei LOCATION MODE IS CALC bei direkten Hashbereichen und bei Satzarten, die in einer Liste gespeichert sind.

  Vollständige Verlagerung führt BALTER in folgenden Fällen durch:

  • Sie verwenden im neuen Schema eine eigene Hashroutine statt der Standard-Hashroutine

  • Sie ändern im neuen Schema bei einem direkten Hashbereich den CALC-Key

  • Sie lassen im neuen Schema den Grund weg für eine indirekte Hash-Speicherung

  • Sie führen im neuen Schema LOCATION MODE IS CALC neu ein

  • Sie ändern im neuen Schema den ASC-/DESC-Key einer Liste

  • Sie definieren im neuen Schema MODE IS LIST neu

  Bei vollständiger Verlagerung speichert BALTER alle Sätze in neue Seiten um und gibt die alten Seiten frei. Das heißt jedoch, dass während des BALTER-Laufs das Doppelte des für die Speicherung der Sätze notwendigen Platzes vorhanden sein muss.

  Verlängern Sie eine Satzart mit besonderer Ablageform, so führt dies zu vollständiger Verlagerung, auch wenn sich an der Ablageform selbst nichts ändert.

• Teilweise Verlagerung

  liegt vor, wenn sich die Sätze verlängern (Benutzer- oder Systemteil) und aus diesem Grund mehr Seiten zur Speicherung benötigen.

  Bei teilweiser Verlagerung bleiben so viele Sätze in den bisherigen Seiten wie möglich, den Rest speichert BALTER in neue Seiten um.

• Verkürzen von Sätzen

  Verkürzen Sie eine Satzart mit besonderer Ablageform, so führt dies wie beim Verlängern einer solchen Satzart zu vollständiger Verlagerung, auch wenn sich an der Ablageform selbst nichts ändert.

  Verkürzen Sie eine Satzart ohne besondere Ablageform, so schiebt BALTER jeweils die Sätze innerhalb einer Seite zusammen. Es wird also Platz innerhalb der einzelnen Seiten frei, BALTER speichert die Sätze aber nicht in andere Seiten um, sodass keine ganzen Seiten frei werden.

BALTER druckt den Platz, den er zum Umspeichern von Sätzen benötigt, nicht im Analyseprotokoll aus. Mit Hilfe von Tabelle 33 und der anschließend dargestellten Berechnungsformeln können Sie jedoch den benötigten Speicherplatz zum Teil berechnen.

Änderung	U r s a c h e		S p e i c h e r b e d a r f
			Formel (siehe "Berechnungs- formeln")	SSL-Klausel, die die Größe bestimmt	Standard- größe
vollständige Verlagerung	direkter Hash- bereich	LOCATION MODE in CALC geändert	3	POPULATION- Klausel	1 Seite
		Hashroutine/CALC-Key geändert
		indirekten in direkten Hashbereich umgewandelt (siehe Tabelle 30)
	indizierte Liste	neuen Set mit MODE IS LIST definiert	bei SYSTEM-Set: min. 1 Seite max. siehe Formel 5 bei Standard-Set: Mindestangabe nicht möglich; BALTER speichert mehrere Set-Occurrence-Tabellen zusammen, wenn sie klein genug sind, und in denselben Realm kommen sollen. max. Größe für eine einzelne Set-Occurrence-Tabelle siehe Formel 5
		MODE-Klausel in LIST geändert
		ASC-/DESC-Key geändert
teilweise Verlagerung (Satzart verlängert)	Benutzerteil verlängert		BALTER trägt so viele Sätze wie möglich in den bisherigen Seiten ein, den Rest verlagert er in andere Seiten. Da die Sätze in den meisten Fällen gestreut gespeichert sind, ist eine Berechnung des erforderlichen Speicherplatzes nicht möglich (außer bei Satzarten mit besonderer Ablageform).
	Systemteil verlängert	Satzart komprimiert
		Owner verkettet mit seiner Tabelle
		Member verkettet mit seinem Owner
		MODE IS CHAIN eingeführt (siehe Tabelle 28, "Set-Eintrag")
		Owner-/Membersatzart: neuen Set mit MODE IS CHAIN hinzugefügt
		bei MODE IS CHAIN hinzugefügt: LINKED TO PRIOR oder ORDER IS LAST (siehe Tabelle 28, "Set-Eintrag")
		Membersatzart: neuen Set hinzugefügt
(keine Verlagerung) Satzart verkürzt	Benutzerteil verkürzt		BALTER schiebt jeweils dieSätze innerhalb einer Seite zusammen (außer bei einer Satzart mit besonderer Ablageform). Zusätzlicher freier Speicherplatz ist - außer bei einer Satzart mit besonderer Ablageform - nicht erforderlich.
	Systemteil verkürzt	Satzart entkomprimiert
		die Verkettung des Owner mit seiner Tabelle aufgehoben
		die Verkettung des Members mit seinem Owner aufgehoben
		mit MODE IS CHAIN definierte Sets gelöscht
		bei MODE IS CHAIN weggelassen: LINKED TO PRIOR und ORDER IS LAST (siehe Tabelle 28, "Set-Eintrag")
		die MODE-Klausel geändert von MODE IS CHAIN in POINTER-ARRAY / LIST (siehe Tabelle 28, "Set-Eintrag)
		Set gelöscht, in dem die Satzart Member war

Tabelle 33: Speicherbedarf beim Umspeichern von Sätzen