› Fóruns › Banco de dados Oracle › Oracle XE com problema WS 2012 R2 em Português › Responder a: Oracle XE com problema WS 2012 R2 em Português
José Laurindo ChiappaBlz ? Então, sobre dump files, antes de qualquer coisa, eu TENHO que te dizer que o ** Mínimo ** que os técnicos desse teu cliente DEVERIAM saber é isso, exatamente QUAL versão de utilitário de export foi usada, exatamente QUAIS parãmetros foram usados, exatamente QUAL era a versão do database e a Edition dele – INCLUSIVE, a versao E a Edition é crucial porque com certeza features mais avançadas (como compressão de dados, criptografia, entre muitas outras) que PODEM existir num banco ENTERPRISE EDITION (a Edition mais completona e profissional) certamente Não Existem num Standard Edition, e também o mesmo para versões : não é impossível um banco versão X não apresentar (porque foi removida/eliminada, digamos) algum feature presente numa versão antiga Y, aí babau… E digo isso não só para vc poder importar mais facilmente, mas ELES MESMOS se tivessem que abrir e importar dados desse dump file TERIAM que informar essas coisas, certo ? Isso me parece MUITO aquele tipo de “backup”/compartilhamento de dados feito sem o menor critério, sem documentação alguma, e (pior) SEM que ninguém tenha testado a Recuperação dele, pessoal confia que está íntegro mas ninguém se deu ao trabalho de realmente fazer um teste de importação… Argh….. E um detalhe adicional, seria MUITO MUITO fácil ter sido solicitado e gerar junto com o .dmp um arquivo-texto de LOG, com TODOS os detalhes da execução e com TODAS as mensagens enviadas pra tela durante o export, era só acrescentar o parâmetro de LOG adequado, normalmente um simples LOGFILE=nomedoarquivodelog.log – com Certeza isso não foi feito, né ? argh#2…..
Bom, respondendo : primeiro de tudo, fyi, desde a versão 10g do SGBD Oracle, um database Oracle possui DUAS ferramentas de exportação e importação capazes de gerar e manipular arquivos .DMP : a mais antiga, defasada MAS ainda presente , são os utilitários exp e imp tradicionais, E a mais atual, recomendada e suportada é o DATAPUMP, que vc aciona com as “novas” tools expdp e impdp – teu Primeiro passo normalmente seria verificar QUAL dessas tools (a tradicional/aposentada OU a nova/recomendada) foi usada, porém como vc tentou usar o impdp e ele Não te deu uma mensagem tipo “IMP-00010: not a valid export file, header failed verification”, é quase Certo que foi usado o expdp/datapump….
Muito bem : sendo isso, https://smarttechways.com/2019/09/16/check-the-version-of-dump-file-before-import-in-oracle/ exemplifica a tool (uma package built-in) que se usa para obter detalhes de um dumpfile gerado via datapump, vejá lá : porém, dada essa mensagem “ORA-39358: Export dump file version 19.3.0.0.0 not compatible with target version 18.1.0.0.0”, é quase certo (vc VAI verificar, mas parece quase certo) que realmente foi usada uma versão mais RECENTE para gerar o dumpfile (versão 19c) do a versão presente no banco tentando importar (18c), é Claro que isso não é compatível por default : veja vc, é CLARO que a versão mais nova (19c) TROUXE novos recursos que no tempo da versão antiga (18c) não eram nem sonhados….A compatibilidade no Oracle é sempre BACKWARD COMPATIBILITY, ie, a versão mais nova conhece TODOS os recursos da versão antiga via de regra, NUNCA o inverso, não tem como a versão antiga ADIVINHAR quais novas features vão existir nas versões mais novas….. CLARO que tem uma maneira da versão mais nova (19c no seu caso) gerar um dumpfile Ignorando as novas features, assim deixando ele Compatível com versões antigas, seria o parâmetro VERSION=numerodaversãoantogadesejada ,mas se deu essa msg aí de cima, com Certeza não foi usado esse parâmetro…
Respondendo então : sendo mesmo verdadeiro isso que indiquei acima, sim, pra vc poder importar esse dump file vc PRECISARÁ fazer isso num database 19c versão 19.3.xxx ou superior (pode ser 21c, sim) ….. E REPITO, nisso estamos falando só da versão : uma vez aberto o dumpfile e extraído o conteúdo com SQLFILE e também obtidos detalhes do header com a package indicada antes, TEM que analisar o SQLFILE e o resultado da package e ver se a Edition de origem tem alguma features “avançada” que a Edition destino não tenha….
Abraços,
José Laurindo Chiappa
Obs : insisto, vc está tendo esse trabalho EXTRA *** não *** porque o SGBD Oracle seja complexo de lidar ou por deficiência das tools , mas sim PELO FATO dos técnicos do seu cliente que geraram o dumpfile Não Saberem o que estavam fazendo e Não terem seguido as best practices…..