[firebase-br] shrink database

[Eder]

Boa tarde Gladiston  Santana,

Obrigado pela colaboração.

A base de dados onde armazenamos os arquivos .XML já é separada no volume
principal.

O que tem me preocupado é o crescimento desproporcional ao tamanho em disco
dos arquivos .XML.

Pretendo fazer alguns testes alterando o tamanho da página para 8K.

Abraços!

Em sex, 14 de dez de 2018 às 11:28, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Uma sugestão, se seus dados sistêmicos estão no mesmo database fisico com
> os blobs, e esses blobs são raramente utilizados - ou estão mais para serem
> arquivados -, talvez você possa analisar a separação em databases fisicos
> distintos.
> Aqui, eu separei uma tabela de imagens do restante dos dados, ficando um
> database físico só para as imagens.
> Fiz isso porque as imagens não tinham tanta movimentação, tava mais para
> arquivamento mesmo, contudo exercia grande impacto no tamanho do database e
> consequentemente no backup.
> Já que me faltava uma jóia do infinito para mudar a realidade, então fiz
> profunda meditação zen e conclui que seria melhor separar os databases para
> resolver o tempo de backup, pois o tempo de backup era sofrível. Eu sou
> meio paranóico com isso!
> Depois de algum tempo, percebi que separa-los foi uma boa ideia porque o
> backup dessas imagens pode ser diaria ou semanal enquanto os dados que são
> mais vitais são resolvidos em intervalo de horas.
> Mais tarde, repeti a mesma técnica e tirei dos dados vitais o que seria
> banco de dados de ceps e cnpj´s que também se tornaram externos.
> Para não ter que fazer meu programa se conectar a 3 ou 4 databases
> diferentes, eu criei uma procedure no banco principal que faz a
> chamada/consulta nos outros usando:
> [for] execute statement ... on external
> e apesar de não ser performático, pois cada chamada perde o tempo de 1s
> para fazer a conexão externa, mas resolve o incomodo de mudar meu programa
> para manter conexões simultaneas a databases distintos - eu até poderia ter
> feito isso, mas não estava disposto.
> Também o banco de imagens tem um tamanho de página mais adequada para o
> tamanho de blob, pois anteriormente minhas páginas eram de 16k, então
> guardar pequenas figuras que eram menores que 4k desperdiçava outros 12k em
> disco.
> Enfim, foi muito boa a mudança e talvez você possa analisar se isso seria
> bom para você também.
>
> []´s
>
> Em qui, 13 de dez de 2018 às 13:27, Eder <edercotta em gmail.com> escreveu:
>
> > Obrigado pela resposta.
> >
> > No caso mencionado anteriormente a tabela é exclusiva para BLOB.
> >
> > Utilizamos o campo BLOB para armazenar arquivos .XML de NFs.  O detalhe é
> > que a tabela possui dois campos BLOBs, XML de envio e retorno.
> >
> > Fiz alguns testes para identificar o impacto desta tabela no tamanho do
> > banco.
> >
> > O tamanho físico do banco era de 16GB.
> > Page Size configurado com valor 4096.
> >
> > O Database Analyst mostrou que o size da tabela é 748mb.
> >
> > Fiz BACKUP e RESTORE no banco, reduziu de 16GB para 13GB em disco. O
> > Database
> > Analyst mostrou que o size da tabela caiu para 723mb.
> >
> > Para entender o quanto essa tabela representa em disco, executei o DROP,
> > realizei BACKUP e RESTORE no banco. O tamanho do banco reduziu de 13GB
> para
> > 2GB.
> >
> > Conclusão: a tabela está ocupando cerca de 11GB em disco.
> >
> > Se puder me apontar uma direção para reduzir o tamanho em disco,
> > agradeço muito.
> >
> > Abraços!
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas:
> http://www.firebase.com.br/pesquisa_lista.html
>


-- 

*Eder Pelinçari*
Software engineer / Project Manager
"Se você esperar pelas condições perfeitas, nunca vai fazer nada."