Cómo comprimir una base de datos MS Access

Question

Tengo un archivo .mdb que es de 70MB.

Después de eliminar todos los registros contenidos en el archivo, el tamaño sigue siendo de 70MB.

¿Cómo puedo hacer que mi archivo .mdb sea más pequeño?

Answer 1

Abra el mdb y realice un 'Compactar y reparar'. Esto reducirá el tamaño del mdb.

También puede establecer la opción 'Compactar al cerrar' en activada (desactivada de manera predeterminada).

Aquí hay un enlace a información adicional: http://www.trcb.com/computers-and-technology/data-recovery/ways-to-compact-and-repair-an-access-database-27384.htm

Answer 2

Cada motor de base de datos que ha existido jamás necesidades de intervención normal se ejecutan en ellos para optimizar el almacenamiento de datos y para recuperar el espacio de holgura. De vuelta en los días de xBase, ejecutó un comando PACK para eliminar filas eliminadas, por ejemplo. En SQL Server, ejecuta scripts para reducir los archivos de datos reales por las mismas razones.

¿Por qué cada motor de base de datos hace esto?

Porque sería un gran golpe de rendimiento si cada escritura en la base de datos tuviera que reescribir todo el archivo en orden optimizado. Considere una base de datos que almacena cada tabla de datos en un archivo separado. Si una tabla tiene 10000 registros, y elimina el 5000º registro, para deshacerse del espacio libre, tendría que volver a escribir toda la segunda mitad del archivo de datos. En cambio, cada base de datos utiliza alguna forma de marcar el espacio utilizado como no utilizado y descartable la próxima vez que se ejecutan las operaciones de optimización en la tabla de datos.

Jet/ACE no es diferente en este aspecto que cualquier otro motor de base de datos y cualquier aplicación que utilice una base de datos Jet/ACE como almacén de datos debe programar operaciones regulares de mantenimiento, incluida una copia de seguridad y luego un compacto.

Hay algunos problemas con esto en Jet/ACE que no están presentes en los motores de la base de datos del servidor. Específicamente, no puede compactar a menos que todos los usuarios hayan cerrado sus conexiones al archivo de datos. En una base de datos de servidor, los usuarios se conectan al proceso del lado del servidor del motor de la base de datos, y ese demonio del lado del servidor es el único "usuario" de los archivos de datos reales en los que se almacenan los datos. Por lo tanto, el servidor demonio puede decidir cuándo realizar las rutinas de optimización y mantenimiento, ya que tiene el control total de cuándo los archivos de datos están en uso o no.

Un problema común con las aplicaciones Access es que los usuarios dejarán abierta su aplicación en sus computadoras y saldrán de la oficina por el día, lo que significa que cuando ejecute su operación compacta, por ejemplo a las 2:00 a.m., el archivo aún está abierto y no puede ejecutarlo (porque el compacto reemplaza el archivo original). La mayoría de los programadores de aplicaciones de Access que enfrentan este problema tolerarán la falla ocasional de este tipo de mantenimiento nocturno (la copia instantánea de volumen aún permite una copia de seguridad del archivo, aunque no hay garantía de que la copia de seguridad se encuentre en un estado 100% consistente) , o diseñarán sus aplicaciones de acceso para terminar en el momento apropiado para permitir operaciones de mantenimiento durante la noche. He hecho ambas cosas, yo mismo.

En aplicaciones que no son de acceso, existe el mismo problema, pero debe abordarse de manera diferente. Para las aplicaciones web, es un problema, pero, en general, diría que cualquier aplicación web que genere los datos suficientes como para que se necesite un compacto es aquella para la que un almacén de datos Jet/ACE es totalmente inapropiado.

Ahora, sobre el tema de Compactar al cerrar:

nunca debería ser utilizado por cualquier persona.

Ever.

Es inútil y muy peligroso cuando en realidad entra en acción

Es inútil porque no hay entorno de producción sin architected adecuadamente en las que los usuarios cada vez se abren la parte de atrás -. Si se trata de una aplicación de acceso, debe ser dividir, con los usuarios que solo abren la interfaz, y si se trata de una aplicación web, los usuarios no interactuarán directamente con el archivo de datos. Entonces, en ambos escenarios, nadie activará el COMPACTO EN CIERTO, por lo que ha perdido el tiempo en encenderlo.

En segundo lugar, incluso si alguien ocasionalmente lo activa, solo funcionará si ese usuario es el único con la base de datos abierta. Como dije anteriormente, no se puede compactar si hay otros usuarios con él abierto, así que esto tampoco va a funcionar: COMPACT ON CLOSE solo puede ejecutarse cuando el usuario que lo activa tiene acceso exclusivo.

Pero lo peor de todo, COMPACT ON CLOSE es peligroso y si se ejecuta puede provocar la pérdida de datos reales. Esto se debe a que hay ciertos estados en los que una base de datos de Jet/ACE puede estar en donde las estructuras internas están fuera de control, pero todos los datos aún están accesibles. Cuando la operación de compacta/reparación se ejecuta en ese estado, los datos pueden perderse potencialmente. Esta es una condición extremadamente rara, pero es una posibilidad muy remota.

El punto es que COMPACT ON CLOSE no es condicional, y no hay un mensaje que le pregunte si desea ejecutarlo. No tienes la posibilidad de hacer una copia de seguridad antes de que se ejecute, por lo que si la enciendes y se inicia cuando tu base de datos se encuentra en ese estado tan raro, podrías perder datos que de otra manera podrías recuperar si no ejecutó la operación compacta.

Por lo tanto, en resumen, nadie con un entendimiento de Jet/ACE y compactación enciende alguna vez COMPACT ON CLOSE.

Para un solo usuario, puede simplemente compactar según sea necesario.

Para una aplicación compartida, algún tipo de script de mantenimiento programado es lo mejor, generalmente se ejecuta durante la noche en el servidor de archivos. Esa secuencia de comandos haría una copia de seguridad del archivo y luego ejecutaría el compacto. Es un script bastante simple de escribir en VBScript y fácil de programar.

Por último, si su aplicación elimina con frecuencia grandes cantidades de registros, en la mayoría de los casos eso indica un error de diseño. Los registros que se agregan y eliminan en el uso de producción regular son DATOS TEMPORALES y no pertenecen a su archivo de datos principal, tanto desde un punto de vista lógico como pragmático.

Todas mis aplicaciones de producción tienen una base de datos temporal como parte de la arquitectura, y todas las tablas temporales se almacenan allí. Nunca me molesto en compactar las bases de datos temporales. Si por alguna razón el rendimiento se empantana debido a la hinchazón dentro de la base de datos temporal, simplemente copiaría una copia prístina vacía de la base de datos temporal encima de la anterior, ya que ninguno de los datos allí es más que temporal. Esto reduce la agitación y la hinchazón en el extremo frontal o posterior y reduce en gran medida la frecuencia de compactos necesarios en el archivo de datos de fondo.

Sobre la cuestión de cómo compactar, hay una serie de opciones:

1. en la interfaz de usuario de acceso se puede compactar la base de datos abierta (Herramientas | Utilidades de la base).Sin embargo, eso no le permite realizar una copia de seguridad como parte del proceso, y siempre es una buena idea realizar una copia de seguridad antes de compactar, en caso de que algo salga mal.

2. en la interfaz de usuario de acceso se puede compactar una base de datos que es no abierta. Éste se compacta de un archivo existente a uno nuevo, de modo que cuando haya terminado, tendrá que cambiar el nombre del archivo original y el archivo recientemente compactado (para tener el nuevo nombre). El cuadro de diálogo ABRIR ARCHIVO que le pregunta a qué archivo compactar le permite cambiar el nombre del archivo en ese punto, de modo que puede hacerlo como parte del proceso manual.

3. en el código, puede utilizar el método DAO DBEngine.CompactDatabase para hacer el trabajo. Esto se puede utilizar desde Access VBA, desde VBScript o desde cualquier entorno en el que pueda usar COM. Usted es responsable en su código de hacer la copia de seguridad y cambiar el nombre de los archivos, etc.

4. otra opción en el código es JRO (Jet & Replication Objects), pero no ofrece nada con respecto a las operaciones compactas que DAO aún no posee. JRO se creó como una biblioteca separada para manejar funciones específicas de Jet que no eran compatibles con ADO, por lo que si usa ADO como su interfaz, la biblioteca recomendada por MS para compactar sería JRO. Desde Access, JRO no es apropiado para compacto, ya que ya tiene disponible el método CompactDatabase, incluso si no tiene una referencia DAO (el DBEngine siempre está disponible en Access, tenga o no una referencia DAO). En otras palabras, DBEngine.CompactDatabase se puede usar en Access sin una referencia DAO o ADO, mientras que el método JRO CompactDatabase solo está disponible con una referencia JRO (o mediante el enlace tardío). Desde fuera de Access, JRO puede ser la biblioteca apropiada.

Permítanme enfatizar la importancia de las copias de seguridad. No lo necesitarás 999 veces de cada 1000 (o incluso menos), ¡pero cuando lo necesites lo necesitarás! Así que nunca compacte sin hacer una copia de seguridad de antemano.

Finalmente, después de cualquier compacto, es una buena idea verificar el archivo compactado para ver si hay una tabla del sistema llamada MSysCompactErrors. Esta tabla enumerará los problemas encontrados durante el compacto, si hubo alguno.

Eso es todo lo que puedo pensar con respecto a compacto por el momento.

Answer 3

El motor de base de datos de Microsoft Access proporciona un método CompactDatabase que realiza una copia compacta del archivo de base de datos. El archivo de la base de datos debe estar cerrado antes de llamar a CompactDatabase.

Documentación:

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

Aquí es un script en Python que utiliza DAO para copiar y compactos archivos 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 puede compactar con la biblioteca pypyodbc (Ya sea .mdb o .accdb)

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

(source)

A continuación, puede copiar compacted.accdb de nuevo a la base de datos.ACCDB con shutil:

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

(source)

Nota: Por lo que yo sé de acceso DB con ODBC, pitón y sus bibliotecas debe ser de 32 bits (link). Además, estos pasos probablemente solo funcionen con el sistema operativo Windows.