[Allegro] Indexzugrif bei hoher Netzlast

[Klaus Lehmann]

Guten Tag allerseits, 
danke für Ihre Nachricht.
Am Montag, 27. Oktober 2014 um 14:47 schrieben Sie.
Ihre Nachricht finden Sie am Ende dieser eMail.

> Am 27.10.2014 14:20, schrieb Anando Eger:
>>
>> ...
>> Könnte die Ursache darin liegen, dass die internen Index-Routinen
>> einfach nicht lange genug warten bzw. bei Zugriffskonflikten einfach
>> "aufgeben"?

mein senf dazu:

ich hatte neulich einen erstaunlichen fehler:
in eine datenbank mit 1,7 Mill datensätze habe ich meine 
updates reingekloppt. ohne rücksicht auf verluste: mit th.berger's 
update.job. das klappte auch ganz prima: mit den parametern -L und 
-F0/0 übrigens. 
PLÖTZLICH: datensatz 17112323 ist gesperrt. huch?!
keiner war in der datenbank! also a99 geöffnet, den datensatz gesucht, 
gefunden, und übers adminmenü (irgendwo bei "?") entsperrt. 
ok. das ganz lief störungsfrei durch!
nie VORHER Und NACHHER sowas gesehen.

kann es sein, daß die ursache HIER zu suchen ist: extrem schnelle 
hardware: das %temp%-laufwerk liegt auf einer SSD, die datenbank AUCH! 
also ca 10x schneller als normale (AHCI-)festplatten. obwohl ich eher 
auf SAS fahre, als auf den normalen....

natürlich wäre es schön, daß dieser fehler NIE wieder vorkommt. es 
erfordert ja ein "händisches" eingreifen....


allerdings:  vor 2 monaten, als ich mit den verarbeitungsroutinen 
anfing, war ich bei 6-8 stunden pro "wochenlauf". jetzt liege ich bei 
11 minuten (protz) ;-)    
der preis für den speed ist dann wohl die potientielle/mögliche 
fehlermeldung....


grüße aus dem osten
ihr klaus lehmann




-- 
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. Only with allegro. Yes we do. Always with allegro.
* Internetkataloge & WebHosting für Allegro-C & Web 2.0 with VuFind
* 2011: Sponsor der Peter-Sodann-Bibliothek (Staucha)
* 2012: mit allegro-utf8 V3 und allegro-vufind auf der IFLA in Helsinki
* 2013: allegronet ist ein eingetragenes Warenzeichen





Am Montag, 27. Oktober 2014 um 14:47 schrieben Sie:
> Am 27.10.2014 14:20, schrieb Anando Eger:
>>
>> es gibt Fehlerberichte "aus dem Felde", dass manchmal, scheinbar
>> unmotiviert, vorhandene Datensätze nicht gefunden werden. Wiederholt
>> man die Suche oder die den Fehler meldende Funktion, scheint wieder
>> alles in Ordnung.
>>
>> ...
>> Könnte die Ursache darin liegen, dass die internen Index-Routinen
>> einfach nicht lange genug warten bzw. bei Zugriffskonflikten einfach
>> "aufgeben"?
>>
> In etwa. Es wird intern beim Weiterschreiten im Index von einem Eintrag
> zum nächsten eine schnellere Einzelplatzvariante angewandt, nachdem der
> Einstieg erst einmal gefunden ist. Das war wohl lange oder meistens
> unkritisch, aber mit höherer Belastung der Betriebssysteme und der
> Netze - wie es wohl allgemein der Fall ist - kann man das inzwischen
> sicher nicht mehr so lax sehen.

>>
>> Was meinen Sie? Ließen sich intern evtl. längere Wartezeiten
>> und/oder Zugriffswiederholungen bei Zugriffskonflikten realisieren?
>>
> Da besteht eine Chance, denke ich. Werden wir zeitnah prüfen.
> Konkret könnte nach dem Scheitern der besagten Einzelplatz-Routine
> nochmal zusätzlich die aufwendigere Mehrplatzroutine zur Anwendung 
> kommen. Hätten wir, wenn's so ist, natürlich längst machen sollen.
> Aber setzt man generell nur die Mehrplatz-Routine ein, wird's insgesamt
> signifikant langsamer, deshalb hatten wir ursprünglich zu der saloppen
> Methodik gegriffen. Mittlerweile kann's aber auch sein, daß diese
> Signifikanz im *Normalfall* gar nicht mehr so spürbar wäre wie es
> dazumal war.
> So jedenfalls meine spontanen Erinnernisse - ich muß der Sache erst mal
> genauer auf den Grund gehen.
> B.E.


> _______________________________________________
> Allegro mailing list
> Allegro at biblio.tu-bs.de
> http://sunny5.biblio.etc.tu-bs.de/mailman/listinfo/allegro