Cómo reparar bases de datos corruptas en aplicaciones de contabilidad

Cuando una aplicación de contabilidad deja de funcionar de la noche a la mañana y empiezan a aparecer mensajes de error relacionados con la base de datos, es normal entrar en pánico. En muchos casos, detrás de estos fallos hay tablas dañadas, índices corruptos o archivos de datos inconsistentes que están impidiendo que el sistema trabaje con normalidad. La buena noticia es que, si sabes por dónde atacar, muchas de estas situaciones se pueden diagnosticar y reparar sin perder (demasiada) información.

En entornos reales -ya sea un ERP, un programa de facturación o una solución contable a medida- es bastante habitual trabajar con motores como MySQL, Microsoft SQL Server o incluso Microsoft Access como base de datos subyacente. Cada uno tiene sus propias herramientas y procedimientos de reparación, pero todos comparten la misma idea: comprobar la integridad, corregir lo que se pueda y minimizar la pérdida de datos. En este artículo vamos a ver, con detalle y con un lenguaje lo más claro posible, cómo reparar bases de datos corruptas en aplicaciones de contabilidad utilizando las técnicas nativas de cada plataforma y algunas buenas prácticas imprescindibles.

Causas habituales de corrupción en bases de datos de contabilidad

Antes de ponerse a teclear comandos como loco, conviene entender qué suele provocar que una base de datos se corrompa. En aplicaciones contables el problema suele estar relacionado con caídas de sistema, cortes de red, apagados bruscos del servidor o errores de disco. Cuando estos incidentes se producen justo mientras se está escribiendo información, las tablas pueden quedar a medio actualizar y el motor marca esos objetos como dañados.

También es relativamente frecuente que, en bases de datos compartidas por varios usuarios, se den condiciones de carrera o accesos concurrentes poco controlados. En este escenario, ciertos motores -sobre todo en configuraciones antiguas- pueden acabar con registros inconsistentes, índices rotos o ficheros internos fuera de sincronía. En un software contable esto se traduce en asientos que no cuadran, facturas que desaparecen o totales que no se corresponden con la realidad.

Otro motivo típico está relacionado con la propia gestión del espacio en disco. Los archivos de base de datos crecen con el uso, se fragmentan, acumulan objetos temporales y, si no se cuidan, terminan afectando al rendimiento. En el caso de Access, por ejemplo, este crecimiento continuo puede acabar provocando errores y daños en el archivo. De ahí la importancia de compactar y reparar periódicamente para eliminar espacio sobrante y corregir pequeñas incoherencias.

Por último, no hay que olvidar los errores humanos y las malas prácticas de administración. Intentar recrear a mano un archivo de log de transacciones que se ha borrado, mover ficheros de datos sin seguir el procedimiento correcto o tocar permisos NTFS sin saber muy bien qué se hace puede dejar una base de datos en un estado delicado, como RECOVERY_PENDING en SQL Server o tablas marcadas como corruptas en MySQL.

Diagnóstico y reparación en Plesk Onyx para MySQL y Microsoft SQL

Si tu aplicación de contabilidad está alojada en un servidor con Plesk Onyx, tienes a tu disposición una interfaz bastante cómoda para intentar solucionar algunos problemas de integridad. Plesk se apoya en las herramientas nativas de cada motor de base de datos; por ejemplo, para MySQL utiliza internamente la utilidad mysqlcheck, que permite comprobar y reparar tablas de forma automática.

El flujo habitual en Plesk para verificar y arreglar una base de datos es bastante sencillo. Desde el panel principal, puedes entrar en Sitios web y dominios > Bases de datos y localizar la base de datos que utiliza tu aplicación de contabilidad. Dentro del panel de herramientas de esa base de datos encontrarás la opción Verificar y reparar, que lanza la comprobación de integridad sobre todas las tablas gestionadas por el motor.

Si durante ese proceso Plesk detecta problemas, en pantalla aparecerá un enlace del estilo «Ver detalles y resolver». Al pulsarlo, se abrirá una lista con las tablas afectadas y el tipo de error encontrado en cada una. En bases de datos MySQL la interfaz te permite seleccionar específicamente qué tablas quieres intentar reparar, lo cual es útil si el daño está muy localizado o si prefieres ser prudente y actuar solo sobre lo estrictamente necesario.

En el caso de Microsoft SQL Server, la filosofía cambia: desde Plesk únicamente es posible lanzar la reparación sobre la base de datos completa, no a nivel de tabla individual. Esto implica que, cuando pulses en reparar, Plesk utilizará las funciones de comprobación y corrección de SQL Server sobre todo el conjunto de datos. Para confirmar la acción, normalmente tendrás que hacer clic en «Reparar los elementos seleccionados» en MySQL o simplemente en «Reparar» en Microsoft SQL, según el motor en uso.

Esta vía mediante interfaz gráfica es ideal como primer intento en entornos donde no se tiene acceso directo por consola o cuando el usuario no está familiarizado con comandos SQL. Aun así, conviene recordar que no todos los escenarios de corrupción se pueden solventar desde Plesk; si el problema es grave, terminarás necesitando actuación manual con las herramientas de base de datos o restaurar desde copia de seguridad.

Reparar bases de datos SQL Server en estado RECOVERY_PENDING o EMERGENCY

En el mundo de SQL Server, es relativamente habitual encontrarse bases de datos que han quedado bloqueadas en estados como RECOVERY_PENDING, SUSPECT o EMERGENCY tras un incidente. En una aplicación de contabilidad, esto se traduce en que el programa no levanta, no puede acceder a sus datos o lanza errores 945, 823 u otros similares al intentar conectarse.

Un caso típico es el de separar una base de datos (detach), borrar accidentalmente su archivo de log .LDF y tratar luego de adjuntarla (attach) de nuevo. En este contexto, SQL Server puede devolver mensajes de error como «Error al adjuntar las bases de datos», invitando a consultar información más detallada en el registro de errores, o un error más grave a nivel de sistema, como el 823, donde se indica que el sistema operativo ha devuelto un problema de lectura al intentar acceder a un archivo físico de datos o log.

Intentar crear a mano un nuevo archivo de log para «engañar» a SQL Server no suele ser una buena idea. El propio motor suele responder con mensajes indicando que la integridad de la base de datos está comprometida y que es necesario ejecutar un DBCC CHECKDB completo. Incluso aunque se logre adjuntar el archivo de datos, es probable que la base de datos quede en estado RECOVERY_PENDING con un error 945, señal de que hay ficheros inaccesibles, falta de espacio o problemas de memoria.

En algunos procedimientos de recuperación se recurre a renombrar el archivo de datos original (por ejemplo, cambiar sergiodb.mdf por sergiodb_bak.mdf) y crear una base de datos nueva con el mismo nombre, obteniendo así un nuevo .MDF y un .LDF limpios. A continuación se detiene SQL Server, se sobreescribe el archivo de datos nuevo con el antiguo “bueno” y se arranca de nuevo el servicio. Este tipo de maniobra, aunque a veces funciona, suele ir acompañado de errores de tipo «Acceso denegado» (5120) o de base de datos inaccesible (945), lo que obliga a revisar permisos NTFS y, de nuevo, deja la base en RECOVERY_PENDING.

Para comprobar en qué estado se encuentra exactamente una base de datos, lo más directo es lanzar una consulta sobre la vista de catálogo de sys.databases:

SELECT state_desc FROM sys.databases WHERE name = ‘NombreDeTuBD’;

Si el resultado muestra RECOVERY_PENDING, tendrás que pasar a acciones más avanzadas. Aquí entra en juego el modo EMERGENCY y las opciones de reparación que ofrece DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS, siempre entendiendo que puede haber pérdida de datos.

Procedimiento avanzado con EMERGENCY y DBCC CHECKDB en SQL Server

Cuando la base de datos está tan tocada que ni siquiera arranca, uno de los enfoques más utilizados (sobre todo si no hay copia de seguridad reciente) pasa por usar el modo de emergencia de SQL Server. Este modo permite montar la base de datos en un estado mínimo de solo lectura, saltándose ciertos chequeos de consistencia para que el administrador pueda intervenir.

El método más común consta de varios pasos encadenados. Primero, se sitúa la base de datos en modo EMERGENCY con una instrucción del tipo:

ALTER DATABASE NombreDeTuBD SET EMERGENCY;

Con este cambio se consigue pasar de RECOVERY_PENDING a EMERGENCY, aunque es necesario contar con permisos de sysadmin para ejecutarlo. A continuación, y para evitar que otras conexiones interfieran, se suele poner la base de datos en modo de usuario único con:

ALTER DATABASE NombreDeTuBD SET SINGLE_USER;

Una vez aislada la base, llega el momento clave: ejecutar DBCC CHECKDB sobre esa base con la opción de reparación que, en casos extremos, permite corregir daños a costa de posibles pérdidas de información:

DBCC CHECKDB (NombreDeTuBD, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;

Esta instrucción analiza a fondo la integridad interna de la base y trata de reconstruir estructuras dañadas, eliminando páginas o registros que no se puedan recuperar. El sufijo WITH NO_INFOMSGS sirve para ocultar mensajes informativos menos relevantes y centrarse en los errores clave. Terminado este proceso, el último paso consiste en devolver la base a modo multiusuario:

ALTER DATABASE NombreDeTuBD SET MULTI_USER;

Si todo va bien, la base de datos debería quedar en estado ONLINE y operativa, aunque lo recomendable es hacer después una revisión funcional de la aplicación de contabilidad y, si es posible, comparar con informes previos o con copias de datos para comprobar qué se ha podido perder o modificar. Este mismo enfoque se puede automatizar o ejecutar desde línea de comandos utilizando SQLCMD, algo muy útil en servidores donde solo se dispone de acceso por consola.

Uso de SQLCMD y comandos prácticos para recuperar SQL Server

El uso de SQLCMD es especialmente útil en servidores Windows donde la interfaz gráfica de SQL Server Management Studio no está disponible o cuando la instancia se administra solo por terminal. Mediante SQLCMD puedes conectarte a la instancia y lanzar todos los comandos necesarios para diagnosticar y reparar la base de tu aplicación contable.

Una secuencia típica de trabajo con SQLCMD podría comenzar con el siguiente comando de conexión, donde se indica el servidor y, si corresponde, el nombre de la instancia:

SQLCMD -S .\nombre_instancia

Una vez dentro, puedes listar el estado de todas las bases de datos con una consulta de catálogo como:

SELECT name, state_desc FROM sys.databases;

O filtrar específicamente por la base de datos problemática que usa tu programa de contabilidad:

SELECT name, state_desc FROM sys.databases WHERE name = ‘nombre_base_datos’;

A partir de ahí, el flujo es similar al descrito anteriormente: se cambia la base a EMERGENCY, luego a SINGLE_USER, se ejecuta DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS y, finalmente, se devuelve a MULTI_USER. Los comandos encadenados suelen ser:

ALTER DATABASE nombre_base_datos SET EMERGENCY;
ALTER DATABASE nombre_base_datos SET SINGLE_USER;
DBCC CHECKDB (nombre_base_datos, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
ALTER DATABASE nombre_base_datos SET MULTI_USER;

Tras esta serie de órdenes, conviene volver a consultar el estado de la base con:

SELECT name, state_desc FROM sys.databases WHERE name = ‘nombre_base_datos’;

y verificar que aparece en modo ONLINE. Aunque este procedimiento puede salvar más de una instalación contable en apuros, no hay que olvidar que implica un riesgo real de pérdida de datos. En entornos de producción, si se dispone de una copia de seguridad aceptablemente reciente, casi siempre es preferible restaurar en lugar de recurrir a REPAIR_ALLOW_DATA_LOSS.

Compactar y reparar bases de datos de Microsoft Access

Muchas pequeñas empresas utilizan aplicaciones contables basadas en Microsoft Access, ya sea con plantillas estándar o con desarrollos a medida. En estos casos, el archivo .ACCDB o .MDB hace de repositorio de toda la información financiera, con el riesgo de que, a medida que pasa el tiempo, el fichero crece, se fragmenta y puede degradar su rendimiento, o incluso llegar a dañarse.

Access incluye desde hace años un comando nativo llamado «Compactar y reparar base de datos», cuya función es doble. Por un lado, elimina espacio no utilizado, reorganiza índices y reduce el tamaño del archivo sin comprimir los datos en sí. Por otro, intenta corregir daños leves que se hayan podido producir en tablas, índices u otros objetos internos, ayudando así a mejorar tanto el rendimiento como la estabilidad general de la aplicación contable.

Antes de lanzar una operación de compactación y reparación, hay varias precauciones que conviene tomar. La primera es hacer una copia de seguridad del archivo de base de datos. Durante el proceso de reparación, Access puede truncar datos dañados o eliminar registros que no pueda reconstruir, por lo que tener un backup reciente permite intentar recuperar manualmente información perdida en caso necesario.

Además, es importante garantizar que se tiene acceso exclusivo al archivo. La operación de compactar y reparar no puede ejecutarse si hay otros usuarios conectados a la base de datos compartida, ya que podría interrumpir su trabajo y aumentar el riesgo de corrupción. Lo habitual en un entorno de contabilidad multiusuario es avisar de antemano, planificar un intervalo de mantenimiento y asegurarse de que nadie tiene abierto el archivo en el momento de iniciar la tarea.

Por último, hay que comprobar que el usuario que realiza la operación tiene permisos suficientes sobre el archivo y la carpeta donde se almacena la base de datos. Si no se dispone de privilegios de lectura y escritura adecuados, Access no podrá crear el archivo temporal ni reemplazar el original una vez terminada la compactación, por lo que será necesario pedir ayuda al administrador del sistema.

Compactar automáticamente al cerrar una base de datos Access

Para minimizar el riesgo de daños y mantener el tamaño del archivo bajo control, Access permite activar la opción «Compactar al cerrar» en cada base de datos. Esta configuración hace que, cada vez que se cierre la base, Access ejecute automáticamente la operación de compactar y reparar, sin que el usuario tenga que acordarse de hacerlo manualmente.

La ruta para activar esta opción pasa por el menú de archivo. Con la base de datos de la aplicación de contabilidad abierta, hay que ir a Archivo > Opciones y, en el cuadro de diálogo «Opciones de Access», seleccionar la sección «Base de datos activa». Dentro de las opciones de la aplicación se encuentra una casilla llamada «Compactar al cerrar»; al marcarla y pulsar Aceptar, la opción queda activada para esa base de datos concreta.

Es importante tener en cuenta que esta configuración se aplica de forma independiente a cada archivo .ACCDB o .MDB. Es decir, si tienes varias bases de datos (por ejemplo, una para contabilidad, otra para nóminas, otra para facturación), tendrás que activar la opción en cada una de ellas por separado si quieres que todas se compacten automáticamente al cerrarse.

En entornos multiusuario es recomendable valorar pros y contras. Esta automatización puede mejorar la salud de la base a largo plazo, pero también implica que, cada vez que se cierra, la base deja de estar disponible durante unos instantes mientras dura la compactación. Si hay muchos usuarios conectados constantemente, quizá convenga más planificar compactaciones manuales periódicas en horas de menor actividad.

Una vez activada la opción, hay que cerrar y volver a abrir la base de datos para que el cambio surta efecto. A partir de ese momento, la base de datos de la aplicación contable se compactará automáticamente al cerrarse, reduciendo el crecimiento innecesario del archivo y corrigiendo pequeños problemas internos de forma regular.

Compactar y reparar manualmente bases de datos Access

Además de la compactación automática al cierre, Access permite lanzar el comando de compactar y reparar de forma manual, tanto en bases de datos abiertas como en aquellas que no se pueden abrir debido a daños más serios. Esto resulta especialmente útil cuando la aplicación contable empieza a ir lenta, aparecen mensajes de error o se sospecha que hay algún tipo de corrupción.

Si la base de datos se puede abrir con normalidad, el proceso es muy directo. Con el archivo abierto, basta con ir a Archivo > Información y utilizar la opción «Compactar y reparar base de datos». Access creará automáticamente una copia compactada y reparada en la misma ubicación, reemplazando al archivo original una vez finalizada la operación, siempre y cuando todo haya ido bien.

Cuando la base de datos está tan dañada que ni siquiera se abre, hay que seguir un procedimiento ligeramente distinto. Primero se inicia Access sin abrir ningún archivo, por ejemplo seleccionando una base de datos en blanco desde la pantalla de plantillas inicial. A continuación, se cierra ese archivo en blanco desde Archivo > Cerrar y se accede a la pestaña Herramientas de base de datos, donde se encuentra el comando «Compactar y reparar base de datos».

Al ejecutarlo, Access mostrará un cuadro de diálogo llamado «Base de datos de origen para compactar», en el que se debe localizar y seleccionar el archivo de base de datos que se desea reparar (la base usada por la aplicación de contabilidad). Tras confirmar, Access intentará compactar y reparar ese archivo, generando una copia en la misma carpeta. Si la operación tiene éxito, la nueva base debería poder abrirse con mayor estabilidad.

En el caso de que Access detecte daños importantes al intentar abrir un archivo, a veces mostrará directamente un mensaje ofreciendo compactar y reparar automáticamente. Si se acepta, pueden ocurrir dos cosas: que Access repare por completo el archivo y muestre un aviso indicando que se ha completado correctamente, o que solo logre una reparación parcial. En este último caso, Access registra los objetos que no ha podido reparar en una tabla del sistema llamada MSysCompactErrors, que se abre automáticamente en vista Hoja de datos.

Esa tabla MSysCompactErrors resulta muy útil si dispones de una copia de seguridad anterior, ya que indica qué tablas, consultas o formularios han sufrido problemas durante el proceso. Activando la visualización de objetos de sistema en el panel de navegación (clic derecho en la barra de título de navegación > Opciones de navegación > Mostrar objetos del sistema), podrás acceder a esta tabla y decidir qué objetos recuperar manualmente desde el backup.

Por qué las bases de datos Access crecen y se dañan con el tiempo

En el día a día de una aplicación de contabilidad basada en Access, los usuarios añaden registros, modifican datos, eliminan asientos y se crean o retocan objetos de diseño. Todo esto hace que el archivo de base de datos aumente de tamaño de forma constante. Parte de ese crecimiento es lógico, pero otra parte se debe a cómo Access gestiona los objetos temporales y el espacio borrado.

Cada vez que Access realiza ciertas operaciones complejas (consultas, informes, etc.), puede crear objetos temporales ocultos para completar la tarea. En teoría, esos objetos deberían eliminarse cuando ya no son necesarios, pero en la práctica a veces quedan restos dentro del archivo. Además, cuando se elimina un objeto de base de datos (una tabla, una consulta, un formulario), el espacio que ocupaba no se libera automáticamente; el archivo sigue usando ese espacio, que queda «hueco» pero reservado.

Con el paso del tiempo, el archivo se va llenando de restos de objetos temporales y de huecos producidos por eliminaciones, lo que provoca una especie de fragmentación interna. El resultado es que el rendimiento de la aplicación contable se degrada: las tablas tardan más en abrirse, las consultas van lentas y las operaciones en general se sienten más pesadas. Aquí es donde la compactación periódica marca la diferencia, ya que reorganiza el contenido, elimina huecos y reduce el tamaño global.

Por otro lado, en escenarios de uso compartido a través de red, con varios usuarios conectados al mismo archivo, el riesgo de daños aumenta ligeramente. Si varios usuarios editan datos al mismo tiempo -especialmente en campos de texto largo o memo– y se producen caídas de red o interrupciones, es más fácil que el archivo quede en un estado inconsistente. Muchos de estos daños afectan más al diseño (formularios, código VBA) que a los datos en sí, pero en algunas ocasiones también se pierden registros, especialmente los de la última operación interrumpida.

Cuando Access detecta una interrupción durante una operación de escritura (por ejemplo, un corte de corriente en mitad de la grabación de un asiento contable), marca el archivo como dañado. Aunque la mayoría de las veces la reparación es posible y la pérdida de información se limita a la última acción realizada, conviene reforzar las medidas de prevención: copias de seguridad regulares, compactación periódica y, si el volumen de datos crece mucho, considerar migrar a un motor más robusto como SQL Server con Access como front-end.

Reparación de bases de datos MySQL en aplicaciones de contabilidad web

En el ámbito de las aplicaciones contables basadas en la web -por ejemplo, sistemas de facturación online o ERPs autoalojados- MySQL es uno de los motores más utilizados. Cuando una tabla MySQL se corrompe, los síntomas suelen ser claros: errores en pantalla relacionados con una o varias tablas concretas, mensajes en el log del servidor y partes de la aplicación que dejan de funcionar.

La primera vía de reparación, si se dispone de un panel como cPanel, suele ser phpMyAdmin. Desde el panel de control se entra en la sección de bases de datos, se abre phpMyAdmin y se selecciona la base de datos donde reside la aplicación de contabilidad. A continuación se listan todas las tablas y se marcan (o se seleccionan todas de una vez), y en el menú desplegable al pie de la página se elige la opción «Reparar la tabla». Esta acción lanza el comando de reparación apropiado en función del motor de almacenamiento (MyISAM, InnoDB, etc.).

Otra opción disponible en cPanel, algo más automatizada, aparece en la sección «Bases de datos MySQL». Allí suele haber un cuadro desplegable bajo el título «Reparar BD» donde se puede escoger la base de datos problemática y pulsar en el botón «Reparar». El panel se encarga de ejecutar las utilidades correspondientes sobre todas las tablas de esa base, lo que simplifica mucho el proceso para usuarios sin conocimientos de SQL.

Para administradores más avanzados, o en servidores donde no se dispone de panel gráfico, la reparación se puede realizar directamente por SSH con la herramienta mysqlcheck. Un comando típico sería:

mysqlcheck –auto-repair nombre_base_de_datos

Esta instrucción revisa todas las tablas de la base de datos indicada y, cuando es posible, ejecuta automáticamente la reparación sobre las que detecta como corruptas. Dependiendo de la configuración del servidor y del tipo de corrupción, puede que sea necesario añadir opciones adicionales o combinar mysqlcheck con otras herramientas del ecosistema MySQL.

En escenarios más críticos, donde la corrupción es severa o afecta a múltiples archivos internos (.MYD, .MYI, .FRM, etc.), puede recurrirse a utilidades de reparación especializadas como SecureRecovery for MySQL. Este tipo de herramientas escanean los archivos corruptos de la base de datos, extraen todos los datos recuperables y los utilizan para reconstruir una nueva versión funcional de la base, que después puede importarse o substituír a la original. Es una vía especialmente valiosa cuando la base de datos soporta una aplicación contable crítica y no hay una copia de seguridad aceptable.

Sea cual sea el método elegido, es importante asumir que no todas las corrupciones se pueden arreglar sin pérdida de datos. En el contexto de la contabilidad, esto obliga a revisar saldos, informes y conciliaciones tras la reparación, y en su caso introducir asientos de ajuste para cuadrar de nuevo la información con la realidad financiera de la empresa.

En definitiva, reparar bases de datos corruptas en aplicaciones de contabilidad exige combinar un buen conocimiento de las herramientas de cada motor (Plesk y mysqlcheck para MySQL, EMERGENCY y DBCC CHECKDB en SQL Server, compactar y reparar en Access) con buenas prácticas de administración: copias de seguridad regulares, pruebas en entornos no productivos y una evaluación cuidadosa del impacto antes de tomar decisiones que puedan implicar pérdida de información. Entender estos procesos y aplicarlos con cabeza puede marcar la diferencia entre un simple susto y un auténtico desastre contable.