Menu de navegação

[ThiagoParticipante]

Pessoal.. Bom dia!!

fiz um export de partiçoes de 4 tabelas, que são relacionadas entre si por FK’s, quando fiz o import em outra base, de mesma versão de ORACLE, a primeira vez começou a fazer o import sem problema como eu coloquei commit=n como parametro, a UNDO estourou.. tive que fazer novamente, dei um alter table trunca partition update indexes pra limpar se houve-se algo, e tentei importar novamente ai começou a dar esse erro de violação de PK..
Lembrando que antes de eu começar a fazer isso eu fiz um alter table disable constraint, nas Fks e PKs das 4 tabelas, e desabilitei as triggers tbm, as unicas coisas q nao desabilitei foram as check constraints..

continuo tomando o erro ORA-00001 toda vez q tento importar alguem tem alguma ideia?

eu uso parfile, segue o modelo:

tables=(LF_NF_SAIDA:CAPA_2012_06,
LF_NF_SAIDA_ITEM:ITM_2012_06,
LF_NF_SAIDA_IMPOSTO:IMP_2012_06,
LF_NF_SAIDA_OBSERVACOES:OBS_2012_06)
rows=y
file=exp_saida_201206.dmp,
log=imp_saida_201206.log,
statistics=none,
grants=n,
indexes=n,
constraints=n,
feedback=1000000,
buffer=10485760,
recordlength=65535,
ignore=y,
commit=y

Eu tenho uma ligeira impressao que mesmo eu truncando as partiçoes com update indexes, o Oracle esteja mesmo assim marcando o segmento é uma mera suposição, mas nao sei como poderia fazer para resolver será que um rebuild nos indexes e um move nas partiçoes q eu to querendo trabalhar ajudaria?

como teoricamente nao tem nenhum dado entre aspas.. deve ser rapido….

abração a todos!

[ThiagoParticipante]

Log de Erro do import:

Import: Release 11.2.0.3.0 – Production on Wed Aug 22 01:11:26 2012

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

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Tes

Export file created by EXPORT:V11.02.00 via direct path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P15 character set (possible charset conversion)
. importing LF’s objects into LF
. importing LF’s objects into LF
. . importing subpartition “LF_NF_SAIDA”:”CAPA_2012_05_OUTROS_37″
IMP-00019: row rejected due to ORACLE error 1
IMP-00003: ORACLE error 1 encountered
ORA-00001: unique constraint (LF.PK_NF_SAIDA) violated

Pessoal… Boa Noite….
Fiz o post.. com o intuito de compartilhar o problema com vocês, busquei na internet, vasculhei tudo, mas oque me levou a ver o problema e a ter a solução foi uma serie de análises em busca ao sucesso rsrsr

Bom vamos lá, meu import tinha 90GB

1 – no primeiro momento fiz o import na base com o seguinte parfile:

userid=lf/lf_1431
tables=(LF_NF_SAIDA:CAPA_2012_05_OUTROS_37)
rows=y
file=exp_saida_201205.dmp
log=imp_saida_201205.log
statistics=none
grants=n
constraints=n
indexes=n
ignore=y
feedback=1000000
buffer=10000000
recordlength=65535
commit=n

vejamos que eu tenho como parametro o commit=n, coloquei de proposito, sabendo que o commit=n carrega mais rapido, mas esqueci de verificar se existia espaço na tablespace UNDO
pra entrar o meu import, bom deixei de um dia pro outro, quando cheguei me deparei com o estouro da UNDO, beleza fazer oque colocar o parametro commit=y e colocar novamente o import,
simples sem mistério, como sempre precavido fiz um select count(*) na subpartition CAPA_2012_05_OUTROS_37 que obtive como retorno 0 registros !!!!!

Otimo beleza… agora só carregar!!!, rodei o import, e tomei o erro de violação de PK…. Pensei pô a subpartition está vazia, mas só pra dar aquela assegurada
rodei um “ALTER TABLE TABLE_NAME TRUNCATE SUBPARTITION SUBPARTITION_NAME. Pensei Opa.. beleza agora vai!!!!!!!
Doce e mera ilusão.. coloquei o import novamente e o mesmo erro, comecei a achar que o arquivo de Export estava com os arquivo duplicados, fui na tabela fiz um select para verificar se havia duplicidade
e pra minha surpresa o registro nao estava duplicado, ai começou o meu cabelo a coçar, minha cara mudou, já comecei a ficar puto com a porcaria de um exp/imp simples, velho, antigo…..
Fiz o post na espectativa que alguem tive-se uma ideia pois eu já tinha tentado bastante coisa.

Já estava sem forçar e com esse problema o dia todo fui dormir as 04:00 da manha e as 06:00 já estava de pé, vim decidido a resolver o problema,
Quebrando muito a cabeça, resolvi largar a M**** do import.
Criar um Db_link de um banco pra outro e fazer via Insert, tive alguns problemas na criação do DB_LINK pois no servidor tinha o mesmo SID que apontava pra 2 servidores diferentes
otimo e eu super feliz e calmo, pois nao fui eu quem o configurou, liguei pro pessoal e pedi um usuario com direitos pra fazer a modificação, nao quiseram me dar, ai forcei eles mesmos a fazerem a alteração.

Conssegui criar o Db_link, beleza como nao sou bobo meti um insert /+ APPEND */ as select /+ PARALLEL 24 */ meti na maquina e vamo q vamo acompanhar..

não é que o Insert deu erro, de violação de PK tambem.. Pronto aí eu comecei a tentar penssar em saidas, pensei po vou verificar esse dado, quando fui na base que estava tentando importar ele existia mesmo, pensei como ele existe se a subpartition dele está 0
a unica explicação é que esse dado que estou trazendo nao está caindo na subpartição certa!

Fui olhar o Max_value das subpartiçoes e partiçoes, até que me deparei com o seguinte quadro:

[color=#FF0000]Partition Name Max Value
CAPA_2012_07 TO_DATE(‘ 2012-09-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_06 TO_DATE(‘ 2012-08-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_05 TO_DATE(‘ 2012-07-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_04 TO_DATE(‘ 2012-06-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)[/color]
CAPA_2012_03 TO_DATE(‘ 2012-04-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_02 TO_DATE(‘ 2012-03-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_01 TO_DATE(‘ 2012-02-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2011_12 TO_DATE(‘ 2012-01-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)

Olhei e falei pultz lógico que a supartition que eu estou verificando está zerada e que o dado existe, pois ele estava caindo em uma partition que nao deveria cair a 2012_04, pois a distribuição do Max_value, fugiu do padrão como podemos notar! Bom fiquei feliz e Pau da vida ao mesmo tempo, por causa da alma caridosa que fez isso na base, mas contudo fazer oque vamos corrigir neh…

Salvei os dados referente à todo o periodo de 2012 em uma tabela temporaria, dropei todas as partitions desde 2012_04, criar as partiçoes corretamente, voltei com os dados !

vejamos a distribuição do Max_Value:

Partition Name Max Value
[b][color=#FF0000]CAPA_2012_12 TO_DATE(‘ 2013-01-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_11 TO_DATE(‘ 2012-12-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_10 TO_DATE(‘ 2012-11-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_09 TO_DATE(‘ 2012-10-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_08 TO_DATE(‘ 2012-09-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_07 TO_DATE(‘ 2012-08-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_06 TO_DATE(‘ 2012-07-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_05 TO_DATE(‘ 2012-06-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_04 TO_DATE(‘ 2012-05-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_03 TO_DATE(‘ 2012-04-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_02 TO_DATE(‘ 2012-03-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2012_01 TO_DATE(‘ 2012-02-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)
CAPA_2011_12 TO_DATE(‘ 2012-01-01 00:00:00’, ‘SYYYY-MM-DD HH24:MI:SS’, ‘NLS_CALENDAR=GREGORIAN’)[/color][/b]

Com o Max_Value devidamente restaurado, dei um ALTER TABLE TRUNCATE PARTITION no mes 2012_05, e importei todo o mês 05, ao inves de importar somente uma subpartition somente,

e pra minha felicidade está rodando e até agora sem erros.. e logicamente coloquei commit=y pra nao estourar a UNDO novamente rsrsrss…..

Bom pessoal quiz compartilhar com vocês pois procurei um bucado pela internet e nao achei nenhuma solução pro meu problema !!! e pra mostrar que temos que tentar de tudo, se eu tivesse jogado a toalha, quando me depara-se com esse problema novamente continuaria sem saber resolver.
Agora eu já tenho mais uma saida pra quando acontecer novamente rsrsrs…

Abração pessoal!!!!!

[Heberton MeloParticipante]

Thiago,

Observei que você esta utilizando o EXP, o interessante seria você utilizar o EXPDP/IMPDP muito melhor em vários sentido em relação ao EXPORT/IMPORT, como por exemplo, você pode iniciar os jobs do Data Pump a partir de um processo de usuário, do SQL Plus ou por meio do Enterprise Manager, mas, todo o trabalho é feito pelos processos de servidor. Isso melhora o desempenho dramaticamente em relação aos antigos utilitários EXPORT/IMPORT, porque os processos do Data Pump executando no servidor têm acesso direto aos arquivos de dados e à SGA, eles não precisam acessá-los por uma sessão. Além disso, é possível iniciar um job do Data Pump e, em seguida, desligar-se dele, deixando-o executar em segundo plano. Você pode conecta-se a qualquer momento ao job para monitorar seu progresso.

Mas, em fim, para resolver o seu problema utilizando o EXPORT/IMPORT, recomendo realizar novamente o EXPORT utilizando também o atributo CONSISTENT=Y.

Ele faz com que todas as consultas dirigidas por exp sejam a partir do mesmo ponto no tempo, consistente no que diz respeito um ao outro.

Por exemplo: Tabelas que possuem relacionamentos.

Atenciosamente,

Heberton Melo
MCP | MCTS | MCITP | OCE | OCA | ITIL | ISO 27002

[Autor]

Posts