Configurando e gerenciando o controle de alterações
Este tópico descreve como habilitar, desabilitar e gerenciar o controle de alterações. Ele também descreve como configurar a segurança e identificar os efeitos sobre o armazenamento e o desempenho quando você usa o controle de alterações.
Habilitando o controle de alterações para um banco de dados
Antes de usar o controle de alterações, você deve habilitar o controle de alterações no nível de banco de dados. Este exemplo mostra como habilitar o controle de alterações usando ALTER DATABASE:
ALTER DATABASE AdventureWorks2008R2
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
Você também pode habilitar o controle de alterações no SQL Server Management Studio usando a caixa de diálogo Propriedades do Banco de Dados (Página Controle de Alterações).
Você pode especificar as opções CHANGE_RETENTION e AUTO_CLEANUP quando habilitar o controle de alterações e alterar os valores a qualquer momento depois que o controle de alterações estiver habilitado.
O valor de retenção determina o período de tempo que o controle de alterações mantém as informações. Informações do controle de alterações anteriores a esse período de tempo são removidas periodicamente. Quando estiver definindo esse valor, deverá considerar com que frequência os aplicativos serão sincronizados com as tabelas no banco de dados. O período de retenção especificado deve ter pelo menos a duração do período de tempo máximo entre as sincronizações. Se um aplicativo obtém as alterações em intervalos maiores, os resultados retornados podem ser incorretos porque algumas informações de alterações podem ter sido removidas. Para evitar resultados incorretos, um aplicativo pode usar a função de sistema CHANGE_TRACKING_MIN_VALID_VERSION para determinar se o intervalo entre as sincronizações foi muito longo.
Use a opção AUTO_CLEANUP para habilitar ou desabilitar a tarefa de limpeza que remove informações antigas de controle de alterações. Isso pode ser útil quando há um problema temporário que impede os aplicativos de sincronizarem e o processo para remover as informações do controle de alterações anterior ao período de retenção precisa ser interrompido até que o problema seja resolvido.
Para qualquer banco de dados que use o controle de alterações, lembre-se do seguinte:
Para usar o controle de alterações, o nível de compatibilidade do banco de dados deve ser definido como 90 ou mais. Se o nível de compatibilidade de um banco de dados for inferior a 90, você poderá configurar o controle de alterações. No entanto, a função CHANGETABLE, usada para obter informações do controle de alterações, retornará um erro.
Usar o isolamento do instantâneo é o modo mais fácil de garantir que todas as informações do controle de alterações sejam consistentes. Por esse motivo, é estritamente recomendável que o isolamento do instantâneo seja definido como ON para o banco de dados. Para obter mais informações, consulte Usando o controle de alterações.
Habilitando o controle de alterações para uma tabela
O controle de alterações deve ser habilitado para cada tabela que você deseja controlar. Quando o controle de alterações está habilitado, são mantidas informações sobre todas as linhas da tabela afetadas por uma operação DML.
O exemplo a seguir mostra como habilitar o controle de alterações em uma tabela usando ALTER DATABASE:
ALTER TABLE Person.Person
ENABLE CHANGE_TRACKING
WITH (TRACK_COLUMNS_UPDATED = ON);
Você também pode habilitar o controle de alterações em uma tabela no SQL Server Management Studio usando a caixa de diálogo Propriedades do Banco de Dados (Página Controle de Alterações).
Quando a opção TRACK_COLUMNS_UPDATED é definida como ON, o Mecanismo de banco de dados do SQL Server armazena informações extras sobre quais colunas foram atualizadas na tabela interna de controle de alterações. O controle de coluna pode permitir a um aplicativo sincronizar apenas as colunas que foram atualizadas. Isso pode melhorar a eficiência e o desempenho. Entretanto, como a manutenção de informações do controle de alterações aumenta a sobrecarga de armazenamento, essa opção é definida como OFF por padrão.
Desabilitando o controle de alterações
É necessário desabilitar o controle de alterações em todas as tabelas com alterações controladas, antes que o controle de alterações seja definido como OFF no banco de dados. Para determinar as tabelas que tenham o controle de alterações habilitadas em um banco de dados, use a exibição do catálogo sys.change_tracking_tables.
O exemplo a seguir mostra como desabilitar o controle de alterações em uma tabela usando ALTER DATABASE:
ALTER TABLE Person.Person
DISABLE CHANGE_TRACKING;
Quando nenhuma tabela de um banco de dados controlar as alterações, você pode desabilitar o controle de alterações no banco de dados. Este exemplo mostra como desabilitar o controle de alterações em um banco de dados usando ALTER DATABASE:
ALTER DATABASE AdventureWorks2008R2
SET CHANGE_TRACKING = OFF;
Gerenciando o controle de alterações
As próximas seções listam exibições de catálogo, permissões e configurações relevantes para o gerenciamento do controle de alterações.
Exibições do catálogo
Para determinar quais as tabelas e bancos de dados que possuem o controle de alterações habilitado, você pode usar as seguintes exibições do catálogo:
A exibição do catálogo sys.internal_tables lista as tabelas internas criadas quando o controle de alterações está habilitado para um usuário da tabela.
Segurança
Para acessar informações do controle de alterações usando as funções de controle de alterações, o principal deve ter as seguintes permissões:
Permissão SELECT em pelo menos as colunas de chave primária, em uma tabela com alterações controladas da tabela que está sendo consultada.
Permissão VIEW CHANGE TRACKING na tabela na qual estão sendo obtidas as alterações. A permissão VIEW CHANGE TRACKING é necessária pelas seguintes razões:
Os registros do controle de alterações incluem informações sobre linhas excluídas, especificamente os valores de chave primária das linhas que foram excluídas. Um principal poderia ter recebido a permissão SELECT em uma tabela com controle de alterações após a exclusão de alguns dados confidenciais. Nesse caso, não convém que o principal tenha acesso às informações excluídas usando o controle de alterações.
As informações do controle de alterações podem armazenar informações sobre as colunas que foram alteradas por operações de atualização. Um principal poderia ter negada a permissão de acesso a uma coluna que contém informações confidenciais. Porém, como as informações de controle de alterações estão disponíveis, um principal pode determinar que um valor de coluna foi atualizado, mas não pode determinar o valor da coluna.
Noções básicas de sobrecarga do controle de alterações
Quando o controle de alterações estiver habilitado em uma tabela, algumas operações de administração são afetadas. A tabela a seguir lista as operações e os efeitos que você deve considerar:
Operação |
Quando o controle de alterações está habilitado |
|---|---|
DROP TABLE |
Todas as informações do controle de alterações da tabela descartada são removidas. |
ALTER TABLE DROP CONSTRAINT |
Uma tentativa para cancelar a restrição PRIMARY KEY falhará. O controle de alterações deve ser desabilitado antes de uma restrição PRIMARY KEY ser cancelada. |
ALTER TABLE DROP COLUMN |
Se a coluna que está sendo cancelada é parte de uma chave primária, não é permitido cancelar a coluna, independentemente do controle de alterações. Se a coluna que está sendo cancelada não é parte de uma chave primária, cancelar a coluna terá êxito. Entretanto, o efeito em qualquer aplicativo que estiver sincronizando esses dados deve ser compreendido antes. Se o controle de alterações de coluna estiver habilitado na tabela, a coluna cancelada poderá retornar como parte das informações do controle de alterações. É responsabilidade do aplicativo controlar a coluna cancelada. |
ALTER TABLE ADD COLUMN |
Se uma nova coluna for adicionada à tabela com controle de alterações, a inclusão da coluna não será controlada. Somente as atualizações e alterações feitas na nova coluna serão controladas. |
ALTER TABLE ALTER COLUMN |
Alterações de tipos de dados de colunas de chave primária não são controladas. |
ALTER TABLE SWITCH |
Trocar uma partição falhará se uma ou ambas as tabelas tiverem o controle de alterações habilitado. |
DROP INDEX ou ALTER INDEX DISABLE |
O índice que aplica a chave primária não pode ser cancelado ou desabilitado. |
TRUNCATE TABLE |
Truncando uma tabela pode ser executada em uma tabela que tenha o controle de alterações habilitado. No entanto, não são controladas as linhas que foram excluídas pela operação e a versão mínima válida é atualizada. Quando o aplicativo controla sua versão, o controle verifica se a versão é muito antiga e é necessário fazer uma atualização. Isso é o mesmo que desabilitar o controle de alterações da tabela e, depois, habilitá-lo novamente. |
O uso do controle de alterações adiciona uma certa sobrecarga às operações DML devido às informações de controle que são armazenadas como parte do procedimento.
Efeitos na DML
O controle de alterações foi otimizado para minimizar a sobrecarga de desempenho nas operações DML. A sobrecarga de desempenho incremental associada com o uso do controle de alterações em uma tabela é semelhante à sobrecarga incorrida quando um índice é criado para uma tabela e precisa ser mantido
Para cada linha alterada por uma operação DML, uma linha é adicionada à tabela interna de controle de alterações. O efeito dessa relação com a operação DML depende de vários fatores, como os seguintes:
O número de colunas de chave primária
A quantidade de dados que estão sendo alterados na linha da tabela do usuário
O número de operações executadas em uma transação
O isolamento do instantâneo, se utilizado, também afeta o desempenho de todas as operações DML, quer o controle de alterações esteja habilitado ou não.
Efeitos no armazenamento
Os dados do controle de alterações são armazenados nos seguintes tipos de tabelas internas:
Tabela de alteração interna
Há uma tabela de alteração interna para cada tabela de usuário para a qual o controle de alterações está habilitado.
Tabela de transação interna
Há uma tabela de transação interna para o banco de dados.
Essas tabelas internas afetam os requisitos de armazenamento das seguintes maneiras:
Para cada alteração, em cada linha na tabela do usuário, uma linha é adicionada à tabela de alteração interna. Essa linha tem uma pequena sobrecarga fixa, mais uma sobrecarga variável igual ao tamanho das colunas de chave primária. A linha pode conter informações de contexto opcionais definidas por um aplicativo. E, se o controle de alterações de coluna estiver habilitado, cada coluna alterada necessitará de 4 bytes na tabela de controle.
Para cada transação confirmada, uma linha é adicionada a uma tabela de transação interna.
Como em outras tabelas internas, você pode determinar o espaço usado para as tabelas de controle de alterações usando o procedimento armazenado sp_spaceused. Os nomes das tabelas internas podem ser obtidos usando a exibição de catálogo sys.internal_tables, como mostrado neste exemplo:
sp_spaceused 'sys.change_tracking_309576141';
sp_spaceused 'sys.syscommittab';
Consulte também