View Full Version : wieviele Sätze gehen wirklich in ein Member ?
... sicherlich eine leichte Frage für euch:
Wie viele Sätze gehen wirklich in ein Member?
Wenn ich mit DSPPF die Dateibeschreibung ansehe, so steht u.A. das:
Teildateibeschreibung
Teildatei . . . . . . . . . . . . . . . . . : MBR TRPI
Teildateiebenen-ID . . . . . . . . . . . : 1081022172003
Erstellungsdatum der Teildatei . . . . . : 22.10.08
Text 'Beschreibung' . . . . . . . . . . . : TEXT TRPI /saktionen
Verfallsdatum der Teildatei . . . . . . . : EXPDATE *NONE
Wartung des Zugriffspfads . . . . . . . . : MAINT *IMMED
Wiederherstellung des Zugriffspfads . . . : RECOVER *AFTIPL
Größe der Teildatei SIZE
Anfangsanzahl der Sätze . . . . . . . . : 10000
Satzanzahl für Erweiterung . . . . . . : 1000
Maximale Anzahl Erweiterungen . . . . . : 32767
Aktuelle Anzahl Erweiterungen . . . . . . : 1950079
Satzkapazität . . . . . . . . . . . . . . : 1950089000
Aktuelle Anzahl Sätze . . . . . . . . . . : 32793064
Anzahl gelöschter Sätze . . . . . . . . . : 19
Speicher zuordnen . . . . . . . . . . . . : ALLOCATE *NO
Zusammenhängender Speicher . . . . . . . : CONTIG *NO
Bevorzugte Speichereinheit . . . . . . . : UNIT *ANY
Die "SatzKapazität" ist die max.Anzahl der Sätze, die in das Member geht ...?
(also in diesem Fall 1'950'089'000) .
Mhmmm ...
crtpf
f10
blättern
--> Anfangsanzahl Sätze 1-2147483646 --> bed.Help *Nomax
hallo Robi,
das ist leider nicht wirklich hilfreich, ich glaube nicht, dass diese Datei auf *NOMAX steht.
Bitte um Beantwortung meines konkreten Beispiels.
Vielen Dank.
Nun ja, das Problem mit der Erweiterung ist, dass man diese ggf. mit einer Defaultantwort auf "Datei voll" umgehen kann.
Also an Stelle die Dateigröße mal auf *NOMAX zu stellen, ist die Anfrage nach Dateierweiterung inzwischen 1.917.312 mal positiv beantwortet worden.
Ich nehme mal an, dass zu Anfang die Meldung relativ häufig kam, man das Beantworten als lästig empfand und eine Standardantwort in die SYSRPYL eingetragen hat als nach der Ursache der Meldung zu forschen.
Hallo,
Vielen herzlichen Dank für Eure Antworten.
Ich möchte im Moment eigentlich nur wissen, wieviele Sätze in dieses Member gehen ..... ???
andreaspr@aon.at
17-08-18, 15:02
Sobald die Anzahl der Sätze in der Tabelle den Wert von 1.950.089.000 überschreitet wird eine Nachricht in die QSYSOPR gestellt:
(C I 9999). Satz nicht hinzugefügt. Teildatei deinePF voll.
Dann kannst du mit "I" die Nachricht ignorieren und es wird der Wert "Satzkapazität" (mit der darüber stehenden Erweiterungen) erweitert.
Und die Erweiterung kannst du beliebig oft durchführen, solange bis deine Platten voll sind.
Die Grenze, da gibts unterschiedliche Aussagen, sind 2Mrd oder 4Mrd Sätze (32-Bit)-Wert = 2^31 oder 2^32.
Die Terabyte umfassen dann Anzahl Sätze mal Satzlänge zzgl. Varlen-Fields sowie LOB's.
Ggf. ist das wiederum bei SQL-Tables auf 64-Bit (Long) erweitert.
Die Aussagen sind ganz eindeutig (dazu braucht man nur in die SQL Referenz Appendix A zu schauen):
Die Grenze für Tabellen/physische Dateien ist 4,2 Mrd Datensätze oder 1,7 Terabyte, je nachdem welche Grenze zuerst erreicht wird.
Bei partitionierten Tabellen können bis zu 256 Partitionen mit den o.g. Grenzen zu einer einzigen Tabelle gehören.
Für Large Objects und VarChar-Felder wird innerhalb des Datensatzes nur die allokierte Länge (SQL Allocate bzw. DDS VARLEN(Zahl)) reserviert. Sofern keine Länge allokiert wird (ohne SQL ALLOCATE bzw. DDS VARLEN ohne Zahl in Klammern) werden im Datensatz nur 16 Byte reserviert, in der die Adresse der Overflow-Area hinterlegt wird. Werte die die allokierte Länge überschreiten werden, in der OverFlow-Area abgelegt und zwar mit der tatsächen Länge.
Beste Performance erhält man, wenn man für VarChar-Felder die allokierte Länge so definiert, dass ca. 80+ % der Daten direkt im Datensatz gespeichert werden können.
Birgitta
Schön dass du das so detailliert beschreibst.
Bzgl. der VARLEN-Felder würde ich ergänzen, alles zu allokieren solange die Satzlänge insgesamt dann 32K nicht übersteigt, da gibt es dann keine Probleme mit den 80%.
Somit wird nur 1 Zugriff statt 2 Zugriffe benötigt.
Die Aussagen sind ganz eindeutig (dazu braucht man nur in die SQL Referenz Appendix A zu schauen):
Die Grenze für Tabellen/physische Dateien ist 4,2 Mrd Datensätze oder 1,7 Terabyte, je nachdem welche Grenze zuerst erreicht wird.
Bei partitionierten Tabellen können bis zu 256 Partitionen mit den o.g. Grenzen zu einer einzigen Tabelle gehören.
Für Large Objects und VarChar-Felder wird innerhalb des Datensatzes nur die allokierte Länge (SQL Allocate bzw. DDS VARLEN(Zahl)) reserviert. Sofern keine Länge allokiert wird (ohne SQL ALLOCATE bzw. DDS VARLEN ohne Zahl in Klammern) werden im Datensatz nur 16 Byte reserviert, in der die Adresse der Overflow-Area hinterlegt wird. Werte die die allokierte Länge überschreiten werden, in der OverFlow-Area abgelegt und zwar mit der tatsächen Länge.
Beste Performance erhält man, wenn man für VarChar-Felder die allokierte Länge so definiert, dass ca. 80+ % der Daten direkt im Datensatz gespeichert werden können.
Birgitta
... die Welt (der AS400) ist ja so einfach und das System Ei und IBM ja so toll...
Ich sehe da erst mal im OP:
- maximale Anzahl der Erweiterungen: 32767
- Anzahl der Erweiterungen: 1950079
da scheint mir doch was auf Software defect hinzudeuten, da scheint doch von AS/400 nach Ei etwas an Qualität verloren gegangen zu sein.
D*B
PS: ich würde da mal:
- Software defect reklamieren, falls mein Release und Kundenstatus das noch hergibt
- die Datei umbenennen, neu erstellen, mit den Parametern, die ich haben will und hoffen, das der Fehler weg ist.