Percy Reyes (SQL Server DBA) @ SQL4Junkies.com

MSSQL_ENG003165: An error was encountered while replication was being restored/removed. The database has been left offline

La restauración de un backup de una base de datos replicada sin usar la opción KEEP_REPLICATION a un servidor con metadata diferente de replicación implica trabajos adicionales y posteriores a la ejecución del RESTORE DATABASE como eliminación de metadata diferente de replicación, eliminación de triggers como por ejemplo tr_MStran_alterschemaonly, tr_MStran_altertable, tr_MStran_altertrigger y tr_MStran_alterview (creadas para validar alteraciones de tablas , triggers , vistas replicadas), se desmarca tablas replicadas, eliminación de subscripciones, publicaciones, artículos. Esto lo hace usando sp_restoredbreplication.

Bien, en este proceso de restauración se puede disparar el siguiente error y luego el estado de la base de datos restaurada se establecerá a offline. Si usted restaura el backup mediante un Job entonces sólo verá un mensaje de error en el Job History que no ayuda a solucionar el problema, no da detalles del error, sólo indica que falló el job. Pero si ejecuta la restauración mediante un SQL Query, el mensaje de error será más completo y ayudará a indagar la causa del error. Posibles causas del error está documentado en MSSQL_ENG003165.

Msg 3165, Level 16, State 1, Line 1
Database 'MiDB' was restored, however an error was encountered while replication was being restored/removed. The database has been left offline. See the topic MSSQL_ENG003165 in SQL Server Books Online.
Msg 3167, Level 16, State 1, Line 1
RESTORE could not start database 'MiDB'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

En base a lo explicado anteriormente respecto a lo que SQL Server realiza luego de restaurar una base de datos replicada he encontrado que existe otra causa más para este tipo de errores. Si usted usa DDL database triggers para implementar procesos de auditoria de la actividad en la base de datos (y prevenir eliminaciones/modificaciones de objetos a usuarios no autorizados) es posible que algún trigger esté impidiendo que los cambios posteriores a la restauración sean completadas, por lo tanto, SQL Server disparará el error y ajustará el estado a offline. Los triggers que usted tendrá que remover(o deshabilitar) antes de generar el backup deben ser principalmente los relacionados a eliminación y modificaciones de tablas, triggers, vistas y otros objetos a nivel de bases de datos que sean replicados. Si desea ahorrarse el trabajo, pues deshabilite todos los triggers de auditoria a nivel de bases de datos y luego de restaurar puede habilitarlos. Otra alternativa para solucionar este tema es dejar que la restauración termine con el error y luego manualmente cambie el estado a online. La última alternativa implica que la depuración de configuraciones de replicaciones de la base de datos no se hayan realizado, tome sus precauciones. Espero sirva.

PercyReyes,

Tempdb Integrity Check: DBCC could not obtain a lock on object “id” because the lock request timeout period was exceeded.

Cuando se ejecuta los comandos DBCC CHECKDB, DBCC CHECKALLOC, DBCC CHECKCATALOG, DBCC CHECKTABLE y DBCC CHECKFILEGROUP se creará previamente una instantánea de la base de datos y sobre esta se realizará la comprobación lógica y física de los objetos. SQL Server asegura que esta instantánea sea coherente y luego de usarla la elimina. Con esta estrategia de evitará problemas de bloqueos y operaciones concurrentes cuando esté ejecutándose uno de los comandos anteriores. En el caso que SQL Server no pueda generar una instantánea procederá a ejecutarlo contra la base de datos real, y usará implicitamente la opción WITH TABLOCK para bloquear las tablas y de este manera asegurar que la comprobación sea confiable.

Existen casos donde estos bloqueos no logran concretarse. Hoy nuevamente se volvió a presentar el caso en uno de mis servers (error 5245), y en este post voy a comentarlo puntualmente para la tempdb, pero antes quiero aclarar lo siguiente:

1. Los comandos DBCC CHECKCATALOG, DBCC CHECKALLOC no son aplicables contra la tempdb.
2. En la práctica, ejecutar DBCC CHECKDB contra la tempdb sólo comprobará de la asignación y la integridad estructural de todas las tablas y vistas indizadas (es lo mismo que ejecutar DBCC CHECKTABLE), más no la comprobación de catálogos y estructuras de asignación de espacio en disco de la base de datos.

Durante la ejecución de DBCC CHECKDB (o también de DBCC CHECKTABLE y DBCC CHECKFILEGROUP) contra la tempdb no se creará una instantánea debido a restricciones internas, esto significa que SQL Server debería bloquear las tablas reales de la tempdb, sin embargo, no es garantizado que los bloqueos se lleven acabo y se disparará el siguiente error:

Msg 5245, Level 16, State 1, Line 1
DBCC could not obtain a lock on object 4 because the lock request timeout period was exceeded.

Cuando ejecute DBCC CHECKDB  usted podrá verificar que se trata de intentos de obtención de bloqueos de las tablas del sistema, para esto podemos usar la vista sys.dm_exec_requests donde la columnas command devuelve DBCC SYS CHECK, wait_resource nos indica que se trata explícitamente cuando se inicia la comprobación de la tabla del sistema con id igual a 4, y percent_complete nos dice que el avance de la comprobación actual es cero. Ahora consultando sys.objects, el objeto con id igual a 4  refiere a la tabla sysrowsetcolumns (tabla del sistema).

Para averiguar más detalles del wait_type (modo de bloqueo) y wait_resource (objeto que se intenta bloquear en este caso) podemos usar sys.dm_os_waiting_tasks, con lo cual se comprabará lo dicho anteriormente respecto al recurso.

Bajo este escenario la recomendación sería reiniciar el servicio, o esperar a que el recurso se libere. No siempre es muy recomendable el uso de DBCC CHECKDB y DBCC CHECKTABLE contra la tempdb, aveces esto podría ocasionar pérdidas de datos, opte por reiniciar el servicio en caso de ser factible, pues todo reinicio implica que la tempdb se vuelva a crear, así como también la ejecución interna de DBCC CHECKDB antes de ponerla en estado online. Esta comprobación interna con DBCC CHECKDB se aplica también para todas las bases de datos usuarios existentes y demás bases de datos del sistema (master, msdb, model, distribution). Espero sirva.

PercyReyes,

Petición de SQL Server 2005 SP4 y SQL Server 2008 SP2 …. Not coming soon?

Considero que la realidad pura y dura es que los Cumulative Updates y hotfixes deben ser usados para solucionar problemas puntuales pero al realizar esta actividad el riesgo es alto, debido a esto las empresas no suelen usarlos a pesar de tener problemas, no hay mucha confianza, requiere bastante testing y tienden a ser inestables. El tema es que ha pasado más de un año y Microsoft aún no ha liberado el SP4 para SQL Server 2005 ni el SP2 para SQL Server 2008, y existen problemas críticos que exigen pronta solución segura, estable, y sin riesgos. Recuerdo algunas consultorías donde los clientes me indicaban que sus soluciones de pronto empezaron a ser lentos y fallar, y cuando les preguntaba que es lo último que habían cambiado ellos indicaban que le habian aplicado el último CU o algún otro hotfix (la solución era desinstalarlo), aplicar todo CU o hotfix que Microsoft libera no es una buena práctica. Por estas cosas se está realizando una petición en Microsoft Connect para pedir/solicitar la liberación de dichos Service Packs (al parecer Microsoft anda más concentrado en la liberación de SQL Server 2008 R2 que en asegurar y brindar el soporte de SQL Server 2005 y SQL Server 2008):

Service Pack 4 for SQL Server 2005

Service Pack 2 for SQL Server 2008

Apoyemos esta iniciativa!.

SQL Server Bug: A floating point exception occurred in the user process. Current transaction is canceled

Hoy en el trabajo un usuario reportó un error que se disparaba en su aplicativo que corre sobre SQL Server 2000 SP3a. El error es de aquellos que en cierto modo ya estaba desesperando a los chicos de soporte de aplicaciones, y motivos han de tener pues cuando me escalaron el tema verifiqué que se trataba de un bug en SQL Server 2000. El mensaje de error es el siguiente (seguido de código T-SQL de UPDATE con filtros usando subconsultas el cual no indico por confidencialidad):

Server: Msg 3628, Level 16, State 1, Line 1
A floating point exception occurred in the user process. Current transaction is canceled.

Microsoft sospecha/indica que el problema se presenta cuando se trabaja con consultas INSERT, UPDATE o DELETE que operan en tablas que se hacen referencia a alguna vista indizada donde se puede encontrar una excepción de punto flotante durante la optimización. Para solucionar el problema recomienda actualizar/aplica el correspondiente Service Pack 4 para SQL Server 2000. Decidí no aplicar dicha recomendación y buscarle otra solución, el impacto de aplicar sería demasiado pues el SP4 en mi experiencia me ha dado problemas en temas de replicaciones, y actualmente tengo estos servidores en replicación a entornos SQL Server 2000 y SQL Server 2005.

Revisando un poco más a fondo el tema detecté que el UPDATE que menciono más arriba disparaba un trigger y dentro de ella se disparaba un stored procedure en la cual pude encontrar el trozo exacto de código que era otro UPDATE y donde se disparaba el error. Sospeché que el problema podría ser por daños en la tabla, para ello revisé la integridad física y lógica de las tablas, sin resultados que me indicará algún daño o corrupción. Comprobé una vez más que el DBCC CHECKDB (en SQL Server 2000) no siempre indicaba problemas de integridad.

El paso siguiente era comprobar la funcionalidad de cada columna, para ellos hice operaciones de update para cada columna, y detecté que estaban corruptas las columnas float donde se realizaba un UPDATE. Por lo tanto, no me quedó duda alguna que las páginas de una de las tablas estaban corruptas. Como paso final y para solucionar el problema apliqué un DBCC DBREINDEX(nombre_tabla_afectada) para reordenar físicamente las páginas de la tabla pues tiene índice CLUSTERED. Espero sirva a muchos!.

PercyReyes,

Collations en SQL Server, ¿Es importante?, ¿Cuán importante es?

Hace unos días me preguntaban al respecto: Collation en SQL Server, ¿Es importante? o ¿Cuán importante es?, bueno, después de haberle explicado de manera general decidí compartir algo más con todo aquel interesadoa través de este post. El collation (intercalación) es una propiedad que gobierna/define los estilos de ordenación, comparación de texto y la forma como se almacena y leen los datos de las páginas. El collation que se debe elegir tiene que soportar la configuración de idioma del sistema Windows, y en esta elección ayuda bastante el programa de instalación de SQL Server, pues durante el proceso recomienda el collation adecuado y compatible al sistema windows. El estandard para sistemas en español e inglés recomendado es SQL_Latin1_General*, y siendo más específico el más usado es SQL_Latin1_General_CP1_CI_AS (proporciona compatibilidad con versiones anteriores). De esta propiedad depende muchos resultados de consultas pues define el patrón de bits para cada caracter posible de representar de acuerdo a los páginas de códigos que soporte. Por lo tanto, póngale bastante atención, aunque parezca insignificante para la mayoría de personas, una inadecuada configuración de este tipo puede impactar bastante, causar conflictos de resolución de intercalaciones y hasta podría dejarle sin servicio. 

El collation puede configurarse/ajustarse a varios niveles tanto servidor, base de datos, columnas, y expresiones. A nivel de servidor puede configurarse durante la instalación ó reconfigurarse fácilmente con una o dos líneas de código usando la consola cmd. Para lo demás podemos usar simple T-SQL.  Ahora bien existen tipos de collations: collations  de SQL Server, Windows Collations, Collations binarios. Si el nombre (o etiqueta) del collation empieza con “SQL” entonces estamos hablando de una intercalación de SQL Server, si tiene sufijo _BIN ó _BIN2 será una intercalación Binaria, en caso contrario será una intercalación windows. Más información al respecto usted puede leer lo siguiente: http://msdn.microsoft.com/es-es/library/ms143515.aspx  y tambien sería bueno que revise las directrices para utilizar intercalaciones BIN y BIN2. 

En este mundo es posible que usted desee reconfigurar el collation instalado a nivel de servidor ya sea por equivocación o simplemente estandarización, para tal fin, primero verificar el collation instalado a nivel de servidor SELECT SERVERPROPERTY('collation') o dándole un click derecho en el nodo a nivel de server, pestaña General, item “Server Collation”.  Es importante enfatizar que el collation instalado a nivel de servidor es heredado para todas las bases de datos del sistema, entre ellas las bases de datos model. El collation para cualquier nueva base de datos que se vaya a crear será heredada de la base de datos model (a menos que se indique otro explicitamente) y no del collation a nivel de servidor como lo he leído y escuchado en varios lugares. En fin… sigamos. Sírvase de los siguientes contenidos para reconfigurar su server.

• Reconfigurar collation a nivel de servidor en SQL Server 2000: http://msdn.microsoft.com/en-us/library/aa197950(SQL.80).aspx . durante el rebuild de la base de datos master usted puede indicar el nuevo collation.
• Reconfigurar collation a nivel de servidor en SQL Server 2005: http://technet.microsoft.com/en-us/library/ms179254(SQL.90).aspx ó http://blogs.digineer.com/blogs/jasons/archive/2007/10/18/change-sql-server-collation.aspx 
• Reconfigurar collation a nivel de servidor en SQL Server 2008: http://technet.microsoft.com/en-us/library/ms179254.aspx

Debo dejar bastante claro que este proceso implica prácticamente actividades de reinicios automáticos del servidor, recreación de las bases de datos del sistema, y detachar del servidor todas las bases de datos de usuario. Por lo tanto, luego de terminar, usted tendrá que atacharlas nuevamente, tome sus precauciones!. Es posible que requiera verificar el collation de alguna base de datos, es sencillo: SELECT DATABASEPROPERTYEX('DBInventory', 'Collation'); Si la propiedad AUTO_CLOSE de la base de datos está configurada en TRUE y no existen alguna conexion abierta entonces la consulta anterior le devolverá NULL. Para solucionar el tema usted debe iniciar la base de datos o abrir una conexión, una forma práctica es:

                USE DBInventory
                GO
                SELECT DATABASEPROPERTYEX('DBInventory', 'Collation');

Una vez más AUTO_CLOSE se hace presente con sus cositas, está propiedad es bastante especial anda por donde no se le llama. En este post no hablaremos más de él, por ahora continuemos. Para listar los collations para todas las bases del servidor puede usar:

Por otra parte, también se puede mantener o crear tablas con columnas cuyos collations de cada una puede ser diferente, depende de los requerimientos de negocio. Aquí un granito para que usted se guie al respecto. En este tema deseo aclarar un escenario que si hasta el momento usted no ha tenido oportunidad de trabajarlo, seguro que lo hará pronto. El caso es cuando por ejemplo, usted tiene una base de datos con objetos cuyos collations son diferentes y desea estandarizar el collation usado. ¿Qué hacer?, muchas personas aún piensan que cambiando el collation a nivel de base de datos los objetos contenidos la heredarán. Tenga mucho cuidado, la alteración del collation sólo afectará a las nuevas columnas y/o expresiones más no a las ya existenes, por lo tanto, es necesario realizar el cambio de collation para cada uno de los objetos según se requiera (el mismo concepto se aplica cuando se altera a nivel de servidor). Puede servirse de Setting and Changing the Column Collation para conseguirlo, aunque es obvio que requerirá realizar cambios en cientos o miles de columnas pues para eso puede usar o escribir lo comúnmente usado código que genera código.

Quiero prevenir que cuando vaya a alterar el collation de alguna columna que participa en un índice, PK, check constraints, etc se disparará un error indicándole la dependencia. Para solucionar esto se debe eliminar el índice ó PK, efectuar el cambio de collation, luego recrear lo dropeado. Este caso generalmente lo he experimentando en proyectos de migraciones durante procesos de estandarizaciones de collations, es importante ser detalloso y precavido al manipular cosas a este nivel.

En realidad es muy interesante todo tema relacionado al manejo y estandarización de collations, selección de collations, escenarios diversos y ricos donde se aprende bastante, especialmente cuando deseamos integrar sistemas multi idiomas, o cuando un equipo de desarrollo desea desarrollar sistemas orientados a mercados globales, es asi que Microsoft sigue mejorando las versiones y en SQL Server 2008 se han incorporado 80 nuevas intercalaciones ideales para trabajar sobre Windows Server 2008. También otros collations quedan obsoletos y de deprecian. Más información de estas novedades las puedes revisar en Working with the New SQL Server 2008 Collations and Earlier Versions of the Native Data Provider. Excelente, espero más adelante compartir experiencias más específicas con los que lio en el dia a dia, y su manejo con datos unicode y no unicode. Por ahora, espero que sea suficiente y les sirva.

PercyReyes,

¿Collations obsoletos en SQL Server 2008? o simplemente depreciados?

No es novedad que en SQL Server 2008 han quedado obsoletas algunos collations lo que en teoría significa que ya no deberían existir en dicha versión pero que para Microsoft no necesariamente tiene porque ser así. Estos collations obsoletos son Hindi_CI_AS, Macedonian_CI_AS, Lithuanian_Classic_CI_AS, Cyrillic_90_CI_AS, Azeri_Latin_90_CI_AS, SQL_ALTDiction_CP1253_CS_AS, Korean_Wansung_Unicode y Cyrillic_90_CI_AS. En la práctica he identificado que la mayor parte de ellos están instalados (usables) pero no visibles y  2 collations ya no han sido instalados: Korean_Wansung_Unicode y Cyrillic_90_CI_AS ( yo diría verdaderamente obsoletos).

¿Si dichos collations han sido declarados obsoletos porque fueron instalados?, hasta donde tengo entendido sólo las características depreciadas deberían instalarse por razones de compatibilidad pero cuando algo queda obsoleto significa que ya no debe soportarse, si son obsoletos porqué los instala y permite su uso, o acaso sirven de base para las nuevas versiones disponibles de dichos collations *_100?. Muchas personas al poder utilizar estos collations no visibles pero existentes podrían pensar que aún su uso es garantizado por compatibilidad, una vez más la teoría y la práctica son diferente. Aún este punto no está muy claro .

Existe la función fn_helpcollations bastante útil en SQL Server que  sirve para visualizar la lista disponible de collations (intercalaciones) soportadas. Según Microsoft la peculariadad de esta funciión es que no visualizará collations absoletos que han dejado de ser compatibles o que ya no se instalaron en SQL Server 2008.

Mi recomendación general en estos temas es use sólamente los collations que visualiza la función fn_helpcollations.

SQL Server 2008 R2: Application and Multi-server Management: Utility Control Point (UCP) , Data-Tier Application(DAC)

Con Application and Multi-server Management Microsoft tiene planeado brindar funcionalidades para ayudar a las organizaciones a administrar y gestionar ambientes SQL Server más eficiente y productivamente lo cual permitirá escalar y controlar con mayor visibilidad n-servidores de bases de datos con respecto a utilización de recursos, diagnóstico proactivo de issues de performance, monitoreo de la salud de las bases de datos, etc. Todo debe llevar a reducir costos en administración.

Los nuevos features en Application and Multi-server Management en SQL Server 2008 R2 involucra la llegada de SQL Server Utility Control Point (UCP) o simplemente SQL Server Utility el cual sirve para centralizar la administración de servidores mediante un punto de control donde podremos inscribir las instancias SQL Server que deseemos monitorear. Esta herramienta nos permite definir políticas base de utilización de recursos que servirán como un tabla de control que indicará la capacidad de consumo de recursos de disco y CPU en el tiempo ya sea desdoblado en días, meses o años (se ve algo interesante). Las Dynamic Management Views (DMV) que llegaron con SQL Server 2005 y la Policy-Based Management (PBM) con SQL Server 2008 son los grandes avances que están haciendo posible lo que hoy Microsoft ha empezado llamar como SQL Server Utility dentro del marco Application and Multi-server Management.

Aunque esta herramienta no es una revolución para el monitoreo y administración de servidores de bases de datos considero que es un gran avance y señal que Microsoft está pensando un poco más en ayudar en las tareas al DBA.  En teoría debería ser muy útil, pero hasta el momento lo tomo como una buena iniciativa nada más, pues he trabajado con herramientas de monitoreo obviamente más grandes y poderosas como Idera, Quest Software, Red-Gate, etc. , y la diferencia es obvia. Espero y deseo que dentro de un tiempo no muy largo podamos prescindir de estas herramientas de terceros y la reemplacemos con SQL Server Utility, ya era tiempo de que Microsoft se enfocará en elaborar este tipo de funcionalidades porque sinceramente SCOM (System Center Operations Manager) ya estaba aburrido, es superficial, genérico, y bien básico para monitoreo de bases de datos SQL Server ( sí ya sé que SCOM está orientado a monitorear instancias físicas de productos Microsoft en entornos IT, pero para SQL Server no sirve mucho).

Otra funcionalidad nueva es Data-Tier Application (DAC) que actuará como una simple unidad de despliegue y control de cambios de la capa de datos de aplicaciones, es decir, útil en escenarios donde se desea controlar los cambios efectuados a nivel de esquemas y ciertos objetos (tables, non-clustered indexes, views, functions, logins, y stored procedures)  en desarrollo, cualquier cambio en el esquema debería ser despleguegado y controlado de manera transparente. DAC viene totalmente integrado con Visual Studio 2010. Con DAC vamos a poder (o ya podemos) generar esquemas limitados de nuestras bases de datos con casi cero esfuerzo, entregárselo a los desarrolladores para que trabajen  y estar tranquilos pues cualquier despliegue o cambio será sencillo de sincronizar, DAC no genera scripts para rellenar con informacion las base de datos, sólo trabaja a nivel de estructura. Otro punto interesante es que con UCP también podremos monitorear a nivel de DAC, filtrar la utilización de recursos por aplicación.

La primer limitante de DAC es que no podremos generar scripts de Stored Procedure extendidos, ensamblados, y otros objetos complejos que incremente el riesgo en la seguridad, no todo está soportado, está limitante a la vez se convierte es una ventaja pues es ideal su uso en ambientes SQL Azure Services. En la nube una de las preucupaciones críticas es la seguridad, y es aquí donde DAC ayudaría mucho: Despliegue de esquemas de bases de datos livianos, no complejas, rápidas.

Otra limitante de estas funcionalidades es que estará sólo disponible con SQL Sever 2008 R2 y en su edición Enterprise. Por ejemplo no vamos a poder usar SQL Server Utility para monitorear servidores que no sean SQL Server 2008 R2!, esto hará un poco más lento su adopción pues implica pagar más de 20 mil dolarés por encima de una edición Standard. Pregunta: realmente vale la pena asumir este costo?, yo creo que no, este tipo de funciones deberían estar disponibles desde las ediciones Standard. Este punto al parecer Microsoft va entendiendo  que no todo lo “exclusivo” debería estar en Enterprise y ha dado un buen paso al incorporar en su edición Standard la tremenda funcionalidad de Backup Compression, así es, en SQL Server 2008 R2 Standard Edition ya tenemos Backup Compression!.  

En fin, después de todo podemos justificar las limitantes  de Application and Multi-server Management como un buen inicio, dado que SQL Server 2008 R2 está enfocado en grandes mejoras en BI, todo se está orientando a Self-service BI, SQL Azure Services, y con fuerza se espera la llegada de Self-service Data Storage (en futuras versiones de SQL Server). Veamos que nos traen en la versión final cuya fecha de lanzamiento se corre rumores que será el 06 Mayo 2010.

PercyReyes,

SQL Server Event: Microsoft SQL Server 2008 R2 Application and Multi-Server Management

El día de mañana sábado 19 diciembre a partir de las 15:30 p.m. se llevará acabo un evento orientado a destripar ciertas nuevas funcionalidades que nos trae el  CTP november de SQL Sever 2008 R2. El lugar es la Universidad Ricardo Palma (Av. Benavides 5440 – Santiago de Surco, Lima - Perú) y los temas a tratarse serán:

• “Aplicando Reporting Services con Microsoft Dynamics”  - Juan Rafael
• “Gemini: Self-Service Business Intelligence con SQL Server 2008 R2 y Office 2010” – Jorge Ojeda
• “Microsoft SQL Server 2008 R2 Application and Multi-Server Management”  - Percy Reyes

Las personas que hacen posible este evento indica que para el ingreso a la universidad es necesario que envíen sus nombres y apellidos al siguiente email: comunidadsqlserverperu@hotmail.com .

La charla de “Application and Multi-Server Management” será parecida a la que brindé el sábado 12 diciembre en Trujillo, esta vez también nos sigue persiguiendo la limitante del tiempo, pues contaremos con sólo una hora, sin embargo, aseguro que podremos divertirnos con los nuevos features, los esperamos a todos.

PercyReyes,

SQL Server 2008 R2 November CTP with Master Data Services

Ya se puede ir descargando SQL Server 2008 R2 November CTP con Master Data Services: http://www.microsoft.com/sqlserver/2008/en/us/R2Downloads.aspx , por ahora sólo está disponible para descarga vía subcripción TechNet o MSDN, y a partir del 11 nov para libre descarga. Comparto recursos para información respecto a Master Data Services, y  otro importante recurso es The What, Why, and How of Master Data Management.

Una de las novedades que más me llamó la atención es la llegada de dos nuevas ediciones: Data Center y Parallel Data Warehouse para implementar servidores de bases de datos en respuesta a necesidades de datacenters altamente escalables a nivel de soporte de cientos de Terabytes de data y rendimiento en ambientes OLTP y OLAP, grandes aportes para soportar el fenómeno data explosion. Impresionante las capacidades!, asi como los costos en licencias:

Se observa que los precios de las ediciones Enterprise y Standarda han crecido!, y totalmente justificable con la llegada de nuevas tecnologías como Application and Multi-Server Management, Managed Self-Service Business Intelligence, Master Data Services y StreamInsight Complex Event Processing Technology. Algo más, se ha actualizado la documentación BOL: http://msdn.microsoft.com/en-us/library/ms130214(SQL.105).aspx, bastante información disponible para ir disfrutando de las novedades y creando HOLs y charlas.

El caso de sp_depends desde SQL Server 6.5, su legado hasta SQL Server 2005/2008 y un sin sabor hasta la fecha

¿Quién no ha usado sp_depends para recuperar información de dependencias de objetos de bases de datos?, creo que casi toda persona que en algún momento de su vida ha trabajado o trabaja con SQL Server, especialmente en temas de desarrollo o soporte donde es casi frecuente su uso. ¿Quién dice yo no?. El punto es que el procedimiento almacenado del sistema sp_depends no devuelve resultados correctos, no es confiable tanto en SQL Server 2000 como en las versiones 2005 y 2008, el caso es más frecuente para bases de datos que se van migrando en el tiempo. Existen situaciones donde podría funcionar y es cuando creas objetos desde cero en la versión que uses, existen otras que no, simplemente indica que no existe alguna dependencia (después de migraciones).

Y por qué es tán importante que la información de este tipo sea confiable?, pues ayudaría a atender requerimientos como estos:

• Realizar cambios en ciertos objetos de bases de datos(como tablas, columnas) y deseas saber dónde estos objetos están siendo referenciados, y de esta manera reducir el riesgo de desplegar cambios parciales.
• Medir el impacto de nuevos desarrollos que implican cambios en objetos de bases de datos, las cuales deben integrarse a los que ya tenemos en producción, y tal vez también necesitemos programar cargas masivas y evitar problemas de rendimiento y bloqueos.
• Mejorar la rapidez del servicio de soporte, saber en que objetos impactará el cambio, por ejemplo, del tipo de dato de una columna. 

A veces incluso, en el caso de procedimientos almacenados de usuario, tenemos que modificarlo moviendo una que otra línea para que las referencias de algunas dependencias se actualicen, y no sabes si va funcionar. En SQL Server 2000 no tienes alternativa para solucionar el tema. En SQL Server 2005 apareció sys.sql_dependencies  que en realidad tampoco es confiable porque lee de la misma tabla del que se sirve sp_depends, esta tabla es sysdepends la cual suele andar desactualizada o actualizarse incorrectamente, no sirve. Discúlpenme pero ya hace muchos años atrás que le he pérdido confianza a este señor sp_depends, además ya está depreciada, sin embargo, la solución no es migrar, Microsoft debería hacer algo para mejorar sp_depends en SQL Server 2000 y SQL Server 2005, y sys.sql_dependencies en SQL Server 2005 y SQL Server 2008.

En SQL Server 2008 tenemos alternativas que sí funcionan muchísimo mejor, podría decir que son confiables(aunque tienen su propias odiseas como esta: http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=331830). Las alternativas son sys.dm_sql_referenced_entities y sys.dm_sql_referencing_entities, sql_expression_dependencies y podemos adicionalmente apoyarnos de sys.objects para conseguir cualquier información de dependencia entre objetos de bases de datos.  El tema aquí es que estas vistas no leen de sysdepends sino la información de dependencia se consigue bajo demanda, es decir es dinámico. Ahora, por ejemplo, si nosotros deseamos saber cual son las dependencias desactualizadas o incorrectas podriamos conseguirlo con algo sencillo:

SELECT OBJECT_NAME(referencing_id) 
FROM sys.sql_expression_dependencies  
WHERE referencing_id NOT IN (
                                                 SELECT id 
                                                 FROM  sysdepends 
                                                )

Cuando realmente es urgente contar con información confiable acerca de dependencias de objetos es donde recién te pones a pensar porque Microsoft no se preocupó mucho antes en mejorar estas funcionalidades en SQL Server 2005 y versiones menores, claro que SQL Server 2008 trabaja bien con estos temas, pero no soluciona los problemas, se tiene que hacer cosas como esto Keeping sysdepends up to date in SQL Server 2008 , lo cual por cierto también es limitado. Es evidente que aún sigo descontento, pero la necesidad de manejar dependencias entre varios miles de objetos, cientos de bases de datos entre muchos servidores, y saber que podría faltar algo actualizado obviamente aún me deja un sin sabor hasta la fecha.

PercyReyes,

¿Envío los e-mails directamente desde el aplicativo o usando SQL Server (SQL Mail/Database Mail)?

Un tema no tan discutido en foros y otros lugares es con respecto a que opción utilizar para enviar e-mails en nuestras aplicaciones, la pregunta sería ¿Envío los e-mails directamente desde el aplicativo o usando SQL Server?. Compartiré mi opinión al respecto en función a mi experiencia como DBA.

El envío de correos directamente desde el aplicativo implica riesgos en seguridad y rendimiento, esto significa que se requiere manipular objetos propios del lenguage (crearlos, gestionar su uso, eliminarlos programáticamente), tareas que están demás mencionar que a nivel de base de datos no es necesario.

Dependiendo del lenguaje de programación que utilices, unos podrán conectarse directamente al servidor de correo y enviar síncronamente, lo que implica que el usuario estará esperando a que el aplicativo haya podido establecer conexión satisfactoria al servidor y luego recibir resultado del envio(fallido o exitoso), este tema podría afectar el rendimiento de las aplicaciones, además se hace complicado, y menos confiable. En escenarios donde el rendimiento de las aplicaciones es crítico no se puede arriesgar de esta manera. Existen otros tipos de lenguajes que requieren el uso de outlook, mantener abierto el outlook sería un factor determinante para que el envio se realice. Desde que apareció la posibilidad de enviar correos através del sistema de envío de correos de SQL Server, Oracle, … ésta se convirtió en primera opción. En proyectos de upgrades de aplicaciones y servidores de bases de datos siempre hemos migrado al uso de SQL Mail o Database Mail por beneficios en seguridad, rendimiento y confiabilidad.

No creo que la lógica de negocio sea un factor determinante para escoger que opción de envio de correo utilizar, más bien, aquellas aplicaciones que trabajan (o trabajaban) con datos almacenados únicamente en archivos con formato plano, excel, access, XML, etc no tendrían más opción que enviar correos directamente desde el aplicativo, este sería un escenario, pero si su aplicativo trabaja con un servidor de bases de datos como SQL Server entonces es recomendable usar SQL Mail (en SQL Server 6.5,7.0, 2000) o Database Mail (SQL Server 2005 y 2008), y aunque existen muchas empresas que aun no han migrado a SQL Server 2005, o SQL Server 2008, en SQL Server 2000 el servicio SQL Mail también es completamente útil. Claro, no vale olvidar que ciertas configuraciones de estos servicios pueden volverse algo complicados dependiendo del escenario, como por ejemplo, configuración de SQL Mail con un servidor Lotus, o SQL Mail con versiones de outlook como 2000/2003 que (a veces) requiere paciencia,  configuraciones de Database Mail a un servidor SMTP de confianza en otro dominio, o puede darse el caso que todo se complica debido a problemas relacionados al firewall y configuraciones de seguridad, etc. Como toda configuración, considero que estos problemas nunca faltan y son experiencias que te aportan mucho.

Enviar correos mediante el servicio Database Mail es un solución avanzada y muy ventajosa, además de ser más práctica y sencilla (aunque complicado muchas veces), flexible, es más rápido, no impacta en la performance de las aplicaciones debido a que el envio es  asincrono, existe un proceso aislado que se encarga de encolar, gestionar,  y enviar los correos en segundo plano mediante Service Broker. Está demás decir que es escalable, seguro (uso de SSL), Database Mail se conecta directamente a uno o varios servidores SMTP para asegurar su envío, y no requiere de un cliente con MAPI extendida (aunque en SQL Mail si es necesario). Vale mencionar características intrinsicas en Database Mail : el envío de correos es auditable, y compatible con HTML!. El envio de correos mediante el aplicativo no cuenta todas estas funcionalidades que te brinda SQL Mail y/o Database Mail.

La tendencia respecto al tema es utilizar SQL Mail o Database Mail(preferible en SQL Server 2005/2008) . Por lo tanto, el factor determinante debe medirse en función a rendimiento, seguridad, confiabilidad y escabilidad. Espero sirva!.

PercyReyes,

SQL Server Monitor Gadget

Si deseas monitorear alguna base de datos mientras esta crece, entonces este gadget es ideal. Interesante gadget útil para monitorear sólamente los archivos data y log de una base de datos alojados en una instancia local. No proporciona funciones de monitoreo remoto.

SQL Server Monitor Gadget for Windows Vista Sidebar

http://consultingblogs.emc.com/jamiethomson/archive/2007/08/09/Announcing-SQL-Server-Monitor-Gadget-for-Windows-Vista-Sidebar.aspx

Otra limitación de este gadget es que sólo puede monitorear una sóla base de datos a la vez. Sería interesante que pudieramos instalar varias copias de este gadget en una misma PC, y así monitorear desde el escritorio todas las bases de datos que tengamos disponibles localmente.

Esperemos una siguiente versión donde se extienda sus funciones, mientras tanto, sigamos usándolo.

PercyReyes,

The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service

Por temas de seguridad en toda compañia se adoptan politicas con respecto a la cuenta usada para ejecutar el motor de base de datos, una de estas políticas es cambiar la clave de la cuenta cada cierto periodo, este periodo podría variar entre 1 a 3 meses. Otra buena práctica es no usar esta misma cuenta para ejecutar los servicios de bases de datos en entornos de soporte, desarrollo o pruebas, es su lugar, es recomendable, pero muy recomendable, utilizar cuentas diferentes a los usados en producción, y cada servicio debe estar configurado con una cuenta distinta con privilegios cero, y dejando que SQL Server Configuration Manager asigne automáticamente los permisos necesarios a la cuenta para que los servicios se ejecuten correctamente.

Un alto riesgo cuando se usa una misma cuenta en entornos de producción y pruebas es por ejemplo cuando cambiamos la clave de la cuenta y se nos olvida aplicar este cambio para algún servicio de cualquiera de los ambientes de pruebas. Aquí el riesgo es que algún servicio a cuya cuenta no se aplicó el cambio de clave podría estar tratando de autenticarse en Active Directory y llegando finalmente a bloquearse, esto originará mal funcionamiento de algunos componentes de SQL Server como es el caso de las replicaciones. Y si por leyes de Murphy, en dicho momento, hubiere problemas de energía eléctrica y el servidor llegara a reiniciarse entonces los servicios de producción no podrán iniciarse, y cuando esto pase, el impacto podría crecer conforme mientras el tiempo pase y usted no encuentre la causa. En compañias donde la operación es 24x7 estos temas es demasiado crítico.

En este escenario, tendríamos que la cuenta usada para correr el servicio estaría bloqueada y quedando inhabilitada para registrar el SPN del servicio correctamente, y si revisamos el log de errores en Windows podremos visualizar el siguiente texto:

The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

Una de las causas de este error es porque la cuenta está bloqueada. En mi experiencia aconsejo ser muy cuidadoso en estos temas, es semejante lo que uno tiene que soportar cuando existen este tipo de errores que tendremos que saber enfrentar. Algunas otras recomendaciones para evitar este tipo de incidentes graves son:

• Realiza un inventariado de los servicios de bases de datos instalados, y averigua que cuenta utilizan.
• No confies en la información que te proporcionan, realiza un escaneado en la red para detectar otros posibles servicios huérfanos que podrian estar ejecutándose con la misma cuenta usada en producción.
• Realiza un checklist de los servicios de bases de datos y diferéncialos por las cuentas que utilicen.
• Cuestiona y mejora las politicas de seguridad aplicadas para las cuentas que ejecutan los servicios de ambientes de producción. El objetivo aquí como auténtico DBA es asegurar la continuidad del negocio, garantizar la operatibilidad de los servicios de bases de datos.

Es muy importante como DBA siempre andar alerta, ser ordenado, manejar checklists, documentarlo todo y mejorar planes de contingencias. Espero les sirva estas recomendaciones, y le ahorre tiempo al diagnosticar problemas de este tipo.

PercyReyes,

The Forrester Wave: Enterprise Database Management Systems, Q2 2009

Interesante documento que nos da una excelente visión del estado del mercado actual de las bases de datos en el mundo empresarial.  Forrester como siempre se ha tomado el trabajo de evaluar las potencialidades y debilidades de los más críticos DBMS. Es genial saber que 27 billones de dólares mueve este mercado a nivel mundial tanto en licencias, soporte, consultoría y servicios, este número espera crecimientos exponenciales gracias al fenómeno de la Data Explosion que ya estamos viviendo y a las nuevas necesidades que vendrán con ella.

Desde la llegada de SQL Server 2005 Microsoft ha crecido bastante, y ésto continúa con la liberación de SQL Server 2008, Microsoft está calificado como el competidor más agresivo en este mercado, mejor estrategia, y se le rescata sus features en programación, alta disponibilidad, seguridad, y por supuesto en integración de datos, este campo nadie va negar los grandes avances y reconocimientos para Microsoft. Comparte el liderazgo con Oracle e IBM DB2 for LUW, productos que están bien posicionados por sus excelentes features, no hay duda.

En resumen:

Microsoft: Te most aggressive DBMS vendor with a strong road map
IBM DB2 for LUW: A strong database ofering with good momentum.
Oracle: Te most comprehensive set of database features and functionality.

Dejo el documento para que lo disfruten, realmente interesante: Enterprise Database Management Systems, Q2 2009

Enjoy,

PercyReyes,

FIPS 127-2 asesinado!, y quien le sigue será SET FIPS_FLAGGER?

Me entero en SQLServerCentral.com que FIPS 127-2 ha sido anulada (motivos?, aún no lo sé), sin embargo, aún no ha sido depreciada la sentencia SET FIPS_FLAGGER  en SQL Server 2008  ni en SQL Server 2008 R2 CTP Agosto, el cual sirve para comprobar el cumplimiento del estándard SQL 92 especificado por FIPS 127-2. FIPS es el estándar federal de procesamiento de información desarrollado por el gobierno de Estados Unidos, cuyo uso está en el desarrollo sistemas de tecnologías de información para el gobierno de EEUU o Canadá. El impacto de la anulación de FIPS 127-2 está relacionado a temas de testing por parte de empresas y contratistas que desarrollan manejadores de bases de datos para el gobierno EEUU o Canadá.

Como ya lo mencioné, esta validación de FIPS 127-2 en SQL Server está implementada por la instrucción SET FIPS_FLAGGER. Al utilizar SET FIPS_FLAGGER el mensaje de advertencia de imcumplimiento tiene el siguiente formato:

FIPS Warning: Line %d has the non-ANSI clause '%ls'.

Usted también puede usarlo para detectar código no ANSI durante los procesos de revisión de calidad de programación con T-SQL. Ejemplo:

SET FIPS_FLAGGER 'FULL'
SELECT TOP 1 localname, internalnumber
FROM  dbo.af_mst_pro
WHERE afe='PE519AD0803'

Ahora FIPS_FLAGGER nos advierte que estamos usando código non-ANSI.

FIPS Warning: Line 1 has the non-ANSI statement 'SET'.
FIPS Warning: Line 2 has the non-ANSI clause 'TOP'.

Es evidente que no podemos dejar de usar cosas non-ANSI (a pesar de su impacto en la performance, portabilidad, interoperabilidad y otros temas…), pero nos ayudará averiguarlo donde lo estamos haciendo (en el caso que usted no sepa que instrucción es ANSI y que es no-ANSI) y poder nosotros decidir. Adicionalmente recuerde que las sentencias non-ANSI tienden a ser depreciadas y discontinuadas conforme van saliendo al mercado nuevas versiones de SQL Server.

Existen algunas preguntas que aún no puedo responderme. ¿cuál será el nuevo estándard a comprobar? , aparecerá un nuevo FIPS que valide el último estandard SQL?… por ahora no hay nada a la vista. Qué hará Microsoft ahora?, depreciará la instrucción SET FIPS_FLAGGER?.

enjoy!,

PercyReyes,

SQL Server 2008 R2 BOL CTP August 2009 y SQL Server 2008 BOL July 2009

Como ya lo dije por twitter, la documentación de SQL Server 2008 R2 CTP Agosto es nula, de pronto te instalas el R2 y te metes a buscar cosas en el BOL para que sólamente te enteres que anda vacío. La buena noticia es que ya tenemos disponible la documentación completa del CTP Agosto de SQL Server 2008 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c18bad82-0e5f-4e82-812b-5b23e5d52b9c , el cual actualiza lo siguiente:

• Instrucciones de setup y migración.
• Información de nuevas características y compatibilidad con versiones anteriores.
• Descripción conceptual de tecnologías y características de escalabilidad en SQL Server.
• Tópicos y procedimientos que describen como usar las diferentes y variadas características de SQL Server.
• Tutorial que te guiara a través de tareas diarias y comunes.
• Referencias, documentación con herramientas gráficas, utilerías de línea de comandos tipo Power Shell, lenguajes de programación e interfaces de programación (APIs) que son soportadas por SQL Server.
• Descripción de bases de datos de ejemplo  y aplicaciones disponibles en esta nueva versión de SQL Server.

Esta instalación actualizará el BOL de SQL Server 2008, por lo tanto, se recomienda que usted trabaje con SQL Server 2008 R2 CTP en un máquina virtual. Algo más, Microsoft también ha publicado la última actualización del BOL de SQL Server 2008 (Julio 2009): http://www.microsoft.com/downloads/details.aspx?familyid=765433F7-0983-4D7A-B628-0A98145BCB97&displaylang=en .

Enjoy!,

PercyReyes,

Cumulative Update #5 para SP3 de SQL Server 2005

Microsoft ha liberado el CU #5 para SP3 de SQL Server 2005: http://support.microsoft.com/kb/972511. Sólo recomiendo aplicar este CU en los casos que sea realmente necesario y se justifiuqe, es decir, cuando alguno de los problemas que se soluciona con este CU sea crítico para usted. Si usted ha decidido aplicar entonces no olvide validarlo en un ambiente de pruebas porque le podria suceder algo parecido a este desastre http://blogs.msdn.com/psssql/archive/2009/08/18/sql-server-cumulative-update-or-service-pack-fails-with-create-database-failed.aspx, caso contrario, espere el SP4 de SQL Server 2005, el cual Microsoft aún no ha revelado fecha.

Mucho cuidado que al instalar este CU se requiere habilitar SMO y XP DMO, las cuales aumentarán la superficie de ataque, por lo tanto no olvide de deshabilitarlos en cuanto termine la instalación. Entre los problemas más comunes que soluciona este CU tenemos:

• Al restaurar una base de datos de SQL Server 2000 mediante SQL Server 2005 Management Studio o SQL Server 2008 Management Studio: "no se puede mostrar el cuadro de diálogo solicitado. Error al recuperar datos para esta solicitud (Microsoft.SqlServer.SmoEnum)"
• La ejecución del comando "xp_readerrorlog" en SQL Server 2005 se bloquea y consume recursos de CPU
• Se produce un problema de rendimiento al ejecutar una consulta utilizando un cursor de avance rápido en SQL Server 2005

Sobre todo el primer error listado arriba es muy conocido cuando se usa SQL Server 2005 Management Studio (9.00.4220 a 9.00.4228), pero por fín ya se terminó la maldición je je je para aquellos DBAs que aún convivimos o administramos algunos servidores en SQL Server 2000 usando la herramienta de cliente de SQL Server 2005/2008. Más información técnica están invitados a revisarlo aqui: http://support.microsoft.com/kb/972687/ . En el caso que usted esté trabajando con SP2 de SQL Server 2005(9.00.3325 a 9.00.3329)  y experimente el primer error entonces podria aplicar este CU: http://support.microsoft.com/kb/972510

Espero que con la llegada del SP4 no se termine el soporte para SQL Server 2005, bueno al parecer todavía tendremos SQL Server 2005 para un buen rato más.

Enjoy!

PercyReyes,

Disponible el CTP de Microsoft SQL Azure!

Señores:

Listo para empezar a divertirse, ya está disponible el tan esperado CTP de SQL Azure: http://msdn.microsoft.com/en-us/sqlserver/dataservices/default.aspx  quedan todos invitados a subirse a la nube!.

Ya estaré contándoles mis penas y alegrias con este servicio.

Saludos,

PercyReyes,

SQL Server 2008 R2 August CTP disponible para todo el planeta!

Desde hace unos minutos ya está disponible Microsoft SQL Server 2008 R2 August CTP para su libre descarga!!!

http://technet.microsoft.com/en-us/evalcenter/ee315247.aspx 

enjoy!,

Se acaban los tipos de exámenes skill-based de Microsoft ;)

… y llega la nueva modalidad de exámenes de certificación basados en rendimiento (performance-based) el cual permitirá filtrar y certificar habilidades con problemas simulados del mundo real y no sólo teórico. Para esto se usará tecnología de virtualización para crear ambientes que tendrán problemas que deberán ser solucionados durante la evaluación.  Invito a leer el post de Brian Egler donde se detalla el tema: http://www.networkworld.com/community/node/43418 … me apunto para rendir más exámenes de administración con SQL Server!!! :D,

Enjoy!,

PercyReyes,