Re: Assunto: [oracle_br] Lentidão no Update

[Marcos Soares marcos....@gmail.com [oracle_br]]

Alessandro, obrigado pelo retorno.

No entanto, esta coluna não faz referência e nem é referenciada por  outras
tabelas.

Abs

Em Qui, 9 de ago de 2018 18:05, Alessandro Lúcio Cordeiro da Silva
alecordeirosi...@yahoo.com.br [oracle_br] 
escreveu:

>
>
> Olá Marcos, tive este problema devido à coluna add ter referência a uma
> tabela com milhares de linha. A solução foi criar um índice sobre a nova
> coluna.
>
> Enviado do Yahoo Mail no Android
> 
>
> Em Qui, 9 9e ago 9e 2018 às 17:36, Marcos Soares marcos@gmail.com
> [oracle_br] escreveu:
>
>
> Pessoal, Blz?
>
> Alguém de vocês já teve problemas de performance com updates após a
> adicionar uma nova coluna em uma tabela? Estamos com este problema aqui no
> nosso ambiente.
> Já analisamos e não há migração de linhas. Fizemos redefinition da tabela
> e não surtiu efeito. O mais estranho é que no ambiente de desenv não houve
> queda de performance.
> Obs.: ambiente de prod utiliza o Dataguard da Oracle.
> Oracle 11g 11.2.0.4.0 64bit
>
> Obrigado.
>
> Marcos
>
> 
>

Re: [oracle_br] Lentidão no Update

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

Sim, mas desconsiderando re-escrita de SQL, como está hoje a coleta de 
indicadores de performance e de waits, que eram meio fracos da última vez que 
eu vi ? As tools já tem suporte pra captura e análise de planos de execução 
REAIS, ao invés da Simulação feita pelo EXPLAIN PLAN ?? Tem algumas tools de 
análise de trace ? Já tem suporte para manipular/exibir dados do AWR e do ASH, 
que a última vez que fui olhar não tinha ? E esse coletor em SGA, ela realmente 
coleta as colunas 'novas' das v$sqlNN, como os BIND VALUEs usados, os planos de 
execução reais extendidos usados nas últimas execuções, etc ? 
 Se puder, fale um pouquinho sobre esses pontos na sua experiência de uso, pra 
ficar registrado pros demais leitores  ...
 
 []s
 
   Chiappa

Re: [oracle_br] Lentidão no Update

[Erick Guimaraes guimaraes.er...@gmail.com [oracle_br]]

Chiappa, os produtos são bem legais. Ele tem coletor bem interessante que é
um executável no SO que varre a SGA em memória, ele não faz query no banco
de dados, logo queries muito curtas são pegas e mapeadas pelo ferramenta. O
tuning é bem interessante, ele te dá uma série de novas escritas, baseadas
nas melhores práticas e na análise que ele tem do DB, tabela, indice e
etc... E sim, ele faz uma real simulação, com medição em cada alternativa
que deu, inclusive você pode setar seu GOAL, ou seja, o que quer reduzir,
lapse time, consumo de CPU, redução de IOs. E mais , faz uma relação entre
a contenção das métricas internas do Oracle com as métricas físicas do
storage. Eu confesso que uso e gosto bastante. Claro que ele é um auxilio e
nada e nunca qq ferramenta que seja irá substituir um professional
capacitado. Forte abraço.

Em 10 de agosto de 2018 10:12, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Blz ? Erick, eu não sei como estão hoje, mas um tempo atrás eu tinha visto
> uns produtos da Quest e achei fracos no quesito de Tuning : em especial,
> eles só faziam o EXPLAIN PLAN (que dá o Plano de Execução estimado, e Não o
> real) dos SQLs a analisar, não tinham muitas informações sobre Histogramas,
> Child Cursors e coisas do tipo, além de só coletarem/exibirem estatísticas
> muito gerais de performance do banco. É algo a analisar/avaliar se
> esses progs vão ser úteis no caso em questão.
>
>  Marcos, primeira coisa : teu ambiente DESENV contém o ** mesmo ** volume
> de dados que PROD, com o mesmo (ou similar) número de sessões concorrentes,
> com um hardware e um software o mais semelhantes possíveis em relação à
> PROD ??? Se não tem, não vejo NADA DE ESTRANHO em observar performance
> diferente em hardwares diferentes manipulando volumes de dados diferentes
> com diferente número de sessões no banco, não é ?? Faz sentido ? Eu acho
> que faz.
>
>  Segundo : essa coluna que vc adicionou, qual é o datatype dela, será que
> não é um datatype complexo/não-escalar como LOB ? Vcs  tem CONSTRAINTS nela
> , em especial FK ? Tem TRIGGERS referenciando ela/usando-a ? Ela é usada
> nos SQLs da aplicação ? Se é usada sim, será que ela não é usada nos WHEREs
> - obviamente, se é citada/usada nos WHEREs e não houver estatísticas e
> histogramas apropriados o CBO pode montar um Plano de Execução impróprio, o
> que nos leva ao Terceiro ponto 
>
>  Terceiro : pra vc SABER o que está sendo diferente em dois databases que
> pro mesmo SQL apresentam performance largamente diferente, vc TEM que
> coletar 4 informações cruciais em ambos os bancos - SE vc não é o DBA e
> portanto não tem acesso à todas elas, Peça Suporte/ajuda pro seu DBA... São
> elas :
>
>a. os indicadores gerais de performance do banco coletados
> imediatamente antes e imediatamente depois da execução do SQL em questão
> (derivados principalmente da V$SYSSTAT) : a idéia é fazer uma coleta da
> V$SYSSTAT imediatamente antes (armazenando numa tabela ou algo assim),
> executar o SQL e imediatamente depois fazer nova coleta, armazenar E fazer
> a diferença entre os valores da segunda e da primeira coleta, o resultado é
> quanto foi 'gasto' 
>
>b. os indicadores de performance/consumo de recursos da sessão (pode
> ser a V$SESSTAT, pode ser a MYSTATS) : http://betteratoracle.com/
> posts/12-runstats é um exemplo possível, eu costumo usar uma Variação
> desse script, que mostra só os indicadores que Foram alterados ou os cuja
> diferença foi maior que um dado valor
>
>c. os Planos de Execução REAIS : quando vc faz um EXPLAIN PLAN (o que
> como eu disse afaik é o que a maioria das tools faz por vc) vc obtém uma
> ESTIMATIVA do plano de execução do SQL... Para vc obter o plano que
> REALMENTE foi criado e usado, inclusive com Detalhes como qtdade de linhas
> estimadas e reais, tempo gasto, etc) vc pode usar a DBMS_XPLAN, desde que
> vc TENHA ativado a coleta extendida : https://blogs.oracle.com/
> optimizer/how-do-i-know-if-the-cardinality-estimates-in-
> a-plan-are-accurate dá um exemplo...
>
>d. os WAIT EVENTs todos que a execução do SQL sofreu : há diversas
> maneiras de se obter isso mas imho a mais simples é vc fazer um TRACE da
> sessão executando o SQL : http://psoug.org/reference/dbms_monitor.html,
> https://community.toadworld.com/platforms/oracle/b/weblog/
> archive/2014/06/22/tracing-code-with-dbms-monitor e
> http://programmersnotes.com/2013/12/how-to-enable-tracing-
> in-oracle-db-how-to-read-trace-files/ tem uns exemplos
>
> ===>>> Com essas 4 informações vc ** VAI ** descobrir o que está diferente
> : PODE  ser que o plano tenha mudado em um dos databases, PODE ser que o
> plano não mudou mas o banco PROD está rodando o mesmo plano que DESENV mas
> com performance inferior (por causa de waits extras, digamos, ou I/O
> ineficiente, ou qtdade de blocos muito diferente de DESENV). Sem essas
> infos vc vai estar CHUTANDO, simples assim
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Lentidão no Update

[Marcos Soares marcos....@gmail.com [oracle_br]]

Chiappa,

Obrigado pelas ótimas sugestões.

Vou solicitar estas informações ao DBA.

Abs,

Marcos


Em Sex, 10 de ago de 2018 10:12, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Blz ? Erick, eu não sei como estão hoje, mas um tempo atrás eu tinha visto
> uns produtos da Quest e achei fracos no quesito de Tuning : em especial,
> eles só faziam o EXPLAIN PLAN (que dá o Plano de Execução estimado, e Não o
> real) dos SQLs a analisar, não tinham muitas informações sobre Histogramas,
> Child Cursors e coisas do tipo, além de só coletarem/exibirem estatísticas
> muito gerais de performance do banco. É algo a analisar/avaliar se
> esses progs vão ser úteis no caso em questão.
>
>  Marcos, primeira coisa : teu ambiente DESENV contém o ** mesmo ** volume
> de dados que PROD, com o mesmo (ou similar) número de sessões concorrentes,
> com um hardware e um software o mais semelhantes possíveis em relação à
> PROD ??? Se não tem, não vejo NADA DE ESTRANHO em observar performance
> diferente em hardwares diferentes manipulando volumes de dados diferentes
> com diferente número de sessões no banco, não é ?? Faz sentido ? Eu acho
> que faz.
>
>  Segundo : essa coluna que vc adicionou, qual é o datatype dela, será que
> não é um datatype complexo/não-escalar como LOB ? Vcs  tem CONSTRAINTS nela
> , em especial FK ? Tem TRIGGERS referenciando ela/usando-a ? Ela é usada
> nos SQLs da aplicação ? Se é usada sim, será que ela não é usada nos WHEREs
> - obviamente, se é citada/usada nos WHEREs e não houver estatísticas e
> histogramas apropriados o CBO pode montar um Plano de Execução impróprio, o
> que nos leva ao Terceiro ponto 
>
>  Terceiro : pra vc SABER o que está sendo diferente em dois databases que
> pro mesmo SQL apresentam performance largamente diferente, vc TEM que
> coletar 4 informações cruciais em ambos os bancos - SE vc não é o DBA e
> portanto não tem acesso à todas elas, Peça Suporte/ajuda pro seu DBA... São
> elas :
>
>a. os indicadores gerais de performance do banco coletados
> imediatamente antes e imediatamente depois da execução do SQL em questão
> (derivados principalmente da V$SYSSTAT) : a idéia é fazer uma coleta da
> V$SYSSTAT imediatamente antes (armazenando numa tabela ou algo assim),
> executar o SQL e imediatamente depois fazer nova coleta, armazenar E fazer
> a diferença entre os valores da segunda e da primeira coleta, o resultado é
> quanto foi 'gasto' 
>
>b. os indicadores de performance/consumo de recursos da sessão (pode
> ser a V$SESSTAT, pode ser a MYSTATS) :
> http://betteratoracle.com/posts/12-runstats é um exemplo possível, eu
> costumo usar uma Variação desse script, que mostra só os indicadores que
> Foram alterados ou os cuja diferença foi maior que um dado valor
>
>c. os Planos de Execução REAIS : quando vc faz um EXPLAIN PLAN (o que
> como eu disse afaik é o que a maioria das tools faz por vc) vc obtém uma
> ESTIMATIVA do plano de execução do SQL... Para vc obter o plano que
> REALMENTE foi criado e usado, inclusive com Detalhes como qtdade de linhas
> estimadas e reais, tempo gasto, etc) vc pode usar a DBMS_XPLAN, desde que
> vc TENHA ativado a coleta extendida :
> https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
> dá um exemplo...
>
>d. os WAIT EVENTs todos que a execução do SQL sofreu : há diversas
> maneiras de se obter isso mas imho a mais simples é vc fazer um TRACE da
> sessão executando o SQL : http://psoug.org/reference/dbms_monitor.html,
> https://community.toadworld.com/platforms/oracle/b/weblog/archive/2014/06/22/tracing-code-with-dbms-monitor
> e
> http://programmersnotes.com/2013/12/how-to-enable-tracing-in-oracle-db-how-to-read-trace-files/
> tem uns exemplos
>
> ===>>> Com essas 4 informações vc ** VAI ** descobrir o que está diferente
> : PODE  ser que o plano tenha mudado em um dos databases, PODE ser que o
> plano não mudou mas o banco PROD está rodando o mesmo plano que DESENV mas
> com performance inferior (por causa de waits extras, digamos, ou I/O
> ineficiente, ou qtdade de blocos muito diferente de DESENV). Sem essas
> infos vc vai estar CHUTANDO, simples assim
>
> []s
>
>   Chiappa
> 
>

Re: [oracle_br] Lentidão no Update

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

Blz ? Erick, eu não sei como estão hoje, mas um tempo atrás eu tinha visto uns 
produtos da Quest e achei fracos no quesito de Tuning : em especial, eles só 
faziam o EXPLAIN PLAN (que dá o Plano de Execução estimado, e Não o real) dos 
SQLs a analisar, não tinham muitas informações sobre Histogramas, Child Cursors 
e coisas do tipo, além de só coletarem/exibirem estatísticas muito gerais de 
performance do banco. É algo a analisar/avaliar se esses progs vão ser 
úteis no caso em questão.

 Marcos, primeira coisa : teu ambiente DESENV contém o ** mesmo ** volume de 
dados que PROD, com o mesmo (ou similar) número de sessões concorrentes, com um 
hardware e um software o mais semelhantes possíveis em relação à PROD ??? Se 
não tem, não vejo NADA DE ESTRANHO em observar performance diferente em 
hardwares diferentes manipulando volumes de dados diferentes com diferente 
número de sessões no banco, não é ?? Faz sentido ? Eu acho que faz.

 Segundo : essa coluna que vc adicionou, qual é o datatype dela, será que não é 
um datatype complexo/não-escalar como LOB ? Vcs  tem CONSTRAINTS nela , em 
especial FK ? Tem TRIGGERS referenciando ela/usando-a ? Ela é usada nos SQLs da 
aplicação ? Se é usada sim, será que ela não é usada nos WHEREs - obviamente, 
se é citada/usada nos WHEREs e não houver estatísticas e histogramas 
apropriados o CBO pode montar um Plano de Execução impróprio, o que nos leva ao 
Terceiro ponto 
 
 Terceiro : pra vc SABER o que está sendo diferente em dois databases que pro 
mesmo SQL apresentam performance largamente diferente, vc TEM que coletar 4 
informações cruciais em ambos os bancos - SE vc não é o DBA e portanto não tem 
acesso à todas elas, Peça Suporte/ajuda pro seu DBA... São elas :
 
   a. os indicadores gerais de performance do banco coletados imediatamente 
antes e imediatamente depois da execução do SQL em questão (derivados 
principalmente da V$SYSSTAT) : a idéia é fazer uma coleta da V$SYSSTAT 
imediatamente antes (armazenando numa tabela ou algo assim), executar o SQL e 
imediatamente depois fazer nova coleta, armazenar E fazer a diferença entre os 
valores da segunda e da primeira coleta, o resultado é quanto foi 'gasto' 

   b. os indicadores de performance/consumo de recursos da sessão (pode ser a 
V$SESSTAT, pode ser a MYSTATS) : http://betteratoracle.com/posts/12-runstats é 
um exemplo possível, eu costumo usar uma Variação desse script, que mostra só 
os indicadores que Foram alterados ou os cuja diferença foi maior que um dado 
valor

   c. os Planos de Execução REAIS : quando vc faz um EXPLAIN PLAN (o que como 
eu disse afaik é o que a maioria das tools faz por vc) vc obtém uma ESTIMATIVA 
do plano de execução do SQL... Para vc obter o plano que REALMENTE foi criado e 
usado, inclusive com Detalhes como qtdade de linhas estimadas e reais, tempo 
gasto, etc) vc pode usar a DBMS_XPLAN, desde que vc TENHA ativado a coleta 
extendida : 
https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate
 dá um exemplo...
  
   d. os WAIT EVENTs todos que a execução do SQL sofreu : há diversas maneiras 
de se obter isso mas imho a mais simples é vc fazer um TRACE da sessão 
executando o SQL : http://psoug.org/reference/dbms_monitor.html, 
https://community.toadworld.com/platforms/oracle/b/weblog/archive/2014/06/22/tracing-code-with-dbms-monitor
 e 
http://programmersnotes.com/2013/12/how-to-enable-tracing-in-oracle-db-how-to-read-trace-files/
 tem uns exemplos
  
===>>> Com essas 4 informações vc ** VAI ** descobrir o que está diferente : 
PODE  ser que o plano tenha mudado em um dos databases, PODE ser que o plano 
não mudou mas o banco PROD está rodando o mesmo plano que DESENV mas com 
performance inferior (por causa de waits extras, digamos, ou I/O ineficiente, 
ou qtdade de blocos muito diferente de DESENV). Sem essas infos vc vai 
estar CHUTANDO, simples assim

[]s

  Chiappa

Re: [oracle_br] Lentidão no Update

[Erick Guimaraes guimaraes.er...@gmail.com [oracle_br]]

Pessoal recomendo a vcs se tiverem oportunidade claro de instalarem a
solução de data base da empresa Quest.  Irá ajudar bastante. Abs

Em Qui, 9 de ago de 2018 17:36, Marcos Soares marcos@gmail.com
[oracle_br]  escreveu:

>
>
> Pessoal, Blz?
>
> Alguém de vocês já teve problemas de performance com updates após a
> adicionar uma nova coluna em uma tabela? Estamos com este problema aqui no
> nosso ambiente.
> Já analisamos e não há migração de linhas. Fizemos redefinition da tabela
> e não surtiu efeito. O mais estranho é que no ambiente de desenv não houve
> queda de performance.
> Obs.: ambiente de prod utiliza o Dataguard da Oracle.
> Oracle 11g 11.2.0.4.0 64bit
>
> Obrigado.
>
> Marcos
> 
>

Assunto: [oracle_br] Lentidão no Update

[Alessandro Lúcio Cordeiro da Silva alecordeirosi...@yahoo.com.br [oracle_br]]

Olá Marcos, tive este problema devido à coluna add ter referência a uma tabela 
com milhares de linha. A solução foi criar um índice sobre a nova coluna. 

Enviado do Yahoo Mail no Android 
 
  Em Qui, 9 9e ago 9e 2018 às 17:36, Marcos Soares marcos@gmail.com 
[oracle_br] escreveu:       

Pessoal, Blz?
Alguém de vocês já teve problemas de performance com updates após a adicionar 
uma nova coluna em uma tabela? Estamos com este problema aqui no nosso 
ambiente. Já analisamos e não há migração de linhas. Fizemos redefinition da 
tabela e não surtiu efeito. O mais estranho é que no ambiente de desenv não 
houve queda de performance.Obs.: ambiente de prod utiliza o Dataguard da 
Oracle. Oracle 11g 11.2.0.4.0 64bit
Obrigado.
Marcos  #yiv1609448090 #yiv1609448090 -- #yiv1609448090ygrp-mkp {border:1px 
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv1609448090 
#yiv1609448090ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv1609448090 
#yiv1609448090ygrp-mkp #yiv1609448090hd 
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 
0;}#yiv1609448090 #yiv1609448090ygrp-mkp #yiv1609448090ads 
{margin-bottom:10px;}#yiv1609448090 #yiv1609448090ygrp-mkp .yiv1609448090ad 
{padding:0 0;}#yiv1609448090 #yiv1609448090ygrp-mkp .yiv1609448090ad p 
{margin:0;}#yiv1609448090 #yiv1609448090ygrp-mkp .yiv1609448090ad a 
{color:#ff;text-decoration:none;}#yiv1609448090 #yiv1609448090ygrp-sponsor 
#yiv1609448090ygrp-lc {font-family:Arial;}#yiv1609448090 
#yiv1609448090ygrp-sponsor #yiv1609448090ygrp-lc #yiv1609448090hd {margin:10px 
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1609448090 
#yiv1609448090ygrp-sponsor #yiv1609448090ygrp-lc .yiv1609448090ad 
{margin-bottom:10px;padding:0 0;}#yiv1609448090 #yiv1609448090actions 
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1609448090 
#yiv1609448090activity 
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1609448090
 #yiv1609448090activity span {font-weight:700;}#yiv1609448090 
#yiv1609448090activity span:first-child 
{text-transform:uppercase;}#yiv1609448090 #yiv1609448090activity span a 
{color:#5085b6;text-decoration:none;}#yiv1609448090 #yiv1609448090activity span 
span {color:#ff7900;}#yiv1609448090 #yiv1609448090activity span 
.yiv1609448090underline {text-decoration:underline;}#yiv1609448090 
.yiv1609448090attach 
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 
0;width:400px;}#yiv1609448090 ..yiv1609448090attach div a 
{text-decoration:none;}#yiv1609448090 .yiv1609448090attach img 
{border:none;padding-right:5px;}#yiv1609448090 .yiv1609448090attach label 
{display:block;margin-bottom:5px;}#yiv1609448090 .yiv1609448090attach label a 
{text-decoration:none;}#yiv1609448090 blockquote {margin:0 0 0 
4px;}#yiv1609448090 .yiv1609448090bold 
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1609448090 
.yiv1609448090bold a {text-decoration:none;}#yiv1609448090 dd.yiv1609448090last 
p a {font-family:Verdana;font-weight:700;}#yiv1609448090 dd.yiv1609448090last p 
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1609448090 
dd.yiv1609448090last p span.yiv1609448090yshortcuts 
{margin-right:0;}#yiv1609448090 div.yiv1609448090attach-table div div a 
{text-decoration:none;}#yiv1609448090 div.yiv1609448090attach-table 
{width:400px;}#yiv1609448090 div.yiv1609448090file-title a, #yiv1609448090 
div.yiv1609448090file-title a:active, #yiv1609448090 
div.yiv1609448090file-title a:hover, #yiv1609448090 div.yiv1609448090file-title 
a:visited {text-decoration:none;}#yiv1609448090 div.yiv1609448090photo-title a, 
#yiv1609448090 div.yiv1609448090photo-title a:active, #yiv1609448090 
div.yiv1609448090photo-title a:hover, #yiv1609448090 
div.yiv1609448090photo-title a:visited {text-decoration:none;}#yiv1609448090 
div#yiv1609448090ygrp-mlmsg #yiv1609448090ygrp-msg p a 
span.yiv1609448090yshortcuts 
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1609448090 
.yiv1609448090green {color:#628c2a;}#yiv1609448090 .yiv1609448090MsoNormal 
{margin:0 0 0 0;}#yiv1609448090 o {font-size:0;}#yiv1609448090 
#yiv1609448090photos div {float:left;width:72px;}#yiv1609448090 
#yiv1609448090photos div div {border:1px solid 
#66;min-height:62px;overflow:hidden;width:62px;}#yiv1609448090 
#yiv1609448090photos div label 
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv1609448090
 #yiv1609448090reco-category {font-size:77%;}#yiv1609448090 
#yiv1609448090reco-desc {font-size:77%;}#yiv1609448090 .yiv1609448090replbq 
{margin:4px;}#yiv1609448090 #yiv1609448090ygrp-actbar div a:first-child 
{margin-right:2px;padding-right:5px;}#yiv1609448090 #yiv1609448090ygrp-mlmsg 
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv1609448090 
#yiv1609448090ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv1609448090 
#yiv1609448090ygrp-mlmsg select, #yiv1609448090 input, #yiv1609448090 textarea 
{font:99% Arial, 

[oracle_br] Lentidão no Update

[Marcos Soares marcos....@gmail.com [oracle_br]]

Pessoal, Blz?

Alguém de vocês já teve problemas de performance com updates após a
adicionar uma nova coluna em uma tabela? Estamos com este problema aqui no
nosso ambiente.
Já analisamos e não há migração de linhas. Fizemos redefinition da tabela e
não surtiu efeito. O mais estranho é que no ambiente de desenv não houve
queda de performance.
Obs.: ambiente de prod utiliza o Dataguard da Oracle.
Oracle 11g 11.2.0.4.0 64bit

Obrigado.

Marcos