El Blog de JuanBO

Un problema bastante común en SQL Server es cambiar el nombre del host (servidor) una vez que está instalado SQL Server. Esto provoca entre otros "daños colaterales" que fallen los asistentes, dejan de funcionar las réplicas, el depurador de Transact - SQL y otros servicios avanzados de SQL Server. La explicación es sencilla, durante la instalación de SQL Server se graba en la base de datos del sistema, master, el nombre del servidor. Este nombre lo podemos consultar a través del la variable global @@SERVERNAME. SELECT @@SERVERNAME Cuando cambiamos el nombre del servidor, estos datos no se actualizan de forma automática, con lo que la información que hay en la base de datos master de SQL Server ha quedado desfasada. Podemos consultar el nombre del host a través de la variable de entorno %COMPUTERNAME% con el siguiente comando DOS. c:\echo %COMPUTERNAME% Solucionar el problema también es fácil, solo debemos ejecutar los procedures sp_dropserver y sp_addserver. En prime

Tim Chapman en Builder Au da una guía para recuperar una base de datos SQL Server mediante el log de transacciones. Aquí una traducción de los puntos más importantes: Muchos DBA (administradores de bases de datos) le tienen pavor a una cosa. Escuchar que tienen que recuperar la base de datos en un cierto punto en el tiempo, especialmente si la base de datos está en producción. Sin embargo, opina que saber hacerlo, es de suma importancia para un DBA, y debe tenerla en su "lista de habilidades". El escenario: Un compañero de trabajo te avisa que ha eliminado accidentalmente datos importantes de la base de datos en producción. Y esos datos deben ser recuperados. Punto 1: Si tienes suerte, tienes un sistema de auditoría de datos que recuperará esos registros de una tabla de auditoría. Punto 2: Si no estás en el punto 1, tienes que usar el log de transacciones, para "deshacer" las últimas transacciones, hasta el momento en que los datos todavía no fueron eliminados.

Este articulo nos muestra la manera de quitar el estado de suspect a una base de dato en SQL Server 2000. Una base de datos puede quedar marcada como suspect por las siguientes razones: Hace falta algúno de los archivos que conforman la base de datos. No se pudo restaurar la base de datos por completoLa base de datos puede estar corrupta El archivo de la base de datos estaba en uso cuando se levanto el manejador. SQL Server no tiene suficiente espacio para recuperar la base de datos al momento de hincar el manejador. Para repara este problema siga los siguientes pasos: Revisar el log de errores del sistema operativo y de SQL Server para tratar de encontrar el motivo por el cuál la b ase de datos quedo en suspect. Levanta SQL Server en modo monousuario. Detener SQL Server Agregar el parámetro –m Iniciar SQL Server Ejecutar sp_resetstatus con el parametro @dbname (ie : sp_resetstatus @dbname = "pubs") Hacer chequeos de consistencia (CHECKDB, CHECKALLOC, etc) Hacer algunos queri