Firebird no Linux
Autor: Antônio David | Publicado: 2011-11-11T02:53:00-08:00

&nbsp;Instalando e Removendo Firebird de Servidores Linux Primeiro baixo os instaladores abaixo:Firebird 01:&nbsp; SuperServer&nbsp; Firebird 02: Classic&nbsp;&nbsp;Lembrando que os links acima se tratam de serviços em 64bits.Vamos lá,Vamos fazer o download do firebird de sua escolha e vamos salvar em um diretório no Linux/home/Linux.
Agora vamos aos comandos:
Extrair o FirebirdCS ou FirebirdSS:#&nbsp;/home/Linux/&nbsp;tar &nbsp;-vzxf FirebirdCS-2.5.1.26351-0.amd64.tar.gz
Entrar no diretório extraído:#&nbsp;/home/Linux/&nbsp;cd FirebirdCS-2.5.1.26351-0.amd64
Executar o comando:#&nbsp;/home/Linux/&nbsp;cd FirebirdCS-2.5.1.26351-0.amd64/sh install.sh  

Será pedida uma senha digite: masterkey e aguarde a finalização da instalação.
Por padrão a porta a ser aberta para uso do firebird no Linux é a 3051Então digite:
#&nbsp; iptables -A INPUT -m multiport -p tcp --dport 3051 -j ACCEPT  

Removendo o firebird do Linux:
Vá até o diretório:# cd /opt/firebird/Bin  

Execute o comando:#&nbsp;/opt/firebird/bin/sh FirebirdUninstall.shAguarde e pronto! O aviso de removido será dado.
Buscando informações em sites relacionados ao serviço de firebird vejam o que encontrei dentro do site: http://www.sinatica.com/&nbsp;
Firebird – SuperServer, ClassicServer ou SuperClassic?Uma das decisões mais importantes na  implantação de um servidor Firebird é a escolha do tipo de servidor. A  escolha é feita na tela do instalador.Se já é difícil fazer uma escolha bem  informada hoje, espere até o lançamento do Firebird 2.5. Serão 3 opções.  SuperServer, ClassicServer e SuperClassic.As grandes diferenças entre eles estão  no cache de páginas e no modo como o servidor gerencia o processo e os  threads que executam seus comandos.SuperServerNo Super Server existe apenas um cache de páginas que é compartilhado por todas as conexões.Por ser compartilhado, este cache é  muito eficiente. Quando vários clientes acessam as mesmas áreas do banco  de dados ou quando algumas tabelas são muito mais acessadas que outras,  todos os clientes se beneficiam de um cache grande e bem preenchido.Por exemplo, quando o cliente A executa:SELECT NOME FROM CLIENTES WHERE CODIGO = 1;algumas páginas relacionadas a tabela CLIENTES e ao índice da chave primária CODIGO são carregados para o cache.Quando o cliente B executa:SELECT NOME, ENDERECO, TELEFONE&nbsp; FROM CLIENTES WHERE CODIGO = 2;ele se beneficia do cache compartilhado porque as páginas que este comando precisa já estão no cache.Note também que existe apenas um único processo onde todos os clientes se conectam.Veja no diagrama:O SuperServer sofre de problemas de  escalabilidade. Se você instalá-lo num computador com mais de uma CPU (o  que é bem provável hoje em dia) ele vai usar apenas uma delas1. Isto não é problema para instalações pequenas ou ambientes onde o servidor terá outras atividades além do banco de dados.Por exemplo, você tem um servidor  dual-core e quer usá-lo como servidor de arquivos, web, impressão e  banco de dados. Não é problema que o Firebird use apenas uma CPU porque o  servidor terá outras atividades para ocupar a outra CPU. E você ainda  terá o benefício de usar um banco de dados leve e ágil, que consome  poucos recursos do servidor.Mas para operações grandes, em que você  quer que o banco de dados aproveite cada ciclo das CPUs do servidor, o  SuperServer pode ser frustrante.1  Exceto se você tiver mais de um banco de dados. A partir do Firebird  2.5, o Superserver consegue usar mais de uma CPU desta maneira. Uma para  cada banco de dados. Se você tiver apenas um banco de dados o limite  ainda se aplica.ClassicServerNo Classic, cada cliente tem um cache próprio e está conectado a um processo dedicado.O cache dedicado é muito menos  eficiente. Se dois clientes acessam a mesma área do banco de dados, esta  área será copiada no cache de cada um deles. Usando o exemplo anterior,  quando o cliente B executasse seu comando, ele não teria o benefício de  um cache já preenchido e o Firebird precisaria acessar o disco  novamente para responder.Além do mais, a sincronização entre os  caches é feita através do disco. Isto aumenta consideravelmente o custo  de I/O para ambientes de alta concorrência.Veja no diagrama:Um grande benefício deste modelo é a  resiliência oferecida pelos múltiplos processos. Se um deles tiver  problemas, apenas o cliente conectado a ele será desconectado. Todo o  restante do banco de dados continua funcionando normalmente.O outro grande benefício é a  escalabilidade. Acredito que esta característica seja a responsável por  boa parte das instalações do ClassicServer. Mesmo em casos onde o cache  dedicado produz resultados inferiores ao cache compartilhado do  Superserver, a escalabilidade do ClassicServer compensa. Basta adicionar  mais hardware e pronto, seu servidor fica mais rápido.Mas esta escalabilidade não vem de  graça. Imagine que você tem 200 clientes simultâneos. São 201 processos,  um para cada cliente e mais um para ficar ouvindo novas conexões. Seu  sistema operacional deve gerenciar todos estes processos e mantê-los em  sincronia. Eles consomem muitos recursos de kernel e isto significa que  ele pode ser relativamente lento.Veja neste exemplo: Firebird 2.5 Alpha 1 Classic com 7 clientes conectados. São 8 processos, 18 threads, 1050 identificadores.SuperClassica partir do Firebird 2.5A equipe de desenvolvimento decidiu usar  o Firebird Classic Server como base para construir o Firebird 3.0, que  será totalmente compatível com SMP. O SuperClassic é o primeiro passo  nessa direção. É uma evolução do Classic Server que resolve o maior  problema que o Classic Server tem: Todos aqueles processos o deixam  lento e tornam a manutenção mais difícil.Bem-vindo ao SuperClassic: Um único processo com cache dedicado.Olhando assim e levando em consideração o  nome, parece um híbrido entre o Classic e o Super, mas não é. O que  fizeram foi encapsular todos aqueles processos em threads. Agora cada  cliente tem um thread dedicado dentro de um único processo.Criar centenas de threads é muito mais  barato que criar centenas de processos e não existe perda de  escalabilidade. A sincronização entre os caches pode ser feita  diretamente em memória, o que reduz o custo de I/O. E outros controles  que antes eram inter-processo agora são inter-thread, muito mais  rápidos.Veja exemplo comparável ao Classic:  Firebird 2.5 Alpha 1 SuperClassic com 7 clientes conectados, 1 processo,  6 threads, 172 identificadores.ConclusãoEsta compilação dos casos mais comuns de  uso é uma sugestão e serve apenas como guia, um ponto inicial na sua&nbsp;  escolha. A sua instalação pode ter detalhes próprios que não foram  abordados aqui.SuperServer Bases de dados pequenas ou pouco acessadas
Servidores pequenos
Ambientes onde o cache compartilhado é mais vantajoso que a escalabilidade do SuperClassic
ClassicServer Ambientes onde a estabilidade é a maior preocupação
 Servidores multi-processados
 Grandes bases de dados com centenas de usuários
SuperClassic Servidores multi-processados
 Grandes bases de dados com centenas de usuários
 Ambientes onde o cache dedicado é mais vantajoso que o cache compartilhado do SuperServer
 Ambientes onde o ClassicServer já não consegue escalarFonte: http://www.sinatica.com/