bloco corrompido

Marcio,

Consegui baixar os arquivos e estou analisando. Mas esqueci de falar, preciso do número de registros por bloco da área que está essa tabela.
Se tiver dúvidas olha no Data Dictionary para ver o nome da área e envia o arquivo .st.

Se puder enviar o tamanho do bloco do banco (4/8KB) ajuda também.

Marcio,

Você gerou os arquivos no banco de dados em que o dump está demorando um monte ou em um banco que já foi reorganizado?

Estou achando que a sequencia dos dados está boa demais.
Fiz uma simulação aqui com o índice primário (item-data) e um buffer pool pequeno, de 3 mil blocos, e a análise é praticamente perfeita, 99,3% de sequencialidade.

Melhor que este índice só o nr-ord-refer e ord-des. Mas mesmo em um buffer pool hipotético de 1 único bloco, a diferença é 17mil leituras apenas.
Considerando que tua tabela usa 2.498.524 blocos, é um número irrisório...



Você chegou a verificar a fragmentação dos arquivos deste banco no sistema operacional? Isto pode influenciar bastante o desempenho de leituras.
A gente acha que está lendo o arquivo sequencialmente, mas como ele está uma "zona" no disco, é muita leitura aleatória....

Marcio,

Sobre HP eu não manjo nada. Você tem que verificar com o administrador da máquina
Esse é o problema de usar essas máquinas alternativas, ninguém conhece isso

O rebuild dos índices que você citou não afetaria a análise, porque estamos analisando a ordem dos dados.
Mas se o rebuild demorou 6h, 40h para o dump nesse mesmo banco é muito tempo, tem algum boi na linha e não parece ser o banco... pode ser a gravação dos arquivos de dump no disco, algo assim...

Se quiser tentar para desencargo usa um dos outros 2 índices que citei antes (nr-ord-refer ou ord-des), mas eu não estou esperando milagres...
E se tiver memória ainda, faz dump com o banco proserve'd e usa um -B de 100mil.