Cosa fanno le operazioni di riparazione e compatta su un .MDB?Cosa fanno le operazioni di riparazione e compattazione su un .MDB? Interromperanno l'arresto anomalo dell'applicazione?
Se queste operazioni non interrompono 1 GB + .MDB in caso di arresto anomalo dell'applicazione VB, quali altre opzioni ci sono?
Perché un file di dimensioni grandi .MDB causa l'arresto anomalo di un'applicazione?
"Cosa fare operazioni di compattazione e riparazione fare per un MDB?"
Prima di tutto, non preoccuparti della riparazione. Il fatto che ci siano ancora dei comandi che pretendono di fare una riparazione autonoma è un retaggio dei vecchi tempi. Quel comportamento di quel comando è stato cambiato molto a partire da Jet 3.51, e da allora è rimasto tale. Cioè, una riparazione non verrà mai eseguita a meno che Jet/ACE non ritenga necessario. Quando si esegue una compatta, verrà verificato se è necessaria una riparazione ed eseguita prima della compatta.
Quindi, che cosa fa?
Una compatta/riparazione riscrive il file di dati, eliminando tutte le pagine di dati inutilizzate, scrivendo tabelle e indici in pagine di dati contigui e contrassegnando tutti i QueryDef salvati per la ricompilazione la prossima volta che vengono eseguiti. Aggiorna inoltre determinati metadati per le tabelle e altri metadati e strutture interne nell'intestazione del file.
Tutti i database presentano una forma di operazione "compatta" perché sono ottimizzati per le prestazioni. Lo spazio su disco è economico, quindi anziché scrivere le cose per usare lo storage in modo efficiente, scrivono invece sul primo spazio disponibile. Pertanto, in Jet/ACE, se si aggiorna un record, il record viene scritto nella pagina dei dati originale solo se i nuovi dati rientrano nella pagina dei dati originale. In caso contrario, la pagina di dati originale viene contrassegnata come non utilizzata e il record viene riscritto in una pagina di dati completamente nuova. In questo modo, il file può diventare frammentato internamente, con pagine di dati usate e non utilizzate mescolate in tutto il file.
Un compatto organizza tutto in modo ordinato e si libera di tutto lo spazio allentato. Riscrive inoltre le tabelle di dati nell'ordine delle chiavi primarie (cluster Jet/ACE sul PK, ma questo è l'unico indice su cui è possibile eseguire il clustering). Gli indici vengono anche riscritti a quel punto, dal momento che col tempo anche quelli diventano frammentati con l'uso.
Compatto è un'operazione che dovrebbe essere parte della normale manutenzione di qualsiasi file Jet/ACE, ma non dovresti farlo spesso. Se stai riscontrando un aumento regolare del numero, suggerisci che potresti utilizzare male il tuo database di back-end memorizzando/cancellando dati temporanei. Se la tua app aggiunge record e li elimina come parte delle sue normali operazioni, allora hai un problema di progettazione che farà gonfiare regolarmente i tuoi file di dati.
Per correggere quell'errore, spostare le tabelle temporanee su un diverso MDB/ACCDB autonomo in modo che il tasso di abbandono non causi il gonfiamento del file di dati principale.
Su un'altra nota non applicabile in questo contesto, i front-end caricano in diversi modi a causa della natura di ciò che è memorizzato in essi. Dato che questa domanda riguarda un MDB/ACCDB usato da VB, non entrerò nei dettagli, ma basti dire che la compattazione di un front-end è qualcosa che è necessario durante lo sviluppo, ma solo molto raramente nell'uso di produzione. L'unico motivo per compattare un front-end di produzione è aggiornare i metadati e ricompilare le query memorizzate in esso.
È sempre stato che i file MDB diventano lenti e inclini alla corruzione poiché superano 1 GB, ma non ho mai saputo perché - è sempre stato solo un fatto della vita. Ho fatto alcune ricerche rapide, non ho trovato nessun addetto ai lavori, o anche ben informato, spiegazioni sul perché questa dimensione sia correlata con i problemi di MDB, ma la mia esperienza è sempre stata che i file MDB diventano incredibilmente inaffidabili avvicinandosi e superando 1 GB .
Ecco l'articolo del ms Kb sulla riparazione e compatto, in dettaglio ciò che accade durante questa operazione:
http://support.microsoft.com/kb/209769/EN-US/
L'applicazione probabilmente si blocca come il risultato di dati impropri/inaspettate tornati da una query di database a un MDB così grande - quale errore in particolare si ottiene quando l'applicazione si arresta in modo anomalo? Forse c'è un modo per catturare l'errore e affrontarlo invece di arresti anomali dell'applicazione.
Non ho mai visto un file MDB/ACCDB oltre 1 GB, quindi non posso dire se sono lenti oltre ciò che ci si aspetterebbe linearmente per la maggiore quantità di dati. Qualsiasi app che si stava avvicinando a quella quantità di dati sarebbe in linea di massima per l'upsize a SQL Server, in ogni caso. È semplicemente troppo facile per qualcosa gonfiare un back-end da 1 GB e colpire il limite di 2 GB e quindi si è appena in difficoltà. –
Se si verifica un arresto anomalo, è possibile provare a decompilare il DB e/o creare un nuovo database e copiare tutti gli oggetti nel nuovo contenitore.
provare il decompilare prima, per fare questo basta aggiungere il flag/decompilare alle opzioni di avvio del vostro DB per esempio
“C: \ Program Files \ accesso \ Access.mdb” “C: \ mydb. mdb”/ decompilare
poi compatta, compilare e quindi compatto di nuovo
EDIT:
non puoi fare senza l'accesso in fase di installazione, ma se si tratta solo di memorizzazione dei dati poi un decompilare non fare alcun bene . Si può tuttavia osservare JetComp per aiutarvi con voi compattazione esigenze
support.microsoft.com/kb/273956
Posso farlo senza aver installato Access? Il .mdb viene utilizzato come back-end per un'app VB. – CJ7
Vedere la mia modifica per ulteriori informazioni –
Decompila è irrilevante per un database che contiene solo tabelle di dati. La domanda dice che è stata usata da VB, così da rendere chiaro che decompilare è completamente non operativo. Non farà male nulla, ma non aiuterà nulla, neanche. –
e se si utilizza un back-end di SQL Server, questo passaggio è solo una completa perdita di tempo allora? –
Sì, se SQL Server viene utilizzato nel back-end, quasi nulla accadrà nel database in un'operazione compatta. –