November 2009 - Artículos - Percy Reyes's Technical Blog

November 2009 - Artículos

SQLServer 2008R2ctpnov

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:

pricing SQL 2008 r2

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.

Publicado por Percy Reyes | 5 comment(s)

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

Publicado por Percy Reyes | 4 comment(s)