Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Vlw Chiappa é exatamente isso que estou fazendo ... obrigado!


Em 13 de abril de 2017 18:04, Mario Rodrigues 
escreveu:

> Vlw Chiappa .. é exatamente isos
>
>
> Em 13 de abril de 2017 18:02, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Ok : entendo que por enquanto os volumes de dados reais vindos da
>> Produção estão cabendo no Oracle XE, E no momento a Aplicação não está
>> usando nenhum recurso que inexiste no XE,  por isso vc estava usando o XE
>> (já que ele é free pra qualquer tipo de dado, em qualquer ambiente , com
>> código prod ou não, nada importa) enquanto não é licenciado um RDBMS full
>> que vai virar Prod e nessa ocasião vai ultrapassar o tamanho de dados
>> permitido no XE, tendi
>>  Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal
>> tá providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos
>> em cima desses dados reais mas em pequeno volume no XE mesmo...
>>   Para que o import possa ocorrer vc vai criar um banco XE novo e usar
>> uma das opções que indiquei em URLs anteriores - acredito que a melhor seja
>> a opção de fazer o import criar as tabelas sem dados E delimitrada por BYTE
>> mesmo que nem deve estar vindo da Produção/origem  e depois rodar o
>> scriptzinho que altera as colunas string de delimitado em BYTEs para
>> delimitado em CHARs Feito isso aí vc roda o import de dados
>>
>> []s
>>
>>   Chiappa
>> 
>>
>
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Vlw Chiappa .. é exatamente isos


Em 13 de abril de 2017 18:02, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Ok : entendo que por enquanto os volumes de dados reais vindos da Produção
> estão cabendo no Oracle XE, E no momento a Aplicação não está usando nenhum
> recurso que inexiste no XE,  por isso vc estava usando o XE (já que ele é
> free pra qualquer tipo de dado, em qualquer ambiente , com código prod ou
> não, nada importa) enquanto não é licenciado um RDBMS full que vai virar
> Prod e nessa ocasião vai ultrapassar o tamanho de dados permitido no XE,
> tendi
>  Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal
> tá providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos
> em cima desses dados reais mas em pequeno volume no XE mesmo...
>   Para que o import possa ocorrer vc vai criar um banco XE novo e usar uma
> das opções que indiquei em URLs anteriores - acredito que a melhor seja a
> opção de fazer o import criar as tabelas sem dados E delimitrada por BYTE
> mesmo que nem deve estar vindo da Produção/origem  e depois rodar o
> scriptzinho que altera as colunas string de delimitado em BYTEs para
> delimitado em CHARs Feito isso aí vc roda o import de dados
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Ok : entendo que por enquanto os volumes de dados reais vindos da Produção 
estão cabendo no Oracle XE, E no momento a Aplicação não está usando nenhum 
recurso que inexiste no XE,  por isso vc estava usando o XE (já que ele é free 
pra qualquer tipo de dado, em qualquer ambiente , com código prod ou não, nada 
importa) enquanto não é licenciado um RDBMS full que vai virar Prod e nessa 
ocasião vai ultrapassar o tamanho de dados permitido no XE, tendi
 Muito bem, minha Recomendação seria nesse meio-tempo enquanto o pessoal tá 
providenciando um banco FULL vc ir fazendo seus testes/desenvolvimentos em cima 
desses dados reais mas em pequeno volume no XE mesmo...
  Para que o import possa ocorrer vc vai criar um banco XE novo e usar uma das 
opções que indiquei em URLs anteriores - acredito que a melhor seja a opção de 
fazer o import criar as tabelas sem dados E delimitrada por BYTE mesmo que nem 
deve estar vindo da Produção/origem  e depois rodar o scriptzinho que altera as 
colunas string de delimitado em BYTEs para delimitado em CHARs Feito isso 
aí vc roda o import de dados

[]s

  Chiappa

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Exatamente o X da questão é teste hoje .. mas vai virar produção e os dados
do teste SÃO REAIS.

Infelizmente é a realidade rsrsrs .. já conversei com o diretor e estamos
vendo licenças .. vlw pessoal


Em 13 de abril de 2017 15:25, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Exatamente, embora depende de que tipo de DESENVOLVIMENTO e/ou TESTES que
> vão ser feitos nesse banco aí : se são testes com dados ** reais ** vindos
> de Produção, e/ou se o código sendo Desenvolvido vai fazer parte de um
> Produto/Aplicativo que vai ser vendido e gerar lucro OU vai ser usado em
> Produção a licença de Desenvolvimento do OTN Absolutamente Não é Válida
> nesse cenário, aí é OU usar o XE OU comprar Licença de Standard ou
> Enterprise, sim, sim
>
>  Já se os dados NÃO SÃO dados reais de um cliente seu nem da sua Produção,
> E qquer código desenvolvido nesse banco NÃO VAI SER executado em produção e
> nem vendido para seus clientes (ou seja, esse código é só uma POC, uma
> Prova de Conceito, um teste simples pra vc ver se um ponto está funcionando
> bem, ou para aprender uma determinada tecnologia, sem dados reais e SEM
> reaproveitar em PROD o código) realmente, a licença Developer do OTN diz
> Claramente que pra esses casos vc está 100% no direito de baixar qquer
> versão de banco Enterprise ou Standard lá no OTN e usar `à vontade, sem
> custo nenhum E por quanto tempo quiser... SE o uso lá do colega se encaixa
> nessas restrições Sim, seria legal ele baixar no OTN e passar a usar ou
> Standard ou Enterprise, pois (entre outras vantagens) nesses bancos se pode
> mudar o CHARACTERSET tranquilinho
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Exatamente, embora depende de que tipo de DESENVOLVIMENTO e/ou TESTES que vão 
ser feitos nesse banco aí : se são testes com dados ** reais ** vindos de 
Produção, e/ou se o código sendo Desenvolvido vai fazer parte de um 
Produto/Aplicativo que vai ser vendido e gerar lucro OU vai ser usado em 
Produção a licença de Desenvolvimento do OTN Absolutamente Não é Válida nesse 
cenário, aí é OU usar o XE OU comprar Licença de Standard ou Enterprise, sim, 
sim 

 Já se os dados NÃO SÃO dados reais de um cliente seu nem da sua Produção, E 
qquer código desenvolvido nesse banco NÃO VAI SER executado em produção e nem 
vendido para seus clientes (ou seja, esse código é só uma POC, uma Prova de 
Conceito, um teste simples pra vc ver se um ponto está funcionando bem, ou para 
aprender uma determinada tecnologia, sem dados reais e SEM reaproveitar em PROD 
o código) realmente, a licença Developer do OTN diz Claramente que pra esses 
casos vc está 100% no direito de baixar qquer versão de banco Enterprise ou 
Standard lá no OTN e usar `à vontade, sem custo nenhum E por quanto tempo 
quiser... SE o uso lá do colega se encaixa nessas restrições Sim, seria legal 
ele baixar no OTN e passar a usar ou Standard ou Enterprise, pois (entre outras 
vantagens) nesses bancos se pode mudar o CHARACTERSET tranquilinho
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Mario,
   Se você não vai usar este sistema em produção, está fazendo testes ou 
desenvolvimento, pode usar uma versão full com a licença "OTN", que não tem 
custo.
    Mas para isso não pode ter esse sistema em produção ai na empresa ou 
organização onde você está. Se tiver uma produção do sistema, a licença OTN não 
vale.
Atc,Luis Freitas 

On Wednesday, April 12, 2017 4:35 PM, "jlchia...@yahoo.com.br [oracle_br]" 
 wrote:
 

     Intão, Angelo : sim, muito provavelmente corrompeu o XE atual mas como era 
uma instância de testes e POCs pelo que entendi então não vale a pena o 
trabalho de tentar consertar, é criar outra  instância mesmo... 
 Agora, não necessariamente essa nova instância ** Obrigatoriamente ** teria 
que ser algo 'full', ie, Standard ou Enterprise : seria interessante se pudesse 
ser algo acima do XE (pois entre outras coisas assim o cara poderia testar 
recursos não disponíveis no XE) mas se isso não for viável (principalmente por 
causa de CUSTOS!!), é ** TOTALMENTE POSSÍVEL ** vc importar dumps de banco 
'full' no e repetir testes / executar rotinas no XE mesmo que elas foram 
originalmente desenvolvidas num banco 'full', *** RESPEITANDO-SE os limites e 
ausências do XE
 
 []s
 
   Chiappa  #yiv9047748934 #yiv9047748934 -- #yiv9047748934ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv9047748934 
#yiv9047748934ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv9047748934 
#yiv9047748934ygrp-mkp #yiv9047748934hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv9047748934 #yiv9047748934ygrp-mkp #yiv9047748934ads 
{margin-bottom:10px;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad 
{padding:0 0;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad p 
{margin:0;}#yiv9047748934 #yiv9047748934ygrp-mkp .yiv9047748934ad a 
{color:#ff;text-decoration:none;}#yiv9047748934 #yiv9047748934ygrp-sponsor 
#yiv9047748934ygrp-lc {font-family:Arial;}#yiv9047748934 
#yiv9047748934ygrp-sponsor #yiv9047748934ygrp-lc #yiv9047748934hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv9047748934 
#yiv9047748934ygrp-sponsor #yiv9047748934ygrp-lc .yiv9047748934ad 
{margin-bottom:10px;padding:0 0;}#yiv9047748934 #yiv9047748934actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv9047748934 
#yiv9047748934activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv9047748934
 #yiv9047748934activity span {font-weight:700;}#yiv9047748934 
#yiv9047748934activity span:first-child 
{text-transform:uppercase;}#yiv9047748934 #yiv9047748934activity span a 
{color:#5085b6;text-decoration:none;}#yiv9047748934 #yiv9047748934activity span 
span {color:#ff7900;}#yiv9047748934 #yiv9047748934activity span 
.yiv9047748934underline {text-decoration:underline;}#yiv9047748934 
.yiv9047748934attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv9047748934 .yiv9047748934attach div a 
{text-decoration:none;}#yiv9047748934 .yiv9047748934attach img 
{border:none;padding-right:5px;}#yiv9047748934 .yiv9047748934attach label 
{display:block;margin-bottom:5px;}#yiv9047748934 .yiv9047748934attach label a 
{text-decoration:none;}#yiv9047748934 blockquote {margin:0 0 0 
4px;}#yiv9047748934 .yiv9047748934bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv9047748934 
.yiv9047748934bold a {text-decoration:none;}#yiv9047748934 dd.yiv9047748934last 
p a {font-family:Verdana;font-weight:700;}#yiv9047748934 dd.yiv9047748934last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv9047748934 
dd.yiv9047748934last p span.yiv9047748934yshortcuts 
{margin-right:0;}#yiv9047748934 div.yiv9047748934attach-table div div a 
{text-decoration:none;}#yiv9047748934 div.yiv9047748934attach-table 
{width:400px;}#yiv9047748934 div.yiv9047748934file-title a, #yiv9047748934 
div.yiv9047748934file-title a:active, #yiv9047748934 
div.yiv9047748934file-title a:hover, #yiv9047748934 div.yiv9047748934file-title 
a:visited {text-decoration:none;}#yiv9047748934 div.yiv9047748934photo-title a, 
#yiv9047748934 div.yiv9047748934photo-title a:active, #yiv9047748934 
div.yiv9047748934photo-title a:hover, #yiv9047748934 
div.yiv9047748934photo-title a:visited {text-decoration:none;}#yiv9047748934 
div#yiv9047748934ygrp-mlmsg #yiv9047748934ygrp-msg p a 
span.yiv9047748934yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv9047748934 
.yiv9047748934green {color:#628c2a;}#yiv9047748934 .yiv9047748934MsoNormal 
{margin:0 0 0 0;}#yiv9047748934 o {font-size:0;}#yiv9047748934 
#yiv9047748934photos div {float:left;width:72px;}#yiv9047748934 
#yiv9047748934photos div div {border:1px solid 
#66;height:62px;overflow:hidden;width:62px;}#yiv9047748934 
#yiv9047748934photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv9047748934
 

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Intão, Angelo : sim, muito provavelmente corrompeu o XE atual mas como era uma 
instância de testes e POCs pelo que entendi então não vale a pena o trabalho de 
tentar consertar, é criar outra  instância mesmo... 
 Agora, não necessariamente essa nova instância ** Obrigatoriamente ** teria 
que ser algo 'full', ie, Standard ou Enterprise : seria interessante se pudesse 
ser algo acima do XE (pois entre outras coisas assim o cara poderia testar 
recursos não disponíveis no XE) mas se isso não for viável (principalmente por 
causa de CUSTOS!!), é ** TOTALMENTE POSSÍVEL ** vc importar dumps de banco 
'full' no e repetir testes / executar rotinas no XE mesmo que elas foram 
originalmente desenvolvidas num banco 'full', *** RESPEITANDO-SE os limites e 
ausências do XE
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Sim sim Ângelo, eu criei um novo banco .. sobre usar uma versão full,
realmente já estou pensando nisso sim ..

Obrigado



Em 12 de abril de 2017 15:37, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Mas agora o banco provavelmente foi corrompido.. pelo que comentou o
> Chiappa na mensagem anterior.. verifica se nao aconteceu ?
>
> Acho que vc vai precisar abandonar o XE e trabalhar com a versao full do
> banco (standard, enterprise)
>
> Se fosse uma situação de um banco normal, do tipo, não quisesse alterar o
> characterset,  ainda teria a opção de poder criar um novo banco e trabalhar
> em cima
>
>
>
>
> 2017-04-12 15:08 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br] :
>
>>
>>
>> Ângelo,
>>
>>
>> Pois eh .. vi ate uma resposta tua a alguns dias
>>  "
>>
>> https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH
>>
>>
>> AL16UTF16
>>
>> Unicode 4.0 UTF-16 Universal character set
>>
>> AL32UTF8
>>
>> Unicode 4.0 UTF-8 Universal character set
>>
>> UTF8
>>
>> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
>> "
>>
>> Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
>> antes de importar os dados:(
>>
>> Vlww
>>
>>
>> Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Mario,
>>>
>>>
>>> Dá uma olhada nisso aqui =>   http://stackoverflow.com/que
>>> stions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>>>
>>> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/B1
>>> 9306_01/server.102/b14225/ch2charset.htm
>>>
>>>
>>> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
>>> isso, mesmo que altere o banco vai chiar... eu acho
>>> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
>>> samba..
>>>
>>>
>>>
>>>
>>>
>>> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
>>> [oracle_br] :
>>>


 Pessoal

 Boa tarde

 Voltando com o topico, a empresa me enviou o characterset é o
 WE8ISO8859P1.

 Dai alterei usando "Alter database character set INTERNAL_USE
 WE8ISO8859P1;" (nunca havia feito, achei na internet)
 Rodando os SQL's
 SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
 SELECT value FROM nls_database_parameters WHERE parameter =
 'NLS_CHARACTERSET'

 Dai blz, quando tento realizar o IMPORT aparecem 2 erros:

 ORA 39006 Erro interno
 ORA 39213 metadados não disponível

 Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import
 com o SYS e da o mesmo erro.


 Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
 oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Acredito que talvez seja no 12c apenas - mas independente disso, já
> que vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU 
> a
> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
> constar qual  o characterset origem usado na exportação E a ** minha 
> **
> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
> ???
>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>
> []s
>
>   Chiappa
>


>>>
>>
> 
>

Re: [oracle_br] impdp

[angelo angelolis...@gmail.com [oracle_br]]

Mas agora o banco provavelmente foi corrompido.. pelo que comentou o
Chiappa na mensagem anterior.. verifica se nao aconteceu ?

Acho que vc vai precisar abandonar o XE e trabalhar com a versao full do
banco (standard, enterprise)

Se fosse uma situação de um banco normal, do tipo, não quisesse alterar o
characterset,  ainda teria a opção de poder criar um novo banco e trabalhar
em cima




2017-04-12 15:08 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
[oracle_br] :

>
>
> Ângelo,
>
>
> Pois eh .. vi ate uma resposta tua a alguns dias
>  "
>
> https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH
>
>
> AL16UTF16
>
> Unicode 4.0 UTF-16 Universal character set
>
> AL32UTF8
>
> Unicode 4.0 UTF-8 Universal character set
>
> UTF8
>
> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
> "
>
> Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
> antes de importar os dados:(
>
> Vlww
>
>
> Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Mario,
>>
>>
>> Dá uma olhada nisso aqui =>   http://stackoverflow.com/que
>> stions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>>
>> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/B1
>> 9306_01/server.102/b14225/ch2charset.htm
>>
>>
>> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
>> isso, mesmo que altere o banco vai chiar... eu acho
>> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
>> samba..
>>
>>
>>
>>
>>
>> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Pessoal
>>>
>>> Boa tarde
>>>
>>> Voltando com o topico, a empresa me enviou o characterset é o
>>> WE8ISO8859P1.
>>>
>>> Dai alterei usando "Alter database character set INTERNAL_USE
>>> WE8ISO8859P1;" (nunca havia feito, achei na internet)
>>> Rodando os SQL's
>>> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
>>> SELECT value FROM nls_database_parameters WHERE parameter =
>>> 'NLS_CHARACTERSET'
>>>
>>> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>>>
>>> ORA 39006 Erro interno
>>> ORA 39213 metadados não disponível
>>>
>>> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com
>>> o SYS e da o mesmo erro.
>>>
>>>
>>> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
>>> oracle_br@yahoogrupos.com.br> escreveu:
>>>


 Acredito que talvez seja no 12c apenas - mas independente disso, já que
 vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
 usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
 STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
 constar qual  o characterset origem usado na exportação E a ** minha **
 Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
 originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
 ???
  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa

 []s

   Chiappa

>>>
>>>
>>
> 
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Vlw Chiappa, o banco realmente havia corrompido, porem como são testes não
é muito problema ...

Sobre as sugestões de testes, vou fazer isso sim ..

Obrigado!

Em 12 de abril de 2017 15:20, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Ops, desconsidere o link de exemplo final, http://serverfault.com/
> questions/317151/how-do-i-make-imp-use-right-charachter-set é o link mais
> apropriado, que contém um script que muda as colunas string definidas como
> BYTE limited para CHAR limited
>
> []so
>
>   Chiappa
>
>
> ---Em oracle_br@yahoogrupos.com.br,  escreveu:
>
>
> Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior
> vc já tinha dito que teu banco 11g E tinha dito que é Express Edition (não
> diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o
> tamanho" é ESSa a dedução), e está Completamente Documentado que o Oracle
> XE ** não ** é oficialmente compatível com qualquer characterset - veja em
> http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a
> info :
>
> "Table 4 Supported Universal Character Sets
> Name Description
>
> AL16UTF16
>
>
> Unicode 4.0 UTF-16 Universal character set
>
> AL32UTF8
>
>
> Unicode 4.0 UTF-8 Universal character set
>
> UTF8
>
>
> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
> 
> 
> "
>
> Então pra mim ao mandar um comando "Alter database character" para um
> characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário
> de dados, sim sim ?? Não é à toa que coisas que dependem de tabelas
> interas/do dicionário (como export e import) tão quebradas OKDOC ?
> Sabe-se lá de onde vc tirou a informação, mas de repente foi de páginas
> como http://www.devmedia.com.br/alterando-padrao-de-caracter-
> no-oracle-xe/9591 , que mostram a mudança no XE ** 10g **, onde elea era
> possível e autorizada, no XE 11g não mais
>   Até ** pode ser ** que recriando o dicionário de dados com os scripts
> apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar
> isso por sua Conta e Risco...
>
>  ===>> Lamento dizer também que vc fez isso à TOA ao saber que
> WE8ISO8859P1 era o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um
> subset completo do AL32UTF8 padrão do XE , ** dificilmente ** daria qquer
> problema se estivesse com NLS_LANG setado corretamente
>
> Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já
> apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com
> BYTES como limitador de strings, e no banco XE com characterset multibyte
> cada caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela
> sendo criada como :
>
> CREATE TABLE nomedatabela (C1 number,
>C2 varchar2(30),
>C3 ..
>
> No exemplo acima, no banco-origem com characterset single-byte
> WE8ISO8859P1 a tabela seria criada com a coluna C2 podendo receber até 30
> bytes, que correspondem a 30 caracteres (pois em single-byte cada caracter
> ocupa um bytes), *** MAS *** com as configs padrão no XE a mesma tabela
> seria criada com a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30
> CARACTERES (em UTF cada caracter pode ocupar MAIS de um byte)
>
> Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de
> extrair os CREATEs das tabelas para confirmar isso), mas meu feeling é que
> é esse o seu problema
>
>  A solução portanto seria (num database XE ** recriado **, não vale o
> trabalho de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR
> que o NLS_LANG está corretamente setado, extrair os DDLs dos creates para
> confirmar a issue (que estará confirada TANTO se vc não ver nada na
> definição do tipo de limite da string como eu mostrei QUANTO se vc ver algo
> tipo C2 varchar2(30 BYTE)), E uma vez conbfirmada vc TERÁ que alterar os
> DDLs para que passem a informar o limite em CARACTERES e não em BYTES,
> veja  http://stackoverflow.com/questions/30707293/import-dmp-
> file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database para um
> exemplo
>
>  []s
>
>Chiappa
>
> 
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Ângelo,


Pois eh .. vi ate uma resposta tua a alguns dias
 "

https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH


AL16UTF16

Unicode 4.0 UTF-16 Universal character set

AL32UTF8

Unicode 4.0 UTF-8 Universal character set

UTF8

Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
"

Vou ver se rola essa dica do UTF8 .. mas acho q o jeito é alterar na mão
antes de importar os dados:(

Vlww


Em 12 de abril de 2017 14:55, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Mario,
>
>
> Dá uma olhada nisso aqui =>   http://stackoverflow.com/
> questions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe
>
> e depois nisso, a documentação oficial =>  https://docs.oracle.com/cd/
> B19306_01/server.102/b14225/ch2charset.htm
>
>
> Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
> isso, mesmo que altere o banco vai chiar... eu acho
> mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um
> samba..
>
>
>
>
>
> 2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br] :
>
>>
>>
>> Pessoal
>>
>> Boa tarde
>>
>> Voltando com o topico, a empresa me enviou o characterset é o
>> WE8ISO8859P1.
>>
>> Dai alterei usando "Alter database character set INTERNAL_USE
>> WE8ISO8859P1;" (nunca havia feito, achei na internet)
>> Rodando os SQL's
>> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
>> SELECT value FROM nls_database_parameters WHERE parameter =
>> 'NLS_CHARACTERSET'
>>
>> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>>
>> ORA 39006 Erro interno
>> ORA 39213 metadados não disponível
>>
>> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com
>> o SYS e da o mesmo erro.
>>
>>
>> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>>
>>>
>>> Acredito que talvez seja no 12c apenas - mas independente disso, já que
>>> vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
>>> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
>>> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
>>> constar qual  o characterset origem usado na exportação E a ** minha **
>>> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
>>> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
>>> ???
>>>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>>>
>>> []s
>>>
>>>   Chiappa
>>>
>>
>>
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Ops, desconsidere o link de exemplo final, 
http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set
 
http://serverfault.com/questions/317151/how-do-i-make-imp-use-right-charachter-set
 é o link mais apropriado, que contém um script que muda as colunas string 
definidas como BYTE limited para CHAR limited

[]s

  Chiappa
 

---Em oracle_br@yahoogrupos.com.br,  escreveu:

 Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior vc 
já tinha dito que teu banco 11g E tinha dito que é Express Edition (não 
diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o tamanho" é 
ESSa a dedução), e está Completamente Documentado que o Oracle XE ** não ** é 
oficialmente compatível com qualquer characterset - veja em 
http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a info :

"Table 4 Supported Universal Character Sets
Name Description

AL16UTF16


Unicode 4.0 UTF-16 Universal character set

AL32UTF8


Unicode 4.0 UTF-8 Universal character set

UTF8


Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant

"

Então pra mim ao mandar um comando "Alter database character" para um 
characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário de 
dados, sim sim ?? Não é à toa que coisas que dependem de tabelas interas/do 
dicionário (como export e import) tão quebradas OKDOC ? Sabe-se lá de onde 
vc tirou a informação, mas de repente foi de páginas como 
http://www.devmedia.com.br/alterando-padrao-de-caracter-no-oracle-xe/9591 , que 
mostram a mudança no XE ** 10g **, onde elea era possível e autorizada, no XE 
11g não mais
  Até ** pode ser ** que recriando o dicionário de dados com os scripts 
apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar isso 
por sua Conta e Risco...
  
 ===>> Lamento dizer também que vc fez isso à TOA ao saber que WE8ISO8859P1 era 
o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um subset completo do 
AL32UTF8 padrão do XE , ** dificilmente ** daria qquer problema se estivesse 
com NLS_LANG setado corretamente 

Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já 
apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com BYTES 
como limitador de strings, e no banco XE com characterset multibyte cada 
caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela sendo criada 
como :

CREATE TABLE nomedatabela (C1 number,
   C2 varchar2(30),
   C3 ..
   
No exemplo acima, no banco-origem com characterset single-byte WE8ISO8859P1 a 
tabela seria criada com a coluna C2 podendo receber até 30 bytes, que 
correspondem a 30 caracteres (pois em single-byte cada caracter ocupa um 
bytes), *** MAS *** com as configs padrão no XE a mesma tabela seria criada com 
a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30 CARACTERES (em UTF 
cada caracter pode ocupar MAIS de um byte)

Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de extrair 
os CREATEs das tabelas para confirmar isso), mas meu feeling é que é esse o seu 
problema 

 A solução portanto seria (num database XE ** recriado **, não vale o trabalho 
de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR que o NLS_LANG 
está corretamente setado, extrair os DDLs dos creates para confirmar a issue 
(que estará confirada TANTO se vc não ver nada na definição do tipo de limite 
da string como eu mostrei QUANTO se vc ver algo tipo C2 varchar2(30 BYTE)), E 
uma vez conbfirmada vc TERÁ que alterar os DDLs para que passem a informar o 
limite em CARACTERES e não em BYTES, veja  
http://stackoverflow.com/questions/30707293/import-dmp-file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database
 para um exemplo
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Colega, lamento informar mas CREIO que fizeste besteira : em msg anterior vc já 
tinha dito que teu banco 11g E tinha dito que é Express Edition (não 
diretamente, mas ao perguntar se "ORACLE XE tem algum limite sobre o tamanho" é 
ESSa a dedução), e está Completamente Documentado que o Oracle XE ** não ** é 
oficialmente compatível com qualquer characterset - veja em 
http://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#XEINW144 a info :

"Table 4 Supported Universal Character Sets
Name Description

AL16UTF16


Unicode 4.0 UTF-16 Universal character set

AL32UTF8


Unicode 4.0 UTF-8 Universal character set

UTF8


Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant

"

Então pra mim ao mandar um comando "Alter database character" para um 
characterset NÂO SUPORTADO, vc imho simplesmente CORROMPEU teu dicionário de 
dados, sim sim ?? Não é à toa que coisas que dependem de tabelas interas/do 
dicionário (como export e import) tão quebradas OKDOC ? Sabe-se lá de onde 
vc tirou a informação, mas de repente foi de páginas como 
http://www.devmedia.com.br/alterando-padrao-de-caracter-no-oracle-xe/9591 , que 
mostram a mudança no XE ** 10g **, onde elea era possível e autorizada, no XE 
11g não mais
  Até ** pode ser ** que recriando o dicionário de dados com os scripts 
apropriados (como CATALOG e CATPROC) mas Ninguém o Garante, vc vai tentar isso 
por sua Conta e Risco...
  
 ===>> Lamento dizer também que vc fez isso à TOA ao saber que WE8ISO8859P1 era 
o characterset de origem, pois WE8ISO8859P1 é ** SIM ** um subset completo do 
AL32UTF8 padrão do XE , ** dificilmente ** daria qquer problema se estivesse 
com NLS_LANG setado corretamente 

Assim sendo, pra mim o seu "problema" aí é o MESMO que eu (E outros) já 
apontamos anteriormente, ie, no banco-origem as tabelas estão criadas com BYTES 
como limitador de strings, e no banco XE com characterset multibyte cada 
caracter pode ocupar mas de um byte... Tipo, se vc tem uma tabela sendo criada 
como :

CREATE TABLE nomedatabela (C1 number,
   C2 varchar2(30),
   C3 ..
   
No exemplo acima, no banco-origem com characterset single-byte WE8ISO8859P1 a 
tabela seria criada com a coluna C2 podendo receber até 30 bytes, que 
correspondem a 30 caracteres (pois em single-byte cada caracter ocupa um 
bytes), *** MAS *** com as configs padrão no XE a mesma tabela seria criada com 
a coluna C2 podendo ter 30 ** BYTES ** no máximo, e não 30 CARACTERES (em UTF 
cada caracter pode ocupar MAIS de um byte)

Vc NÂO O DIZ portanto suponho que NÂO TENHA FEITO o que eu pedi (ie, de extrair 
os CREATEs das tabelas para confirmar isso), mas meu feeling é que é esse o seu 
problema 

 A solução portanto seria (num database XE ** recriado **, não vale o trabalho 
de tentar SALVAR esse XE que vc corrompeu, eu acho) vc CONFIRMAR que o NLS_LANG 
está corretamente setado, extrair os DDLs dos creates para confirmar a issue 
(que estará confirada TANTO se vc não ver nada na definição do tipo de limite 
da string como eu mostrei QUANTO se vc ver algo tipo C2 varchar2(30 BYTE)), E 
uma vez conbfirmada vc TERÁ que alterar os DDLs para que passem a informar o 
limite em CARACTERES e não em BYTES, veja  
http://stackoverflow.com/questions/30707293/import-dmp-file-created-in-oracle-11g-we8iso8859p1-to-oracle-11g-xe-database
 para um exemplo
 
 []s
 
   Chiappa

Re: [oracle_br] impdp

[angelo angelolis...@gmail.com [oracle_br]]

Mario,


Dá uma olhada nisso aqui =>
http://stackoverflow.com/questions/23779159/change-nls-character-set-parameters-on-oracle-11g-xe

e depois nisso, a documentação oficial =>
https://docs.oracle.com/cd/B19306_01/server.102/b14225/ch2charset.htm


Tenho a impressão que por limitacoes do XE, vc nao vai conseguir fazer
isso, mesmo que altere o banco vai chiar... eu acho
mas se o encoding WE8ISO8859P1  for um subset do UTF8, talvez dê um samba..





2017-04-12 12:37 GMT-03:00 Mario Rodrigues marioirodrig...@gmail.com
[oracle_br] :

>
>
> Pessoal
>
> Boa tarde
>
> Voltando com o topico, a empresa me enviou o characterset é o WE8ISO8859P1.
>
> Dai alterei usando "Alter database character set INTERNAL_USE
> WE8ISO8859P1;" (nunca havia feito, achei na internet)
> Rodando os SQL's
> SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
> SELECT value FROM nls_database_parameters WHERE parameter =
> 'NLS_CHARACTERSET'
>
> Dai blz, quando tento realizar o IMPORT aparecem 2 erros:
>
> ORA 39006 Erro interno
> ORA 39213 metadados não disponível
>
> Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com o
> SYS e da o mesmo erro.
>
>
> Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Acredito que talvez seja no 12c apenas - mas independente disso, já que
>> vc não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a
>> usar a sugestão (que FUNCIONA, sim) do outro colega de usar o comando
>> STRINGS no dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve
>> constar qual  o characterset origem usado na exportação E a ** minha **
>> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
>> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
>> ???
>>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>>
>> []s
>>
>>   Chiappa
>>
>
> 
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Pessoal

Boa tarde

Voltando com o topico, a empresa me enviou o characterset é o WE8ISO8859P1.

Dai alterei usando "Alter database character set INTERNAL_USE WE8ISO8859P1;"
(nunca havia feito, achei na internet)
Rodando os SQL's
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET';
SELECT value FROM nls_database_parameters WHERE parameter =
'NLS_CHARACTERSET'

Dai blz, quando tento realizar o IMPORT aparecem 2 erros:

ORA 39006 Erro interno
ORA 39213 metadados não disponível

Alguem já passou por isso?? Faltou fazer algo?? Já tentei ate import com o
SYS e da o mesmo erro.


Em 5 de abril de 2017 18:04, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Acredito que talvez seja no 12c apenas - mas independente disso, já que vc
> não conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a usar a
> sugestão (que FUNCIONA, sim) do outro colega de usar o comando STRINGS no
> dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve constar
> qual  o characterset origem usado na exportação E a ** minha **
> Sugestão de vc extrair o DDL só da tabela  pra ver se a coluna
> originalmente foi definida com tamanho em CARACTERES ou em BYTES, vc fez
> ???
>  Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Acredito que talvez seja no 12c apenas - mas independente disso, já que vc não 
conseguiu obter o characterset de origem pelo impdp, vc CHEGOU a usar a 
sugestão (que FUNCIONA, sim) do outro colega de usar o comando STRINGS no 
dumpfile que a empresa mandou ?? Logo nas primeiras linhas deve constar qual  o 
characterset origem usado na exportação E a ** minha ** Sugestão de vc 
extrair o DDL só da tabela  pra ver se a coluna originalmente foi definida com 
tamanho em CARACTERES ou em BYTES, vc fez ??? 
 Essas coisas ABSOLUTAMENTE NÃO DEPENDEM da tal outra Empresa

[]s

  Chiappa

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Pode ser - vou experimentar num 12c assim que puder...

[]s

  Chiappa

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Isabele,

Obrigado pela ajuda, eu fiz isso tb (alterar a coluna com problema) e deu
certo, mas não posso deixar assim rsrsrs .. é aquele famoso paliativo
rsrsrsrs
Ainda no aguardo do retorno da empresa ..

Chiappa .. a questão da linha do export done .. será que é só no 12c? no
11g num rola???



Em 4 de abril de 2017 15:40, Isabele de Araujo Barros isabe...@gmail.com
[oracle_br]  escreveu:

>
>
> Mario,
>
> Já aconteceu esse problema comigo. No Oracle XE o encoding padrão é o
> utf-8.
> No UTF-8 tem caracteres que podem ocupar mais de 1 byte, por isso ocorre o
> problema.
>
> http://stackoverflow.com/questions/81448/difference-between-
> byte-and-char-in-column-datatypes
>
> http://dba.stackexchange.com/questions/2736/oracle-import-
> problem-caused-by-different-character-sets
>
> O que eu fiz foi identificar as colunas com problema, criei as tabelas sem
> dados, aumentei o tamanho dos campos e importei os dados.
>
> Acho que também mudando de byte para char também resolve, mas não testei.
>
> Att,
> Isabele
>
>
> Em 4 de abril de 2017 15:23, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Mario, tenta importar de novo com o impdp ( vai dar erro )
>>
>> mas coloca pra gerar log em txtlogfile=erro.txt  e olha o arquivo de
>> erro gerado
>> O encoding utilizado vai aparecer dentro do log, logo no inicio quando o
>> arquivo dmp começar a ser lido.
>>
>> E ai vc pode ajustar a sua sessão pra importar com o encoding original.
>>
>>
>>
>>
>> On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> wrote:
>>
>>>
>>>
>>> Mario,
>>>
>>>O melhor é ver qual o characterset da base que gerou o export, e
>>> criar uma base usando o mesmo characterset.
>>>
>>>Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix),
>>> deve aparecer o characterset em que ele foi gerado, que provavelmente é o
>>> characterset da base de origem.
>>>
>>>Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve
>>> estar usando uma base UTF8 (Unicode).
>>>
>>> Atc,
>>> Luis Freitas
>>>
>>>
>>> On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues
>>> marioirodrig...@gmail.com [oracle_br]" 
>>> wrote:
>>>
>>>
>>>
>>> Pois é ... já solicitei as informações a empresa q fez o export .. é que
>>> tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
>>> pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
>>> deles ...
>>>
>>> Obrigado
>>>
>>>
>>>
>>> Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
>>> [oracle_br]  escreveu:
>>>
>>>
>>> Ta com cara de encoding  mesmo.
>>>
>>> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
>>> oracle_br@yahoogrupos.com.br> escreveu:
>>>
>>>
>>> Será que não está com o encoding errado não ?
>>>
>>> Tem que ser igual ao do banco de dados que foi exportado, do contrario
>>> vai chover erros pra todo lado porque o impdp tenta fazer uma conversão
>>> impossível de rolar.
>>>
>>>
>>>
>>> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
>>> [oracle_br]  :
>>>
>>>
>>> [image: alt]Oracle XE tem os mesmos limites de coluna que as outras
>>> versões. Acontece que o erro está mostrando que o carácter que ele está
>>> tentando importar tem tamanho 31 mesmo, maior que o da coluna, por isso o
>>> erro. Verifique essa linha em questão se é assim mesmo, faça uma consulta
>>> na base que exportou.
>>>
>>>
>>>
>>>
>>> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
>>> [oracle_br]  escreveu:
>>>
>>>
>>> Pessoal,
>>>
>>> Bom Dia
>>>
>>> Estou realizando o import de uma base, dai aestou tendo a seguinte msg
>>> de erro:
>>>
>>> value too large for column DESCRICAO(actual: 21, maximum: 20)
>>>
>>> Quem fez o DUMP me informou que a coluna em questão esta com 30 no
>>> tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
>>> o tamanho???
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> [image: photo]
>>> *Tércio Costa, *
>>> *Oracle Certified SQL Expert*
>>> Analista de Sistemas, Unimed João Pessoa
>>> m:+55 83 9 9915 9168 | w:https://oraclepress.wordpr ess.com/
>>>  |
>>> 
>>> 
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> César Carvalho
>>> Especialista em Banco de Dados
>>> MCP|MCSA|VPS|VTSP
>>> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
>>> *Skype:*  cesar.dba
>>>
>>>
>>>
>>>
>>>
>>
> 
>

Re: [oracle_br] impdp

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Chiappa,
   Meu 11g r2 aqui também não mostra informação de charset no impdp.
   Talvez só tenha isso na 12c?
;;;Import: Release 11.2.0.4.0 - Production on Thu Mar 30 15:21:43 2017
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights 
reserved.;;;Connected to: Oracle Database 11g Enterprise Edition Release 
11.2.0.4.0 - 64bitProductionWith the Partitioning, OLAP, Data Mining and Real 
Application Testing optionsMaster table "SYSTEM"."SYS_IMPORT_SCHEMA_01" 
successfully loaded/unloadedStarting "SYSTEM"."SYS_IMPORT_SCHEMA_01":  
system/ directory=DATA_PUMP_2 dumpfile=.dmp logfile=impdp_xxx.log 
parallel=8 schemas=XXXProcessing object type SCHEMA_EXPORT/USER...
Atc,Luis Freitas 

On Tuesday, April 4, 2017 6:45 PM, "Isabele de Araujo Barros 
isabe...@gmail.com [oracle_br]"  wrote:
 

     Mario,
Já aconteceu esse problema comigo. No Oracle XE o encoding padrão é o utf-8.No 
UTF-8 tem caracteres que podem ocupar mais de 1 byte, por isso ocorre o 
problema.
http://stackoverflow.com/ questions/81448/difference- between-byte-and-char-in- 
column-datatypes

http://dba.stackexchange.com/questions/2736/oracle-import-problem-caused-by-different-character-sets

O que eu fiz foi identificar as colunas com problema, criei as tabelas sem 
dados, aumentei o tamanho dos campos e importei os dados.
Acho que também mudando de byte para char também resolve, mas não testei.
Att,Isabele

Em 4 de abril de 2017 15:23, angelo angelolis...@gmail.com [oracle_br] 
 escreveu:

     Mario, tenta importar de novo com o impdp ( vai dar erro ) 

mas coloca pra gerar log em txt    logfile=erro.txt  e olha o arquivo de erro 
geradoO encoding utilizado vai aparecer dentro do log, logo no inicio quando o 
arquivo dmp começar a ser lido.   

E ai vc pode ajustar a sua sessão pra importar com o encoding original.




On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] 
 wrote:

     Mario,
   O melhor é ver qual o characterset da base que gerou o export, e criar uma 
base usando o mesmo characterset.
   Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix), deve 
aparecer o characterset em que ele foi gerado, que provavelmente é o 
characterset da base de origem.
   Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar 
usando uma base UTF8 (Unicode).
Atc,Luis Freitas 

On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues 
marioirodrig...@gmail.com [oracle_br]"  wrote:
 

     Pois é ... já solicitei as informações a empresa q fez o export .. é que 
tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou 
pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender 
deles ...
Obrigado



Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com [oracle_br] 
 escreveu:

     Ta com cara de encoding  mesmo.

Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] 
 escreveu:

     Será que não está com o encoding errado não ?

Tem que ser igual ao do banco de dados que foi exportado, do contrario vai 
chover erros pra todo lado porque o impdp tenta fazer uma conversão impossível 
de rolar.



2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com [oracle_br] 
 :

     Oracle XE tem os mesmos limites de coluna que as outras versões. Acontece 
que o erro está mostrando que o carácter que ele está tentando importar tem 
tamanho 31 mesmo, maior que o da coluna, por isso o erro. Verifique essa linha 
em questão se é assim mesmo, faça uma consulta na base que exportou.




Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com 
[oracle_br]  escreveu:

     Pessoal,
Bom Dia
Estou realizando o import de uma base, dai aestou tendo a seguinte msg de erro:
value too large for column DESCRICAO(actual: 21, maximum: 20)

Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho ... 
alguem sabe me informar se no ORACLE XE tem algum limite sobre o tamanho???


   



-- 

 
||   Tércio Costa, Oracle Certified SQL Expert
 Analista de Sistemas, Unimed João Pessoa  m:+55 83 9 9915 9168 | 
w:https://oraclepress.wordpr ess.com/ |     |


   

   



-- 

César CarvalhoEspecialista em Banco de DadosMCP|MCSA|VPS|VTSPE-mail: 
cesar@hotmail.com | cesar.sysdba@gmail.comSkype:  cesar.dba   

  

  

   

  #yiv0475605862 #yiv0475605862 -- #yiv0475605862ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv0475605862 
#yiv0475605862ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv0475605862 
#yiv0475605862ygrp-mkp #yiv0475605862hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv0475605862 #yiv0475605862ygrp-mkp #yiv0475605862ads 
{margin-bottom:10px;}#yiv0475605862 

Re: [oracle_br] impdp

[Isabele de Araujo Barros isabe...@gmail.com [oracle_br]]

Mario,


Já aconteceu esse problema comigo. No Oracle XE o encoding padrão é o utf-8.
No UTF-8 tem caracteres que podem ocupar mais de 1 byte, por isso ocorre o
problema.


http://stackoverflow.com/questions/81448/difference-
between-byte-and-char-in-column-datatypes


http://dba.stackexchange.com/questions/2736/oracle-import-problem-caused-by-different-character-sets


O que eu fiz foi identificar as colunas com problema, criei as tabelas sem
dados, aumentei o tamanho dos campos e importei os dados.


Acho que também mudando de byte para char também resolve, mas não testei.


Att,
Isabele




Em 4 de abril de 2017 15:23, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:


>
>
> Mario, tenta importar de novo com o impdp ( vai dar erro )
>
> mas coloca pra gerar log em txtlogfile=erro.txt  e olha o arquivo de
> erro gerado
> O encoding utilizado vai aparecer dentro do log, logo no inicio quando o
> arquivo dmp começar a ser lido.
>
> E ai vc pode ajustar a sua sessão pra importar com o encoding original.
>
>
>
>
> On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> wrote:
>
>>
>>
>> Mario,
>>
>>O melhor é ver qual o characterset da base que gerou o export, e criar
>> uma base usando o mesmo characterset.
>>
>>Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix),
>> deve aparecer o characterset em que ele foi gerado, que provavelmente é o
>> characterset da base de origem.
>>
>>Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar
>> usando uma base UTF8 (Unicode).
>>
>> Atc,
>> Luis Freitas
>>
>>
>> On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues
>> marioirodrig...@gmail.com [oracle_br]" 
>> wrote:
>>
>>
>>
>> Pois é ... já solicitei as informações a empresa q fez o export .. é que
>> tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
>> pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
>> deles ...
>>
>> Obrigado
>>
>>
>>
>> Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>> Ta com cara de encoding  mesmo.
>>
>> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>
>> Será que não está com o encoding errado não ?
>>
>> Tem que ser igual ao do banco de dados que foi exportado, do contrario
>> vai chover erros pra todo lado porque o impdp tenta fazer uma conversão
>> impossível de rolar.
>>
>>
>>
>> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
>> [oracle_br]  :
>>
>>
>> [image: alt]Oracle XE tem os mesmos limites de coluna que as outras
>> versões. Acontece que o erro está mostrando que o carácter que ele está
>> tentando importar tem tamanho 31 mesmo, maior que o da coluna, por isso o
>> erro. Verifique essa linha em questão se é assim mesmo, faça uma consulta
>> na base que exportou.
>>
>>
>>
>>
>> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>> Pessoal,
>>
>> Bom Dia
>>
>> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
>> erro:
>>
>> value too large for column DESCRICAO(actual: 21, maximum: 20)
>>
>> Quem fez o DUMP me informou que a coluna em questão esta com 30 no
>> tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
>> o tamanho???
>>
>>
>>
>>
>>
>>
>> --
>>
>> [image: photo]
>> *Tércio Costa, *
>> *Oracle Certified SQL Expert*
>> Analista de Sistemas, Unimed João Pessoa
>> m:+55 83 9 9915 9168 | w:https://oraclepress.wordpr ess.com/
>>  |
>> 
>> 
>>
>>
>>
>>
>>
>> --
>>
>> César Carvalho
>> Especialista em Banco de Dados
>> MCP|MCSA|VPS|VTSP
>> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
>> *Skype:*  cesar.dba
>>
>>
>>
>>
>>
>
>

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Bom para eu nao ficar parado a espera da empresa, no import dou uma pausa
ao terminar de criar a tabelas .. dai altero a coluna q estava dando erro
...e dou continue no import e funciona rsrsrsrs

Mas uma coisa me deixou "encafifado" no meu LOG nao aparece tão detalhado
... somente isso:
Import: Release 11.2.0.2.0 - Production on Ter Abr 4 17:55:30 2017

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights
reserved.
;;;
Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 -
Production
Tabela-mestre "SYS"."SYS_IMPORT_SCHEMA_01" carregada/descarregada com
sucesso
Iniciando "SYS"."SYS_IMPORT_SCHEMA_01":  sys/ AS SYSDBA
DUMPFILE=03042017.dmp schemas=private LOGFILE=importacao.log

Será que tenho q acrescentar algo???


de qualquer maneira obrigado a todos!


Em 4 de abril de 2017 17:29, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Luiz, talvez nem seja necessário o Mário olhar o cabeçalho do dumpfile,
> pois quando se faz um import via de regra ele ** JÁ MOSTRA ** o
> characterset usado na exportação, tipo :
>
>
> Import: Release 12.1.0.2.0 - Production
>
> Copyright (c) 1982, 2016, Oracle and/or its affiliates.  All rights
> reserved.
>
> Username: / as sysdba
>
> Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 -
> 64bit Production
> With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
> and Real Application Testing options
> Master table "SYS"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded
> import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
> export done in AL32UTF8 character set and AL16UTF16 NCHAR character set
> WARNING: possible data loss in character set conversions
> Starting "SYS"."SYS_IMPORT_SCHEMA_01":  / AS SYSDBA directory=temp
> dumpfile=user.dmp logfile=user.log schemas=demo
> Processing object type SCHEMA_EXPORT/USER
> Processing object type SCHEMA_EXPORT/DEFAULT_ROLE
> 
>
> Olha a linha do export done
>
> Mário, além da questão de CHARACTERSET, outro ponto é se a tabela foi
> criada com a opção de limitar as colunas por TAMANHO EM BYTES ou por
> TAMANHO EM CARACTERES : principalmente sendo XE seu banco-destino, nas
> versões mais recentes o XE só está disponível com um characterset
> MULTIBYTE, ie, onde cada caracter pode ocupar mais de um byte...
> Experimenta fazer um import só das estruturas e veja se não pe esse o
> caso...
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] impdp

[jlchia...@yahoo.com.br [oracle_br]]

Luiz, talvez nem seja necessário o Mário olhar o cabeçalho do dumpfile, pois 
quando se faz um import via de regra ele ** JÁ MOSTRA ** o characterset usado 
na exportação, tipo :


Import: Release 12.1.0.2.0 - Production

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

Username: / as sysdba

Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit 
Production
With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics
and Real Application Testing options
Master table "SYS"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded
import done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
export done in AL32UTF8 character set and AL16UTF16 NCHAR character set
WARNING: possible data loss in character set conversions
Starting "SYS"."SYS_IMPORT_SCHEMA_01":  / AS SYSDBA directory=temp 
dumpfile=user.dmp logfile=user.log schemas=demo
Processing object type SCHEMA_EXPORT/USER
Processing object type SCHEMA_EXPORT/DEFAULT_ROLE


Olha a linha do export done

Mário, além da questão de CHARACTERSET, outro ponto é se a tabela foi criada 
com a opção de limitar as colunas por TAMANHO EM BYTES ou por TAMANHO EM 
CARACTERES : principalmente sendo XE seu banco-destino, nas versões mais 
recentes o XE só está disponível com um characterset MULTIBYTE, ie, onde cada 
caracter pode ocupar mais de um byte... Experimenta fazer um import só das 
estruturas e veja se não pe esse o caso...

[]s

  Chiappa

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Angelo

Boa Tarde

Eita .. vou esperar o retorno deles..

OBS - Eu ja uso o log.. mas nele nao fala nada


Em 4 de abril de 2017 15:30, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Ih cara
>
> Tem um detalhe, que lembrei agora...
>
> O Oracle XE só suporta estes encodings abaixo... Mesmo que tente corrigir,
> acho que vai continuar a dar ruim  :(
>
> https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH
>
>
> AL16UTF16
>
> Unicode 4.0 UTF-16 Universal character set
>
> AL32UTF8
>
> Unicode 4.0 UTF-8 Universal character set
>
> UTF8
>
> Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant
>
>
>
>
> On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> wrote:
>
>>
>>
>> Mario,
>>
>>O melhor é ver qual o characterset da base que gerou o export, e criar
>> uma base usando o mesmo characterset.
>>
>>Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix),
>> deve aparecer o characterset em que ele foi gerado, que provavelmente é o
>> characterset da base de origem.
>>
>>Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar
>> usando uma base UTF8 (Unicode).
>>
>> Atc,
>> Luis Freitas
>>
>>
>> On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues
>> marioirodrig...@gmail.com [oracle_br]" 
>> wrote:
>>
>>
>>
>> Pois é ... já solicitei as informações a empresa q fez o export .. é que
>> tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
>> pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
>> deles ...
>>
>> Obrigado
>>
>>
>>
>> Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>> Ta com cara de encoding  mesmo.
>>
>> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
>> oracle_br@yahoogrupos.com.br> escreveu:
>>
>>
>> Será que não está com o encoding errado não ?
>>
>> Tem que ser igual ao do banco de dados que foi exportado, do contrario
>> vai chover erros pra todo lado porque o impdp tenta fazer uma conversão
>> impossível de rolar.
>>
>>
>>
>> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
>> [oracle_br]  :
>>
>>
>> [image: alt]Oracle XE tem os mesmos limites de coluna que as outras
>> versões. Acontece que o erro está mostrando que o carácter que ele está
>> tentando importar tem tamanho 31 mesmo, maior que o da coluna, por isso o
>> erro. Verifique essa linha em questão se é assim mesmo, faça uma consulta
>> na base que exportou.
>>
>>
>>
>>
>> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>> Pessoal,
>>
>> Bom Dia
>>
>> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
>> erro:
>>
>> value too large for column DESCRICAO(actual: 21, maximum: 20)
>>
>> Quem fez o DUMP me informou que a coluna em questão esta com 30 no
>> tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
>> o tamanho???
>>
>>
>>
>>
>>
>>
>> --
>>
>> [image: photo]
>> *Tércio Costa, *
>> *Oracle Certified SQL Expert*
>> Analista de Sistemas, Unimed João Pessoa
>> m:+55 83 9 9915 9168 | w:https://oraclepress.wordpr ess.com/
>>  |
>> 
>> 
>>
>>
>>
>>
>>
>> --
>>
>> César Carvalho
>> Especialista em Banco de Dados
>> MCP|MCSA|VPS|VTSP
>> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
>> *Skype:*  cesar.dba
>>
>>
>>
>>
>>
> 
>

Re: [oracle_br] impdp

[angelo angelolis...@gmail.com [oracle_br]]

Ih cara

Tem um detalhe, que lembrei agora...

O Oracle XE só suporta estes encodings abaixo... Mesmo que tente corrigir,
acho que vai continuar a dar ruim  :(

https://docs.oracle.com/cd/E17781_01/install.112/e18803/toc.htm#BABGBFJH


AL16UTF16

Unicode 4.0 UTF-16 Universal character set

AL32UTF8

Unicode 4.0 UTF-8 Universal character set

UTF8

Unicode 3.0 UTF-8 Universal character set, CESU-8 compliant




On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] <
oracle_br@yahoogrupos.com.br> wrote:

>
>
> Mario,
>
>O melhor é ver qual o characterset da base que gerou o export, e criar
> uma base usando o mesmo characterset.
>
>Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix),
> deve aparecer o characterset em que ele foi gerado, que provavelmente é o
> characterset da base de origem.
>
>Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar
> usando uma base UTF8 (Unicode).
>
> Atc,
> Luis Freitas
>
>
> On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues
> marioirodrig...@gmail.com [oracle_br]" 
> wrote:
>
>
>
> Pois é ... já solicitei as informações a empresa q fez o export .. é que
> tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
> pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
> deles ...
>
> Obrigado
>
>
>
> Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
> [oracle_br]  escreveu:
>
>
> Ta com cara de encoding  mesmo.
>
> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Será que não está com o encoding errado não ?
>
> Tem que ser igual ao do banco de dados que foi exportado, do contrario vai
> chover erros pra todo lado porque o impdp tenta fazer uma conversão
> impossível de rolar.
>
>
>
> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
> [oracle_br]  :
>
>
> [image: alt]Oracle XE tem os mesmos limites de coluna que as outras
> versões. Acontece que o erro está mostrando que o carácter que ele está
> tentando importar tem tamanho 31 mesmo, maior que o da coluna, por isso o
> erro. Verifique essa linha em questão se é assim mesmo, faça uma consulta
> na base que exportou.
>
>
>
>
> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br]  escreveu:
>
>
> Pessoal,
>
> Bom Dia
>
> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
> erro:
>
> value too large for column DESCRICAO(actual: 21, maximum: 20)
>
> Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho
> ... alguem sabe me informar se no ORACLE XE tem algum limite sobre o
> tamanho???
>
>
>
>
>
>
> --
>
> [image: photo]
> *Tércio Costa, *
> *Oracle Certified SQL Expert*
> Analista de Sistemas, Unimed João Pessoa
> m:+55 83 9 9915 9168 | w:https://oraclepress.wordpr ess.com/
>  |
> 
> 
>
>
>
>
>
> --
>
> César Carvalho
> Especialista em Banco de Dados
> MCP|MCSA|VPS|VTSP
> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
> *Skype:*  cesar.dba
>
>
>
>
> 
>

Re: [oracle_br] impdp

[angelo angelolis...@gmail.com [oracle_br]]

Mario, tenta importar de novo com o impdp ( vai dar erro )

mas coloca pra gerar log em txtlogfile=erro.txt  e olha o arquivo de
erro gerado
O encoding utilizado vai aparecer dentro do log, logo no inicio quando o
arquivo dmp começar a ser lido.

E ai vc pode ajustar a sua sessão pra importar com o encoding original.




On 4 April 2017 at 15:10, Luis Freitas lfreita...@yahoo.com [oracle_br] <
oracle_br@yahoogrupos.com.br> wrote:

>
>
> Mario,
>
>O melhor é ver qual o characterset da base que gerou o export, e criar
> uma base usando o mesmo characterset.
>
>Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix),
> deve aparecer o characterset em que ele foi gerado, que provavelmente é o
> characterset da base de origem.
>
>Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar
> usando uma base UTF8 (Unicode).
>
> Atc,
> Luis Freitas
>
>
> On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues
> marioirodrig...@gmail.com [oracle_br]" 
> wrote:
>
>
>
> Pois é ... já solicitei as informações a empresa q fez o export .. é que
> tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
> pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
> deles ...
>
> Obrigado
>
>
>
> Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
> [oracle_br]  escreveu:
>
>
> Ta com cara de encoding  mesmo.
>
> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Será que não está com o encoding errado não ?
>
> Tem que ser igual ao do banco de dados que foi exportado, do contrario vai
> chover erros pra todo lado porque o impdp tenta fazer uma conversão
> impossível de rolar.
>
>
>
> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
> [oracle_br]  :
>
>
> [image: alt]Oracle XE tem os mesmos limites de coluna que as outras
> versões. Acontece que o erro está mostrando que o carácter que ele está
> tentando importar tem tamanho 31 mesmo, maior que o da coluna, por isso o
> erro. Verifique essa linha em questão se é assim mesmo, faça uma consulta
> na base que exportou.
>
>
>
>
> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br]  escreveu:
>
>
> Pessoal,
>
> Bom Dia
>
> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
> erro:
>
> value too large for column DESCRICAO(actual: 21, maximum: 20)
>
> Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho
> ... alguem sabe me informar se no ORACLE XE tem algum limite sobre o
> tamanho???
>
>
>
>
>
>
> --
>
> [image: photo]
> *Tércio Costa, *
> *Oracle Certified SQL Expert*
> Analista de Sistemas, Unimed João Pessoa
> m:+55 83 9 9915 9168 | w:https://oraclepress.wordpr ess.com/
>  |
> 
> 
>
>
>
>
>
> --
>
> César Carvalho
> Especialista em Banco de Dados
> MCP|MCSA|VPS|VTSP
> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
> *Skype:*  cesar.dba
>
>
>
>
> 
>

Re: [oracle_br] impdp

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

Mario,
   O melhor é ver qual o characterset da base que gerou o export, e criar uma 
base usando o mesmo characterset.
   Pode olhar o arquivo com "strings .dmp | head" (Em linux/unix), deve 
aparecer o characterset em que ele foi gerado, que provavelmente é o 
characterset da base de origem.
   Se eu fosse chutar, o arquivo deve ser WE8ISO8859P1 e  você deve estar 
usando uma base UTF8 (Unicode).
Atc,Luis Freitas 

On Tuesday, April 4, 2017 2:01 PM, "Mario Rodrigues 
marioirodrig...@gmail.com [oracle_br]"  wrote:
 

     Pois é ... já solicitei as informações a empresa q fez o export .. é que 
tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou 
pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender 
deles ...
Obrigado



Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com [oracle_br] 
 escreveu:

     Ta com cara de encoding  mesmo.

Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] 
 escreveu:

     Será que não está com o encoding errado não ?

Tem que ser igual ao do banco de dados que foi exportado, do contrario vai 
chover erros pra todo lado porque o impdp tenta fazer uma conversão impossível 
de rolar.



2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com [oracle_br] 
 :

     Oracle XE tem os mesmos limites de coluna que as outras versões. Acontece 
que o erro está mostrando que o carácter que ele está tentando importar tem 
tamanho 31 mesmo, maior que o da coluna, por isso o erro. Verifique essa linha 
em questão se é assim mesmo, faça uma consulta na base que exportou.




Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com 
[oracle_br]  escreveu:

     Pessoal,
Bom Dia
Estou realizando o import de uma base, dai aestou tendo a seguinte msg de erro:
value too large for column DESCRICAO(actual: 21, maximum: 20)

Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho ... 
alguem sabe me informar se no ORACLE XE tem algum limite sobre o tamanho???


   



-- 

 
||   Tércio Costa, Oracle Certified SQL Expert
 Analista de Sistemas, Unimed João Pessoa  m:+55 83 9 9915 9168 | 
w:https://oraclepress.wordpr ess.com/ |     |


   

   



-- 

César CarvalhoEspecialista em Banco de DadosMCP|MCSA|VPS|VTSPE-mail: 
cesar@hotmail.com | cesar.sysdba@gmail.comSkype:  cesar.dba   

  #yiv2982689928 #yiv2982689928 -- #yiv2982689928ygrp-mkp {border:1px solid 
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2982689928 
#yiv2982689928ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2982689928 
#yiv2982689928ygrp-mkp #yiv2982689928hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv2982689928 #yiv2982689928ygrp-mkp #yiv2982689928ads 
{margin-bottom:10px;}#yiv2982689928 #yiv2982689928ygrp-mkp .yiv2982689928ad 
{padding:0 0;}#yiv2982689928 #yiv2982689928ygrp-mkp .yiv2982689928ad p 
{margin:0;}#yiv2982689928 #yiv2982689928ygrp-mkp .yiv2982689928ad a 
{color:#ff;text-decoration:none;}#yiv2982689928 #yiv2982689928ygrp-sponsor 
#yiv2982689928ygrp-lc {font-family:Arial;}#yiv2982689928 
#yiv2982689928ygrp-sponsor #yiv2982689928ygrp-lc #yiv2982689928hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2982689928 
#yiv2982689928ygrp-sponsor #yiv2982689928ygrp-lc .yiv2982689928ad 
{margin-bottom:10px;padding:0 0;}#yiv2982689928 #yiv2982689928actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2982689928 
#yiv2982689928activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2982689928
 #yiv2982689928activity span {font-weight:700;}#yiv2982689928 
#yiv2982689928activity span:first-child 
{text-transform:uppercase;}#yiv2982689928 #yiv2982689928activity span a 
{color:#5085b6;text-decoration:none;}#yiv2982689928 #yiv2982689928activity span 
span {color:#ff7900;}#yiv2982689928 #yiv2982689928activity span 
.yiv2982689928underline {text-decoration:underline;}#yiv2982689928 
.yiv2982689928attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv2982689928 .yiv2982689928attach div a 
{text-decoration:none;}#yiv2982689928 .yiv2982689928attach img 
{border:none;padding-right:5px;}#yiv2982689928 .yiv2982689928attach label 
{display:block;margin-bottom:5px;}#yiv2982689928 .yiv2982689928attach label a 
{text-decoration:none;}#yiv2982689928 blockquote {margin:0 0 0 
4px;}#yiv2982689928 .yiv2982689928bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2982689928 
.yiv2982689928bold a {text-decoration:none;}#yiv2982689928 dd.yiv2982689928last 
p a {font-family:Verdana;font-weight:700;}#yiv2982689928 dd.yiv2982689928last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2982689928 
dd.yiv2982689928last p span.yiv2982689928yshortcuts 

Re: [oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Pois é ... já solicitei as informações a empresa q fez o export .. é que
tenho certeza que vai demorar uns 2 dias para eu obter a resposta .. estou
pesquisando (com as dicas de vcs) uma forma de tentar resolver sem depender
deles ...

Obrigado



Em 4 de abril de 2017 13:44, César Carvalho cesar.sys...@gmail.com
[oracle_br]  escreveu:

>
>
> Ta com cara de encoding  mesmo.
>
> Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Será que não está com o encoding errado não ?
>>
>> Tem que ser igual ao do banco de dados que foi exportado, do contrario
>> vai chover erros pra todo lado porque o impdp tenta fazer uma conversão
>> impossível de rolar.
>>
>>
>>
>> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
>> [oracle_br] :
>>
>>>
>>>
>>> Oracle XE tem os mesmos limites de coluna que as outras versões.
>>> Acontece que o erro está mostrando que o carácter que ele está tentando
>>> importar tem tamanho 31 mesmo, maior que o da coluna, por isso o erro.
>>> Verifique essa linha em questão se é assim mesmo, faça uma consulta na base
>>> que exportou.
>>>
>>>
>>>
>>>
>>> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
>>> [oracle_br]  escreveu:
>>>


 Pessoal,

 Bom Dia

 Estou realizando o import de uma base, dai aestou tendo a seguinte msg
 de erro:

 value too large for column DESCRICAO(actual: 21, maximum: 20)

 Quem fez o DUMP me informou que a coluna em questão esta com 30 no
 tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
 o tamanho???




>>>
>>>
>>> --
>>>
>>> [image: photo]
>>> *Tércio Costa, *
>>> *Oracle Certified SQL Expert*
>>> Analista de Sistemas, Unimed João Pessoa
>>> m:+55 83 9 9915 9168 <+55+83+9915+9168> | w:https://oraclepress.wordpr
>>> ess.com/  |
>>> 
>>> 
>>>
>>>
>>
>
>
> --
>
>
> César Carvalho
>
> Especialista em Banco de Dados
>
> MCP|MCSA|VPS|VTSP
>
> *E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com
>
> *Skype:*  cesar.dba
>
> 
>

Re: [oracle_br] impdp

[César Carvalho cesar.sys...@gmail.com [oracle_br]]

Ta com cara de encoding  mesmo.

Em 4 de abril de 2017 13:35, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Será que não está com o encoding errado não ?
>
> Tem que ser igual ao do banco de dados que foi exportado, do contrario vai
> chover erros pra todo lado porque o impdp tenta fazer uma conversão
> impossível de rolar.
>
>
>
> 2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
> [oracle_br] :
>
>>
>>
>> Oracle XE tem os mesmos limites de coluna que as outras versões. Acontece
>> que o erro está mostrando que o carácter que ele está tentando importar tem
>> tamanho 31 mesmo, maior que o da coluna, por isso o erro. Verifique essa
>> linha em questão se é assim mesmo, faça uma consulta na base que exportou.
>>
>>
>>
>>
>> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
>> [oracle_br]  escreveu:
>>
>>>
>>>
>>> Pessoal,
>>>
>>> Bom Dia
>>>
>>> Estou realizando o import de uma base, dai aestou tendo a seguinte msg
>>> de erro:
>>>
>>> value too large for column DESCRICAO(actual: 21, maximum: 20)
>>>
>>> Quem fez o DUMP me informou que a coluna em questão esta com 30 no
>>> tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
>>> o tamanho???
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> [image: photo]
>> *Tércio Costa, *
>> *Oracle Certified SQL Expert*
>> Analista de Sistemas, Unimed João Pessoa
>> m:+55 83 9 9915 9168 <+55+83+9915+9168> | w:https://oraclepress.wordpr
>> ess.com/  |
>> 
>> 
>>
>>
> 
>



-- 


César Carvalho

Especialista em Banco de Dados

MCP|MCSA|VPS|VTSP

*E-mail:* cesar@hotmail.com | cesar.sys...@gmail.com

*Skype:*  cesar.dba

Re: [oracle_br] impdp

[angelo angelolis...@gmail.com [oracle_br]]

Será que não está com o encoding errado não ?

Tem que ser igual ao do banco de dados que foi exportado, do contrario vai
chover erros pra todo lado porque o impdp tenta fazer uma conversão
impossível de rolar.



2017-04-04 11:31 GMT-03:00 Tércio Costa terciosilvaco...@gmail.com
[oracle_br] :

>
>
> Oracle XE tem os mesmos limites de coluna que as outras versões. Acontece
> que o erro está mostrando que o carácter que ele está tentando importar tem
> tamanho 31 mesmo, maior que o da coluna, por isso o erro. Verifique essa
> linha em questão se é assim mesmo, faça uma consulta na base que exportou.
>
>
>
>
> Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
> [oracle_br]  escreveu:
>
>>
>>
>> Pessoal,
>>
>> Bom Dia
>>
>> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
>> erro:
>>
>> value too large for column DESCRICAO(actual: 21, maximum: 20)
>>
>> Quem fez o DUMP me informou que a coluna em questão esta com 30 no
>> tamanho ... alguem sabe me informar se no ORACLE XE tem algum limite sobre
>> o tamanho???
>>
>>
>>
>>
>
>
> --
>
> [image: photo]
> *Tércio Costa, *
> *Oracle Certified SQL Expert*
> Analista de Sistemas, Unimed João Pessoa
> m:+55 83 9 9915 9168 <+55+83+9915+9168> | w:https://oraclepress.
> wordpress.com/  |
> 
> 
>
> 
>

Re: [oracle_br] impdp

[Tércio Costa terciosilvaco...@gmail.com [oracle_br]]

Oracle XE tem os mesmos limites de coluna que as outras versões. Acontece
que o erro está mostrando que o carácter que ele está tentando importar tem
tamanho 31 mesmo, maior que o da coluna, por isso o erro. Verifique essa
linha em questão se é assim mesmo, faça uma consulta na base que exportou.




Em 4 de abril de 2017 11:16, Mario Rodrigues marioirodrig...@gmail.com
[oracle_br]  escreveu:

>
>
> Pessoal,
>
> Bom Dia
>
> Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
> erro:
>
> value too large for column DESCRICAO(actual: 21, maximum: 20)
>
> Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho
> ... alguem sabe me informar se no ORACLE XE tem algum limite sobre o
> tamanho???
>
>
>
> 
>



-- 

[image: photo]
*Tércio Costa, *
*Oracle Certified SQL Expert*
Analista de Sistemas, Unimed João Pessoa
m:+55 83 9 9915 9168 <+55+83+9915+9168> | w:
https://oraclepress.wordpress.com/  |

RE: [oracle_br] impdp

['Schiavini' et...@schiavini.inf.br [oracle_br]]

Mário

 

O charset e o tipo de varchar2 (byte ou char) são os mesmos no banco de origem 
e no de destino?

 

Étore 

 

From: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] 
Sent: terça-feira, 4 de abril de 2017 11:17
To: oracle_br@yahoogrupos.com.br
Subject: [oracle_br] impdp

 

  

Pessoal, 

 

Bom Dia

 

Estou realizando o import de uma base, dai aestou tendo a seguinte msg de erro:

 

value too large for column DESCRICAO(actual: 21, maximum: 20)

 

Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho ... 
alguem sabe me informar se no ORACLE XE tem algum limite sobre o tamanho???

 

 

 





[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] impdp

[Mario Rodrigues marioirodrig...@gmail.com [oracle_br]]

Pessoal,

Bom Dia

Estou realizando o import de uma base, dai aestou tendo a seguinte msg de
erro:

value too large for column DESCRICAO(actual: 21, maximum: 20)

Quem fez o DUMP me informou que a coluna em questão esta com 30 no tamanho
... alguem sabe me informar se no ORACLE XE tem algum limite sobre o
tamanho???

[oracle_br] IMPDP ORA-01843: not a valid month

[Raphael Franco]

Senhores,

Oracle 10.2.0.4 / Linux Red hat 5.4 64Bits.

Estou atualizando uma base de testes a partir de um expdp do banco de produção.

O problema é que algumas tabelas estão apresentando erro na importação:

CREATE TABLE USERTESTE.IN_DOC_TYPE (DOC_TYPE_ID VARCHAR2(23) NOT NULL 
ENABLE, DOC_TYPE_NAME VARCHAR2(40), DOC_TYPE_DESC VARCHAR2(256), 
IS_ACTIVE NUMBER(12,0) NOT NULL ENABLE, CREATION_USR_ID VARCHAR2(23), 
CREATION_TIME TIMESTAMP (6) DEFAULT '1970-01-01 00:00:00', MOD_USR_ID 
VARCHAR2(23), MOD_TIME TIMESTAMP (6) DEFAULT '1970-01-01 00:00:00', 
CLASS_ID VARCHAR2(23), SIG_VERIFY_INTERVAL 
ORA-39083: Object type TABLE failed to create with error:
ORA-01843: not a valid month

Ou seja, o problema está no MOD_TIME TIMESTAMP (6) DEFAULT '1970-01-01 
00:00:00'.

No banco onde estou importando (data pump) ja setei a variavel de ambiente 
NLS_DATE_FORMAT='-MM-DD HH24:MI:SS' e o erro persiste!
Também ja setei a variavel NLS_LANG igual ao do banco de produção quando foi 
realizado o expdp.

Agora estou tentando alterar o NLS_DATE_FORMAT do banco, porém não entra em 
vigor, segue:
Coloquei via PFILE e reiniciei o BD.

SYS@sml show parameter nls_date_format

NAME     TYPE VALUE
 --- --
nls_date_format      string -MM-DD HH24:MI:SS

SYS@sml select sysdate from dual;

SYSDATE
-
04-DEC-13

SYS@sml select * from NLS_DATABASE_PARAMETERS where 
parameter='NLS_DATE_FORMAT';

PARAMETER       VALUE
-- 
NLS_DATE_FORMAT        DD-MON-RR


Alguem ja passou por esse problema ORA-01843: not a valid month no IMPDP no 
banco 10.2 ?? Isso pode ser um bug ??
E como eu troco o NLS_DATE_FORMAT ??

att.
Phael

Re: [oracle_br] IMPDP ORA-01843: not a valid month

[Andre Santos]

Raphael

Para TIMESTAMP há outros parâmetros NLS: NLS_TIMESTAMP_FORMAT e
NLS_TIMESTAMP_TZ_FORMAT.

Exemplos:
--
alter session set nls_date_format = 'dd/mm/ hh24:mi:ss';
alter session set nls_timestamp_format= 'dd/mm/ hh24:mi:ssxff';
alter session set nls_timestamp_tz_format = 'dd/mm/ hh24:mi:ssxff tzr';
--

De qualquer maneira, conversão implícita é uma coisa a ser evitada.
Seria melhor alterar a forma de definição do DEFAULT dessas colunas.

[ ]

André




Em 4 de dezembro de 2013 15:00, Raphael Franco pha...@yahoo.com.brescreveu:



 Senhores,

 Oracle 10.2.0.4 / Linux Red hat 5.4 64Bits.

 Estou atualizando uma base de testes a partir de um expdp do banco de
 produção.

 O problema é que algumas tabelas estão apresentando erro na importação:

 CREATE TABLE USERTESTE.IN_DOC_TYPE (DOC_TYPE_ID VARCHAR2(23) NOT
 NULL ENABLE, DOC_TYPE_NAME VARCHAR2(40), DOC_TYPE_DESC VARCHAR2(256),
 IS_ACTIVE NUMBER(12,0) NOT NULL ENABLE, CREATION_USR_ID VARCHAR2(23),
 CREATION_TIME TIMESTAMP (6) DEFAULT '1970-01-01 00:00:00', MOD_USR_ID
 VARCHAR2(23), MOD_TIME TIMESTAMP (6) DEFAULT '1970-01-01 00:00:00',
 CLASS_ID VARCHAR2(23), SIG_VERIFY_INTERVAL
 ORA-39083: Object type TABLE failed to create with error:
 ORA-01843: not a valid month

 Ou seja, o problema está no MOD_TIME TIMESTAMP (6) DEFAULT '1970-01-01
 00:00:00'.

 No banco onde estou importando (data pump) ja setei a variavel de ambiente
 NLS_DATE_FORMAT='-MM-DD HH24:MI:SS' e o erro persiste!
 Também ja setei a variavel NLS_LANG igual ao do banco de produção quando
 foi realizado o expdp.

 Agora estou tentando alterar o NLS_DATE_FORMAT do banco, porém não entra
 em vigor, segue:
 Coloquei via PFILE e reiniciei o BD.

 SYS@sml show parameter nls_date_format

 NAME TYPE VALUE
  ---
 --
 nls_date_format  string -MM-DD HH24:MI:SS

 SYS@sml select sysdate from dual;

 SYSDATE
 -
 04-DEC-13

 SYS@sml select * from NLS_DATABASE_PARAMETERS where
 parameter='NLS_DATE_FORMAT';

 PARAMETER   VALUE
 -- 
 NLS_DATE_FORMATDD-MON-RR


 Alguem ja passou por esse problema ORA-01843: not a valid month no
 IMPDP no banco 10.2 ?? Isso pode ser um bug ??
 E como eu troco o NLS_DATE_FORMAT ??

 att.
 Phael




  

RES: RES: RES: [oracle_br] Impdp Não termina!

[Milton Bastos Henriquis Junior]

Bom dia Welvis!

O import ainda não terminou... rs...
Acredito que esteja executando sim, pois veja as ultimas linhas do alert.log:


Tue Oct 11 05:25:01 2011
Thread 1 advanced to log sequence 14779 (LGWR switch)
  Current log# 1 seq# 14779 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
Tue Oct 11 07:18:26 2011
Thread 1 advanced to log sequence 14780 (LGWR switch)
  Current log# 2 seq# 14780 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO02.LOG
Tue Oct 11 09:12:41 2011
Thread 1 advanced to log sequence 14781 (LGWR switch)
  Current log# 3 seq# 14781 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
Tue Oct 11 10:55:49 2011
Thread 1 advanced to log sequence 14782 (LGWR switch)
  Current log# 1 seq# 14782 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG

Uma dúvida: carga de dados via impdp gera LOG, correto?
Pois essa instancia está “bloqueada” – ninguém está criando conexões nela, 
bloqueei o usuário para poder fazer este import.
Portanto eu suponho que estes switchs de log estejam sendo causados pelo 
próprio impdp.


Att,
--
Milton Bastos
http://miltonbastos.com

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011 11:30
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Impdp Não termina!



Então, já fiz este tipo de coisa.. é meio demorado mesmo.. mas roda..

Veja se ha alguma coisa no metalink sobre isso, tipo bug ou algo do genero...

Uma outra coisa que sempre esquecemos.. é...

Se esta estrutura ja existe.. temos..

Constraints, Triggers, Indices... estas coiasas...

Gere um trace desta sessão.. vai vamos saber o que está acontecendo...

Abraço Amigo..

att,

Welvis Douglas


De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.br
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 11:19
Assunto: RES: RES: [oracle_br] Impdp Não termina!


Log do impdp:

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit 
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Tabela-mestre SYSTEM.SYS_IMPORT_TABLE_01 carregada/descarregada com sucesso
Iniciando SYSTEM.SYS_IMPORT_TABLE_01: system/@orcecdes 
dumpfile=DIR_EXP:movitsaida%U.dmp logfile=DIR_EXP:imp_movitsaida.log 
tables=gemcote.mov_itsaida content=data_only
Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA

--
Milton Bastos
http://miltonbastos.com

De: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
[mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br] Em 
nome de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011 11:14
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Impdp Não termina!

O que acusa no Log de importação?

att


De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.brmailto:milton.bastos%40meta.com.br
Para: 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 10:41
Assunto: RES: [oracle_br] Impdp Não termina!

Beleza Welvis!

Abri o alert.log e o último erro foi este:

Thread 1 advanced to log sequence 12264 (LGWR switch)
Current log# 3 seq# 12264 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
Wed Oct 05 07:50:36 2011
ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
Duration=44155 sec, SCN: 0x0003.e9f64f76):
Wed Oct 05 07:50:36 2011
SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), NVL(dump_position, 
:2), dump_length, dump_allocation, grantor, object_row, object_schema, 
object_long_name, processing_status, processing_state, base_object_type, 
base_object_schema, base_object_name, property, size_estimate, in_progress FROM 
SYSTEM.IMPFULL WHERE process_order between :3 AND :4 AND processing_state 
 :5 AND duplicate = 0 ORDER BY process_order
Wed Oct 05 07:57:50 2011
Thread 1 advanced to log sequence 12265 (LGWR switch)
Current log# 1 seq# 12265 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
Wed Oct 05 07:58:42 2011

Repare que foi no dia 5 de outubro... hoje já é dia 10.
De lá pra cá, tudo que tem no alert são os switchs de log.

--
Milton Bastos
http://miltonbastos.com

De: 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 
[mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br]
 Em nome de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011

Re: RES: RES: RES: [oracle_br] Impdp Não termina!

[José Laurindo]

 que os dados tão no lugar, aí sim vc cria as constraints com 
NOVALIDATE (pois aí NÂo haverá table scans pra validar dados), e cria os 
índices ** com PARALLEL option, , em múltiplas sessões, E em sessões onde vc 
colocou SORT_AREA_SIZE bem alto, etc
 
 []s
 
   Chiappa

--- Em oracle_br@yahoogrupos.com.br, Milton Bastos Henriquis Junior 
milton.bastos@... escreveu

 Bom dia Welvis!
 
 O import ainda não terminou... rs...
 Acredito que esteja executando sim, pois veja as ultimas linhas do alert.log:
 
 
 Tue Oct 11 05:25:01 2011
 Thread 1 advanced to log sequence 14779 (LGWR switch)
   Current log# 1 seq# 14779 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
 Tue Oct 11 07:18:26 2011
 Thread 1 advanced to log sequence 14780 (LGWR switch)
   Current log# 2 seq# 14780 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO02.LOG
 Tue Oct 11 09:12:41 2011
 Thread 1 advanced to log sequence 14781 (LGWR switch)
   Current log# 3 seq# 14781 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
 Tue Oct 11 10:55:49 2011
 Thread 1 advanced to log sequence 14782 (LGWR switch)
   Current log# 1 seq# 14782 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
 
 Uma dúvida: carga de dados via impdp gera LOG, correto?
 Pois essa instancia está “bloqueada” †ninguém está criando conexões 
 nela, bloqueei o usuário para poder fazer este import.
 Portanto eu suponho que estes switchs de log estejam sendo causados pelo 
 próprio impdp.
 
 
 Att,
 --
 Milton Bastos
 http://miltonbastos.com
 
 De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 
 nome de Welvis Moretto
 Enviada em: segunda-feira, 10 de outubro de 2011 11:30
 Para: oracle_br@yahoogrupos.com.br
 Assunto: Re: RES: RES: [oracle_br] Impdp Não termina!
 
 
 
 Então, já fiz este tipo de coisa.. é meio demorado mesmo.. mas roda..
 
 Veja se ha alguma coisa no metalink sobre isso, tipo bug ou algo do genero...
 
 Uma outra coisa que sempre esquecemos.. é...
 
 Se esta estrutura ja existe.. temos..
 
 Constraints, Triggers, Indices... estas coiasas...
 
 Gere um trace desta sessão.. vai vamos saber o que está acontecendo...
 
 Abraço Amigo..
 
 att,
 
 Welvis Douglas
 
 
 De: Milton Bastos Henriquis Junior 
 milton.bastos@...mailto:milton.bastos%40meta.com.br
 Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
 oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 Enviadas: Segunda-feira, 10 de Outubro de 2011 11:19
 Assunto: RES: RES: [oracle_br] Impdp Não termina!
 
 
 Log do impdp:
 
 Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 
 64bit Production
 With the Partitioning, OLAP, Data Mining and Real Application Testing options
 Tabela-mestre SYSTEM.SYS_IMPORT_TABLE_01 carregada/descarregada com 
 sucesso
 Iniciando SYSTEM.SYS_IMPORT_TABLE_01: system/@orcecdes 
 dumpfile=DIR_EXP:movitsaida%U.dmp logfile=DIR_EXP:imp_movitsaida.log 
 tables=gemcote.mov_itsaida content=data_only
 Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA
 
 --
 Milton Bastos
 http://miltonbastos.com
 
 De: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
 [mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br] 
 Em nome de Welvis Moretto
 Enviada em: segunda-feira, 10 de outubro de 2011 11:14
 Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 Assunto: Re: RES: [oracle_br] Impdp Não termina!
 
 O que acusa no Log de importação?
 
 att
 
 
 De: Milton Bastos Henriquis Junior 
 milton.bastos@...mailto:milton.bastos%40meta.com.brmailto:milton.bastos%40meta.com.br
 Para: 
 oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
  
 oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 Enviadas: Segunda-feira, 10 de Outubro de 2011 10:41
 Assunto: RES: [oracle_br] Impdp Não termina!
 
 Beleza Welvis!
 
 Abri o alert.log e o último erro foi este:
 
 Thread 1 advanced to log sequence 12264 (LGWR switch)
 Current log# 3 seq# 12264 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
 Wed Oct 05 07:50:36 2011
 ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
 Duration=44155 sec, SCN: 0x0003.e9f64f76):
 Wed Oct 05 07:50:36 2011
 SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), 
 NVL(dump_position, :2), dump_length, dump_allocation, grantor, object_row, 
 object_schema, object_long_name, processing_status, processing_state, 
 base_object_type, base_object_schema, base_object_name, property, 
 size_estimate, in_progress FROM SYSTEM.IMPFULL WHERE process_order 
 between :3 AND :4 AND processing_state  :5 AND duplicate = 0 ORDER BY 
 process_order
 Wed Oct 05 07:57:50 2011
 Thread 1 advanced to log sequence 12265 (LGWR switch)
 Current log# 1 seq# 12265 mem# 0: 
 D:\ORACLE\PRODUCT\10.2.0\ORADATA

Re: RES: RES: RES: [oracle_br] Impdp Não termina!

[José Laurindo]

 não exportar (e não 
 importar depois) nem índices nem triggers nem estatísticas ... Dependendo do 
 seu hardware, se ele suporta múltiplas sessões, pode ser interessante vc 
 gerar vários arquivos (provavelmente usando cláusulas de WHERE diferentes pra 
 cada um deles, que separem os dados diferentemente) , pra depois vc ter 
 várias sessões simultâneas de importação
 - na hora da importação , vc vai importar só os dados , os índices e 
 constraints e estatísticas vc recria depois, em modo parallel, etc
 
- é Crítico pra uma importação eficiente  : além dos parâmetros comuns de 
 parallel e relacionados, que ao que vejo vc já está usando, vc usar 
 DIRECT-MODE : pra isso, além da tabela estar como NOLOGGING, além do database 
 não estar como force - logging, há algumas exigências mais, 
 http://sshailesh.wordpress.com/2009/05/03/does-oracle-datapump-uses-direct-path-load/
  fala de algumas

  - depois que os dados tão no lugar, aí sim vc cria as constraints com 
 NOVALIDATE (pois aí NÂo haverá table scans pra validar dados), e cria os 
 índices ** com PARALLEL option, , em múltiplas sessões, E em sessões onde vc 
 colocou SORT_AREA_SIZE bem alto, etc
  
  []s
  
Chiappa
 
 --- Em oracle_br@yahoogrupos.com.br, Milton Bastos Henriquis Junior 
 milton.bastos@ escreveu
 
  Bom dia Welvis!
  
  O import ainda não terminou... rs...
  Acredito que esteja executando sim, pois veja as ultimas linhas do 
  alert.log:
  
  
  Tue Oct 11 05:25:01 2011
  Thread 1 advanced to log sequence 14779 (LGWR switch)
Current log# 1 seq# 14779 mem# 0: 
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
  Tue Oct 11 07:18:26 2011
  Thread 1 advanced to log sequence 14780 (LGWR switch)
Current log# 2 seq# 14780 mem# 0: 
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO02.LOG
  Tue Oct 11 09:12:41 2011
  Thread 1 advanced to log sequence 14781 (LGWR switch)
Current log# 3 seq# 14781 mem# 0: 
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
  Tue Oct 11 10:55:49 2011
  Thread 1 advanced to log sequence 14782 (LGWR switch)
Current log# 1 seq# 14782 mem# 0: 
  D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
  
  Uma dúvida: carga de dados via impdp gera LOG, correto?
  Pois essa instancia está “bloqueada” †ninguém está criando conexões 
  nela, bloqueei o usuário para poder fazer este import.
  Portanto eu suponho que estes switchs de log estejam sendo causados pelo 
  próprio impdp.
  
  
  Att,
  --
  Milton Bastos
  http://miltonbastos.com
  
  De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 
  nome de Welvis Moretto
  Enviada em: segunda-feira, 10 de outubro de 2011 11:30
  Para: oracle_br@yahoogrupos.com.br
  Assunto: Re: RES: RES: [oracle_br] Impdp Não termina!
  
  
  
  Então, já fiz este tipo de coisa.. é meio demorado mesmo.. mas roda..
  
  Veja se ha alguma coisa no metalink sobre isso, tipo bug ou algo do 
  genero...
  
  Uma outra coisa que sempre esquecemos.. é...
  
  Se esta estrutura ja existe.. temos..
  
  Constraints, Triggers, Indices... estas coiasas...
  
  Gere um trace desta sessão.. vai vamos saber o que está acontecendo...
  
  Abraço Amigo..
  
  att,
  
  Welvis Douglas
  
  
  De: Milton Bastos Henriquis Junior 
  milton.bastos@mailto:milton.bastos%40meta.com.br
  Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
  oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
  Enviadas: Segunda-feira, 10 de Outubro de 2011 11:19
  Assunto: RES: RES: [oracle_br] Impdp Não termina!
  
  
  Log do impdp:
  
  Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 
  64bit Production
  With the Partitioning, OLAP, Data Mining and Real Application Testing 
  options
  Tabela-mestre SYSTEM.SYS_IMPORT_TABLE_01 carregada/descarregada com 
  sucesso
  Iniciando SYSTEM.SYS_IMPORT_TABLE_01: system/@orcecdes 
  dumpfile=DIR_EXP:movitsaida%U.dmp logfile=DIR_EXP:imp_movitsaida.log 
  tables=gemcote.mov_itsaida content=data_only
  Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA
  
  --
  Milton Bastos
  http://miltonbastos.com
  
  De: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
  [mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br]
   Em nome de Welvis Moretto
  Enviada em: segunda-feira, 10 de outubro de 2011 11:14
  Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
  Assunto: Re: RES: [oracle_br] Impdp Não termina!
  
  O que acusa no Log de importação?
  
  att
  
  
  De: Milton Bastos Henriquis Junior 
  milton.bastos@mailto:milton.bastos%40meta.com.brmailto:milton.bastos%40meta.com.br
  Para: 
  oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
   
  oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
  Enviadas

Re: [oracle_br] Impdp Não termina!

[Welvis Moretto]

Eai Miltão... Blz?

Seguinte...

verifique o Log... , pode ter ter alguma área mal dimensionada..

Verifique o Log.. veja o que tem de mensagem.. 


abraço!




De: Milton Bastos Henriquis Junior milton.bas...@meta.com.br
Para: oracle_br@yahoogrupos.com.br oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 9:21
Assunto: [oracle_br] Impdp Não termina!


  
Bom dia amigos!

Deixei rodando um import via DataPump na quinta-feira e não terminou até agora!
Oracle 10gR2, Windows Server 2008.

Detalhe: na sexta-feira já aparecia o status abaixo:
Percent Done: 100
Mas não finaliza, está como EXECUTING até agora.

O import é de apenas UMA tabela, porém é uma tabela grandinha - quase 50GB.
O que faço? Cancelo e inicio novamente???
Há alguma maneira mais rápida?

Import status

Job: SYS_IMPORT_TABLE_01
Operation: IMPORT
Mode: TABLE
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: D:\dump\movitsaida%u.dmp
Dump File: D:\dump\movitsaida01.dmp
Dump File: D:\dump\movitsaida02.dmp
Dump File: D:\dump\movitsaida03.dmp
Dump File: D:\dump\movitsaida04.dmp
Dump File: D:\dump\movitsaida05.dmp
Dump File: D:\dump\movitsaida06.dmp
Dump File: D:\dump\movitsaida07.dmp
Dump File: D:\dump\movitsaida08.dmp
Dump File: D:\dump\movitsaida09.dmp
Dump File: D:\dump\movitsaida10.dmp
Dump File: D:\dump\movitsaida11.dmp
Dump File: D:\dump\movitsaida12.dmp
Dump File: D:\dump\movitsaida13.dmp
Dump File: D:\dump\movitsaida14.dmp
Dump File: D:\dump\movitsaida15.dmp
Dump File: D:\dump\movitsaida16.dmp

Worker 1 Status:
State: EXECUTING
Object Schema: GEMCOTE
Object Name: MOV_ITSAIDA
Object Type: TABLE_EXPORT/TABLE/TABLE_DATA
Completed Objects: 1
Completed Rows: 11,414,851
Completed Bytes: 48,585,454,616
Percent Done: 100
Worker Parallelism: 1

--
Milton Bastos
http://miltonbastos.com

This message has been scanned for malware by Websense. www.websense.com

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]

RES: [oracle_br] Impdp Não termina!

[Milton Bastos Henriquis Junior]

Beleza Welvis!

Abri o alert.log e o último erro foi este:

Thread 1 advanced to log sequence 12264 (LGWR switch)
  Current log# 3 seq# 12264 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
Wed Oct 05 07:50:36 2011
ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
Duration=44155 sec, SCN: 0x0003.e9f64f76):
Wed Oct 05 07:50:36 2011
SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), NVL(dump_position, 
:2), dump_length, dump_allocation, grantor, object_row, object_schema, 
object_long_name, processing_status, processing_state, base_object_type, 
base_object_schema, base_object_name, property, size_estimate, in_progress FROM 
SYSTEM.IMPFULL WHERE  process_order between :3 AND :4 AND processing_state 
 :5 AND duplicate = 0 ORDER BY process_order
Wed Oct 05 07:57:50 2011
Thread 1 advanced to log sequence 12265 (LGWR switch)
  Current log# 1 seq# 12265 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
Wed Oct 05 07:58:42 2011

Repare que foi no dia 5 de outubro... hoje já é dia 10.
De lá pra cá, tudo que tem no alert são os switchs de log.

--
Milton Bastos
http://miltonbastos.com

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011 10:29
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Impdp Não termina!



Eai Miltão... Blz?

Seguinte...

verifique o Log... , pode ter ter alguma área mal dimensionada..

Verifique o Log.. veja o que tem de mensagem..

abraço!


De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.br
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 9:21
Assunto: [oracle_br] Impdp Não termina!


Bom dia amigos!

Deixei rodando um import via DataPump na quinta-feira e não terminou até agora!
Oracle 10gR2, Windows Server 2008.

Detalhe: na sexta-feira já aparecia o status abaixo:
Percent Done: 100
Mas não finaliza, está como EXECUTING até agora.

O import é de apenas UMA tabela, porém é uma tabela grandinha - quase 50GB.
O que faço? Cancelo e inicio novamente???
Há alguma maneira mais rápida?

Import status

Job: SYS_IMPORT_TABLE_01
Operation: IMPORT
Mode: TABLE
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: D:\dump\movitsaida%u.dmp
Dump File: D:\dump\movitsaida01.dmp
Dump File: D:\dump\movitsaida02.dmp
Dump File: D:\dump\movitsaida03.dmp
Dump File: D:\dump\movitsaida04.dmp
Dump File: D:\dump\movitsaida05.dmp
Dump File: D:\dump\movitsaida06.dmp
Dump File: D:\dump\movitsaida07.dmp
Dump File: D:\dump\movitsaida08.dmp
Dump File: D:\dump\movitsaida09.dmp
Dump File: D:\dump\movitsaida10.dmp
Dump File: D:\dump\movitsaida11.dmp
Dump File: D:\dump\movitsaida12.dmp
Dump File: D:\dump\movitsaida13.dmp
Dump File: D:\dump\movitsaida14.dmp
Dump File: D:\dump\movitsaida15.dmp
Dump File: D:\dump\movitsaida16.dmp

Worker 1 Status:
State: EXECUTING
Object Schema: GEMCOTE
Object Name: MOV_ITSAIDA
Object Type: TABLE_EXPORT/TABLE/TABLE_DATA
Completed Objects: 1
Completed Rows: 11,414,851
Completed Bytes: 48,585,454,616
Percent Done: 100
Worker Parallelism: 1

--
Milton Bastos
http://miltonbastos.com

This message has been scanned for malware by Websense. www.websense.com

[As partes desta mensagem que não continham texto foram removidas]

[As partes desta mensagem que não continham texto foram removidas]



Clique 
aquihttps://www.mailcontrol.com/sr/0T19yDu7rnfTndxI!oX7Uj80y4Ou3KxpNZo8trhQKt4xHo+3szDSddyDjQ5oP6JGIEZflx!5bMqh35PDdlVduQ==
 para reportar este e-mail como SPAM.


[As partes desta mensagem que não continham texto foram removidas]

Re: RES: [oracle_br] Impdp Não termina!

[Welvis Moretto]

O que acusa no Log de importação?

att




De: Milton Bastos Henriquis Junior milton.bas...@meta.com.br
Para: oracle_br@yahoogrupos.com.br oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 10:41
Assunto: RES: [oracle_br] Impdp Não termina!


  
Beleza Welvis! 

Abri o alert.log e o último erro foi este: 

Thread 1 advanced to log sequence 12264 (LGWR switch) 
Current log# 3 seq# 12264 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG 
Wed Oct 05 07:50:36 2011 
ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
Duration=44155 sec, SCN: 0x0003.e9f64f76): 
Wed Oct 05 07:50:36 2011 
SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), NVL(dump_position, 
:2), dump_length, dump_allocation, grantor, object_row, object_schema, 
object_long_name, processing_status, processing_state, base_object_type, 
base_object_schema, base_object_name, property, size_estimate, in_progress FROM 
SYSTEM.IMPFULL WHERE  process_order between :3 AND :4 AND processing_state 
 :5 AND duplicate = 0 ORDER BY process_order 
Wed Oct 05 07:57:50 2011 
Thread 1 advanced to log sequence 12265 (LGWR switch) 
Current log# 1 seq# 12265 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG 
Wed Oct 05 07:58:42 2011 

Repare que foi no dia 5 de outubro... hoje já é dia 10. 
De lá pra cá, tudo que tem no alert são os switchs de log. 

-- 
Milton Bastos 
http://miltonbastos.com 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Welvis Moretto 
Enviada em: segunda-feira, 10 de outubro de 2011 10:29 
Para: oracle_br@yahoogrupos.com.br 
Assunto: Re: [oracle_br] Impdp Não termina! 



Eai Miltão... Blz? 

Seguinte... 

verifique o Log... , pode ter ter alguma área mal dimensionada.. 

Verifique o Log.. veja o que tem de mensagem.. 

abraço! 

 
De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.br 
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
Enviadas: Segunda-feira, 10 de Outubro de 2011 9:21 
Assunto: [oracle_br] Impdp Não termina! 


Bom dia amigos! 

Deixei rodando um import via DataPump na quinta-feira e não terminou até agora! 
Oracle 10gR2, Windows Server 2008. 

Detalhe: na sexta-feira já aparecia o status abaixo: 
Percent Done: 100 
Mas não finaliza, está como EXECUTING até agora. 

O import é de apenas UMA tabela, porém é uma tabela grandinha - quase 50GB. 
O que faço? Cancelo e inicio novamente??? 
Há alguma maneira mais rápida? 

Import status 

Job: SYS_IMPORT_TABLE_01 
Operation: IMPORT 
Mode: TABLE 
State: EXECUTING 
Bytes Processed: 0 
Current Parallelism: 1 
Job Error Count: 0 
Dump File: D:\dump\movitsaida%u.dmp 
Dump File: D:\dump\movitsaida01.dmp 
Dump File: D:\dump\movitsaida02.dmp 
Dump File: D:\dump\movitsaida03.dmp 
Dump File: D:\dump\movitsaida04.dmp 
Dump File: D:\dump\movitsaida05.dmp 
Dump File: D:\dump\movitsaida06.dmp 
Dump File: D:\dump\movitsaida07.dmp 
Dump File: D:\dump\movitsaida08.dmp 
Dump File: D:\dump\movitsaida09.dmp 
Dump File: D:\dump\movitsaida10.dmp 
Dump File: D:\dump\movitsaida11.dmp 
Dump File: D:\dump\movitsaida12.dmp 
Dump File: D:\dump\movitsaida13.dmp 
Dump File: D:\dump\movitsaida14.dmp 
Dump File: D:\dump\movitsaida15.dmp 
Dump File: D:\dump\movitsaida16.dmp 

Worker 1 Status: 
State: EXECUTING 
Object Schema: GEMCOTE 
Object Name: MOV_ITSAIDA 
Object Type: TABLE_EXPORT/TABLE/TABLE_DATA 
Completed Objects: 1 
Completed Rows: 11,414,851 
Completed Bytes: 48,585,454,616 
Percent Done: 100 
Worker Parallelism: 1 

-- 
Milton Bastos 
http://miltonbastos.com 

This message has been scanned for malware by Websense. www.websense.com 

[As partes desta mensagem que não continham texto foram removidas] 

[As partes desta mensagem que não continham texto foram removidas] 



Clique 
aquihttps://www.mailcontrol.com/sr/0T19yDu7rnfTndxI!oX7Uj80y4Ou3KxpNZo8trhQKt4xHo+3szDSddyDjQ5oP6JGIEZflx!5bMqh35PDdlVduQ==
 para reportar este e-mail como SPAM. 

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]

RES: RES: [oracle_br] Impdp Não termina!

[Milton Bastos Henriquis Junior]

Log do impdp:

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit 
Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Tabela-mestre SYSTEM.SYS_IMPORT_TABLE_01 carregada/descarregada com sucesso
Iniciando SYSTEM.SYS_IMPORT_TABLE_01:  system/@orcecdes 
dumpfile=DIR_EXP:movitsaida%U.dmp logfile=DIR_EXP:imp_movitsaida.log 
tables=gemcote.mov_itsaida content=data_only
Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA



--
Milton Bastos
http://miltonbastos.com

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011 11:14
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: [oracle_br] Impdp Não termina!



O que acusa no Log de importação?

att


De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.br
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 10:41
Assunto: RES: [oracle_br] Impdp Não termina!


Beleza Welvis!

Abri o alert.log e o último erro foi este:

Thread 1 advanced to log sequence 12264 (LGWR switch)
Current log# 3 seq# 12264 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG
Wed Oct 05 07:50:36 2011
ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
Duration=44155 sec, SCN: 0x0003.e9f64f76):
Wed Oct 05 07:50:36 2011
SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), NVL(dump_position, 
:2), dump_length, dump_allocation, grantor, object_row, object_schema, 
object_long_name, processing_status, processing_state, base_object_type, 
base_object_schema, base_object_name, property, size_estimate, in_progress FROM 
SYSTEM.IMPFULL WHERE process_order between :3 AND :4 AND processing_state 
 :5 AND duplicate = 0 ORDER BY process_order
Wed Oct 05 07:57:50 2011
Thread 1 advanced to log sequence 12265 (LGWR switch)
Current log# 1 seq# 12265 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG
Wed Oct 05 07:58:42 2011

Repare que foi no dia 5 de outubro... hoje já é dia 10.
De lá pra cá, tudo que tem no alert são os switchs de log.

--
Milton Bastos
http://miltonbastos.com

De: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
[mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br] Em 
nome de Welvis Moretto
Enviada em: segunda-feira, 10 de outubro de 2011 10:29
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Assunto: Re: [oracle_br] Impdp Não termina!

Eai Miltão... Blz?

Seguinte...

verifique o Log... , pode ter ter alguma área mal dimensionada..

Verifique o Log.. veja o que tem de mensagem..

abraço!


De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.brmailto:milton.bastos%40meta.com.br
Para: 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 9:21
Assunto: [oracle_br] Impdp Não termina!

Bom dia amigos!

Deixei rodando um import via DataPump na quinta-feira e não terminou até agora!
Oracle 10gR2, Windows Server 2008.

Detalhe: na sexta-feira já aparecia o status abaixo:
Percent Done: 100
Mas não finaliza, está como EXECUTING até agora.

O import é de apenas UMA tabela, porém é uma tabela grandinha - quase 50GB.
O que faço? Cancelo e inicio novamente???
Há alguma maneira mais rápida?

Import status

Job: SYS_IMPORT_TABLE_01
Operation: IMPORT
Mode: TABLE
State: EXECUTING
Bytes Processed: 0
Current Parallelism: 1
Job Error Count: 0
Dump File: D:\dump\movitsaida%u.dmp
Dump File: D:\dump\movitsaida01.dmp
Dump File: D:\dump\movitsaida02.dmp
Dump File: D:\dump\movitsaida03.dmp
Dump File: D:\dump\movitsaida04.dmp
Dump File: D:\dump\movitsaida05.dmp
Dump File: D:\dump\movitsaida06.dmp
Dump File: D:\dump\movitsaida07.dmp
Dump File: D:\dump\movitsaida08.dmp
Dump File: D:\dump\movitsaida09.dmp
Dump File: D:\dump\movitsaida10.dmp
Dump File: D:\dump\movitsaida11.dmp
Dump File: D:\dump\movitsaida12.dmp
Dump File: D:\dump\movitsaida13.dmp
Dump File: D:\dump\movitsaida14.dmp
Dump File: D:\dump\movitsaida15.dmp
Dump File: D:\dump\movitsaida16.dmp

Worker 1 Status:
State: EXECUTING
Object Schema: GEMCOTE
Object Name: MOV_ITSAIDA
Object Type: TABLE_EXPORT/TABLE/TABLE_DATA
Completed Objects: 1
Completed Rows: 11,414,851
Completed Bytes: 48,585,454,616
Percent Done: 100
Worker Parallelism: 1

--
Milton Bastos
http://miltonbastos.com

This message has been scanned for malware by Websense. www.websense.com

[As partes desta mensagem que não continham texto foram removidas]

[As partes desta mensagem que não continham texto foram removidas]

Clique 
aquihttps

Re: RES: RES: [oracle_br] Impdp Não termina!

[Welvis Moretto]

Então, já fiz este tipo de coisa.. é meio demorado mesmo.. mas roda.. 


Veja se ha alguma coisa no metalink sobre isso, tipo bug ou algo do genero...

Uma outra coisa que sempre esquecemos.. é...

Se esta estrutura ja existe.. temos..

Constraints, Triggers, Indices... estas coiasas...

Gere um trace desta sessão.. vai vamos saber o que está acontecendo...


Abraço Amigo..

att,

Welvis Douglas




De: Milton Bastos Henriquis Junior milton.bas...@meta.com.br
Para: oracle_br@yahoogrupos.com.br oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 10 de Outubro de 2011 11:19
Assunto: RES: RES: [oracle_br] Impdp Não termina!


  
Log do impdp: 

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit 
Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options 
Tabela-mestre SYSTEM.SYS_IMPORT_TABLE_01 carregada/descarregada com sucesso 
Iniciando SYSTEM.SYS_IMPORT_TABLE_01:  system/@orcecdes 
dumpfile=DIR_EXP:movitsaida%U.dmp logfile=DIR_EXP:imp_movitsaida.log 
tables=gemcote.mov_itsaida content=data_only 
Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA 



-- 
Milton Bastos 
http://miltonbastos.com 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Welvis Moretto 
Enviada em: segunda-feira, 10 de outubro de 2011 11:14 
Para: oracle_br@yahoogrupos.com.br 
Assunto: Re: RES: [oracle_br] Impdp Não termina! 



O que acusa no Log de importação? 

att 

 
De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.br 
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
Enviadas: Segunda-feira, 10 de Outubro de 2011 10:41 
Assunto: RES: [oracle_br] Impdp Não termina! 


Beleza Welvis! 

Abri o alert.log e o último erro foi este: 

Thread 1 advanced to log sequence 12264 (LGWR switch) 
Current log# 3 seq# 12264 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO03.LOG 
Wed Oct 05 07:50:36 2011 
ORA-01555 caused by SQL statement below (SQL ID: 6tr7wbt5rmryt, Query 
Duration=44155 sec, SCN: 0x0003.e9f64f76): 
Wed Oct 05 07:50:36 2011 
SELECT process_order, flags, xml_clob, NVL(dump_fileid, :1), NVL(dump_position, 
:2), dump_length, dump_allocation, grantor, object_row, object_schema, 
object_long_name, processing_status, processing_state, base_object_type, 
base_object_schema, base_object_name, property, size_estimate, in_progress FROM 
SYSTEM.IMPFULL WHERE process_order between :3 AND :4 AND processing_state 
 :5 AND duplicate = 0 ORDER BY process_order 
Wed Oct 05 07:57:50 2011 
Thread 1 advanced to log sequence 12265 (LGWR switch) 
Current log# 1 seq# 12265 mem# 0: 
D:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCECDES\REDO01.LOG 
Wed Oct 05 07:58:42 2011 

Repare que foi no dia 5 de outubro... hoje já é dia 10. 
De lá pra cá, tudo que tem no alert são os switchs de log. 

-- 
Milton Bastos 
http://miltonbastos.com 

De: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
[mailto:oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br] Em 
nome de Welvis Moretto 
Enviada em: segunda-feira, 10 de outubro de 2011 10:29 
Para: oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br 
Assunto: Re: [oracle_br] Impdp Não termina! 

Eai Miltão... Blz? 

Seguinte... 

verifique o Log... , pode ter ter alguma área mal dimensionada.. 

Verifique o Log.. veja o que tem de mensagem.. 

abraço! 

 
De: Milton Bastos Henriquis Junior 
milton.bas...@meta.com.brmailto:milton.bastos%40meta.com.brmailto:milton.bastos%40meta.com.br
 
Para: 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 
oracle_br@yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.brmailto:oracle_br%40yahoogrupos.com.br
 
Enviadas: Segunda-feira, 10 de Outubro de 2011 9:21 
Assunto: [oracle_br] Impdp Não termina! 

Bom dia amigos! 

Deixei rodando um import via DataPump na quinta-feira e não terminou até agora! 
Oracle 10gR2, Windows Server 2008. 

Detalhe: na sexta-feira já aparecia o status abaixo: 
Percent Done: 100 
Mas não finaliza, está como EXECUTING até agora. 

O import é de apenas UMA tabela, porém é uma tabela grandinha - quase 50GB. 
O que faço? Cancelo e inicio novamente??? 
Há alguma maneira mais rápida? 

Import status 

Job: SYS_IMPORT_TABLE_01 
Operation: IMPORT 
Mode: TABLE 
State: EXECUTING 
Bytes Processed: 0 
Current Parallelism: 1 
Job Error Count: 0 
Dump File: D:\dump\movitsaida%u.dmp 
Dump File: D:\dump\movitsaida01.dmp 
Dump File: D:\dump\movitsaida02.dmp 
Dump File: D:\dump\movitsaida03.dmp 
Dump File: D:\dump\movitsaida04.dmp 
Dump File: D:\dump\movitsaida05.dmp 
Dump File: D:\dump\movitsaida06.dmp 
Dump File: D:\dump\movitsaida07.dmp 
Dump File: D:\dump\movitsaida08.dmp 
Dump File: D:\dump\movitsaida09.dmp 
Dump File: D:\dump

[oracle_br] impdp

[welvis]

Olá pessoal tudo bem?

Estou com um Oracle 11G e gostaria de exportar um owner que está lá e
importar para uma máquina de Homologação 10G.

Para o imp/exp eu usava outro client, o client que exportava usava o mesmo
para importar...

Para o expdp preciso fazer a mesma coisa?

Att,

Welvis Douglas da Silva Moretto
OCA DBA 10g - OCE Sql
Fone:  (41) 9997-6297
E-mail:welvis_doug...@hotmail.com, welvis.m...@terceiros.stcruz.com.br

Re: [oracle_br] impdp

[Gerson Junior]

O imp/exp funciona da mesma forma sim.

Só alguns parametros que são um pouco diferentes, tipo: OWNER passa a ser
SCHEMA, entre outros.

Pra facilitar, faz: expdp help=y ou impdp help=y que vai te mostrar todos
os parametros.

Abraço.

Sucesso!



Gerson S. de Vasconcelos Júnior
OCA DBA - Oracle Certified Associate
Fone: (81) 9816-0236
Msn: gerson.vasconce...@gmail.com
Skype: gersonvjunior
http://www.diaadiaoracle.com.br/


Em 29 de março de 2011 14:48, wel...@stcruz.com.br escreveu:



 Olá pessoal tudo bem?

 Estou com um Oracle 11G e gostaria de exportar um owner que está lá e
 importar para uma máquina de Homologação 10G.

 Para o imp/exp eu usava outro client, o client que exportava usava o mesmo
 para importar...

 Para o expdp preciso fazer a mesma coisa?

 Att,

 Welvis Douglas da Silva Moretto
 OCA DBA 10g - OCE Sql
 Fone: (41) 9997-6297
 E-mail: welvis_doug...@hotmail.com, welvis.m...@terceiros.stcruz.com.br

  



[As partes desta mensagem que não continham texto foram removidas]





--
Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--
Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » 
Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
http://www.oraclebr.com.br/  

 Links do Yahoo! Grupos

* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

* Para sair deste grupo, envie um e-mail para:
oracle_br-unsubscr...@yahoogrupos.com.br

* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

[oracle_br] impdp mais rapido.

[Duilio Bruniera Junior]

Pessoal, alguem sabe como acelerar o processo de import do datapump
eu rodo assim :

impdp usuario/senha dumpfile=dump_000%U.dmp remap_schema=user_1:user_2
content=all transform=oid:n exclude=statistics directory=backup_dir
parallel=8 remap_tablespace=TABLESPACE_1:TABLESPACE_2 logfile=log_file.log;

gostaria de saber se alguem sabe se posso mexer incluir algum parametro que
acelere o import do datapump


Valeu


[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] IMPDP - ORA-12899

[Márcio Ricardo Alves da Silva]

Fiz um expdp do banco oracle 10g release 10.2.0.1 e um impdp no oracle XE

algumas tabelas deu erro de ORA-12899, como eu consigo resolver?

Att,
Márcio.











[As partes desta mensagem que não continham texto foram removidas]

[oracle_br] Impdp com network link

[rflribeiro]

Terei que fazer em breve uma migração de uns schemas do 8.1.7.3 p/ 10.2,
ambos em windows. Gostaria de saber se é possível fazer um impdp
diretamente do 8 p/ o 10 utilizando network_link via database link.
Estava pensando em criar os tablespaces, acertar o nls e importar os
users diretamente desta forma. Terei uma boa janela de trabalho e nenhum
problema em carregar a rede. Obrigado.

-- 

Reginaldo Ribeiro
Administrador de Bancos de Dados
Oracle Certified Associate 10g
_
DBcom IT Experts
skype: rflribeiro
msn: [EMAIL PROTECTED]
mobile: 551192344290
fone: 551162165375
e-mail: [EMAIL PROTECTED]
site: www.dbcom.com.br