Recuperação de desastre do SQL Server

  • Artigo

SQL Server: Recuperando-se de desastres usando backups

Paul S. Randal

T aqui não é muito ponto levando backups do SQL Server a menos que você sabe como restaurá-los. Se você tiver algo mais complicado que apenas um backup completo do banco de dados, você vai precisar saber algumas opções RESTORE para poder restaurar com êxito seu banco de dados para o ponto desejado no tempo.

Isso é ainda mais o caso se você tiver um layout de banco de dados complicada ou uma estratégia de backup complexa e você deseja ser capaz de restaurar, por exemplo, um único arquivo ou grupo de arquivos, ou tirar proveito de disponibilidade parcial do banco de dados.
Contanto que você tiver uma estratégia eficaz de backup e os backups são válidos, você poderá recuperar de um desastre dentro de seu RTO (Recovery Time Objective) e para sua RPO (Recovery Point Objective). O primeiro artigo desta série de três partes, discuti vários tipos de backups e como formular uma estratégia de backup (consulte "Noções básicas sobre backups do SQL Server" na edição de julho de 2009).

Neste artigo, explicarei como funciona a restauração e como executar algumas operações de restauração mais comuns. Ele será útil se você leu o artigo de backup e o material de plano de fundo que mencionei na introdução deste artigo. Também vou explicar alguns mais complicadas operações, como fazer uma restauração de ponto no tempo e uma restauração piecemeal online com disponibilidade parcial do banco de dados.

Como no artigo anterior no BACKUP, não vou para explicar como funciona a sintaxe RESTORE ou percorrer as etapas específicas de todas as operações de restauração. MANUAIS online faz um excelente trabalho que. Consulte"RESTORE (Transact-SQL)"para obter mais informações, especialmente os exemplos espalham em todo o tópico. Há realmente tantas opções para RESTORE que é um inteiro outro tópico para explicá-los! " Fazendo backup e restaurando tópicos como (SQL Server Management Studio)"explica como usar as ferramentas para executar restaurações.

Quatro fases de restauração

Vamos começar com como restauração realmente funciona. Uma operação de restauração tem até quatro fases:

  1. Criação de arquivo e a inicialização
  2. Cópia de log de dados e/ou transação
  3. REFAZER a fase de recuperação
  4. DESFAZER a fase de recuperação

Uma das principais metas de recuperação de desastres é colocar o banco de dados online rapidamente possível. Se seu plano de recuperação de desastres envolve restaurar backups (em vez de, digamos, fazer failover para um espelho de banco de dados), você vai desejar que o processo de restauração deve ser o mais rápido possível. Com cada quatro etapas de restauração em mente, há algo que você pode fazer para acelerar as?

A primeira etapa pode ser ignorada essencialmente se os arquivos de log e dados já existem. Isso significa que se você vai sobrescrever um banco de dados existente, não descartar o banco de dados antes de executar a restauração. Em vez disso, use a opção WITH REPLACE na primeira operação de restauração para dizer ao SQL Server para usar arquivos existentes. Se os arquivos não existirem, eles serão criados e inicializados em seguida. Criar os arquivos é muito rápida, mas o processo de zero-Inicializando-los pode ser muito lento.

Por motivos de segurança e por padrão, todos os arquivos de banco de dados são inicializada para zero. Você pode habilitar a inicialização instantânea de arquivo para a instância do SQL Server, qual pulará processo zeroing para arquivo de dados crie e crescer operações, incluindo aquelas necessárias durante uma restauração--possivelmente economizando horas de inatividade, mesmo se os arquivos de dados são somente gigabytes de tamanho. Arquivos de log de transações são sempre zero inicializado devido à natureza circular do log de transação própria.

Você pode ler mais sobre tudo isso com referências a Books Online, na minha "Inicialização instantânea" categoria de postagem de blog.

Você pode estar se perguntando sobre a segunda fase--por que o item dizer "e / ou log de transação"? Se você ler o artigo anterior, você irá se lembrar de que todos os backups diferenciais e completos também incluam alguns registros de log de transação, para habilitar o banco de dados a ser restaurado para um ponto de forma transacional consistente no tempo. Fase dois é uma operação de cópia puro--nenhum processamento dos dados é realizado--portanto a principal forma de acelerar isso é ter um subsistema de E/s better-performing. Essa é uma algumas vezes quando é aceitável "throw hardware no problema."

Outra maneira para acelerar a fase de cópia é usar algum tipo de tecnologia de compactação de backup, ambos nativo para o SQL Server 2008 ou através de uma das várias soluções de terceiros. Duas partes da fase de cópia são leitura da mídia de backup e gravando os arquivos de dados e/ou log. Se você não pode fazer leituras de menos (usando mídia de backup compactadas), você pode acelerar o processo geral às custas de uma pequena quantidade de recursos da CPU.

Fases três e quatro são sobre executando recuperação no log de transação para colocar o banco de dados para um ponto de forma transacional consistente no tempo. Expliquei detalhes de recuperação no artigo de fevereiro de 2009"Noções básicas sobre registro em log e recuperação no SQL Server". Observe que fase quatro é opcional, como explicarei posteriormente.

É suficiente dizer que o log de transação mais que precisa ser recuperado durante uma restauração, levará mais tempo a restauração. Isso significa que se, por exemplo, você tem um backup completo do banco de dados de uma semana atrás e hourly backups de log de transações desde então, o processo de restauração será essencialmente repetição todas as transações da última semana antes da conclusão. Discuti uma solução para este artigo anterior--adicionando os backups diferenciais em uma estratégia de backup total plus log.

Um backup diferencial do banco de dados contém todas as páginas de arquivo de dados que foram alterados desde o último backup completo do banco de dados e podem ser usadas em uma operação de restauração para evitar a repetição todas as transações que ocorreram no período entre o backup completo do banco de dados e o backup diferencial do banco de dados. Isso pode reduzir consideravelmente o tempo para restaurar o banco de dados, mas às custas de uma estratégia de backup um pouco mais complicada.

Você pode encontrar mais informações no tópico Books Online"Otimizando o backup e desempenho de restauração no SQL Server".

Que você precisa para restauração?

Quando o desastre, a primeira coisa que você precisa fazer é trabalhar fora o que foi danificado, como vai para ditar ações que você deve tomar para recuperar do desastre. Falha de mídia de armazenamento, as possibilidades incluem:

  • Danos a todo o banco de dados (por exemplo, tudo o que era armazenar o banco de dados foi destruído, ou o banco de dados era um arquivo de dados único e foi danificado).
  • Danificar um único grupo de arquivos de um banco de dados do grupo de multi-arquivos.
  • Danificar um único arquivo de um grupo de arquivos multiarquivos.
  • Danos a uma única página no banco de dados.
  • Danos se espalham por banco de dados.

Você pode avaliar os danos por examinando o log de erro do SQL Server para notificações de arquivo (s) são inacessíveis, leitura de página ocorreram erros (para instância, falhas de soma de verificação de página ou um erro de detecção de página interrompida) ou corrupção geral foi encontrada. Se ocorreram danos, é prática usual para executar a operação de verificação de consistência de DBCC CHECKDB para ter uma idéia de como difundido o dano é.

Uma explicação de verificação de consistência está além do escopo deste artigo, mas você pode assistir um vídeo de uma apresentação feitas no Tech-Ed IT Forum em novembro de 2008 intitulado"Técnicas de sobrevivência corrupção"e ouvir uma entrevista TechNet Radio do anteriormente este ano onde discutir corrupção do banco de dados (download direto são links aqui).

Desastres não estão limitados a falhas de servidor ou subsistema de E/s--também há erro humano considerar. Tabelas de banco de dados (ou dados a partir deles) são freqüentemente acidentalmente excluídos por aplicativos mal programados ou descuidadas instruções Transact-SQL (o cenário "Eu não percebe que estava no servidor de produção"). Em tais casos, pode ser muito difícil figura fora o que precisa ser restaurado e de qual ponto no tempo, especialmente se ninguém possui para o cometer. Você pode obter sorte usando relatórios padrão do rastreamento padrão onde a operação do DDL ainda está disponível ou a instrução DELETE foi detectada pelo seu próprio log--mas geralmente não há nenhum registro de quem fez o que o banco de dados. Discutirei recuperar dessa situação em mais detalhes posteriormente. Independentemente de quem executou a exclusão acidental de dados ou quando ele aconteceu, mais tempo esperar para recuperar--ou mais tempo passa antes que sejam feitas ciente do problema--mais complexo pode ser para recuperar.

Portanto, como uma primeira etapa se o banco de dados está sendo executado no modelo de recuperação FULL e log de transações não danificado, execute um backup de cauda de log para garantir que todas as transações até o ponto do desastre são backup. Esse backup de log de transação "final" terá tudo até o momento do desastre e pode ser usado para colocar o banco de dados restaurado, longe como possíveis, possivelmente atualizadas.

Resumindo, você precisa trabalhar fora ter que restaurar. Em seguida, ele se torna uma pergunta o que você é capaz de restaurar.

É possível restaurar o que são?

O objetivo de qualquer operação de restauração é restaurar backups de possíveis mais baixas, portanto a operação de restauração é o mais rápida possível e conclui dentro RTO, permitindo também atender às sua RPO.

A pergunta principal para perguntar aqui é "What backups preciso?" Se o backup apenas que você tem é um backup completo do banco de dados de uma semana atrás e todo o banco de dados foi perdido, há apenas uma restauração opção--para um ponto no tempo de uma semana atrás, perder todo trabalho desde então. Simplesmente, sua estratégia de backup deve sempre garantir que sejam capazes de restaurar o que você precisa no caso de desastre, como discutido no artigo anterior.

Então, como determinar quais backups ter disponível? Primeiro, você pode consultar vários backup histórico tabelas no banco de dados msdb. Essas tabelas contêm um registro de todos os backups foram tomadas na instância do SQL Server desde a última vez que as tabelas de histórico de backup foram limpas.

Como diz respeito backups em si, é uma prática recomendada para nomear arquivos de backup para incluir o banco de dados, tipo de backup, data e hora para que o backup pode ser identificado de relance. Se você ainda não tiver feito isso, você pode descobrir que um arquivo de backup contém usando o comando RESTORE HEADERONLY. Isso exibirá o conteúdo do cabeçalho do arquivo de backup, essencialmente os metadados que descreve o backup propriamente dito. Você pode ler mais no tópico Books Online "Exibindo informações sobre backups".

Usando qualquer método, você está tentando descobrir a seqüência de restauração para usar para restaurar os dados danificados ou excluídos. Uma seqüência de restauração é um conjunto de backups deve ser restaurado e a ordem apropriada para restaurá-los. A seqüência de restauração pode ser simples como apenas um backup completo (de um banco de dados, grupo de arquivos ou arquivo), ou um conjunto complicado de completo, diferencial e backups de log de transação.

Por exemplo, imagine um cenário onde envolve a estratégia de backup completo do banco de dados, banco de dados diferencial e backups de log de transação. Se ocorre uma falha do sistema e os arquivos de dados estão danificados, o que é a seqüência de restauração? Figura 1 ilustra esse exemplo.

Nesse caso, a seqüência de restauração mais curto e mais rápida é o backup completo do banco de dados mais recente (F), o backup do banco de dados diferencial mais recente (D2) e, em seguida, todos os subseqüentes backups de log de transações, até e incluindo o backup de cauda de log (L7 e L8).

Um dos problemas complicados ao planejar uma seqüência de restauração está localizando o backup de log da primeira transação necessários para restaurar (às vezes chamado localizando "mínimo LSN" ou "mínimo-log número seqüencial"). No exemplo a do Figura 1, somente backups de log de transações L7 e L8 são necessários, pois o backup do banco de dados diferencial D2 traz o banco de dados para um ponto mais recente no tempo do que a transação anterior backups de log.

Figura 1: Seqüência de restauração de exemplo

SQL Server permitirá anterior, desnecessários log de transações backups a serem restaurados, mas eles não serão usados e essencialmente apenas desperdício de recuperação de desastres time.continuing meu exemplo, o que aconteceria se D2 de backup do banco de dados diferencial foi danificado ou faltando? Figura 2 mostra esse caso.

Figura 2: Restaurar a seqüência com um BackUp do banco de dados diferencial danos

Nesse cenário, a seqüência de restauração mais curto e mais rápida é o backup completo do banco de dados mais recente (F), o próximo backup de banco de dados diferencial mais recente (D1) e, em seguida, todos os subseqüentes backups de log de transações (L4, L5, L6, L7 e L8). É possível somente como backups D1, L4, L5 e L6 ainda estão disponíveis. É importante que você não excluir backups muito cedo; caso contrário, você poderia executar problemas durante um desastre.

Por exemplo, se o backup completo do banco de dados F estiver danificado, a menos que o backup completo do banco de dados anterior ainda está disponível, o banco de dados não será recuperável. Se o backup do banco de dados diferencial D1 for excluído como D2 for concluída, em seguida, o cenário do Figura 2 não será possível e a seqüência de restauração envolverá todos os backups de log de transação desde o backup completo do banco de dados--uma seqüência de restauração potencialmente muito longo.

Isso suscita a pergunta de "Quando você deve excluir os backups anteriores?" A resposta é definitivamente "It depende!" Se você não tiver uma obrigação legal de manter seus backups ao redor de um determinado período de tempo, em seguida, ele você e depende da estratégia de backup que você tem e quanto espaço em disco é necessário. Independentemente disso, não imediatamente excluir os backups anteriores como um novo é tirado; é melhor manter pelo menos um ou dois concluídos ciclos de backups antes de livrar dos backups antigos. Idealmente, você deve testar seus backups antes de remover os mais antigos.

Para backups de log de transação, em geral você deve ter todos eles desde o último backup completo do banco de dados foi tirado, como é que a seqüência de restauração de retorno final. Se uma única transação efetuar backup do log de transação backup "cadeia" está faltando ou danificado, não é possível continuar a operação de restauração anteriores a lacuna. Como mencionei no artigo anterior, verificando a integridade dos backups é uma parte fundamental de poder restaurar com êxito.

Você pode encontrar mais detalhes em descobrir o que você é capaz de restaurar o tópico abrangente Books Online"Trabalhando com seqüências de restauração para bancos de dados do SQL Server".

Cenários de restauração de exemplo

O cenário mais comum de restauração envolve um backup completo do banco de dados e, em seguida, um ou mais backups de log de transações para colocar o banco de dados frente no tempo. Isso pode ser feito através do SQL Server Management Studio (SSMS) ou por meio do TRANSACTA-SQL, embora haja algo que precisa estar ciente se você vai usar RESTORE comandos diretamente.

Quando um backup restaurado, há três opções para como a operação de restauração for concluída e todos eles se relacionam a fase UNDO de recuperação. Como cada backup sucessiva na seqüência de restauração é restaurado, a fase REDO de recuperação é sempre executada mas fase Desfazer não pode ser executada até o último backup na cadeia de backup do log de transação foi restaurado. Isso é porque como recuperação for concluída, nenhum backups do log de transações adicionais podem ser aplicados, portanto todos restaura em deve especificar a seqüência de restauração para não executar a fase UNDO de recuperação.

Infelizmente, o padrão é executar a fase UNDO de recuperação--o equivalente a usar a opção WITH RECOVERY na instrução RESTORE. Ao restaurar vários backups, você deve ter cuidado cada uma Especifica WITH NORECOVERY. Na verdade, a maneira mais segura é usar a opção WITH NORECOVERY em todas as restaurações na seqüência de restauração e manualmente conclua recuperação posteriormente. Eis alguns exemplo de código TRANSACTA-SQL para restaurar um backup completo do banco de dados e dois backups de log de transação e concluir manualmente recuperação colocar o banco de dados online:

RESTORE DATABASE DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Full_051709_0000.bak'
COM CHECKSUM, SUBSTITUIR NORECOVERY;
IR

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0100.bak'
COM NORECOVERY;
IR

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
COM NORECOVERY;
IR

RESTORE DATABASE DBMaint2008 WITH RECOVERY;
IR

Observe que também usei a opção de CHECKSUM na restauração do backup completo do banco de dados para garantir que qualquer somas presentes no banco de dados que estão sendo restaurado são verificadas como eles são restaurados.

Se não WITH NORECOVERY foi especificado na primeira instrução RESTORE, será retornado o seguinte erro:

Msg 3117, nível 16, estado 1, linha 1
O log ou backup diferencial não pode ser restaurado porque não há arquivos estão prontos para rollforward.
Msg 3013, nível 16, estado 1, linha 1
RESTORE LOG está sendo encerrado de forma anormal.

Caso contrário você deve ter muito cuidado para usar a opção direita risco tendo que iniciar uma seqüência de restauração longo novamente--há nenhuma maneira para desfazer recuperação depois é concluído.

No entanto, há uma opção interessante que tipo de faz que--a opção WITH STANDBY. Esta é a última das três opções que mencionei anteriormente. Funciona executando a fase UNDO de recuperação, mas mantém uma observação de que tinha (em um arquivo de "desfazer" cujo nome e caminho que você especificar) e permite acesso somente leitura para o banco de dados. O banco de dados é consistente transacional, mas você tem a capacidade de continuar com a seqüência de restauração. Se você decidir continuar, o desfazer é invertido (usando o conteúdo do arquivo Desfazer) e o próximo arquivo de log de transação é restaurado. Isso é útil em dois cenários: Para permitir acesso somente leitura para um banco de dados secundário de envio de log e para observar o conteúdo do banco de dados durante a seqüência de restauração.

Se o desastre que está recuperando de envolve exclusão acidental de uma tabela, por exemplo, convém fazer uma restauração de ponto no tempo. Há várias maneiras para fazer isso, mas o mais comum é onde você deseja restaurar o banco de dados, mas garantir a recuperação não prosseguir após um certo tempo. Nesse caso, você pode usar a opção WITH STOPAT para impedir restauração de log de transação de indo passado o tempo que você sabe que a tabela foi excluído. Por exemplo, usando o TRANSACTA-SQL exemplo acima, se eu quisesse impedir que o banco de dados restaurado passado 1: 45 h, eu poderia usar a sintaxe a seguir na segunda instrução RESTORE LOG:

RESTORE LOG DBMaint2008 FROM
DISK = 'C:\SQLskills\DBMaint2008_Log_051709_0200.bak'
COM NORECOVERY, STOPAT = ' 2009 - 05 - 17 01:45:00.000 ';
IR

Eu poderia até mesmo combinar STOPAT e STANDBY para ver se o ponto correto que foi no tempo e em seguida, se não, restaurar o backup de log de transação mesmo com um tempo de alguns segundos mais tarde e assim por diante. Esse tipo de operação se torna muito entediante, mas pode ser a única solução se você não souber qual horário uma operação ocorreu.

Uma discussão abrangente sobre essas e outras opções para a instrução RESTORE pode ser encontrada no tópico Books Online"RESTORE argumentos (Transact-SQL)".

Um dos mais interessantes novos recursos introduzidos no SQL Server 2005 Enterprise Edition foi disponibilidade parcial do banco de dados. Esse recurso permite que um banco de dados do grupo de multi-arquivos estar online e disponível como longa como pelo menos o grupo de arquivos principal está online. Obviamente, os dados em quaisquer grupos de arquivos offline não podem ser acessados, mas esse recurso permite que um banco de dados muito grande ser divididos em grupos separados para recuperação mais fácil e rápido. Outro recurso somente Enterprise que foi adicionado é a capacidade de executar restaurações piecemeal (por exemplo, um único grupo de arquivos de um banco de dados de multi-grupo de arquivos) online, enquanto o restante do banco de dados está sendo usado para processamento.

Esses dois recursos combinados habilitar alguns cenários de restauração eficiente e bastante sofisticados, contanto que o banco de dados foi projetado dessa maneira e existem backups corretos.

Você encontrará um excelente, detalhadas artigo SQL Server técnico intitulado "Microsoft SQL Server 2005 parcial Database disponibilidade" com alguns exemplos extensivos disponíveis em tinyurl.com/mbpa65. Também é uma minuto de 75 a gravação de Kimberly l. Tripp entregando uma sessão do Tech-Ed EMEA intitulada"SQL Server 2005 VLDB disponibilidade e estratégias de recuperação"que é vale a pena assistindo.

Considerações ao restaurando para um local diferente

O cenário de restauração mais simples é quando o banco de dados está sendo restaurado na mesma instância do SQL Server para que ele geralmente é anexado e com o mesmo nome. Como mover ainda mais longe do cenário, o rastro da operação de restauração se torna mais complicado.

Se o banco de dados está sendo restaurado na mesma instância, mas com um nome diferente, talvez você precise fazer alterações em elementos como DTS/SSIS pacotes, planos de manutenção de banco de dados, seqüências de aplicativo e qualquer coisa que se baseia em um nome de banco de dados.

Se o banco de dados está sendo restaurado em uma instância diferente no mesmo servidor, as coisas ficam muito mais complicadas:

  • Logins SQL Server serão diferentes ou não existir.
  • Trabalhos do SQL Agent e pacotes DTS/SSIS serão diferentes ou não existir.
  • O banco de dados mestre é diferente, portanto, quaisquer procedimentos armazenados definido pelo usuário podem estar faltando.
  • O nome da instância do SQL Server será diferente, portanto, pode haver problemas de conectividade do cliente.
  • Se o banco de dados está sendo restaurado em uma instância em um servidor diferente, tudo listados se aplica, mas há poderão ser adicionados problemas de segurança como contas Windows podem ser diferentes e pode estar em um domínio diferente do Windows.
  • Uma consideração é a edição do SQL Server está sendo restaurado o banco de dados no. Há alguns recursos que, se usado no banco de dados, verifique o banco de dados "Enterprise apenas-"--não pode ser restaurado no Standard Edition (ou inferior) instância do SQL Server.
  • No SQL Server 2000 e anteriores, isso não é um problema. No SQL Server 2005 se tabela ou índice de particionamento é usado, o banco de dados é "Enterprise apenas-." No SQL Server 2008, a lista de recurso é:
  • Captura de dados de alteração
  • Criptografia de dados transparente
  • Compactação de dados
  • Particionamento

Todos esses exigem privilégios sysadmin para ativar exceto compactação de dados, que pode ser ativada por um proprietário de tabela, assim, potencialmente quebrar um plano de recuperação de desastres envolvendo restaurando uma instância de Standard Edition. Você pode dizer se qualquer um desses recursos estão sendo usados no banco de dados usando sys.dm_db_persisted_sku_features DMV e ajustar seu plano de recuperação de desastres adequadamente.

Aprofundar mais profunda

Como com primeiro artigo na série de backups, há muitas facetas de operações de restauração que não tenho espaço para abordar. Agora que você conhece as noções básicas, entretanto, você pode aprofundar em alguns dos manuais online e blog links para informações mais profundas. O melhor lugar para iniciar no Books Online é o tópico"Restauração e recuperação Overview (SQL Server)". Você também pode encontrar uma grande quantidade de informações em meu blog, iniciando com a categoria de backup e restauração.

A principal vantagem que eu gostaria que você para aproveitar este artigo é que para recuperar um banco de dados usando backups com êxito, você precisa prática para certificar-se de que saber o que fazer. Você não deseja ser aprender a sintaxe para o comando RESTORE durante uma situação de recuperação de desastres high-pressure. Você também pode encontrar o que sua estratégia de backup não permite que você recupere dentro de seus requisitos de negócios. Talvez levarem muito tempo para restaurar os backups, talvez seus backups de log estiverem sobrescrevendo acidentalmente outro, ou talvez você esqueceu de fazer backup do certificado de servidor usado para habilitar a criptografia transparente de banco de dados no SQL Server 2008.

De longe a melhor maneira para se preparar para desastres é ter um plano de restauração que lista as etapas para percorrer e ter um conjunto de scripts que ajudará a identificar quais backups existirem e a ordem em que para restaurá-los. Sempre gosto de dizer que isso deve ser escrito por DBA mais sênior na equipe e testado por DBA mais júnior--para garantir que todos podem seguir as etapas com segurança. No entanto, se você for um DBA involuntário, você vai precisar reunir um plano de si mesmo e certifique-se de que siga.

No próximo artigo, explicarei como recuperar da corrupção do banco de dados se você não tiver quaisquer backups e por que você pode escolher executar uma operação de reparo, mesmo se você tiver backups.
No tempo média e como sempre, se você tiver qualquer comentário ou dúvida, solte me linha-- Paul@SQLskills.com.

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

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