SQL Server 2008

Controlando alterações no seu banco de dados empresarial

Paul S. Randal

 

Visão geral:

  • A necessidade de controlar alterações
  • Controlando alterações no SQL Server 2005
  • Controlando alterações no SQL Server 2008
  • Controlando a captura de dados no SQL Server 2008

Sumário

Como controlar alterações no SQL Server 2005
Maneiras fáceis de controlar alterações no SQL Server 2008
Como a captura de dados de alteração funciona
Como o controle de alterações funciona
Conclusão

Para desenvolvedores, um problema difícil no SQL Server é controlar quais dados são alterados em um banco de dados. Um desafio ainda maior é arquitetar uma solução simples que não afete muito o desempenho da carga de trabalho e não seja difícil de criar, implementar e gerenciar. Então, por que se dar ao trabalho de controlar alterações? O controle de alterações realmente vale a pena? Dois exemplos bastante citados são os de oferecer suporte a atualizações para um data warehouse e oferecer suporte à sincronização de sistemas heterogêneos, ocasionalmente conectados.

Um data warehouse normalmente possui alguma representação das tabelas no banco de dados OLTP (transação online), mas os esquemas de tabela podem realmente ser muito diferentes. Isso significa que é preciso ser um processo ETL (extrair, transformar, carregar) para mover os dados de um banco de dados OLTP para o data warehouse.

Posso imaginar três possibilidades para fazer isso. A primeira é atualizar o data warehouse inteiro periodicamente. Sem dúvida isso não é prático para grandes volumes de dados e também significa que as atualizações no data warehouse não são contínuas. O segundo método é usar um esquema de particionamento no banco de dados OLTP para permitir que o processo ETL funcione apenas nos dados novos desde o processo ETL anterior. Este método funciona apenas para inserções de dados, e não atualizações ou exclusões, e requer um mecanismo complexo para gerenciar a definição de limites de partição e partições de alternância. O terceiro método é controlar alterações nos dados OLTP e executar apenas o processo ETL usando os dados alterados. É o método mais eficiente em termos de volume de dados.

Os dispositivos móveis são ubíquos no ambiente de negócios atual, o que significa que lidar com sistemas conectados ocasionalmente é uma exigência. Em termos de sistemas de bancos de dados, o problema é como atualizar com eficiência um armazenamento de dados em um dispositivo que não é conectado com freqüência, especialmente quando esse armazenamento é pequeno e tem um esquema radicalmente diferente do banco de dados principal.

Considere um representante de vendas de celular responsável por uma parte de um catálogo de produtos muito grande. Toda noite, ele conecta o dispositivo de mão ao banco de dados principal para baixar os dados mais recentes (todas as alterações àquela parte do catálogo de produtos, simplificadas para armazenamento em um dispositivo de mão). A transferência de dados deve ser tão eficiente quanto possível.

Agora, você pode fazer o sistema do banco de dados preparar toda a parte relevante do catálogo de produtos para o download no dispositivo e fazer o dispositivo baixá-la. Em outras palavras, todos os dados são baixados sempre que o dispositivo se conecta, mesmo que não sejam alterados. Sem dúvida, é uma abordagem nada eficiente.

Outra abordagem é fazer o sistema de banco de dados controlar as alterações na parte relevante do catálogo de produtos. Assim, quando se conectar, o dispositivo de mão solicitará os dados que foram alterados desde a última conexão. Nesta solução, o sistema do banco de dados precisa preparar apenas um subconjunto dos dados e o download é tão eficiente quanto possível.

Outro motivo para controlar alterações é oferecer suporte à auditoria, o que é essencial hoje em dia. A auditoria controla as alterações que estão sendo feitas, bem como as que já ocorreram e quem as fez. Isso realmente coloca tudo em outro nível, com restrições rígidas quanto à durabilidade, segurança e correção de uma trilha de auditoria completa.

As tecnologias criadas para controlar alterações de dados no SQL Server 2008 não foram programadas para oferecer suporte à auditoria; entretanto, o SQL Server 2008 oferece um novo recurso, chamado SQL Server Audit, especialmente criado para auditoria. Rick Byham falou sobre o recurso SQL Server Audit no artigo "SQL Server 2008: segurança" da edição de abril de 2008 da TechNet Magazine (disponível em technet.microsoft.com/magazine/cc434691).

Como você pode ver, há vários motivos interessantes para controlar as alterações nos dados. Então, a grande questão é: qual a melhor maneira de controlar?

Como controlar alterações no SQL Server 2005

Com o SQL Server 2005 (e as versões anteriores do SQL Server), não existe uma solução pronta e simples. Por isso, nessas plataformas, os desenvolvedores precisam criar soluções personalizadas para seus aplicativos que, em geral, envolvem colunas de carimbo de data/hora, gatilhos DML (Linguagem de Manipulação de Dados) e tabelas extras. Essas soluções, no entanto, apresentam vários problemas em potencial. Por exemplo:

  • A adição de colunas de carimbo de data/hora causa uma alteração no esquema de tabelas (com possíveis efeitos indiretos em procedimentos armazenados e outro código).
  • Um gatilho DML, implicitamente, faz parte da transação que contém a DML pela qual é disparado, por isso, seu tempo de execução aumenta a duração da transação. Quanto mais complexo o gatilho, maior o tempo de execução e, portanto, maior o efeito negativo sobre o desempenho da carga de trabalho. Os disparadores DML usados para controlar alterações precisam processar as tabelas inseridas e excluídas para obter todas as alterações e inseri-las em outra tabela de controle.
  • A tabela de controle precisa ser gerenciada de forma a evitar um crescimento descontrolado, o que pode exigir a criação de algo como um trabalho do Agent que corte os dados antigos periodicamente.

Maneiras fáceis de controlar alterações no SQL Server 2008

O SQL Server 2008 apresenta duas novas tecnologias que permitem controlar as alterações nos dados com muito mais facilidade: o controle de alterações e a captura de dados de alteração. Os dois recursos controlam os dados alterados (e usam as operações de inserir, atualizar ou excluir para controlar exatamente como os dados são alterados) e eliminam a necessidade de soluções personalizadas. Tirando essas semelhanças, seus mecanismos e o que realmente é controlado são bastante diferentes.

A captura de dados de alteração usa um mecanismo assíncrono que controla todas as alterações que ocorrem em uma tabela (ou um conjunto definido de colunas da tabela), incluindo os próprios valores da coluna. Ela foi criada para cenários como o processo ETL de data warehouse descrito anteriormente.

A Figura 1 ilustra os dados de alteração sendo consumidos em frações de tempo. O mecanismo de captura de dados de alteração extrai os dados alterados em um conjunto de tabelas, com as alterações mais recentes na parte superior da tabela. O processo ETL pode consultar as tabelas, mantendo os dados de alteração para todas as alterações que ocorreram em um período definido. Esse mecanismo permite que o processo ETL limite a quantidade de dados que deve ser consumida em cada lote.

fig01.gif

Figura 1 Dados de alteração históricos consumidos em frações de tempo (clique na imagem para ampliá-la)

O controle de alterações, por sua vez, usa um mecanismo síncrono que controla apenas a linha que foi alterada em uma tabela (e, opcionalmente, a lista de colunas alteradas). Ele foi criado para tratar de problemas como o do sistema conectado ocasionalmente do cenário I descrito anteriormente. Essa abordagem é ilustrada na Figura 2.

fig02.gif

Figura 2 Um sistema conectado ocasionalmente usando dados de controle de alterações (clique na imagem para ampliá-la)

Os dois recursos apresentam um aumento em E/S e registro em log, mas isso também vale para soluções personalizadas (os dados de alteração precisam ser armazenados em algum lugar). O que torna esses dois recursos potencialmente diferentes de uma solução personalizada é que as tabelas usadas para armazenar os dados de alteração devem estar no mesmo banco de dados que as tabelas que estão sendo controladas. Isso significa que todos os dados de alteração serão incluídos em backups e, possivelmente, transmitidos na rede pelo envio de log e espelhamento do banco de dados.

Em termos de desenvolvimento, esses dois recursos devem remover uma boa parte da complexidade do controle de alterações. Não há qualquer alteração de esquema ou gatilho necessário para essas tecnologias. As duas tecnologias possuem processos de limpeza automáticos e configuráveis, solicitam alterações por tempos de confirmação de transação e fornecem funções internas para recuperar as informações de alteração.

Da perspectiva do gerenciamento, cada uma das abordagens apresenta vantagens e desvantagens. Com qualquer tecnologia, há muita informação que deve ser compreendida antes de desenvolver e implantar as soluções que usam esses recursos. No restante deste artigo, apresentarei uma visão geral de cada recurso, mostrando como funcionam e os pontos práticos a serem considerados antes de usá-los em produção.

Como a captura de dados de alteração funciona

A captura de dados de alteração não faz nada como parte das transações que alteram a tabela a ser controlada. Em vez disso, as operações de inserção, atualização e exclusão são gravadas no log de transações, como normais, e periodicamente coletadas no log. A coleta é executada por um trabalho do leitor de log do SQL Agent, e as operações coletadas são armazenadas em uma tabela separada chamada de tabela de alteração. Posteriormente, a tabela de alteração poderá ser consultada para obter os dados de alteração usando uma das duas funções. A combinação entre a tabela de alteração e as duas funções é chamada de instância de captura. A Figura 3 mostra o fluxo de dados usando a captura de dados de alteração para acionar um processo ETL de data warehouse.

\\msdnmagtst\MTPS\TechNet\issues\en\2008\11\Randal - SQL\layout\FIGURES\fig03.gif

O processo de habilitar a captura de dados de alteração envolve dois estágios. Primeiro, um membro da função de servidor fixa sysadmin deve habilitar a captura de dados de alteração para o banco de dados, usando sys.sp_cdc_enable_db. Depois, um membro da função de servidor fixa db_owner deve habilitar a captura de dados de alteração em uma tabela específica, usando sys.sp_cdc_enable_table. Esses requisitos de segurança são necessários devido à possibilidade de alto uso do disco caso a captura de dados de alteração seja malconfigurada. É perfeitamente justificável que um proprietário de tabela não possa habilitar o recurso e surpreender um administrador do banco de dados com um uso extra do disco.

Quando a captura de dados de alteração é habilitada para um banco de dados, o banco de dados obtém algumas adições, incluindo um novo esquema (chamado cdc), algumas tabelas de dados e um gatilho para capturar eventos DDL (Linguagem de Definição de Dados). Um recurso que acho interessante é o de obter uma lista das alterações DDL em uma tabela.

O ato de habilitar a captura de dados de alteração também cria a instância de captura para a tabela (a tabela de alterações e até duas funções para retornar os dados de alteração). O nome da tabela de alteração é o mesmo que o da instância de captura, com o acréscimo de _CT. A primeira função é sempre criada e usada para retornar os dados de alteração da tabela de alterações. A segunda função será criada se a opção de permitir alterações de rede for especificada. Isso significa que apenas o resultado final de todas as alterações capturadas será retornado, em vez de todas as alterações intermediárias que a primeira função retorna. Os dois nomes de função são, respectivamente, fn_cdc_get_all_changes_ e fn_cdc_get_net_changes_, com o acréscimo do nome da instância de captura. Observe que, assim como o recurso de controle de alterações, essa funcionalidade requer que a tabela tenha uma chave primária ou outro índice exclusivo.

Ao lidar com a primeira tabela no banco de dados para habilitar a captura de dados de alteração, dois trabalhos do SQL Agent podem ser criados: o de captura e o de limpeza. Digo que "podem ser criados" porque o trabalho de captura é o mesmo usado para coletar transações na replicação transacional. Se a replicação transacional já estiver configurada, apenas o trabalho de limpeza será criado e o trabalho do leitor de log existente também será usado como trabalho de captura. Isso é bom porque ter dois trabalhos do leitor de log geraria rapidamente problemas de contenção com o log e, com isso, problemas de desempenho. Seja como for, o SQL Agent deve ser executado se você deseja usar a captura de dados de alteração.

A lógica dentro do leitor de log automaticamente manipula a captura de dados de alteração das tabelas habilitadas e desabilitadas e altera o que é coletado do log de transações, conforme adequado. Um ponto importante a ser ressaltado aqui é que, assim que a captura de dados é habilitada, o log de transações se comporta exatamente da mesma forma que com a replicação transacional (o log não pode ficar truncado até que o leitor de log o processe). Isso significa que uma operação de ponto de verificação, inclusive no modo de recuperação SIMPLE, não irá truncar o log, a menos que já tenha sido processado pelo leitor de log.

Além disso, se o modelo de recuperação BULK_LOGGED for usado para reduzir o registro em log, a captura de dados de alteração fará com que tudo seja completamente registrado, exceto para operações de criação/descarte/recriação de índice. Se você nunca viu esse comportamento, saiba que ele pode causar problemas de tamanho de log de transações, especialmente se os padrões do trabalho de captura forem alterados de forma que o log não seja processado com tanta freqüência.

Por padrão, o trabalho de captura é executado continuamente, verificando o log a cada cinco segundos e processando um máximo de 500 transações a partir do log. Também, por padrão, o trabalho de limpeza é executado todo dia, às 2 A.M., e remove todas as entradas de dados de alteração com mais de três dias das tabelas de alterações. Você pode alterar essas configurações usando o procedimento sys.sp_cdc_change_job; assim, as alterações só entrarão em vigor quando você reiniciar os trabalhos usando sys.sp_cdc_stop_job e sys.sp_cdc_start_job.

Embora, em geral, tenha um baixo impacto no desempenho do sistema, o processo do leitor de log é possível em sistemas OLTP muito carregados com uma grande quantidade de dados de alteração, em que a adição de apenas um processo do leitor de log pode causar a contenção do log de transações. A verdadeira contenção seria causada pelos cabeçalhos de disco que são movidos entre o ponto em que o log é gravado pelas transações e o ponto em que é lido pelo processo do leitor de log. Nesse caso, pode ser necessário alterar a freqüência com que o trabalho de captura é executado para garantir que o desempenho OLTP não seja afetado. Isso, porém, cria uma compensação clássica do tipo espaço em disco versus desempenho: o log continuará a crescer até que o trabalho de captura o processe.

O mesmo problema ocorrerá se a freqüência do trabalho de limpeza ou os períodos de retenção de dados de alteração forem alterados (as tabelas de alteração continuarão a crescer até que os dados de alteração sejam limpos). Isso nos leva a uma consideração de design quantitativa sobre o que é controlado e por quanto tempo é retido. Os pontos importantes a serem considerados aqui incluem:

  • A lista de colunas necessárias para a instância de captura. Quanto mais colunas são capturadas, mais dados de alteração são inseridos nas tabelas de alteração.
  • A quantidade de espaço em disco utilizada pelas tabelas de alteração.
  • A freqüência com que o processo é executado que consome os dados de alteração. Lembre-se de que os dados não podem ser excluídos enquanto não forem usados.
  • A freqüência com que o processo de limpeza é executado (pode haver tantos dados de alteração gerados que o processo de limpeza que os exclui só pode ser executado no fim de semana, por exemplo, porque de outra forma geraria um excesso de logs de transação).

A captura de dados de alteração pode ser configurada para simplesmente controlar todas as alterações em uma tabela ou controlar o subconjunto das colunas em uma tabela. O uso de um subconjunto poderá ser útil se algumas colunas secundárias forem colunas varchar muito grandes ou colunas BLOB (objeto binário grande), como texto, imagem ou XML; caso contrário, o espaço usado pela tabela de alteração pode crescer descontroladamente, com muita rapidez.

Dado o grande potencial para uso de espaço em disco, o local do grupo de arquivos da tabela de alteração pode ser definido quando a captura de dados de alteração é habilitada. Isso facilita o gerenciamento do espaço em disco subjacente e significa que todos os dados de alteração podem ser armazenados em um volume com um nível RAID menos dispendioso do que o banco de dados principal. Além disso, embora as configurações do trabalho de limpeza se apliquem a todas as instâncias, uma instância individual poderá ser limpa separadamente a qualquer momento se o espaço em disco se tornar um problema. Você pode monitorar o uso de espaço em disco com facilidade utilizando sp_spaceused nas tabelas de captura.

A linha gravada na tabela de alteração contém metadados sobre a transação (o número de seqüência do log de confirmação, ou LSN), bem como a ordem dentro da transação em que a alteração ocorreu, qual foi a operação, uma bitmask das colunas que foram alteradas e os valores da coluna.

As alterações DDL serão irrestritas enquanto a captura de dados de alteração estiver habilitada. Entretanto, elas poderão ter algum efeito nos dados de alteração coletados se as colunas forem adicionadas ou descartadas. Se uma coluna controlada for descartada, todas as entradas seguintes na instância de captura terão NULL para essa coluna. Se uma coluna for adicionada, ela será ignorada pela instância de captura. Em outras palavras, a forma da instância de captura é definida ao ser criada.

Se as alterações de coluna forem necessárias, é possível criar outra instância de captura para uma tabela (até o máximo de duas instâncias de captura por tabela) e permitir que os consumidores dos dados de alteração migrem para o novo esquema de tabela. Mas tenha cuidado ao fazer isso porque duas instâncias de captura para uma tabela controlada significa o dobro de espaço em disco, E/S e registro em log.

Sem entrar em muitos detalhes, as alterações são recuperadas das tabelas de alteração usando as funções que descrevi. As funções obtêm um LSN inicial e um final, e há outras funções fornecidas que permitem converter um tempo normal em um LSN. Ao recuperar atualizações, é possível inclusive especificar para ver os valores anteriores e posteriores, ou apenas os anteriores. Para ver o screencast em que uso a captura de dados de alteração, visite www.technetmagazine.com/video.

Como o controle de alterações funciona

Como mencionei, o controle de alterações é um processo síncrono e bem menos complexo do que a captura de dados de alteração. Ele faz parte da transação que faz uma alteração na linha de uma tabela controlada, e o fato de que a linha foi alterada é controlado em uma tabela separada. É o que chamamos de tabela interna, e não existe nenhum controle sobre seu nome ou o local em que é armazenada. Não considero isso um problema, pois deve haver bem menos dados nessa tabela do que em uma tabela de alteração suada para capturar dados de alteração. Mas ainda pode haver problemas de espaço em disco, como explicarei daqui a pouco.

O fato de que o controle de alterações é feito de forma síncrona significa que há um processamento extra dentro de cada transação que altera a tabela controlada. O efeito sobre o desempenho é semelhante ao de quando um índice não clusterizado existe na tabela e deve ser atualizado a cada alteração que ela sofre. As transações em si também são controladas quando confirmadas por uma linha na tabela sys.syscommittab interna.

O controle de alterações é habilitado e desabilitado usando a sintaxe ALTER DATABASE e ALTER TABLE e segue o mesmo modelo que a captura de dados de alteração, na qual deve ser habilitado no nível do banco de dados antes do nível da tabela. A seqüência de operações deve ser semelhante à seguinte:

ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON
  (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
GO
USE AdventureWorks2000;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
  WITH (TRACK_COLUMNS_UPDATED = ON);
GO

As permissões necessárias para habilitar o controle de alterações no nível do banco de dados e da tabela também são diferentes das usadas para habilitar a captura de dados de alteração: db_owner e o proprietário da tabela, respectivamente. Quando o controle de alterações é habilitado no nível do banco de dados, é possível definir o período de retenção, bem como se os dados de alteração serão limpos automaticamente. O período de retenção padrão é 2 dias, com um máximo de 90 dias e um mínimo de um minuto.

A limpeza automática também é ativada por padrão. Ao fazer alterações nessas configurações, é necessário avaliar as mesmas compensações que expliquei com a captura de dados de alteração (basicamente, de espaço em disco e desempenho em relação às necessidades do aplicativo).

Por padrão, para cada linha, é capturado apenas que ela foi alterada. Isso é feito anotando a chave primária da linha que foi alterada (o que significa que o controle de alteração em uma tabela requer que ela tenha uma chave primária), junto com um número de versão (quando o banco de dados é habilitado para controle de alterações, um número de versão é instituído e permite a ordenação de operações) e o tipo de operação que fez a alteração. Opcionalmente, você também pode controlar quais colunas são alteradas, o que requer 4 bytes por coluna alterada.

O monitoramento de espaço em disco é um pouco diferente do controle de alterações, já que os dados de alteração são armazenados em tabelas internas. Para encontrar os nomes das tabelas internas usadas, basta usar a exibição de catálogo do sistema sys.internal_tables:

SELECT [name] FROM sys.internal_tables
  WHERE [internal_type_desc] = 'CHANGE_TRACKING';
GO

Depois, passe o nome em sp_spaceused para ver quanto espaço em disco está sendo usado.

Diferentemente da captura de dados de alteração, quando o controle de alterações é habilitado, há restrições sobre a DDL que podem ser executadas em uma tabela controlada. A restrição mais notável é que a chave primária não pode ser alterada de forma alguma. A outra restrição que vale destacar aqui é que um ALTER TABLE SWITCH irá falhar se o controle de alterações estiver habilitado na tabela envolvida. Isso se deve basicamente ao fato de que não faz sentido iniciar ou remover o controle de alterações automaticamente para uma partição retirada de uma tabela particionada e com controle de alterações ou uma tabela com controle de alterações colocada em uma tabela particionada, respectivamente.

As alterações são recuperadas das tabelas de alteração internas usando uma nova função CHANGETABLES (CHANGES …). Ela obtém o nome da tabela com controle de alterações mais o número da versão do tempo anterior em que foi usada e retorna as informações sobre todas as linhas que foram alteradas desde então. Há várias funções para localizar a versão válida atual e mais antiga. O aplicativo pode usar as informações retornadas para consultar a tabela com controle de alterações a fim de obter os valores de coluna reais. Isso, claro, é um processo de várias etapas; você obtém a versão atual, a usa para consultar o controle de alterações e, então, consulta nas tabelas os dados de coluna correspondentes àquela versão.

Em um sistema em constante alteração, é possível obter resultados inconsistentes ou incorretos, a menos que algum tipo de exibição sem alteração da versão, dos dados de alteração e dos dados da coluna seja mantido. Para isso, você pode usar o isolamento de instantâneo e encapsular o processo de várias etapas em uma transação explícita. Esse método funciona bem, mas apresenta algumas desvantagens. O isolamento de instantâneo pode afetar o desempenho da carga de trabalho e afeta o desempenho e o uso do espaço de tempdb. Para obter mais detalhes sobre isso, visite technet.microsoft.com/library/cc280358.

Conclusão

A Figura 4 fornece uma comparação lado a lado do controle de alterações e dos dados de alteração para que você possa ter uma idéia melhor das principais diferenças identificadas pelos DBAs. Você pode ver na tabela que a captura de dados de alteração é muito mais complicada do que o controle de alterações. Ela requer mais cuidado ao decidir o que controlar porque o tamanho da tabela de controle pode crescer rapidamente se, digamos, a tabela controlada tiver colunas BLOB ou linhas muito largas. Também pode haver problemas de gerenciamento de log de transações, já que o log não ficará truncado até que o leitor de log colete seus registros.

Figura 4 Comparação entre o controle de alterações e a captura de dados de alteração

Recurso Controle de alterações Captura de dados de alteração
Síncrono Sim Não
Requer o SQL Agent Não Sim
Força o registro em log total de algumas operações em massa Não Sim
Evita o truncamento de log Não Sim, até os registros de log serem coletados
Requer isolamento de instantâneo Recomendado Não
Requer tabelas separadas para armazenar os dados de controle Sim Sim
Requer chave primária Sim Não por padrão
Permite o posicionamento de tabelas de controle Não Sim
Potencial para problemas de consumo de espaço Pouco Muito
Processo de limpeza automática Sim Sim
Restrições quanto a DDL Sim Não
Permissão necessária para habilitar Sysadmin Proprietário do banco de dados

Contudo, o controle de alterações também tem seus requisitos. Por exemplo, é necessária uma chave primária e é extremamente recomendado usar isolamento de instantâneo quando o controle de alterações é habilitado. O isolamento de instantâneo em si pode adicionar uma sobrecarga de trabalho significativa e requer um gerenciamento de tempdb muito mais cuidadoso.

Ainda há um outro problema que os desenvolvedores e DBAs precisam enfrentar: a recuperação de desastre. Embora a discussão mais profunda sobre esse assunto esteja fora do escopo deste artigo, o tópico da recuperação de desastre é tão importante que não pode deixar de ser mencionado.

Os dois recursos funcionam bem com BACKUP e RESTORE. O problema surge quando um banco de dados é restaurado para um momento anterior. Como o aplicativo/sistema em geral deve se comportar? Soluções personalizadas criadas para controlar alterações também enfrentam esse problema, e ele ainda deve ser considerado ao usar o SQL Server 2008.

Como sempre, não deixe de ler toda a documentação disponível (technet.microsoft.com/library/bb418491) e os white papers existentes antes de embarcar em um projeto de design e implantação que envolva os novos recursos de controle de alterações. Primeiro você precisa descobrir se há outros possíveis problemas aplicáveis ao seu caso que não abordei aqui. Você também deve obter detalhes sobre os novos SPs e DMVs (exibição de gerenciamento dinâmico) de monitoramento.

Além desses novos recursos, houve um grande avanço nos métodos anteriores de controle de alteração de dados. Agora que eles existem, você pode ter certeza de que os desenvolvedores irão usá-los nas soluções que você gerencia.

Há questões de configuração e gerenciamento importantes a serem consideradas e espero que este artigo tenha lhe dado uma boa idéia das tecnologias para que você possa prever e se preparar para alguns dos problemas que discutimos. Se tiver algum comentário ou dúvida sobre este artigo, não hesite em me escrever, usando o endereço Paul@SQLskills.com.

Paul S. Randal é diretor administrativo da SQLskills.com e MVP do SQL Server. Ele trabalhou na equipe do mecanismo de armazenamento do SQL Server da Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Paul é especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e participa regularmente em conferências pelo mundo. Ele bloga em SQLskills.com/blogs/paul.