Hallo zusammen,
da ich über die Suche zu diesem Thema leider nichts finden konnte, bitte ich mit diesem Beitrag um eure Hilfe.
Problem ist, dass unsere Datenbank (jetzt accdb, vorher aber auch bei mdb) in ziemlich regelmäßigen Abständen von ca. 6-8 Wochen massive Probleme bekommt.
Das macht sich in sofern bemerkbar, dass man entweder schon beim direkten öffnen der DB(Backend) eine Fehlermeldung erhält, dass die Datenbank inkonsistent sei und repariert werden muss. Was zum Glück bisher auch immer noch möglich war. Manchmal lässt sie sich aber auch noch ganz normal öffnen.
Was jedoch immer gleich ist, dass bei mindestens einer Tabelle (natürlich der größten in Bezug auf Datensätze) der Primärschlüssel und damit auch alle Beziehungen nicht mehr vorhanden sind.
Dabei gibt es immer mindestens ein Datensatz wo alle Felder mit #### gefüllt sind.
Bisher ließen sie sich ohne Probleme löschen und alles reparieren, was aber mit einem erheblichen Aufwand verbunden ist. Der Vorgang dauert jedes mal mehrere Stunden, vom erkennen bis zur vollständigen Wiederherstellung.
Natürlich gibt es im PK-Feld dann auch immer doppelte Einträge.
Die Anwendung (Frontend) und damit auch die DB (Backend, nur Tabellen) wird von meist 5-10 Usern genutzt und hat nach der Komprimierung rund 120MB.
Die betroffene Tabelle, manchmal sind es auch mehrere, umfasst mehr als 100.000 Datensätze bei rund 70 Spalten.
Die Datenbank wird auch immer mindestens einmal die Woche komprimiert.
Hat jemand von euch dazu irgendwelche Lösungsvorschläge oder sonstige Erfahrungswerte?
Wie lässt sich das verhindern? (außer auf einen SQL-Server ausweichen, das wäre ein Zeitaufwand von ungefähr einem Jahr, von dem zusätzlichen administrativen und finanziellem Aufwand ganz abgesehen)
Gruß Dieter
Hallo,
hat jeder User sein eigenes Frontend, oder liegt das auch zentral auf dem Server ?
In einer Mehrbenutzerumgebung benötigt jeder User unbedingt sein eigenes Frontend auf seinem PC. Sonst läuft Access nicht stabil.
es hat jeder User sein eigenes Frontend, was auch bei jedem Start zuerst vom Server auf den lokalen Rechner kopiert wird.
Hallo Dieter,
Hast du schon durch dieses "gekämpft"?
http://www.donkarl.com?FAQ1.23 (http://www.donkarl.com?FAQ1.23)
http://www.donkarl.com?FAQ1.27 (http://www.donkarl.com?FAQ1.27)
gruss ekkehard
Hallo ekkehard,
Danke erstmal für die schnelle Antwort, auch an Klaus.
Bei den beiden Links handelt es sich ja ausschließlich um Reparaturmaßnahmen einer defekten DB.
Das ist "zum Glück" ja gar nicht mein Problem. Reparieren war bisher immer mit Bordmitteln möglich.
Ich versuche einen Weg zu finden das zu verhindern, sofern es einen gibt.
Ich suche nach möglichen Ursachen.
Oder ist die DB einfach zu groß?
Ist Access an seine Grenzen gestoßen?
Die DB läuft noch in einigen anderen Umgebungen, meist deutlich unter 100MB, dort gibt es keine Probleme.
Hallo Dieter,
ZitatIch suche nach möglichen Ursachen.
O.K.
Regelmäsiges Komprimieren des BE können wir voraussetzen?
ZitatOder ist die DB einfach zu groß?
Ist Access an seine Grenzen gestoßen?
2 GByte ist IMO immer noch die Grenze.
Falls ihr da schon angekommen seid könnte man die Möglichkeiten eruieren, das BE
aufzuteilen. Der von den Profis aber wohl eher vorgeschlagene Schritt wird die Nutzung
eines SQL-Servers sein.
gruss ekkehard
komprimiert wird mindestens einmal die Woche. Empfohlen habe ich täglich, aber da die betreffenden Personen nicht jeden Tag so früh sind, läuft es Erfahrungsgemäß auf 2-3mal die woche raus.
Von 2GB sind wir noch weit entfernt. Bei der einen DB habe ich vor kurzem teile einiger Tabellen archiviert, da sie schon bei 330MB angekommen ist, was sich bei der Performance im Front-End schon ziemlich bemerkbar gemacht hat. Nach der Archivierung lag sie bei 150MB und damit das FE wieder spürbar flüssiger.
Die Netzwerkperformance lässt da sehr zu wünschen übrig, meiner Meinung nach.
Kopiert man einfach die DB via copy paste, dann dauert das alleine schon mehr als 10 Sekunden, für 330MB, was rein rechnerisch und im Kopierdialog auch sichtbar, auf 20-25MB/s rauskommt, zu manchen Zeiten auch gerne weniger.
Eindeutig zu wenig, wie ich finde, um flüssig zu arbeiten. Oder erwarte ich da zuviel?
Sorry, dann sind meine bescheidenen Kenntnisse leider schon am Ende :'(
Hallo,
hier sind noch 2 interessante Links zum Thema (in Englisch):
http://allenbrowne.com/ser-47.html
http://allenbrowne.com/ser-25.html
Weitere Fragen, die mir so in den Sinn kommen:
Kannst du sicherstellen, dass die Client-PCs immer richtig runtergefahren werden oder werden sie manchmal einfach nur ausgeschaltet?
Vielleicht entwickelst du einen Mini-Log, in dem nur vermerkt wird, wer sich wann angemeldet und abgemeldet hat. Mit einer geschickten Abfrage ließe sich dann ermitteln, wie häufig logon ohne logoff erfolgte. Diese Information wäre nach einem Crash vielleicht hilfreich.
Hast du schon mal bei den Nutzern nachgefragt, ob sie sich mehrfach pro Tag anmelden müssen, obwohl der PC durchläuft? Das würde für Netzwerk-Probleme sprechen.
All das ist nur interessant, wenn die Unterbrechung genau während eines Schreibvorgangs erfolgt. Ist es möglich, dass solche Schreibvorgänge mal etwas länger dauern (z.B. wegen starker Netzbelastung oder weil der Umfang der zu speichernden Daten recht groß ist), so dass der Nutzer die Gelegenheit hat, den PC mittendrin auszuschalten?
Erhält der Nutzer eine Info "Erfolgreich gespeichert"?
Erfolgen die Crashs gehäuft zu bestimmten Uhrzeiten (Schichtwechsel, Feierabend)?
Gibt es auch bei anderen serverbasierten Anwendungen gelegentlich Probleme?
Überladen/überlasten Nutzer ihre PCs mit zu vielen offenen Anwendungen, zwischen denen sie bei Bedarf hin und her schalten?
Unerklärlich ist mir, wieso ### in allen Feldern des kaputten Records erscheint. Diese Frage können wohl nur MS-Mitarbeiter beantworten, die über den Access-Sourcecode verfügen... Oder stehen in den Feldern andere Daten, die nur nicht dargestellt werden können? Hast du schon mal probiert, einen solchen Record (nach Eingabe eines gültigen Wertes in einer - indizierten - Spalte) mit einer Abfrage zu suchen und auszugeben oder zu exportieren?
All das als Anregungen zur Ursachensuche. Viel Erfolg!
lg
crystal
Nachtrag:
Wer verwaltet den Server? Werden zu bestimmten Zeitpunkten Backups ausgeführt und dazu Schreibzugriffe temporär unterbunden? Könnte interessant sein, da das Backend ja nur eine Datei ist und keine Applikation und daher auf einem reinen Fileserver liegen wird. Wenn dann der Server-Admin ignoriert, dass noch User verbunden sind (muss er ja quasi, weil es immer Kollegen gibt, die sich nicht abmelden, könnte es auch knallen... Frag doch mal nach, wie eure IT-Abteilung ("Rechenzentrum") mit deinem Backend, dem entspr. Speichermedium und ggf. dem zugehörigen Server umgeht. Und frage auch, ob es vielleicht Network-Traffic-Limits gibt.
Hallo crystal,
Danke für die zahlreichen Anregungen und Tipps.
Das mit dem Mini-Log ist mir auch schon in den Sinn gekommen und das werde ich auch tun.
Auch werde ich dafür sorgen, dass sich das Front-End spätestens um 23Uhr selbst beendet, für all diejenigen die ein beenden nicht für nötig halten oder schlicht vergessen.
Vom ein oder anderen User bekam ich schon die Rückmeldung, dass es nicht nur mit dieser DB Probleme gab, was auf störungen im Netzwerk schließen lässt. Beim letzten Crash war bei einer Außenstelle die Telefonanlage kaputt. Nur wenn der Admin das als Ursache abstreitet... ::)
Die Sache mit den # in den Feldern ist wirklich merkwürdig. Ich programmier jetzt schon fast 20 Jahre mit Access, aber das war mir bis dato noch nicht unter gekommen, ebenso wenig, dass sich der Primärschlüssel verabschiedet. Es stehen in jedem Feld unzählige #, selbst in potenziell leeren Feldern, aber nicht weil das Feld etwa zu klein eingestellt ist. Das verhalten ist mir bekannt.
Mit dem Systemadmin bin ich schon in Kontakt, aber zu dem "Fehler" der vor dem PC sitzt, kann er mir auch nur wenig sagen. ;)
Das Backup läuft meines wissens immer Nachts, da aber bisher noch keine Rücksicherung statt gefunden hat, kann das auch nicht die Ursache sein. Die eigentlich genutzte Datei bleibt dabei ja unberührt.
Was meinst du genau mit Network-Traffic-Limits? was genau lässt sich da ggf. einschränken?
Gruß Dieter
Hallo Dieter,
Danke für deine Rückmeldung. Deine Frage
ZitatWas meinst du genau mit Network-Traffic-Limits? was genau lässt sich da ggf. einschränken?
Läßt sich durchaus so beantworten: alles.
Öffentlich wird zur Zeit z.B. "Free Internet" gefordert, weil es von Anbietern Bestrebungen gibt, gewisse Internet-Dienste bevorzugt zu bedienen - die anderen müssen sich dann z.B. mit geringerer Geschwindigkeit begnügen oder sie können gegen Bezahlung bessere Leistung bekommen.
In einem modernen Netzwerk werden managable switches eingesetzt. Damit ist es z.B. möglich, einzelne ports, also indirekt die Geräte, die da jeweils dranhängen (PCs, Drucker usw.) mit unterschiedlichen Prioritäten zu versehen. Es gibt viele weitere Möglichkeiten, es ist kaum möglich, die hier aufzuführen.
Man kennt das noch von früheren T-Online-Routern: der Media-Receiver musste an Port 1 angeschlossen werden, weil der priorisiert wurde, um flüssige Fernsehbilder zu ermöglichen.
Moderne professionelle Switches (z.B. von Cisco) können z.B. inaktive Ports in der Prio automatisch runtersetzen. Wenn dann wieder eine Aktivität erfolgt, muss die sich in der Prio erstmal wieder hochhangeln, was eben ein paar Momente dauert.
Weiter ist es möglich, einzelnen Ports eine gewissen QoS (Quality of Service) zuzuordnen, d.h. quasi, bestimmte Antwortzeiten sicherzustellen, oder zu garantieren, das größere Datenmengen 'verzögerungsfrei' transportiert werden. Andere müssen dann eben warten.
Ich denke, du musst dich da tatsächlich mit den Rechenzentrum-Spezis zusammensetzen; sie sollten über Möglichkeiten verfügen, den Netzwerk-Verkehr zu analysieren.
Vielleicht hilft es schon, das Backend auf einen "abteilungsnahen" Server zu verlagern, so dass alle Anwender relativ kurzen Zugriff haben (einfach von der Kabellänge her betrachtet). Vorteilhaft wäre auch, wenn alle Anwender und der Server am gleichen switch hängen würden.
Ansonsten bliebe nur, für dein Backend auch eine gewisse QoS einzufordern oder es z.B. auf einen PC innerhalb der Abteilung zu verlagern.
Noch ein Beispiel, das die Problematik verdeutlichen soll.
An einem 24-Port-Switch, der eine Bandbreite von 100MBit/s leisten kann, hängen 24 PCs. Würden nun alle das Fußball-Finale anschauen, würde sich die Bandbreite auf 100/24, also ca. 4MBit/s verringen (vereinfachte Rechnung). Da würde das Bild schon etwas ruckeln, besonders dann, wenn z.B. der PC des Chefs eine QoS-Vereinbaung über 20MBit/s hat...
All dies soll dir nur zeigen, dass es eine schwierige Aufgabe ist, ein Firmen-Netzwerk zu managen und es dabei möglichst allen zu jedem Zeitpunkt recht zu machen. Die Admins haben es nicht leicht und so kann ich dir nur empfehlen, positiv und motivierend auf sie zu zu gehen, vielleicht sogar mit dem Ausdruck der Verzeiflung, damit es ihnen leichter fällt, dir zu helfen.
lg
crystal
Hallo crystal,
Da werde ich mich wohl oder übel wenigstens soweit in die Materie einarbeiten, auch wenn es eigentlich nicht mein Job ist, dass ich mit denen reden kann, ohne dass sie mir sonst was erzählen.
Danke erstmal für die ausführliche Antwort.
Dann wäre erst mal nur noch die Frage nach den mit ##### gefüllten Zeilen.
Falls das jemand schon mal gesehen hat und eine Ursache oder gar Lösung kennt, bin ich für jeden Tipp dankbar.