Menu de navegação

[jspaulonciParticipante]

Bom dia pessoal, estou com uma dúvida.
O assunto é linhas migradas ou encadeadas.

Fiz o seguinte, de acordo com o livo Manual do DBA Oracle Database 11g
(apesar de eu estar usando 10g)
Esse livro é da Oracle Press, o autor é Bob Bryla e Kevin Loney.

Eu simulei linhas migradas em uma tabela.
Inseri 6 milhões de linhas , no insert, um desses campos estava nulo,
depois fiz o update nesse campo null para as 6 milhões de linhas, com uma string grande.

Então , rodei o comando
analyze table clientes list chained rows into chained_rows;

Esse comando populou a tabela chained_rows (já previamente criada)
Até aí tudo bem

Entaum eu execute o comando
alter table clientes shrink space;

O Oracle executou , mas ele não diminuiu o espaço alocado na dbs_segments para a tabela clientes e, depois que rodei o comando
analyze table clientes list chained rows into chained_rows; o Oracle populou novamente a tabela clientes.

Vocês sabem o que eu fiz de errado ?

Obrigado

João Paulo Spaulonci

[jspaulonciParticipante]

Corrigindo pessoal…..

Depois que eu fiz o shrink space eu rodei o comando analyze table clientes list chained rows into chained_rows; somente para constatar se o Oracle tinha realmente organizado as linhas que estavam migradas, e constatei que não, pois a tabela chained_rows ficou populada depois que rodei o analyze.

Obrigado

Spaulonci

[vieriParticipante]

tente esse mini how-to Paulo:

LINHAS-ENCADEADAS=>>CHAINED_ROWS

select table_name,
num_rows,
chain_cnt,
avg_row_len,
pct_free,
pct_used
from dba_tables
where chain_cnt > 0
order by chain_cnt desc;

ELIMINANDO AS LINHAS ENCADEADAS

Antes de começar o processo, verifique se em seu Banco existe a tabela CHAINED_ROWS,
caso ela não tenha sido criada em outro momento,
faça isso agora através do script “ORACLE_HOME/rdbms/admin/UTLCHAIN.SQL”

**Atenção: este processo deve ser preferencialmente executado sem que outras sessões
estejam sendo executadas no momento,
para que com isso possamos garantir a integridade dos dados,
isso é facil de obter colocando o
banco em RESTRICT MODE ou simplesmente bloqueando o
objeto em questão ( LOCK TABLE ).

Iniciando o processo:
analyze table xx list chained rows into CHAINED_ROWS;
create table temp_xx as select * from xx
where rowid in (select head_rowid from chained_rows
where table_name = ‘xx’
and owner= ‘OWNER’);

Obs.: Neste passo transferimos os dados para uma tabela auxiliar para nos ajudar com o processo de eliminação das linhas encadeadas.

delete from xx
where rowid in (select head_rowid from chained_rows
where table_name = ‘xx’
and owner= ‘OWNER’);

insert into xx select * from temp_xx;

drop table xx_temp;

[vieriParticipante]

A idéia do srink table,
á compactar objetos que estejam fragmentados.

Linha encadeadas não é bem uma fragmentação,
e um “estado” qu se encontra uma linha que é muito alterada e qcaba pertencendo a diversos blocos, sem usar toda sua totalidado (dos blocos).

Ai ao invês de carregar por exemplo 100blocos para memôria numa consulta levaria 150…

para eliminar esse linhas somente reconstruindo elas.

já o shrinl ele não reconstrui, ele aglutina extents vazios..

acho que é por ai…

Fragmentação não é meu forte .. eu as elimino mais internamente
ainda tenhu algumas icognitas.

[jspaulonciParticipante]

Obrigado Vieri.

[Rodrigo AlmeidaParticipante]

Os principais fatores que podem ocasionar migração de linhas é a configuração utilizada para PCTFREE e PCTUSED, eles que informam se a linha será migrada ou não de acordo com a operação DML.

O shirink é apenas para eliminar as fragmentações sobre os extents do segmento, como o coalesce nas tablespaces (que não funciona muito diga-se de passagem)!

Se mexer com essas configurações, irá conseguir ver bem os resultados que deseja.

Abraços,

[jspaulonciParticipante]

Existe alguma metodologia para saber qual será o pctfree ideal para uma tabela ?

Abraços

Spaulonci

[Autor]

Posts