Hallo,
das Problem sieht folgendermaßen aus:
Ich hatte rund 2,7 Millionen Einträge in der Datenbank. Danach habe ich alle nicht benötigten Angebote daraus gelöscht. Das waren rund 1 Million.
Zuvor ließ sich die DB immer von 2 GB auf rund 1,1 bis 1,2 GB komprimieren.
Jetzt mit 1 Million weniger Einträgen lässt sie sich aber von 2 GB auf rund 1,8 GB komprimieren.
Zusätzlich wächst die Datenbank jedes Mal beim Abgleich rasant an.
Nach nur gut 5.000 Abfragen ist sie wieder bei 2 GB.
Woran liegt das und wie kann man das Problem beheben?
Ich habe bereits die Artikeltabelle in einen DB kopiert, das hat nichts gebracht.
Vielen Dank für eine prompte Antwort.
Beste Grüße,
Martin
Datenbank lässt sich nicht komprimieren und wächst schnell
-
abfrager2010
- Beiträge: 2
- Registriert: 15.04.2010, 19:31
Hallo Martin!
Der "Verwaltungsaufwand", und damit auch der interne Speicherplatzbedarf ist bei vielen Datensätzen enorm hoch so dass die DB bei nur wenigen zusätzlichen Abfragen (wie bei Dir) schon wieder ans Limit kommt.
Dies DB-Verhalten ist eigentlich "normal" (obwohl nicht schön)!
Evt. läßt sich noch etwas mehr freier Speicher gewinnen, wenn man reparieren/komprimieren direkt mit Access ausführt!
Prinzipielle Abhilfe: noch mehr abspecken oder SQL-DB (Enterprise)
Der "Verwaltungsaufwand", und damit auch der interne Speicherplatzbedarf ist bei vielen Datensätzen enorm hoch so dass die DB bei nur wenigen zusätzlichen Abfragen (wie bei Dir) schon wieder ans Limit kommt.
Dies DB-Verhalten ist eigentlich "normal" (obwohl nicht schön)!
Evt. läßt sich noch etwas mehr freier Speicher gewinnen, wenn man reparieren/komprimieren direkt mit Access ausführt!
Prinzipielle Abhilfe: noch mehr abspecken oder SQL-DB (Enterprise)
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
-
abfrager2010
- Beiträge: 2
- Registriert: 15.04.2010, 19:31
Hallo Tim,
das ist klar, dass der Aufwand immer mehr zunimmt.
Aber es ist schon sehr seltsam, wenn ich die DB mit mehr Inhalt auf 1,1 GB komprimieren kann und mit nicht eubmal 2/3 des Inhalts tut sich fast nichts bei der Komprimierung. Es wird jedes Mal deutlich weniger. Heute ging die Komprimierung nur noch auf 1,99 GB. Also Resultat gleich null. Bei gleicher Datensatzzahl waren es vorher weit unter 1 GB.
Die direkte Ausführung in Access habe ich auch schon gemacht, hat nichts gebracht. Es scheint, als würde etwas die Komprimierung der DB blockieren.
Zur Not müsste ich eine neue DB machen, was aber wenig Sinn macht, dann kann man ja bei allen Auswertungen immer erst die Daten zusammenfügen.
Beste Grüße,
Martin
das ist klar, dass der Aufwand immer mehr zunimmt.
Aber es ist schon sehr seltsam, wenn ich die DB mit mehr Inhalt auf 1,1 GB komprimieren kann und mit nicht eubmal 2/3 des Inhalts tut sich fast nichts bei der Komprimierung. Es wird jedes Mal deutlich weniger. Heute ging die Komprimierung nur noch auf 1,99 GB. Also Resultat gleich null. Bei gleicher Datensatzzahl waren es vorher weit unter 1 GB.
Die direkte Ausführung in Access habe ich auch schon gemacht, hat nichts gebracht. Es scheint, als würde etwas die Komprimierung der DB blockieren.
Zur Not müsste ich eine neue DB machen, was aber wenig Sinn macht, dann kann man ja bei allen Auswertungen immer erst die Daten zusammenfügen.
Beste Grüße,
Martin
Hallo Martin!
Dieses Datenbankverhalten ist mir auch schon immer aufgestoßen. Es kommt noch etwas dazu. Wenn die DB über BayWotch angesprochen wird, scheinen die internen Access-Sicherheitsmechanismen nicht 100% zu greifen. Es ist somit möglich, die DB zu "überfüllen", d.h., man kann mehr Datensätze unterbringen als es direkt unter Access möglich wäre. Access macht beim Erreichen des Limits dicht, scheint aber andere Zugriffsarten nicht zu behindern. Insofern ist eine DB am Rande des Limits immer gefährdet (Sicherungskopien sollten reichlich gemacht werden), denn eine überfüllte DB kann man auch direkt unter Access nicht mehr zu Leben erwecken (alles schon durchprobiert).
Welche Größe wird den unter
C:\Dokumente und Einstellungen\[USER-NAME]\Anwendungsdaten\BayWotch4 angezeigt?
Heute geht das nicht mehr, da die verschiedenen Tabellen einer DB über frisch generierte und somit zufälligen IDs miteinander verknüpft sind ... und das kann nur innerhalb eines geschlossenen Systems funktionieren.
Beispiel: wird in der einen Datenbank für einen bestimmten Verkäufer die ID = xxx generiert kann der gleiche Verkäufer in einer anderen BayWotch-Installation die ID= yyy bekommen.
Dieses Datenbankverhalten ist mir auch schon immer aufgestoßen. Es kommt noch etwas dazu. Wenn die DB über BayWotch angesprochen wird, scheinen die internen Access-Sicherheitsmechanismen nicht 100% zu greifen. Es ist somit möglich, die DB zu "überfüllen", d.h., man kann mehr Datensätze unterbringen als es direkt unter Access möglich wäre. Access macht beim Erreichen des Limits dicht, scheint aber andere Zugriffsarten nicht zu behindern. Insofern ist eine DB am Rande des Limits immer gefährdet (Sicherungskopien sollten reichlich gemacht werden), denn eine überfüllte DB kann man auch direkt unter Access nicht mehr zu Leben erwecken (alles schon durchprobiert).
Welche Größe wird den unter
C:\Dokumente und Einstellungen\[USER-NAME]\Anwendungsdaten\BayWotch4 angezeigt?
Man konnte früher (Vers. 2 von BW) mit einer UNION-Abfrage mehrere Datenbanken (nur Lesezugriff) zu einer virtuellen DB zusammen fassen. D.h. man konnte alte Daten in mehrere Datenbanken auslagern und diese wieder zusammenfügen und an BayWotch zurück geben. Abfragen dauerten aber recht lange und man mußte, wenn man mit BW arbeiten wollte, die "normale" DB wieder einrichten. Das ging aber mit einer zweiten Installation von BayWotch recht gut.Zur Not müsste ich eine neue DB machen, was aber wenig Sinn macht, dann kann man ja bei allen Auswertungen immer erst die Daten zusammenfügen.
Heute geht das nicht mehr, da die verschiedenen Tabellen einer DB über frisch generierte und somit zufälligen IDs miteinander verknüpft sind ... und das kann nur innerhalb eines geschlossenen Systems funktionieren.
Beispiel: wird in der einen Datenbank für einen bestimmten Verkäufer die ID = xxx generiert kann der gleiche Verkäufer in einer anderen BayWotch-Installation die ID= yyy bekommen.
Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Nachtrag:
Was mir noch eingefallen ist: man könnte BayWotch mehrfach installieren:
BayWotch 01
BayWotch 02
BayWotch 03
usw.
Da man den Pfad und und auch den Ort der Datenbank während der Installation einstellen kann, würden alle Instanzen sauber getrennt sein.
Mit BW 01 könnte man Fahrräder, mit BW 02 Motorräder und mit BW 03 Autos beobachten. Wenn man also mehrere Beobachtungsfelder, die miteinander nichts zu tun haben, bearbeiten möchte, wäre dies auch ein gangbarer Weg, durch Datenaufteilung kleinere Datenbanken zu haben (zumindestens erstmal!
)
Was mir noch eingefallen ist: man könnte BayWotch mehrfach installieren:
BayWotch 01
BayWotch 02
BayWotch 03
usw.
Da man den Pfad und und auch den Ort der Datenbank während der Installation einstellen kann, würden alle Instanzen sauber getrennt sein.
Mit BW 01 könnte man Fahrräder, mit BW 02 Motorräder und mit BW 03 Autos beobachten. Wenn man also mehrere Beobachtungsfelder, die miteinander nichts zu tun haben, bearbeiten möchte, wäre dies auch ein gangbarer Weg, durch Datenaufteilung kleinere Datenbanken zu haben (zumindestens erstmal!
)Gruß
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)
Tim
__________________________
XP Pro; SP3 (werde ohne Not auch nicht wechseln !!)