Menu de navegação

[marceloantonioParticipante]

Olá a todos,
Instalei um Oracle XE 11g R2 em um servidor Windows Server 2012 R2 e Português, e observei alguns problemas com por exemplo a past /bin do Oracle não foi adicionada a PATH, e o que aconteceu é que foi criada uma variavel “CAMINHO” (PATH em portugues) e /bin foi adicionado nessa variável.

Também não consigo abrir a console web 127.0.0.1:8080/….

Instalei o mesmo Oracle XE em um servidor Windows Server 2012 R2 em Inglês e não tive nenhum problema.
Alguém já viu esse comportamento?
Existe um forma de contornar isso?

Obrigado antecipadamente.

[José Laurindo ChiappaModerador]

Opa, blz ? Então, com CERTEZA vc está com algum BUG em mãos : como porém TANTO o Oracle 11g QUANTO o Windows Server 2012 são versões ANTIQUÍSSIMAS, que não tem nem SOMBRA de Suporte, o que vc faria é work-around mesmo, ie : editar a variável PATH manualmente – eu na verdade prefiro ter um .BAT que já seta para mim ORACLE_SID, ORACLE_HOME e PATH…

Outro ponto aí é que as versões antigas do Oracle Enterprise Manager dbconsole (a versão single-instance, extremamente capada e limitada) que vinha com as versões antigas do Oracle USAVAM java, que vem sendo removido Completamente dos browsers de internet mais modernos : recomendo vc usar ao invés dela o Oracle SQL DEVELOPER, que vc baixa gratuitamente no site da Oracle…

Abraços,

José Laurindo Chiappa

[marceloantonioParticipante]

Obrigado Chiappa,
Eu preferi manter apenas a VM com WS 2012 R2 em ingles, e não tive nenhum problema. Acho que a velha máxima de que servidor dever ser mantido sempre no idioma ingles se comprovou no meu caso, apesar de alguns MCSEs dizerem que não tem nada a ver, mas na prática pude comprovar que parece mesmo que tem problemas sim.

Entretanto, agora estou com outro problema, recebi um DUMP de um Cliente e preciso restaurar num servidor Oracle, mas não tenho nenhuma informação da versão do export e o Cliente também não sabe.

Instalei um XE 18.4, e ao tentar importar estou tendo a seguinte mensagem:

C:\Users\macmar>impdp system/Welcome01 dumpfile=FOLHASS7-ORA01-01-20220531.DMP,FOLHASS7-ORA01-02-20220531.DMP,FOLHASS7-ORA01-03-20220531.DMP content=metadata_only sqlfile=sqlfile.sql

Import: Release 18.0.0.0.0 – Production on Mon Dec 5 17:21:28 2022
Version 18.4.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 18c Express Edition Release 18.0.0.0.0 – Production
ORA-39002: invalid operation
ORA-39358: Export dump file version 19.3.0.0.0 not compatible with target version 18.1.0.0.0

Pelo erro ORA-39358, estou a entender que o export provavelmente foi feito em um Oracle 19.3, e como o meu ambiente é um 18.4 então não conseguirei importar, certo?

Preciso instalar um 19c ou 21c para conseguir importar?
Existe alguma tool da Oracke onde eu consiga ler o DUMP para saber qual a versão foi gerado?
Muito obrigado pela preciosa ajuda.

[José Laurindo ChiappaModerador]

Blz ? Então, sobre a questão da língua do servidor, sim : SEMPRE vai ser feita uma Tradução, uma Adaptação em cima do software original, e isso PODE levar em raros casos à bugs …. Não estou dizendo que seja uma Prática Recomendada em absolutamente 100% dos casos, que em TODOS os softwares em TODAS as versões vai SEMPRE causar bugs/interferência a tradução, mas é algo possível – então, se isso não te incomoda em nada, principalmente ao lidar com softwares antigos e sem suporte como é XE 11g e Windows Server 2012, pode ser interessante ter a política de trabalhar com a versão original em Inglês dos softwares….

Abraços,

Chiappa

[José Laurindo ChiappaModerador]

Blz ? 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…..

[Autor]

Posts