miércoles, octubre 05, 2005

Profiler de SQL

Hace un tiempo había escrito un artículo sobre el Profiler de SQL Server, en el que se explicaba como utilizar esta herramienta para analizar la necesidad de crear índices para una determinada consulta, utilizando el Index Tunning Wizard.

En ese momento recién lo empezabamos a usar, por lo que no tenía mucha experiencia en ese tema. Después de haberlo usado un tiempo para varias cosas, tenemos un conjunto de tareas en las que resulta muy útil.

Básicamente esta herramienta permite registrar la actividad en la base de datos. Los usos que le estamos dando son:
  • Análisis de programas
    Podemos ver todas las sentencias que se están ejecutando en la base de datos. Además es posible filtrar por varios valores, entre ellos el número de proceso y el identificador de la base de datos.

    Esto nos permite analizar un programa desde otra perspectiva, viendo exáctamente lo que está haciendo en la base de datos.

  • Buscar las consultas que más demoran
    Uno de los datos más útiles que tenemos es la duración que tuvo cada consulta en la ejecución, lo que permite, cuando se están analizando problemas de performance, que nos concentremos en las consultas con mayor duración, que son las primeras candidadtas a analizar.

    Junto con la información de las duraciones, suele ser útil ver también la cantidad de lecturas, escrituras y el uso de CPU de cada consulta.

    Muchas veces al analizar un problema de performance, teníamos que intuir donde estaba el problema, pero con el Profiler podemos estar seguros de que estamos atacando el cuello de botella.

  • Ver los planes de ejecución
    Es posible ver los planes de ejecución de las sentencias, agregando el tipo de evento correspondiente (Excecution plan dentro de Performance).

    Los planes de ejecución también se pueden ver en forma gráfica desde el Query Analizer, pero el que nos muestra el Profiler es el que efectivamente fue utilizado por el DBMS para resolver la consulta.

  • Determinar pérdidas en la integridad transaccional
    Cuando nos encontramos con un programa que perdió la integridad transaccional, porque se está haciendo un commit en alguna parte que no debería, con GeneXus no siempre es fácil determinar donde se produce.

    Con el Profiler, vemos exáctamente donde se hizo el commit, y por lo tanto podemos rastrear a partir de las consultas cual fue el programa que lo hizo.
La información que genera el Profiler, además de poder verse en pantalla se puede guardar a un archivo o a una tabla. El archivo es útil cuando tenemos la salida del Profiler generada por ejemplo en un cliente y la queremos traer para analizar. Guardar los datos como tabla permite hacer consultas sobre la información, para buscar por ejemplo las sentencias que más demoran o las que se ejecutan más veces.

martes, octubre 04, 2005

Principals, Securables, Permissions

En la documentación de SQL Server 2005, se usan frecuentemente los términos "Principals", "Securables" y "Permissions" para expresar aspectos de seguridad de SQL Server 2005. Este artículo describe estos 3 conceptos.

Principals: Es a quien se asignan los permisos ( logins, usuarios, roles, etc )
En el contexto de SQL Server los "Principals" existen en 3 niveles diferentes:
- A nivel del sistema operativo Windows : usuarios(locales y de dominio) y grupos de usuarios
- A nivel de instancia SQL Server: logins (windows y sqlserver logins) y server roles
- A nivel de base de datos: usuarios, roles y roles de aplicación

Securables: Los recursos sobre los que se asigna permisos( bases de datos, tablas, archivos, etc)
Los "Securables" también existen a diferentes niveles:
- A nivel de windows, consisten de a archivos y claves de la registry que usa SQL Server.
- A nivel de SQL Server, están organizados en forma jerárquica:
- El nivel superior es la instancia, en este nivel los "Securables" son logins, http endpoints, bases de datos, etc.
- El siguiente nivel es la base de datos, en este nivel los "Securables" son servicios, assemblies, esquemas, etc.
- El siguiente nivel es el esquema, en este nivel los "Securables" son tablas, vistas, procedures, etc.

Permissions: Son los privilegios que se otorgan a los "Principals" para controlar la acciones que estos pueden realizar sobre los "Securables". ( permisos de write sobre un archivo, delete sobre una tabla, etc )
- A nivel de Windows, se usan ACL's para otorgar o denegar "Permissions"
- A nivel de SQL Server se usan las sentencias GRANT, REVOKE y DENY para otorgar o denegar "Permissions". Los "Permissions" asignados a determinado nivel son heredados de forma implícita en los niveles inferiores. Por ejemplo si a un rol se le asigna permiso de select sobre un esquema, el rol va a tener permisos de select sobre los "Securables" de ese esquema (típicamente tablas)