Menu de navegação

[Fábio NascimentoParticipant]

Boa Tarde.

Sou analista de sistemas, mas não pertenço a TI da empresa, e estou cuidando de um banco de dados PRD e TST, ambos 12c sem archive ligado.

21/11/2019 – Vários dados foram cadastrados, no PRD via ERP, de vários setores em várias tabelas, inclusive eu cadastrei informações.

22/11/2019 – Fiz uma cópia fria do banco PRD, ele fica sozinho, num servidor virtual para uma base de teste TST, em outro servidor virtual e funcionou perfeitamente e a produção foi aberta normalmente.

23/11/2019 – queda de energia geral na empresa, servidores desligaram, inclusive os virtuais onde ficam os SGDBs, PRD e TST

24/11/2019 – servidores são ligados, o banco é ligado também, conforme visto no log e no v$session.

25/11/2019 – Funcionários quando precisaram, verificaram que os dados cadastrados no PRD dia 21/11/2019 não estavam mais lá e a base de Teste TST estava com os dados antigos. Também verifiquei o mesmo.

Minhas perguntas seriam:

1 – O Oracle quando sofre um dano desse, pode subir(startar) e voltar um snapshot do próprio Oracle automaticamente? E se sim onde isso fica gravado?

2 – Em casos da TI retornar um snapshot dos servidores virtuais, sempre se volta e fica transparente quando ocorre, sem transparecer ao usuário que o servidor foi restaurando? Salvo quando se nota que algo está faltando?

 

Observação:

Devido a grande complexidade de amarrações no relacionamentos, descartamos a ideia de alguém ter apagado os dados de forma proposital.

Agradeço a ajuda , se puderem.

 

Att,

 

Fábio Nascimento.

[José Laurindo ChiappaModerator]

Blz, Fábio ? Não sendo do TI eu ** acredito ** que vc logicamente não é DBA, então muito provavelmente vc não ter ter acesso e direitos pra comprovar, mas vou te passar os Conceitos de funcionamento envolvidos no seu cenário para vc Avaliar o que pode ter acontecido aí….
Seguinte : o RDBMS Oracle *** não *** trabalha com SNAPSHOTs, nem pra garantir consistência de leitura e NEM para recuperar transações… O mecanismo é : os dados ficam em arquivos chamados DATAFILES, numa estrutura chamada BLOCO – um datafile é composto de milhares de blocos, e os dadatfiles são agrupados em estruturas lógicas chamadas TABLESPACES…
Quando um SQL qualquer precisa alterar um dado, se o dado não está no cache ele TEM que ser lido e colocado no cache, que é onde acontece a alteração : por questões de Performance, NUNCA uma alteração de dados é feita diretamente nos datafiles…. os bytes alterados são gravados num LOG especial, que fica em arquivos do banco chamados REDO LOG FILES, e quando acontece o COMMIT, novamente para melhor performance, os datafiles Não SÃO SINCRONIZADOS IMEDIATAMENTE com os bytes que estão no REDO LOG FILE : o Oracle só faz uma “marquinha” no REDO LOG registrando que esses bytes FORAM comitados, e em BACKGROUND, DEVAGARINHO, ele vai lendo o conteúdo do REDO LOG e vai gravando ele no DATAFILE ao qual o dado pertence…. Há vários mecanismos de cache e similares mais pra que essa gravação não seja overhead pra performance, mas a idéia é essa ….

Até aqui, tudo bem ? Imagino que sim, não é nada tão complexo…. Muito bem, o que vai acontecer se por qquer motivo o software do RDBMS Oracle for abortado/desligado enquanto está nessa situação de dados comitados presentes no REDO LOG FILE e ainda não gravados no DATAFILE ? Na próxima vez que o RDBMS for startado, o software VAI reconhecer (através das “marquinhas” internas presentes nos arquivos) que o banco está inconsistente e VAI automaticamente ler os dados comitados dos REDO LOG FILES e os gravará nos datafiles…. Simples assim, NÃO HÁ SNAPSHOT envolvido, belezinha ???

==> O que eu SUPONHO que pode ter acontecido aí é que quando caiu a energia o redo log file ainda estava lockado pelo sistema operacional e se corrompeu (talvez não completamente, talvez só os pedaços finais do arquivo : AÍ , o redo log file indisponível, o database ficou só com os dados que já estavam no datafile….
Isso de arquivo corromper se não for fechado corretamente não é incomum, acredito que como Analista de Sistemas vc já deve ter visto N casos onde uma máquina após queda de energia perde algum arquivo por causa de cache do disco ou coisas assim…. Só o DBA desse banco pode Confirmar ou Negar o que eu disse mas é uma suposição válida…. Compreendido ??

Abraços,

Chiappa

OBS : é ULULANTEMENTE ÓBVIO que o RDBMS Oracle, tendo sido Projetado para atender ambientes Críticos, tem N mecanismos de Segurança que PODEM ser implementados para que não haja NUNCA a chance de perda de dados – um deles é, já que o REDO LOG FILE é tão crítico e importante assim, um banco Oracle PROFISSIONALMENTE gerido/controlado, com dados de PRODUÇÃO, deveria estar fazendo CÓPIAS automáticas do redo log file , isso é o ARCHIVE MODE que vc diz que tá (absurdamente, imho, se é um banco PROD) desligado aí no seu banco….
Outro mecanismo MUITO comum pra evitar perdas/corrupções no redo log é ativar o mecanismo que faz o RDBMS ORACLE gravar os bytes alterados TANTO no redo log file local do servidor PROD quanto TAMBÉM gravar esses bytes num banco STANDBY, de segurança, que reside em OUTRO servidor…. okdoc ??

[Author]

Posts