Muchas veces me consultan como se puede monitorear a reporting service, por ejemplo como saber cuales reportes son los que mas se ejecutaron, cuales usuarios son los que mas reportes usan, y cualquier otra información de log.

Pues bien SSRS guarda mucha información en su meta data (base de datos de SSRS) y dentro de ella también se guarda información de log, o sea cada vez que nosotros ejecutamos un reporte se guarda información estadística para que luego la podamos consumir.

Aquí les paso un link de un proyecto el cual yo utilizo para levantar esta información y mostrarla en un reporte, el proyecto incluye un paquete de SSIS (SQL Server Integration Service) como así también los reportes en SSRS finales, la verdad que esta muy piola este paquete de utilidades que además son gratis y open :)

Yo esto lo tengo implementado en varios clientes y me ayudo a ver mucha información estadística de los reportes, por ejemplo pude saber cuales eran los menos usados y así luego ver de deprecarlos

Todos conocemos la sentencia Order By de TSQL (Transact SQL), de hecho si necesitamos garantizar un orden el uso del Order By es la única forma de hacerlo.

Ahora bien, en este post nos dedicaremos a mostrar los impactos en la performance si es que no se tienen las cosas de forma adecuada , como así también haremos un best practica del Order By.

El primer paso será mostrar como funciona y sus efectos, para ello crearemos una tabla temporal la cual llenaremos con datos de la tabla “Sales.SalesOrderHeader” de nuestra base de ejemplos Adventureworks

use AdventureWorks2008 
go

create table #t1 (id int)

insert into #t1 values 
(0),(1),(2),(3),(4),
(5),(6),(7),(8),(9)

select * 
into #tablaorder
from 
Sales.SalesOrderHeader 
cross join
#t1

Aquí tenemos una nueva tabla (sin ningún tipo de índices) la cual tiene los registros de Sales.SalesOrderHeader por 10 (para ello hicimos un Cross Join contra una tabla auxiliar)

Bien, ahora lo que haremos es crearle un índice Clúster

create clustered index cl1 on #tablaorder(Salesorderid)
go

Ahora ya tenemos nuestra tabla con un solo índice por numero de orden y que a su vez es Clúster.

Que haremos ahora, pues algo simple, empezaremos a ejecutar consultas contra nuestra tabla, la primera que haremos será sin Ordenamiento y la segunda será con Ordenamiento sobre la columna del índice Clúster, en ambas Querys mostrare el plan de ejecución

select t1.salesorderid from #tablaorder t1
where t1.salesorderid > = 60000

select t1.salesorderid from #tablaorder t1
where t1.salesorderid > = 60000
order by t1.salesorderid 

Como podemos observar en ambos casos el plan de ejecución es el mismo, o sea, aplicar un Order By sobre una columna que tiene un índice no genero mas trabajo.

Ahora lo que haremos es justamente ejecutar una query con un Order By sobre una columna sin índice (por ejemplo OrderDate)

select t1.salesorderid,t1.orderdate
from #tablaorder t1
where t1.salesorderid > = 60000
order by t1.orderdate 

 

Ya aquí podemos observar que se agrego una nueva operación (Sort) la cual representa el 60% de todo el Query Plan, si hacemos la comparativa entre los dos Query Plan (sin Order By y con Order By sobre OrderDate) vamos a encontrarnos con lo siguiente

Aquí podemos observar que del total del tiempo (ambas querys) la segunda y la que contiene el Order By se lleva el 76% lo cual indica que es mucho mas lenta que la primera que no tiene un Order By.

Esto porque se da? pues como vimos estamos ordenando por una columna sin índices, ahora lo que haremos es crearle un índice por OrderDate a la tabla y volver a correr las Querys

create index cl2 on #tablaorder(orderdate)

select t1.salesorderid,t1.orderdate
from #tablaorder t1
where t1.salesorderid > = 60000

select t1.salesorderid,t1.orderdate
from #tablaorder t1
where t1.salesorderid > = 60000
order by t1.orderdate 

Ahora podemos ver que ambas querys tardan lo mismo y que la operación de Sort ha desaparecido gracias al índice que 

hemos creado.

Conclusiones:

El Order By es una sentencia muy útil pero tenemos que tener nuestros cuidados, y aquí viene la parte para reflexionar:

Cuando usamos Order By existe la posibilidad que el usuario cambie el Orden luego? o es importante el Orden en lo que

estamos retornando? pensemos que cada vez que ponemos un Order By podemos estar penalizando el rendimiento si no 

tenemos los índices adecuados y muchas veces los Order By que usamos no tienen sentido ya que se pueden hacer

desde el reporte o la aplicación, entonces no le demos una sobrecarga el motor (vimos que hasta un 60% represento)

si es que no tiene sentido, es mas les cuento que en mi experiencia he resuelto algunos temas de performance en querys

simplemente por eliminar un Order By innecesario, recordemos que los Order By los podemos hacer muchas veces en

la grilla de nuestra aplicación sin castigar al motor de base de datos que es un recurso mas critico, imaginemos una query

con Order By innecesario que la usan cientos de usuarios por día

Aquí le dejo el código script para que hagan sus pruebas

Muchas veces los desarrolladores tenemos la necesidad de consultar datos de la metadata de SQL Server, que es esto de la metadata? pues bien, la metadata es la información que guarda SQL Server en tablas sobre datos como (Stores, tablas, columnas de una tabla, las vistas, el código de los Store, etc.)

Imaginemos que deseamos saber los parámetros que tiene un Store Procedure o bien en que tablas se encuentra una columna dada, o cuales son las relaciones que tiene una tabla, para poder hacer todo este tipo de querys necesitamos consultar esta metadata.

Bien, como lo hacemos, pues hay varias formas , una de ellas es consultas las tablas internas de SQL lo cual no es muy recomendado porque pueden cambiar entre versiones del producto (hasta con la instalación de un service pack) y dejarnos de funcionar nuestras querys, a partir de 2005 se pueden usar las vistas de sistema que son una mejora importante ya que nos dan una capa intermedia de acceso sin acceder directamente a las tablas de sistema, pero solo funciona a partir de 2005.

La otra opción es usar unas vistas ANSI (Standard para aquellas bases de datos que soporten ANSI) llamadas INFORMATION_SCHEMA, estas vistas se encuentran en casi todas las versiones de SQL Server (2000, 2005 y 2008) pero como son ANSI no se puede obviamente consultar todo lo que se puede hacer con las vistas o tablas internas.

Ahora bien, estas vistas ANSI si a los efectos de lo que un desarrollador puede consumir abarcan casi el 90% ya que en todos los motores existen las tablas, las relaciones, las columnas etc., esas cosas que consumimos con frecuencia las resuelven estas vistas ANSI sin mayor problema.

Bien, en este post les voy a mostrar distintas consultas habituales que hacemos como desarrolladores y las resolveré con las INFORMATION_SCHEMA.

 

Consultar información de las columnas de tablas

 

-- TABLAS QUE CONTIENEN UNA COLUMNA

SELECT * FROM INFORMATION_SCHEMA.COLUMNS 
WHERE COLUMN_NAME = 'CUSTOMERID'

Listado de Tablas

SELECT * FROM INFORMATION_SCHEMA.TABLES 

Campos que conforman una PK

SELECT 
   TC.TABLE_NAME, CU.COLUMN_NAME 
FROM 
   INFORMATION_SCHEMA.TABLE_CONSTRAINTS TC 
   INNER JOIN 
   INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU
   ON TC.CONSTRAINT_NAME = CU.CONSTRAINT_NAME 
   WHERE TC.CONSTRAINT_TYPE = 'PRIMARY KEY' 
   AND TC.TABLE_NAME = 'CUSTOMER' -- TABLA 
ORDER BY TC.TABLE_NAME    

Relaciones entre tablas

SELECT 
    FK_Table  = FK.TABLE_NAME, 
    FK_Column = CU.COLUMN_NAME, 
    PK_Table  = PK.TABLE_NAME, 
    PK_Column = PT.COLUMN_NAME, 
    ConstraintName = C.CONSTRAINT_NAME 
FROM 
    INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS C 
    INNER JOIN 
    INFORMATION_SCHEMA.TABLE_CONSTRAINTS FK 
        ON C.CONSTRAINT_NAME = FK.CONSTRAINT_NAME 
    INNER JOIN 
    INFORMATION_SCHEMA.TABLE_CONSTRAINTS PK 
        ON C.UNIQUE_CONSTRAINT_NAME = PK.CONSTRAINT_NAME 
    INNER JOIN 
    INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU 
        ON C.CONSTRAINT_NAME = CU.CONSTRAINT_NAME 
    INNER JOIN 
    ( 
      SELECT 
            TC.TABLE_NAME, CU.COLUMN_NAME 
      FROM 
      INFORMATION_SCHEMA.TABLE_CONSTRAINTS TC 
      INNER JOIN 
      INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU
      ON TC.CONSTRAINT_NAME = CU.CONSTRAINT_NAME 
      WHERE TC.CONSTRAINT_TYPE = 'PRIMARY KEY' 
    ) PT 
    ON PT.TABLE_NAME = PK.TABLE_NAME 
WHERE 
PK.TABLE_NAME = 'SALESORDERHEADER' -- TU TABLA

 

Checks de una tabla dada

SELECT TC.TABLE_SCHEMA,TC.TABLE_NAME,CU.COLUMN_NAME,
CK.CHECK_CLAUSE 
  FROM INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE CU
INNER JOIN
INFORMATION_SCHEMA.TABLE_CONSTRAINTS  TC
ON TC.TABLE_NAME = CU.TABLE_NAME 
AND
TC.CONSTRAINT_NAME = CU.CONSTRAINT_NAME 
INNER JOIN
INFORMATION_SCHEMA.CHECK_CONSTRAINTS CK
ON
CK.CONSTRAINT_NAME = TC.CONSTRAINT_NAME 
WHERE CONSTRAINT_TYPE = 'CHECK'
AND
TC.TABLE_NAME = 'CUSTOMER' -- TU TABLA

Parámetros de un Store Procedure

SELECT *
FROM INFORMATION_SCHEMA.PARAMETERS 
WHERE SPECIFIC_NAME ='ufnGetProductDealerPrice'

Resumen:

Aquí les mostré algunas de las querys que mas usamos los desarrolladores cuando necesitamos consultar la metadata, como podrán haber observado no es nada complejo hacerlo y como en ANSI lo podemos usar en todas las versiones de SQL Server, para cosas mas complejas y quizás mas para administradores DBA es aconsejable usar las vistas de sistema de 2005 / 2008 y en 2000 las tablas de sistema pero para los desarrolladores yo recomiendo las INFORMATION_SCHEMA ya que con ellas cubren casi todas las necesidades y ante cambios de versión de producto no deben actualizar su código.

Les dejo un adjunto con todo el código acá descripto y algunos ejemplos mas

Como todos sabrán en SQL Server Analysis Service (SSAS) por defecto los administradores local del equipo también lo son de SSAS, ahora bien, en muchas empresas esto no es deseable para lo cual queremos que los Admin del equipo no tengan acceso sobre el SSAS.

Este post indica paso a paso de como deshabilitar a los administradores.

· Inicie el SSMS (Sql Server Management Studio)

· Conecte contra el servidor de SSAS (debe tener permisos para poder hacerlo claro)

· Vaya a las propiedades del servidor pulsando el botón alterno del mouse

· Acceda a las opciones de Seguridad y deje ahí solo los administradores del SSAS

Ahora que ha definido a los Administradores del SSAS lo que debemos hacer es deshabilitar a los admin locales, por mas que los hayamos sacado de la opción security también es necesario deshabilitarlo desde las opciones avanzadas, entonces

· Vaya a la solapa general y pulse el botón “Show Advanced (all) Properties”

· Busque ahora dentro de la grilla de opciones la que dice “Security \ BuiltinAdminsAreServerAdmins” y ponga su valor en false

Con esto ya los administradores locales no tendrán acceso a nuestro SSAS.

La tarea de pasar Login entre servidores es algo casi habitual entre los DBA, esta tarea se puede deber a migraciones de versiones, cambios de servidores, etc..

Como todos sabrán SQL Server dispone de dos tipos de Logins, los de Windows y los de SQL.

Bien, como pasamos los logins de un servidor a otro? pues Microsoft ha publicado unos script muy interesantes para estas tareas, uno para SQL 2000 y el otro para SQL 2005 / 2008.

Los Script están muy buenos de verdad pero carecen de una funcionalidad muy importante para mi gusto que es pasar los roles de esos login, pues bien como esta tarea es repetitiva me he tomado el trabajo de modificar estos dos script y agregarle la funcionalidad faltante.

Es importante usar estos Script ya que pasan datos importantes como la Password y el SID, este ultimo asegura que luego no tengamos problemas de usuarios huérfanos

 

Los días 19 y 20 de noviembre estaré dando una doble jornada de 4 horas cada una sobre Reporting Service.

Las mismas son organizadas por el club de usuarios Microsoft de argentina y en las mismas mostraré desde los conceptos básicos hasta el desarrollo e implementación de reportes y features mas Enterprise.

Aquí les dejo el link para la inscripción