Descrição das opções de recuperação de desastres para Microsoft SQL Server

Este artigo descreve várias soluções para recuperar dados de uma base de dados do Microsoft SQL Server, se ocorrer um desastre. Este artigo também explica as vantagens e desvantagens de cada solução.

Recuperação de desastres é um processo que pode utilizar para ajudar a recuperar informações de sistemas e dados, se ocorrer um desastre.

Alguns exemplos de desastres incluem um natural um desastre man-made como um firewall ou um desastre como uma falha de disco de dois técnico numa matriz redundante de RAID matriz discos independentes () 5.

Planeamento de recuperação de desastres é o trabalho é dedicado para preparar todas as acções que devem ocorrer em resposta a um desastre. O planeamento incluem a selecção de uma estratégia para ajudar a recuperar dados importantes. A selecção da estratégia de recuperação de desastres adequado depende seus requisitos empresariais.

Nota As soluções que são descritas neste artigo só fornecem descrições gerais das tecnologias que podem ser utilizados. Estas descrições gerais são para comparar vários métodos de recuperação de desastres e os planos de recuperação de desastres. Antes de decidir no qual desastres solução de recuperação é melhor para si, certifique-se de que observa cada uma das soluções de recuperação de desastres sugeridas mais detalhadamente. Depois de debater cada solução de recuperação de desastres, este artigo contém hiperligações onde pode encontrar informações adicionais sobre essa solução.

Activação pós-falha clustering

Clusters de failover de Microsoft SQL Server 2000 foi concebido para activação pós-falha automaticamente se ocorrer uma falha de hardware ou uma falha de software. Pode utilizar o SQL Server 2000 activação pós-falha clusters para criar um cluster de activação pós-falha para uma única instância do SQL Server 2000 ou para várias instâncias do SQL Server 2000. Activação pós-falha clustering permite que um sistema de base de dados mudar automaticamente o processamento de uma instância do SQL Server a partir de um servidor falha para um servidor de trabalho. Por conseguinte, activação pós-falha clustering é útil se ocorrer uma falha de sistema operativo ou se efectuar uma actualização planeada dos recursos de sistema da base de dados. Além disso, clustering de activação pós-falha aumenta a disponibilidade do servidor com nenhum período de inactividade.

Porque o clustering de activação pós-falha está concebido para o servidor alta disponibilidade com quase nenhum período de indisponibilidade servidor, os nós de cluster devem ser geograficamente perto uns dos outros. Clustering de activação pós-falha não pode ser útil se ocorrer uma falha de matriz de disco.

Nota Para implementar a activação pós-falha clusters, tem de instalar Microsoft SQL Server 2000 Enterprise Edition.

Os seguintes sistemas operativos suportam clustering de activação pós-falha:

• Microsoft Windows NT 4.0, Enterprise Edition
• Microsoft Windows 2000 Advanced Server
• Microsoft Windows 2000 Datacenter Server
• Microsoft Windows Server 2003, Enterprise Edition
• Microsoft Windows Server 2003, Datacenter Edition

Estes sistemas operativos incluem um componente instalável, o serviço Microsoft Cluster (MSCS). Para implementar a activação pós-falha clustering para SQL Server, tem de instalar MSCS.

Para obter mais informações sobre MSCS e respectiva instalação, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Partido e desvantagens da utilização de clustering de activação pós-falha

Partido

Desvantagens

• Provoca uma despesa maior. A manutenção de dois servidores é duas vezes o custo de manutenção de um único servidor. Uma vez que tiver de manter dois servidores ao mesmo tempo, é mais dispendiosa instalar e manter nós de cluster.
• Servidores devem estar na mesma localização. Se os ramos da organização através de globo e os clusters activos/activos devem ser implementados em ramos, a rede e infra-estrutura de armazenamento que terá de utilizar é muito diferente de um cluster de servidor de dispositivo de quórum padrão. Por conseguinte, embora seja possível, é melhor não utilizar servidores geograficamente distantes.
• Tem sem protecção contra uma falha de matriz de disco.
• Clustering de activação pós-falha não permite a criação de clusters de activação pós-falha ao nível da base de dados ou no nível de objecto da base de dados, como, por exemplo, o nível de tabela.

Para mais informações sobre a activação pós-falha clustering, visite o seguinte Web site da Microsoft:Para obter mais informações sobre a activação pós-falha clusters, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre a política de suporte da Microsoft para um cluster de activação pós-falha do SQL Server, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Espelhamento da base de dados

Espelhamento da base de dados é uma solução de software principalmente para aumentar a disponibilidade da base de dados. Só é possível implementar espelhamento num regime por base de dados. Espelhamento (mirroring) só funciona com bases de dados que utilizam o modelo de recuperação total. Os modelos de recuperação simples e registado em massa não suportam mirror da base de dados. Por conseguinte, todas as operações em massa sempre totalmente são registadas. Espelhamento da base de dados funciona com qualquer nível de compatibilidade de base de dados suportadas.

Partido e desvantagens da utilização de espelhamento da base de dados

Vantagens

• Espelhamento da base de dados aumenta a protecção de dados.
• Espelhamento da base de dados aumenta a disponibilidade de uma base de dados.
• Espelhamento da base de dados melhora a disponibilidade de base de dados de produção durante as actualizações.

Desvantagens

• A base de dados espelhos (mirror) deverá ser idêntica à base de dados principal. Por exemplo, todos os objectos, os inícios de sessão e permissões devem ser idênticas.
• Espelhamento da base de dados envolve a transferência de informações de um computador para outro computador através de uma rede. Por conseguinte, a segurança das informações que transfere o SQL Server é muito importante.

Replicação transaccional do peer-to-peer

Replicação transaccional do peer-to-peer foi concebida para aplicações que podem ler ou podem modificar os dados qualquer base de dados que participam na replicação. Além disso, se todos os servidores que hospedam as bases de dados não estiverem disponíveis, pode modificar a aplicação para encaminhar tráfego para os restantes servidores. Os restantes servidores contêm cópias idênticas dos dados.

Partido e desvantagens da utilização de replicação transaccional do peer-to-peer

Vantagens

• Desempenho de leitura melhorado porque pode distribuir a actividade em todos os nós.
• Agregar o desempenho de actualização, desempenho de inserir e eliminar desempenho para a topologia assemelha-se o desempenho de um único nó porque todas as alterações são propagadas para todos os nós.

Desvantagens

• Replicação de peer-to-peer está disponível apenas no SQL Server 2005 Enterprise Edition.
• Todas as bases de dados participantes tem de conter idênticos esquemas e dados.
• Recomendamos que cada nó utilize base de dados respectiva distribuição. Esta configuração elimina a possibilidade de SQL Server 2005 para que um ponto único de falha.
• Não pode incluir tabelas e outros objectos nas várias publicações de peer-to-peer numa base de dados única publicação.
• Tem de ter uma publicação activada para replicação peer-to-peer antes de criar quaisquer subscrições.
• Tem de inicializar subscrições utilizando uma cópia de segurança ou definir o valor do tipo de sincronização de subscrição para apenas suporte de replicação .
• Replicação transaccional do peer-to-peer não fornece detecção de conflitos ou resolução de conflitos.
• Recomendamos que não utilize colunas de identidade.

Manutenção de um servidor em espera quente

Pode criar e manter um servidor em espera quente utilizando um dos seguintes métodos:

• Registo de envio
• Replicação transaccional

Obter mais informações sobre cada um destes dois métodos a seguir.

Registo de envio

Envio de registo está incluído no resource kit para o Microsoft SQL Server 7.0 e é totalmente incorporada no Microsoft SQL Server 2000 Enterprise Edition e no Microsoft SQL Server 2000 Developer Edition. Inicie envio utiliza um servidor em espera que não é utilizado durante as operações normais. Um servidor em espera é útil para ajudar a recuperar dados se ocorrer um desastre. Só pode utilizar envio do registo ao nível da base de dados. Não pode utilizar ao nível da instância.

Quando um servidor em espera é restaurar registos de transacções, a base de dados é em modo exclusivo e inutilizável. No entanto, pode executar comandos fornecer informações sobre tarefas entre restauros de registo de transacções ou da base de dados da consola de comandos (DBCC) verifica para continuamente verificar a integridade do servidor em espera. Para aplicações tais como servidores de suporte de decisão que requerem processo contínuo num servidor da base de dados, envio de registo não é uma opção adequada.

A latência no servidor em espera é com base na frequência efectuadas cópias de segurança da registo de transacções no servidor principal e, em seguida, aplicada ao servidor em espera. Se o servidor primário falhar, poderá perder as alterações que foram efectuadas pelas transacções ocorridas após o registo de transacções mais recente cópia de segurança.

Por exemplo, se cópias de segurança de registo de transacções são retiradas cada 10 minutos, transacções durante as mais recentes 10 minutos poderão ser perdidas. Isto não significa necessariamente que as actualizações de dados efectuadas para o servidor principal durante o período de latência serão perdidas. Normalmente, as novas actualizações no registo de transacções primário podem ser recuperadas e aplicadas no servidor em espera quente com apenas um pequeno atraso de mudar de servidor primário para o servidor em espera. O principal objectivo do envio de registo é manter um servidor em espera quente. Se mantiver que um servidor em espera quente é o principal objectivo, é provável que ser mais adequados do que as soluções que este artigo aborda envio do registo.

Vantagens e desvantagens da utilização de envio do registo

Vantagens

• Pode recuperar todas as actividades da base de dados. A recuperação inclui quaisquer objectos que foram criados, tais como tabelas e vistas. Também inclui alterações de segurança, tais como os novos utilizadores que foram criados e alterações de permissão.
• Pode restaurar a base de dados mais rapidamente. O restauro da base de dados e o registo de transacções se baseia em formatos de página de baixo nível. Por conseguinte, registo envio acelera o processo de restauro e resulta na recuperação rápida dos dados.

Desvantagens

• A base de dados é inutilizável durante o processo de restauro porque a base de dados está em modo exclusivo no servidor em espera.
• Existe uma falta de granularidade. Durante o processo de restauro, todas as alterações no servidor principal são aplicadas no servidor em modo de suspensão. Pode utilizar o envio de registo para aplicar alterações a algumas tabelas e para rejeitar as alterações restantes.
• Não existe nenhum failover automática de aplicações. Quando o servidor primário falha devido a um desastre, o servidor em espera não activação pós-falha automaticamente. Por conseguinte, tem de redireccionar explicitamente as aplicações que ligar o servidor principal para o servidor em espera (failover).

Nota Se o principal objectivo é manter um servidor em espera quente, a Microsoft recomenda que utilize o envio do registo. O servidor em espera quente reflecte todas as transacções que ocorrem no servidor principal. No entanto, pode utilizar o servidor em modo de espera quando o servidor primário está disponível.

Para obter mais informações sobre como configurar um servidor em espera quente utilizando o envio de registo, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre o envio do registo, visite os seguintes Web sites da Microsoft:

Replicação transaccional

Pode também utilizar replicação transaccional para manter um servidor em espera quente. Replicação transaccional replica os dados num servidor (Editor) para outro servidor (o subscritor) com menos latência de envio do registo. Pode implementar a replicação transaccional ao nível do objecto da base de dados como o nível de tabela. Por conseguinte, a Microsoft recomenda que utilize replicação transaccional quando tiver menos dados para proteger e tem de ter um plano de recuperação rápida.

Pode utilizar uma subscrição de emissão para impor a replicação transaccional entre dois servidores com o servidor primário como o fabricante e o servidor em modo de suspensão como subscritor. Replicação transaccional assegura a replicação de dados. Quando o publisher falha, pode ser utilizado o subscritor.

Esta solução é vulnerável a falhas de fabricante e o subscritor ao mesmo tempo. Neste cenário, não é possível proteger os dados. Em todos os outros cenários tais como a falha de um distribuidor ou de um subscritor, é melhor voltar a sincronizar dados do subscritor com os dados do fabricante.

Deverá utilizar replicação transaccional para manter um servidor em espera quente apenas quando não implementam as alterações do esquema ou não implementam outras alterações à base de dados, tais como alterações de segurança que a replicação não suporta.

Nota Replicação não foi concebida para a manutenção de servidores em modo de espera quentes. Com a replicação, pode utilizar dados replicados no subscritor para gerar relatórios. Também pode utilizar a replicação para outras utilizações gerais sem ter de executar o processamento do fabricante relativamente ocupado.

Vantagens e desvantagens da utilização de replicação transaccional

Vantagens

• Pode ler dados de um subscritor enquanto aplicar as alterações.
• As alterações são aplicadas com menos latência.
  
  Nota Esta vantagem poderá não ser aplicável se qualquer uma das seguintes condições for verdadeira:
  • Agentes de replicação não estão definidas para contínua .
  • Agentes de replicação são interrompidos devido a erros que poderão ocorrer durante a replicação.

Replicação transaccional poderá demorar mais tempo para aplicar alterações porque batch grande actualizações têm de ser efectuadas durante a replicação.

Desvantagens

• As alterações do esquema ou alterações de segurança que são executadas no Editor depois de estabelecer a replicação não estará disponíveis no subscritor.
• Distribuidor de replicação transaccional utiliza uma ligação de interligação de bases de dados abertas (ODBC, Open Database CONNECTIVITY) ou uma ligação OLE da base de dados (OLEDB) para distribuir dados. No entanto, envio de registo utiliza TRANSACTION RESTORE baixo nível instrução Transact-SQL para distribuir os registos de transacção. Uma instrução TRANSACTION RESTORE é muito mais rápida do que uma ligação ODBC ou OLEDB uma ligação.
• Normalmente, a mudança servidores apaga configurações de replicação. Por conseguinte, tem de configurar a replicação duas vezes:
  Quando muda para o subscritor.
  Quando mudar para o fabricante.
• Se ocorrer um desastre, tem de mudar manualmente servidores, redireccionar todas as aplicações para o subscritor.

Para obter mais informações sobre replicação, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Funcionalidade de cópia de segurança e restauro

A funcionalidade de cópia de segurança e restauro do SQL Server fornece uma salvaguarda importante para proteger dados críticos armazenados nas bases de dados SQL Server. Pode criar uma cópia de uma base de dados (uma cópia) utilizando a cópia de segurança e restaurar a funcionalidade e, em seguida, armazenar a cópia da base de dados numa localização que está protegida contra a potencial falha do servidor que executa a instância do SQL Server. Se ocorrer uma falha de sistema de base de dados ou danos na base de dados, pode em seguida, utilizar a cópia de segurança para recriar a base de dados ou para restaurar a base de dados.

Quando planear a recuperação de desastres utilizando a cópia de segurança e restaurar a funcionalidade, também determine como críticos os dados da base de dados são. Além disso, determinar os requisitos de restauro da base de dados. Por exemplo, determine os seguintes requisitos de restauro:

• O ponto que restaurar a base de dados. Tem de decidir qual dos dois seguintes que pretende fazer:
  Restaure a base de dados do estado da noite antes da falha.
  Restaure a base de dados a condição de um ponto de tempo, o mais próximo possível à hora da falha.
• Tempo que a base de dados pode ficar indisponível. Se tem de restaurar a base de dados imediatamente.

Depois de determinar os requisitos de restauro, pode planear um processo de cópia de segurança que mantém um conjunto de cópias de segurança para cumprir os requisitos

Só pode restaurar uma base de dados a condição do ponto de tempo em que fez a cópia de segurança mais recente. Transacções ocorridas após essa cópia de segurança poderão ser perdidas. Por este motivo, a Microsoft recomenda que utilize a funcionalidade de cópia de segurança e restauro apenas para aplicações de base de dados não-críticos.

Vantagens e desvantagens de utilizar a funcionalidade de cópia de segurança e restauro

Vantagens

• Pode criar uma segurança de base de dados de suportes amovíveis para ajudar a proteger contra falhas de disco.
• Não é necessário dependem da rede, tal como quando utilizar clusters de activação pós-falha ou iniciar envio.

Desvantagens

• Quando cria uma cópia da base de dados, não é possível efectuar operações como a criação de tabela, criação de índices, diminuir a base de dados ou operações nonlogged.
• Se ocorrer uma falha, poderá perder os dados mais recentes.
• Se ocorrer um desastre, tem de restaurar manualmente a base de dados.

Nota Antes de utilizar o procedimento de cópia de segurança e restauro num ambiente de produção, recomenda-se testar exaustivamente este procedimento num ambiente de teste.

Para obter mais informações sobre a funcionalidade de cópia de segurança e restauro, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre a funcionalidade de cópia de segurança e restauro, visite os seguintes Web sites da Microsoft:

Disco redundância de dados utilizando uma matriz redundante de discos independentes (RAID)

Um RAID armazena dados redundantes nos discos múltiplos para maior fiabilidade e menos tempo de inactividade para servidores. Níveis RAID 0, 1 e 5 são normalmente utilizadas como opções de recuperação para o SQL Server. Permitem as tecnologias RAID mencionadas para a falha e a substituição de um único disco consequent sem o servidor em offline. Se ocorrerem várias falhas de disco, dados podem não ser recuperáveis. Por conseguinte, a Microsoft recomenda que combinam dados redundantes gestão com um procedimento de cópia de segurança e restauro para ajudar a tornar-se de que não são perdidos dados se uma falha de hardware ou outras falhas ocorre.

RAID 0 utiliza tecnologia repartição (striping) para um acesso mais rápido, enquanto que RAID 1 utiliza tecnologia de espelhamento de fiabilidade dos dados. Uma técnica comum utilizada na gestão de base de dados relacional envolve a utilização em conjunto RAID 0 e 1 RAID. Nesta técnica, duas matrizes repartidos (striped) idênticas de unidades são constantemente actualizadas para que as informações armazenadas no ambas as matrizes seja o mesmo. Se falhar uma matriz, a matriz assume automaticamente até que a matriz original é colocada novamente online.

RAID 5 (também conhecido como repartição com paridade) utiliza uma matriz de discos repartidos único com bits de paridade escritas juntamente com os dados. Quando qualquer um disco falha, os bits de paridade pode ser utilizados para calcular os dados em falta até substituir o disco. Ao substituir o disco, pode utilizar a informação de paridade e os restantes dados para recriar os dados do disco que falhou e copiar os dados recriados no novo disco. Todas estas operações ocorrem sem imobilização do sistema de base de dados. Um RAID fornece muitas outras opções e funcionalidades para a ajudar a garantir que os sistemas de base de dados experimentar como o período de indisponibilidade pouco possível.

Partido e desvantagens da utilização de um RAID

Partido

Desvantagens

• Pode demorar muito tempo para recuperar os dados.
• Se vários discos falharem, não poderá recuperar os dados importantes.

Para obter mais informações sobre RAID, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base:

Para transferir uma versão actualizada do SQL Server 2000 Books Online, visite o seguinte Web site da Microsoft:Para obter mais informações sobre outras opções de recuperação de desastres, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Para obter mais informações sobre a activação pós-falha clusters, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre a funcionalidade de cópia de segurança e restauro, visite o seguinte Web site da Microsoft:Para obter mais informações sobre a funcionalidade de cópia de segurança e restauro, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft: Para obter mais informações sobre pastas de catálogo de texto completo e ficheiros, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: