Olá Sergio,
Você não pode mudar só um pouco a estratégia do seu backup/restore?
Por exemplo, primeiro você faz uma restauração somente do esquema da
tua base, tabelas, constraints e afins.
E depois, como segunda etapa, restaurar somente os dados? Pode ser
uma possibilidade.
Alguns outros detalhes, você não está com nenhuma trigger sendo
disparada nessa tabela ou em alguma outra? Não tem nenhum lock travando
esta tabela, ou uma referência circular?
Qualquer coisa, você pode postar o problema para o pessoal da lista
oficial do PG, talvez a "performance" ou a "admin" possam lhe ajudar.
Até mais.
Fernando Simon
Sergio Medeiros Santi wrote:
> Pessoal:
>
> Ontem as 12 horas eu larguei a restauração novamente. As novas
> informações são as seguintes:
>
> Tempo total de restauração olhando pelos logs registrados: 14:03 (14
> horas!)
> Tempo total da aplicação da constraint listada abaixo: 12:13 (12 horas!!!)
>
> Olha eu agradeço as sugestões de fazer backup "físico", das
> informações de tempo de outros usuários, mas eu continuo achando que
> tem algo errado no meu caso. Uma única constraint consumindo 12 horas
> de um total de 14 horas necessários! Acho demais. Outro fato
> interessante é que, dentro do que acompanhei da aplicação da
> constraint o consumo de processador é baixíssimo (menos de 10% em um
> Xeon 2.13), bem como apresenta baixo consumo de memória e baixa
> atividade de disco. Parece simplesmente que esta etapa da restauração
> está fazendo corpo mole, operação tartaruga.
>
> Também já citei o tamanho da base (30G ao fazer o backup e 21G após a
> restauração) e o número de registros das duas tabelas envolvidas
> (NotaItem com 20.000.000 de registros e Produto com 40.000 registros).
> Pelo nível técnico das discussões que acompanho nesta lista eu
> esperava algum questionamento, ou sugestão mais relacionado ao
> problemas, ou ao menos uma afirmação de que os tempos que citei são
> normais (o que não acredito).
>
> Alguém sabe me dizer o que justifica que uma única contraint consumir
> tanto tempo? A mesma tabela aplica outras constraints em muito menos
> tempo (NotaItem com 20.000.000 de registros e NotaFiscal com 1.400.000
> registros) por exemplo, consome 4 minutos. Existe alguma forma de
> fazer um explain analyse de uma constraint?
>
> Pelo nível das discussões que tenho acompanhado estou estranhando a
> falta de comentários "profundos" sobre este caso que tenho estudado a
> uns 6 meses. Este caso me é bastante instigante e não consigo apenas
> me conformar com a situação. De tempos em tempo eu a retomo. Ou
> resolvo isto ou acho uma explicação plausível sobre o caso. Não
> pretendo concluir que este fato deva-se a "Vontade de Deus" e que devo
> me resignar.
>
> Não vou jogar isto para baixo do tapete!
>
> Sergio Medeiros Santi
>
>
>
> Sergio Medeiros Santi escreveu:
>> Gente:
>>
>> Essa discussão sobre o backup "físico" foi bem elucidativo, mas
>> voltando a origem da thread ... Ninguém, além de mim, acha estranho
>> que todo o processo de restore consuma 12 horas, sendo que uma única
>> contraint consuma 3/4 deste tempo e que o resto criação da estrutura,
>> carga dos dados, criação de indices, criação de todas as demais
>> constraints consuma apenas 1/4 do tempo?
>>
>> No exemplo abaixo eu já verifiquei e existe índice pelos dois campos
>> envolvidos um deles é a própria primary key.
>>
>> ALTER TABLE ONLY "NotaItem" ADD Constraint
>> "NotaItem_CodigoProduto_Produto_FK" FOREGN KEY
>> ("CodigoProdutoItem" REFERENCES
>> "Produto" ("CodigoInternoProduto") MATH FULL ON UPDATE RESTRICT
>> ON DELETE RESTRICT;
>>
>> Posso até estar enganado, mas tem que haver uma explicação para este
>> tempo absurdo ou alguma mancada muito grande.
>>
>> Abraços,
>> Sergio Medeiros Santi
>>
>>
>>
>>
>> __________ Informação do NOD32 IMON 2719 (20071212) __________
>>
>> Esta mensagem foi verificada pelo NOD32 sistema antivírus
>> http://www.eset.com.br
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>> __________ Informação do NOD32 IMON 2719 (20071212) __________
>>
>> Esta mensagem foi verificada pelo NOD32 sistema antivírus
>> http://www.eset.com.br
>>
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
