Varchar Felder und tatsächliche Länge in DB

[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

[andreaspr@aon.at]

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

Wie gesagt, das war auch die Aussage bei einer Abfrage die 10 Minuten dauerte, bis ich sie dann auf 200 mSek verbessert habe.
Ich höre diese Sprüche immer wieder und immer wieder sind sie widerlegbar!

Ich habe bis jetzt noch kein System gehabt, wo nicht enormes Potential zu verbesserung der Leistung vorhanden war.

Und nur zu behaupten, man habe mit ein paar Indizes des Index Advisors probiert das System zu verbessern, zeigt mir eigentlich schon, dass man gar nicht wirklich versucht hat sich damit zu beschäftigen.

Das System ist generell extrem stabil und auch sehr schnell.
Wenn sich der Hersteller auf der AS/400 nicht auskennt ist es das eine.
Wenn jedoch der Hersteller behauptet, das System sei langsam, weil SEINE Anwendung nicht vernünftig darauf läuft, so ist das was ganz anderes!
Und wenn man das noch den Hersteller blind glaubt, dann hat man sowieso schon verloren

[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?

[andreaspr@aon.at]

Dafür gibt es bei Oracle und auch bei anderen Systemen Statistiken im System und Optimierungen in der Engine.
Die sollte von selbst erkennen welcher Index am Besten ist.
Wenn das nicht der Fall wäre würde ich das einfach als BUG bezeichnen.
Das Beispiel mit der Sortierung (fehlendes ORDER BY) von Baldur fand ich sehr passend!

[Fuerchau]

Im Zweifel wird ein ungeschickter Index gar nicht erst verwendet.
Manche SQL-Dialekte erlauben da sogar, den zu nehmenden Index vorzugeben, egal ob er passt oder nicht.
Gerade solche Sachen sollte man wirklich der DB überlassen, wenn sie denn korrekt implementiert ist.

Z.T. gehe ich bei ODBC-Anwendungen sogar hin, lade die Daten unsortiert und sortiere mit Hilfe der vorhandenen Methoden von ADO.
Dies hat sich manchmal sogar als performanter erwiesen, ins besonders wenn man Sortierungen auf berechneten Feldern hat.

Auch dieses ist mitunter ein SQL-Problem, Berechnungen in den OrderBy aufzunehmen wo mit Sicherheit kein Index vorhanden sein kann.
Auch Berechnungen in der Where-Klausel sind solche Kandidaten.
Es gibt viele ungünstige Methoden, wo jede DB halt ihre Stärken oder Schwächen darauf hat und unterschiedlich performante Ergebnisse bringt.