- This topic has 7 replies, 4 voices, and was last updated 8 years, 8 months ago by José Laurindo Chiappa.
-
AuthorPosts
-
29 de fevereiro de 2016 at 5:05 am #108048bruno_dbaParticipant
olá pessoal, gostaria de tirar uma duvida, só por desencargo mesmo, tenho um banco que sofreu ataque de hacker onde quase todos datafiles físicos foram criptografados, porem 2 dos principais arquivos dados e indices não foram danificados pela criptografia, a duvida seria a seguinte eu conseguiria associar esses dois datafiles em um novo database ?
eu tentei fazer o padrão recriar o controlfile adicionando a tablespace porem ocorre o erro
ERRO na linha 1:
ORA-01503: CREATE CONTROLFILE falhou
ORA-01159: o arquivo n?o e do mesmo banco de dados que o arquivo anterior – id
de banco de dados incorreto
ORA-01110: 6 do arquivo de dados: ‘C:APPORACLEORADATAXEINDICES01.DBF’pesquisei sobre mas não achei muita coisa, será que existe alguma forma de forçar o oracle abrir esses arquivos mesmo sendo de outro banco id diferente ?, uma opção que tbm não encontrei, será que existe algum programa que consiga extrair DDL de dentro dos arquivos fisicos ?.
obrigado pessoal.
29 de fevereiro de 2016 at 3:18 pm #108049rmanParticipant@bruno_dba
A grande pergunta, e o backup? Tanto um backup Datapump/Rman resolveria o problema.
29 de fevereiro de 2016 at 4:02 pm #108050guilhermeParticipant@bruno_dba
Acredito que não possa executar este procedimento que estas tentando. Como o @rman falou, procura utilizar o backup neste caso…
29 de fevereiro de 2016 at 5:43 pm #108052bruno_dbaParticipanto problema é que todos arquivos de backup, datapump, rmam que estavam em outro servidor da rede foram criptografados por esse malware, esse é um ambiente de um cliente toda infra é responsa dele, eu apenas administro o banco conforme a necessidade deles.
infelizmente o jeito vai ser ele pagar o resgate dos dados para o hacker.
29 de fevereiro de 2016 at 5:44 pm #108053bruno_dbaParticipantrealmente, se o cliente copiasse o bkp pra outro lugar, mas deixava na mesma rede em hd externo, o malware infectou e criptografou tudo.
29 de fevereiro de 2016 at 5:57 pm #108054rmanParticipant@bruno_dba
Se a partir desse episódio houver mudança na política de backup e recovery já é um avanço. Aqui o backup é feito em fita magnética.
29 de fevereiro de 2016 at 6:43 pm #108055bruno_dbaParticipantcom certeza os caras vão ficar mais espero e manter isso fora da rede.
[quote=”rman” post=33448]@bruno_dbaSe a partir desse episódio houver mudança na política de backup e recovery já é um avanço. Aqui o backup é feito em fita magnética.[/quote]
29 de fevereiro de 2016 at 11:33 pm #108057José Laurindo ChiappaModeratorbruno, que fique claro que tecnicamente falando, para que um datafile possa ser relacionado com um determinado database, vc precisa ** sim ** de dados extras/metadados que estão fora do datafile, lá nas tabelas do SYS, além do controlfile que relaciona as coisas : só uma cópia do datafile em si não serve de ABSOLUTAMENTE COISA NENHUMA, tá bem ?? SE o seu cliente, sabendo disso, além dos backups/cópias dos datafiles em si tivesse feito uma CÓPIA desses metadados aí sim vc poderia fazer o RDBMS Oracle “registrar” esses datafiles em outro banco, veja na documentação sobre TRANSPORTABEL TABLESPACE…
Agora : Ok que no caso foi algo excepcional, um caso de violação de sistemas, mas digamos que o cliente tivesse perdido os arquivos por questões técnicas, tipo falha de hardware ou bug, o que que ele faria para os recuperar de volta ??? Isso não tava previsto na política de recuperação dele ??
Se a resposta for “não tem como se recuperar de perdas em qualquer situação/posição no tempo após o último backup”, o que vc vai fazer é Aproveitar a situação da perda por violação para Apontar a necessidade de complementação na política de backup (com backup de archives mais frequentes, quem sabe) , talvez (se houver uma criticidade que justifique) pensar na hipótese de stand-by, de gerar os metadados para possível replug de datafiles via export, etc…
Por mais que vc “só administre”, quando vc vê uma situação de risco imho é parte da tua obrigação com o cliente a apontar : se mais tarde ele não te der bola e te ignorar/ignorar a tua recomendação técnica azar o dele, ao menos a sua Obrigação como expert vc fez….[]s
Chiappa
-
AuthorPosts
- You must be logged in to reply to this topic.