[Allegro] Update Erfahrungen

Mi Jan 11 10:14:51 CET 2017

Guten Tag Herr Fischer,
danke für Ihre Nachricht.
Am Dienstag, 10. Januar 2017 um 17:20 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

in Suhl sitzend, hier ist schnee!

ich saachte:
>> dann müsste es auch schnell wie idefix gehen!
>> 250.000 datensätze sind nix!
> Das hat jetzt insgesamt knapp 24 Std. gedauert, als "nix" würde ich das nicht bezeichnen.

das muss schneller gehen! wirklich!!!

was ich bei meinem bigdata-projekt gemerkt habe:
die ausgangsdatenbank sollte "klein und fein" sein!

"klein und fein" =
1. frisch indexiert! (5 mill datensätze, 8GB, das indexieren dauert ca
15-30 min)
2. mit einer api, die winzig ist! (SEHR winzig)
nur  mit einem PS. zum thema PS habe ich viel geschrieben (z.B. satzzeichen
am anfang eines PS sind plusungut!)
3. und DAS gilt es noch zu überlegen, in der cfg:
f500 oder f10000
4.  und  in  der  cfg  ALLE  felder  erlauben:  von  0.-9.;  bestimmte
feldanfänge an der 2. stelle a-Z. im ganzen sehr großzügig sein!
acon IST sehr zickig, wenn es auf ein unerlaubtes feld trifft!

> Was genau passiert, ist mir nicht klar, die Anzeige im cmd-Fenster
> blieb manchmal recht lange stehen, um sich dann doch wieder weiter zu bewegen.

nein,  das  geht  zackzack.  man  kann  KAUM die zeilen mitverfolgen, so
schnell geht das!

> Wichtig ist natürlich die Einstellung -F0/0, ohne die dauert das eher drei Tage (mindestens!).
> Ich möchte fragen, ob das nicht als Standard gesetzt werden kann,
bitte definitiv nicht.

[das  ist  das  schöne  an allegro-skripten, ICH setze die parameter!
keiner bestimmt MIR was vor! ;-)]

> weiß aber nicht, ob viele Administratoren Updates laufen lassen,
> während andere Nutzer an der Datenbank arbeiten. Ich vermeide das.

ja z.b.: olle icke. mein allegro-zdb wird vom admin angestossen, und
läuft,  ohne die kollegen zu BELÄSTIGEN! und nach ein paar stunden hat
man neue zdb-datensätze in der eigenen datenbank drin!, OHNE (fast)was
zu merken.

> Ich habe aber auch mit acon knapp 10 Anläufe gebraucht, weil es
> zwischendurch hing oder abstürzte.
> Die Meldung im CMD-Fenster war dann
> EXCEPTION-Error (memory-access) in program "acon.exe" !!

mögliche   ursachen:   ein   feld   fehlt  in  der  cfg.  der  PS  ist
falsch/unsauber konstruiert.
evtl noch  mehr ursachen....

> Eventuell meldete sich auch Windows mit
> [Window Title]
> acon, console program f. allegro/avanti
> [Main Instruction]
> acon, console program f. allegro/avanti funktioniert nicht mehr
> [Content]
> Das Programm wird aufgrund eines Problems nicht richtig ausgeführt.
> Das Programm wird geschlossen und Sie werden benachrichtigt, wenn eine Lösung verfügbar ist.
> [Debuggen] [Programm schließen]

arbeiten sie etwas immer noch in der virtuellen maschine?
nur dos kann sauber ;-)

ich  würde  immer alle "parameter" oder "zustände" abschalten, die von
der  norm  abweichen.  oder alles "zusätzliche" (wie z.b. das arbeiten
UNTER a99.exe; grauslich!).
;-)

viel glück.

grüße, ihr klaus lehmann

ps:  es ist immer schwierig, solche ratschläge umzusetzen. evtl muss man
(s)ein  ganzen  grundkonzept ändern. und das tut man meistens nie ;-)
für das saubere durcharbeiten von
anfang   bis   ende  (ohne  fehler und abstürze), habe ich ca 1- 1 1/2
jahre für allegro-imd benötigt.
allegro-zdb ging schneller: ca 3/4 jahr..... ;-)

-- 
Mit freundlichen Grüßen,
Ihr Klaus Lehmann
http://allegronet.de * eMail: allegronet at t-online.de * phone: 03528-452 807(fax 809) * mobil: 0171-953 7843
allegronet.de * Klaus Lehmann * D-01454 Radeberg * Bahnhofstr. 1
zuständiges Finanzamt: FA Hoyerswerda; zuständige Kammer: IHK Dresden;
zuständige Aufsichtsbehörde: Gewerbeamt Radeberg; USt-IdNr: DE247550760
* Software für zufriedene Bibliothekare: 1000x bewaehrt und ergiebig
* Bereits 4x allegro-utf8. Buchen Sie die allegro-Roadshow. Yes we can!
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 mit VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: Bolero 64bit. Fußige Noten aufgeblättert (=Die Fußnotendoku)
* 2014: allegro-zdb: endlich. Die Wiedervereinigung! + eBooks
* 2015: allegro-vufind. Endlich! Noch moderner! Web2 auch für Ihren Katalog?
* 2016: allegro-imd.Die weltgrößte(?) Filmdatenbank nur für Filmbibliotheken
Lesen Sie auf http://portal.allegronet.de/allegrowerkstatt/allegro-windows die
Wahrheit zur Zukunft von allegro-C. Bilden Sie sich Ihre eigene Meinung! Lesen Sie!

Am Dienstag, 10. Januar 2017 um 17:20 schrieben Sie:
> Liebe KollegInnen,

> mein (erster…) Update dieser Datenbank ist jetzt erfolgreich
> durchgelaufen, ich will hier nur kurz meine Erfahrungen und Ergebnisse vorstellen.

> 1. Update mit A99
> Versuche mit A99 sind durchweg gescheitert. Ich hatte das – u.a.
> wegen des "Update auf Probe" und der visuellen Kontrolle – zunächst
> bevorzugt, aber dann aufgegeben, weil A99 ständig hängenblieb und
> auch der einzelne Update zu lange dauerte.

>>> Das läuft bei A99 immer für einige Datensätze (ein paar Hundert), und dann bleibt A99 mit einer Anzeige der Art
>>> 238. Rec# 95295, |41 68.0489.01
>>> stehen, und es geht erst weiter, wenn ich den Update erneut aufruft.
>> 
>> Bei größeren Datenmengen bleibt a99 manchmal scheinbar stehen, in Wirklichkeit läuft der Prozeß aber weiter!

> Bei mir lief der Prozess nicht weiter: entweder A99 stürzte ab oder
> es hing, ohne dass Datenbankdateien oder Logdatei sich nicht änderten.

> Schnell lief nur der Update aus Probe. Dass A99 bei dem Versuch,
> die Daten auch zu speichern abstürzte, könnte ich ich verschmerzen.
> Für das dann aber bei jedem (?) Datensatz auftretende

> Date diff: inceton, (2) 42, 409-428 (1941) / 20170107/16:27:48-96896/156
> …
> Sorry, jemand anders war schneller
> und hat den Satz inzwischen geändert

> weiß ich immer noch keine Lösung. Damit ging es definitiv nicht weiter.

> 2. Update mit acon und update.job
>> Am 09.01.2017 um 12:45 schrieb Klaus Lehmann <lehmann_klaus at t-online.de>:
>> 
>>> hier noch ein paar weitere Informationen und Fragen zu meinem Updateprozess.
>>> Die Updatedatei ist eigentlich recht simpel, darin sind alles Zweizeiler der Art
>> ;-)
>> dann müsste es auch schnell wie idefix gehen!
>> 250.000 datensätze sind nix!

> Das hat jetzt insgesamt knapp 24 Std. gedauert, als "nix" würde ich das nicht bezeichnen.
> Was genau passiert, ist mir nicht klar, die Anzeige im cmd-Fenster
> blieb manchmal recht lange stehen, um sich dann doch wieder weiter zu bewegen.
> Wichtig ist natürlich die Einstellung -F0/0, ohne die dauert das eher drei Tage (mindestens!).
> Ich möchte fragen, ob das nicht als Standard gesetzt werden kann,
> weiß aber nicht, ob viele Administratoren Updates laufen lassen,
> während andere Nutzer an der Datenbank arbeiten. Ich vermeide das.

> Ich habe aber auch mit acon knapp 10 Anläufe gebraucht, weil es
> zwischendurch hing oder abstürzte.
> Die Meldung im CMD-Fenster war dann
> EXCEPTION-Error (memory-access) in program "acon.exe" !!

> Eventuell meldete sich auch Windows mit
> [Window Title]
> acon, console program f. allegro/avanti
> [Main Instruction]
> acon, console program f. allegro/avanti funktioniert nicht mehr
> [Content]
> Das Programm wird aufgrund eines Problems nicht richtig ausgeführt.
> Das Programm wird geschlossen und Sie werden benachrichtigt, wenn eine Lösung verfügbar ist.
> [Debuggen] [Programm schließen]

> (Eine Nachricht habe ich nicht bekommen…)

> Da danach auch immer die Satztabelle gesperrt war, habe ich in
> update.job an geeigneter Stelle ein
> set tbl fre
> angebracht.
> Die einzelnen Versuche lieferten normalerweise zwischen 40.000 und
> 70.000 Datensätze vor Absturz oder Hängenbleiben. Nach ein paar
> Versuchen, die nach wenigen Sätzen abbrachen, habe ich das
> Windowssystem neu gestartet, danach sind die letzten 20.000 Sätze klaglos durchgelaufen.

> Die erfolgreichen Versuche lieferten zunächst etwa 7-9.000 Sätze
> pro Stunde, am Ende 12-14.000 Datensätze.

> Herr Wolf hatte mir noch geschrieben und u.A. Bedenken gegenüber
> update.job im Vergleich zu update.exe geäußert. Das werde ich noch probieren.

> Ob dieser Prozess mit anderen Bedingungen besser gelaufen wäre,
> kann ich nicht sagen. Mein Eindruck ist aber, das weder
> – die Kategorienummer #05 (im "hierarchischen" Bereich, da wüsste
> ich sowieso gern mal, was das macht oder heißt) noch
> – die Punkte im Primärschlüssel
> etwas ausgemacht haben: Ich kann mir nicht vorstellen, dass das
> nach 70.000 Sätzen plötzlich zuschlägt.

> Nach den Abstürzen habe ich immer bei dem letzten erfolgreichen
> Datensatz weiter gemacht, damit liegen die Abstürze wohl nicht an
> (drastischen) Besonderheiten der jeweiligen Datensätze.

> Ich werde mich jetzt den nächsten Updates zuwenden.
> Für etwaige Hinweise und Erklärungen, insbesondere die Abstürze
> betreffend, wäre ich natürlich dankbar.

> Mit freundlichen Grüßen
> Thomas Fischer