martes, agosto 10, 2010

Instalación de Adventure Works Database SQL Server 2005

AdventureWorks es una base de datos de ejemplo/prueba para utilizar en las versiones de SQL Server 2005, es lo que viene a reemplazar a las antiguas Northwind y/o Pubs Databases.

AdventureWoks no se instala automáticamente con SQL Server, se debe seleccionar al momento de la instalación del motor... si no lo hiciste así entonces la puedes descargar desde el sitio de Microsoft haciendo click acá! En este sitio se encuentran diferentes versiones de AdventureWorks. Las versiones que me interesan son 2 AdventureWorksDB.msi y AdventureWorksBI.msi.

Una vez descargada la Base de Datos, hay que instalarla para lo cual partimos por un simple doble clic en el archivo que descargamos y se lanzará el Asistente de instalación, primera pantalla click en Next.


Aceptamos los terminos y condiciones, click en Next.


Se muestra el directorio de destino en que quedarán instalados los archivos .mdf y .ldf


Comienza la instalación, esto tomara un par de minutos.


Instalación Completada!


Vamos al directorio que nos mostro el asistente y podemos ver que tenemos los archivos: AdventureWorks_Data.mdf y AdventureWorks_Log.ldf


Entonces ahora tenemos los archivos de data y log instalados, sin embargo si consultamos al motor veremos que este no nos muestra la base de datos que nos interesa, para eso ejecutemos la siguiente Query:

SELECT name, dbid, filename FROM sysdatabases

name      dbid  filename
--------- ----- -----------------------
master    1     C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf
tempdb    2     C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\tempdb.mdf
model     3     C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\model.mdf
msdb      4     C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MSDBData.mdf

(4 row(s) affected)

Pero porqué pasa esto si acabamos de instalarla? Efectivamente eso fue lo que hicimos, pero, nos falta un paso muy importante, atachar la base de datos, esto es hacer que el motor la reconozca como tal y sepa en qué archivos dejar la data y qué archivo trabajarlo como log.

Para atachar la base de datos utilizamos el procedimiento almacenado sp_attach_db con el siguiente formato:

EXEC sp_attach_db @dbname, @filename1, @filename2

Donde
- @dbname es el nombre de la Base de Datos
- @filename1 es la ruta del archivo de datos (AdventureWorks_Data.mdf)
- @filename2 es la ruta del archivo de log (AdventureWorks_Log.ldf)

Entonces:

EXEC sp_attach_db
N'AdventureWorks',
N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_Data.mdf',
N'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_Log.ldf'

Command(s) completed successfully.

Listo, ahora deberiamos tener nuestra base de datos AdventureWorks online, para ellos volvemos a consultarle al objeto sysdatabases cuáles son las bases de datos que tiene online:

name           dbid filename
-------------- ---- ---------------------
master         1    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdf
tempdb         2    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\tempdb.mdf
model          3    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\model.mdf
msdb           4    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MSDBData.mdf
AdventureWorks 5    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\AdventureWorks_Data.mdf

(5 row(s) affected)

Excelente! Nuestra Base de Datos ya está online y lista para usarla. Con el archivo AdventureWorksBI.msi utilizado para practicas de Business Intelligence y OLAP debemos realizar los mismos pasos y conseguiremos tener nuestra base de datos de prueba online.

Espero que les ayude de alguna manera a aquellos que no han podido dejar las bases de prueba online, esto va de ayuda a un amigo que me consultó cómo hacer esto.
Saludos

lunes, julio 26, 2010

DBCC CHECKDB Error "8967" en SQL Server 2005

Me topé con este error por primera vez atendiendo a un cliente, el escenario era el siguiente: Windows 2003 Server SP3 corriendo un SQL Server 2005 SP2 apuntando las BD a unos Storages Hitachi, se cambiaron los storages por unos HP, y en la migración de un storage a otro, las BD se corrompieron, ya que migraron sin tener certificada la comunicación entre el servidor y los storages, en consecuencia, fue necesario reparar las 30 BD para poder dejarlas operativas, y lo típico... ni hablar de respaldos.


Ahora tengo que aclarar una cosa, nunca antes había tenido problemas con ninguno de los comandos DBCC, pero esta vez obtenía error tras error, cabe señalar que el Error “8967” solamente lo vas a ver si tu BD está corrupta, es raro pero cierto, y el error obtenido es:

Msg 8967, Level 16, State 216, Line 1
An internal error occured in DBCC which prevented further processing. Please contact Product Support.

 

Ok, analicemos el asunto, CHECKDB utiliza un snapshop de la BD al momento de analizarla y chequear su consistencia, a las páginas de esta “foto” le asigna un LSN (Log Sequence Number) y al chequear la BD debe asegurarse de que el LSN no sea diferente del que se creo en el snapshop, de ser así, esto supondría que la página fue modificada después de que el snapshop fue creado, por lo tanto CHECKDB estaría trabajando con una vista de la BD inconsistente. Cuando CHECKDB detecta esto, se detiene inmediatamente.

Buscando la forma de poder solucionar este problema encontré que se trata de un BUG del CHECKDB el que bajo ciertas circunstancias en que una página de la BD está corrupta la auditoría interna del CHECKDB falla pero el chequeo del LSN se realiza de todos modos, si la corrupción afecta al LSN estampado en el header de la página entonces se gatilla el error “8967”. A continuación adjunto el error que entrega cuando el LSN ha sido corrompido:

2008-05-22 14:55:01.95 spid53   DBCC encountered a page with an LSN greater than the current end of log LSN (31:0:1) for its internal database snapshot. Could not read page (1:143), database [DatabaseName]
 (database ID 15), LSN = (-1:65535:18), type = 255, isInSparseFile = 0. Please re-run this DBCC command.
2008-05-22 14:55:01.95 spid53   DBCC CHECKDB [DatabaseName] WITH all_errormsgs, no_infomsgs executed by [DomainName]\[User] terminated abnormally due to error state 1. Elapsed time: 0 hours 0 minutes 0 seconds.

El error muestra y detalla que no puede leer el Header de una determinada página dentro del snapshop que toma de la BD, cuando llegamos a este punto pensamos que teníamos todo perdido, pero nos quedaban un par de opciones, según Microsoft podemos correr el comando DBCC CHECKDB acompañado de la opción CONTINUE_AFTER_ERROR, esto lo que hará es chequear consistencia de la BD y si encuentra errores seguirá su ejecución. 

Ahora bien, tranquilos, no está todo perdido, este problema es un bug que en determinadas circunstancias el CHECKDB no puede ejecutarse, ya que por defecto se ejecuta con la BD online y fallará en el control del LSN. Una forma de evitar esto es usando la opción WITH TABLOCK del CHECKDB, esta opción realiza un chequeo de la BD offline y por lo tanto no necesita un snapshop.

Después de unos cuantos días viviendo con estos problemas reparando BD y probándolas, logramos restaurarlas en su 100%, las BD siguieron entregando errores de corrupción (8967) pero las consultas ejecutadas sobre ellas respondían sin problemas ni errores.

Vale la pena señalar que este problema es un caso conocido para Microsoft y aún no han conseguido repararlo. (Ver el articulo KB 960791).
Bueno, resumiendo, no se podrán eliminar los errores de corrupción, pero cuando las opciones CHECKALLOC, CHECKCATALOG y CHECKTABLE no entreguen errores de corrupción y el CHECKDB entregue el error "8967" se debería tender a pensar que la BD está reparada, esto basado en que el error se produce SOLO en BD que ya estan corruptas, por lo tanto, nunca dejaremos de obtener ese error aunque tengamos la BD 100% reparada.

Saludos!

miércoles, julio 21, 2010

Bienvenidos

Quiero darles la bienvenida a este blog en donde se busca dar soluciones a problemas cotidianos y ser un espacio para el intercambio de ideas, la resolución de errores y la mejora continua en la administración de nuestras Bases de Datos o proyectos de Business Intelligence.