Los triggers o desencadenadores son disparadores que saltan cuando realizamos la acción o evento al que van asociados. En MS SQL Server, además de los triggers clásicos relacionados con acciones DML (insert, update, delete) que se ejecutan en su lugar (instead of) y después (after triggers), desde SQL Server 2008 (por lo menos) existe otro tipo que son los triggers asociados a acciones que se producen por consultas DDL. Este segundo tipo de trigger está más pensado para labores administrativas como la propia auditoria, para el control de cierto tipo de operaciones e incluso evitar esos cambios.

En un momento dado, alguien puede modificar los datos de una tabla sensible. En otra ocasión, algún despistado puede borrar una tabla, o registros de otra tabla que no debería. Si ese "alguien" se da cuenta y nos lo comenta no pasa nada, como dba seguro que tenemos alguna copia de respaldo para poder recuperar esos datos. El problema lo podemos tener con tablas que no se usan apenas o que alguien ha borrado y no ha confesado. Para poder empezar nuestra búsqueda necesitamos habilitado el seguimiento de cambios. En este post veremos como examinar el contenido del log con una base de datos de prueba..

Para quién no lo sepa, SQL Server Express es una edición gratuita en miniatura de Sql Server. Esta versión está pensada para aplicaciones de escritorio y/o pequeñas aplicaciones web o de servidor. Esta base de datos se puede considerar la versión competidora a la versión gratuita de Oracle (Oracle XE). Ambas versiones están siempre al día y se han ido actualizando con el paso de los años y versiones. De hecho, el lanzamiento de la primera versión Express fue con la versión de SQL Server 2005.

Las vistas pueden ser una herramienta perfecta para simplificar consultas que unen distintas tablas, permiten abstenerse de la estructura origen y simplificar si hace falta la estructura saliente. También nos pueden servir como un mecanismo de seguridad que limitará el acceso de los usuarios a datos no deseados de las tablas base. Con MS SQL Server, Microsoft ha ido un paso más allá y permite crear un nuevo tipo de vistas llamado vista indizada.

Existen algunos tips que permiten mejorar el rendimiento y reducir el tiempo de procesado en nuestras bases de datos de Analysis Services. Hay unas cuantas páginas dedicadas a ello y resúmenes por ahí que marcan unas líneas a seguir (y otras que no!). En este post nombro un ejemplo y de que manera podemos medir esa posible mejora de forma objetiva basándonos en el uso de los contadores de rendimiento del sistema y de Sql Server Profiler.

Bids Helper es un add-in con funcionalidades que complementa y añade nuevas funcionalidades para el desarrollo en SQL Server 2005, 2008, 2008 R2, 2012 usando BI Development Studio. Es un complemento de libre descarga que se mantiene vivo al que se le continúan añadiendo nuevas posibilidades. Su posibilidad de uso abarca desde proyectos de Analysis Services con funcionalidades básicas, proyectos de Integration Services y en menor medida algo de Reporting Services. 

"Waiting for table metadata lock"... Este error nos lo encontramos en MySql al lanzar una consulta del tipo DDL. Se produce normalmente al lanzar una consulta para modificar un objeto que está siendo usado actualmente en nuestra base de datos. Empezaremos a lidiar con él a partir de la versión 5.5 de MySql y a consecuencia de la introducción de un nuevo tipo de bloqueos: "metadata locking".

Siguiendo la línea del anterior post sobre Report Builder 2,0, dejo quizás una última lista de cosas a tener en cuenta y como satisfacer otras necesidades que me he ido encontrado con el tiempo. Cualquier aporte en los comentarios será bienvenido porque yo doy por cerrado mi aportación a este tema.

Mantenerse actualizado es bueno y de vez en cuando va bien probar cosas nuevas que nos puedan permitir mejorar en algún aspecto de nuestro día a día. De vez en cuando me gusta ir viendo nuevas herramientas y tratar de seguir siendo proactivo para hacer mejor mi trabajo o al menos más cómodo. Anteriormente comente en otro post la existencia de un complemento de Apex llamado Refactor que permitía refactorizar para codificar de forma más clara y/o automática. En este post comento un poco el funcionamiento de una herramienta que se llama SQL Sentry Plan Explorer.  

Casi siempre nos enteramos de que alguna query va lenta por alguna queja de usuario. Ahora se queja que hace tiempo aquella cosa que hacía tardaba tanto y hoy cuando lo ha hecho un par de veces la cosa ha sido más lenta de normal.

Realmente puede estar pasando de todo, pero entre las causas comunes podemos encontrarnos de todo un poco: fragmentación en la misma tabla, estadísticas que no están al dia, carga fuera de lo habitual en el servidor en ese mismo momento, incremento del volumen en las tablas implicadas, cambios en la aplicación...