Menu de navegação

[armandovelosoParticipante]

Pessoal,

abaixo seguem o comando que estou executando pra coletar estatisticas do banco e o erro apresentado:

==============================
BEGIN dbms_stats.gather_table_stats(‘OWNER’,’TABELA’, degree=>8, cascade=>true); END;

*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
==============================

Para todas as outras tabelas desse banco (mais de 300), a coleta de estatistica nao apresenta erro.

Antes eu rodava um comando apenas para coletar de todo schema (dbms_stats.gather_schema_stats(‘SCHEMA’, degree=>8, cascade=>true);), mas ao perceber que nao estava completando todas as tabelas, gerei script para executar um tabela de cada vez, entao encontrei o problema acima, apenas numa tabela especifica.

Obrigado![/b]

[vieriParticipante]

diminui o paralelismo(degree)
para 2 ou 4. 8 é um valor muito alto.

[armandovelosoParticipante]

Usei degrre=>2 e nada.. mesmo erro!

======================
BEGIN dbms_stats.gather_table_stats(‘OWNER’,’TABELA’, degree=>2, cascade=>true); END;
*
ERROR at line 1:

ORA-03113: end-of-file on communication channel

Usei tambem sem o parametro “degree” e deu o mesmo erro…

A demais tabelas do banco nao dao problema algum…

[CleitonHanzenParticipante]

Opá…

Olha o arquivo alert.log e ver q erro q tá dando (provávelmente algum ORA-7445 ou ORA-600)…..Lembrando ainda q Paralell Query só funciona em Enterprise Edition…se estiver com Standard nem espefique o parâmetro degree..

[armandovelosoParticipante]

Cleiton,

não é gerado nada no alert.log!

Mesmo sem especificar o degree, o erro continua.

[armandovelosoParticipante]

Será que expotar a tabela, dropa-la e depois importa-la, nao resolve?

Sei que é um procedimento “trabalhoso”, pois precisa apagar todas as FKs que referenciam essa tabela (apenas um DISABLE nao da certo), mas se essa for a única solução…

[CleitonHanzenParticipante]

Opá…

Com o ANALYZE tá dando erro também?

Faz aí:

analyze table owner.tabela validate structure;
analyze table owner.tabela validate structure cascade;
analyze table owner.tabela compute statistics;

[armandovelosoParticipante]

Opa, Cleiton…
Apesar de no export nao acontecer problema nenhum em bloco…
Acho que vc acertou…

Veja:

analyze table OWNER.TABELA validate structure
*
ERROR at line 1:

ORA-01498: block check failure – see trace file

Olhando o arquivo de trace, encontrei no inicio do arquivo (é enorme…),

algo que pode ajudar:

kdbchk: the amount of space used is not equal to block size

used=7812 fsc=0 avsp=743 dtl=8064

[CleitonHanzenParticipante]

Hehehe….

Tabela corrompida sempre é um stress e pior ainda, podem ser tantas coisas diferentes que causam isso……Recentemente tive um caso desses, que reiniciando a instância parou de ocorrer (Corrupção em Memória… 😆 ), mas já teve outros casos de ser corrupção física que tivemos que fazer restore do banco/tabela ou até mesmo usar o CTAS (quando não tinhamos backup)…

A solução vai depender mais da análise do caso…..hehehehe

[armandovelosoParticipante]

Orientado por esse site:
http://www.fors.com/velpuri2/Backup%20a … %20example

Fiz ate a parte que sugere a criacao de uma tabela populada com o rowid do bloco defeituoso:
create table temp_t1 as
select * from system.t1
where dbms_rowid.rowid_block_number(rowid) = XX
and dbms_rowid.rowid_to_absolute_fno (rowid, ‘SYSTEM’,’T1′) = YY;

Me surpreendeu o fato de a tabela ficar com 36 registros!
É uma tabela de dados dos EMPREGADOS… daí eu estou na dúvida do melhor procedimento a adotar, já que partir pra backup ta dificil, pq nao temos backup de 2 meses atrás (+ ou – esse tempo que nao fazia as estatisticas nessa tabela), backup mais antigo so o do fim do ano.. acredito nao ser uma boa ideia recorrer a esse backup.

Nesse link que coloquei acima ele segue 2 caminhos:

Fix: DBMS_REPAIR.FIX_CORRUPT_BLOCKS (ORA-1578)

E depois o skip: DBMS_REPAIR.SKIP_CORRUPT_BLOCKS

Se eu fizer isso, vou “perder” 36 registros de empregados?

[CleitonHanzenParticipante]

Opá…

Tenta fazer primeiro o CTAS direto….sem ser dessa forma…..sobre a quantidade de registos, faz um count na tabela (se tiver índice esses dois passos funcionam, se não tiver, daí é outra história….hehehe)

[armandovelosoParticipante]

Cleiton,
como assim “CTAS direto”?
Vc fala de CTAS te toda a tabela?

[CleitonHanzenParticipante]

Opá…

Isso mesmo….se conseguir e tiver tudo OK, faz um drop na “atual” e rename na nova… 🙂

[armandovelosoParticipante]

Cara,
na tabela gerada pelo CTAS, com o rowid (36 regstros) ja ficou com problema mesmo.
Se eu der um “select * from temp_empregado” da o mesmo erro q aparece no analyze:
ERROR:
ORA-03113: end-of-file on communication channel

Como vc falou, criei uma tabela com CTAS completa da original, criou na boa, com a mesma qtde de registros (1817 registros), mas da o mesmo erro com o “select *…”

[CleitonHanzenParticipante]

Opá….

Ki bom q deu certo…menos mal….heheheh

Mas o q tá bizarro é esse ORA-3113…..eu tentaria dar um flush na shared_pool ou até mesmo stop/start no banco….pq isso tá mais parecendo corrupção em memória….Vc chegou a ver com o DBV se os DBF´s estavam corrompidos?

[Autor]

Posts