PDA

Vollständige Version anzeigen : Datenbank explodiert!?


BaEck
05.11.2001, 19:04
Hallo,

ich habe eine Datenbank zur Mietvertragsverwaltung gebaut (Access97, WIN98), die an sich gut funktioniert. Es gibt ca. 30 Nutzer, vor einer Woche waren 400 Datensätze erfaßt, die DB hatte ca. 25 MB. Heute sind 440 Datensätze erfaßt, die DB ist aber 77 MB!! groß.

Diese "Explosion" gab es schon einmal, ich habe sie dann komprimiert, ...

Was kann denn die Ursache sein?

Barbara

Bernd Koch
05.11.2001, 21:34
Das Problem ist für Acc97 (soweit ich weiß auch für Acc95) bekannt, die Ursache nicht.
Scheint ein bug inAccess zu sein.

Bezeichnenderweise kann man ja ab Acc2000 einstellen, dass bei jedem Schließen der DB automatisch komprimiert wird.

Vergleiche auch FAQ 1.22, vielleicht hilft einer der dortigen Tipps.

www.donkarl.com (http://www.donkarl.com)


Bernd

ceki
06.11.2001, 08:51
"It´s not a bug, it´s a feature!" würde Microsoft jetzt sagen.
Fakt ist, daß sämtliche Berechnungen, Aktionen, kurz, alles was ACCESS macht Speicherplatz benötigt.
Leider aber wird dieser Speicherplatz nach den Aktionen (z.B. auch Abfragen) zwar geleert, aber nicht mehr freigegeben.
Dadurch erhöht sich die Dateigröße natürlich ständig.
D.h. je mehr Abfragen, usw. Deine DB enthält, umso stärker ist das "Wachstum".
Du hast jetzt zwei Möglichkeiten dem entgegenzuwirken.

1.) Versuche Deine Abfragen so weit wie möglich in VBA unterzubringen.
2.) regelmäßige Komprimierung

Wobei das mit der Komprimierung in einer Mehrbenutzerumgebung natürlich ein großes Problem ist.

Ich hab das in meinem Fall damals so gelöst, daß ich die DB in ein Front- und ein Backend getrennt hat.
Im Backend waren alle Datensätze gespeichert und die Berechnungen, Abfragen, usw. wurden im Frontend durchgeführt.
Danach hab ich eine neue DB angelegt, die beim Starten ein Formular öffnet, das wiederum die gewünschte DB (Frontend) öffnet.
Damit kann ich von Zeit zu Zeit eine Kopie der Frontend ziehen, diese komprimieren und die Start-DB auf die neue, komprimierte DB "umrouten".
Jeder Benutzer, der danach die DB über die Start-DB öffnet kommt automatisch auf die komprimierte DB, ohne daß er das merkt.
Die alte, große DB, kannst dann spätestens am nächsten Arbeitstag löschen.

Ist zwar nicht sehr elegant, aber der einzige Weg, der mir dafür eingefallen ist, weil wennst die DB komprimieren möchtest, müssen alle User ausgestiegen sein.

Aber vielleicht hat jemand eine besser Idee?

Gruß
Karl

Bernd Koch
06.11.2001, 10:27
@ Karl,

vielleicht habe ich deinen Text ja nur falsch verstanden aber komprimierst du wirklich das/die frontend(s)?

Was sollte das bringen? Die Daten werden physikalisch ausschließlich in den Tabellen abgespeichert (also im backend) und nur dort bläht sich die DB auch auf. Alle Berechnungen, Abfragen usw. greifen von den frontends auf das backend zu - nur dort wird was mit den Daten angestellt. Somit muss auch nur das backend regelmäßig komprimiert werden.

Du erwähnst die Abfragen. Es ist eigentlich nicht wesentlich, wie viele Abfragen ich (im frontend) habe, sondern höchstens, wie oft ich Abfragen benutze (weil damit, wie du richtig schreibst, Speicherplatz - auf dem server/backend - genutzt aber nicht mehr frei gegeben wird). Die einzelne Abfrage selbst besteht ja nur aus dem bisschen SQL-Code und da ist es - speicherplatzmäßig - egal, ob der so bleibt wie er ist oder ob ich ihn aus VBA heraus aufrufe. Es kann andere Gründe für VBA geben aber für das Verhindern des Aufblähens hat das wohl keine Auswirkungen.

Das grundsätzliche Problem für Mehrbenutzerumgebungen bleibt aber natürlich so, wie du es beschreibst: alle Nutzer müssen draußen sein, ehe ich das backend komprimieren kann.

Bernd


P.S.
Es dauert jetzt schon fast eine halbe Stunde und ich konnte die Antwort immer noch nicht abschicken. Wird Zeit, dass Günther auf einen vernünftigen Server umzieht.

Bernd Koch
06.11.2001, 10:29
... dafür ist sie dann gleich zweimal erschienen ...



[Dieser Beitrag wurde von Bernd Koch am 06.11.2001 editiert.]

Sascha Trowitzsch
06.11.2001, 11:11
Mich würde nur eins interessieren:

Wieso ist eine DB mit gerade mal 400 DS 25 MB groß??
In eine solche Datei kriege ich fast das gesamte Berliner Telefonbuch. (1,3 Mio DS)

Speicherst du etwa die Mietverträge als Scans, also als Bitmaps in der DB ab?
Das wäre keine so gute Idee.

Fragt sich Sascha.

ceki
06.11.2001, 12:19
@Bernd

Bin zwar kein Profi, aber bei mir laufen die Abfragen, Berechnungen, etc. schon alle im Frontend ab und damit bläht sich auch das Frontend auf.

Du könntest ja theoretisch auch eine .txt-Datei für die Datenherkunft verknüpfen und die Berechnungen in der DB ausführen. Dann bläht sich ja auch nicht die txt auf.

Die Anzahl der DS sind ja nicht das Problem. 400 sollten kaum merkbar sein.

Mein Backend läuft schon ca. 2 Monate ohne komprimieren und ich bin grad mal um ein paar hundert (2 oder 3) kb gestiegen, obwohl die DS-Zahl mittlerweile bei ca. 3500 liegt.
Also dürfte das Backend relativ unangetastet bleiben.

Bei mir explodierte eigentlich immer nur das FE, und das auch nur, weil ich ein Endlosformular habe, das alle 2sek. eine Aktualisierung durchführt.

Ich hatte damals auch relativ viele Abfragen, die ich dann aber bald mit VBA-Codes in den Formularen selbst untergebracht hab. Wie Du richtig gemeint hast, spielt es keine Rolle, ob Du eine Abfrage oder das gleiche in VBA hast.
Nur hab ich für Vorgänge, die ich jetzt mit ein bisschen VBA ausführen kann, damals einige Abfragen, die ALLE immer wieder ausgeführt werden mußten, benötigt.
Von daher ist mir die VBA-Variante lieber.
Kurz, je weniger Access machen muß, umso weniger stark bläht sich die DB auf.

Und für die "alle User raus"-Variante hab ich bis jetzt noch keinen besseren Weg gefunden, weil "rauskicken" wollte ich sie nicht. (obwohl ich die Möglichkeit auch integriert hab - sicher ist sicher! *ggg*)

Die 25MB haben mich auch etwas irritiert. Deshalb glaube ich, daß eine Menge Aktionen und Abfragen, etc. in dieser DB stecken.
Die DS alleine können es wirklich nur schwer sein.

Kannst Du uns dazu noch mehr Infos geben, Barbara?

Gruß
Karl

BaEck
06.11.2001, 22:20
Erst einmal danke für die vielen Antworten und Vorschläge.

Ja, meine DB ist riesig: Bei dem Hinweis auf viele Abfragen könnte ich sofort zustimmen: die DB hat 16 Tabellen, 60 Abfragen, 40 Formulare .. und ich habe keine Leichen mehr drin ..

Leider ist dieser Umfang auch erforderlich, da nicht nur die Mietverträge, sondern auch die dazugehörigen Zahlungen sowie das Tracing und Tracking behandelt wird.

Barbara

BaEck
06.11.2001, 22:22
Ich habe einen Tip schon befolgt und sämtliche Objekte in eine neue, leere DB importiert, die jetzt mit 460 Datensätzen 6,2 MB hat - das klingt doch schon besser!!

Barbara

Sascha Trowitzsch
07.11.2001, 01:02
@ Ceki:
Ich glaube doch, du unterliegst einem Irrtum mit der Vorstellung, alles was Access anstelle, verbrate Speicher, der nicht mehr zurückgegeben werde.

Zunächst mal ist da der Unterschied zwischen Platte und RAM. Die Aktionen laufen im RAM ab und der wird mal vergrößert, mal verkleinert und jedenfalls ordnungsgemäß zurückgegeben. Du kannst ja mal einen Speichermonitor laufen lassen.
Das Geschehen im RAM hat keinen direkten Bezug zum Platzbedarf der DB im File. Das Ausführen eine Auswahlabfrage z.B. ändert überhaupt nichts an der Größe der DB, genausowenig wie Ausführen von VBA-Code.
Anders verhält es sich bei Aktionsabfragen.
Grundsätzlich ändert sich die Größe der DB, wenn Datensätze verändert werden und vor allem, wenn temporäre Objekte angelegt und wieder gelöscht werden. Genau das ist es auch, was die meisten DBs aufbläht und sollte vermieden werden.

@ BaEck:
Ich fürchte, dass die 6,2MB nur eine vorübergehende Größe bleiben werden. Wenn die DB vorher so stark angewachsen ist, dann wird sie das nun wieder tun. Du solltest die DB auf so Geschichten wie Aktionsabfragen und temporäre Objekte überprüfen und dafür nach anderen Lösungen suchen.
Vielleicht liegt es auch am Tabellendesign und den Felddefinitionen. Mit falschen Textfeldern kann man ziemlich viel unnötigen Platz verschwenden.

Was die Einschätzung "groß" angeht (nur so als Richtgröße):
Bin im Moment an einer DB mit 70 Tabellen, 300 Abfragen, 50 Formularen, 25 Berichten, ca. 3000 Zeilen VBA. Die drei Haupttabellen haben beim Kunden im Moment jeweils etwa 3000 DS.
Das FE ist 3,3 MB groß, das BE 1,8 MB.

Ciao, Sascha

ziege
07.11.2001, 06:14
Hallo,

für das komprimieren und sichern der alten DB gibt es hier ein Tool (AP Service Manager): http://www.access-paradies.de/

Ich habe das Teil mal von einer Firma testen lassen die uns eine "riesige" DB verkauft hat. Die Entwickler haben mir schriftlich bestätigt. "Geprüft und für gut befunden."

Bislang habe ich das Teil trotzdem nicht regelmäßig im Einsatz weil ich immer noch "ein ungutes Gefühl" habe, mich beim Sichern von Daten auf ein Windows Programm zu verlassen.

Vieleicht hat ja der eine oder andere Erfahrungen mit solchen Tools.

Gruß

Ziege

ceki
07.11.2001, 09:55
@Sascha:
Richtig, hab ich auch so gemeint, nur ein bisserl zu allgemein ausgedrückt.
Mein Problem war damals, daß ich viel mit Anfüge- und Löschabfragen gearbeitet hab.
Sobald die nicht ausgeführt wurden, wuchs die DB nur minimal (muß doch noch irgendwas anderes auch das Aufblähen bewirken).
Hab dann Wege gefunden, durch die ich diese Anfüge- und Löschabfragen ersetzen konnte (VBA), und siehe da, das Wachstum hielt sich fortan stark in Grenzen.
Hab mich wohl etwas zu global ausgedrückt, sorry.

Gruß
Karl