Unicode - Performance weg

[Fuerchau]

Das mit dem Allocate würde ich mal lassen. Wenn Geschwindigkeit Vorrang hat, dann sollte man VARCHAR's nicht splitten!

Was das Wachstum von 10GB zu 25GB angeht, so vermute ich dass neben der Unicode-Umstellung ggf. noch auf VARGRAPHIC bzw. NVARCHAR umgestellt wurde.
Wie der Vorredner schon sagte, es macht keinen Sinn jedes Feld auf Unicode umzustellen oder CHAR(1) auf NVARCHAR(1). Hier würde ein NCHAR(1) schon reichen.

[spiceisnice]

Danke für die Anworten bisher.

Das Datenbankdesign ist durch den ERP Hersteller vorgegeben, alle CHAR Felder auf GRAPHICS umgestellt. Der Größenwachstum ist ja noch beherrschbar, Problem bleibt eben die längere Datenübertragung, vor allen im BI Bereich auf Datawarehouse mit SQL Server als Ziel. QRY und CPYF sind nur einfache Beispiele um die Auswirkung rasch zu sehen, spielen in der Praxis keine Rolle.

[Fuerchau]

Ggf. klappt es ja mit Views bzw. Casts für die BI-Welt um die Übertragungslast zu minimieren:

cast(trim(UnicodeFeld) as varchar(nn) ccsid 1208)

CCSID 1208 entspricht UTF-8.
Dies ist ja variabel zwischen 1-4 Byte, wobei eben 99,9% aller Zeichen nur 1 Byte lang ist.
Damit kann das Übertragungsvolumen ja reduziert werden.

Allerdings geht der SQL-Server (oder auch andere ODBC-Programme) nicht davon aus, UTF-8 zu bekommen sondern entweder SBCS (1252 ANSI) oder Unicode (2-byte-Code).
Für die Umwandlung UTF-8 in Unicode gibt es im SQL-Server allerdings keine Standardfunktion.
Diese müsste man als .NET-Funktion noch integrieren.

Eine Komprimierung von 2-byte-Zeichen (im ODBC-Treiber einstellbar), wobei eben bei 99,9% das 1.Byte immer x'00' ist wird nicht so effektiv sein, da solche Routinen selten auf diese Spezifika eingehen.
X'40404040' lässt sich eben besser komprimieren als x'0020002000200020'.

Für BI gibt es nur eine vernünftige Lösung:
Übertragen der Daten in die SQL-Datenbank per Update-Lösung (Scripte), so dass nur neu entstandene Daten kopiert werden müssen und nicht immer alles.

Alternativ kannst du ja auch Views erstellen, die dir für BI alles wieder auf 273 umwandeln solange du keine gemischten Daten (West-/Osteuropa) hast.

Und vielleicht ist ja alles gar nicht so schlimm.

[andreaspr@aon.at]

Das mit dem Allocate würde ich mal lassen. Wenn Geschwindigkeit Vorrang hat, dann sollte man VARCHAR's nicht splitten!

Eigentlich ist es genau umgekehrt. Wenn kein Allocate angegeben wird, werden IMMER die Werte außerhalb des Satzes gespeichert. Somit müssen zusätzliche I/Os durchgeführt werden um die Werte der Spalten zu bekommen.
Mit dem ALLOCATE Parameter kann definiert werden ab wieviel Zeichen erst der zu speichernde Wert ausgelagert werden soll.
Beispiel:
Wenn also der Großteil der Werte einer Spalte nicht mehr als 20 Zeichen beinhalten und die Spalte mit VARCHAR(200) definiert wurde, macht es zwecks Performance Sinn ein ALLOCATE(20) zu definieren.
Somit bleiben die vielen kleineren Werte zusammen im gleichen Speicherbereich wie der Satz selber und man erspart sich viele I/Os dadurch.

[alfredo]

Angeblich gibt es minimum-Allocate von 32 Bytes, die das System immer nimmt.
(Wahrscheinlich weil, viele das Allocate vergessen)

Speziell bei Kommentarfeldern mach Varchar Sinn.
Beispiel möglicher Kommentar 500 Zeichen, es wird aber nur bei 1% ein Kommentar erfasst.

Bei Zuweisung in RPG ist ein %trim empfehlenswert.
Man kann das mit SQL mit Length(Feld) bei besetehenden Daten überprüfen.

Bei uns ist auch der Trend Richtung Unicode.
Das ist natürlich für Joins problematisch, wenn manche Dateien umgestellt sind, andere nicht.

[BenderD]

... ist doch interessant, dass beim Thema Performance immer wieder die Mythen dominieren:
- varchar und allocate: Angabe von Allocate < Feldlänge spart Platz und wird mit zusätzlichem synchronem I/O bestraft, wenn die belegte Feldlänge > alls der allocate ist. Das lesen von "Luft" ist asynchroner I/O und kann wg. pre paging vernachlässigt werden.
- VARCHAR allgemein: Verwendung von VARCHAR ist verbreiteter Standard außerhalb von DB2, die AS/400 Implementierung ist lausig und ich würde das eher vermeiden, wenn nicht Datenbank Unabhängigkeit gefordert ist.
- Unicode: was die Positionierung der AS/400 angeht ähnlich wie VARCHAR, aber "wat mutt dat mutt"
- Keyfelder: Keyfelder sollten immer Binary sein (Integer oder CCSID 65535), niemals VARCHAR (eine verbreitete Oracle Sitte) - ansonsten können unterschiedliche Keys je nach Einstellungen des Bildschirms gleich aussehen (das ist also kein Performance Problem).

D*B

[Fuerchau]

Laut Doku (SQL-Handbuch) gehört die IBM diesbezüglich tatsächlich erschlagen!

Schaut man sich den Callstack mal so an, dann ist die letzte Ebene beim File-IO immer QDBPUT/QDBGET.
Bei Native-IO genauso wie bei SQL.
Beim Lesen wird also immer der gesamte Datensatz bereitgestellt, beim Schreiben der gesamte Datensatz erwartet. Zusätzlich gilt immer noch die Regel, dass die Satzlänge (ohne LOB's) ja max. 32KB ist.
Also muss ich im Umkehrschluss alle VARCHAR's mit ALLOCATE(Defined-Size) definieren damit diese eben im Satzbereich und nicht extra gespeichert werden.
Platz sollte hier nicht ausschlaggebend sein.

Die IBM sollte den Default für ALLOCATE irgendwie so setzen können, dass dies immer gilt.
Man bedenke, dass beim Lesen immer die gesamte Datenzeile zur Verfügung gestellt wird. Also zusätzliche IO's für den Varchar-Bereich immer durchgeführt werden.
SQL entnimmt dann die benötigten Variablen aus diesem Puffer bzw. stellt sie beim Update dort hin.
RPG/LE macht dies genauso, in dem die verwendeten Felder per Move aus dem Puffer in die Variablen übertragen werden (auch wenn eine DS definiert ist!) und beim Update wieder zurück.
COBOL arbeitet direkt mit dem IO-Puffer.

Fazit:
Wenn also Performance gewünscht wird, so muss man bei Create Table / CRTPF für Varchar/Nvarchar die Allocate-Klausel auf das Maximum setzen!

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