Unicode - Performance weg

[Fuerchau]

Varchar als Keyfelder sind von der Bedeutung her unkritisch!
Bei einem Unique-Key sind die Schlüssel "A" und "A " identisch, da bei einem SQL-Vergleich per Definition ungleich lange Zeichenketten nach rechts als mit Leerzeichen aufgefüllt gelten.
Bei COBOL/RPG gilt dies im Vergleich genauso.
Anders ist es leider bei den Programmvariablen vom Typ String, z.B. in C++ (CString), Java, .NET, VBScript u.v.m.
Hier wird ein Vergleich über alle Zeichen durchgeführt, d.h., dass "A" dann ungleich "A " ist, deshalb wird dann hier häufig mit TRIM-Funktionen gearbeitet.
Wenn ich dann die Sprachen mische, habe ich natürlich in der Behandlung von Varchar's ein paar Probleme.

Was das Speichern/Lesen angeht so werden die "nicht verwendeten" Zeichen immer mit Leerzeichen aufgefüllt. Es bleibt nie ein Rest irgendwie stehen.
Einzig RPG kennt das Problem beim MOVE ohne (P), dass hier Schrott stehen bleiben kann (was häufiger auch beabsichtigt ist).

[BenderD]

... dieses Verhalten ist Database abhängig, Oracle sieht das anders als DB2. Das Problem ist ganz generell, dass Keyfelder in der Anzeige (und bei Zuweisungen innerhalb SQL) nicht konvertiert werden sollten, weil dies zu seltsamen Effekten führen kann.

[COS]

Liebes Forum,

eventuell hat jemand ähnliche Erfahrungen gemacht (und ev. Lösungsansätze):

Wir stellen gerade eine klassische AS/400 RPG Standardsoftware auf JAVA Unicode um (infor MOVEX 12.5 RPG auf infor M3 13.2).

.....

Wo kann man hier ansetzen? Infrastruktur ist aktuell mit Power7 6Proc, V7R1, VIOS, Partitionen, SVC und SAN mit V7000 etc....


wieviel RAM hat denn die Partition und wie sehen die WRKSYSSTS Werte aus ?

wenn von Record-Level-Access auf SQL-Zugriffe (JDBC) gewechselt wird,
ist mehr RAM durchaus empfehlenswert.

[Fuerchau]

RAM spielt zwar auch eine Rolle, aber nicht so sehr in diesem Zusammenhang.
Ich glaube da liegt ja auch eher ein Mess-/Rechenfehler vor:).
Von 150MB/Sek. nach 60MB/Sek. halte ich für ein Gerücht.
Die Frage ist, was denn da gemessen wird.
In Summe würde sich ja a) doppelte Zeit und b) doppelte Datenmenge eine vierfache Verarbeitungszeit ergeben.

Wichtiger ist da eher wie viele Sätze je Sekunde verarbeitet werden.
Da sich die Satzlänge (siehe DSPFD) ja ggf. mehr als verdoppelt hat (10GB -> 25GB) muss natürlich auch mehr gelesen/geschrieben werden.
Wenn dann auch noch VARGRAPHIC/NVARCHAR an Stelle von GRAPHIC/NCHAR verwendet wird erklärt sich natürlich (siehe oben) die stärkere IO-Last.

Ach ja, was die IO-Zeiten so angeht kann es auch an einer anderen Plattenverteilung liegen.

[COS]

ggf. auf Euren PTF-Stand achten:



Dear SAP on IBM i users,

there was a performance issue found with DB Group 30 installed on R710.
PTFs were marked defective.

There were no functional issues found and are all performance issues.

The defective PTFs have been removed from the download List and have been replaced by MF59226, MF59240 and MF59241. The fixing DB Group 31 is being worked on.

Please go ahead and load and apply these PTFs (plus CO's and PRE's) to avoid performance issues.

Sorry for the circumstances !!


i.A. Stephan Schuettler
IBM i Global Support Center
SAP on IBM i Power Systems
Germany