-
Hallo,
Vielen herzlichen Dank für Eure Antworten.
Ich möchte im Moment eigentlich nur wissen, wieviele Sätze in dieses Member gehen ..... ???
-
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.
-
 Zitat von B.Hauser
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.
-
 Zitat von BenderD
- 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.
Das ist eher ein Übersetzungsfehler (findet man ja öfter)... Maximale Erweiterungen = x Erweiterungen a 1000 Sätze.
Aktuelle Erweiterungen = je 1 Satz.
Aber heutzutage spricht man lieber nicht mehr von Membern, und auch nicht von Dateien mit Satzbegrenzungen.
Und wenn wir Langeweile haben, bauen wir uns mal eine 10TB-Spielwiese und probierens aus...
-h
-
Vielen Dank an Euch. Meine Frage ist beantwortet.
Im IBM-Knowledge-Center ist das im Original-Englisch ganz genau beschrieben:
Record capacity. The actual number of records this member can contain. The value is calculated by multiplying the increment number of records by the maximum number of increments, and adding the initial number of records. This field only applies to a physical file and is 0 for a logical file.
Hab's erst bei der Beschreibung des QUSRMBRD-API gefunden.
Da kann man natürlich diesen Wert auslesen.
THX.
-
 Zitat von wilfried
Vielen Dank an Euch. Meine Frage ist beantwortet.
Im IBM-Knowledge-Center ist das im Original-Englisch ganz genau beschrieben:
Record capacity. The actual number of records this member can contain. The value is calculated by multiplying the increment number of records by the maximum number of increments, and adding the initial number of records. This field only applies to a physical file and is 0 for a logical file.
Hab's erst bei der Beschreibung des QUSRMBRD-API gefunden.
Da kann man natürlich diesen Wert auslesen.
THX.
Anfangsanzahl der Sätze . . . . . . . . : 10000
Satzanzahl für Erweiterung . . . . . . : 1000
Maximale Anzahl Erweiterungen . . . . . : 32767
Aktuelle Anzahl Erweiterungen . . . . . . : 1950079
Satzkapazität . . . . . . . . . . . . . . : 1950089000
32767 * 1000 + 10000 = 32777000
obige Anzeige behauptet allerdings, dass fast das 60 fache an Erweiterungen vorläge.
D*B
PS: im übrigen sagt diese Berechnung nichts darüber aus, ob man wirklich so viele Sätze da reinkriegen würde - sieh dir mal sysibm/sysdummy1 an, die steht auf *NOMAX und da geht nur ein Satz rein.
-
Wie D*B ja schon bemerkte, rein rechnerisch stimmt da ja was nicht:
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
10.000 + 32767 * 1000 = 32.777.000
Aktuelle bereits 32.793.064?
Möglich sind aber 1.950.089.000 ?
-
Also ich habe das so gerechnet:
Aktuelle Anzahl Erweiterungen * Satzanzahl für Erweiterung + Anfangsanzahl der Sätze = Satzkapazität
1950079 * 1000 + 10000 = 1950089000
So kommt man zumindest auf die "Satzkapazität". :-)
Es scheint so, dass die "Maximale Anzahl Erweiterungen" mit 32767 falsch ist. ?? Mhm .... Grübel ....
(Hinweis: Wir sind hier unter V7R1 mit Service-Extention).
THX.
-
Wobei dies ja wiederum bedeuten würde, dass du jede Menge Daten wieder gelöscht und einen RGZPFM gemacht hast.
Similar Threads
-
By FichtenElch in forum IBM i Hauptforum
Antworten: 13
Letzter Beitrag: 26-04-18, 11:50
-
By alex61 in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 04-08-17, 19:36
-
By Miles in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 22-08-14, 14:15
-
By Robi in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 13-11-01, 17:07
-
By Matthias.Hayn in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 20-05-01, 16:36
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks