Menu de navegação

[acg1574Participante]

Pessoal, tem uma instancia nossa que achei o backup dela e gostaria de voltar ele, só tenho o dmp dela, minha duvida é o seguinte, tenho um servidor de homologacao, e tenho uma instancia nele, e o dump que tenho de 2018 o nome da instancia era outra, preciso criar essa instancia, como nunca fiz isso gostaria de uma ajuda para cria-la e importar o dump, e tambem gostaria de saber se corro o risto de atrapalhar algo na instancia hoje ativa ja que os controls files , tables spaces provavelmente eram os mesmos nomes

Outra coisa que gostaria de saber é se tem como eu verificar as informacoes do dump antes de importar ele, pra ver o nome da instancia e outras informacoes necessarias, caminho de pastas, etc…

obrigado a todos.

[José Laurindo ChiappaModerador]

Tudo jóia ? Espero que sim… Então, na verdade um dump file ***** NÃO ****** pode ser considerado um BACKUP propriamente dito Justamente pelo FATO de não registrar/guardar EM LUGAR NENHUM as informações INTERNAS do database, como dados de instância, Dicionário de Dados, patches aplicados, CHARACTERSET e LINGUAGEM usados, etc, etc, etc : um dump file contém APENAS e TÃO SOMENTE os dados DOS USUÁRIOS e as estruturas físicas (tabelas, índices, tablespaces, constraints, etc) desses dados…

Sendo assim, em caso de crash OU de necessidade de voltar esses dados, PRIMEIRO vc TEM que ter um database na MESMA EXATA VERSÃO/RELEASE e Edition,com os MESMO EXATOS patches aplicados, OU TEM que criar um database vazio nessas condições, para Só DEPOIS vc poder trazer esses dados de usuário do dump file pra dentro desse database criado ou que já existe – CASO vc só tenha mesmo o dump file E não tenha registro de versão, Edition,patch level e dados/propriedades da instância a partir de onde esses dados foram extraídos e o dump file gerado, FERROU : absolutamente Não Tem Como vc obter TODAS essas informações a partir do dump file, que (como foi dito) é só uma cópia DOS DADOS DE USUÁRIO, simplesmente, nada mais, nada menos – dados INTERNOS do database absolutamente Não Fazem parte do escopo de um dump file……

Isso explicado, fica patente que Não tem Como fazer o que vc perguntou, Não Tem Como vc extrair de um dump dados que Não Estão Lá…. O que vc VAI ter que fazer é, PRIMEIRO, já que vc Não Vai Saber exatamente nem a versão nem o release nem o patch level, é tentar ler esse dump num database bem recente, tipo 19c : como vc diz que esse dump file é de 2018, certamente deve ser Anterior ao 19c, é razoável supor que todos os patches constantes dessa versão antiga que vc usava em 2018 DEVEM estar presentes no 19c… E como vc Não Sabe qual foi a Edition usada, sugiro usar um 19c ENTERPRISE EDITION, que é a Edition mais “alta”, que em tese contém todos os recursos possíveis do SGBD Oracle em si…. E, repetindo, como dito num dump file nós Não Temos nome de instância (então é ABSOLUTAMENTE INDIFERENTE o NOME da instância existente ou criada que controla o database existente ou criado onde vc vai importar o dump) mas nós TEMOS SIM nomes de tablepaces, de schemas/usuários, de tabelas, índices, etc, etc : para EVITAR que eventualmente algum usuário ou objeto seja sobrescrito/tenha dados indesejados adicionados, o IDEAL é que esse database 19c aonde vc vai importar os dados de usuário do dump seja criado mesmo do zero, com NOME e LOCAIS diferentes do database homologação que vc já tem hoje – DEPOIS de tudo importado aí sim vc PODE mover dados paraHomologação, se desejado….

E FINALMENTE : algumas POUCAS informações internas usadas NA SESSÃO QUE FEZ A EXPORTAÇÃO (os valores reais do database, como eu disse, não ficam registrados no dum file), tais como characterset, versão da tool de dump usada, e algumas poucas mais, vc pode SIM extrair do dump file e pode deduzir (NÃO é 100% certo, absoluto, mas melhor que nada) que no database estejam os mesmo settings/valores : veja https://pavandba.com/2011/07/13/different-ways-to-get-dumpfile-version-other-information/ para alguns exemplos/links….
Falando sobre o conteúdo de armazenamento de dados(ie, estruturas , usuários, tablespaces, etc), que isso SIM nós temos dentro de um dumpfile, vc tem duas opções pra obter isso : SE o dump file foi gerado com a tool de exportação default e recomendada do 10g em diante, use a opção SQLFILE no impdp cfrme https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL933 indica , E se foi usada versão inferior à 10g (acredito que não, em 2018 10g já estava fora de suporte, mas enfim), aí use a opção INDEXFILE no imp , cfrme https://community.oracle.com/tech/developers/discussion/427023/how-to-extract-a-ddl-from-a-dump-database mostra….

Abraços,

José Laurindo Chiappa

OBS : notar que vc VAI ter todo esse trabalho EXTRA não por causa de problemas de usabilidade ou de complexidade mas sim porque quem usou a ferramenta Não Sabia o que estava fazendo, Não sabia como ela trabalha e assim NÃO registrou os detalhes INTERNOS do database de onde foi gerado o dump file originalmente… ok ?? E um detalhe, era MUITO MUITO FÁCIL a pessoa ter Documentado isso, bastaria ter colocado como argumento pro comando exp / expdp na hora de gerar o dumpfile o comando que gera um arquivo de log (normalmente se chama LOGFILE mesmo), E ter feito algumas poucas queries na GV$DATABASE, DBA_REGISTRY e GV$INSTANCE) e deixado o output delas junto com o dump file, que praticamente TODO ou quase TODO esse trabalho que indiqeui acima TERIA sido desnecessário…

[Autor]

Posts