Diferença entre linhas encadeadas e migradas

Linhas encadeadas e migradas são explicadas nas Estruturas de armazenamento lógico do Guia de conceitos .

Uma linha migrada seria uma linha cujos dados da coluna foram completamente transferidos de um bloco para outro devido a uma atualização. O bloco original teria essencialmente apenas um "endereço de encaminhamento" armazenado para essa linha.

Uma linha encadeada teria partes de seus dados de coluna em vários blocos. O bloco original conteria os dados reais da coluna e um endereço de encaminhamento para o restante. (Você pode obter linhas encadeadas em mais de dois blocos.)

Ambos são implementados da mesma maneira no fundo, então são realmente dois aspectos da mesma coisa.

Observe também que, para tabelas com mais de 255 colunas, todas as linhas são tecnicamente encadeadas - uma "parte de linha" pode conter apenas 255 valores de coluna. O encadeamento pode acontecer no mesmo bloco ou com outros blocos, dependendo da disponibilidade de espaço (e não é particularmente "ruim" se todos os dados terminarem no mesmo bloco).

A única maneira, até onde eu sei, de obter dados precisos sobre o encadeamento de linhas é usar:

ANALYZE TABLE your_table [partition (your_part)] LIST CHAINED ROWS

Consulte Listando linhas encadeadas de tabelas e clusters .

Isso é potencialmente caro, toda a tabela precisa ser verificada. A coleta de estatísticas não preenche a CHAIN_CNTcoluna da dba_tablesvisualização. (Acho que pode ter acontecido em algum momento, mas não no 11.2, pelo menos.)

Você pode monitorar a estatística table fetch continued row¹v$sysstat ( ) para ver se uma consulta é afetada por linhas encadeadas ou migradas, mas não acredito que você possa ter essa métrica por sessão, então você precisa de um sistema silencioso para medir ou a leitura será "barulhento".

The Secrets of Oracle Row Chaining and Migration contém informações interessantes sobre linhas encadeadas e migradas, como você as mede e possíveis formas de corrigi-las.
Como sempre, não reconstrua tabelas ou altere parâmetros de armazenamento "só porque" você vê linhas encadeadas ou migradas. Faça isso apenas se você medir que está realmente causando problemas de desempenho.

_{¹ Das descrições das estatísticas :}

_{Número de vezes que uma linha encadeada ou migrada é encontrada durante uma busca}

_{A recuperação de linhas que abrangem mais de um bloco aumenta a E/S lógica por um fator que corresponde ao número de blocos que precisam ser acessados. Exportar e reimportar pode eliminar esse problema. Avalie as configurações dos parâmetros de armazenamento PCTFREE e PCTUSED. Este problema não pode ser corrigido se as linhas forem maiores que os blocos do banco de dados (por exemplo, se o tipo de dados LONG for usado e as linhas forem extremamente grandes).}

_{Consulte também Busca de Tabela por Linha Contínua .}

Uma maneira mais "proativa" de descobrir se você tem problemas com linhas encadeadas é usar o OEM e o Segment Advisor. (Administration –> Storage –> Segment Advisor -> Chained Row Analysis) O Segment Advisor é executado em um cronograma e procura por operações curiosamente longas que possam sinalizar um problema de linha encadeada. Em seguida, ele faz uma análise mais profunda durante a janela de manutenção do banco de dados e oferece a opção de corrigir o problema... mas prefiro corrigir o problema fora do OEM.

Para resolver o problema, você tem algumas opções. Lendo a resposta acima, é estranho que um documento recente da Oracle mencione fazer uma exportação/importação ... que funciona, mas provavelmente não é a opção mais rápida ou fácil.

Uma maneira muito mais rápida do que uma exportação/importação é fazer um "alter table table_name move;"...que reorganizará a tabela no mesmo tablespace. Isso também pode ser feito paralelizado. Depois disso, você precisará reconstruir todos os índices dessa tabela.

Outra opção (online) é usar dbms_redefinition. Isso é ótimo quando funciona, mas é mais complicado do que as outras opções.

Você também pode fazer uma inserção em uma nova tabela (inserir em new_table_name, selecionar * de table_name), renomear as tabelas para que a nova tabela tenha o nome antigo e, em seguida, reconstruir os índices.

Na minha experiência, a melhor maneira geralmente é alterar a tabela, a menos que você tenha restrições de capacidade de armazenamento.