Qual sua distribuição favorita para rodar banco de dados Firebird?
Enviado por Carlos (warmbooterΘhotmail·com):
“A FireBase, maior portal em português sobre banco de dados Firebird, quer saber qual a distribuição Linux preferida pelos usuários do Firebird no Brasil. Para participar da pesquisa, basta ir até o site da FireBase e votar na pesquisa, que está localizada na barra lateral direita da página. O resultado da pesquisa servirá também como guia para a elaboração/adaptação de novos instaladores da ferramenta de monitoramento de banco de dados Firebird – FB DataGuard, da IBSurgeon. Atenção: A pesquisa é destinada apenas a usuários do banco de dados Firebird.”
• Publicado por Augusto Campos em
2011-05-20
@brlinuxblog
Feed RSS
nao rode firebird
Nas últimas vezes que tentei usar, ok, faz um tempo. Continua sendo meio complicado.
Infelizmente acho que Firebird continua muito com a cultura windows, onde nasceu com delphi/interbase.
Ja rodei Firebird 1.5 com Linux e funcionou perfeitamente.
Na época que desenvolvia para ele não tinha do que reclamar…
Pessoal,
utilizo o firebird em diversas aplicações. Meu ERP, FreedomERP, inclusive roda em Firebird. Creio que o pessoal é meio cabeça fechada. A cultura windows é furada como decisão de uso do Firebird ou não. Para não me alongar, segue o link da explicação de “O porque o Firebird?” http://freedom.osns.com.br/redmine/wiki/freedom/Banco_de_Dados_Firebird#Porque-Firebird escrito por um colega da lista FreedomERP em relação a esse tipo de questionamento sobre Porque usar ou porque não utilizar outro DB. Não sou defensor de DB A ou B ou C… Sou um SysAdmin que implementa de acordo com as necessidades. E sobre a instalação, é tão fácil quanto o MySQL ou PostgreSQL. Como o Weber disse ai em cima, faz um tempo que não utiliza ou tentou utilizar, faz um teste :) segue a documentação do pessoal do Firebird ou até a documentação de instalação do FreedomERP http://freedom.osns.com.br/redmine/wiki/freedom/Banco_de_Dados_Firebird que detalha a instalação em Debian/Ubuntu/Slackware/CentOS/RHEL, etc… Creio que um SGBD utilizado por Nasa, Motorola, Nokia, IBM entre outras grandes corporações, não seja um software a ser colocado apreciação. Abraços!
Se o Firebird e o SQLite entrassem na Cúpula do Trovão, qual deles sairia vivo? =D
Tércio Martins
A cúpula do trovão não tinha regra, a não ser as que a Tina Turner decidisse.
Já se fosse uma luta de boxe ou MMA, não estariam na mesma categoria. O SQLite é um pena (ou algo abaixo disso se existir).
A única semelhança é que o firebird tem versão embedded também.
Kram3r
O firebird tem origem no windows e parece continuar dedicado a desenvolvedores Delphi (logo, só windows).
Tanto é assim que eu fui testar justamente o Firebird com uso embedded com aplicativos Freepascal no Linux.
Um trabalhão para tentar fazer funcionar. Sinal que não se anda investindo nisso para outra plataforma que não windows.
A documentação continua basicamente a mesma de quando eu usava a 1.5: Perto da inexistente. Continua a mesma coisa, um amontoado de artigos avulsos sobre temas esparsos. Só mudou a quantidade e foram adicionados artigos que cobrem versões novas.
Estou sendo duro, mas gosto do banco. Acho que ele tem seu valor como um meio termo entre algo muito leve, SQLite, e algo mais porrada, Postgres. Além do apelo de poder ser embutido ou não e migrar os dados entre esses ambientes.
Mas o projeto é meio bagunçado, e faz tempo.
Weber Jr.
Kram3r
“Para não me alongar, segue o link da explicação de “O porque o Firebird?” http://freedom.osns.com.br/redmine/wiki/freedom/Banco_de_Dados_Firebird#Porque-Firebird escrito por um colega da lista FreedomERP em relação a esse tipo de questionamento sobre Porque usar ou porque não utilizar outro DB.”
Eu li …
Olha, se fosse você até tirava aquele depoimento de lá. Mais queima o filme que qualquer outra coisa.
Não precisar de DBA, que seria o único diferencial real listado, é uma falácia.
Nenhum banco precisa de DBA em pequenas quantidades de dados, nem mesmo Oracle.
Já instalei sistemas que faziam instalação silenciosa de Oracle. Os clientes nem sabiam disso. Como eram poucos dados, não precisava mexer mesmo.
Quando a carga de dados, consultas e conexões/transações simultâneas começa a crescer, sem alguém para cuidar, o desastre é iminente.
@Weber Jr,
Onde trabalho usam firebird como banco de dados do software, bem, veio de legado do delphi, mas sobre ser vinculado ao windows isto é preconceito mesmo.
A instalacao no linux é estremamente simples onde vc instala pode pegar um tar.bz2 onde roda um script de instalacao, q instala um daemon pro xinet e pede pra colocar a senha de sysdba, apartir dai qq client em outra maquina ja pode usar o banco de dados.
Temos mais de 50 clientes rodando com o banco em firebird, quase a totalidade com linux, sendo os q sao windows nao tem opcoes de deixar maquinas dedicadas para um servidor linux. Uns sao estremamente grandes com 80gb, 50gb, 25gb.
Sobre carga e conexoes simultanes o que tem banco de 25gb agora esta com 280 conexoes ( sendo +150 maquinas diferentes) ao banco de dados.
Sobre DBA posso confirmar exatamente o q falado. Por padrao vc nao precisa de tunning nenhum no banco de dados, mesmo nestes grandes. A unica configuracao que fazemos é em clientes grandes de aumentar o numero de conexoes do xinetd onde em algumas disto limita o numero de conexoes simultaneas a um mesmo servico.
Rotinas de backup sao scriptadas, assim como de garbage colection. Ocasionalmente ocorre de certos sql ficarem “travadas” no server, mediante a ma construcoes de relatorio por parte de enduser, etc, mas mesmo nestes casos é possivel fazer script para regularmente matar processos rodando onde a outra ponta da conexao nao existe mais, isto em alguns casos, pois na maioria o fato de vc matar a aplicacao q chamou esta sentenca ja finaliza no lado do server. Com isto a nescessidade de dba eh praticamente zero, com o maior prb q temos é de eventuais diskfulls por excesso de backups feitos sem ninguem por parte do cliente se preocupar em tirar do server.
Uma coisa que é bem pratica do gerenciador é que (por padrao) todo banco de dados fica constante em um unico arquivo. Apesar de ser recomendado fazer por backup, de um modo rapido, para copiar um banco basta copiar um unico arquivo sendo em maquinas diferentes, ou na mesma para criar um banco de testes, etc
Para este banco funcionar nao se precisa nem registrar no banco ou colocar em um diretorio especifico (a nao ser se configurado um diretorio root base para bancos) pois o caminho e nome do arquivo pode ser colocado na conexao no client.
Isto facilita ate mesmo para suporte, onde em certos clientes com administradores de rede, nao dbas, fica facil de pedir copia do banco pedindo soh para ele enviar o arquivo para nos.
Acho que o Rodrigo já explicou bem o que já havia dito dentro do link que passei. Rodrigo, ótima explicação.
“Uma coisa que é bem pratica do gerenciador é que (por padrao) todo banco de dados fica constante em um unico arquivo.”
Não considero prático. Não trabalhar com arquivo de log pode ter um ganho enorme na performance de inserções simultâneas concorrentes, como é o caso. Mas se houver dano no SGBD a chance de recuperação é praticamente nula, o maior problema do FB, depois da lentidão em consultas.
Respondendo à pergunta da notícia, a melhor performance eu consegui no Red Hat.
@Marcos,
Firebird nao trabalha com arquivo de log, mas ele trabalha com multiplas versoes de records dentro do proprio database. Ao iniciar uma transacao, todo dado nao commitado é gravado como uma nova versao do record, mantendo a anterior no banco.. mesmo apos commitar este dado, a versao antiga nao eh removida se tiver transacao na qual este dado é importante.
Por exemplo, um backup inicia uma transacao, todo e qq operacao que é feita no banco, apos o inicio do backup nao vai ter importancia para ele pois a versao de records que o backup vai usar é a do momento de inicio da sua transacao. Somente apos que o dado antigo é totalmente desnescessario ele é marcado como dirty e a pagina de banco usada é liberada pra ser sobrescrita.
Em um eventual crash de servidor não existe a nenhuma nescessidade de log pra recovery, pq simplesmente o banco desconsidera as versoes de records nao commitadas dando auto rollback nelas, mantendo as versoes saudaveis.
“Firebird nao trabalha com arquivo de log, mas ele trabalha com multiplas versoes de records dentro do proprio database.”
Sim, isso provê ganho em inserções, mas é um desastre em recuperação de falhas. É muito mais fácil corromper um banco dessa forma.
Outra desvantagem é que o tamanho físico do banco de dados cresce muito mais rápidoii9
A grosso modo, o resultado é o mesmo de um arquivo de log.
Arquivo de log transaction, serve para guardar estado do banco anterior a transacao, ai em uma eventual falta de energia vc tem como saber exatamente o que foi efetivamente comitado e dar rollback no que nao foi.
O modo que o firebird faz de multi versionamento de recorde é o mesmo, simplemente transacoes incompletas sao descartadas e retornadas ao estado anterior naturalmente. Tem casos que isto nao salva que é qnd dados saudaveis (ja comitados) sao por alguma maneira corrompidos, mas ai já é um problema de hardware, onde uma eventual corrupcao de um arquivo de log ou de dados nao constantes nele da mesmo problema.
Sobre aumentar muito o banco não é realidade. A cada N transactions ou manualmente (prefiro configurar o cron manualmente para madrugada) o gerenciador faz um garbage collection, aonde pega todas as versoes de records ja nao visiveis por nenhuma transacao ativa e marca a pagina de dados dela como free para uso. Ex, o banco pode crescer gigas por uma transacao de insercao grande nao comitada, mas com o tempo o espaco usado por ela vai ser reaproveitado e vai demorar para ter um novo aumento de tamanho.