Para aquellos que les interese conocer cada uno de los protocolos y esquemas en cada servicio de SQL Server 2008, Microsoft hace unos días publico estos excelentes documentos técnicos.

Se los recomiendo de verdad, muy buenos

En el mes de febrero de 2010 realice dos webcast en los cuales he presentado las novedades que trae Reporting Service en su versión 2008 R2.

Aquí les dejo los links a cada video como así también los ejemplos y material de los mismos

 

Novedades en SSRS 2008 R2 parte 1

Novedades en SSRS 2008 R2 parte 2

 

Hace un par de días Microsoft libero todo un kit de entrenamiento para SQL Server 2008 R2.

Recordemos que esta versión esta en beta y tiene fecha de lanzamiento año 2010.

El kit esta muy bueno ya que contiene muchos ejemplos, HOL, PPT y demos con muchas de las novedades de esta nueva versión de SQL Server

Aquí les dejo el link de acceso a la descarga del mismo

Ya esta disponible el nuevo CTP de la próxima versión de SQL Server (SQL Server 2008 R2).

Aquí les dejo el link

El Clustered Index es uno de los índices mas importantes que tenemos, y una de sus razones es que solo podemos disponer de uno por tabla y todo tipo de consultas que utilicen rango de valores serán muy beneficiadas por este tipo de índices.

Ahora bien, por defecto cuando creamos una Primary Key se genera de forma automática por esos campos el Clustered Index de nuestra tabla.

Muchos desarrolladores que hacen diseños de tablas prestan poca atención a este detalle. En este Post vamos a analizar los impactos de performance que podemos tener con solo el hecho de no definir de forma adecuada nuestro CLustered Index.

Si creo una tabla (o la modifico) desde el modo de diseño, cuando agregue una primary key veremos una ventana como la siguiente

Aquí podemos observar que la opción de “Create as Clustered” esta en Yes para nuestra Primary Key.

También sucede lo mismo si lo hacemos vía código como muestra el siguiente ejemplo

use tempdb 
go

drop table movimientos
drop table articulos
drop table numeros
drop table fechas

create table movimientos (id bigint identity PRIMARY KEY,
                          articulo varchar(50),
                          fecha datetime,
                          cantidad int
                         )
go 

sp_help movimientos

Bien lo que haremos ahora es crear una tabla similar a la anterior pero que la primary key no sea el Clustered, porque? porque en mi tabla de movimientos las consultas de rango son de fecha a fecha y no de ID, con lo cual si pongo un indice CLustered para este tipo de consultas voy a mejorar su tiempo de respuesta.

Para ello primero creamos una copia de movimientos con SELECT INTO para no copiar índices

select * 
into movimientos2 from movimientos 

Ahora crearemos el indice Clustered por la columna Fecha y un indice Non Clustered por ID

create clustered index ix3 on movimientos2(fecha)
create index ix4 on movimientos2(id)

También le vamos a crear a la tabla movimientos un indice por fecha ya que no lo tenia pero en este caso será en Non Clustered

create index ix2 on movimientos(fecha)

Con el siguiente código veremos como han quedado cada una de estas tablas con relación a los índices

exec sp_helpindex movimientos
exec sp_helpindex movimientos2

Aquí podemos observar bien que ambas tablas tienen índices por los mismos campos solamente con la diferencia del Clustered que en la segunda lo hemos puesto por fecha ya que es una tabla la cual sus querys son muy usadas por ese campo y en rangos (una clásica tabla de movimientos)

Bien, ahora lo que haremos es ejecutar una query en ambas tablas (la misma Query) y ver los resultados del Query Plan

 

select articulo 
from movimientos 
where fecha >= '20091101'
and fecha < '20100101'

select articulo 
from movimientos2
where fecha >= '20091101'
and fecha < '20100101'

Como podemos observar el primer Query representa un 94% del tiempo total de ambas ejecuciones y el segundo un 6%, siendo este ultimo mucho mas performante.

Aquí podemos  ver lo que ha sucedido con solo el hecho de aplicar el clustered a la columna adecuada, y como mensaje: es muy pero muy importante definir bien el Clustered , este post esta destinado a mostrar que dejarlo por Defecto no es una buena idea y que cada tabla debería tener un estudio de que columnas deberían ser el Clustered Index

Aquí también les dejo el Script completo para que puedan jugar con el mismo y ver los resultados.

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

El día sábado 26 de septiembre se desarrolla uno de los eventos mas importantes del año, el famoso CodeCamp.

Este evento se caracteriza por tener una variedad de temas muy interesantes sobre las tecnologías Microsoft.

En el mismo yo seré orador brindando una conferencia sobre como hacer reportes con Reporting Service 2008 R2, aquí mostrare desde los conceptos básicos hasta las novedades que trae esta nueva versión del producto, como siempre lo hare todo en vivo y con muchos ejemplos usando solo los power point para presentación.

Los espero, y para aquellos que no puedan ir aquí en mi blog publicare el material como así también el link a un video de presentación.

El día viernes 28/8/2009 di el siguiente webcast donde he mostrado alguna de las novedades de SQL Server 2008 a nivel Transact SQL ( Merge, Grouping Set, Row Contructor , etc)

Aquí les dejo el material y el link al video.

El otro día en una reunión de amigos surgió la pregunta sobre como se hacen análisis de tuning o que herramientas hay para poder hacer parte de esta tarea.

La idea de este post es poner una serie de programas free con sus respectivos links las cuales yo utilizo para analizar SQL Server y son de mucha utilidad.

 

Aquí vamos

ClearTrace

Esta herramienta es una de mis favoritas, nos permite luego de generar las trazas con el profiler del SQL Server hacer todo un resumen de las mismas.

Los puntos buenos que tiene a mi gusto es que resume las querys y si por ejemplo tengo tres procesos que son la misma query o mismo store pero con distintos valores en los parámetros lo veremos todo en uno solo.

Los análisis que se pueden hacer con esta tool son muy buenos de verdad y por ejemplo podemos sacar Reads, Writes, CPU, Duración,etc..

PAL

Esta es una excelente herramienta para analizar los contadores del Windows Performance. La misma tiene bastantes funcionalidades hasta la opción de generar todo un reporte final con los counter.

PSSDiag

Una de mis favoritas, permite recolectar distinta información de nuestro SQL 2000 o 2005 de una forma muy simple.

SQL Nexus

Esta herramienta nos ayuda a analizar los datos recolectados por el PSSDiag o SQLDiag

SQL DMVStats

Esta herramienta funciona con SQL 2005 o 2008 y nos permite recolectar información de las famosas DMV y guardar los resultados en una base de datos, lo cual podemos luego hacer cualquier tipo de análisis.

SQL Server Best Practice Analyzer

Utilidad indispensable, nos permite analizar las malas practicas de un servidor SQL Server (tablas, querys, triggers, backups, seguridad, etc)

Hay dos versiones, la 1.0 para 2000 y la 2.0 para 2005

 

SQL Server 2005 Performance Dashboard Reports

Esta serie de reportes son EXCELENTES, utilizan como fuente de datos las DMV y se integra 100% con el Management Studio de 2005 a partir del Sp2 que nos permite ejecutar reportes Custom vía un archivo RDL.

SQLSIM

Esta herramienta nos permite hacer stress de IO en un servidor emulando los algoritmos de SQL Server.

Una de sus grandes ventajas es la no necesidad de tener un SQL Server instalado para hacer los test

Como bien indica el titulo de este post, ya hace unos días que tenemos disponible el CTP de la nueva versión de SQL 2008 llamada R2 o Kilimanjaro.

Aquí el link

El día viernes 17 de julio di un webcast en el cual mostré las ventajas de la integración de reporting service con sharepoint, además se ve en el mismo la forma de configuración  , los cuidados que hay que tener y por ultimo un sitio funcionando.

Aquí les dejo el link para que puedan ver el video ondemand