AVANTI: GM vermisst

[Thomas Berger]

Dierk Hoeppner wrote:
> 
> Herr Berger schrieb:
> 
> > > nutzen will - verglichen mit dem Direktzugriff ist die Nutzung von
> > > avanti langsamer -
> Im Zusammenhang mit der WBI-Datenbank, die es jetzt bei uns gibt,
> habe ich so etwas mal grob getestet. Zunaechst mal wird ja fuer jeden
> Job ein neuer Prozess gestartet. Unter UNIX wie unter Windows. Das
> kostet vom Prinzip her Zeit. Dann wollte ich eine Datenbank (fast)
> neu aufbauen: Eine funktionierende DB auf einer SUN (220 Mhz) mit
> einer Handvoll Daten sollte mit ca. 1,5 Millionen DS aufgefuellt
> werden. Ich habe dann mit einem Python-Script immer Packen zu 50
> Datensaetzen von meinem Rechener ruebergeschickt. Alle 1,5 Mio. Saetze
> auf einmal schafft avanti nicht :-( Deswegen die Stueckelung. Daher
> viele Prozesse und viele Rueckmeldungen, die entgegengenommen wurden.
> Das hat viel Zeit gekostet. Mehrere Stunden. Das wurde in der
> Nacht dann voellig durch die Bandsicherung ausgebremst, so dass er
> am Morgen immer noch dabei war.
> Das selbe lokal mit update ging wesentlich schneller. Am schnellsten
> ging, weil auch sehr viel V14 Stammsatzersetzungen zu erledigen
> waren, dies: Aus den Grunddateien Pseudo-ALds gemacht und dann einen
> Reindex machen.
> 
> Zugegeben, dies ist ein extremes Beispiel. Aber zum Testen ganz nett.

Haben Sie auch mit der update-Funktion von Avanti getestet,
denn was sie beschreiben, ist doch ein Upload, wo die Saetze
Bestandteil des Jobs sind.

Ich selber habe ausserdem auch das umgekehrte Extrem im Kopf:
hunderte von Malen am Tag muss ein Upate von ganz wenigen
Saetzen gemacht werden.

 
> > Ich denke an Faelle, wo regelmaessig viele Daten eingespielt
> > werden und (loeschungen, splits, umlenkungen) ueber die
> > Moeglichkeiten des -fm-Schalters von Update hinaus komplexe
> > Vergleiche vorgenommen werden.
> 
> Da wuerden die vorhandenen Mittel (Exportsprache, Script-Sprache) aber
> schon ausreichen. Was noch fehlt ist eine exklusive
> Schreibberechtigung fuer einen ueber einen laengeren Zeitraum, wo man
> dann seine Sachen machen kann. Wir denken uns etwas in dieser
> Richtung aus.

Ich weiss nicht so recht:
Auch wenn ich die exklusive Berechtigung habe, muesste ich
einen Job absetzen (bzw. SRCH starten), der mir den aktuellen
Zustand des Satzes liefert, ihn per download an den Client
schicken (nur so wird er einer .cPR unterworfen), der Client
schickt ihn dann mit einem neuen Job zurueck.

Fazit sind zwei Jobs pro Datensatz. 

Wenn ich das fuer viele Saetze machen, muss ich zwischendurch
die exklusive Berechtigung wieder abgeben und etwas warten,
denn ansonsten koennte ich die Bearbeiter ja in den Feierabend
schicken und alles konventionell mit SRCH und UPDATE machen.

Zweiter Nachteil der zwei-Job-Loesung ist, dass ich keine
Operationen machen kann, die die Identnummer aendern.

Ich glaube wirklich, dass ein "internes Ein-Satz-Download"
etwa 
get object 1 --(xxx.cPR)--> put object 2
sehr viel Nutzen bringen wuerde (xport param 2 haben Sie
fuer nicht-ZAD-Verbindungen ja abgeklemmt, da sollte doch
noch ein Slot fuer eine Parameterdatei frei sein :-)

viele Gruesse
Thomas Berger