Varchar Felder und tatsächliche Länge in DB

[itec01]

da sieht man mal wieder, dass die AS/400 nicht für solche Dinge gemacht wurde.
Man muss sehr aufpassen, dass man die Varchar Felder korrekt füllt.
Eine Zuweisung mit *blanks geht schief, weil hier der volle Wert genommen wird. Hier muss man geziehlt einen clear auf das varchar Feld machen.
Hat man in einem Programm sowohl das Füllen als auch das Auslesen eines Varchar Feldes geht es nicht mit dem %trim, weil man CVTOPT(*VARCHAR) benötigt. Hier muss man dann die ersten zwei Stellen manuell füllen.

Ich bin nun am Überlegen komplett auf die varchar Logik zu verzichten, weil ich auch denke, dass varchar Felder langsamer bei den Dateioperationen sind.
Was denkt ihr und wie habr Ihr dies organisiert?

Gruß

[B.Hauser]

VarChar-Felder werden zumindest mit EVAL sauber befüllt. Wenn Du allerdings in RPGIV immernoch mit MOVEs hantierst, ...

Wenn Du ein VarChar Feld mit *Blanks füllst ist klar, dass es komplett gefüllt wird. Um ein Feld zu initialisieren bzw. zu clearen ist der Befehl CLEAR da. Wenn Du willst kannst Du natürlich auch die Anzahl der belegten Zeichen mit %LEN setzten.

Beim Füllen aus Character Feldern mit fixer Länge wird nun mal die komplette Länge übertragen. Wenn Du die folgenden Blanks nicht benötigst musst Du diese eben mit einem %TRIM oder %TRIMR oder %SUBST entfernen.

Ich weiß nicht warum Du findest, dass das nicht logisch ist.

Birgitta

[Fuerchau]

weil man CVTOPT(*VARCHAR) benötigt ?

Achtung:
Wenn man diese Option verwendet, wird aus Varchar ein Feld fester Länge!
So wie ich es oben schon mal gesagt habe.
Klar muss man in diesem Fall die Längeninformation wieder selber verwalten.

Also diese Option nicht verwenden, dann klappts auch mit Varchar !!!

[itec01]

Hallo,
mal eine generelle Frage?
Ab welcher Feldlänge nutzt Ihr varchar Felder? Lt. Handbuch bedeuten varchar Felder meistens einen zweiten Plattenzugriff.
Ich habe ab einer Länge von 100 Byte damit begonnen varchar Felder mit varlen(1) zu nutzen. Nun habe ich im Handbuch gelsesen, dass man als varlen die Länge nehmen soll, die meistens gefüllt. Das lässt sich nicht immer so einfach sagen. Auf jeden Fall soll es Probleme mit der Performance geben. Ich habe nun größte Bedenken bei Tabellen mit ca. 10 Mio. Sätzen und einigen Varchar Felder.


Danke.

Klaus

[B.Hauser]

1. bis zu einer Länge von 32 Zeichen werden die Daten nicht in die Overflow-Area geschrieben, sondern direkt im Datensatz verwaltet. Ich gebe trotzdem immer explizit die reservierte Länge (ALLOCATE(x) in SQL Tabellen oder VARLEN(X) in DDS Dateien) an.
2. Wenn Du VARLEN ohne Zusatz oder VARCHAR ohne ALLOCATE definierst werden alle Texte für Spalten mit mehr als 32 Zeichen in der Overflow-Area gespeichert, wodurch ein Extra-Zugriff erforderlich ist. (Kommt noch aus der Zeit als Speicher knapp und teuer war.)
3.Die Empfehlung lautet, dass die beste Performance dadurch erreicht werden kann, wenn ca. 80+ % aller Daten im Datensatz gespeichert werden. Der zusätzliche Zugriff auf die Overflow-Area erfolgt nur für die Ausreißer, d.h. die Texte die länger als die reservierte Länge sind.
3. Der (zusätzliche) Zugriff in die Overlow-Area wird nur dann kritisch, wenn gleichzeitig Large Object-Spalten verwendet werden. Soweit ich das bei Dir beurteilen kannst arbeitest Du mit DDS beschriebenen Dateien, bei denen eh' keine LOBs definiert werden können.

Die Verwendung von Feldern mit variabler Länge ist z.B. auch beim Selektieren besser, da die belegte Länge im Feld hinterlegt ist und dann auch nur diese Anzahl an Zeichen verglichen wird.
Weiterhin ist ein TRIM nicht erforderlich, der bei großen alphanumerischen Feldern mit fixer Länge ebenfalls zeitintensiv ist, da beginnend von der letzen Stelle aus rückwärts geprüft werden muss.

M.E. sind Felder mit variabler Länge sooft wie möglich verwendet werden (Ausnahme vielleicht kurze Felder bis 10 Zeichen).

Birgitta

[BenderD]

... die Verwendung von varchar ist im Bereich von Oracle und DB2 auf Mainframe Standard und das spricht eindeutig für varchar. Auf der AS/400 wäre ich da sehr vorsichtig und würde das vorher mal benchmarken, wie sich das auswirkt. Meine letzten Benchmarks in dieser Richtung (muss so V5R2 darum gewesen sein) waren katastrophal, das war um mehr als 20 % langsamer, bei Flächen deckender Verwendung von Varchar.

D*B

[Fuerchau]

Ein Vergleich von Varlenfelder oder Fixed-Feldern im SQL ist unerheblich, da bei unterschiedlicher Länge der Rest mit Blanks angenommen wird.
Ein Trim wird hier nicht durchgeführt, da der Vergleich auf MI-Ebene erfolgt (CMPBLA = ohne Blanks, CMPBLAP = mit Blanks) und bewegt sich im Nanosekundenbereich.

Entscheidend ist natürlich der 2. benötigte Zugriff, deshalb die allocierte Länge.
Da ein Datensatz ohne LOB's aber 32KB nicht überschreiten kann, sind Varlenfelder mit Überlaufbereich eher kontraproduktiv.

In DDS kann man daher besser die Allocate-Länge auch auf die max. Länge setzen.

[HerbertW]

Auf der AS/400 wäre ich da sehr vorsichtig und würde das vorher mal benchmarken, wie sich das auswirkt.
D*B

Vor 30 Jahren, als Speicher knapp und teuer war, gab es auf dem System /34 Lohnabrechnungssysteme, die 1000 Abrechnungen per RPGII in einer halben Stunde im Spool bereitstellten.

Heute tröpfeln 10 Abrechnungen je Minute heraus. Dies mit einer Maschine mit der zigtausendfachen CPW-Leistung einer /34 und allem möglichen Schnickschnack wie SQL-Zugriff, Java-Client, VARLEN-Felder flächendeckend selbst bei einstelligen Kennzeichen im Satz, alle Datumsfelder in einer Länge von 26 Byte, 2000 SQL-Trigger, 4000 Einträgen im Indexadviser usw. Da ist doch der Fortschritt irgendwo auf der Strecke geblieben? Als wir die Anwendung auf SQL-Server migriert hatten, war wieder Ruhe und die Fachabteilung zufrieden.

[Fuerchau]

Dann denke ich, dass da schwere Designfehler in der Anwendung vorliegen.
Die Langsamkeit hier auf die Maschine zu schieben lag sicherlich nicht an der Umstellung auf SQL sondern an der falschen Verwendung von SQL.
Dieter könnte da sicherlich Romane schreiben.

10 Abrechnungen je Sekunde halte ich da schon für realistischer .

[andreaspr@aon.at]

Ja, dem kann ich nur zustimmen.
Bei meinem letzten Vortrag bei der IBM in Wien vorherige Woche habe ich ein paar genau dieser Beispiele gebracht.
Eine Abfrage in SQL die zwischen 7 und 10 MINUTEN!!! gedauert hat, konnte ich durch minimale Änderungen der Anweisung auf ~200 MILLISEKUNDEN beschleunigen!!
Das war zwar das extremste Beispiel, aber bei vielen, vielen anderen Anweisungen sind ebenso zw. 50% bis 400% mehr performance enthalten, wenn man sich nur etwas mit der Datenbank auskennt!!
Oder zumindest die Regeln die die IBM vorgibt beachtet.

P.S.: Bei der Anweisung die bis zu 10 Minuten benötigte, gab es auch den Satz: "Die Maschiene sei zu schwach"

lg Andreas

[HerbertW]

Die Anwendung ist lt. Hersteller (einer der Marktführer) für IBM i freigegeben. Aber nicht deswegen, weil er die DB der AS400 so toll findet, sondern weil viele Anwender das so wollten. Sie würden zwar eine andere DB empfehlen, aber wer unbedingt i haben will...

Sie hätten übrigens alles versucht, die Performance auf der i zu verbessern. Es sei nicht gelungen.

Als Anwender kann man noch den Indexadvisor beachten und den einen oder anderen Index anlegen. Viel gebracht hat das nichts.

Eine Anwendung, die auf Oracle oder SQL-Server gut läuft, läuft noch lange nicht gut auf AS400. Da muss der Hersteller anscheinend zusätzlichen Aufwand treiben. Als Anwender kam man ihm schlecht sagen, er möge doch mal bei IBM Kurse belegen, um das Problem in den Griff zu bekommen.

[BenderD]

... als Anwender kann und sollte man allerdings auch, eine Lösung immer nur im Verbund Hardware/Software betrachten und gegebenen Falls entsprechende Anforderungen an Antwortzeiten und Durchsatz in ein Pflichtenheft mit aufnehmen und sich vom Anbieter bestätigen lassen.
Für den Anbieter ist das von Dir geschilderte allerdings ein Armutszeugnis, das würde der ein oder andere hier im Forum Vertretene besser hinbekommen.

D*B