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

Traduções de Artigos Traduções de Artigos
Artigo: 169039 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Sumário

Este artigo fornece dois exemplos de desastres simples planos de recuperação de um site pode considerar ao planear proactivamente a recuperação de dados de um desastre grave. O primeiro exemplo é destinado sites com o windows de manutenção do sistema disponíveis; o segundo exemplo foi concebido para sites funcionar numa base 24 horas.

A intenção deste artigo é fornecer um ponto de partida para recuperação de desastres esforços de planeamento. Este artigo não é o plano de recuperação de desastres. É onde pode considerar a luz do seu ambiente, modificar em conformidade, especificar e certifique-se.

Mais Informação

Suponha que um firewall ocorre e removerá o Centro de dados de 24 horas. Tem a certeza de que pode recuperar? Quanto demora para recuperar e que o sistema disponível? Quanto perda de dados podem tolerar os utilizadores? Estes devem ser algumas das preocupações chaves de cada administrador de sistema (SA, Security ASSOCIATION) e administrador de base de dados (DBA) carregada com a manutenção de dados do sistema inestimável. Recuperação de desastres é o processo pelo qual a informação sistemas são recuperados na eventualidade de um catastrophe: um desastre natural ou manmade como um firewall ou técnico desastres tal como uma falha de disco de dois numa matriz RAID-5. Planeamento de recuperação de desastres é dedicado a preparar todas as acções que ocorrerão em resposta a um evento grave o trabalho. Avaliação de recuperação de desastres é a simulação de um evento grave e/ou a avaliação de capacidade do desastres recuperação plano para fornecer as necessidades de recuperação especificado.

Idealmente, o plano de recuperação de desastres deveria indicar recuperação quanto devem ter e a base de dados final indicar provável que os utilizadores. Por exemplo, "após a aquisição de hardware especificado, recuperação deve ser concluída em 48 horas e dados vão ser garantidos apenas até ao fim da semana anterior." É normalmente importante que gestão ser mantido claramente informado destas especificações. Avaliação de recuperação de desastres deverá conseguir substantiate a especificação.

Um plano de recuperação de desastres podem ser estruturado muitas formas diferentes e pode conter muitos tipos de informações (como obter o hardware, que é comunicar o que, que são as pessoas a contactar em caso de um desastre, como são a ser contactado, ao qual pertence a administração de planeamento etc.). Este artigo é dedicado apenas a proposta alguns hipóteses iniciais para a recuperação técnica do SQL Server.

Segue-se um exemplo de sites que não funcionam numa base 24 horas (ou seja, sites que têm janelas manutenção disponíveis):

Para preparar para desastre, efectue o seguinte todos os dias (ou sempre que a janela Manutenção é):
  1. Encerre o SQL Server.
  2. Copiar ficheiros de dispositivo da base de dados tudo, preferably para outro computador no outro edifício (mas tenha em atenção de carga em rede) e também para um dispositivo de banda (com o servidor para baixo, o dispositivo podem ser copiados ficheiros tal como outros ficheiros).
  3. Manter registos do sistema de uma forma segura. Registe o directório onde todos os ficheiros de SQL Server estão localizados, especialmente o ficheiro Master.dat. Manter registos de todos os service packs instalados para o Windows NT Server e SQL Server. Manter registos das bibliotecas de rede utilizados, o modo de segurança e a palavra-passe SA.
  4. Manter um script de funcionalidade base para avaliar rapidamente capacidade mínimo (consulte a nota no final deste artigo).
  5. Para minimizar a quantidade de dados perdidos durante o dia, efectuar informações de registo da base de dados e transacções enquanto o sistema está activo. Consulte os livros do SQL Server Online para obter mais informações sobre procedimentos de cópia, carga e recuperação.
  6. Avaliar os passos de recuperação de desastres seguintes, antecipadamente noutro servidor e alterar os passos conforme necessário.
Para recuperar depois de um desastre, efectue o seguinte depois de adquirir hardware adequado de substituição:
  1. Instalar o Windows NT Server e carregar o pack de serviço apropriado. Verifique se existe funcionalidade de domínio apropriado. Por exemplo, verifique se esse ficheiro partilha funciona correctamente.
  2. Instalar o SQL Server e carregue o pack de serviço apropriado. Colocar o dispositivo de base de dados principal no mesmo directório, tal como foi inicialmente instalado. Seleccione também a mesma biblioteca de rede, modo de segurança e palavra-passe do SA como antes.
  3. Confirme que o SQL Server está a ser correctamente executado. Se o Windows NT Server nome foi alterado, utilização sp_dropserver e sp_addserver corresponder ao nome do Windows NT Server.
  4. Pare o SQL Server.
  5. Mova todos os ficheiros do dispositivo de base de dados volta às respectivas localizações originais, incluindo o ficheiro Master.dat.
  6. Reinicie o SQL Server.
  7. Se existem quaisquer registos de base de dados ou transacção passado este tempo, carregue-los.
  8. Verificar a disponibilidade do sistema. Execute um script de funcionalidade para assegurar o funcionamento adequado. Idealmente, antes dos utilizadores são lançados no sistema, tempo deve ser fornecido para executar DBCC CHECKDB e NEWALLOC em cada base de dados e DBCC TEXTALL e TEXTALLOC essas bases de dados e tabelas que contêm campos de texto. Isso visa garantir que o processo de migração não alterar os ficheiros de uma forma indesejável.
  9. Depois de executar instruções DBCC mostra a base de dados para ser consistente e o script de teste a funcionalidade tiver êxito, permitem aos utilizadores continuar.
Segue-se um exemplo de sites que têm janelas não manutenção online e que são executados sete dias por semana, 24 horas por dia:

Para preparar um desastre, efectue o seguinte:
  1. Periodicamente copiar bases de dados, preferably para um disco noutro computador no outro edifício (mas tenha em atenção de carga em rede) e também para um dispositivo de banda. Registos de transacções podem ser geridos do mesmo modo.
  2. Manter registos do sistema de uma forma segura. Registe o directório onde todos os ficheiros de SQL Server estão localizados, especialmente o ficheiro Master.dat. Manter registos de todos os service packs instalados para o Windows NT Server e SQL Server. Manter registos das bibliotecas de rede utilizados, o modo de segurança e a palavra-passe SA. Manter registos das opções de base de dados especificada.
  3. Grave scripts de todas as alterações de tamanho para todos os dispositivos e bases de dados. Isto é essencial simplificar a recuperação nesta situação!
  4. Manter um script de funcionalidade base para avaliar rapidamente capacidade mínimo (consulte a nota na parte inferior deste artigo).
  5. Avaliar os passos de recuperação de desastres seguintes, antecipadamente noutro servidor e alterar os passos conforme necessário.
Recuperar depois de um desastre ocorreu após adquirir hardware adequado:
  1. Instalar o Windows NT Server e carregar o pack de serviço apropriado. Verifique se existe funcionalidade de domínio apropriado. Por exemplo, verifique se esse ficheiro partilha funciona correctamente.
  2. Instalar o SQL Server e carregue o pack de serviço apropriado. Certifique-se de colocar o dispositivo de base de dados principal no mesmo directório que antes. Seleccione também a mesma biblioteca de rede, modo de segurança e palavra-passe do SA como antes.
  3. Confirme que o SQL Server está a ser correctamente executado. Se o Windows NT Server nome foi alterado, executar sp_dropserver e sp_addserver corresponder ao nome do Windows NT Server.
  4. Criar ou alterar todos os dispositivos e bases de dados dos scripts efectuados no passo 3 da secção anterior acima. Bases de dados podem ser criadas para LOAD.
  5. Depois de todos os ficheiros do dispositivo e bases de dados estão dimensionadas como estavam no momento da última cópia de memória se as informações de início de sessão do utilizador ou as informações de início de sessão do servidor remoto for significativas da registada base de dados principal, avance para o passo 5a. Caso contrário, se não forem importantes, avance com o passo 6.

    1. Pare o SQL Server.
    2. Inicie o SQL Server no modo de utilizador único na linha de comandos "SQLSERVR - c -m".
    3. Carregar a de dados principal do último dump do mesmo antes do catastrophe ocorreu.
    4. Depois de êxito, pare e reinicie normalmente do SQL Server. Avance para o passo 6.
  6. Coloque cada uma das bases de dados de utilizador a partir dos ficheiros registados (e o registo de transacções também regista se for apropriado).
  7. Pare e reinicie o SQL Server.
  8. Verificar a disponibilidade do sistema. Se a base de dados principal não foi carregado no passo 5 c, defina as opções da base de dados para cada base de dados. Execute um script de funcionalidade para garantir o funcionamento adequado do SQL Server. Idealmente, antes dos utilizadores são lançados no sistema, tempo deve ser fornecido para executar DBCC CHECKDB e NEWALLOC cada base de dados e DBCC TEXTALL e TEXTALLOC naqueles bases de dados e tabelas que contêm texto campos. Isso visa garantir que o processo de migração não alterar os ficheiros de uma forma indesejável.
  9. Depois de executar instruções DBCC mostra a base de dados para ser consistente e o script de teste a funcionalidade tiver êxito, permitem aos utilizadores continuar.
Avaliação de recuperação de desastres fornece a verificação do plano e é conseguida levando hardware suficiente, fornecendo directrizes de recuperação desastre documentada e ter uma cópia de segurança SA ou DBA (alguém que não esteja envolvido com plano de desenvolvimento) recuperar o sistema neste computador. Efectue periódicas avaliações de recuperação de desastres para verificar a vida do plano de recuperação de desastres actual.

Se os dados importantes, não pode ser overstated a importância da avaliação de recuperação de desastres. O que é o risco de empresa se não obtiver os dados novamente? O que é o custo para atraso cada hora em obter o sistema efectua a cópia de segurança e em execução? Isto não é uma situação para assumir que os dados são recuperáveis rapidamente; verificá-la! Compreender os passos muito cuidadosamente antes do tempo e irá minimizar a importância e incerteza imposta as circunstâncias de alguns catastrophe futura.

Este artigo foi escrito como uma expansão à secção de recuperação da base de dados na página 48 do manual de implementação do Microsoft SQL Server 6.5 (encontrado na World Wide Web em http://www.microsoft.com/sql/deploy.htm). Poderá encontrar informações adicionais sobre como copiar SQLSERVR LOAD principal base de dados no SQL Server Books Online e na base de dados de conhecimento da Microsoft.

NOTA: A "funcionalidade base script" é uma secção de código que pode ser utilizado para demonstrar rapidamente o funcionamento com êxito da base de dados da perspectiva de uma aplicação específica. Normalmente este é um ficheiro .SQL com comandos SQL batches executar no servidor a partir de ISQL. Para outras aplicações, um ficheiro .bat é mais apropriado, porque pode contém comandos BCP e ISQL. Este script funcionalidade base é muito específicas da aplicação e pode demorar várias formas diferentes. Por exemplo, num sistema Decision Support/relatório, o script pode ser apenas uma cópia de um par da chave de fornecer informações sobre consultas; para uma transacção online (OLTP) de aplicação de processamento poderá ser a execução de um lote de procedimentos armazenados para executar instruções INSERT, UPDATE e DELETE. O objectivo é confirmar, perspectiva bruto, tudo está a funcionar como previsto. O script funcionalidade base fornece uma ferramenta útil para a SA ou DBA conseguir ver que a base de dados é novamente num estado viável, sem consoante os utilizadores finais para verificação.

Propriedades

Artigo: 169039 - Última revisão: 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 revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 169039
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

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