Varchar Felder und tatsächliche Länge in DB

[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

[Fuerchau]

Ein gutes Datenbankdesign und eine darauf abgestimmte Anwendung läuft mit jeder Datenbank performant.
Spezielle DB-spezifische Methoden sind da grundsätzlich nicht nötig.
Die DB2/400 hat lange Zeit Designfehler halt bestraft (falsche Zugriffe, fehlende Indizes), seit V6 legt die DB da schon mal diese permanenten Indizes an, die dann beim nächsten IPL wieder weg sind.

Oracle und co. haben den Entwickler bei schlechtem Design durch Automatismen halt besser unterstützt, was man der DB2/400 nicht zu lasten legen sollte.

Ich lade z.B. aus einer Oracle-DB per Java Daten auf die AS/400 und umgekehrt.
Ein simpler SQL auf eine View in der Oracle-DB (select * from View) dauert bis zum 1. Satz schon mal mehrere Minuten.
Wenn ich dann mal nachfrage wieso das so lange dauert (an die DB darf ich nicht dran), dann bekomme ich nur zur Antwort "Das ist halt so, Indizes dürfen wir nicht anlegen da das die Anwendung sonst stören könnte".
Was für eine bescheuerte Aussage.
Wie kann ein Index die Anwendung stören?
Da kann ich mir nur vorstellen, dass da so mancher "order by" fehlt und man die Sortierung dann so erwartet wie sie die DB liefert und wundert sich dann beim nächsten Servicepack wieso die Anwendung auf einen Fehler läuft.

[Pikachu]

... "Das ist halt so, Indizes dürfen wir nicht anlegen da das die Anwendung sonst stören könnte".
Was für eine bescheuerte Aussage.
Wie kann ein Index die Anwendung stören?

Theoretisch wärs doch zumindest möglich, daß sich ein SQL in einer Anwendung dann ab und zu für diesen neuen Index entscheidet (sich verrennt) obwohl ein anderer vorhandener Index schnellere Ergebnisse gebracht hätte. Es könnte doch sein, daß ein ungeschickter Index alles an sich zieht und ausbremst? Oder kommt sowas in der Praxis nie vor?