Alta disponibilidade com SQL Server 2000 - Log Shipping - Parte II

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Saiba como trabalhar com log shipping nas versões mais populares do SQL Server 2000: a Standard e o Desktop Engine (MSDE).

capasql27.jpg

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

Alta disponibilidade com SQL Server 2000 Log Shipping Parte II: Log Shipping na versão Standard

 

Paulo Ribeiro

Vimos na primeira parte dessa matéria que 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.

Fomos apresentados ao log shipping na versão Enterprise, que possui essa feature embutida no Enterprise Manager, inclusive com interface para monitoramento. A questão que ficou em aberto e que será o objeto dessa matéria é como trabalhar com log shipping nas versões mais populares do SQL Server 2000: a  Standard e o Desktop Engine (MSDE).

 

Os bastidores do log shipping

 

Um processo de log shipping pode ser resumido em três fases:

Realização de backups no servidor primário (database e log);

Cópia dos arquivos de backup para o servidor secundário;

Restauração dos arquivos de backup no servidor standby.

Se quiséssemos criar e manter um servidor standby bastaria executar essas três etapas – backup local, cópia do arquivo de backup e restauração – para que pudéssemos usufruir de todas as vantagens de um servidor standby, correto?

A afirmação está parcialmente correta, vamos explicar por que: backups consecutivos devem ser restaurados em modo NORECOVERY até que o último backup tenha sido aplicado. Nessa condição, um database fica apto para utilização somente quando o último backup de log for executado e o recovery aplicado. Uma das grandes vantagens de um servidor standby é que a base nesse servidor pode ser utilizada para acessos de leitura, mas se executássemos simplesmente backups e restaurações convencionais a base standby não poderia ser utilizada até que o recovery fosse aplicado. Como resolvemos essa situação? É o que veremos

a seguir.

 

Como executar uma restauração em modo standby

 

A restauração em modo standby resume-se a uma informação adicional no comando RESTORE: a cláusula STANDBY, cuja finalidade é deixar o database disponível para leituras após cada restauração. Para manter o  database em um estado consistente, transações em aberto não são restauradas: serão mantidas em um repositório temporário, fora dos limites do database – o UNDOFILE.

O papel do arquivo de UNDO é armazenar temporariamente transações em aberto, mantendo-as em um arquivo à parte para posterior aplicação. Suponha que a transação A foi iniciada às 10h20min e concluída às 10h45min. Às 10h30min foi executado o backup de log 1 e às 10h50min o backup de log 2. A transação A foi registrada, portanto, em dois backups de log. Na restauração em modo standby, uma transação não pode ser restaurada “parcialmente”, pois isso fere um princípio básico do mundo transacional, conhecido por “atomicidade”: ou a transação é efetivada como um todo ou não será aplicada. Voltando ao nosso exemplo, ao término do backup de log 1, a transação A – que não foi finalizada – não será restaurada parcialmente no database standby, sendo copiada para um repositório temporário – o arquivo de UNDO. Assim que a restauração do backup de log 2 iniciar, antes de qualquer coisa o arquivo de UNDO será lido e a “parte inicial” da transação A será aplicada.

Com o término da restauração desse backup, a transação A estará integralmente registrada no database standby. Assim como aconteceu com a transação A, se existir alguma transação em aberto ao término da segunda restauração, essa(s) transação(ões) será(ão) registrada(s) no arquivo de UNDO para posterior aplicação.

Agora que entendemos como funciona o processo de restauração standby, vamos dar mais um passo a frente iniciando a configuração de log shipping.

 

Como criar uma configuração de log shipping

 

Além dos três passos descritos no item “Os bastidores do Log Shipping”, é necessário estabelecer  mecanismos de controle para que o procedimento de manutenção do database standby possa ser executado automaticamente. Precisamos garantir, por exemplo, que a restauração dos arquivos respeite a ordem cronológica dos backups. São necessárias também as filas de envio e restauração para que um mesmo arquivo não seja copiado e/ou restaurado várias vezes.

Adicionando esses controles e reescrevendo o procedimento, teríamos o seguinte cenário para criar um database standby:

Execute um backup full do database de produção; armazene-o preferencialmente em um disco local e específico para essa finalidade;

Registre a execução do backup em um arquivo de controle;

Crie um job para efetuar backups de log periódicos do database de produção, armazene-os também em um disco local;

Crie um job no servidor standby para ler o arquivo de controle e executar as cópias dos arquivos de backup para o servidor standby;

Crie um job no servidor standby para efetuar as restaurações dos arquivos de backup copiados no item anterior.

Agora que você já sabe exatamente o que fazer – e percebeu que vai dar um pouco de trabalho – vamos ao que interessa. A Microsoft já desenvolveu um procedimento para o SQL Server 7.0, baseado no SQLMaint (utilitário para criação dos planos de manutenção), que automatiza todo o processo de manutenção de servidores standby (ver Nota 1). Na versão Enterprise essas rotinas foram embutidas como uma feature do próprio Enterprise Manager, mas nada impede que você usufrua de servidores standby na versão Standard do SQL Server 2000, basta seguir uma receita, conforme veremos a seguir.

 

Nota 1. Scripts para criação do log shipping

 

Os scripts utilizados nessa matéria foram extraídos do Microsoft BackOffice Resource 4.5 Resource Kit, mas você poderá fazer o download no site da SQL Magazine.

 

Criando um database standby passo-apasso

 

Passo 1: Planejamento

 

Para execução do log shipping em sua totalidade serão necessários pelo menos dois servidores:

o servidor primário responde pelo database de produção;

o secundário (ou standby) é o clone, ou seja, aquele onde será restaurada e mantida atualizada uma cópia do database de produção.

No exemplo dessa matéria, \\SrvSQLMag é o servidor primário, \\SrvSQLMag_STB o servidor standby. O nome do database é dbTeste (ver Figura 1).

 

Figura 1. Servidores participantes do log shipping."

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?