Como novedad en SQL Server 2008 nace el Declarative Management Framework. Este framework está basado en políticas que nos permitirán manejar entidades en el servidor o en un grupo de servidores. Para comprender mejor su funcionamiento definiremos algunos de los conceptos utilizados y a continuación pondremos algún ejemplo de su uso para que quede todo clarito clarito 

Objetivos

Aquellas entidades que podrán ser afectadas por nuestras políticas son denominadas objetivos. Se organizan de forma jerárquica comenzando a nivel de instancia, base de datos y finalmente por tipo de objetos (tablas, vistas, etc.) Ejemplos de objetivos: base de datos, tablas, índices, procedimientos almacenados, etc.

Facetas

Representa una agrupación lógica de las propiedades comunes de diferentes objetivos. Por ejemplo la faceta “Index Facet” agrupa propiedades como IsClustered, SpaceUsed, FillFactor, etc. Sobre estas propiedades podremos crear nuestras condiciones a validar y éstas serán dependientes de cada tipo de objetivo. Algunas facetas pueden ser comunes para diferentes tipos de objetos.

Condiciones

Las condiciones representan expresiones generadas a partir de las propiedades de las facetas aplicables al objetivo en cuestión. Por ejemplo podríamos tener una expresión que controlara que el nombre de los procedimientos almacenados comience por “pa_” como una buena práctica de nomenclatura. Para ello crearíamos una expresión donde validaremos que la propiedad “name” de la faceta “StoredProcedure Facet” cumpla la condición LIKE ‘pa_%’.

Política

Una política configura el cumplimiento de una condición indicando además a que objetivos de la jerarquía deberemos aplicarla. También indicaremos de qué forma deseamos hacer la política efectiva. Podemos elegir entre:

  • No forzar la aplicación de ésta. En este caso deberíamos lanzar manualmente la comprobación
  • Forzar su aplicación. En este caso se utilizaran triggers DDL para evaluarla en el acto.
  • Comprobarla instantáneamente. Se notificará con un evento en el log cuando se infringe la política.
  • Comprobación programada. Mediante un job de SQL Agent se comprobará con una frecuencia configurable.

Como la letra con ejemplos entra vamos a ellos. Vamos a crear una política que prohíba la creación de vistas en nuestra base de datos y otra que nos obligue a nombrar cada procedimiento almacenado comenzando por “pa_”. ¡Al ataque! J

Lo primero presentar la nueva estructura que aparece en el Management Studio:

Políticas en SQL Server 2008 - Declarative Management Framework

Podemos ver que bajo el apartado policy management tenemos las políticas, las condiciones y las facetas. Comenzaremos creando las condiciones. Para ello simplemente con el botón derecho seleccionaremos la opción para crear una nueva condición. Utilizaremos la propiedad Name de la faceta “View Facet” para configurarla:

Políticas en SQL Server 2008 - Declarative Management Framework

Con esta condición lo que conseguimos es que cualquier vista sea inválida pues ningún nombre de vista cumple NOT LIKE ‘%’. El siguiente paso sería crear una política que compruebe esta condición sobre nuestra base de datos.

Políticas en SQL Server 2008 - Declarative Management Framework

Indicaremos como condición la condición creada anteriormente y editaremos el filtro de forma que solo se aplique a nuestra base de datos de test. Indicaremos también que el modo de ejecución, es decir, la forma en la que haremos efectiva nuestra política, sea obligado (Enforce). Una vez hecho esto, si intentamos crear una vista en nuestra base de datos obtendremos el siguiente error:

Policy 'No se admiten vistas' has been violated by 'Server/Database[@Name='test']/View[@Name='testview' and @Schema='dbo']'.
This transaction will be rolled back.
Msg 3609, Level 16, State 1, Procedure sp_syspolicy_dispatch_event, Line 88
The transaction ended in the trigger. The batch has been aborted.

Para nuestra política de nomenclatura de procedimientos crearemos una condición que utilice la propiedad Name de la faceta “StoredProcedure Facet”. En este caso nuestra condición forzará que el nombre sea LIKE ‘pa_%’. A continuación crearemos la política con dicha condición indicando que se aplica a nivel de nuestra base de datos y que se haga efectiva de forma obligatoria. Si intentamos crear un procedimiento que no lo cumpla obtendremos el siguiente error:

Policy 'Los procedimientos deben cumplir la nomenclatura' has been violated by 'Server/Database[@Name='test']/StoredProcedure[@Name='testproc4' and @Schema='dbo']'. This transaction will be rolled back.
Msg 3609, Level 16, State 1, Procedure sp_syspolicy_dispatch_event, Line 88
The transaction ended in the trigger. The batch has been aborted.

Debemos tener en cuenta que las políticas no se comprueban contra objetos ya existentes si no son modificados o sufren cambios. En estos casos debemos comprobar manualmente la política. Esto se realiza pulsando el botón derecho sobre la política y seleccionando “Test Policy”. Si ejecutamos la comprobación contra esta última política vemos que existen 3 procedimientos (previos a la creación de la política) que la incumplen.

Políticas en SQL Server 2008 - Declarative Management Framework

Si utilizaramos el modo de ejecución de comprobación instantánea (check on changes) cuando intentáramos crear un procedimiento veríamos lo siguiente en el log de eventos:

Políticas en SQL Server 2008 - Declarative Management Framework

Dicho evento podría ser capturado por un servicio Windows para llevar a cabo alguna acción o monitorizarse desde alguna herramienta de control externa. En este caso el procedimiento sí se habría creado pese a incumplir la nomenclatura.

Una vez instalada la política, aquellos elementos que no la cumplan aparecerán marcados en el Management Studio con un icono indicando que violan alguna de nuestras políticas. Podemos ver en el caso del procedimiento almacenado como el icono nos guía por la jerarquía para encontrar los elementos “culpables”

 Políticas en SQL Server 2008 - Declarative Management Framework

Como conclusión, este nuevo framework nos permite mediante políticas realizar de forma sencilla labores de control que de otra forma deberíamos codificar manualmente. En SQL Server 2005 cuando deseamos crear este tipo de comprobaciones debemos programar nuestros propios triggers DDL. Además las políticas pueden ser exportadas a un fichero xml e importadas en otros servidores o instancias manteniendo así un repositorio de políticas común para nuestra organización.

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like