RES: RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Chiappa, Sim, concordo. Irei avaliar suas dicas para implementar neste banco. Muito obrigado por sua ajuda. Grato, Ednilson De: sentto-1682896-121504-1487187307-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121504-1487187307-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de jlchia...@yahoo.com.br [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 17:35 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object Só um ponto em cima da sua situação : como é algo não tão comum eu não tinha pensado em possível corrupção no LOB, então estava tentando esgotar as possibilidades de Snapshot too old "normal", ie, realmente devido a undo necessário para consistência de leitura da query não presente Uma vez que com a muito boa lembrança do outro colega vc chegou numa possível corrupção de LOB (que vc Contornou excluindo o registro com rowid inválido) e a msg de snapshot não retornou , penso que neste momento vc tem é que tentar Primeiro encontrar a causa dessa corrupção e Segundo validar esse banco para que não haja outras posssíveis corrupções ocultas - é aquele procedimento de sempre, ie : export full, dbverify com banco online E com banco offline, scripts e tools Oracle específicos para healtchcheck, etc E após isso feito, analise CUIDADOSAMENTE a possibilidade de passar a usar SECUREFILEs nos seus LOBs, via de regra isso tem implicações positivas não só pra Performance mas também para segurança/evitar corrupção ... https://technology.amis.nl/wp-content/uploads/2013/04/SecureFile-Lobs.pdf fala um pouco sobre as vantagens de securefiles sobre basic, que iirc é o que vc está usando hoje []s Chiappa
Re: RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Só um ponto em cima da sua situação : como é algo não tão comum eu não tinha pensado em possível corrupção no LOB, então estava tentando esgotar as possibilidades de Snapshot too old "normal", ie, realmente devido a undo necessário para consistência de leitura da query não presente Uma vez que com a muito boa lembrança do outro colega vc chegou numa possível corrupção de LOB (que vc Contornou excluindo o registro com rowid inválido) e a msg de snapshot não retornou , penso que neste momento vc tem é que tentar Primeiro encontrar a causa dessa corrupção e Segundo validar esse banco para que não haja outras posssíveis corrupções ocultas - é aquele procedimento de sempre, ie : export full, dbverify com banco online E com banco offline, scripts e tools Oracle específicos para healtchcheck, etc E após isso feito, analise CUIDADOSAMENTE a possibilidade de passar a usar SECUREFILEs nos seus LOBs, via de regra isso tem implicações positivas não só pra Performance mas também para segurança/evitar corrupção ... https://technology.amis.nl/wp-content/uploads/2013/04/SecureFile-Lobs.pdf fala um pouco sobre as vantagens de securefiles sobre basic, que iirc é o que vc está usando hoje []s Chiappa
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Fico feliz em saber que pude ajudar. Um abraço. Dá uma sapeada no meu blog de vez em quando :) http://bancotunado.blogspot.com.br Evandro Giachetto Oracle DBA evandrogiache...@gmail.com http://bancotunado.blogspot.com.br/ Em 15 de fevereiro de 2017 15:03, 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: > > > Evandro, > > Ignora meu e-mail anterior, eu havia feito um move da tabela para outra > tablespace. > > Executei novamente aquele script e peguei o novo rowid. > > > > SQL> delete compras.adm_compras_page where rowid='AAC6pYABbAABSSFAA5'; > > > > 1 row deleted > > > > SQL> COMMIT; > > > > Commit complete > > > > E agora fez o export com sucesso. > > > > Gostaria de agradecer a você, Chiappa e Jonathan Barbosa pela ajuda. > > > > Forte Abraço, > > Ednilson > > > > *De:* sentto-1682896-121499-1487172832-ednilson.silva=jbs. > com...@returns.groups.yahoo.com [mailto:sentto-1682896-121499- > 1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome > de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br] > *Enviada em:* quarta-feira, 15 de fevereiro de 2017 13:34 > > *Para:* oracle_br@yahoogrupos.com.br > *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object > > > > > > Veja bem. > > > > Temos 2 problemas aqui. > > > > 1. Seu Lob está corrompido. > > Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente). > > > A saída do script informou algumas rowid em que foram encontrados blocos > corrompidos. > > > > 2. > > MAX(MAXQUERYLEN) > > > >33094 > > > > COLUMN_NAME SECUREFILE PCTVERSION RETENTION > > - -- -- -- > > TEXTSHOT NO 28800 > > > > Quer dizer que a query mais demorada de seu banco precisa reter undo por > 33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800. > > > > Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria > ser, no mínimo, 33094. > > > > Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido. > > > > Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). > Se você puder excluir essa linha e recriá-la > > > > Em seguida, rode novamente aquele procedimento para identificar corrupção > e veja se tem mais. > > > > > Evandro Giachetto > Oracle DBA > evandrogiache...@gmail.com > > http://bancotunado.blogspot.com.br/ > > > > Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' > ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br> > escreveu: > > > > Evandro, > > Segue resultado do primeiro comando, desculpe não entendi muito bem o > resultado. > > > > Error on rowid AABaK4AAyAAM2zJAA4 page 0 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 1 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 2 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 3 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > > > SQL> select max(maxquerylen) from v$undostat; > > > > MAX(MAXQUERYLEN) > > > >33094 > > > > SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION > > 2from dba_lobs > > 3 where OWNER = 'COMPRAS' > > 4 and TABLE_NAME = 'ADM_COMPRAS_PAGE'; > > > > COLUMN_NAME SECUREFILE PCTVERSION RETENTION > > - -- -- -- > > TEXTSHOT NO 28800 > > > > > > > > Grato, > > > > > *_Ednilson Silva* > > (11) 3144-4305 > > JBS S/A >
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Esse rowid existe? Select * from COMPRAS.ADM_COMPRAS_PAGE where rowid=’AABaK4AAyAAM2zJAA4’; Evandro Giachetto Oracle DBA evandrogiache...@gmail.com http://bancotunado.blogspot.com.br/ Em 15 de fevereiro de 2017 14:53, 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: > > > Evandro, > > Como faço para excluir esse registro? > > > > Seria ? > > delete from COMPRAS.ADM_COMPRAS_PAGE where rowid=’AABaK4AAyAAM2zJAA4’; > > ORA-01410: ROWID inválido > > > > Grato, > > Ednilson > > > > *De:* sentto-1682896-121499-1487172832-ednilson.silva=jbs. > com...@returns.groups.yahoo.com [mailto:sentto-1682896-121499- > 1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome > de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br] > *Enviada em:* quarta-feira, 15 de fevereiro de 2017 13:34 > > *Para:* oracle_br@yahoogrupos.com.br > *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object > > > > > > Veja bem. > > > > Temos 2 problemas aqui. > > > > 1. Seu Lob está corrompido. > > Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente). > > > A saída do script informou algumas rowid em que foram encontrados blocos > corrompidos. > > > > 2. > > MAX(MAXQUERYLEN) > > > >33094 > > > > COLUMN_NAME SECUREFILE PCTVERSION RETENTION > > - -- -- -- > > TEXTSHOT NO 28800 > > > > Quer dizer que a query mais demorada de seu banco precisa reter undo por > 33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800. > > > > Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria > ser, no mínimo, 33094. > > > > Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido. > > > > Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). > Se você puder excluir essa linha e recriá-la > > > > Em seguida, rode novamente aquele procedimento para identificar corrupção > e veja se tem mais. > > > > > Evandro Giachetto > Oracle DBA > evandrogiache...@gmail.com > > http://bancotunado.blogspot.com.br/ > > > > Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' > ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br> > escreveu: > > > > Evandro, > > Segue resultado do primeiro comando, desculpe não entendi muito bem o > resultado. > > > > Error on rowid AABaK4AAyAAM2zJAA4 page 0 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 1 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 2 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > Error on rowid AABaK4AAyAAM2zJAA4 page 3 > > ORA-01555: snapshot too old: rollback segment number with name "" too > > small > > ORA-22924: snapshot too old > > ORA-06512: at "SYS.DBMS_LOB", line > > 1084 > > ORA-06512: at line 1 > > > > SQL> select max(maxquerylen) from v$undostat; > > > > MAX(MAXQUERYLEN) > > > >33094 > > > > SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION > > 2from dba_lobs > > 3 where OWNER = 'COMPRAS' > > 4 and TABLE_NAME = 'ADM_COMPRAS_PAGE'; > > > > COLUMN_NAME SECUREFILE PCTVERSION RETENTION > > - -- -- -- > > TEXTSHOT NO 28800 > > > > > > > > Grato, > > > > > *_Ednilson Silva* > > (11) 3144-4305 > > JBS S/A > > > > *De:* sentto-1682896-121494-1487162780-ednilson.silva=jbs. > com...@returns.groups.yahoo.com [mailto:sentto-1682896-121494- > 1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome > de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br] > *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:46 > >
RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Evandro,
Como faço para excluir esse registro?
Seria ?
delete from COMPRAS.ADM_COMPRAS_PAGE where rowid=’AABaK4AAyAAM2zJAA4’;
ORA-01410: ROWID inválido
Grato,
Ednilson
De:
sentto-1682896-121499-1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121499-1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
Enviada em: quarta-feira, 15 de fevereiro de 2017 13:34
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Veja bem.
Temos 2 problemas aqui.
1. Seu Lob está corrompido.
Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente).
A saída do script informou algumas rowid em que foram encontrados blocos
corrompidos.
2.
MAX(MAXQUERYLEN)
33094
COLUMN_NAME SECUREFILE PCTVERSION RETENTION
- -- -- --
TEXTSHOT NO 28800
Quer dizer que a query mais demorada de seu banco precisa reter undo por 33094
segundos, enquanto o tempo máximo de retenção de seu lob é de 28800.
Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria ser,
no mínimo, 33094.
Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido.
Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). Se
você puder excluir essa linha e recriá-la
Em seguida, rode novamente aquele procedimento para identificar corrupção e
veja se tem mais.
Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/
<https://googledrive.com/host/0B2Cf_sTHpAPjNjFoTXotV3p4emc/signature.png>
Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:
Evandro,
Segue resultado do primeiro comando, desculpe não entendi muito bem o resultado.
Error on rowid AABaK4AAyAAM2zJAA4 page 0
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 1
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 2
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 3
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
33094
SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
2from dba_lobs
3 where OWNER = 'COMPRAS'
4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
COLUMN_NAME SECUREFILE PCTVERSION RETENTION
- -- -- --
TEXTSHOT NO 28800
Grato,
_
Ednilson Silva
(11) 3144-4305 <tel:(11)%203144-4305>
JBS S/A
De:
sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
Enviada em: quarta-feira, 15 de fevereiro de 2017 10:46
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Não acho que o expdp esteja alterando a tabela no momento do export.
Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou RETENTION
ou PCTVERSION.
Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
utilizado (Doc ID 452341.1)
set serverout on
exec dbms_output.enable(10);
declare
pagenumber;
lennumber;
c varchar2(10);
charpp number := 8132/2;
begin
for r in (select rowid rid, dbms_lob.getlength () len
from ) loop
if r.len is not null then
for page in 0..r.len/charpp loop
begin
select dbms_lob.substr (, 1, 1+ (page * charpp))
into c
from
where rowid = r.rid;
exception
when others then
dbms_output.put_line ('Error on rowid ' ||R.rid||' page '||page);
dbms_output.put_line (sqlerrm);
end;
RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Evandro, Ignora meu e-mail anterior, eu havia feito um move da tabela para outra tablespace. Executei novamente aquele script e peguei o novo rowid. SQL> delete compras.adm_compras_page where rowid='AAC6pYABbAABSSFAA5'; 1 row deleted SQL> COMMIT; Commit complete E agora fez o export com sucesso. Gostaria de agradecer a você, Chiappa e Jonathan Barbosa pela ajuda. Forte Abraço, Ednilson De: sentto-1682896-121499-1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121499-1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de Evandro Giachetto evandrogiache...@gmail.com [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 13:34 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object Veja bem. Temos 2 problemas aqui. 1. Seu Lob está corrompido. Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente). A saída do script informou algumas rowid em que foram encontrados blocos corrompidos. 2. MAX(MAXQUERYLEN) 33094 COLUMN_NAME SECUREFILE PCTVERSION RETENTION - -- -- -- TEXTSHOT NO 28800 Quer dizer que a query mais demorada de seu banco precisa reter undo por 33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800. Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria ser, no mínimo, 33094. Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido. Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). Se você puder excluir essa linha e recriá-la Em seguida, rode novamente aquele procedimento para identificar corrupção e veja se tem mais. Evandro Giachetto Oracle DBA evandrogiache...@gmail.com http://bancotunado.blogspot.com.br/ <https://googledrive.com/host/0B2Cf_sTHpAPjNjFoTXotV3p4emc/signature.png> Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: Evandro, Segue resultado do primeiro comando, desculpe não entendi muito bem o resultado. Error on rowid AABaK4AAyAAM2zJAA4 page 0 ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-22924: snapshot too old ORA-06512: at "SYS.DBMS_LOB", line 1084 ORA-06512: at line 1 Error on rowid AABaK4AAyAAM2zJAA4 page 1 ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-22924: snapshot too old ORA-06512: at "SYS.DBMS_LOB", line 1084 ORA-06512: at line 1 Error on rowid AABaK4AAyAAM2zJAA4 page 2 ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-22924: snapshot too old ORA-06512: at "SYS.DBMS_LOB", line 1084 ORA-06512: at line 1 Error on rowid AABaK4AAyAAM2zJAA4 page 3 ORA-01555: snapshot too old: rollback segment number with name "" too small ORA-22924: snapshot too old ORA-06512: at "SYS.DBMS_LOB", line 1084 ORA-06512: at line 1 SQL> select max(maxquerylen) from v$undostat; MAX(MAXQUERYLEN) 33094 SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION 2from dba_lobs 3 where OWNER = 'COMPRAS' 4 and TABLE_NAME = 'ADM_COMPRAS_PAGE'; COLUMN_NAME SECUREFILE PCTVERSION RETENTION - -- -- -- TEXTSHOT NO 28800 Grato, _ Ednilson Silva (11) 3144-4305 <tel:(11)%203144-4305> JBS S/A De: sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de Evandro Giachetto evandrogiache...@gmail.com [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 10:46 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object Não acho que o expdp esteja alterando a tabela no momento do export. Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais. Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou RETENTION ou PCTVERSION. Tente verificar se seu lob não está corrompido. Esse script aqui pode ser utilizado (Doc ID 452341.1) set serverout on exec dbms_output.enable(10); declare pagenumber; lennumber; c varchar2(10); charpp number := 8132/2; begin for r in (select rowid rid, dbms_lob.getlength () len from ) loop if r.len is not null then for page in 0..r.len/charpp loop begin select dbms_lob.substr (, 1, 1+ (page * charpp)) int
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Veja bem.
Temos 2 problemas aqui.
1. Seu Lob está corrompido.
Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente).
A saída do script informou algumas rowid em que foram encontrados blocos
corrompidos.
2.
MAX(MAXQUERYLEN)
33094
COLUMN_NAME SECUREFILE PCTVERSION RETENTION
- -- -- --
TEXTSHOT NO 28800
Quer dizer que a query mais demorada de seu banco precisa reter undo por
33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800.
Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria
ser, no mínimo, 33094.
Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido.
Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). Se
você puder excluir essa linha e recriá-la
Em seguida, rode novamente aquele procedimento para identificar corrupção e
veja se tem mais.
Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/
Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Evandro,
>
> Segue resultado do primeiro comando, desculpe não entendi muito bem o
> resultado.
>
>
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 0
>
> ORA-01555: snapshot too old: rollback segment number with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 1
>
> ORA-01555: snapshot too old: rollback segment number with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 2
>
> ORA-01555: snapshot too old: rollback segment number with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 3
>
> ORA-01555: snapshot too old: rollback segment number with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
>
>
> SQL> select max(maxquerylen) from v$undostat;
>
>
>
> MAX(MAXQUERYLEN)
>
>
>
>33094
>
>
>
> SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
>
> 2from dba_lobs
>
> 3 where OWNER = 'COMPRAS'
>
> 4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
>
>
>
> COLUMN_NAME SECUREFILE PCTVERSION RETENTION
>
> - -- -- --
>
> TEXTSHOT NO 28800
>
>
>
>
>
>
>
> Grato,
>
>
>
>
> *_Ednilson Silva*
>
> (11) 3144-4305
>
> JBS S/A
>
>
>
> *De:* sentto-1682896-121494-1487162780-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121494-
> 1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:46
>
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Não acho que o expdp esteja alterando a tabela no momento do export.
>
>
>
> Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
> corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
>
>
>
> Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
> RETENTION ou PCTVERSION.
>
>
>
> Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
> utilizado (Doc ID 452341.1)
>
>
>
> set serverout on
>
> exec dbms_output.enable(10);
>
> declare
>
> pagenumber;
>
> lennumber;
>
> c varchar2(10);
>
> charpp number := 8132/2;
>
>
>
> begin
>
> for r in (select rowid rid, dbms_lob.getlength () len
>
> from ) loop
>
> if r.len is not null then
>
> for page in 0..r.len/charpp loop
>
> begin
>
> select dbms_lob.substr (, 1, 1+ (page *
> charpp))
>
> into c
>
> from
>
> where rowid = r.rid;
>
>
>
> exception
>
> when others then
>
> dbms_output.put_line ('Error on rowid ' ||R.rid||' page
> '||pag
RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Evandro,
Segue resultado do primeiro comando, desculpe não entendi muito bem o resultado.
Error on rowid AABaK4AAyAAM2zJAA4 page 0
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 1
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 2
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
Error on rowid AABaK4AAyAAM2zJAA4 page 3
ORA-01555: snapshot too old: rollback segment number with name "" too
small
ORA-22924: snapshot too old
ORA-06512: at "SYS.DBMS_LOB", line
1084
ORA-06512: at line 1
SQL> select max(maxquerylen) from v$undostat;
MAX(MAXQUERYLEN)
33094
SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
2from dba_lobs
3 where OWNER = 'COMPRAS'
4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
COLUMN_NAME SECUREFILE PCTVERSION RETENTION
- -- -- --
TEXTSHOT NO 28800
Grato,
_
Ednilson Silva
(11) 3144-4305
JBS S/A
De:
sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121494-1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
Enviada em: quarta-feira, 15 de fevereiro de 2017 10:46
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Não acho que o expdp esteja alterando a tabela no momento do export.
Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou RETENTION
ou PCTVERSION.
Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
utilizado (Doc ID 452341.1)
set serverout on
exec dbms_output.enable(10);
declare
pagenumber;
lennumber;
c varchar2(10);
charpp number := 8132/2;
begin
for r in (select rowid rid, dbms_lob.getlength () len
from ) loop
if r.len is not null then
for page in 0..r.len/charpp loop
begin
select dbms_lob.substr (, 1, 1+ (page * charpp))
into c
from
where rowid = r.rid;
exception
when others then
dbms_output.put_line ('Error on rowid ' ||R.rid||' page '||page);
dbms_output.put_line (sqlerrm);
end;
end loop;
end if;
end loop;
end;
/
Se o LOB não estiver corrompido, use essa query para verificar o tempo máximo
usado pelas queries no banco:
select max(maxquerylen) from v$undostat;
Como seu undo_retention é bem grande, eu acredito que esse tempo não será
maior. O problema então provavelmente está mesmo no RETENTION/PCTVERSION do seu
LOB.
Tenta verificar o retention/pctversion do seu lob.
"COMPRAS"."ADM_COMPRAS_PAGE"
select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where
OWNER='COMPRAS' and TABLE_NAME='ADM_COMPRAS_PAGE';
Se o Retention do LOB for menor que o UNDO_RETENTION, altere-o para um valor
maior (Até o máximo de MAX(UNDO_RETENTION, MAXQUERYLEN) ).
Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/
<https://googledrive.com/host/0B2Cf_sTHpAPjNjFoTXotV3p4emc/signature.png>
Em 15 de fevereiro de 2017 10:32, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:
Chiappa,
Minha UNDO esta como GUARANTEED.
Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot too old
ORA-01555: instantâneo muito antigo: número de segmento de rollback com nome
"" muito pequeno
ORA-22924: snapshot muito antigo
Esta bem claro mesmo que no momento do export algum processo esta alterando
essa tabela sim, irei aprofundar meus teste nisso.
Grato,
Ednilson
De:
sentto-1682896-121491-1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121491-1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de jlchia...@yahoo.com.br [oracle_br]
Enviada em: quarta-feira, 15 de fevereiro de 2017 10:14
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Tá, e os outros pontos ** todos ** : essa Retention
Re: RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Hmmm - pra uma tablespace de UNDO que está registrada como GUARANTEED dar um SNAPSHOT TOO OLD é necessário realmente que haja uma pressão constante por UNDO, tão grande que não há como o RDBMS honrar o retention - cfrme https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:7705505116425 nos lembra, a RETENÇÃO é uma forte recomendação que nós fazemos para o RDBMS mas ele ainda pode ocupar totalmente o UNDO disponível se for obrigado a isso... Com Certeza é o caso de vc analisar sua Transações (E também suas eventuais queries de longa duração) versus teu consumo de UNDO, com os scripts constantes nos links que te passei - basicamente vc vai ter que ter acesso a V$UNDOSTAT, V$TRANSACTION, V$SESSION+V$SQL (para determinar quem eventualmente tá fazendo queries de longa duração, digamos)... []s Chiappa
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
E, claro.
Estou considerando que você já verificou seu ambiente externo (Discos, CPU,
Memória), se não tem muita concorrência, como o Chiappa falou.
Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/
Em 15 de fevereiro de 2017 10:46, Evandro Giachetto <
evandrogiache...@gmail.com> escreveu:
> Não acho que o expdp esteja alterando a tabela no momento do export.
>
> Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
> corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
>
> Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
> RETENTION ou PCTVERSION.
>
> Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
> utilizado (Doc ID 452341.1)
>
> set serverout on
> exec dbms_output.enable(10);
> declare
> pagenumber;
> lennumber;
> c varchar2(10);
> charpp number := 8132/2;
>
> begin
> for r in (select rowid rid, dbms_lob.getlength () len
> from ) loop
> if r.len is not null then
> for page in 0..r.len/charpp loop
> begin
> select dbms_lob.substr (, 1, 1+ (page *
> charpp))
> into c
> from
> where rowid = r.rid;
>
> exception
> when others then
> dbms_output.put_line ('Error on rowid ' ||R.rid||' page
> '||page);
> dbms_output.put_line (sqlerrm);
> end;
> end loop;
> end if;
> end loop;
> end;
> /
>
> Se o LOB não estiver corrompido, use essa query para verificar o tempo
> máximo usado pelas queries no banco:
>
> select max(maxquerylen) from v$undostat;
>
> Como seu undo_retention é bem grande, eu acredito que esse tempo não será
> maior. O problema então provavelmente está mesmo no RETENTION/PCTVERSION do
> seu LOB.
>
> Tenta verificar o retention/pctversion do seu lob.
>
> "COMPRAS"."ADM_COMPRAS_PAGE"
>
> select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where
> OWNER='COMPRAS' and TABLE_NAME='ADM_COMPRAS_PAGE';
>
> Se o Retention do LOB for menor que o UNDO_RETENTION, altere-o para um
> valor maior (Até o máximo de MAX(UNDO_RETENTION, MAXQUERYLEN) ).
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://bancotunado.blogspot.com.br/
>
>
> Em 15 de fevereiro de 2017 10:32, 'Ednilson Silva'
> ednilson.si...@jbs.com.br [oracle_br] <oracle_br@yahoogrupos.com.br>
> escreveu:
>
>>
>>
>> Chiappa,
>>
>> Minha UNDO esta como GUARANTEED.
>>
>>
>>
>> Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot
>> too old
>>
>>
>>
>> ORA-01555: instantâneo muito antigo: número de segmento de rollback com
>> nome "" muito pequeno
>>
>> ORA-22924: snapshot muito antigo
>>
>>
>>
>> Esta bem claro mesmo que no momento do export algum processo esta
>> alterando essa tabela sim, irei aprofundar meus teste nisso.
>>
>>
>>
>> Grato,
>>
>> Ednilson
>>
>>
>>
>> *De:* sentto-1682896-121491-1487160830-ednilson.silva=jbs.com.br@
>> returns.groups.yahoo.com [mailto:sentto-1682896-121491-
>> 1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
>> de *jlchia...@yahoo.com.br [oracle_br]
>> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:14
>> *Para:* oracle_br@yahoogrupos.com.br
>> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>>
>>
>>
>>
>>
>> Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED
>> ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos
>> citando e vc não nos diz SE não for, avalie a Possibilidade de tornar
>> esse UNDo como GUARANTEED ..
>> De que maneira vc checou que não havia no exato momento do export
>> ninguém fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá
>> incluso nisso consulta na V$TRANSACTION ?? A questão aqui é tentar
>> localizar eventuais JOBs (até externos ao banco, talvez) e/ou sessões que
>> façam acessos pequenos mas intermitentes e frequentes - seria Interessante
>> se nesses testes isolados que vc vai fazer à noite vc lançasse mão de
>> alguma técnica (ogra que seja, como remover temporariamente acesso, baixar
>> listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar
>> garantir que ninguém acesse a tabela enquanto rola o export...
>> Nesse teste que vc vai fazer é ** imperativo ** que além de não haver
>> outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como
>> indicado previamente, também... E Não Deixe de fazer os demais testes que
>> sugeri na minha outra resposta, como testar com exp tradicional, tentar um
>> SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do
>> expdp como um todo, usando as notas que indiquei, seria de bom tom também
>> antes do teu teste à noite...
>>
>> []s
>>
>>Chiappa
>>
>>
>>
>
>
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Não acho que o expdp esteja alterando a tabela no momento do export.
Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
RETENTION ou PCTVERSION.
Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
utilizado (Doc ID 452341.1)
set serverout on
exec dbms_output.enable(10);
declare
pagenumber;
lennumber;
c varchar2(10);
charpp number := 8132/2;
begin
for r in (select rowid rid, dbms_lob.getlength () len
from ) loop
if r.len is not null then
for page in 0..r.len/charpp loop
begin
select dbms_lob.substr (, 1, 1+ (page * charpp))
into c
from
where rowid = r.rid;
exception
when others then
dbms_output.put_line ('Error on rowid ' ||R.rid||' page
'||page);
dbms_output.put_line (sqlerrm);
end;
end loop;
end if;
end loop;
end;
/
Se o LOB não estiver corrompido, use essa query para verificar o tempo
máximo usado pelas queries no banco:
select max(maxquerylen) from v$undostat;
Como seu undo_retention é bem grande, eu acredito que esse tempo não será
maior. O problema então provavelmente está mesmo no RETENTION/PCTVERSION do
seu LOB.
Tenta verificar o retention/pctversion do seu lob.
"COMPRAS"."ADM_COMPRAS_PAGE"
select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where
OWNER='COMPRAS' and TABLE_NAME='ADM_COMPRAS_PAGE';
Se o Retention do LOB for menor que o UNDO_RETENTION, altere-o para um
valor maior (Até o máximo de MAX(UNDO_RETENTION, MAXQUERYLEN) ).
Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/
Em 15 de fevereiro de 2017 10:32, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br] <oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Chiappa,
>
> Minha UNDO esta como GUARANTEED.
>
>
>
> Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot too
> old
>
>
>
> ORA-01555: instantâneo muito antigo: número de segmento de rollback com
> nome "" muito pequeno
>
> ORA-22924: snapshot muito antigo
>
>
>
> Esta bem claro mesmo que no momento do export algum processo esta
> alterando essa tabela sim, irei aprofundar meus teste nisso.
>
>
>
> Grato,
>
> Ednilson
>
>
>
> *De:* sentto-1682896-121491-1487160830-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121491-
> 1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *jlchia...@yahoo.com.br [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:14
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED
> ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos
> citando e vc não nos diz SE não for, avalie a Possibilidade de tornar
> esse UNDo como GUARANTEED ..
> De que maneira vc checou que não havia no exato momento do export ninguém
> fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá incluso
> nisso consulta na V$TRANSACTION ?? A questão aqui é tentar localizar
> eventuais JOBs (até externos ao banco, talvez) e/ou sessões que façam
> acessos pequenos mas intermitentes e frequentes - seria Interessante se
> nesses testes isolados que vc vai fazer à noite vc lançasse mão de alguma
> técnica (ogra que seja, como remover temporariamente acesso, baixar
> listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar
> garantir que ninguém acesse a tabela enquanto rola o export...
> Nesse teste que vc vai fazer é ** imperativo ** que além de não haver
> outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como
> indicado previamente, também... E Não Deixe de fazer os demais testes que
> sugeri na minha outra resposta, como testar com exp tradicional, tentar um
> SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do
> expdp como um todo, usando as notas que indiquei, seria de bom tom também
> antes do teu teste à noite...
>
> []s
>
>Chiappa
>
>
>
RES: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Chiappa, Minha UNDO esta como GUARANTEED. Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot too old ORA-01555: instantâneo muito antigo: número de segmento de rollback com nome "" muito pequeno ORA-22924: snapshot muito antigo Esta bem claro mesmo que no momento do export algum processo esta alterando essa tabela sim, irei aprofundar meus teste nisso. Grato, Ednilson De: sentto-1682896-121491-1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121491-1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de jlchia...@yahoo.com.br [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 10:14 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos citando e vc não nos diz SE não for, avalie a Possibilidade de tornar esse UNDo como GUARANTEED .. De que maneira vc checou que não havia no exato momento do export ninguém fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá incluso nisso consulta na V$TRANSACTION ?? A questão aqui é tentar localizar eventuais JOBs (até externos ao banco, talvez) e/ou sessões que façam acessos pequenos mas intermitentes e frequentes - seria Interessante se nesses testes isolados que vc vai fazer à noite vc lançasse mão de alguma técnica (ogra que seja, como remover temporariamente acesso, baixar listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar garantir que ninguém acesse a tabela enquanto rola o export... Nesse teste que vc vai fazer é ** imperativo ** que além de não haver outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como indicado previamente, também... E Não Deixe de fazer os demais testes que sugeri na minha outra resposta, como testar com exp tradicional, tentar um SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do expdp como um todo, usando as notas que indiquei, seria de bom tom também antes do teu teste à noite... []s Chiappa
RES: RES: [oracle_br] Re: ORA-31693: Table data object
Oi Ednilson, Acredito que o erro de snapshot too old nesse caso é devido ao lob estar corrompido. Por favor, verifique a seguinte nota. Export Fails With Errors ORA-2354 ORA-1555 ORA-22924 And How To Confirm LOB Segment Corruption Using Export Utility (Doc ID 833635.1) Obrigado, Jonathan De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: Wednesday, February 15, 2017 9:56 AM Para: oracle_br@yahoogrupos.com.br Assunto: RES: RES: [oracle_br] Re: ORA-31693: Table data object Chiappa, A RETENTION da tabela esta igual a do banco. SQL> select retention from dba_lobs where table_name='ADM_COMPRAS_PAGE'; RETENTION --< o> 28800 SQL> show parameter undo NAME TYPEVALUE --- undo_management string AUTO undo_retention integer 28800 undo_tablespace string UNDOTBS1 Já verifiquei e não existe nenhum processo gravando nada nesta tabela. Existe uma outra tabela que é mais acessada que esta e não ocorre este erro. Consegui uma “janela” hoje a noite para uma parada no sistema, irei fazer um teste sem ninguém conectado. Grato, Ednilson De: <mailto:sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com> sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com [ <mailto:sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com> mailto:sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de <mailto:jlchia...@yahoo.com.br> jlchia...@yahoo.com.br [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 09:31 Para: <mailto:oracle_br@yahoogrupos.com.br> oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: ORA-31693: Table data object Tá : quando vc diz que "seguiu os conselhos" com isso vc : - CHECOU o RETENTION do próprio LOB além do retention a nível de banco, ta l como indicado no primeiro LINK ?? - CONSULTOU precisamente como está a Utilização de UNDO no seu sistema enquanto rola o EXPORT ?? - CONSULTOU a V$TRANSACTION e demais relacionadas pra ** CONFIRMAR ** a sua Hipótese de transações frequentes alterando essa tabela ? Já pensou na maneira ** OGRA ** de descobrir quem está acessando um objeto, ie, simplesmente remover acesso ao objeto e ver quem/o que reclama ?? A questão é evitar o "achismo", vc tem que descobrir EXATAMENTE como está a tua utilização de UNDO e quais transações estão concorrendo com o export []s Chiappa -- E-mail Seguro Vetorial.net Mensagem classificada como NAO-SPAM. Para classificar como SPAM, encaminhe para s...@vetorial.net Chave de Identificacao: 1000,58a441e0587321831329685 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos citando e vc não nos diz SE não for, avalie a Possibilidade de tornar esse UNDo como GUARANTEED .. De que maneira vc checou que não havia no exato momento do export ninguém fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá incluso nisso consulta na V$TRANSACTION ?? A questão aqui é tentar localizar eventuais JOBs (até externos ao banco, talvez) e/ou sessões que façam acessos pequenos mas intermitentes e frequentes - seria Interessante se nesses testes isolados que vc vai fazer à noite vc lançasse mão de alguma técnica (ogra que seja, como remover temporariamente acesso, baixar listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar garantir que ninguém acesse a tabela enquanto rola o export... Nesse teste que vc vai fazer é ** imperativo ** que além de não haver outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como indicado previamente, também... E Não Deixe de fazer os demais testes que sugeri na minha outra resposta, como testar com exp tradicional, tentar um SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do expdp como um todo, usando as notas que indiquei, seria de bom tom também antes do teu teste à noite... []s Chiappa
RES: RES: [oracle_br] Re: ORA-31693: Table data object
Chiappa, A RETENTION da tabela esta igual a do banco. SQL> select retention from dba_lobs where table_name='ADM_COMPRAS_PAGE'; RETENTION -- 28800 SQL> show parameter undo NAME TYPEVALUE --- undo_management string AUTO undo_retention integer 28800 undo_tablespace string UNDOTBS1 Já verifiquei e não existe nenhum processo gravando nada nesta tabela. Existe uma outra tabela que é mais acessada que esta e não ocorre este erro. Consegui uma “janela” hoje a noite para uma parada no sistema, irei fazer um teste sem ninguém conectado. Grato, Ednilson De: sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com [mailto:sentto-1682896-121488-1487158273-ednilson.silva=jbs.com...@returns.groups.yahoo.com] Em nome de jlchia...@yahoo.com.br [oracle_br] Enviada em: quarta-feira, 15 de fevereiro de 2017 09:31 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: ORA-31693: Table data object Tá : quando vc diz que "seguiu os conselhos" com isso vc : - CHECOU o RETENTION do próprio LOB além do retention a nível de banco, tal como indicado no primeiro LINK ?? - CONSULTOU precisamente como está a Utilização de UNDO no seu sistema enquanto rola o EXPORT ?? - CONSULTOU a V$TRANSACTION e demais relacionadas pra ** CONFIRMAR ** a sua Hipótese de transações frequentes alterando essa tabela ? Já pensou na maneira ** OGRA ** de descobrir quem está acessando um objeto, ie, simplesmente remover acesso ao objeto e ver quem/o que reclama ?? A questão é evitar o "achismo", vc tem que descobrir EXATAMENTE como está a tua utilização de UNDO e quais transações estão concorrendo com o export []s Chiappa
