Clique aqui para ler esse artigo em PDF.
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 "
[...] continue lendo...