Policy Based Management

Um grande desafio na área de desenvolvimento de software é manter o padrão de objetos desenvolvidos, uma vez que cada desenvolvedor teve um aprendizado diferente do outro. Isso não é uma realidade exclusiva dos ambientes de desenvolvimento, com os objetos de bancos de dados a situação é parecida.

O SQL Server 2008 trouxe a implementação de um componente que facilita a criação de estruturas de validação e gerenciamento dos objetos. O Policy Based Management (PBM), que em tradução livre significa Gerenciamento Baseado em Política, foi desenvolvido para mudar a forma como o DBA lida com a manutenção e as verificações sobre os objetos no SQL Server.

O PBM é aplicável em diversas situações nas quais os responsáveis pelo desenvolvimento de objetos de banco de dados devem seguir uma determinada regra, uma política de padronização. O exemplo mais simples para esse caso é a criação de uma política de padronização de nomenclaturas, em que uma das regras é que todas as Stored Procedures devam ser iniciadas pelo prefixo “stp_%” e, ainda nesse cenário, poderíamos dizer que todas as tabelas devam ser iniciadas pelo prefixo “tb_%”, ou poderíamos ter a condição que todas as tabelas devem conter primary key.

Após compreender melhor a aplicação do PBM, podemos criar um novo cenário no qual em uma grande fábrica de software existem três servidores de banco de dados SQL Server utilizados para desenvolvimento, e cada um com cinquenta databases. Nesse cenário, é perceptível o quanto o PBM poderá ser um forte aliado no dia-a-dia do DBA.

Partes de um PBM

Podemos dizer que implementar uma regra é muito simples, basta trabalhar sobre quatro conceitos simples:

Facets: são um conjunto de propriedades lógicas que modelam o comportamento ou as características para certos tipos de destinos. Uma política deve ser escrita sobre uma faceta que contém propriedades. Exemplos práticos de facetas podem ser: tabela, stored procedure, banco de dados e etc.

Conditions: são expressões boleanas [booleanas ou lógicas] que especificam um conjunto de estados permitidos do tipo de destino.

Policies: uma policy é o comportamento esperado de uma condição criada para uma faceta. De uma maneira geral, é a combinação entre a faceta e a condição criada.

Target Type: são os objetos a serem gerenciados. Os alvos podem ser tabelas, bancos de dados, stored procedures, entre muitos outros objetos.

Ainda falando de conceitos, uma política poderá ser validada por quatro ações, descritas a seguir:

On demand: avalia a política quando o usuário força a validação.

On schedule: cria um job no SQL Server Agent para validar a política.

On change: log only – valida automaticamente quando acontece uma alteração no objeto e cria uma notificação.

On change: prevent – através de uma trigger DDL evita que a alteração viole alguma regra.

Criando um PBM

Agora que já conhecemos as partes que dividem um PBM, vou exemplificar como criar uma policy que evita que os desenvolvedores criem stored procedures que não possuam o prefixo “spt_” no nome. Abaixo, segue um passo-a-passo.

Passo 1 – Criar a condição:

Expandindo o grupo Management do Management Studio, vamos encontrar o sub-grupo Policy Management. Ao expandir esse grupo, vamos encontrar o grupo abaixo chamado “Conditions”. Clicando sobre essa pasta com o botão direito, aparecerá um sub-menu e o comando New Condition.

Figura 1 – Criando uma nova condição

Na janela que se abrirá, vamos parametrizar os campos conforme o quadro abaixo:

Campo	Descrição	Valor
Name	Nome da condição	con_valida_nome_stp
Facet	A faceta do objeto que será avaliada	Multipart Name
Expression	Expressão booleana sobre o objeto e a faceta	Field = @Name Operator = LIKE Value = “stp_%”
Description	Texto que descreve a condição.	Condição que valida o nome das stored procedures.

Quadro 1 – parâmetros para uma nova condição

Passo 2 – Criar a policy

Após a criação da condição, o próximo passo será criar a policy [aqui cabe a palavra política ou regra]. Para isso, devemos clicar com o botão direito sobre a guia Policy e selecionar o comando New Policy conforme a figura 2.

Figura 2 – Nova Policy

Na janela New Policy, criaremos a nossa regra, para evitar que os desenvolvedores criem stored procedures fora do padrão. Vamos seguir o preenchimento conforme o quadro 2.

Campo	Descrição	Valor
Name	Nome da policy.	Regra_validacao_nome_stp
Enabled	Habilita a policy para ser validada, se esta opção for desmarcada a policy será ignorada.	Marcado.
Check conditions	Identifica uma condição para ser validada.	Condicao_valida_nome_stored_procedure
Against targets	Indica qual é o objeto alvo da validação.	Every – Stored Procedure Every – Database
Evaluation mode	Indica o modo de avaliação, quando a avalição irá acontecer.	On change: prevent
Category	Permite criar, ou selecionar uma categoria para classificar as policies.	Manter o padrão de nomenclatura
Description	Permite um texto descritivo sobre a policy, esse texto será exibido se acontecer uma exceção.	Esta policy evita que sejam criadas stored procedures com nomes fora do padrão.
Text to display	Permite um texto que será exibido quando acontecer à condição verdadeira da expressão.	Conforme normas de desenvolvimento o padrão de nomenclatura pede um prefixo “stp_”

Quadro 2 – parâmetros da nova policy

 

Figura 3 – Nova policy

Testando a verificação

A validação da nossa policy é simples de ser criada, basta criarmos uma stored procedure com o nome fora do padrão proposto, veja na listagem 1.

Listagem 1

create proc sp_datahora

as

select GETDATE();

Ao executar a criação deste objeto, receberemos o erro, conforme a figura 4. Nessa imagem, podemos observar três informações importantes que são retornadas: condição, descrição e help.

Figura 4 – resultado da execução

Na listagem 2, segue o script com a nomenclatura correta.

Listagem 2

create proc stp_datahora

as

select GETDATE();

Conclusão

Concluindo, o PBM é uma ferramenta ágil e prática para manter a ordem nos servidores SQL Server. Um ponto importante que quero deixar registrado é o fato de que as policys podem ser contra objetos de versões anteriores ao SQL Server 2008, claro que há uma restrição para algumas facets, mas é possível.