Removendo um índice teimoso... | GPO (Grupo de Profissionais Oracle)

Este tópico contém 32 respostas, 7 vozes e foi atualizado pela última vez 16 anos, 7 meses atrás por Rodrigo Almeida.

Visualizando 15 posts - 16 até 30 (de 33 do total)

← 1 2 3 →

Autor

Posts
4 de março de 2009 às 8:47 pm #85595
David Siqueira
Participante
Beleza..Vou caçar mais alfuma coisa por aqui e posto pra ti depois.

Abcs.

David
4 de março de 2009 às 9:36 pm #85598
vieri
Participante
o shrink é do 10g …. ai é 9né..

porque será que o nome do trace gerado está começando com snap.

Tera alguma mview na jogada?!?!
4 de março de 2009 às 9:44 pm #85601
David Siqueira
Participante
Marcio , procurei no metalink algo relacionado, o máximo que achei foi esse link , acredito que chegue perto do seu problema mais ainda não é isso:

https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1509268141782644468::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,261816.1,1,1,1,helvetica

Dá uma olhada lá!!!

Abcs.

David
4 de março de 2009 às 9:45 pm #85602
Marcio68Almeida
Participante
[quote=”vieri”:13dacoa4]o shrink é do 10g …. ai é 9né..

porque será que o nome do trace gerado está começando com snap.

Tera alguma mview na jogada?!?![/quote]

SNAP é o nome do banco… 😀
4 de março de 2009 às 9:51 pm #85603
Marcio68Almeida
Participante
[quote=”Drbs”:3a7odwtb]Marcio , procurei no metalink algo relacionado, o máximo que achei foi esse link , acredito que chegue perto do seu problema mais ainda não é isso:

https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1509268141782644468::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,261816.1,1,1,1,helvetica

Dá uma olhada lá!!!

Abcs.

David[/quote]

Dei uma olhada, mas lá é a versão 9.2.0.3 aqui é 9.2.0.8
A solução deles :
- Please apply one of patch for your platform if available or upgrade the database to 10.1.0.2.0 in which this bug is addressed.
Não posso alterar a versão para 10g, a aplicação ainda não está homologada para 10g
4 de março de 2009 às 9:56 pm #85605
David Siqueira
Participante
De volta a prancheta então..hehehehe!!!!…
Abcs.
David
4 de março de 2009 às 9:59 pm #85606
Rodrigo Almeida
Participante
Subject: ORA-600 [25012] “Relative to Absolute File Number Conversion Error”
Doc ID: 100073.1 Type: REFERENCE
Modified Date : 24-FEB-2009 Status: PUBLISHED

Note: For additional ORA-600 related information please read Note 146580.1

PURPOSE:
This article discusses the internal error “ORA-600 [25012]”, what
it means and possible actions. The information here is only applicable
to the versions listed and is provided only for guidance.

ERROR:
ORA-600 [25012] [a] [b]

VERSIONS:
versions 8.0 to 10.1

DESCRIPTION:

We are trying to generate the absolute file number given a tablespace
number and relative file number and cannot find a matching file number
or the file number is zero.

ARGUMENTS:
Arg [a] Tablespace Number
Arg [b] Relative file number

FUNCTIONALITY:
KERNEL FILE MANAGEMENT TABLESPACE COMPONENT

IMPACT:
POSSIBLE PHYSICAL CORRUPTION

SUGGESTIONS:

The possibility of physical corruption exists.

Obtain the trace files and alert.log for this error and log an iTAR
with Oracle Support Services for diagnosis.

If the Arg [b] Relative file number returns 0 (zero), look for fake indexes
that can cause this error.

The following query list fake indexes :

select a.*,b.flags from dba_objects a, sys.ind$ b
where a.object_id = b.obj#
and bitand(b.flags,4096)=4096;

Known Issues:

Bug# 5653641 See Note 5653641.8
Corrupt dictionary from DROP TABLESPACE containing _offline_rollback_segments
Fixed: 11.2

Bug# 4925342 See Note 4925342.8
OERI [25027] / OERI [25012] on IOT analyze estimate statistics
Fixed: 9.2.0.8, 10.2.0.3, 11.1.0.6

Bug# 4305391 See Note 4305391.8
OERI[25012] with kditalp can occur during a temporary LOB operation
Fixed: 9.2.0.7, 10.1.0.5, 10.2.0.1

Bug# 3915343 See Note 3915343.8
OERI [25012] on COMMIT with refresh ON-COMMIT Materialized view over cluster
Fixed: 9.2.0.7, 10.1.0.5, 10.2.0.1

Bug# 3900237 See Note 3900237.8
OERI[25012] changing length of indexed column for a global temporary table
Fixed: 9.2.0.7

Bug# 3771508 See Note 3771508.8
OERI[kcbgtcr_1] / OERI[25012] selecting from V$AQ in a shared server
Fixed: 9.2.0.7

Bug# 3751874 See Note 3751874.8
OERI[25012] can occur when _old_connect_by_enabled set to true
Fixed: 9.2.0.6, 10.1.0.4, 10.2.0.1

Bug# 3430832 See Note 3430832.8
OERI[25012] in DML after ONLINE create index against PARTITIONED table
Fixed: 9.2.0.6, 10.1.0.3, 10.2.0.1

Bug# 3258674 See Note 3258674.8
QMN process may dump or raise an internal error during DML
Fixed: 9.2.0.7, 10.1.0.4, 10.2.0.1

Bug# 3150268 See Note 3150268.8
OERI[kcbgcur_1] / OERI:25012 deleting rows from PARENT table with LIST subpartitions
Fixed: 9.2.0.5, 10.1.0.2

Bug# 3070856 See Note 3070856.8
OERI:12700 / 25012 / ktrexc_1 on transported tablespace with SMU
Fixed: 9.2.0.5, 10.1.0.2

Bug# 2531519 See Note 2531519.8
OERI:[25012] from parallel direct load of bitmap managed segments
Fixed: 9.2.0.3, 10.1.0.2

Bug# 2526334 See Note 2526334.8
OERI:25012 from AND EQUAL with B-Tree and DOMAIN index
Fixed: 9.2.0.3, 10.1.0.2

Bug# 2287815 See Note 2287815.8
OERI:KTSPISCHNT / OERI:25012 after exchange PARTITION with bitmap managed segments
Fixed: 9.0.1.4, 9.2.0.1

Bug# 2214167 See Note 2214167.8
OERI:25012 / wrong results possible after TRUNCATE of bitmap managed index
Fixed: 9.0.1.4, 9.2.0.1

Bug# 2212389 See Note 2212389.8
OERI:25012 / Cursor frame memory corruption when cursor with BINDS aged out / reloaded
Fixed: 9.0.1.4, 9.2.0.1

Bug# 2189615 See Note 2189615.8
OERI:25012 / OERI:504 [cache buffers chains] selecting from certain V$ tables
Fixed: 8.1.7.4, 9.0.1.4, 9.2.0.1

Bug# 2184731 See Note 2184731.8
OERI:25012 possible from index prefetch
Fixed: 8.1.7.4, 9.2.0.1

Bug# 1968815 See Note 1968815.8
OERI:25012 possible from SMON following DROP TABLESPACE command
Fixed: 9.0.1.2, 9.2.0.1

Bug# 1949273 See Note 1949273.8
OERI:25012 / ORA-1555 / ORA-22922 accessing LOB data after ALTER TABLE MOVE lob
Fixed: 8.1.7.3, 9.0.1.0

Bug# 1872985 See Note 1872985.8
Dump / OERI:25012 from BITMAP CONVERSION of INDEX on GLOBAL TEMPORARY TABLE
Fixed: 9.0.1.2, 9.2.0.1

Bug# 1837529 See Note 1837529.8
OERI:KFTR2BZ_1/OERI:25012 from CREATE sub-partitioned local INDEX ONLINE
Fixed: 8.1.7.3, 9.0.1.1, 9.2.0.1

Bug# 1834530 See Note 1834530.8
OERI:25012 / wrong results after EXCHANGE PARTITION with indexes with different FREELIST /FREELIST GROUPS
Fixed: 8.1.7.4, 9.0.1.4, 9.2.0.1

Bug# 1788648 See Note 1788648.8
OERI:25012 [2147483647] possible selecting from certain V$ views
Fixed: 8.1.7.3, 9.0.1.1, 9.2.0.1

Bug# 1784708 See Note 1784708.8
OERI:KCBGTCR_1/OERI:25012 accessing LONG / LONG RAW in a HASH CLUSTER
Fixed: 8.1.7.3, 9.0.1.1, 9.2.0.1

Bug# 1698789 See Note 1698789.8
Wrong results, ORA-1410, ORA-8103, OERI:25012 on SELECT of UNSCOPED REF with ROWID
Fixed: 9.2.0.1

Bug# 1678963 See Note 1678963.8
OERI:25012 / OERI:4142 possible on TRUNCATE of a table with a CLOB column
Fixed: 8.1.7.2, 9.0.1.0

Bug# 1527982 See Note 1527982.8
OERI:25012 / Bitmap indextable mismatch after UPDATE of PARTITION KEY moves rows
Fixed: 8.1.7.2, 9.0.1.0

Bug# 1396571 See Note 1396571.8
OERI:25012 possible importing with TRANSPORT_TABLESPACE=Y
Fixed: 8.0.6.3, 8.1.6.3, 8.1.7.1, 9.0.1.0

Bug# 1312233 See Note 1312233.8
OERI:25012 / OERI:KCBGCUR_1 possible on PQ STAR query with PARTITIONED fact table
Fixed: 8.1.6.3, 8.1.7.0

Bug# 1297674 See Note 1297674.8
OERI:25012 Analyzing partitioned table with ESTIMATE
Fixed: 8.0.6.2, 8.1.6.3, 8.1.7.0

Bug# 1264970 See Note 1264970.8
OERI:25012 / OERI:6050 possible coalescing index with freelists
Fixed: 8.1.7.1, 9.0.1.0

Bug# 1228658 See Note 1228658.8
Create INDEX on SNAPSHOT/MV can produce corrupt index (OERI:13004 / OERI:25012 / ORA-1499)
Fixed: 8.1.6.2, 8.1.7.0

Bug# 1138239 See Note 1138239.8
OERI-25012 possible on direct read from plugged in (transportable) tablespace
Fixed: 8.1.6.2, 8.1.7.0

Bug# 1108002 See Note 1108002.8
OERI:25012 when DBMS_STATS tries to gather stats for a GLOBAL TEMPORARY table
Fixed: 8.1.7.0

Bug# 986928 See Note 986928.8
DBMS_SPACE.UNUSED_SPACE reports OERI:25012 for TEMPORARY tables
Fixed: 8.1.7.0

Bug# 718499 See Note 718499.8
OERI:25012 possible on OPS parallel create index
Fixed: 8.0.6.1, 8.1.5.0

Bug# 679817 See Note 679817.8
OERI:25012 from view containing 2+ LOB columns
Fixed: 8.0.5.1

Bug# 677243 See Note 677243.8
OERI:kdddgbX on DELETE / UPDATE / SELECT for UPDATE with an invalid ROWID
Fixed: 8.0.6.0

Bug# 595698 See Note 595698.8
DELETE on table with many child constraints may dump.
Fixed: 8.0.4.3, 8.0.5.0

Marcio,

Passa o patchset que está aplicado no banco de dados, se é 9.2.0.1, 9.2.0.2, 9.2.0.3 e etc…

Sobre os índices com NOSEGMENTS, basta ver um arquivo de parâmetro da instância, o parâmetro _use_nosegment_indexes, é um parâmetro oculto.

Sobre o primeiro parâmetro do seu erro ORA-600, no metalink deu isso:

================================================
4 de março de 2009 às 10:34 pm #85609
Ishii
Participante
Olá a todos,

To chegando agora… mas vamos ver se eu ajudo…

A view DBA_SEGMENTS usa a tabela SEG$ e a view DBA_INDEXES também, já a view DBA_OBJECT usa a tabela OBJ$ e a tabela SEG$. Pelo que parece ele ficou somente nesta tabela OBJ$ por alguma razão e por isso os resultados estranhos nas queries… eu faria o seguinte teste:

1) DUMP full da Base
2) Import full numa base de teste
3) Delete na OBJ$ deste indice (pelo menos tem o ID)
4) Rezar muito e ver se tudo funciona….

[]s Ishii
4 de março de 2009 às 11:06 pm #85610
Marcio68Almeida
Participante
[quote=”alphamek”:cejt03d0]Subject: ORA-600 [25012] “Relative to Absolute File Number Conversion Error”
Doc ID: 100073.1 Type: REFERENCE
Modified Date : 24-FEB-2009 Status: PUBLISHED

Marcio,

Passa o patchset que está aplicado no banco de dados, se é 9.2.0.1, 9.2.0.2, 9.2.0.3 e etc…

Sobre os índices com NOSEGMENTS, basta ver um arquivo de parâmetro da instância, o parâmetro _use_nosegment_indexes, é um parâmetro oculto.

Sobre o primeiro parâmetro do seu erro ORA-600, no metalink deu isso:

================================================[/quote]

Bom, o erro que nos aconteceu realmente pode ser uma das “milhares” de opções mostradas pelo documento… risos…
Nós já nos encontramos na última versão do 9i, por enquanto não podemos passar para o 10g, neste caso por MUITOS motivos… 🙁

Esse parâmetro é realmente bastante oculto, difícil de encontrar alguma coisa concreta sobre ele, vi como usar, não como ver se está true or false…

Ishii,
Nós já nos encontramos na fase “resar muito”… risos…
Estava pensando se há alguma forma de remover o objeto usando apenas o ID, sugeriram remover da $OBJ, mas para mim isso só iria esconder o problema, pois o objecto físico continuaria lá, não ???

Por enquanto não é um problema que esteja impactando em nosso banco, é um, na verdade dois, objetos que não deveriam estar lá.
Também não possuímos, neste momento, uma outra máquina para fazer esse teste.
5 de março de 2009 às 12:23 am #85614
vieri
Participante
Nessa altura do campeonato , update em tabela interna, tentativas e tentativas.. to meio com sono mas ve se isso faz sentido…

caso vc consiga descobrir em qual tablespace está o index louco,

faça um rebuild de todos os outros índices nesta tbps para outra tablespace e drope a tbps antiga que ficou com o índice zumbi.

😈
5 de março de 2009 às 5:57 pm #85617
Marcio68Almeida
Participante
[quote=”vieri”:1n8xf80k]Nessa altura do campeonato , update em tabela interna, tentativas e tentativas.. to meio com sono mas ve se isso faz sentido…

caso vc consiga descobrir em qual tablespace está o index louco,

faça um rebuild de todos os outros índices nesta tbps para outra tablespace e drope a tbps antiga que ficou com o índice zumbi.

😈 [/quote]
Essa é a ação que começamos a tomar ontem…
Esse índice e a tabela baleados não estão interferindo em nada, mas não gosto de lixos no meu banco…
Estou aproveitando para redistribuir índices e tabelas para outras tablespaces, não gosto de tablespaces com um número muito grande de objetos, a chance de dar dor de cabeça é enorme…
6 de março de 2009 às 5:20 am #85630
CleitonHanzen
Participante
Opá..

Tbém toh chegando meio atrasado (as últimas semanas estão Fo..s). Bom, já tive este erro no Oracle 10g e fiquei em conferência com um engenheiro da Oracle durante umas 3 horas e o cara não achava solução. Drop da tabela não funcionava, drop da tablespace não funcionava (estas operações geram outras operações DROP por debaixo dos panos). Por fim, acabamos descobrindo que o índice estava associado à uma PK, mas a PK não existia mais….Criamos a PK para usar o maldito índice, demos drop na PK e boa, problema resolvido..

Tente isso….. 🙂

Flw.
10 de março de 2009 às 5:40 pm #85706
Marcio68Almeida
Participante
Estavamos recriando os objetos em outra tablespace para remover a que possui os dados “loucos”…
Vamos testar essa opção da PK e ver o que acontece…

Por enquanto, obrigado a todos…
27 de abril de 2009 às 6:49 pm #86466
Marcio68Almeida
Participante
Demorei por que tinha muita tabela nessa tablespace e não dava para fazer rebuild no índices e move das tabelas…
Agora só tem a tabela “danificada” nessa tablespace.

Dei o seguinte comendo…
drop tablespace tablespace INCLUDING CONTENTS and datafiles

Me deu o seguinte erro :
The following error has occurred:
ORA-00604: error occurred at recursive SQL level 2 ORA-01426: numeric overflow
Details: ORA-00604: error occurred at recursive SQL level 2 ORA-01426: numeric overflow
27 de abril de 2009 às 9:07 pm #86472
Rodrigo Almeida
Participante
O comando está com o nome da tablespace?

Abraços,

Rodrigo Almeida
Autor

Posts

Visualizando 15 posts - 16 até 30 (de 33 do total)

← 1 2 3 →

Você deve fazer login para responder a este tópico.