Curso de Banco de Dados Plataforma: MS SQL Server. Change Traking MS SQL Server

Tamanho: px

Começar a partir da página:

Download "Curso de Banco de Dados Plataforma: MS SQL Server. Change Traking MS SQL Server"

Lívia Affonso
5 Há anos
Visualizações:

1 Change Traking MS SQL Server Sumário 1. O que é? Para que serve? Como habilitar? Como funciona? Passos iniciais para aplicar: E na prática? Principais vantagens Principais desvantagens

1. O que é? Mecanismo do SQL Server que permite consultar as alterações (Insert/Update/Delete) de uma determinada tabela sem a necessidade de utilizar trigger. 2. Para que serve?

3. Como habilitar? Por default, esta propriedade vem desabilitada. Primeiro é necessário habilitar este recurso nas propriedades do próprio banco de dados (Imagem 1).

2 1. O que é? Mecanismo do SQL Server que permite consultar as alterações (Insert/Update/Delete) de uma determinada tabela sem a necessidade de utilizar trigger. 2. Para que serve? Duas de suas principais utilidades são: 2.1. Fazer processo um processo manual replicação sem a necessidade de utilizar o próprio replicador do SQL Server; 2.2. Coletar logs das movimentações nas tabelas para efeito de histórico. 3. Como habilitar? Por default, esta propriedade vem desabilitada. Primeiro é necessário habilitar este recurso nas propriedades do próprio banco de dados (Imagem 1). Neste exemplo, o banco de dados chama-se Teste. Imagem 1 Depois, terá que habilitar o recurso nas tabelas desejadas, conforme Imagem 2. O único pré-requisito é que a tabela possua uma chave primária (independe o tipo de dados ou se a PK é simples ou composta). A tabela utilizada neste exemplo chama-se Tab_Teste. 2

3 Imagem 2 4. Como funciona? Basta fazer operações de Insert, Update ou Delete nas tabelas com o Change Tranking habilitado. A cada operação dessa, o SQL gera um novo ID sequencial (versionador) para controle dos logs. Para saber qual o ID atual, é só executar o comando: Select CHANGE_TRACKING_CURRENT_VERSION() AS ID Para conferir o log de cada uma dessas operações, basta executar o comando abaixo: Select * From CHANGETABLE(CHANGES Tab_Teste, 0) As Alteracao Onde está Tab_Teste, basta colocar o nome da tabela a ser verificada. O 0 (zero) é o parâmetro para indicar a partir de qual ID se quer consultar os logs. O resultado deste select será: Sendo: - SYS_CHANGE_VERSION: Exibe o ID sequencial referente à última operação de Update ou Delete. Se nenhuma dessas duas operações foram realizadas, o ID será o mesmo da coluna SYS_CHANGE_CREATION_VERSION; - SYS_CHANGE_CREATION_VERSION: Exibe o ID sequencial que foi armazenado no momento do Insert do registro; - SYS_CHANGE_OPERATION: Contém o tipo de operação, D para Delete e I para Insert ou Update (para saber se houve update, basta conferir se os IDs da primeira e segunda colunas estão diferentes); - Codigo: é a PK da tabela Tab_Teste. Se a tabela consultada tivesse PK composta, essas demais colunas iriam aparecer logo após a SYS_CHANGE_CONTEXT, assim como o Codigo apareceu nesse exemplo. 5. Passos iniciais para aplicar: 5.1. Definir um período de retenção dos logs Habilitar a propriedade Change Traking (CT) no banco de dados desejado parametrizando o período de retenção pré-definido Mapear as tabelas que deverão ser monitoradas Habilitar a propriedade Change Traking nas tabelas mapeadas Criar uma tabela (Log_Controle_CT) para controlar os logs da Change Traking com as seguintes colunas: Codigo: PK (chave primária) sequencial para identificar os registros dessa nova tabela; Nome_Tabela: Nome da tabela monitorada que será processada; 3

4 ID_Anterior: ID do CT para saber qual foi o valor inicial do intervalo do último processamento; ID_Atual: ID do CT para saber qual foi o valor final do intervalo do último processamento. Esse valor será o ID_Anterior do registro seguinte na próxima sincronização; Data_Sincronizacao: irá armazenar a data/hora da última verificação. 6. E na prática? 6.1. Deverá ser criado um job ou serviço que, de tempo em tempo, executará uma procedure (quem também deverá ser criada); 6.2. Essa procedure varrerá os logs da CHANGETABLE das tabelas com CT habilitado e irá retornar os registros que foram movimentados, bem como o tipo de operação (U/I/D). A partir da PK que é retornada na CHANGETABLE, é possível localizar o respectivo registro na tabela de origem. Quem irá orientar essa procedure para não fazer mais de uma vez o mesmo levantamento, será a tabela criada no item 4.6. Essa tabela possui os intervalos de ID que já foram processados da última vez. Então, a cada novo processamento, as colunas ID_Anterior e ID_Atual deverão ser atualizadas com a nova faixa processada. Exemplo: Na primeira execução, o registro de controle da Tab_Teste ainda não existia nessa nova tabela. Então, Select na CHANGETABLE será feito com o parâmetro 0 (zero) e a coluna SYS_CHAGEN_VERSION deverá ser menor ou igual ao ID de CT atual: Select * From CHANGETABLE(CHANGES Tab_Teste, 0) As Alteracao where sys_change_version <= (Select CHANGE_TRACKING_CURRENT_VERSION() ); Com isso, será possível obter as PKs dos registros que foram movimentados no período na tabela Tab_Teste, bem como o tipo de operação (I/U/D). Essas informações poderão ser armazenadas em alguma outra tabela, ou também se criar o Script DML de cada registro e aplica-lo em uma outra base; Após essa a primeira execução, um registro deverá ser criado na tabela Log_Controle_CT com o Nome_Tabela = Tab_Teste, ID_Anterior = 0 (zero) e o ID_Atual = (Select CHANGE_TRACKING_CURRENT_VERSION() ). No próximo processamento, a tabela Tab_Teste iniciará a verificação da CHANGETABLE com o valor do ID_Atual e o sys_change_version <= (Select CHANGE_TRACKING_CURRENT_VERSION() ). Ao final, Log_Controle_CT será atualizada com o ID_Aanterior = ID_Atual e o ID_Atual = (Select CHANGE_TRACKING_CURRENT_VERSION() ). 7. Principais vantagens 7.1. Recurso poderá ser utilizada na versão free do MS SQL Server (Express). A replicação do próprio SQL Server só está disponível em versões pagas; 7.2. Não cria tantos objetos como a própria replicação do SQL Server (triggers, tabelas, etc.); 7.3. Não onera tanto a base. 4

5 8. Principais desvantagens 8.1. Em caso de Update, não dá para precisar qual coluna foi alterada; 8.2. Se o período de retenção do log for muito grande (1 mês, por exemplo) e as movimentações nas tabelas monitoradas forem excessivas, pode causar alguma lentidão no momento em que o SQL Server estiver executando autolimpeza. 5

Documentos relacionados

José Antônio da Cunha

José Antônio da Cunha CEFET-RN Natal, 10 de maio de 2013 Auditando operações DML com OUPUT Imagine o seguinte cenário: você possui uma tabela muito importante em seu banco de dados e gostaria de implantar