P>

capaSQL26.JPG

Clique aqui para ler todos os artigos desta edição

Alta disponibilidade com SQL Server 2000 log shipping

Paulo Ribeiro

Log shipping pode ser definido como um processo automático de geração, envio e restauração de  transaction log backups entre pelo menos dois servidores. O backup de log é efetuado periodicamente no servidor de produção (também conhecido por servidor primário) sendo armazenado e transferido seqüencialmente para outro(s) servidor(es) participante(s) do log shipping – conhecido por servidor(es) standby. Se o database de produção entrar em colapso, é possível realizar um “upgrade” no database  standby para que substitua o de produção.

O objetivo dessa matéria será apresentar ao leitor um passo-a-passo para configuração de um servidor standby com utilização de log shipping. Começaremos com uma pergunta:

Quem precisa de log shipping?

Para ajudá-lo a responder, farei mais duas perguntas:

·         Quanto tempo seria necessário para substituir o servidor de banco de dados de produção por outro, levando-se em conta a instalação do sistema operacional, configuração do SQL Server e restauração de  backups?

·         Quais são as garantias de que os backups estão em condições de uso, isto é, foram de fato executados,  armazenados em local conhecido e seguro e com mídias aptas para leitura?

 

A proposta do log shipping é fornecer um meio de alta disponibilidade para manutenção de um database através de um servidor stand-by:

·         Com o log shipping você tem a certeza de que seu backup está em condições de utilização;

·         O downtime, isto é, o tempo que a empresa deixa de produzir à espera da substituição do servidor de produção é reduzido – a cópia já se encontra restaurada noutro servidor!

·         A base restaurada no servidor standby pode ser utilizada para leituras, retirando o ônus do processamento de relatórios do servidor de produção.

 

Agora que o pensamento comum é “... todos precisamos de log shipping ...” caminharemos para a segunda etapa: pré-requisitos.

Pré-requisitos

O primeiro pré-requisito é convencer a si próprio de que, além do backup, é necessário um meio eficiente e seguro para validação da rotina de backup. Se como resultado desse processo conseguirmos manter um servidor standby, melhor ainda. Agora, passemos para os pré-requisitos:

·         Servidor stand-by: será necessário pelo menos outro servidor, onde serão restaurados os transaction logs gerados no servidor principal. Já que o objetivo desse servidor é substituir o principal em caso de falha do database de produção, a configuração ideal dessa máquina será tanto melhor quanto mais próximo da configuração do servidor principal;

·         Edição do SQL Server 2000: a versão Enterprise Edition possui interfaces específicas para criação, administração e monitoramento do log shipping. Para outras versões esse processo é manual, mas existem procedimentos “prontos para uso” que serão objeto da segunda parte dessa matéria.

Configurações Iniciais

Confirmados os pré-requisitos, vamos às configurações iniciais:

 

Recovery Model

O database participante de log shipping não pode estar configurado com recovery SIMPLE pelo fato dessa modalidade de recuperação não suportar backups de log. Os modelos permitidos para log shipping são BULK LOGGED e FULL.

 

Shares

No servidor primário, será necessária a criação de um share para compartilhamento dos arquivos de backup de log acessados a partir do servidor standby.

 

Logins

Os logins existentes no servidor principal precisam de alguma forma migrar para o servidor standby, caso contrário os acessos ao database standby serão comprometidos. A criação dos usuários poderia ser executada de três maneiras diferentes, vamos analisá-las em separado.

 

·         Método “manual”: os usuários do servidor principal são criados “um-a-um” no servidor standby. Além de cansativo, principalmente se você possui muitos usuários, o SID para usuários com autenticação no SQL Server (SQL Server Authentication) não será mantido, gerando ghost users (ver Nota 1) no database standby.

 

Nota 1. SID´s & Ghost Users

    SID ou Security Identification é um código interno gerado pelo sistema operacional no momento do cadastramento do usuário no servidor de domínio. O SID é gravado na tabela de sistema SYSXLOGINS, e é independente de servidor para usuários criados com segurança integrada. Para contas com autenticação no SQL Server,  o SID será gerado internamente pelo SQL Server, o que significa que um mesmo usuário cadastrado em servidores diferentes possuirá SID’s também diferentes.

     Dizemos que existem usuários fantasmas (ghost users) em um database quando o SID do usuário no database não possui correspondente na tabela MASTER.DBO.SYSXLOGINS. Esse problema acontece quando restauramos um database em outro servidor, onde o usuário não existe ou existe com SID diferente. Para maiores esclarecimentos, consulte http://support.microsoft.com/kb/274188/.

 

·         DTS: o DTS (ver Nota 2) possui um mecanismo – Transfer Logins Task  que facilmente transporta logins de um servidor para outro. Basta selecionar o servidor origem, o destino e executar a atualização (ver Figura 1). Pode-se também criar um job a partir desse pacote, garantindo que o servidor standby mantenha o sincronismo de logins com o servidor primário. Comparando-se com o método manual, o DTS é inegavelmente a melhor opção; o problema é que essa task também não mantém o SID do usuário no momento na transferência.

 

Nota 2. DTS

O DTS - acrônimo de Data Transformation Sevices - é uma ferramenta gráfica com diversos recursos de programação utilizada para extrair, transformar e consolidar dados originários de fontes diversas (arquivos texto, SQL Server, Oracle, Excel, etc).

image003.jpg

Figura 1. Transfer Logins Task no DTS.

 

Comentário: se você não possui usuários com SQL Server Authentication ou não pretende utilizar o database do servidor standby para leituras, escolha esse modelo de sincronização. Para resolver o problema de compatibilidade entre os SIDs, utilize a procedure SP_CHANGE_ USERS_LOGIN se ocorrerem problemas com o servidor primário e você precisar “liberar” o servidor standby para produção (ver Listagem 1, para maiores detalhes consulte o BOL).

Listagem 1. Utilizando a procedure SP_CHANGE_USERS_LOGINS para verificar incompatibilidade de SIDs.

-- para verificar se existem incompatibilidades entre SID´s (SysUsers X Sysxlogins)

EXEC sp_change_users_login 'Report'

 

-- para equalizar os SID´s

EXEC sp_change_users_login

     @action='update_one'

    ,@usernamepattern=

    ,@loginname=

 

·

Este artigo é exclusivo para assinantes. Descubra as vantagens
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo