[Allegro] Update Erfahrungen

[Fischer, Thomas]

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

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 842 bytes
Beschreibung: Message signed with OpenPGP using GPGMail
URL         : <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20170110/525077c2/attachment.sig>