December 2009 - Artículos

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,

Publicado por Percy Reyes | 4 comment(s)

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.

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:

Para SQL Server 2000/2005/2008:              SELECT [name], DATABASEPROPERTYEX( [name],  'Collation') AS collation FROM sysdatabases 
Para SQL Server 2005/2008         :              SELECT name, collation FROM sys.databases 

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,

Publicado por Percy Reyes | 9 comment(s)

¿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.

Publicado por Percy Reyes | 1 comment(s)

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

image 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,

Publicado por Percy Reyes | 3 comment(s)

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,

Publicado por Percy Reyes | 4 comment(s)