525er mit V5R4 versus SQL Server 2012 auf normaler Serverhardware

[KingofKning]

Hallo *all,

ich habe hier eine 525 mit V5R4 im Einsatz. Weiterhin setzten wir die Software Aruba ein, die die Daten per SQL abruft.

Da die DDS beschriebenen Dateien damals mit der Prämisse "Schnelle Umsetzung vor sauberen Design" realisiert wurde, läuft das zwar aber jede Schnecke ist schneller....

Der Vorschlag lautet jetzt die Daten auf einen 2012er SQL-Server zu schubsen und die Abfrage dort laufen zu lassen.

Kann man da auch nur Ansatzweise erwarten das ein PC-Server die Daten schneller liefert als die AS/400?

Den Index-Advisor habe ich schon zur Optimierung genutzt, da hier aber die Daten viel mit Join etc. beschafft werden, bräuchte es wohl ein komplettes Redesign.

Dafür fehlen mir aber die SQL Kenntnisse umd die Dateien optimal zu gestalten, und auch die Kenntnisse die RPG-Programme dann anzupassen.

Könnte ein blosser Umstieg auf V7R1 etwas bringen, auch wenn man die Dateien nicht optimiert?

GG

[BenderD]

... ohne Anpassung der Software kriegt man die Daten auch nicht auf den SQL Server. Ob das dann da schneller läuft oder langsamer ist, lässt sich aus dem Ärmel nicht beantworten und hängt in erster Linie von der Hardware ab. Der blanke Umstieg von Release V5R4 nach V7R1 macht das keinesfalls schneller, auch hier entscheidet die Hardware!!! (Bei gleicher Hardware ist das neuere Release eher langsamer, der Vorteil liegt darin, dass neuere Releases auf stärkere Hardware ausgelegt sind).
Für die Geschwindigkeit von SQL Zugriffen ist die physische Verteilung der Daten eher zweitrangig, was da zählt ist das Indexdesign, sprich: sind die erforderlichen Indexe statisch vorhanden, oder werden sie temporär angelegt. Ob das alles ausgereizt ist, wäre als erstes noch zu untersuchen.

D*B

[andreaspr@aon.at]

Hallo,

bei der Performance einer Abfrage spielt das OS nur eine marginale Rolle.

Ich habe schon Abfragen von Kunden vor mier gehabt, wo das SQL mit allen Joins und Sub-Selects über 1 A4 Seite hinausgegangen ist.
Abfrage lief 6 Stunden und wurde dann abgebrochen, da sie nie zu enden schien.
Nach kurzer Analyse legte ich gezielt einen Index an und die Abfrage lieferte in 10 sek. das Ergebnis.
Insgesamt hat mich das 20 min. gekostet (inkl. Erstellzeit für den Index)

Einen Umstieg auf 6.1 oder 7.1 kann aber auf jeden Fall helfen, da ab 6.1 ein Index auch eine WHERE Bedingung haben kann, was auch wieder viel Performance bringen kann.

Man muss halt nur aufpassen. Je mehr Indice vorhanden sind, desto langsamer sind Updates, Insert und Deletes.
Außerdem werden bei neuen Indice alte teilweise nicht mehr benötigt und sind nur noch Leichen.

Mit diesem SQL bekommst du alle Indice die länger als 2 Wochen nicht mehr benutzt werden.

Select * From QSYS2.SYSINDEXSTAT
Where Index_Schema like 'PRAN%'
And LAST_QUERY_USE < current timestamp - 14 days

lg Andreas

[KingofKning]

Unter V5R4 gibt es die Tabelle wohl nicht. Schade._GG

[Fuerchau]

Nicht per SQL.
Aber eigentlich sollte dann an dem Index/der LF das "zuletzt benutzt" Attribut gefüllt werden (DSPOBJD).

[BenderD]

Nicht per SQL.
Aber eigentlich sollte dann an dem Index/der LF das "zuletzt benutzt" Attribut gefüllt werden (DSPOBJD).

... da würde ich mich mal nicht darauf verlassen wollen. Basierend auf der Sysindexstat würde ich auch keine LFs blind löschen. Zugriffspfade dienen auch dem Query Optimizer als Informationsquelle, selbst wenn sie für den Zugriffspfad nacher nicht benutzt werden...