¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

Implementação de HP EVA SAN para SAP MaxDB Wintel: Backups com tecnologia de instantâneos

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 4 Vistas
0
Cargando...

Olá a todos,

Estamos implementando um novo HP EVA SAN para o nosso ambiente SAP MaxDB Wintel. Como parte da configuração SAN, vamos utilizar a tecnologia de instantâneos do EVA para realizar um backup noturno.

Atualmente, o HP Data Protector não suporta o MaxDB para o conceito de "Backup sem tempo de inatividade" (ZDB), então precisamos realizar instantâneos de LUN usando os comandos nativos do EVA. O ZDB teria sido útil, pois se integra ao SAP e permite que o banco de dados/SAP saiba quando um backup instantâneo foi feito. No entanto, como mencionei, essa função não está disponível no MaxDB (apenas no SAP com Oracle).

Estamos cientes de que o SAP suporta instantâneos em dispositivos de armazenamento externo, conforme indicado nas notas OSS 371247 e 616814.

Para fazer o instantâneo, faremos algo semelhante (se não exatamente) ao que a nota 616814 descreve abaixo:

Para criar o espelho dividido ou o instantâneo, siga os passos abaixo:

dbmcli -d <nome_do_banco_de_dados> -u <usuario_dbm>,<senha>

util_connect <usuario_dbm>,<senha>

util_execute suspend logwriter

==> Criar o instantâneo no EVA

util_execute resume logwriter

util_release

exit

Obviamente, o MaxDB e o SAP não estão cientes de que um "backup" foi feito. Isso levanta algumas questões para as quais gostaria de ver se alguém tem uma solução.

a. Para habilitar o backup automático de logs, o MaxDB precisa saber que primeiro foi feito um backup "completo". É possível que o MaxDB esteja ciente de que um backup instantâneo do banco de dados foi feito, o que nos permitiria habilitar o backup automático de logs?

b. O SAP também gosta de saber que um backup foi feito. Os relatórios de Alerta do Earlywatch começam a ficar um pouco nervosos quando nenhum backup é feito no sistema por um tempo.

Além disso, o DB12 mencionará que o sistema não está em um estado recuperável, quando na verdade está. Existe alguma solução disponível aqui?

Saudações

Shaun

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

Olá Lars,

Obrigado pelos seus comentários. Aprecio a sua opinião e tomei nota. Vamos realizar um backup padrão do banco de dados todas as noites para fita (além de instantâneos), não apenas para ter uma possível proteção dupla, mas também para verificar os blocos do banco de dados e os controles de consistência que você mencionou tão acertadamente como extremamente importantes.

Bem, ninguém nega que o SAP está "bem" com isso. É apenas uma diferença entre estar "bem" com algo (o que significa aqui: você pode usar as funções do MaxDB de forma que os instantâneos do EVA funcionem para um backup) em comparação com a forma simples e direta que foi implementada em um nível de clique no SAP CCMS. Tecnicamente, sua ideia de usar instantâneos provavelmente funcionará, mas como já escrevi, você terá que monitorar você mesmo.

Seria bom ver a HP e a SAP (MaxDB) levarem a tecnologia de instantâneos um ou dois passos adiante, para fornecer um backup consistente garantido e que possa ser verificado ao nível de bloco. Acredito que a tecnologia ZDB (backup sem tempo de inatividade, por exemplo, instantâneos) da HP para o SAP no Oracle usando o Data Protector faz isso agora! Não é verdade?

Desculpe dizer isso, mas isso é tarde demais. Vamos supor que você tenha uma corrupção no banco de dados (tarde ou cedo você terá uma). A principal saída de tal situação é recuperar um backup para evitar a perda de dados. Agora, suponha que você acabou de entrar em uma corrupção com uma das transações do SAP que você não usa com muita frequência. Que backup você pode usar e ter certeza de que a corrupção não está lá?

A corrupção de dados pode significar muitas coisas. Se estamos falando de corrupção de estrutura ou de bloco, então esperamos que seus controles de consistência e verificação de blocos do backup do banco de dados chamem a atenção do DBA. Com sorte, a recuperação do banco de dados a partir da fita e a restauração resolveriam isso.

No entanto, se estamos falando de corrupção de dados como "lixo de dados" que foi carregado no banco de dados, ou um ABAP malicioso corrompeu vários milhões de linhas de dados, então isso se torna um pouco mais complicado. Se o problema for identificado imediatamente, restaurar a partir do backup é uma opção viável para nós.

Se o problema ocorreu há mais de 48 horas, então restaurar a partir de um backup não é uma opção. Somos uma operação de fabricação 24x7x365. Enviamos produtos pelo mundo todo. Produzimos e enviamos muitos produtos em uma janela de 24 horas que não podem ser recriados (ou assim diz o negócio) se os dados forem perdidos.

Teríamos que ser criativos e fazer coisas como restaurar um backup do banco de dados de produção para outro servidor e extrair os documentos originais "bons" de volta para o original, ou esperar que o ABAP malicioso possa corrigir qualquer erro que tenham cometido originalmente nos dados.

Veja... poderíamos falar de centenas de cenários de corrupção, mas cada problema terá que ser avaliado, e a decisão de restaurar ou não será tomada com base no problema em questão.

Um procedimento muito melhor (também não incluído nas ações de clique do CCMS): - fazer um backup - fazer uma recuperação - fazer uma verificação de consistência

Adoraria pensar que isso é algo que poderíamos fazer diariamente em um sistema de testes, mas com um banco de dados de produção de 1,7 TB, nossos backups levam 6 horas, uma restauração levaria cerca de 10 horas, e a verificação de consistência... bem, um tempo.

E que luxo poder fazer isso... você conhece algum lugar que realmente faça isso?

Já escrevi sobre isso... Não é minha culpa... então de quem é?

Levei um momento para ler... sendo da Nova Zelândia, poderia facilmente me relacionar com as ovelhas ?


            
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Shaun,

> Então, para a pergunta a - simplesmente fazer uma cópia de segurança em NUL (no Windows) para evitar a restrição funcionaria?

Não o faria, por que faria? Descartar uma boa cópia de segurança que posso usar pelo menos enquanto tiver cópias de segurança de acompanhamento é algo que não faria. Por que não manter essa cópia de segurança?

Uma vez que você pode criar a cópia de segurança inicial dos dados enquanto o banco de dados estiver totalmente operacional, você não perde tempo com isso.

> E para b - concordo que gostaria de seguir uma metodologia de cópia de segurança compatível, e embora estejamos considerando usar instantâneos, não descartaremos a cópia de segurança em fita. Pelo menos, faríamos pelo menos uma cópia de segurança semanal em fita (provavelmente faremos mais de 1 por semana em fita).

Essa é uma escolha bastante sábia! Nesse caso, a cópia de segurança inicial de dados será apenas a primeira dessas cópias de segurança semanais.

> Sei que é um vídeo promocional, mas um cliente como eu vê isso e assume que a SAP está bem com isso, já que estão elogiando o MaxDB com EVAs.

Bem, ninguém nega que a SAP está "bem" com isso.

É apenas uma diferença entre estar "bem" com algo (o que significa aqui: você pode usar os recursos do MaxDB de forma que os instantâneos do EVA funcionarão para uma cópia de segurança) em comparação com a forma simples e direta que foi implementada em um nível de clique no SAP CCMS.

Tecnicamente, sua ideia de usar instantâneos provavelmente funcionará, mas, como já escrevi, você terá que cuidar do monitoramento por si mesmo.

> Quanto à verificação da consistência do instantâneo, faríamos periodicamente uma atualização do sistema de nossos sistemas de teste (trimestralmente) usando um snapclone e depois um instantâneo.

Lamento dizer que isso é tarde demais.

Suponha que você tenha uma corrupção no banco de dados (cedo ou tarde você terá uma).

A principal saída de uma situação assim é restaurar uma cópia de segurança para evitar a perda de dados.

Agora, suponha que você acabou de entrar em uma corrupção com uma das transações da SAP que não usa com muita frequência.

Que cópia de segurança você pode usar e ter certeza de que a corrupção não está lá? O instantâneo de armazenamento na verdade não lê blocos do banco de dados e não realiza nenhum tipo de verificação de consistência. Apenas uma cópia de segurança através do Kernel do MaxDB fará isso.

De qualquer forma, ainda é possível que ocorram corrupções em uma cópia de segurança.

E agora? Testar e ver se o problema está presente em todas as cópias de segurança para as quais você ainda tem cópias de segurança de registro?

Está falando sério?

Um procedimento muito melhor é (também não incluído nas ações de clique do CCMS):

- fazer uma cópia de segurança

- fazer uma recuperação

- fazer uma verificação de consistência

Se você receber um "OK" para os três passos, só então saberá que:

- seus dados foram salvos com sucesso

- realmente podem ser recuperados

- uma vez recuperados, o banco de dados estará livre de corrupção

Já escrevi sobre isso ... [Não é culpa minha - de quem então?|https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/8847] [o link original está quebrado] [o link original está quebrado] [o link original está quebrado] ;

> Também faríamos nossas verificações de consistência do banco de dados durante o fim de semana para evitar altos tempos de carga durante as horas principais de trabalho da semana.

Que sorte a sua, não há horas de trabalho no fim de semana... Aliás, seus grandes trabalhos de relatórios em lote também descansam nos fins de semana?

> E após uma atualização do sistema, faríamos uma verificação de consistência para garantir que o restaurado esteja correto (do ponto de vista estrutural).

Boa ideia, mas você estaria verificando com pouca frequência.

> Nosso objetivo com os instantâneos era substituir a maioria de nossas cópias de segurança diárias por um instantâneo, mas ainda fazer pelo menos nossas cópias de segurança semanais, mensais e anuais em fita.

Concordo plenamente e realmente gosto das oportunidades que você obtém com isso.

Mas tenha em mente

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Lars,

Então, para a pergunta a - simplesmente fazer um backup para NUL (no Windows) para evitar a restrição funcionaria?

E para b - Concordo que gostaria de seguir uma metodologia de backup compatível, e embora estejamos considerando usar instantâneos, não descartamos o backup em fita. Pelo menos, faríamos pelo menos um backup semanal em fita (é provável que façamos mais de um por semana em fita).

Suponho que o SAP "de alguma forma" suporta o MaxDB e instantâneos em um EVA4400, pois encontrei este vídeo promocional com pessoas da HP e SAP MaxDB falando sobre as funções de instantâneos, etc.:

http://h30423.www3.hp.com/index.jsp?fr_story=f752332210f499cb6619bd142f5f7a9cdca72a96&fr_chl=d9138bf...

Sei que é um vídeo promocional, mas um cliente como eu o vê e assume que o SAP concorda com isso, já que estão promovendo o EVA com o MaxDB.

Em relação à verificação da consistência da instantânea, periodicamente faríamos uma atualização do sistema de nossos sistemas de teste (trimestralmente) usando um snapclone e depois uma instantânea.

Também faríamos nossas verificações de consistência do banco de dados durante o fim de semana para evitar altos tempos de carregamento durante as horas principais de trabalho.

E após uma atualização do sistema, faríamos uma verificação de consistência para garantir que o que foi restaurado esteja correto (de uma perspectiva estrutural).

E como mencionei, não estamos eliminando completamente a fita, apenas reduzindo seu uso.

Nosso objetivo com os instantâneos era substituir a maioria de nossos backups diários por um instantâneo, mas continuar fazendo pelo menos nossos backups semanais, mensais e anuais em fita.

Saudações

Shaun

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Shaun,

ad a)

Você precisa fazer um backup completo inicial dos dados aqui - não há como evitar. Se não quiser mantê-lo, jogue-o fora depois.

ad b)

Também é um ponto onde você (atualmente) precisa decidir entre usar a abordagem da SAP (apenas usar os processos suportados e predefinidos, pois são os únicos capturados no CCMS) OU confiar em seus próprios processos de backup e monitoramento.

Já que o relatório EWA é apenas uma coleção de avisos e insights que precisam ser verificados e interpretados de qualquer forma, você sempre pode dizer que o relatório EWA está OK, a menos que o aviso de backup ausente seja o único aviso.

De qualquer forma, o que realmente me faz questionar é como o restante da sua estratégia de backup se parece.

Como você automatiza a verificação do snapshot de backup?

Como você automatiza a verificação de consistência do banco de dados de backup?

A abordagem de Snapshot-Backup que você está usando obviamente oferece a grande oportunidade de criar uma segunda cópia do banco de dados (a partir do backup feito), abrir o banco de dados e realizar uma verificação de consistência sem colocar carga na máquina de produção.

Isso faz parte do seu processo?

Atenciosamente, Lars

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?