|
SQL Server: Cómo reparar base de datos Microsoft SQL Server corrupta con error
Tutorial donde mostramos cómo reparar una base de datos Microsoft SQL Server errónea o corrupta, que no arranca, con error "3456". Indicamos también algunos consejos para evitar errores en SQL Server.
Videotutorial Reparar base de datos SQL Server corrupta que no arranca error 3456 Could not redo log recordA continuación mostramos el videotutorial "Reparar base de datos SQL Server corrupta que no arranca error 3456 Could not redo log record":
Antecedentes y síntomas de la base de datos corrupta o errónea Microsoft SQL ServerA continuación mostraremos cómo reparar una base de datos corrupta Microsoft SQL Server. Microsoft SQL Server es un motor de base de datos avanzado de uso empresarial. Dicho motor es bastante robusto y no suelen producirse errores en él si se siguen las recomendaciones del fabricante y las que indicamos aquí. Averiguar y consultar errores en SQL Server, ficheros de log y visor de sucesosEn el ejemplo que recuperaremos el error se produjo en la base de datos Microsoft SQL Server que la aplicación Veeam Backup & Replication instalar para su funcionamiento. En concreto al intentar iniciar el servicio de Veeam Backup & Replication producía el siguiente error:
El error anterior de Veeam Backup & Replication era debido a que la base de datos VeeamBackup de Microsoft SQL Server tenía un error, para consultarlo accedemos a los ficheros de log de SQL Server que suelen estar en la carpeta:
En esta carpeta se encuentran los ficheros de log de errores y ficheros de traza con información detallada de los posibles errores Abriendo el ficheor SQLDump0001.log podemos comprobar el error que se produce, en nuestro caso Error: 3456
En el visor de sucesos también puede aparecer algún error y su descripción, desde "Inicio" - "Panel de control" - "Herramientas administrativas" - "Visor de sucesos": Buscaremos el error asociado con origen MYSQL$VEEAM (en nuestro caso el nombre de la instancia de SQL Server), pulsando con el botón derecho del ratón y seleccionando "Propiedades" podremos consultar los datos: En las propiedades del error podremos consultar los detalles:
Una vez detectado el error y comprobada la instancia y base de datos en que se produce podremos actuar en consecuencia, como indicamos a continuación. Comprobar servicio de SQL Server y nombre de instanciaTambién es conveniente comprobar el servicio de SQL Server para ver su estado y el nombre de la instancia, para ello accederemos a "Inicio" - "Ejecutar": Escribiremos sevices.msc, pulsaremos "Aceptar": Normalmente el servicio suele tener el nombre "SQL Server (XXX)" donde "XXX" será el nombre de la instancia, si el error no es "grave" el servicio de SQL Server estará iniciado, para ver las propiedades pulsaremos con el botón derecho del ratón sobre él y seleccionaremos "Propiedades": En las propiedades del servicio podremos comprobar el nombre de la instancia y el nombre del servicio MSSQL$VEEAM: En un mismo equipo puede haber varias instancias de bases de datos SQL Server.
Copia de seguridad (backup) de la base de datos Microsoft SQL ServerAntes de realizar cualquier acción sobre la base de datos es muy recomendable hacer copia de seguridad, para ello detendremos los servicios de SQL Server y copiaremos todos los ficheros de datos a una ubicación segura. También podemos hacer la copia de seguridad desde SQL Server Management Studio como indicamos en el siguiente tutorial: También podremos hacer la copia de seguridad con el comando osql como indicamos a continuación: En este otro enlace mostramos con más detalle los métodos para hacer copia de seguridad de una base de datos SQL Server:
Cómo reparar una base de datos Microsoft SQL Server con error 3456, corrupta, que no arrancaEn primer lugar revisaremos los ficheros de log de SQL Server para tratar de obtener más información sobre el error que se pueda haber producido, como indicamos aquí. Una vez revisados los log realizaremos una copia de seguridad de la base de datos, de esta forma podremos proceder con mayor seguridad, como indicamos aquí. Abriremos una ventana de MS-DOS, desde "Inicio" - "Ejecutar": Escribiremos cmd, pulsaremos "Aceptar": Ejecutaremos el siguiente comando para accede a la herramienta de administración de SQL Sever desde la línea de comandos SQLCMD:
Una vez conectados escribiremos la siguiente sentencia SQL para obtener el estado de la base de datos corrupta, en nuestro caso, como hemos visto en los log, veeambackup:
A continuación introduciremos "go" y pulsaremos INTRO para ejecutar la consulta anterior: Nos mostrará la base de datos introducida y su estado, en nuestro caso en estado SUSPECT lo que indica que tiene algún problema, pues el estado normal es ONLINE. Si no sabemos el nombre de la base de datos podemos ejecutar la consulta SQL anterior sin el where para que nos devuelva el estado de todas las bases de datos:
A continuación trataremos de reparar la base de datos en estado SUSPECT, para ello en primer lugar la cambiaremos a estado EMERGENCY con el comando:
A continuación ejecutaremos el siguiente comando para cambiar la base de datos a SINGLE_USER, así evitaremos que los usuarios no puedan conectarse mientras intentamos repararla:
Una vez que tenemos la base de datos en EMERGENCY y SINGLE_USER ejecutaremos el siguiente comando para tratar de repararla:
El comando anterior puede tardar en ejecutarse unos minutos, en función del tamaño de la base de datos a reparar y tras finalizar puede mostrar el warnig (aviso): The log for database 'VeeamBackup' has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files. Este aviso es relativamente normal, nos indica que se ha perdido la coherencia transaccional al realizar la recuperación, en principio es el proceso lógico pues al encontrar ficheros de redo log corruptos ha partido del último válido. Si el proceso se ha ejecutado correctamente volveremos a cambiar el estado de la base de datos a MULTI_USER con el comando:
Comprobaremos el estado de la base de datos para consultar si ha sido reparada con el comando:
Si la recuperación ha sido correcta nos debería aparecer con estado ONLINE: A partir de este momento volveremos a hacer copias de seguridad y a revisar periódicamente los log y tratar de seguir los siguientes consejos para evitar futuros errores o corrupciones en la base de datos.
Recomendaciones para evitar errores en SQL ServerExisten muchas recomendaciones para evitar posibles errores en un motor de base de datos Microsoft SQL Server, muchas de ellas aplicables a cualquier otro motor de base de datos avanzado como Oracle, PostgreSQL, Firebird, MySQL, DB2, Informix, etc. A continuación enumeraremos algunas de ellas:
Artículos relacionados
CréditosArtículo realizado íntegramente por Alonsojpd miembro fundador del Proyecto AjpdSoft. Anuncios
Enviado el Miércoles, 09 julio a las 01:54:46 por ajpdsoft
|
|