INF: Recuperação de desastres planejamento para o SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 169039 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Sumário

Este artigo apresenta dois exemplos de desastre simples planos de recuperação que um site pode considerar ao planejar proativamente para recuperação de dados de um desastre grave. O primeiro exemplo destinado para sites com janelas de manutenção do sistema disponíveis; o segundo exemplo foi projetado para operar em uma base de 24 horas de sites.

A intenção deste artigo é fornecer um ponto de partida para recuperação de desastres esforços de planejamento. Este artigo não é seu plano de recuperação de desastres. Ele é para que você considere sabendo de seu próprio ambiente, modifique adequadamente, especificar e verificar.

Mais Informações

Suponha que um incêndio ocorre e exclui o Centro de dados de 24 horas. Tem certeza que você pode recuperar? Quanto tempo levará você recuperar e seu sistema disponível? Perda de dados quanto os usuários podem tolerar? Esses devem ser algumas das principais preocupações de cada administrador de sistema (SA) e administrador de banco de dados (DBA) encarregados de manter dados de sistema valioso. Recuperação de desastres é o processo por quais informações de sistemas são recuperados no caso de uma catástrofe: um desastre natural ou manmade como um incêndio ou desastre técnico como uma falha no disco dois em uma matriz RAID-5. Planejamento de recuperação de desastres é o trabalho dedicado à preparação todas as ações que ocorrerão em resposta a um evento catastrófico. Avaliação de recuperação de desastres é a simulação de um evento catastrófico e/ou a avaliação de recurso do desastre recuperação plano para entregar as necessidades de recuperação especificado.

O ideal é que o plano de recuperação de desastres deve indicar quanto tempo de recuperação devem assumir e o banco de dados final estado podem esperar que os usuários. Por exemplo, "após a aquisição de hardware especificado, recuperação deve ser concluída em 48 horas e dados irão ser garantidos apenas backup ao final da semana anterior." É importante normalmente gerenciamento ficar informado claramente dessas especificações. Avaliação de recuperação de desastres deve ser capaz preencher a especificação.

Um plano de recuperação de desastres podem ser estruturado muitas maneiras diferentes, e pode conter vários tipos de informações (como obter o hardware, que é para se comunicar o quê, quem são as pessoas a ser contatado em caso de desastre, como são para ser contatado, que é proprietário a administração de planejamento e assim por diante). Este artigo é dedicado somente ao propondo alguns caminhos iniciais para a recuperação técnica do SQL Server.

Este é um exemplo de sites que não funcionam em uma base 24 horas (isto é, sites que possuem janelas de manutenção disponíveis):

Para se preparar para desastres, faça o seguinte todos os dias (ou sempre que é a janela de manutenção):
  1. Desligar o SQL Server.
  2. Copiar todos os arquivos de dispositivo banco de dados, preferably para outro computador em outro prédio (mas lembre-se de carga de rede) e também para um dispositivo de fita (com o servidor para baixo, o dispositivo de arquivos podem ser copiados assim como quaisquer outros arquivos).
  3. Manter logs de sistema de maneira segura. Registre o diretório onde todos os arquivos SQL Server estão localizados, especialmente o arquivo Master.dat. Manter registros de todos os service packs instalados para Windows NT Server e SQL Server. Manter registros das bibliotecas de rede usados, o modo de segurança e a senha.
  4. Manter um script de funcionalidade básica para avaliar rapidamente a capacidade mínima (consulte a Observação no final deste artigo).
  5. Para minimizar a quantidade de dados perdidos durante o dia, execute despejos de log de transações e banco de dados enquanto o sistema está ao vivo. Consulte os manuais do SQL Server Online para obter mais informações sobre procedimentos de despejo, carga e recuperação.
  6. Avaliar as seguintes etapas de recuperação de desastres antecipadamente em outro servidor e corrigir as etapas conforme necessário.
Para recuperar após a ocorrência de um desastre, faça o seguinte após adquirir hardware substituto adequado:
  1. Instalar o Windows NT Server e carregar o pacote de serviço apropriado. Verifique se existe a funcionalidade de domínio apropriado. Por exemplo, verifique se esse arquivo compartilhamento funciona corretamente.
  2. Instalar o SQL Server e carregue o pacote de serviço apropriado. Coloque o dispositivo banco de dados mestre no mesmo diretório como ele foi instalado inicialmente. Selecione também a mesma biblioteca de rede, modo de segurança e senha como antes.
  3. Confirme SQL Server está sendo executado corretamente. Se o Windows NT Server nome foi alterado, uso sp_dropserver e sp_addserver corresponder ao nome do Windows NT Server.
  4. Pare SQL Server.
  5. Mova todos os arquivos de dispositivo banco de dados de volta para seus locais originais, incluindo o arquivo Master.dat.
  6. Reinicie o SQL Server.
  7. Se os logs de transação ou banco de dados estão disponíveis depois desse período, carregue-los.
  8. Verifique a disponibilidade do sistema. Execute um script de funcionalidade para garantir a operação adequada. Idealmente, antes que os usuários são lançados no sistema, tempo deve ser fornecido para executar DBCC CHECKDB e NEWALLOC em cada banco de dados e DBCC TEXTALL TEXTALLOC esses bancos de dados e tabelas que contêm campos de texto. Isso é garantir que o processo de migração não alterou os arquivos em uma forma indesejável.
  9. Depois de executar as instruções de DBCC mostra o banco de dados para ser consistente e o script de teste de funcionalidade tiver êxito, permitem aos usuários continuar.
Este é um exemplo de sites que têm não janelas de manutenção online e que execute sete dias por semana, 24 horas por dia:

Para se preparar para um desastre, faça o seguinte:
  1. Periodicamente despejar todos os bancos de dados, preferably para um disco em outro computador em outro prédio (mas lembre-se de carga de rede) e também em um dispositivo de fita. Logs de transação podem ser tratados da mesma forma.
  2. Manter logs de sistema de maneira segura. Registre o diretório onde todos os arquivos SQL Server estão localizados, especialmente o arquivo Master.dat. Manter registros de todos os service packs instalados para Windows NT Server e SQL Server. Manter registros das bibliotecas de rede usados, o modo de segurança e a senha. Manter registros das opções de banco de dados especificado.
  3. Registre em scripts de todas as alterações de tamanho para todos os dispositivos e bancos de dados. Isso é crucial para simplificar a recuperação nessa situação!
  4. Manter um script de funcionalidade básica para avaliar rapidamente a capacidade mínima (consulte a observação na parte inferior deste artigo).
  5. Avaliar as seguintes etapas de recuperação de desastres antecipadamente em outro servidor e corrigir as etapas conforme necessário.
Para recuperar após um desastre ocorreu após adquirir hardware adequado:
  1. Instalar o Windows NT Server e carregar o pacote de serviço apropriado. Verifique se existe a funcionalidade de domínio apropriado. Por exemplo, verifique se esse arquivo compartilhamento funciona corretamente.
  2. Instalar o SQL Server e carregue o pacote de serviço apropriado. Certifique-se de colocar o dispositivo de banco de dados mestre no mesmo diretório como antes. Selecione também a mesma biblioteca de rede, modo de segurança e senha como antes.
  3. Confirme SQL Server está sendo executado corretamente. Se o Windows NT Server nome foi alterado, execute sp_dropserver e sp_addserver corresponder ao nome do Windows NT Server.
  4. Criar ou alterar todos os dispositivos e bancos de dados de scripts feitos na etapa 3 da seção anterior acima. Bancos de dados podem ser criados para LOAD.
  5. Depois que todos os arquivos do dispositivo e bancos de dados são dimensionados como estavam no momento da último despejo, se as informações de logon do usuário ou as informações de logon do servidor remoto for significativas do banco de dados mestre despejado, continue com a Etapa 5a. Caso contrário, se não forem essenciais, prossiga com a etapa 6.

    1. Pare o SQL Server.
    2. Iniciar o SQL Server no modo de único usuário a partir da linha de comando "SQLSERVR - c -m".
    3. Carregar o banco de dados mestre do despejo de último dele antes da catástrofe ocorreu.
    4. Depois de sucesso, pare e reinicie o SQL Server normalmente. Continue com a etapa 6.
  6. Carregar cada um dos bancos de dados do usuário de arquivos despejados (e o log de transações Despeja também, se apropriado).
  7. Pare e reinicie o SQL Server.
  8. Verifique a disponibilidade do sistema. Se o banco de dados mestre não foi recarregado na etapa 5 c, defina as opções banco de dados para cada banco de dados. Execute um script de funcionalidade para garantir a operação adequada do SQL Server. Teoricamente, antes que os usuários são lançados no sistema, tempo deve ser fornecido para executar DBCC CHECKDB e NEWALLOC em cada banco de dados, e DBCC TEXTALL TEXTALLOC naqueles bancos de dados e tabelas contendo texto campos. Isso é garantir que o processo de migração não alterou os arquivos em uma forma indesejável.
  9. Depois de executar as instruções de DBCC mostra o banco de dados para ser consistente e o script de teste de funcionalidade tiver êxito, permitem aos usuários continuar.
Avaliação de recuperação de desastres fornece a verificação do plano e é alcançada Obtendo suficiente de hardware, fornecendo o desastre documentado recuperação diretrizes e ter um backup SA ou DBA (alguém que não está envolvida com plano de desenvolvimento) recuperar o sistema neste computador. Execute avaliações de recuperação de desastres periódico para verificar a vitalidade do plano de recuperação de desastres atual.

Se seus dados estiverem valiosos, a importância da avaliação de recuperação de desastres não pode ser exagerada. O que é o risco de negócios se você não pode receber os dados novamente? O que é o custo de atraso do cada hora na obtendo seu sistema de backup e em execução? Isso não é uma situação presuma que seus dados são recuperáveis rapidamente; Verifique se ele! Entender as etapas muito exaustivamente antes do tempo e você minimizará o estresse e a incerteza impostas pelo circunstâncias de alguns catástrofe futura.

Este artigo foi escrito como uma expansão a seção de recuperação de banco de dados na página 48 do guia de implantação do Microsoft SQL Server 6.5 (encontrado na World Wide Web em http://www.microsoft.com/sql/deploy.htm). Informações adicionais sobre banco de dados mestre DUMP LOAD SQLSERVR podem ser encontradas no SQL Server Books Online e na Base de dados de Conhecimento da Microsoft.

Observação: A "script de funcionalidade básica" é um lote de código que pode ser usado para demonstrar rapidamente o funcionamento bem-sucedida do banco de dados da perspectiva de um aplicativo específico. Mais comumente este é um arquivo. SQL com comandos SQL em lote executar no servidor a partir ISQL. Para outros aplicativos, um arquivo .bat é mais adequado porque ele pode conter comandos BCP e ISQL. Esse script funcionalidade básica é muito específico do aplicativo e pode levar vários formulários diferentes. Por exemplo, em um sistema Decision Support/relatório, o script pode ser simplesmente uma cópia de alguns da chave do relatório de consultas; para uma transação on-line (OLTP) aplicativo de processamento pode ser a execução de um lote de procedimentos armazenados para executar instruções INSERT, UPDATE e DELETE. O objetivo é confirmar, de uma perspectiva bruta, que tudo está funcionando conforme o esperado. O script de funcionalidade básica fornece uma ferramenta interessante para a SA ou administrador de banco de dados poder ver que o banco de dados é novamente em um estado viável, sem dependendo dos usuários finais para verificação.

Propriedades

ID do artigo: 169039 - Última revisão: sexta-feira, 14 de novembro de 2003 - Revisão: 3.0
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palavras-chave: 
kbmt kbenv kbhowto kbusage KB169039 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 169039
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com