2010-08-07 9 views
8

Ich habe eine .mdb Datei, die 70 MB ist.So komprimieren Sie eine MS Access-Datenbank

Nach dem Löschen aller Datensätze in der Datei bleibt die Größe 70 MB.

Wie mache ich meine .mdb Datei kleiner?

+0

Einige Änderungen vorgenommen. Hat einen Punt in Megabyte genommen. Es schien die wahrscheinlichste Maßeinheit zu sein. Beeinflusst das Ergebnis der Frage nicht wirklich. – spender

+2

Ich bekomme einfach nicht die Kritik an dieser Frage. Ich ging zu der Quelle für die ursprüngliche Frage, und es war völlig klar, was gefragt wurde, obwohl die Änderungen definitiv ihre Klarheit verbesserten. Es war eine echte Frage von Anfang an. Zweitens sind Fragen zur Wartung von Datenbanken, die nicht explizit mit der Programmierung verbunden sind, auf SO erlaubt, da sie überall auftreten. Daher sehe ich nicht, dass es sich notwendigerweise um eine SuperUser-Frage handelt. Für mich sieht es aus wie eine Grauzone - es wäre eine OK-Frage auch auf SU, aber ich sehe nicht, dass es nicht auf SO gehört. –

Antwort

8

Öffnen Sie die MDB und machen Sie eine "Compact and Repair". Dies wird die Größe der MDB reduzieren.

Sie können die Option "Beim Schließen schließen" auch aktivieren (standardmäßig deaktiviert). Hier

ist ein Link zu einigen zusätzlichen Informationen: http://www.trcb.com/computers-and-technology/data-recovery/ways-to-compact-and-repair-an-access-database-27384.htm

+3

Wie hast du das verstanden ...? – Alexander

+1

Ich hatte das selbe genaue Problem vor 10 Jahren ... ich denke, das waren meine genauen Worte ... ;-) –

+1

wie man komprimiert und repariert –

16

Jede Datenbank-Engine, die jemals existiert hat Bedürfnisse regelmäßige Wartungsarbeiten an ihnen ausführen, um die Datenspeicherung zu optimieren und schlaff Raum zu erholen. In xBase-Tagen haben Sie beispielsweise einen PACK-Befehl ausgeführt, um gelöschte Zeilen zu entfernen. In SQL Server führen Sie Skripts aus, um die eigentlichen Datendateien aus denselben Gründen zu verkleinern.

Warum tut dies jede Datenbank-Engine?

Da wäre es ein enormer Leistungseinbruch, wenn jeder Schreibvorgang in der Datenbank die gesamte Datei in optimierter Reihenfolge neu schreiben müsste. Stellen Sie sich eine Datenbank vor, die jede Datentabelle in einer separaten Datei speichert. Wenn eine Tabelle 10000 Datensätze enthält und Sie den 5000. Datensatz löschen, müssen Sie die gesamte zweite Hälfte der Datendatei neu schreiben, um Speicherplatz zu sparen. Stattdessen verwendet jede Datenbank eine Form der Markierung des verwendeten Speicherplatzes als unbenutzt und als verwerfbar, wenn das nächste Mal die Optimierungsoperationen in der Datentabelle ausgeführt werden.

Jet/ACE ist in dieser Hinsicht nicht anders als jede andere Datenbank-Engine und jede Anwendung, die eine Jet/ACE-Datenbank als Datenspeicher verwendet, sollte regelmäßige Wartungsvorgänge planen, einschließlich einer Sicherung und dann einer Komprimierung.

Es gibt einige Probleme mit diesem Jet/ACE, die in Server-Datenbank-Engines nicht vorhanden sind. Insbesondere können Sie nicht komprimieren, wenn nicht alle Benutzer ihre Verbindungen zur Datendatei geschlossen haben. In einer Serverdatenbank stellen die Benutzer eine Verbindung zum serverseitigen Prozess der Datenbanksteuerkomponente her, und dieser serverseitige Dämon ist der einzige "Benutzer" der eigentlichen Datendateien, in denen die Daten gespeichert sind. Somit kann der Server-Dämon entscheiden, wann die Optimierungs- und Wartungsroutinen ausgeführt werden sollen, da er vollständig kontrolliert, wann die Datendateien verwendet werden oder nicht. Ein häufiges Problem bei Access-Anwendungen ist, dass Benutzer ihre Anwendung auf ihren Computern geöffnet lassen und das Büro für den Tag verlassen, was bedeutet, dass die Datei immer noch geöffnet ist, wenn Sie Ihre kompakte Operation um 2:00 Uhr morgens ausführen und Sie können es nicht ausführen (weil compact die ursprüngliche Datei ersetzt). Die meisten Programmierer von Access-Anwendungen, die auf dieses Problem stoßen, tolerieren das gelegentliche Scheitern dieser Art von Übernacht-Wartung (Volumeschattenkopie ermöglicht weiterhin eine Sicherung der Datei, obwohl es keine Garantie gibt, dass die Sicherungskopie zu 100% intern konsistent ist) oder sie werden ihre Access-Anwendungen so entwickeln, dass sie zu einem Zeitpunkt beendet werden, der für Wartungsarbeiten über Nacht ausreicht. Ich habe beides gemacht.

In Nicht-Access-Anwendungen existiert das gleiche Problem, muss aber anders angegangen werden. Für Webanwendungen ist das ein gewisses Problem, aber im Allgemeinen würde ich sagen, dass jede Webanwendung, die die Daten so aufwühlt, dass eine Komprimierung benötigt wird, eine solche ist, für die ein Jet/ACE-Datenspeicher völlig ungeeignet ist.Jetzt

, zum Thema COMPACT CLOSE:

Es sollte nie von jedermann genutzt werden.

Immer.

Es ist sinnlos und geradezu gefährlich, wenn es tatsächlich in Kicks

Es ist nutzlos, weil es keine ist-richtig architected Produktionsumgebung, in der Benutzer jemals das hintere Ende eröffnen -. Wenn es sich um eine Access-App ist, sollte es sein Teilen, wobei Benutzer nur das Frontend öffnen, und wenn es eine Web-App ist, interagieren Benutzer nicht direkt mit der Datendatei. In beiden Szenarien wird also niemand das COMPACT ON CLOSE auslösen, also haben Sie Ihre Zeit damit verschwendet, es einzuschalten.

Zweitens, auch wenn jemand es gelegentlich auslöst, wird es nur funktionieren, wenn dieser Benutzer der einzige mit der geöffneten Datenbank ist. Wie ich oben sagte, kann es nicht kompaktiert werden, wenn andere Benutzer mit ihm geöffnet sind, so dass dies auch nicht funktionieren wird - COMPACT ON CLOSE kann nur ausgeführt werden, wenn der Benutzer, der es auslöst, exklusiven Zugriff hat.

Aber das Schlimmste von allem, COMPACT ON CLOSE ist gefährlich und wenn es läuft kann zu tatsächlichen Datenverlust führen. Dies liegt daran, dass es bestimmte Zustände gibt, in denen sich eine Jet/ACE-Datenbank befinden kann, in der interne Strukturen außer Kontrolle geraten, die Daten jedoch immer noch zugänglich sind. Wenn der Komprimierungs-/Reparaturvorgang in diesem Zustand ausgeführt wird, können Daten möglicherweise verloren gehen. Dies ist eine extrem seltene Bedingung, aber es ist eine sehr entfernte Möglichkeit.

Der Punkt ist, dass COMPACT ON CLOSE nicht bedingt ist, und es gibt keine Eingabeaufforderung, die Sie fragt, ob Sie es ausführen möchten. Sie haben vor der Ausführung keine Möglichkeit, ein Backup zu erstellen. Wenn Sie es eingeschaltet haben und es sich einschaltet, wenn sich Ihre Datenbank in diesem sehr seltenen Zustand befindet, könnten Sie Daten verlieren, die Sie andernfalls wiederherstellen könnten Sie haben die kompakte Operation nicht ausgeführt.

Kurz gesagt, niemand mit einem Verständnis von Jet/ACE und Verdichtung schaltet sich jemals auf COMPACT ON CLOSE.

Für einen einzelnen Benutzer können Sie nur nach Bedarf komprimieren.

Für eine geteilte Anwendung ist ein geplantes Wartungsscript das Beste, das normalerweise über Nacht auf dem Dateiserver ausgeführt wird. Dieses Skript erstellt eine Sicherungskopie der Datei und führt dann den Komprimierungsjob aus. Es ist ein ziemlich einfaches Skript, das in VBScript geschrieben und leicht geplant werden kann.

Zuletzt, wenn Ihre Anwendung häufig eine große Anzahl von Datensätzen löscht, ist dies in den meisten Fällen ein Hinweis auf einen Konstruktionsfehler. Datensätze, die im normalen Produktionsbetrieb hinzugefügt und gelöscht werden, sind TEMPORARY DATA und gehören nicht logisch und pragmatisch in Ihre Hauptdatei.

Alle meine Produktions-Apps haben eine temporäre Datenbank als Teil der Architektur, und alle temporären Tabellen sind dort gespeichert. Ich mache mir nie die Mühe, die temporären Datenbanken zu komprimieren. Wenn aus irgendeinem Grund die Leistung aufgrund von Blähungen in der temporären Datenbank hängenblieb, würde ich einfach eine leere Kopie der temporären Datenbank über die alte kopieren, da keine der darin enthaltenen Daten etwas anderes als temporär ist. Dies reduziert die Abwanderung und Aufblähung im Front-End oder Back-End und reduziert die Häufigkeit notwendiger Komprimierungen in der Backend-Datendatei erheblich.

Auf die Frage, wie, zu verdichten, gibt es eine Reihe von Optionen:

  1. in der Access-Benutzeroberfläche Sie die aktuell geöffnete Datenbank komprimieren kann (TOOLS | DATABASE UTILITIES).Das erlaubt Ihnen jedoch nicht, eine Sicherungskopie als Teil des Prozesses zu erstellen, und es ist immer eine gute Idee, vor dem Komprimieren eine Sicherungskopie zu erstellen, nur für den Fall, dass etwas schief geht.

  2. In der Access UI können Sie eine Datenbank komprimieren, die nicht geöffnet ist. Dieser komprimiert von einer vorhandenen Datei zu einer neuen Datei. Wenn Sie fertig sind, müssen Sie sowohl die ursprüngliche als auch die neu komprimierte Datei umbenennen (um den neuen Namen zu haben). Der DATEIÖFFNEN-Dialog, der Sie fragt, welche Datei zu komprimieren ist, erlaubt Ihnen, die Datei an diesem Punkt umzubenennen, so dass Sie dies als Teil des manuellen Prozesses tun können.

  3. In Code können Sie die DAO DBEngine.CompactDatabase-Methode verwenden, um die Aufgabe auszuführen. Dies kann von Access VBA oder von einem VBScript aus oder von jeder Umgebung verwendet werden, in der Sie COM verwenden können. Sie sind in Ihrem Code verantwortlich für die Sicherung und Umbenennung von Dateien und so weiter.

  4. eine andere Option im Code ist JRO (Jet & Replikationsobjekte), aber es bietet nichts in Bezug auf kompakte Operationen, die DAO nicht bereits hat. JRO wurde als separate Bibliothek erstellt, um Jet-spezifische Funktionen zu behandeln, die in ADO selbst nicht unterstützt wurden. Wenn Sie ADO als Schnittstelle verwenden, ist JRO die MS-empfohlene Bibliothek für die Komprimierung. In Access ist JRO für compact ungeeignet, da Ihnen die CompactDatabase-Methode bereits zur Verfügung steht, selbst wenn Sie keine DAO-Referenz haben (die DBEngine ist in Access immer verfügbar, unabhängig davon, ob Sie eine DAO-Referenz haben). Mit anderen Worten, DBEngine.CompactDatabase kann in Access ohne eine DAO- oder ADO-Referenz verwendet werden, während die JRO-CompactDatabase-Methode nur mit einer JRO-Referenz verfügbar ist (oder eine späte Bindung verwendet). Außerhalb von Access kann JRO die geeignete Bibliothek sein.

Lassen Sie mich betonen, wie wichtig Backups sind. Sie werden es nicht 999 von 1000 (oder noch seltener) brauchen, aber wenn Sie es brauchen, werden Sie es schlecht brauchen! Also niemals komprimieren, ohne vorher ein Backup zu machen.

Schließlich ist es nach jeder Komprimierung eine gute Idee, die komprimierte Datei zu überprüfen, um zu sehen, ob es eine Systemtabelle namens MSysCompactErrors gibt. In dieser Tabelle werden alle Probleme aufgeführt, die während des Komprimierens aufgetreten sind.

Das ist alles, was ich in Bezug auf kompakt für jetzt denken kann.

+3

Nice Post, obwohl Ihre Antwort fühlt sich an wie eine Fliege mit einer Bazooka töten. :) –

+0

Heh, ja, schätze ich. Aber die Frage wird oft genug gestellt, und es ist ziemlich klar, dass Leute Datenbanken benutzen, einschließlich Jet/ACE, ohne das Grundverständnis zu haben, wie sie funktionieren. Das bringt alles an einem Ort, mehr oder weniger, und ich hoffe, dass die Leute darauf hingewiesen werden können, wenn es nötig ist, anstatt dass andere Fragen zu diesem Thema Stück für Stück beantworten müssen. Ich schreibe gerne solche Antworten, da es mir hilft zu verstehen, was ich tue und was ich nicht weiß. Ich hoffe es hilft auch anderen manchmal. –

4

Das Microsoft Access-Datenbankmodul stellt eine CompactDatabase-Methode bereit, die eine kompakte Kopie der Datenbankdatei erstellt. Die Datenbankdatei muss vor dem Aufruf von CompactDatabase geschlossen werden.

Dokumentation:

Hier ist ein Python-Skript, das DAO verwendet zu kopieren und kompakte MDB-Dateien:

import os.path 
import sys 
import win32com.client 

# Access 97: DAO.DBEngine.35 
# Access 2000/2003: DAO.DBEngine.36 
# Access 2007: DAO.DBEngine.120 
daoEngine = win32com.client.Dispatch('DAO.DBEngine.36') 

if len(sys.argv) != 3: 
    print("Uses Microsoft DAO to copy the database file and compact it.") 
    print("Usage: %s DB_FILE FILE_TO_WRITE" % os.path.basename(sys.argv[0])) 
    sys.exit(2) 

(src_db_path, dest_db_path) = sys.argv[1:] 
print('Using database "%s", compacting to "%s"' % (src_db_path, dest_db_path)) 
daoEngine.CompactDatabase(src_db_path, dest_db_path) 
print("Done") 
1

Mit Python Sie mit kompaktem können die pypyodbc Bibliothek (Entweder .mdb)

import pypyodbc 
pypyodbc.win_compact_mdb('C:\\data\\database.accdb','C:\\data\\compacted.accdb') 

(source)

Dann können Sie compacted.accdb zurück zur Datenbank kopieren.Accdb mit shutil:

import shutil 
shutil.copy2('C:\\data\\compacted.accdb','C:\\data\\database.accdb') 

(source)

Hinweis: Soweit ich für Zugriff DB wissen mit ODBC, Python und seine Bibliotheken müssen 32bit (link). Diese Schritte funktionieren wahrscheinlich auch nur mit Windows OS.

Verwandte Themen