SQL Server

Noções básicas sobre logs e de recuperação no SQL Server

Paul S. Randal

 

Visão geral:

  • Como log e recuperação funcionam no SQL Server
  • Como funciona o log de transações e o que você precisa saber sobre gerenciá-lo
  • Modelos de recuperação e seu efeito sobre logs

Conteúdo

O que É registro?
O que É recuperação?
O log de transações
Modelos de recuperação
Quebra automática para cima

Algumas das partes mais mal compreendidas do SQL Server são o log e mecanismos de recuperação.O fato de que o log de transação existe e pode causar problemas se não gerenciada corretamente parece confound muitos "DBAs involuntárias". Por que é possível para o log de transação para aumentar acoplados?Por que às vezes demora tanto tempo para o banco de dados ficar online após uma falha no sistema?Por que não é possível o log ser desativado completamente?Por que não é possível recuperar meu banco de dados corretamente?Apenas o que é o log de transações e por que há-lo?

Essas são todas as perguntas que vejo repetidamente no SQL Server fóruns e newsgroups, portanto, neste artigo quer forneça uma visão geral do Registro e sistema de recuperação e explique por que ele é tal parte integral do mecanismo de armazenamento do SQL Server.Explicarei a arquitetura do log de transações e como os modelos de recuperação três disponíveis para um banco de dados podem alterar o comportamento do log de transações e o processo de log propriamente dito.Ao longo do caminho, também será fornecer alguns links para recursos abrangendo práticas recomendadas de transação log gerenciamento.

O que É registro?

Log e de recuperação não são conceitos que são exclusivos do SQL Server — todos os sistemas de gerenciamento comercial banco de dados relacional (RDBMSs) devem peça para oferecer suporte as várias propriedades ACID de transações.ACID significa atomicidade, consistência, isolamento e durabilidade, que sejam as propriedades fundamentais de um sistema de processamento de transação (por exemplo, um RDBMS).Você pode ler mais sobre isso naSeção de propriedades ACID da biblioteca MSDN.

Vídeo

Paul Randal demonstra a importância do gerenciamento o log de transações corretamente no modelo de recuperação completa, e ele mostra a você técnicas para fazer isso no SQL Server.

Operações em um RDBMS são registradas (ou registradas) no nível de termos o que acontece nas estruturas de armazenamento do banco de dados físico e lógico.Cada alteração nas estruturas de armazenamento tem seu próprio registro de log, que descreve a estrutura seja alterada e o que a alteração foi.Isso é feito de tal forma que a alteração pode ser repetida ou revertida, se necessário.Os registros de log são armazenados em um arquivo especial denominado log de transações, descreverei isso mais detalhadamente mais adiante, mas agora você pode pensá-lo como um arquivo seqüencial acesso.

Um conjunto de um ou mais essas alterações podem ser (e na verdade, sempre são) agrupados em uma transação, que fornece a unidade básica de fazer alterações (atomicidade) um banco de dados, longe como usuários, os desenvolvedores de aplicativos, e os DBAs estão envolvidos.Uma transação é bem-sucedida (confirmação) ou falha/é cancelada (revertendo).No primeiro caso, as operações que formam a transação têm a garantia para ser refletidas no banco de dados do.No segundo caso, as operações são garantia não ser refletida no banco de dados de.

Transações no SQL Server são marcas explícita ou implícita.Uma transação explícita é um em que o usuário ou o aplicativo emite uma instrução BEGIN TRANSACTION T-SQL, sinalização o início de um grupo de alterações relacionadas por sessão.Uma transação explícita é bem-sucedida quando uma instrução COMMIT TRANSACTION é emitida, sinalização a conclusão bem-sucedida do grupo de alterações.Se uma instrução ROLLBACK TRANSACTION for emitida em vez disso, todas as alterações feitas por sessão desde a instrução BEGIN TRANSACTION emitida são revertidas (revertido) e a transação for anulada.Uma reversão de transação também pode ser forçada por um evento externo, como o banco de dados com pouco espaço em disco ou uma falha de servidor, conforme explicarei posteriormente.

Uma transação implícita é um em que o usuário ou o aplicativo não explicitamente emite uma instrução BEGIN TRANSACTION antes da emissão de uma instrução T-SQL.No entanto, considerando que todas as alterações para o banco de dados devem ser transacionais, o mecanismo de armazenamento será iniciado automaticamente uma transação nos bastidores.Quando a instrução T-SQL é concluída, o mecanismo de armazenamento automaticamente confirma a transação que ele iniciado disposto ao redor de instrução do usuário.

Você pode pensar que isso não é necessário porque uma única instrução T-SQL não gera um grande número de alterações para as estruturas de armazenamento do banco de dados, mas considere algo parecido com uma instrução ALTER INDEX RECRIAR.Embora esta instrução não pode estar contida em uma transação explícita, ele foi possível gerar um número enorme de alterações para o banco de dados.Portanto, deve haver algum mecanismo para garantir que se algo errado (a instrução for cancelada, por exemplo), todas as alterações são corretamente revertidas.

Como exemplo, considere o que acontece quando uma linha única tabela é atualizada em uma transação implícita.Imagine uma tabela de heap simples com um c1 de coluna inteiro e um c2 de coluna char.A tabela tem 10.000 linhas e um usuário envia uma consulta de atualização da seguinte maneira:

UPDATE SimpleTable SET c1 = 10 WHERE c2 LIKE '%Paul%';

Ocorrem as seguintes operações:

  • As páginas de dados do SimpleTable são lidas do disco na memória (o pool de buffer) para que eles podem ser pesquisados para linhas correspondentes. Acontece que as páginas de dados de três mantenha cinco linhas que correspondem ao predicado da cláusula WHERE.
  • O mecanismo de armazenamento é iniciado automaticamente uma transação implícita.
  • As páginas de dados de três e linhas de dados cinco são bloqueadas para permitir que as atualizações aconteçam.
  • As alterações são feitas aos dados cinco registros nas páginas três dados na memória.
  • As alterações também serão gravadas em registros de log no log de transações no disco.
  • O mecanismo de armazenamento confirma a transação implícita automaticamente.

Observe que eu não listar uma etapa em que as páginas de dados atualizados três são gravadas novamente fora em disco. Isso ocorre porque eles ainda não precisam ser; desde que os registros de log descrevem as alterações estão no disco no log de transações, as alterações estão protegidas. Se as páginas precisam ser posteriormente lido ou alterado novamente, em seguida, a cópia mais atualizada da página já está na memória, não no disco (ainda). As páginas de dados serão gravadas check-out no disco quando a próxima operação de ponto de verificação ocorre ou se a memória que usarem no pool de buffer é necessária para outra imagem de página.

Pontos de verificação existem por duas razões — ao lote up gravação e / ss para melhorar o desempenho e reduzir o tempo necessário para recuperação de falha. Em termos de desempenho, se uma página de dados eram forçada check-out para o disco sempre que ele foi atualizado, o número de gravação de E/s que ocorrem em um sistema ocupado poderia facilmente sobrecarregar o subsistema de E/s. É melhor gravar periodicamente sujas páginas (páginas que foram alteradas desde a leitura do disco) que escrever páginas imediatamente como elas são alteradas. Discutirei o aspecto da recuperação dos pontos de verificação em alguns instantes.

Uma concepção equivocada sobre pontos de verificação é que eles apenas gravam páginas com as alterações das transações confirmadas. Isso não é verdade, um ponto de verificação sempre gravará todas as páginas sujas, independentemente se a transação que alterados de uma página foi confirmada ou não.

Log de Write-ahead é o mecanismo no qual os registros de log que descreve uma alteração estão gravados no disco antes das alterações se são gravadas. Ele fornece a parte de durabilidade as propriedades ACID. Desde que os registros de log descrevendo alterações estejam no disco, no caso de uma falha, os registros de log (e, portanto, as alterações se) podem ser recuperados e os efeitos da transação não são perdidos.

O que É recuperação?

Procurando dicas do SQL Server?

Para obter dicas sobre como SQL Server, visite o Dicas do TechNet Magazine SQL Server a página.

Para obter mais dicas sobre outros produtos, visite o Índice da TechNet Magazine dicas.

Log existe para dar suporte a uma variedade de operações no SQL Server. Ele garante que se ocorrer uma falha, uma transação confirmada corretamente refletirão no banco de dados após a falha. Ele garante que uma transação não confirmada será ser revertida corretamente e não refletida no banco de dados após uma falha. Ele garante que é possível cancelar uma transação em andamento e tem todas as suas operações revertida. Ele permite que uma cópia de backup do log de transação a serem tomadas para que possa ser restaurado a um banco de dados e os backups de log de transação repetidos para colocar o banco de dados a um ponto específico no tempo com consistência transacional. E oferece suporte a recursos que dependem de ler o log de transações, como a replicação, o espelhamento do banco de dados e captura de dados de alteração.

A maioria desses usos de log envolve um mecanismo chamado de recuperação. Recuperação é o processo de ter as alterações descritas nos registros de log repetidos ou revertido no banco de dados. Repetição de log é chamado a REFAZER (ou rolo frente) fase de recuperação. Log Revertendo registros é chamado a desfazer (ou reversão) fase de recuperação. Em outras palavras, recuperação será Verifique se uma transação e todos os seus registros de log constituintes são o refeitas ou desfeitos.

A forma simples de recuperação é quando uma única transação for cancelada, nesse caso é desfeita e não é nenhum efeito líquido no banco de dados. A forma mais complexa é a recuperação de falha — ao SQL Server falhar (por qualquer motivo) e o log de transações deve ser recuperado para trazer o banco de dados para um ponto de forma transacional consistente. Isso significa que todas as transações foram confirmadas no momento da falha devem ser roladas frente para garantir que seus efeitos são mantidos no banco de dados. E todas as transações em andamento que não tinham confirmado no momento da falha devem ser revertidas para garantir que seus efeitos não são persistentes no banco de dados.

Isso ocorre porque não há nenhum recurso de uma transação no SQL Server para continuar após uma falha. Portanto, se os efeitos de uma transação parcialmente concluída não são desfeitos, o banco de dados deve ficar em um estado inconsistente (possivelmente mesmo estruturalmente corrompido, dependendo do que a transação foi no meio de fazer).

Portanto, como recuperação sabe o que fazer? Todos os processos de recuperação dependem do fato de que cada registro de log é marcado com um número de seqüência de log (LSN). Um número de seqüência de log é um número de aumento constante, três partes que define a posição de um registro log o log de transações. Cada registro de log em uma transação é armazenado em ordem seqüencial dentro o log de transação e contém o ID de transação e o LSN do registro de log anterior para a transação. Em outras palavras, cada operação que está registrada como parte da transação tem um "link" volta para a operação que imediatamente precedidos-lo.

Para o caso simples de uma única transação ser revertida, o mecanismo de recuperação pode facilmente e rapidamente siga a cadeia de operações registradas da operação mais recente volta para a primeira operação e desfazer os efeitos das operações na ordem oposta do qual eles ocorreram. As páginas do banco de dados que foram afetadas pela transação são ou ainda no pool de buffer no disco. Em ambos os casos, a imagem da página que está disponível é garantido que ser um no qual o efeito da transação será refletido na página e deve ser desfeita.

Durante a recuperação de falha, o mecanismo é mais complicado. O fato de que páginas do banco de dados não estão gravadas no disco quando uma transação confirmada significa que não há nenhuma garantia de que o conjunto de páginas do banco de dados no disco precisamente o conjunto de alterações descritas no log de transações — para transações confirmadas ou não confirmadas. No entanto, há uma parte final do quebra-cabeça que ainda não mencionados ainda — todas as páginas do banco de dados tiver um campo em seu cabeçalho de página (uma parte de 96 bytes da página 8192 bytes que contém metadados sobre a página) que contém o LSN do último registro log que afetados a página. Isso permite que o sistema recuperação decidir o que fazer sobre um registro de log específico que ele deve recuperar:

  • Para um registro de log de uma transação confirmada em que a página de banco de dados tem um igual de LSN a ou maior que o LSN do registro de log, nada precisa ser feito. O efeito do registro de log já tenha sido persistentes na página no disco.
  • Para um registro de log de uma transação confirmada em que a página de banco de dados tem um LSN menor que o LSN do registro de log, o registro de log deve ser refeito para garantir que os efeitos de transação são mantidos.
  • Para um registro de log de uma transação não confirmado em que a página de banco de dados tem um igual de LSN a ou maior que o LSN do registro de log, o registro de log deve ser desfeito para garantir que os efeitos de transação não são persistentes.
  • Para um registro de log de uma transação não confirmado em que a página de banco de dados tem um LSN menor que o LSN do registro de log, nada precisa ser feito. O efeito do registro de log não foi mantido na página no disco e assim não precisa ser desfeita.

Recuperação de falha lê através do log de transações e garante que todos os efeitos de transações confirmadas todos são mantidos no banco de dados, e todos os efeitos de todas as transações não confirmadas não são persistentes no banco de dados — o RETRABALHO e desfazer fases, respectivamente. Depois que a recuperação de falha for concluído, o banco de dados é transacional consistente e disponibilizado para uso.

Mencionei anteriormente que um dos usos de uma operação de ponto de verificação é reduzir a quantidade de tempo que utiliza de recuperação de falha. Por periodicamente liberar todas as páginas com problemas no disco, o número de páginas que alterou por causa de transações confirmadas mas cujas imagens não estão no disco é reduzido. Isso, por sua vez, reduz o número de páginas que precisa ter aplicada durante a recuperação de falha de recuperação de REFAZER.

O log de transações

Recuperação de falha é possível somente se o log de transação está intacto. Na verdade, o log de transações é a parte mais importante do banco de dados — é o único local onde todas as alterações para o banco de dados são garantidas a ser descrita no caso de uma falha.

Se o log de transação estiver faltando ou danificado após uma falha, em seguida, recuperação de falha não é concluída, levando a um banco de dados suspeito. Nesse caso, o banco de dados deve ser restaurado a partir de backups ou recuperados usando opções menos desejáveis, tais como correção do modo de emergência. (Esses procedimentos estão além do escopo deste artigo mas serão abordados na profundidade nos artigos posteriormente no ano).

O log de transações é um arquivo especial que cada banco de dados deve ter para funcionar corretamente. Ele contém os registros de log que são produzidos de fazer logon e são usados para lê-las novamente durante a recuperação (ou qualquer dos outros usos de log que já mencionei). Bem como o espaço ocupado pelos registros de log próprios, uma transação também será reservar espaço no log de transações de qualquer potencial registros de log necessário se a transação tivesse que ser cancelado e necessárias para reverter. Este contas para o comportamento você poderá observar onde, digamos, uma transação que atualiza a 50 MB de dados no banco de dados, na verdade, poderá solicitar 100 MB de espaço de log de transação.

Quando um novo banco de dados é criado, o log de transação está essencialmente vazio. Medida transações ocorrerem, registros de log são gravados em seqüência o transação log, que significa que não há nenhum ganho de desempenho de criar transações de vários arquivos de log — uma muito concepção equivocada. O log de transações usará cada arquivo de log por sua vez.

Registros de log para transações simultâneas podem ser intercalados no log de transações. Lembre-se de que registros de log para uma única transação são vinculados por suas LSNs, portanto, não há necessidade para todos os registros de log para uma transação a serem agrupadas juntas no log. LSNs quase podem ser pensados como um carimbo de data / hora.

A arquitetura física do log de transação é mostrada na Figura 1 . Ele é dividido internamente em partes menores chamados virtual arquivos de log (ou VLFs). Esses são apenas um recurso mais fácil gerenciamento interno do log de transação. Quando um VLF fica cheio, fazer automaticamente prosseguirá para usar a próxima VLF no log de transações. Você pode pensar que, eventualmente, o log de transações será executado fora do espaço, mas isso é onde o log de transações é tão diferente dos arquivos de dados.

fig01.gif

Figura 1 arquitetura física da transação de logon

O log de transações é realmente um arquivo de circular — desde que os registros de log no início do log de transações tiverem sido truncados (ou desmarcados). Em seguida, quando o log atinge o final do log de transação, ele será disposto ao redor para o início novamente e começa sobrescrevendo o que estava lá antes.

Então, como log obter truncado para o espaço ocupados por eles pode ser reutilizado? Um registro de log não for mais necessário no log de transações se todas as dos seguintes forem verdadeiras:

  • A transação do qual ele é parte foi confirmada.
  • As páginas do banco de dados que alterá-lo foram todos gravadas em disco por um ponto de verificação.
  • O registro de log não é necessário para um backup (completo, diferencial ou log).
  • O registro de log não é necessário para qualquer recurso que lê o log (como o espelhamento do banco de dados ou replicação).

Um registro de log que ainda é necessário é chamado ativo, e um VLF que tenha pelo menos um registro de log ativo também é chamado ativo. Vez com freqüência, o log de transações é verificado para ver se todos os registros log em um total VLF ativos ou não; se forem todos inativos, o VLF é marcado como truncado (ou seja, que o VLF pode ser substituído depois que o log de transações quebra). Quando um VLF for truncado, ele não é substituído ou zerado de qualquer forma — ele apenas é marcado como truncado e, em seguida, pode ser reutilizado.

Esse processo é chamado de truncamento do log — não deve ser confundida com, na verdade, reduzindo o tamanho do log de transação de. Truncamento de log nunca altera o tamanho físico do log de transação — somente quais partes do log de transações são ativos ou não. a Figura 2 mostra o log de transações da Figura 1 após Ocorreu truncamento.

fig02.gif

A Figura 2 A transação logon após truncamento do log

Ativo VLFs compõem o log lógico — a parte do log de transações que contém todos os registros de log ativo. O próprio banco de dados sabe onde a recuperação de falha deve começar a ler registros de log na parte do log ativo — o início da transação ativa mais antigo no log, o MinLSN (isso é armazenado na página de inicialização do banco de dados).

Recuperação de falha não sabe onde parar de ler registros de log, portanto, ele continua até alcançar uma seção zerada do log de transações (se o log de transações ainda não tiver quebradas) ou um registro de log cujos bits de paridade não se ajustam a seqüência do registro de log anterior.

Como VLFs ficarem truncados e novos são ativados, o log de lógico move no arquivo de log de transação física e eventualmente deve ser disposto ao redor para o início novamente, conforme mostrado na A Figura 3 .

fig03.gif

A Figura 3 A natureza circular do log de transações

A verificação se truncamento de log pode ocorrer-se em uma das seguintes circunstâncias:

  • Quando um ponto de verificação ocorre no modelo de recuperação simples ou em outros modelos de recuperação quando nunca foi colocado em um backup completo. (Isso significa que um banco de dados permanecerá em um modelo de recuperação pseudo-SIMPLE após sendo alternado de SIMPLE até que ocorra um backup completo do banco de dados.)
  • Quando um backup do log for concluída.

Lembre-se que truncamento de log não pode ser possível por causa das muitas razões que um registro de log deve permanecer ativo. Ao truncamento do log não pode ocorrer, os VLFs não podem ser truncados e, eventualmente, o log de transação tem a crescer (ou outro arquivo de log de transação ser adicionados). Crescimento de log de transação excessiva pode causar problemas de desempenho por meio de um fenômeno conhecido como fragmentação VLF. Remover VLF fragmentação, às vezes, pode levar a uma melhoria drástica no desempenho de atividades relacionadas de log.

Para obter mais informações sobre isso, consulte blog do Kimberly Tripp lançar" As etapas 8 a melhorar a taxa de transferência de log de transações." Adriana aborda as práticas recomendadas relacionadas à transação log capacidade de planejamento, gerenciamento e melhor desempenho — é vale a pena ler!

Há dois problemas comuns que podem impedir o truncamento do log:

  • Uma transação de ativa de execução demorada. O log de transação inteira como o primeiro registro de log da transação ativa mais antiga nunca pode ser truncado até que essa transação confirma ou anula.
  • Alternar para o modelo de recuperação total, fazer um backup completo e, em seguida, nunca fazer qualquer faça backups. O log de transações toda permanecerá ativo, aguardando para ser feito por um backup do log.

Para obter uma lista completa de fatores e instruções sobre como determinar o que está impedindo o truncamento do log, consulte o tópico manuais online do SQL Server" Fatores que podem atraso truncamento do log." Também criei uma demonstração de vídeo que mostra o efeito de crescimento de log de transação não controlado e como remover VLF fragmentação — check-out screencast vídeo (e screencasts anterior sobre tópicos SQL) em technetmagazine.com/videos.

Se o log de transações crescer a capacidade e não é possível aumentar qualquer Além disso, em seguida, erro 9002 será relatado e será necessário executar etapas para fornecer mais espaço, como crescimento o arquivo de log, adicionar outro arquivo de log ou remover qualquer impedimento para o log sendo truncado.

Sob nenhuma circunstância deve você excluir o log de transações, tente recriá-lo usando comandos não documentados ou simplesmente truncá-lo usando as opções NO_LOG ou TRUNCATE_ONLY do LOG de BACKUP, que foram removidas do SQL Server 2008). Essas opções irão causar inconsistência transacional (e mais provável corrupção) ou remover a possibilidade de ser capaz de recuperar corretamente o banco de dados.

Para obter mais informações sobre como solucionar um log de transações completo, consulte o tópico de manuais online do" Solucionando problemas de um log de transações total (erro 9002)."

Modelos de recuperação

Como você pode ver, o comportamento do log de transações depende em parte no modelo de recuperação do que banco de dados está usando. Há três modelos de recuperação disponível, e todos eles têm um efeito no comportamento de log de transação como operações são registradas ou ambos.

O modelo de recuperação total significa que cada parte de cada operação está conectado, o que é chamado estar totalmente conectado. Depois que um backup completo do banco de dados foi colocado no modelo de recuperação total, o log de transações não será automaticamente truncar até que um backup do log é obtido. Se desejar fazer uso de backups de log e a capacidade de recuperar um banco de dados para um ponto específico em tempo, não use o modelo de recuperação total. No entanto, se você quiser usar o espelhamento do banco de dados, em seguida, você não tem nenhuma opção, como ele suporta apenas o modelo de recuperação total.

O modelo de recuperação BULK_LOGGED tem a mesma semântica de truncamento de log de transação como o modelo de recuperação total mas permite que algumas operações a serem registradas parcialmente, o que é chamada minimamente sendo registrados. Alguns exemplos são uma reconstrução de índice e algumas operações de carregamento em massa — no modelo de recuperação total a toda a operação é registrada.

Mas no modelo de recuperação BULK_LOGGED somente a alocação alterações são registradas, que reduz drasticamente o número de registros de log produzido e, por sua vez, reduz o potencial de crescimento de log de transação. Para obter mais informações sobre operações registradas no mínimo, consulte a seção Books Online" Operações que podem ser registradas no mínimo."

Finalmente, o modelo de recuperação simples, na verdade, tem o mesmo comportamento de log como a recuperação BULK_LOGGED, mas a semântica de truncamento do log de transação é bastante diferente. Backups do log não são possíveis no modelo de recuperação simples, o que significa que o log pode ser truncado (desde que nada mais é mantém registros de log ativo) quando ocorre um ponto de verificação. Há vantagens e desvantagens a cada um desses modelos de recuperação em termos de que os backups são possíveis (ou necessário) e a capacidade de recuperar para vários pontos no tempo (FALAREI sobre isso em outro artigo posteriormente neste ano).

Quebra automática para cima

Este artigo foi realmente uma explicação mais Acadêmica do como uma parte crítica do SQL Server funciona. Espero que tenha gerenciado para limpar os erros de concepção que você talvez tenha tido. Se esta for a primeira introdução ao log e recuperação, estes são os pontos-chave que gostaria de você se longe neste artigo:

  • Não crie vários arquivos de log, como ele não levará a um ganho de desempenho.
  • Conhecer o modelo de recuperação do banco de dados está usando e o efeito no log de transação — especialmente ao redor se ele pode automaticamente truncar ou não quando ocorre um ponto de verificação.
  • Conhecer o potencial de crescimento de log de transação, os fatores que podem levar a ele e como obtê-lo voltar sob controle.
  • Sabe onde procurar ajuda ao solucionar um log de transações completo.

No meu blog, tem que muito mais informações sobre o log de transações e fatores que afetam — consulte meu categoria de postagem de blog " Log de transação"para obter mais detalhes. Vários tópicos de manuais online sobre o log de transações também são muito boas — começando com Gerenciamento de log de transações.

Como sempre, se você tiver quaisquer comentários ou dúvidas, por favor, solte-me uma linha no Paul@SQLskills.com.

Graças à l Kimberly. Tripp para fornecer uma revisão técnica de neste artigo.

S. Paul Randal é o diretor de gerenciamento de SQLskills.come um MVP do SQL Server. Ele trabalhou na equipe mecanismo de armazenamento do SQL Server da Microsoft de 1999 para 2007. Paul escreveu DBCC CHECKDB/reparo para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Paul é um especialista em recuperação de desastres, alta disponibilidade e manutenção de banco de dados e é um apresentador regular em conferências em todo o mundo. Blogs de he em SQLskills.com/blogs/paul.