Come comprimere un database MS Access

Question

Ho un file .mdb che è 70 MB.

Dopo aver eliminato tutti i record contenuti nel file, la dimensione rimane 70 MB.

Come si riduce il file .mdb?

Answer 1

Aprire il mdb e fare un 'Compact and Repair'. Questo ridurrà la dimensione del mdb.

È inoltre possibile impostare l'opzione "Compatta al termine" su on (disattivata per impostazione predefinita).

Ecco un link ad alcune informazioni aggiuntive: http://www.trcb.com/computers-and-technology/data-recovery/ways-to-compact-and-repair-an-access-database-27384.htm

Answer 2

Ogni motore di database che sia mai esistito esigenze normale intervento girano su di loro per ottimizzare la memorizzazione dei dati e per recuperare slack space. Indietro in giorni xBase, hai eseguito un comando PACK per rimuovere le righe cancellate, per esempio. Su SQL Server, si eseguono script per ridurre i file di dati effettivi per gli stessi motivi.

Perché ogni motore di database esegue questa operazione?

Perché sarebbe un enorme successo in termini di prestazioni se ogni scrittura sul database dovesse riscrivere l'intero file in ordine ottimizzato. Considera un database che memorizza ciascuna tabella di dati in un file separato. Se una tabella ha 10000 record e si elimina il 5000 ° record, per eliminare lo spazio allentato, è necessario riscrivere l'intera seconda parte del file di dati. Invece, ogni database utilizza una forma di marcatura dello spazio utilizzato come non utilizzato e scartato la prossima volta che le operazioni di ottimizzazione vengono eseguite sulla tabella dati.

Jet/ACE non è diverso da questo punto di vista rispetto a qualsiasi altro motore di database e qualsiasi applicazione che utilizza un database Jet/ACE come archivio dati dovrebbe avere pianificate operazioni di manutenzione regolari, incluso un backup e una compatta.

Ci sono alcuni problemi con questo in Jet/ACE che non sono presenti nei motori di database del server. In particolare, non puoi compattare se tutti gli utenti non hanno chiuso le loro connessioni al file di dati. In un database del server, gli utenti si connettono al processo sul lato server del motore di database e quel demone sul lato server è l'unico "utente" dei file di dati effettivi in ​​cui i dati sono archiviati. Pertanto, il demone del server può decidere quando eseguire le routine di ottimizzazione e manutenzione, dal momento che ha il pieno controllo di quando i file di dati sono in uso o meno.

Un problema comune con le applicazioni di Access è che gli utenti lasceranno l'applicazione aperta sui loro computer e lasceranno l'ufficio per il giorno, il che significa che quando si esegue l'operazione compatta, ad esempio alle 2:00 del mattino, il file è ancora aperto e non è possibile eseguirlo (perché compatto sostituisce il file originale). La maggior parte dei programmatori di applicazioni Access che riscontrano questo problema tollera l'errore occasionale di questo tipo di manutenzione durante la notte (la copia shadow del volume consente comunque un backup del file, sebbene non sia garantito che la copia di backup sarà in uno stato internamente coerente al 100%) , o progetteranno le loro applicazioni di accesso per terminare in un momento appropriato per consentire operazioni di manutenzione durante la notte. Ho fatto entrambe le cose, me stesso.

Nelle applicazioni non di accesso, lo stesso problema esiste, ma deve essere affrontato in modo diverso. Per le applicazioni Web, si tratta di un problema, ma in generale, direi che qualsiasi app Web che elabora i dati abbastanza da richiedere una compatta è una per la quale un archivio dati Jet/ACE è del tutto inappropriato.

Ora, sul tema della COMPATTO SU CHIUSURA:

non dovrebbe mai essere utilizzato da chiunque.

Sempre.

E 'inutile e addirittura pericoloso quando si prende in realtà in

E' inutile perché non c'è propriamente-architettato ambiente di produzione in cui gli utenti avrebbero mai apriremo il back-end -. Se si tratta di un app di accesso, dovrebbe essere diviso, con gli utenti che aprono sempre solo il front-end e, se si tratta di un'app Web, gli utenti non interagiranno direttamente con il file di dati. Quindi, in entrambi gli scenari, nessuno attiverà mai il COMPACT ON CLOSE, quindi hai sprecato il tuo tempo per accenderlo.

In secondo luogo, anche se qualcuno lo fa occasionalmente attivarlo, funzionerà solo se quell'utente è l'unico con il database aperto. Come ho detto sopra, non può essere compattato se ci sono altri utenti con esso aperti, quindi non funzionerà, COMPACT ON CLOSE può essere eseguito solo quando l'utente che lo attiva ha accesso esclusivo.

Ma la cosa peggiore di tutte, COMPACT ON CLOSE è pericoloso e se viene eseguito può portare alla perdita di dati effettiva. Questo perché ci sono determinati stati in cui può trovarsi una base di dati Jet/ACE in cui le strutture interne non sono più disponibili, ma i dati sono tutti ancora accessibili. Quando l'operazione di compattazione/riparazione viene eseguita in quello stato, i dati possono potenzialmente andare persi. Questa è una condizione estremamente rara, ma è una possibilità molto remota.

Il punto è che COMPACT ON CLOSE non è condizionale e non vi è alcun prompt che ti chieda se desideri eseguirlo. Non hai la possibilità di fare un backup prima dell'esecuzione, quindi se lo hai acceso e si attiva quando il tuo database si trova in quello stato molto raro, potresti perdere i dati che altrimenti potresti recuperare non hai eseguito l'operazione compatta.

Quindi, in breve, nessuno con la comprensione di Jet/ACE e compattazione si accende mai COMPACT ON CLOSE.

Per un singolo utente, è possibile compattare solo se necessario.

Per un'applicazione condivisa, una sorta di script di manutenzione programmata è la cosa migliore, di solito in esecuzione durante la notte sul file server. Quello script farebbe un backup del file, quindi eseguirà il compact. È uno script abbastanza semplice da scrivere in VBScript e facilmente programmabile.

Infine, se l'applicazione elimina spesso un numero elevato di record, nella maggior parte dei casi è un'indicazione di un errore di progettazione. I record aggiunti e cancellati nell'uso regolare della produzione sono TEMPORANEI e non appartengono al file di dati principale, sia in modo logico che pragmatico.

Tutte le mie app di produzione hanno un database temporaneo come parte dell'architettura e tutte le tabelle temporanee sono memorizzate lì. Non mi sono mai preoccupato di compattare i database temporanei. Se per qualche ragione le prestazioni sono impantanate a causa del bloat all'interno del database temporaneo, dovrei semplicemente copiare una copia vuota e priva del database temporaneo sopra a quella vecchia, dato che nessuno dei dati in esso contenuti è diverso dal temporaneo. Ciò riduce il churn e il bloat nella parte anteriore o posteriore e riduce notevolmente la frequenza dei compatti necessari sul file di dati back-end.

Sulla questione di come compattare, ci sono una serie di opzioni:

1. nel accesso utente è possibile compattare il database attualmente aperto (Strumenti | Utilità database).Tuttavia, questo non ti permette di fare un backup come parte del processo, ed è sempre una buona idea fare il backup prima di compattare, nel caso qualcosa vada storto.

2. nell'interfaccia utente di accesso è possibile compattare un database che è non aperto. Questo compatta da un file esistente a uno nuovo, quindi quando hai finito devi rinominare sia il file originale sia quello appena compattato (per avere il nuovo nome). La finestra di dialogo FILE OPEN che ti chiede quale file da compattare ti permette di rinominare il file in quel punto, così puoi farlo come parte del processo manuale.

3. in codice, è possibile utilizzare il metodo DAO DBEngine.CompactDatabase per fare il lavoro. È utilizzabile da Access VBA o da VBScript o da qualsiasi ambiente in cui è possibile utilizzare COM. Sei responsabile nel tuo codice per fare il backup e rinominare i file e così via.

4. un'altra opzione nel codice è JRO (Jet & Oggetti di replica), ma non offre nulla per quanto riguarda le operazioni di compattazione che DAO non ha già. JRO è stato creato come una libreria separata per gestire funzionalità specifiche Jet che non sono stati supportati in ADO, quindi se si sta utilizzando ADO come l'interfaccia, la biblioteca di MS-consigliato per la compattazione sarebbe JRO. Dall'interno di accesso, JRO è inappropriato per compatto, come ci si già il metodo CompactDatabase a disposizione, anche se non si dispone di un riferimento DAO (l'DBEngine è sempre disponibile in Access anche se non si dispone di un riferimento DAO). In altre parole, DBEngine.CompactDatabase può essere utilizzato all'interno di accesso senza né un DAO o ADO di riferimento, in cui il metodo JRO CompattaDatabase è disponibile solo con un riferimento JRO (o utilizzando l'associazione tardiva). Dall'esterno di Access, JRO potrebbe essere la libreria appropriata.

Lasciatemi sottolineare quanto siano importanti i backup. Non ne avrai bisogno 999 volte su 1000 (o anche meno spesso), ma quando ne hai bisogno, ne avrai bisogno! Quindi mai compatto senza fare un backup in anticipo.

Infine, dopo ogni compatto, è una buona idea per controllare il file compattato per vedere se c'è una tabella di sistema denominata MSysCompactErrors. Questa tabella elenca tutti i problemi incontrati durante il compact, se ce ne fossero.

Questo è tutto quello che posso pensare di considerare compatta per ora.

Answer 3

Il motore di database di Microsoft Access fornisce un metodo CompactDatabase che esegue una copia compatta del file di database. Il file di database deve essere chiuso prima di chiamare CompactDatabase.

Documentazione:

• Pages on microsoft.com about "Compact and Repair Database"
• DBEngine.CompactDatabase Method (DAO)

Ecco uno script Python che utilizza DAO per copiare e compatti file MDB:

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") 

Answer 4

con Python è possibile compattare con la libreria pypyodbc (Sia mdb o accdb)

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

(source)

Quindi è possibile copiare compacted.accdb torna al database.ACCDB con shutil:

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

(source)

Nota: Per quanto ne so per l'accesso DB con ODBC, pitone e le sue librerie deve essere a 32 bit (link). Inoltre, questi passaggi probabilmente funzionano solo con il sistema operativo Windows.