BD Sospechosa y SQL Server 2008

Gran puntazo a favor de SQL Server 2008!!! Ya no podemos separar por error o desconocimiento una base de datos en estado sospechoso, os adjunto una captura de un futuro post que estoy preparando: (cómo bien reza, sólo podemos repararla o quitarla (DROP :-)), muhahaha)

Errores en la web

Errores tontos como diría un compañero, que también tiene su blog personal. Petada al canto al intentar ver más vídeos en la peich de JumpStartTV. La verdad es que tiene vídeos interesantes pero la navegación deja mucho que desear.
Seguro que cuando vean la petada al que se le olvidó poner el Try Catch no se le vuelve a olvidar xDDD.

Bueno aún no han corregido el error (13/09/2008) pero la petada ya no es evidente para los demás, parece ser que el Try Catch ha funcionado

Resolución de problemas relacionados con Tiempo de Espera agotado

Buscando y rebuscando en los libros en pantalla (sí no tengo otra cosa mejor que hacer ;-) y os sorprenderíais de la documentación que nos aportan y que mucha gente desconoce), he encontrado la solución que nos aporta Microsoft para solucionar los problemas de tiempo de espera agotado al intentar conectar desde nuestra aplicación contra el servidor que contiene la BD.
A muchos os puede parecer lógico o algo fácil, pero seguro que alguien en algún momento lo ha sufrido y ha tenido que buscar información al respecto (verdad Berni ;-) ).
Bueno no me enrollo más y os pongo el link a los BOL

ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.es/s10de_4deptrbl/html/ad6e3f43-7d0b-4d6c-ab2a-038a5a3b2690.htm

y en internet

http://msdn.microsoft.com/es-es/library/ms190181.aspx

Reconstruir las Bases de Datos de sistema en SQL Server 2008

Más conocido como “Rebuild master”. Para hacerlo debemos seguir los siguientes pasos:

1.- Abrimos una consola de msdos y nos situamos en la carpeta dónde tenemos instalado SQL Server 2008 en nuestra máquina, en mi caso C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Release

2.- Ejecutaremos Setup.exe con las siguientes opciones, si tenemos activado el modo de autenticación usaremos la siguiente sintaxis:

Setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME= /SQLSYSADMINSACCOUNTS=

habrá que sustituirlo por el nombre de nuestra instancia o MSSQLSERVER en caso de que sea la instancia por defecto

son los grupos de Windows o cuentas individuales.

Si tuviéramos configurado el modo de autenticación mixta usaríamos la misma sintaxis añadiendo la opción /SAPWD para especificar la contraseña del usuario SA. Si no lo hacemos nos daría un error.

Si quisiéramos reconstruir las bases de datos de sistema con una intercalación diferente a la usada en la instalación de SQL Server, necesitaremos especificar el parámetro /SQLCOLLATION. Si omitimos el parámetro entonces se reconstruirán con la intercalación que utilizamos en la instalación de SQL Server.

3.- Cuando termine el setup de reconstruir las bases de datos, retornará al prompt sin dar ningún aviso. Si sucediera algún error este se visualizaría en el prompt. En el caso de que no viéramos errores podríamos dar un vistazo al log “Summary”.

4.- Los log se almancenan en \100\setupbootstrap\logs, podemos revisarlo abriendo el fichero Summary.txt

Por supuesto todo esto lo podemos hacer si la necesidad de tener el DVD de instalación, lo tenemos todo en \Binn\templates, por ejemplo la ruta en mi equipo es C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\Binn\Templates. En este directorio tenemos todas las bases de datos del sistema que se copian en el momento de la instalación. Por lo tanto una vez reconstruyamos las bases de datos tendremos que cogerlas de este directorio y copiarlas en nuestro directorio de datos.
Si en este directorio no tuviéramos estas bases de datos al intentar hacer la reconstrucción nos daría un error.

Si no tuviéramos las bases de datos entonces tendríamos que ejecutar la instalación desde el DVD y seleccionar la opción reparar o bien buscar dentro del DVD la siguiente ruta, dependiendo de si es para una plataforma x86, x64 o ia64:
setup\sql_engine_core_inst_msi\PFiles\SqlServr\MSSQL.X\MSSQL\Binn\Template
y copiarlas bases de datos en la carpeta templates de nuestro equipo. Una vez copiadas las bases de datos, ejecutaremos la reconstrucción con la instrucción que os he dado un poco más arriba.

Otro de los aspectos no mencionados en este ladrillazo es lo siguiente, ¿qué pasa con la base de datos Resource? Muy sencillo, la reconstrucción no vuelve a generar una nueva bd Resource (mssqlsystemresource). Para ello tendremos que ejecutar la instalación desde el DVD y seleccionar la opción Reparar.

Vídeos de SQL SERVER

Leyendo diversos post por la red de un lado para otro cuando el tiempo me lo permite he descubierto un site interesante

http://www.sqlservervideos.com/

Tenemos los vídeos ordenados por temática, también podemos verlos por nivel de dificultad, por el tipo de audiencia (DBA, programador, ...), etc. Por el momento son 15 vídeos que imagino irán creciendo con el paso del tiempo.

Pérdida de conexión intermitente entre Windows 2003 Server y SQL Server

Al final se corrobora que no sólo de soft vivimos sino que también tenemos que bajar a los infiernos del hard para solventar problemas extraños que te hacen calentarte la cabeza y discutir con tus compañeros y clientes.

En fin, a los que os pueda surgir este error:
[DBNETLIB]Error general de red. Consulte la documentación de red

Con esta configuración:
Windows 2003 Server con SP2 y SQL Server 2005 con SP2 y equipados con una tarjeta de red modelo NC373i. Como veréis no sólo se puede producir con esta configuración (expongo esta por ser la que me ha originado el dolor de cabeza :) )

La solución que nos aporta Microsoft la tenéis en este enlace:
http://support.microsoft.com/kb/942861

Por supuesto recordaros que si aplicando las recomendaciones que nos ofrece Microsoft no conseguimos solucionarlo, debemos pasar a la acción y comprobar que nuestras bases de datos estén libres de errores de consistencia.

REPAIR_ALLOW_DATA_LOSS y el daño que podemos causar en nuestra BD.

La gran mayoría de las veces que nos enfrentemos a un problema en nuestra base de datos la solución que nos ofrece el comando DBCC CHECKDB será que usemos la opción REPAIR_ALLOW_DATA_LOSS, pues bien, antes de lanzarnos de cabeza debemos tener en cuenta los riesgos que podemos sufrir.

REPAIR_ALLOW_DATA_LOSS es un recurso rápido para poner en funcionamiento nuestra base de datos, el propósito no es guardar los datos de los usuarios, sino recuperar la consistencia estructural de la BD, tan rápido como sea posible de una manera correcta. Pero en este proceso para conseguir la consistencia borrará tanto datos como páginas corruptas.

Imaginemos el siguiente escenario, el DBA de nuestra entidad bancaria no realiza los backups necesarios para preservar la información y recuperarse de un desastre. El servidor sufre un apagón y resulta dañado un disco duro no pudiendo guardar correctamente una página, causando un TORN PAGE. Desafortunadamente en esa página está nuestra cuenta corriente. Como el DBA no dispone de copias de seguridad realiza una reparación con REPAIR_ALLOW_DATA_LOSS. Como resultado de esta reparación la página dañada resulta borrada!!! Y con ella nuestra cuenta corriente y la muchos otros clientes!!! xDDD