[firebase-br] shrink database

[Eduardo Jedliczka]

Não seria muito mais simples realizar o parsing dos arquivos XML e gravar
em tabelas do tipo pai-> [chave-> valor] ?

Ainda teria o benefício de permitir o uso de índices para localizar/filtrar
os valores.

Outra forma seria implementar (embora não exista nativamente no FB) um
DICTIONARY (ter uma tabela de palavras e substituí-las antes de gravar
CLOB).

==========================
Eduardo Jedliczka
Curitiba - Pr
==========================


Em sáb, 15 de dez de 2018 às 14:44, Eder <edercotta em gmail.com> escreveu:

> 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."
> ______________________________________________
> 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
>