Guia Firebird 3 Rev1 - 01

1
Guia de Migração para o Firebird 3

1ª edição – 2016
Autor: Carlos Henrique Cantu
Piracicaba – São Paulo
Copyright 2016 © Carlos Henrique Cantu

Todos os direitos reservados pelo autor.
Nenhuma parte deste livro poderá ser reproduzida, transmitida e/ou

gravada por qualquer meio eletrônico, mecânico, por fotocópia e
outros, sem a prévia autorização, por escrito, do autor.
Edição, diagramação, finalização e publicação:

Carlos Henrique Cantu
Revisão 1.01
2
Índice
Índice ........................................................................................... 2
Dedicatória .................................................................................. 5
Agradecimentos........................................................................... 6
Prefácio ..................................................................................... 11
Introdução ................................................................................. 12
Ícones usados ............................................................................ 13
Erratas ....................................................................................... 14
Noções básicas, mas essenciais! ............................................... 15
SuperServer vs. Classic vs. SuperClassic .............................. 16
Classic (CS)....................................................................... 18
SuperServer (SS) ............................................................... 19
SuperClassic (SC) ............................................................. 20
Embedded .......................................................................... 21
Qual arquitetura escolher?..................................................... 22
Arquitetura 32 vs 64 bits ....................................................... 24
Instalando o Firebird 3 .............................................................. 26
Instalando o Firebird 3 no Linux ........................................... 27
Instalando o Firebird 3 no Windows ..................................... 35
Arquitetura desejada.......................................................... 40
Serviço ou Aplicação?....................................................... 41
Iniciar automaticamente .................................................... 41
Biblioteca cliente (fbclient.dll) .......................................... 41
gds32.dll ............................................................................ 41
Autorização para cliente legados ...................................... 42
Verificando se o Firebird está em execução ..................... 44
Instalação via Zip Kit ........................................................ 47
INSTSVC .......................................................................... 47
INSTREG .......................................................................... 49
INSTCLIENT .................................................................... 49
Migrando uma base de dados já existente, para o Firebird 3 .... 51
Porque é necessário “migrar” a base de dados? .................... 52
ODS (On Disk Structure) ...................................................... 53
Testando a integridade da base de dados com o gbak ........... 54
Problemas com a codificação de caracteres .......................... 56
Certificando sua metadata ..................................................... 58
Índice
3
Migrando a base de dados para o Firebird 3 ......................... 62

Migrando servidores 24x7..................................................... 63
Como acelerar o processo de backup/restore........................ 64
Usuários no Firebird 3 ............................................................... 66
Usuários locais ...................................................................... 68
Senhas ................................................................................... 70
Inicializando a base de dados de segurança .......................... 71
Gerenciamento de usuários via SQL ..................................... 73
Criando usuários................................................................ 74
Alterando usuários ............................................................ 76
Removendo usuários ......................................................... 76
Tabelas sec$users e sec$user_attributes................................ 77
Preparando um script para inserção de usuários no novo
servidor.................................................................................... 79
Protegendo os dados armazenados ............................................ 84
Criando um ambiente seguro ................................................ 86
Criptografando a base de dados ............................................ 87
Conclusão .............................................................................. 89
Melhorias no protocolo de comunicação .................................. 90
Criptografia dos dados trafegados ......................................... 91
Compactação do tráfego ........................................................ 94
Melhorias para uso em redes de alta latência ........................ 95
String de conexão .................................................................... 100
Sintaxe “legada” .................................................................. 101
Sintaxe baseada em URL .................................................... 103
Endereços IPv6.................................................................... 106
Firebird 3 e aplicações legadas ............................................... 107
Aplicações feitas em .NET .................................................. 108
Aplicações usando Jaybird .................................................. 109
Tipo lógico (boolean) .......................................................... 110
Conectando o FB 3 usando uma fbclient antiga .................. 110
Performance de queries ....................................................... 111
Palavras reservadas ............................................................. 112
Manipulação de Tabelas de Sistema (RDB$...) .................. 113
Testando as Queries de suas aplicações .............................. 115
Obtendo o número de conexões via mon$attachments ....... 116
Apêndices ................................................................................ 118
Macros ................................................................................. 119
Índice
4
Entradas de configuração .................................................... 120

Glossário ................................................................................. 123
Índice
5
Dedicatória
Este livro é dedicado à minha esposa Elizabeth, minha filha

Larissa, e aos meus pais, Carlos e Sônia.
Dedicatória
6
Agradecimentos
Não posso deixar de começar agradecendo todos que participaram
da campanha de financiamento coletivo, possibilitando que esse livro
fosse escrito - obrigado pela confiança!
Ter escolhido o Firebird como principal (e hoje único) SGBD
usado nas minhas aplicações, me proporcionou ter contato com
pessoas do mundo todo, seja através de e-mails, chats ou mesmo
pessoalmente, nas conferências internacionais e no Firebird Developers
Day. Muitas dessas pessoas acabaram se tornando grandes colegas, e
vários foram parte importante na solução de dúvidas durante o
processo de escrita desse Guia de Migração.
Sendo assim, meu agradecimento para os core-developers Vlad
Khorsun, Alex Peshkov e Dmitry Yemanov, por estarem sempre dispostos
a responder minhas dúvidas, Jiří Činčura e Mark Rotteveel pelos
esclarecimentos nas questões do .NET Provider e Jaybird, Paul Reeves,
responsável pelo instalador do Firebird para Windows, Alexey
Kovyazin e Dmitry Kuzmenko, pela parceria de longa data que acabou se
tornando uma forte amizade, e Ivan Prenosil, pelas longas conversas
sobre temas em comum, que muitas vezes foram além do Firebird.
Obviamente, Ann Harrison, pela constante simpatia e por estar
sempre disposta a ajudar (no que for preciso), além de revisar a versão
em inglês desse guia, e seu marido, Jim Starkey, por ter criado o
InterBase© e, portanto, possibilitado a existência do Firebird. Jederson
Zuchi e Marcelo Daibert por ajudarem com a revisão do livro e, por
último, Adriano dos Santos Fernandes, por ser o único brasileiro
participando como desenvolvedor do Firebird.

Março/2016
www.firebase.com.br / blog.firebase.com.br / www.firebirdnews.org

www.supercontrol.com.br / www.warmboot.com.br
Agradecimentos
7
Segue a lista de pessoas/empresas (em ordem alfabética, dois

participantes por linha) que participaram da campanha de
financiamento coletivo que possibilitou que esse Guia fosse escrito:
Acesys Tecnologia em Adilson Pazzini

Sistemas Ltda
Adriano Wolff Alberto Ricardo Gonçalves de Souza
Alex Antunes da Silva Alexandre Chaves Martins
Alexandre de Souza Pinheiro Alexandre G. Camilo
Alirio Botelho Junior Aloisio Sampaio Cairo
Americo Belmiro de Souza Amilcar Coelho de
Neto Vasconcellos
André Fernando Piasentin Andrei Luis dos Santos
Angelo Ricardo Miquelin Neto Anônimo
Anselmo Souza Antonio Carlos de Moura
Antonio Carlos Nunes Junior Ap Engenharia de Software
Aparecido dos Santos Silva Ari Rodrigues da Silva
Ari Tadashi Sato Arielton Lima
Artur Bezerra Artur Moreira
Beneval A. P. Junior
Ascont Sistemas
Carlos Alberto Santa Clara Carlos Antonio Morcerf
Carlos do Nascimento Filho Carlos E. Tré
Carlos Eleutério dos Reis Carlos Luiz Francisco
Carlos Rempto Carsoft Sistemas
CF Company Desenvolvimento de Software
Casasoft desenvolvimento de
Sistemas Ltda
Chrystian Sweick Silva Cigo Software de Gestao
Claudio Brasileiro Pimenta Cleverson Ruivo da Silva
Cristiano Schenatto D&O Sistemas
Daisson André dos Santos Daniel Alves Qualhato
Daniel Simões de Almeida Daniel Yamamoto

Darcy Luiz Muller Daré, Gimenez e Cia Ltda Me
Dari Junior - DSoft Solutions data C Informática
Delcy Dias Diassis Bonfim Macedo
Diego Fernandes de Souza Dimas Fernando Braga
Dirceu Altair Henchen Dorival da Silva Reis
Dream Sistemas Dsin - Tecnologia da
Informação
Eder Paz
Eder Laudelino Polizel
Edgar da Silva Oliveira Edison Kemerich de Brito
Edivaldo Venancio da Silva Edmar de Oliveira Frazão
Agradecimentos
8
Eduardo Brigoni Eduardo Sório Neto
Eduardo Suruagy Eduardo Trevisan
Eldon Rodrigues Aquino Eney Duarte Gomes - Versátil
Informática
Erick A M P
Erick Figueira
Erik Fabiano Elias Fabiano de Oliveira Prado
Fábio Albano Fábio Henrique Guimarães
Fábio Henrique Pereira do Fabio José Pandim
Nascimento
Fabrício Carvalho de Matos Fernando Oliveira Pereira
Fernando Pimenta Fernando Quartarollo
Flavio Hermes Francisco Carlos Rodrigues
Francisco Nilson Brasil da Costa Francisco Rogeres Sousa de Melo
Francisco Schimitt
Fusiontech® Sistemas
Genésio Becker George De Luca
Gerasoft Informática Ltda. Giga Informática Dracena Ltda -
Me
Gilberto S Moura Gilson Inacio do Carmo
Gilson Peloso Gleisson Leal
Grupo Acert Guto (Gutemberg Lima Sampaio)
Hélio José Almeida de Oliveira Helton Alves Costa
Hercules Gomes Cangussu Hugo Eyng
Hugo Fabrício Gonçalves e Silva Humberto Mendes
Hyperbyte Informática IBS Sistemas
Idez Sistemas Infomatte Sistemas e
Consultoria
Ismael da Silva Marques Ivan José de Mecenas Silva
Jacson Vilson Meyer Jardel Thomas
Jederson donizete Zuchi Jéter Rabelo Ferreira
Joao Batista Dias da Cruz João Bosco dos Santos
Joao Carlos S. Santos João Marcelo Collar
Joao Rodrigues dos Santos Jorge Rocha Filho
José Alberto Ferrão Silva José Antonio Bonna
José B.Moreira Jose Bezerra
Jose Helder Camurca Junior José Henrique Godoi Alves
José Nazareno Freire Neto Jose Nilton Pace
Jose Pereira de Souza Júlio César Andrade dos Anjos
Julio Cesar Mazoni Kelver Merlotti
Keysolution Kk Borges BH
Leandro Bertasso
Kleberson Toro Vidal
Agradecimentos
9
Leandro Irgang Leonardo Wascheck –

Intercamp Sistemas S.A.
Limber Software(Ronaldo Loercio Luiz Relly
Bett e Fernando Fiorentin)
Loercio Luiz Relly Luciano Carneiro dos Santos
Luis Paulo Alves Rodrigues Luis Roberto Vieira
Luis Wagner dos Santos Luis Zen
Luiz Henrique Spies Luiz C. G. Mota
Luiz Filipe Meinecke Marcello Cainelli
Marcelo Augusto Cicogna Marcelo Duraes da Silva
Marcelo Estanislau Geyer Marcelo Rodrigues de Oliveira
Marcelo Silva Márcio Alves dos Santos
Marcio Bertelli Marcos Fábio Travain
Marcos Pegoraro Marcos Torres
Mario Aldo Serafim Inacio Mario Hollanda
Marlene Abi-Ali Mauri Lima de Oliveira
Mauro Gomes
Mauricio Junqueira
Melkcimar Francisco da Costa Menandro Dias Evangelista Neto
Miari Tecnologia Ltda Miguel Angel Romero Arcas
Nelson A. Servija Vechini Nelson Henrique Corrêa
Nepomuceno
Nelson Vilas Boas Nirlan E. Fundão
Orsini Vicari Aguiar Oscar Luiz Rodrigues de Oliveira
Osvaldo Goncalves da Cruz Júnior Otavio Benini - Benini
Informática E Sistemas
Otávio Ferdin Júnior Paulo Eduardo Strahler
Paulo Henrique Albanez Paulo Pereira Botelho
(PHA)
Paulo Roberto Lucas Lázaro Paulo Santana
Pedro Santo André Neto Prevedello Sistemas Ltda
Primesoftware Rafael Moreira Neves
Rc Equipe Em Informática Com Reginaldo José Fiomano
E Serv Ltda
Renato Miranda Renato Piovesano Bartolmei
Ricardo da Silva Almeida Ricardo Faria Beatriz
Robert de Godoy Barbosa Roberto Couto dos Santos
Roberto Keri Robson Ferreira Gomes
Rodrigo Belmiro Rodrigo Mourão
Rogerio deckert Zek Rondinely de Souza Soares
Roubledo demiam Gasoni Rubens Moraes Santos
Rudar Informatica Ltda Rui Richard Blaese
Agradecimentos
10
Saac.Software Sady Moreira

Samuel Santana dos Santos Saul Godino da Silva Filho
Sergio de Siqueira Silbeck Sistemas
Siro Costa Marques
Staff Consultoria Em
Informática Ltda
Sysbase Informática Ltda Syscon Tecnologia - Raitecsul
Syslife Sistemas Systemar Informática Ltda
Technosystem Assessoria E Sistemas Teodorico Nicolau Rodrigues Junior
Tham Informática Ltda Thiago Falcao Pereira
Valdemir Jacon Sanches Valdenir Rigonatto
Valdir Stiebe Junior Vinicius de Souza Barreira
Virtua Software Ltda VirtualSoft Informática e
Tecnologia Ltda
Wagner Machado Walfrido Cesar Cintra
Wander Pereira dos Santos Wanderson Pereira
Webdutos Wellington Rodrigo Sala
Whanderson Santos Rodrigues Wilton de Souza Magalhaes
Youngarts Sistemas
Muito obrigado a todos!

11
Prefácio
O Firebird 3.0 é a atualização mais significativa desde o
lançamento do Firebird no ano 2.000. As novidades vão desde o
aprimoramento da multitarefa, permitindo ao SuperServer aproveitar
multi-processadores simétricos, até melhorias na segurança com a
autenticação de usuários locais e tráfego criptografado de dados.
Antigos limites foram ampliados, como tamanho das senhas e o
número de transações aceitas antes de ser necessário um
backup/restore. As mudanças na interface incluem uma nova API
orientada a objetos, suporte a plug-ins que permitem estender as
funcionalidades do SGBD e providers que simplificam o
desenvolvimento da engine, reduzindo a complexidade de alternar as
formas de acesso entre embedded e baseada em servidor. O Firebird 3
é mais rápido, mais seguro, mais capaz e mais flexível do que qualquer
versão anterior.
Carlos Cantu prestou um grande serviço à Comunidade Firebird
explicando – em termos claros e precisos – como migrar aplicações
existentes para o Firebird 3. Carlos trabalha ativamente com o
Firebird desde seu lançamento, tendo lançado dois livros e escrito
dezenas de artigos sobre Firebird ao longo dos anos. Ele tem sido
fundamental apoiando e incentivando o uso do Firebird no Brasil
através do portal FireBase. Quando decidiu escrever um Guia de
Migração para ajudar os usuários no processo de migração para a
versão 3, mais de 200 empresas e desenvolvedores individuais
contribuíram financeiramente para viabilizar o projeto. O FB 3 é uma
grande versão! Dividindo as novidades em grupos é a única maneira
de entende-las e usá-las. O ponto de partida é explicar como mover
aplicativos e bases de dados de versões anteriores para o Firebird 3.
O Guia de Migração não substitui o Release Notes que acompanha o
Firebird 3, mas expande e explica uma parte do que o Release Notes
trata, reduzindo o potencial de erros e confusões ao migrar para o FB
3. Esse livro é o que você precisa para iniciar o uso do Firebird 3 com
sucesso.
Ann Harrison
Abril/2016
Prefácio
12
Introdução
Após um hiato de praticamente 10 anos, desde o lançamento do
meu último livro (Firebird 2), senti que era hora de escrever algo novo.
Sendo assim, nada melhor do que aproveitar o lançamento da tão
aguardada versão 3 do Firebird, e ajudar aqueles que pretendem
migrar seus servidores existentes para essa nova versão.
A história do Firebird 3 poderia facilmente ser enquadrada em um
dramalhão mexicano! Inúmeros atrasos, promessas não cumpridas,
mudanças de data, etc. fizeram até com que algumas pessoas
duvidassem de que, em algum momento, essa versão fosse realmente
ser lançada! Felizmente, isso está para acontecer - ou talvez já tenha
acontecido - dependendo de quando estiver lendo esse livro!
O Firebird 3 traz inúmeras novidades, como o tão aguardado
suporte total a SMP no SuperServer, criptografia no tráfego da rede e
da base de dados, usuários locais na base de dados, melhorias no
protocolo de comunicação, além de diversos novos recursos em
diferentes áreas do SGBD. Tudo isso acabou fazendo com que o
processo de migração de uma versão prévia do Firebird, não seja tão
fácil como foi nas versões anteriores, onde, basicamente, era
necessário apenas a troca do Firebird, ou, quando muito, um
backup/restore da base de dados. Essa foi a razão pela qual optei por
escrever um guia de migração!
O livro aborda apenas os tópicos essenciais relacionados ao
processo de migração. Para ficar a par de todas as novidades trazidas
nessa versão, incluindo os novos comandos PSQL, é
importantíssimo que você leia o Release Notes!
Recomendo a todos os leitores que acessem periodicamente o site
www.firebase.com.br, para se manterem informados sobre as
novidades do Firebird, além de ter acesso a centenas de artigos, dicas,
download e também à lista de discussão da FireBase, onde poderão
tirar suas dúvidas, inclusive sobre assuntos tratados aqui.
Espero que o livro seja uma agradável leitura!
Carlos H. Cantu
Março/2016
Introdução
13
Ícones usados
Durante a leitura desse livro, você encontrará diversos ícones que,
além de chamar a atenção para assuntos importantes, acabam
deixando a leitura mais leve. São eles:
Ignorar o assunto abordado poderá induzir a uma

situação de “perigo iminente”!
O assunto requer atenção especial!
Ignorar o assunto abordado poderá comprometer

a disponibilidade do servidor, dados e/ou
ambiente.
Importante/Dica
No final do livro há um glossário que pode ser consultado quando

o leitor não souber a definição de alguns termos ou abreviações (ex:
UDF, MGA, etc).
Ícones usados
14
Erratas
Os erros e correções que venham a ser detectados após a
publicação desse livro estarão listados em
www.firebase.com.br/guiafb3.php.
Aconselho visitar a página periodicamente.
Novas revisões desse guia podem ser disponibilizadas a qualquer
momento, também na referida página.
Caso encontre algum erro, encaminhe por e-mail

para livro@firebase.com.br, a fim de que seja
corrigido nas próximas revisões e adicionado na
seção de erratas na FireBase.
Erratas
15
Noções básicas, mas

essenciais!
Não pense em pular esse capítulo!
Noções básicas, mas essenciais!

16
Antes de adentrarmos nas especificidades do Firebird 3, é

importante que você entenda alguns conceitos importantes que o
ajudarão a entender como o Firebird funciona, e a compreender o
porquê de algumas das mudanças.
O Firebird trabalha com três diferentes “arquiteturas” (ou modos),
e entende-las corretamente pode significar a diferença entre o sucesso
ou a frustração durante sua utilização.
SuperServer vs. Classic vs. SuperClassic
O Firebird pode funcionar com três arquiteturas (modos)

diferentes: SuperServer, Classic e SuperClassic. Para entender a diferença
entre elas, é necessário conhecer alguns aspectos internos do SGBD:
Um arquivo de base de dados é composto por diversos “blocos
lógicos” de informação, chamado de páginas. As páginas tem
tamanho fixo, definido na criação do banco de dados ou durante um
restore pelo gbak, usando o parâmetro -p(age). Existem diversos tipos
de páginas em uma base de dados Firebird: algumas armazenam os
dados, outras os segmentos de índices, inventário de transações, blobs,
etc.
Quando uma base de dados é acessada por um processo do
Firebird, certa quantidade de RAM é alocada como cache de disco, para
agilizar o acesso às páginas que foram lidas recentemente da base de
dados. O Firebird usa dois tipos de cache: Cache de Metadados e Cache de
Páginas. O Cache de Metadados, como o próprio nome sugere, armazena
os metadados do banco, ou seja, a estrutura dos objetos que compõe a
base de dados (tabelas, procedures, triggers, etc.). O Cache de Páginas
armazena as páginas que foram acessadas recentemente, fazendo com
que um novo acesso a essas páginas seja muito mais rápido, visto que
não é necessário recupera-las do disco. Em suma, quando o Firebird
precisa de uma informação que está gravada em uma determinada
página do banco de dados, primeiro ele checa se essa página já se
encontra no seu próprio cache, caso contrário, faz a requisição de
leitura para o Sistema Operacional, que irá busca-la no seu próprio
cache ou no disco, carregando assim a página para o cache do Firebird.
Em geral, podemos imaginar que temos diferentes camadas de
cache, como exemplificado na figura a seguir.

17
Cache de páginas do Firebird
Cache do Sistema (Operacional/Arquivos)
Cache do dispositivo de armazenamento
Arquivo da base de dados
A quantidade de memória alocada para o cache de páginas do

Firebird é definida globalmente, no arquivo firebird.conf, ou
individualmente (por banco de dados), através do gfix usando o
parâmetro -buffers (nesse caso, a informação sobre o tamanho do cache
fica gravada no header do arquivo). O tamanho do cache (buffer) é
sempre definido em número de páginas, e não em bytes . Sendo
assim, a quantidade total de memória alocada para o cache de um
banco de dados é determinada pelo parâmetro buffers multiplicado
pelo tamanho da página do banco de dados. Por exemplo, em um
banco de dados com páginas de 8KB, configurando-se o buffers para
4.000, alocará 32.768.000 bytes de memória (4.000 x 8.192 bytes), ou
seja, cerca de 32MB.
Quando o valor de buffers (gravado no header da

base de dados através do gfix) for zero, o Firebird
assume o valor definido no parâmetro
DefaultDbCachePages no firebird.conf.
É aí que aparece a primeira diferença entre as arquiteturas do

Firebird. Na versão SuperServer, diferentes conexões a um mesmo
banco de dados, compartilham o cache entre si. Já na versão
Classic e na SuperClassic, cada conexão tem seu próprio cache ,
que não é compartilhado. Esse assunto será discutido com mais
detalhes ainda nesse capítulo.
Outro aspecto do Firebird que precisa ser entendido é que,
dependendo da arquitetura escolhida, ele usará threads ou processos
(independentes e paralelos) para atender as conexões.

18
A seguir, comentarei as características das três arquiteturas do

Firebird, suas diferenças e pontos de atenção.
Classic (CS)
Na versão Classic, cada conexão com o banco de dados é atendida

por um processo do Firebird. Com isso, podemos dizer que existirão
“n” Firebirds rodando, conforme o número de conexões ativas. O
cache de banco de dados é alocado individualmente para cada
processo, e não é compartilhado entre eles.
No exemplo anterior, se tivermos 10 conexões acessando uma
mesma base de dados, o total de memória alocada para o cache de
páginas com o Firebird Classic seria de 320MB (10 x 32MB)!
Um dos principais motivos de uma possível queda

de performance ao se usar a versão Classic ou
SuperClassic é a definição de um buffer muito
grande. Como o cache não é compartilhado entre as
conexões, dependendo da quantidade de memória
RAM do servidor e do número de conexões
simultâneas, uma grande quantidade de RAM
poderá ser alocada para cache, fazendo com que o
sistema operacional faça uso de memória virtual,
fazendo swap no disco, prejudicando a performance
do servidor como um todo.
O fato de cada conexão ser atendida por um processo

independente do Firebird cria uma maior “independência” entre elas,
permitindo que um processo seja encerrado sem que isso afete as
outras conexões. Isso pode ser útil em casos onde alguma conexão
esteja sobrecarregando o servidor: bastaria encerrar o processo do
Firebird que está servindo àquela conexão. Todas as outras conexões
continuariam funcionando normalmente. Essa independência
também ajuda em situações indesejáveis, como por exemplo, o uso
de alguma UDF (User Defined Function) problemática causando a queda
do servidor. No Classic, apenas o processo do Firebird que “chamou”
a UDF iria cair, sem interferir nos demais.

19
Apesar de não ser uma situação muito comum,

devemos ficar atentos ao usar o Classic no
Windows para atender um alto número de
conexões (gerando, portanto, um grande número
de processos) pois o limite para o “desktop heap” do
Windows pode se esgotar. Se esse for o caso, altere
o usuário do Windows associado ao processo do
Firebird, de LocalSystem para outro.
Lembre-se também que cada processo do Firebird consumirá

recursos do servidor, que não se limitam apenas à memória usada para
o cache. É importante dimensionar corretamente o hardware e o
sistema operacional utilizado, para evitar o esgotamento desses
recursos. Dê preferência para sistemas operacionais 64bits, bem
como para o Firebird 64bits.
No Windows, mesmo quando não há conexões ativas no Firebird,
um processo (fb_inet_server.exe para versões anteriores do FB, e
firebird.exe para o FB 3) estará sempre presente. Esse processo age
como listener, ou seja, quando um novo pedido de conexão é feito, ele
recebe o pedido e dispara um novo processo do Firebird para atende-
la. No Linux, geralmente o xinetd é usado como listener.
SuperServer (SS)
No modelo SuperServer, as conexões são atendidas por threads de

um único processo do Firebird. O cache de páginas do banco de dados
é compartilhado entre todas as conexões que estão acessando uma
mesma base de dados. O fato do cache ser compartilhado permite um
menor consumo de memória e menor carga de I/O, visto que as
páginas do cache não precisam ser sincronizadas constantemente
entre diferentes processos (como é o caso do Classic e do
SuperClassic).
O fato de existir um único processo servindo as diferentes
conexões cria uma “desvantagem” do SuperServer em relação ao
Classic, pois caso alguma conexão sobrecarregue (ou “trave”) o
servidor, se encerrarmos o processo do Firebird, todas as conexões
serão perdidas.

20
Outra desvantagem é que (até a versão 2.5) o SuperServer não

consegue tirar proveito de execuções paralelas em máquinas
multiprocessadas (SMP). No Windows, o Firebird precisa ficar
atrelado à um único core, evitando que o sistema operacional fique
alternando o processo entre os vários cores, na tentativa de balancear
a carga. Felizmente, o Firebird 3 sana essa limitação!
No Firebird 2.5, é possível fazer com que o SS use

mais de um core, se houver mais de uma base de
dados no servidor sendo acessada. Para isso, deve-
se configurar o parâmetro CPUAffinitymask do
firebird.conf de forma que permita o uso de mais de
um processador. No entanto, o Firebird usará
apenas um core para “atender” uma mesma base de
dados.
SuperClassic (SC)
O SuperClassic é um híbrido entre o Classic e o SuperServer.

Assim como no SuperServer, existe apenas um processo do Firebird
atendendo as conexões através de threads. No entanto, o cache funciona
de forma similar ao Classic, ou seja, não é compartilhado entre as
conexões.
A vantagem do SuperClassic é que ele escala melhor do que o
SuperServer (no Firebird 2.5) e o Classic. Mesmo com o cache não
sendo compartilhado, a sincronização das páginas entre eles é feita de
forma mais eficiente do que no Classic, visto que não há necessidade
de comunicação entre diferentes processos do Firebird (a
sincronização das páginas é feita dentro do mesmo processo).
A mesma regra de cálculo de consumo de RAM para cache usada
no Classic deve ser aplicada no SuperClassic, portanto, exige os
mesmos cuidados para evitar o consumo excessivo e esgotamento da
RAM do servidor.
Como o SuperClassic usa apenas um processo, consome menos
recursos do servidor quando comparado ao Classic. A arquitetura
SuperClassic foi criada como sendo uma arquitetura de transição para
o Firebird 3 (que traz um SuperServer totalmente escalável).

21
Embedded
A versão embarcada (embedded) do Firebird permite distribuir o

SGBD com sua aplicação, sem necessidade de instala-lo no
computador do usuário final. Isso é muito útil, por exemplo, para
distribuir versões de demonstração de softwares, catálogos digitais,
etc.
Antes do Firebird 3, era necessário renomear a fbembed.dll para
fbclient.dll, fazendo com que sua aplicação carregasse a biblioteca
cliente que, nesse caso, também era o servidor Firebird!
Já no Firebird 3, devemos distribuir a aplicação juntamente com a
fbclient.dll “normal” e alguns outros arquivos necessários para o
correto funcionamento do SGBD, e fazer com que a aplicação acesse
a base de dados fornecendo somente o nome do arquivo ou alias (sem
localhost, etc.). Outra novidade é que agora é possível configurar o
embedded para agir como um SS, CS ou SC.
A seguir, temos a lista de arquivos que devem ser distribuídos com
as aplicações em modo embedded:
fbclient.dll – biblioteca cliente
firebird.msg – arquivo de mensagens
ib_util.dll – alocação de memória usada por algumas UDFs
icudt52.dll – suporte a internacionalização
icudt52l.dat – suporte a internacionalização
icuin52.dll – suporte a internacionalização
icuuc52.dll – suporte a internacionalização
firebird.conf – caso queira definir algum parâmetro diferente
do padrão
databases.conf – caso queira usar aliases ou definir parâmetro
por BD
msvcp100.dll – caso já não esteja disponível no Windows
msvcr100.dll – caso já não esteja disponível no Windows
intl\fbintl.conf – caso utilize algum charset diferente de NONE
intl\fbintl.dll – caso utilize algum charset diferente de NONE
plugins\engine12.dll – engine do Firebird 3
Note, no entanto, que o Firebird embedded não faz autenticação

quando se loga na base de dados (nem a senha, nem o usuário são
consistidos). Mesmo assim, pode-se restringir o acesso do usuário
“logado” à determinados objetos da base de dados, utilizando os
comandos grant/revoke.
A seguir, temos um resumo das diferenças nas arquiteturas
disponíveis no Firebird 3.

22
Arquiteturas Nome do SMP Cache de Acesso Threads/

Firebird 3 Executável friendly dados exclusivo ao Processos
compartilhado arquivo
SuperServer firebird SIM Sim Sim Threads
Classic firebird Sim Não Não Processos
SuperClassic firebird Sim Não Não Threads
Qual arquitetura escolher?
É difícil criar uma regra ou “receita de bolo” válida para todas as

situações imagináveis, pois existem inúmeras variáveis ou
características especiais que podem influenciar na escolha da
arquitetura mais adequada a ser usada.
A seguir, ofereço um “guia geral” que pode servir como base para
essa decisão, mas lembre-se que sempre poderá haver necessidades
especiais que fujam da “receita” apresentada. Estou considerando que
o servidor esteja corretamente dimensionado em relação ao hardware
e sistema operacional.
Classic – Pode ser usado em servidores multiprocessados,

suportando considerável número de conexões simultâneas. É “SMP
friendly”, pois o sistema operacional distribui os processos do
Firebird entre os cores disponíveis. O Classic é especialmente
interessante quando se exige o máximo de estabilidade, pois a
queda de um processo do Firebird não afeta as outras conexões
existentes.
SuperClassic – Pode ser usado em servidores multiprocessados

(SMP friendly), mas seu uso é aconselhado apenas com sistemas
operacionais 64bits (a versão do Firebird também deve ser 64bits).
Suporta alto número de conexões simultâneas e consome menos
recursos do SO se comparado com o Classic, escalando melhor, pois
a sincronização do cache não exige comunicação entre os processos.
No entanto, diferente do Classic, a queda do processo do Firebird faz
com que todas as conexões existentes sejam derrubadas.

23
A arquitetura SuperServer merece uma atenção especial, pois sua

indicação é diferente quando estamos falando do Firebird 2.5 ou do
3.0. Vejamos:
SuperServer no Firebird 2.5 – De forma geral, deve ser usado

por iniciantes ou pessoas que não têm experiência com o Firebird.
Pode ser usado em situações onde haja poucas conexões simultâneas,
e as queries e operações executadas no banco sejam rápidas e estejam
otimizadas, e/ou quando o compartilhamento do cache entre as
conexões justifique a escolha em detrimento ao suporte à SMP.
SuperServer no Firebird 3 – A SuperServer é a arquitetura

padrão no Firebird 3! Diferente do que acontecia antes, agora ela é
“SMP friendly”, ou seja, aproveita todas as CPUs/Cores da máquina
servidora, e continua oferecendo cache compartilhado – o melhor
dos mundos!
Dmitry Yemanov, atual chefe da equipe de

desenvolvimento do Firebird, costuma dizer em
sua MasterClass sobre otimização de performance,
que “a não ser que você seja paranoico em relação a
estabilidade, deve escolher o SuperServer”. Ou seja: se a
opção de “matar” um processo do Firebird sem
afetar as outras conexões for algo realmente
importante para você (paranoia?), então use o
Classic. Já o SuperClassic, apesar de ainda
suportado, não tem mais razão de existir.
No Firebird 3, a arquitetura a ser usada (CS, SS ou SC) é definida

globalmente através do novo parâmetro ServerMode , disponível no
firebird.conf. Futuramente, é provável que esse parâmetro também
esteja disponível por base de dados, através do arquivo databases.conf.
Os valores aceitos para o ServerMode são:
• Super (ou ThreadedDedicated) – é a arquitetura padrão

no Firebird 3. Os arquivos das bases de dados são abertos

24
em modo exclusivo por um único processo do Firebird.

As conexões servidas por esse processo compartilham o
cache entre elas.
• SuperClassic (ou ThreadedShared) - Os arquivos das
bases de dados são abertos de forma não exclusiva, por um
único processo do Firebird, o que possibilita que uma
conexão embarcada/embedded acesse a mesma base de
dados que já esteja aberta pelo Firebird. Cada conexão tem
seu próprio cache.
• Classic (ou MultiProcess) – para cada conexão, um novo
processo independente do servidor é iniciado. Uma base
de dados pode ser aberta por múltiplos processos locais ou
embarcado/embedded. Cada conexão/processo tem seu
próprio cache.
O antigo arquivo aliases.conf agora se chama

databases.conf. O “novo” arquivo oferece uma gama
de configurações muito maior do que o antigo
aliases.conf (que servia apenas para definir apelidos
para as bases de dados).
Arquitetura 32 vs 64 bits
O Firebird oferece versões nativas para 32 e 64 bits. Obviamente,

se o sistema operacional utilizado no servidor for 32 bits, não será
possível instalar o Firebird 64bits. No entanto, se o sistema
operacional for 64 bits, há a possibilidade de instalar tanto o Firebird
32bits como o 64bits.
O Firebird 64bits geralmente consome 30% mais

memória do que a versão 32 bits. Ao usar a versão
64 bits, certifique-se que a quantidade de memória
no servidor esteja corretamente dimensionada.
A principal diferença das versões 32 x 64bits é a quantidade de

memória que o Firebird poderá aproveitar e, consequentemente,

25
quanto ele poderá escalar. O Firebird 32 bits não consegue endereçar

mais que 2 GB de memória. Sendo assim, se o servidor tem 4GB ou
mais de RAM e a versão 32 bits do Firebird for instalada, o FB não
“aproveitará” toda a memória disponível, gerando impacto negativo,
especialmente nas versões SuperServer e SuperClassic.
Um fator que pode ser decisivo na escolha da “bitagem” é se você
faz uso de UDFs (User Defined Functions). A maioria das UDFs
disponível na Internet foi compilada em 32 bits e, portanto, não pode
ser utilizada com o Firebird 64bits. Para solucionar o problema,
precisam ser compiladas em 64bits, mas nem sempre o código fonte
dessas UDFs está disponível, e nem sempre existem compiladores
que geram código 64 bits.
As UDFs que acompanham o Firebird (fbudf e ib_udf) já foram
compiladas de acordo com a “bitagem” do Firebird instalado. O
problema são as UDFs criadas por terceiros!
Muitos pacotes de UDFs disponibilizados na

Internet podem ser totalmente substituídos pelo
pacote FreeAdhocLib. Essa biblioteca de UDFs
oferece uma série de funções totalmente
compatíveis com outros pacotes de UDFs, com a
vantagem de ser disponibilizada tanto em 32 como
em 64 bits. A FreeAdhocLib pode ser encontrada
na área de downloads da FireBase
(www.firebase.com.br).
Deve-se prestar atenção especial na versão da

biblioteca cliente do Firebird (fbclient.dll) que será
carregada pela aplicação cliente. Caso a aplicação
seja 32 bits, então a fbclient.dll carregada também
deverá ser 32 bits. Se a aplicação é 64bits, a
fbclient.dll também deverá ser 64 bits. O instalador
do Firebird 64bits já inclui ambas as versões da
biblioteca cliente, sendo que a versão 32 bits fica
gravada na pasta WOW64 do Firebird.

26
Instalando o
Firebird 3
Aprenda a instalar o Firebird 3 no Linux e no Windows.
Instalando o Firebird 3
27
Instalando o Firebird 3 no Linux
A combinação de Linux + Firebird geralmente é extremamente

estável! Para efeito de exemplo, estarei demonstrando como instalar
o Firebird 3 no Linux CentOS 7 (64bits), através do download do arquivo
tar.gz. Dependendo da distribuição do Linux utilizada, pode ser que o
Firebird 3 já esteja disponível através de repositórios, sendo também
uma opção para instalação (vai da preferência de cada um).
Eu estou longe de ser um expert em Linux. O

intuito desse capítulo é servir como um passo-a-
passo básico, mas visto as inúmeras distribuições
existentes e a falta de padrão entre elas, pode ser
que haja algumas diferenças entre o que está
mostrado aqui e o que você vai obter no seu linux.
A primeira coisa a ser feita é entrar no site www.firebirdsql.org e

clicar na opção Downloads do menu superior, e depois escolher o
Firebird 3 no menu lateral.
Será listado diversos arquivos de instalação, para diferentes
sistemas operacionais e arquiteturas (32, 64 bits). Observe também
que existem versões de debug (que devem ser usadas quando você
detectar algum bug no Firebird e desejar auxiliar os desenvolvedores
no processo de depuração), pacotes zip, instaladores, entre outras.
28
Para o correto funcionamento do Firebird 3 no

Linux, atente para as versões mínimas do kernel e
da glibc que devem estar instaladas:
• kernel - 2.6.39
• glibc - 2.12
Para esse exemplo, escolhi o arquivo Firebird-3.0.0.32366-

ReleaseCandidate2.amd64.tar.gz (versão mais atual quando esse livro foi
escrito).
Após fazer o download, devemos descompactar o conteúdo do
arquivo.
Abra um shell (terminal) do linux, vá até o diretório onde o arquivo
foi baixado, e execute o comando:
tar -xvf Firebird-3.0.0.32366-ReleaseCandidate2.amd64.tar.gz
Com isso, será criado um novo diretório com o nome do arquivo

descompactado (Firebird-3.0.0.32366-ReleaseCandidate2.amd64)
contendo alguns arquivos, entre eles, o script de instalação (install.sh).
Entre no diretório recém criado pela descompactação do arquivo,
e execute o install.sh:
cd Firebird-3.0.0.32366-ReleaseCandidate2.amd64/
sudo ./install.sh
Lembre-se que para instalar, você deve estar logado

como root, ou usar o sudo para obter direitos de root,
caso contrário, receberá a mensagem “You need to be
'root' user to do this change.”
Uma mensagem aparecerá, pedindo que você pressione ENTER

para começar a instalação, ou CTRL-C para aborta-la. Pressione
ENTER.
Nesse ponto, pode haver algumas “surpresas”. Nesse exemplo, a
instalação foi abortada, devido à falta da biblioteca libtommath, da qual
o script de instalação depende. Se essa biblioteca já estiver disponível
no Linux instalado, não haverá mensagem de erro, e a instalação
29
continuará normalmente. No entanto, nesse exemplo, precisamos

resolver o problema da dependência para continuar.
Vamos então instalar a biblioteca libtommath:

wget http://dl.fedoraproject.org/pub/epel/6/x86_64/libtommath-
0.42.0-3.el6.x86_64.rpm
sudo rpm -Uvh libtommath-0.42.0-3.el6.x86_64.rpm
Outra forma de instalar a biblioteca libtommath é:

sudo yum update yum install libtomath
Já com a biblioteca instalada, recomeçaremos a instalação,

executando mais uma vez o install.sh.
sudo ./install.sh
Firebird 3.0.0.32366-ReleaseCandidate2.amd64 Installation
Press Enter to start installation or ^C to abort
Extracting install data
Updated /etc/services
Please enter new password for SYSDBA user: masterkey
Install completed
30
[osboxes@osboxes Firebird-3.0.0.32366-ReleaseCandidate2.amd64]$
O instalador pedirá que você forneça uma senha para o SYSDBA.

No exemplo, usei masterkey, mas é extremamente recomendado que
você utilize outra senha, visto que masterkey é uma senha
“mundialmente conhecida” e, portanto, completamente insegura.
Se tudo correu bem, a instalação será finalizada com a mensagem
“Install completed”.
O script de instalação pode ser chamado com o

parâmetro -silent, que fará uma instalação silenciosa
(sem perguntas). Nesse caso, uma senha aleatória
para o SYSDBA será gerada e armazenada no
arquivo SYSDBA.password
Muitos usuários preferem instalar o Firebird

através de repositórios, utilizando o apt-get em
distribuições baseadas no Debian, ou yum em
distribuições baseadas no RedHat. Uma das
vantagens do uso dos repositórios é que o próprio
sistema tentará resolver os problemas de
dependências, sendo que a atualização do software
também se dá de forma mais fácil. No entanto,
geralmente há uma certa demora entre o
lançamento de uma nova versão do Firebird e a
disponibilização dela nos repositórios.
Para testar se o Firebird foi realmente instalado, podemos fazer

uma conexão na base de dados de exemplo (employee.fdb), que
acompanha toda instalação do Firebird.
Vá para o diretório onde o Firebird foi instalado:
cd /opt/firebird
31
Dependendo da distribuição do Linux utilizada, o

diretório de instalação do Firebird pode ser
diferente do /opt.
Vamos tentar conectar na base de dados employee através do isql:

./bin/isql employee
Statement failed, SQLSTATE = 08006
Can not access lock files directory /tmp/firebird/
Use CONNECT or CREATE DATABASE to specify a database
SQL> quit;
Se você obteve o erro acima, então o usuário logado não tinha

direitos suficientes para fazer uma conexão embarcada (embedded) com
o Firebird. Note que, na linha de comando, não especificamos o
nome de um host, portanto, o Firebird tentará fazer a conexão como
sendo embarcada, e não via tcp/ip. Lembre-se também que em uma
conexão embedded, usuário e senha não são validados.
O Firebird 3 já vem com um apelido (alias) criado

com o nome de employee, apontando para a base de
dados de exemplo (employee.fdb)
Sendo assim, temos três opções para fazer a conexão:
1. Executar o isql como usuário root (ex: sudo ./bin/isql)

2. Adicionar o usuário ao grupo firebird do Linux (sudo
usermod -a usuário -G firebird). Se estiver adicionando o
usuário atualmente logado no shell, lembre-se de “re-logar”
após inseri-lo no grupo, para que a alteração tenha efeito.
3. Conectar na employee via tcp/ip (localhost), ao invés de usar
uma conexão embedded.
Usando a terceira opção:

./bin/isql -user SYSDBA -pas masterkey localhost:employee
Database: localhost:employee, User: SYSDBA
SQL> show database;
Database: localhost:employee
Owner: SYSDBA
PAGE_SIZE 8192
Number of DB pages allocated = 307
32
Sweep interval = 20000

Forced Writes are ON
Transaction - oldest = 165
Transaction - oldest active = 166
Transaction - oldest snapshot = 166
Transaction - Next = 171
ODS = 12.0
Default Character set: NONE
Sendo assim, podemos observar que o Firebird está operacional,

pois fomos capazes de conectar na base de dados employee.
O padrão do instalador é configurar o Firebird 3 no modo
SuperServer. Podemos alterar o modo do servidor (Super, Classic,
SuperClassic) através do parâmetro ServerMode no firebird.conf. No
entanto, no Linux, é recomendável fazer a troca usando o script
changeServerMode.sh , disponível no diretório bin do Firebird. Mas
qual seria a diferença?
Segundo Alex Peshkov, quando alteramos o parâmetro ServerMode
no firebird.conf, a fim de configurar o Firebird em modo Classic, o
próprio Firebird agirá como listener, gerenciando os pedidos de
conexão. No entanto, essa forma de executar o Classic é “nova”,
portanto, não há um histórico de uso em produção confirmando sua
estabilidade. Em versões anteriores, o Classic sempre dependeu do
inetd/xinetd (en.wikipedia.org/wiki/Xinetd), que recebe os pedidos de
conexões e as repassa para o Firebird.
Ao usar o script changeServerMode.sh para configurar o modo do
servidor para Classic, ele fará as configurações necessárias de forma
que o xinetd ou o systemd seja utilizado. Uma das vantagens do uso do
xinetd é aproveitar algumas configurações “extras” disponíveis,
ficando fácil, por exemplo, limitar o número de conexões aceitas, ou
mesmo impedir novas conexões, etc.
sudo ./changeServerMode.sh
Firebird server may run in 2 different modes - super and classic.
Super server provides better performance, classic - better
availability.
Which option would you like to choose: (super|classic) [super] classic

Stopping currently running engine...
Starting firebird in classic server mode...
Done.
33
Se você utilizar o script changeServerMode.sh para

trocar o modo de execução do Firebird, qualquer
nova mudança no modo de operação deve sempre
ser feita através do script, e não alterando
diretamente o ServerMode no firebird.conf. Caso
contrário, você poderá ficar com uma instalação
inconsistente. É altamente recomendável fazer a
mudança sempre através do script.
A instalação do Firebird no Ubuntu 14.04 LTS e

no 15.03 64bits transcorreu exatamente da mesma
forma que no CentOS, inclusive em relação a falta
da biblioteca libtommath. No caso, como o rpm não
vem instalado por padrão no Ubuntu, utilizei os
comandos abaixo para instalar a biblioteca:
sudo apt-get update
sudo apt-get install libtommath
Se desejar desinstalar o Firebird, utilize o script FirebirdUninstall.sh

que se encontra no diretório bin do Firebird.
Caso já tenha uma versão anterior do Firebird

instalada, e queira instalar o Firebird 3 mantendo a
versão anterior, experimente o seguinte:
1. Baixe e extraia o .tar.gz do Firebird 3

(Firebird-3.0.0.32366-
ReleaseCandidate2.amd64.tar.gz).
2. Extraia o conteúdo do arquivo
buildroot.tar.gz que foi gerado pela etapa
anterior.
3. Copie o conteúdo da pasta opt/firebird
recém descompactada para um outro local,
por exemplo, /opt/firebird3
4. Edite o firebird.conf em opt/firebird3 e altere
os parâmetros necessários para fazer com
que ele não conflite com o Firebird já
34
existente, por exemplo, alterando o

RemoteServiceName, RemoteServicePort, etc.
5. Crie o usuário SYSDBA.
6. Inicie o Firebird, via prompt de comando.
35
Instalando o Firebird 3 no Windows
Instalar o Firebird no Windows sempre foi (e continua sendo) uma

tarefa muito fácil. O instalador segue a tradição “Next – Next – Finish”
e, em poucos minutos, você tem um Firebird rodando e pronto para
ser usado!
Antes de continuar, é importante ler o capítulo

“Noções básicas, mas essenciais”, pois a
informação contida nele será de grande valia nas
decisões tomadas durante o processo de instalação.
Inicie o processo entrando no site www.firebirdsql.org e clicando

na opção Downloads do menu superior, e depois escolhendo o Firebird
3 no menu lateral.
Será listado diversos arquivos de instalação, para diferentes
sistemas operacionais e arquiteturas (32, 64 bits). Observe também
que existem versões de debug (que devem ser usadas quando você
detectar algum bug no Firebird e desejar auxiliar os desenvolvedores
no processo de depuração), pacotes zip, instaladores, entre outras.
Nesse passo a passo, escolhi a versão 32bits do Firebird 3 RC2 (a
versão mais atual disponível quando esse capítulo foi escrito).
Ao executar o instalador, a primeira tela apresentada será a escolha
do idioma usado durante a instalação. Escolheremos Português
(Portugal), já que não há opção para o Português (Brasil):
36
Em seguida, a licença padrão do Firebird será exibida, sendo

necessário aceita-la para continuar.
A próxima tela mostra o conteúdo do arquivo instalacao_leia-me.txt,

contendo informações sobre essa versão do Firebird. Clique em
Seguinte para continuar:
37
A próxima tela determina em qual pasta o Firebird 3 será instalado.

O padrão no Windows é instala-lo na pasta Firebird\Firebird_3_0
dentro da pasta padrão de programas, que no Windows 32 bits é
chamada Program Files (ou Arquivos de Programas, se o Windows estiver
em Português). Nesse passo a passo, instalarei em C:\Firebird3.
38
Na próxima tela, através da caixa de seleção, poderemos escolher

entre 4 tipos de instalação:
• Instalação completa do Server e ferramentas de

desenvolvimento - Instala o servidor Firebird
juntamente com os utilitários de linha de comando
(gbak, gfix, isql, etc).
• Instalação das ferramentas do Cliente para
programadores e administradores - Instala o
39
cliente do Firebird e as ferramentas de linha de

comando (gbak, gfix, isql, etc.).
• Instalação mínima do Cliente – sem servidor,
sem ferramentas - Instala somente os arquivos
necessários para o funcionamento da fbclient.dll
(biblioteca cliente do Firebird).
• Instalação Personalizada – permite indicar quais
módulos desejamos instalar, sendo: Componentes do
Servidor, Componentes do Programador e das ferramentas de
administração, e Componentes do Cliente, sendo que este
último é obrigatório.
Prosseguiremos com a instalação Completa.

Em seguida, o instalador permitirá determinar a pasta no Menu
Iniciar, onde os ícones do Firebird serão criados. Observe que há
opção para não criar qualquer ícone, se assim desejar:
40
A próxima tela merece atenção especial, pois permite definir

inúmeras opções:
Arquitetura desejada
Podemos escolher entre Classic, SuperClassic ou SuperServer (padrão).

Observe que, ao optar pelo SuperClassic ou SuperServer, é dada a opção
de usar o Guardian para iniciar/monitorar o Firebird (não
recomendado no caso do Firebird ser instalado como serviço).
41
Serviço ou Aplicação?
Salvo por alguma razão específica, é recomendado instalar o

Firebird sempre como Serviço (padrão). Assim, não é necessário
logar no Windows do servidor para que o Firebird seja executado,
além de dispensar totalmente o uso do Guardian.
Executar o Firebird como aplicação pode ser interessante nos
computadores de desenvolvimento, onde geralmente há uma maior
necessidade de iniciar e parar o Firebird, tarefa simplificada quando o
mesmo é executado como aplicação, pois o ícone do Firebird estará
presente na barra de tarefas do Windows.
Iniciar automaticamente
Em um servidor de produção, é comum (e desejado) que o

Firebird seja iniciado automaticamente junto com o Windows. Se essa
opção não for marcada, será responsabilidade de alguém iniciar o
Firebird, sempre que houver um boot do sistema operacional.
Biblioteca cliente (fbclient.dll)
O instalador dá a opção de copiar a fbclient.dll para a pasta de

sistema do Windows (system32 ou syswow64, dependendo da “bitagem”
do sistema operacional). Aconselho copiar a fbclient para a pasta de
sistema apenas nos casos onde as aplicações que utilizam o Firebird
não sejam capazes de encontrar a biblioteca em outro local.
gds32.dll
Aplicações legadas, criadas para o InterBase ou para o Firebird 1.0,

esperam que a biblioteca cliente se chame gds32.dll e não fbclient.dll.
Sendo assim, caso utilize alguma aplicação que se encaixe nesse perfil,
recomendo optar pela criação da biblioteca de retro-compatibilidade.
42
Autorização para cliente legados
Essa opção configura os parâmetros AuthServer, AuthClient,

UserManager e WireCrypt, de forma que permita que clientes legados
(ex: fbclient de versões mais antigas do Firebird) consigam conectar no
servidor Firebird 3. Observe que o Firebird fica menos seguro ao se
optar por essa configuração.
Continuando com a instalação, a tela seguinte permitirá definir o

nome e a senha do usuário administrador. Deixando os campos em
branco, fará com que o instalador crie o usuário administrador com
o nome de SYSDBA e com a senha masterkey.
43
É altamente recomendado que não se use a senha

masterkey em um servidor de produção, pois ela é
amplamente conhecida!
A próxima tela exibirá um resumo das opções escolhidas durante

a instalação, sendo a última oportunidade para revisar e voltar para as
etapas anteriores, caso queira alterar alguma opção:
Se tudo estiver correto, clique em Instalar e aguarde o final do

processo de cópia e configuração dos arquivos.
A próxima tela exibirá algumas informações de pós-instalação,
relacionadas a essa versão do Firebird:
44
Na última etapa, o instalador dará a opção de iniciar o Firebird, e

de abrir a página de pós-instalação
(www.firebirdsql.org/en/afterinstall-br/).
Com isso, finalizamos o passo a passo da instalação do Firebird 3
em um servidor Windows.
Verificando se o Firebird está em execução
Existem diversas maneiras de saber se o servidor Firebird está

sendo executado.
Caso tenha optado por instalá-lo em modo Aplicação, sempre que
o servidor estiver rodando, um ícone será apresentado ao lado do
relógio do Windows, na barra de ferramentas.
45
Quando instalado como Serviço, nenhum ícone é exibido. Nesse

caso, basta rodar a aplicação “Serviços/Services” que acompanha o
Windows, e checar o status do serviço do Firebird, como mostrado
na imagem abaixo.
O status do serviço também pode ser verificado através do

utilitário instsvc, com o parâmetro “q”:
C:\Firebird3>instsvc q
Firebird Server - DefaultInstance IS installed.
Status : running
Path : C:\Firebird3\firebird.exe -s DefaultInstance
Startup : automatic
Run as : LocalSystem
Outra forma de verificar se o servidor está rodando

(independentemente de ser como serviço ou aplicação) é tentar conectar
algum banco de dados. No caso, podemos usar o próprio banco de
dados de exemplo que acompanha o Firebird (employee.fdb). Para isso,
46
abra um prompt de comando, e tente conectar o employee.fdb através do

isql:
C:\Firebird3>isql -user SYSDBA -pas masterkey
localhost:employee
Observe que, no exemplo acima, estamos conectando na base de

dados employee.fdb (que acompanha o Firebird) via tcp/ip (localhost)
utilizando o alias “employee”, que já vem configurado no arquivo
databases.conf em uma instalação padrão do Firebird.
Se o servidor não estiver rodando, será exibida uma mensagem de
erro:
C:\Firebird3>isql -user SYSDBA -pas masterkey
localhost:employee
Unable to complete network request to host "localhost".
-Failed to establish a connection.
Caso contrário, cairemos dentro do prompt do isql, indicando que o

servidor está ativo. Agora, usaremos o comando show tables para exibir
as tabelas do banco de dados, provando que estamos conectados:
Database: localhost:employee, User: SYSDBA
SQL> show tables;
COUNTRY CUSTOMER
DEPARTMENT EMPLOYEE
EMPLOYEE_PROJECT JOB
PROJECT PROJ_DEPT_BUDGET
SALARY_HISTORY SALES
Para sair do isql e retornar ao prompt de comando do Windows, digite:

exit; <enter>
O Firebird utiliza, por padrão, a porta 3050 do

TCP/IP. Se o Firewall do Windows (ou qualquer
firewall de terceiros) estiver ativo, será necessário
desbloquear essa porta, caso contrário, os pedidos
de conexão das estações de trabalho serão
recusados.
A configuração pode ser feita através da interface
gráfica do próprio Firewall do Windows, ou via
47
linha de comando, executando como

Administrador:
No Windows Vista ou superior:

netsh advfirewall firewall add rule name="Firebird"
dir=in action=allow protocol=TCP localport=3050
No Windows XP:
netsh firewall add portopening protocol=TCP port=3050
name="Firebird" mode=ENABLE scope=SUBNET
Instalação via Zip Kit
O Zip Kit disponibilizado na página de downloads do Firebird,

nada mais é do que a estrutura de diretórios e arquivos necessários
para rodar um servidor Firebird, compactados em um único arquivo
padrão zip.
Existem situações especiais onde não é desejado instalar o Firebird
através do instalador. Por exemplo, quando se deseja rodar mais de
uma versão do Firebird em um mesmo computador (o instalador não
é preparado para essas situações).
Obviamente, descompactar o Zip Kit em uma pasta qualquer é
apenas parte do processo de instalação. Em geral, para completar a
configuração, é necessário o uso de alguns utilitários que
acompanham o Firebird, em especial o instsvc, instreg e o instclient,
descritos a seguir.
INSTSVC
A função desse utilitário, encontrado na pasta bin do Firebird, é
instalar, configurar ou manipular o servidor Firebird como serviço,
nas versões do Windows que suportam esse recurso.
O comando mais básico que podemos utilizar para instalar o
serviço FB é instsvc install. Ele fará com que o serviço do Firebird seja
criado, configurado para iniciar automaticamente durante o boot do
sistema, e sob a identidade padrão do sistema (chamada LocalSystem
ou SistemaLocal). No entanto, o instsvc fornece vários outros
parâmetros para customizar a criação e inicialização do serviço:
instsvc i[nstall]
48
[ -a[uto]* | -d[eman
[ -g[uardian] ]
[ -l[ogin] username
[ -n[ame] instance ]
[ -i[nteractive] ]
sta[rt] [ -b[oostpriority] ]
[ -n[ame] instance ]
sto[p] [ -n[ame] instance ]
q[uery]
r[emove] [ -n[ame] instance ]
A descrição completa de cada um dos parâmetros pode ser obtida

no arquivo README.instsvc.txt encontrado na pasta doc no diretório
de instalação do FB. Os itens marcados com * indicam a ação padrão.
Associando o serviço a outro usuário
O padrão na instalação do servidor como serviço é

deixá-lo associado ao usuário “LocalSystem” ou
“SistemaLocal”. Isso pode abrir uma brecha para
crackers tentarem ganhar acesso ao computador,
atacando o serviço do Firebird. É aconselhável,
portanto, associar o serviço a outro usuário com
poderes mais limitados.
O instsvc pode configurar o serviço associando-o a
outro usuário, sendo que o mesmo já deve estar
criado no Windows, com direitos de escrita/leitura
a todos os bancos de dados e ao arquivo firebird.log.
Por questões de segurança, não é aconselhado que
o usuário tenha direito de escrita ao arquivo
firebird.conf e nos executáveis do Firebird.
Para indicar ao instsvc o nome/senha do usuário a
ser utilizado com o serviço do Firebird, deve-se
utilizar o parâmetro -login seguidos do nome do
usuário e a senha separados por espaço, por
exemplo:
instsvc i -g -login usuario senha
Em instalações onde o Guardian esteja presente, o

serviço do servidor Firebird deve estar configurado
para ser iniciado manualmente, pois é tarefa do
Guardian iniciá-lo quando necessário.
49
O utilitário instsvc também pode ser usado para iniciar e parar o

serviço do Firebird:
instsvc start
Service "Firebird Server - DefaultInstance" successfully started.
instsvc stop
Service "Firebird Server - DefaultInstance" successfully stopped.
INSTREG
O utilitário instreg.exe cria no registro do Windows a chave padrão
(HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances) que
aponta para o local onde o servidor Firebird está instalado. O
processo do servidor não necessita dessa chave, mas existem
inúmeras aplicações, incluindo os utilitários do próprio Firebird, que
usam essa chave para determinar onde o Firebird está instalado.
O diretório base de instalação do Firebird a ser configurado na
chave do registro será a pasta onde se encontra o instreg.exe, por isso
é importante que ele esteja gravado e seja executado na pasta
de instalação do Firebird.
Os parâmetros para o instreg são:
instreg i[nstall]
r[emove]
Onde:
i[nstall]: cria a chave no registro do windows.

r[emove]: apaga a chave do registro.
INSTCLIENT
O instclient.exe é responsável por instalar a biblioteca cliente do
Firebird (fbclient.dll) ou a biblioteca de retro-compatibilidade (gds32.dll)
na pasta de sistema do Windows.
instclient i[nstall] [ -f[orce] ] library
q[uery] library
r[emove] library
where library is: f[bclient] | g[ds32]
50
I[nstall] irá instalar a biblioteca cliente. A opção -f[orce] faz com

que o instclient instale a biblioteca mesmo que encontre uma versão
mais nova já instalada. Use essa opção com cuidado, pois pode
comprometer instalações já existentes.
R[emove] irá apagar uma biblioteca que já tenha sido instalada.
Q[uery] irá mostrar a versão da biblioteca cliente atualmente
instalada.
51
Migrando uma base

de dados já
existente, para o
Firebird 3
Migrando uma base de dados já existente, para o Firebird 3

52
Porque é necessário “migrar” a base de dados?
Diferente do que acontecia anteriormente, onde uma nova versão

do Firebird podia acessar bases de dados criadas em versões
anteriores (ou até mesmo por algumas versões do InterBase®), o
Firebird 3 só consegue abrir bases de dados criadas por ele mesmo.
A implementação de novos recursos geralmente exige mudanças no
formato de armazenamento do arquivo da base de dados. Manter a
compatibilidade com os formatos antigos torna o código do Firebird
mais complexo e difícil de manter. Esse código sofreu grandes
mudanças no Firebird 3, permitindo a execução de queries em paralelo
no SuperServer em máquinas multiprocessadas e, como resultado, a
retrocompatibilidade foi removida.
Para usar bases de dados já existentes com o Firebird 3, devemos
convertê-las para o novo formato. Essa conversão pode ser feita
simplesmente usando o gbak para fazer um backup da base de dados
na versão corrente, e depois restaura-lo no Firebird 3. No entanto,
vários fatores podem complicar a migração, especialmente das
versões muito antigas do Firebird. Se o responsável pelo SGBD não
tinha o hábito de fazer backup/restore rotineiros das bases de dados,
pode ser que erros tenham permanecidos na estrutura física/lógica do
arquivo, tornando o processo de migração mais difícil.
Antes de tentar migrar as bases de dados, devemos verificar se é
possível fazer com sucesso um backup/restore na versão do Firebird
que está sendo usada. O processo de backup é simples, mas pode
revelar problemas escondidos na estrutura física da base de dados,
que geralmente podem ser corrigidos com o gfix. A restauração do
backup poderá revelar problemas na consistência lógica, como campos
not null contendo nulos, duplicidade em índices únicos e violações de
chave estrangeira. Esses problemas geralmente aparecem quando se
usa versões muito antigas (e menos confiáveis) do Firebird, ou
manipulava-se diretamente as tabelas de sistema. Os erros reportados
pelo gbak indicarão onde estão os problemas, que deverão ser
corrigidos manualmente, editando/corrigindo os dados através do isql
ou qualquer outro aplicativo que permita a manipulação dos dados.
Com a ampliação e melhoria da implementação da SQL no
Firebird 3, algumas partes da linguagem foram alteradas. O Firebird
3 traz palavras reservadas que anteriormente não eram reservadas.

53
Caso sua base de dados use alguma dessas palavras em nomes de

tabelas, procedures, campos, views ou triggers, será necessário adaptar a
metadata antes de migra-la para o Firebird 3. O FB 3 pode ser mais
rigoroso na identificação de comandos SQL fora do padrão,
comparado com versões anteriores. Para identificar
incompatibilidades, extraia a DDL da base de dados para um script, e
execute-o no Firebird 3.
Algumas versões mais antigas do Firebird não tratavam
corretamente caracteres especiais (não-ASCII) nas tabelas de sistema.
O gbak das versões 2.1, 2.5 e 3.0 do Firebird identificam esses
problemas ao restaurar um backup, e trazem opções de linha de
comando para corrigi-los na maioria dos casos.
Depois de verificar que uma base de dados está fisicamente e
logicamente consistente, e que sua metadata é compatível com o
padrão usado no Firebird 3, você está pronto para a migração.
O restante desse capítulo descreve em detalhes o que é ODS,
técnicas para identificar potenciais problemas com a metadata e com
o processo de backup/restore, bem como a melhor forma de resolve-
los. Você deve seguir esses passos para todas as bases de dados que
serão migradas para o Firebird 3, minimizando o downtime para seus
usuários.
ODS (On Disk Structure)
Toda base de dados Firebird segue uma estrutura (formato) pré-

definida. O número da ODS (On Disk S tructure) é que determina a
versão da estrutura usada no arquivo da base de dados.
A tabela abaixo mostra as diferentes ODS, de acordo com a versão
do Firebird.
Firebird ODS
1.0 10.0
1.5 10.1
2.0 11.0
2.1 11.1
2.5 11.2
3.0 12.0

54
A ODS é representada por um número no formato MM.m, onde

MM é chamado de Major Version, e m é a Minor Version, por exemplo:
10.1 (M = 10, m = 1).
Para saber qual a ODS de uma base de dados,

utilize o utilitário gstat com o parâmetro -h e
procure pelo valor em “ODS Version”. Para mais
informações sobre ODS, leia o artigo em
www.firebase.com.br/artigo.php?id=2785
Até o Firebird 2.5, todas as versões do Firebird eram capazes de

acessar bases de dados criadas com uma ODS anterior a da versão
utilizada. Por exemplo, você podia usar o Firebird 2.5 para acessar
uma base de dados criada no Firebird 1, sem qualquer problema. No
entanto, o Firebird 3 só acessa bases de dados com a ODS = 12.
O Firebird 3 não consegue acessar bases de dados

criadas em versões anteriores. Apenas bases com
ODS 12 são reconhecidas.
Sendo assim, ao migrar para o Firebird 3, você deverá usar o gbak para
fazer um backup da base de dados usando sua versão atual do Firebird
instalado. Depois, com o Firebird 3 já instalado, deverá fazer um
restore do backup anteriormente gerado, criando uma nova base de
dados com ODS = 12.
A equipe de desenvolvimento do Firebird planeja lançar, em uma
subversão futura, um provider que permita que o Firebird 3 abra bases
de dados com ODS menor que 12 (criadas por versões anteriores do
Firebird). No entanto, não se sabe se isso irá realmente acontecer,
nem quando.
Testando a integridade da base de dados com o gbak
Antes de tentar migrar uma base de dados criada em uma versão

anterior do Firebird, use o gbak para fazer um backup/restore da base.

55
O backup pode ser feito com a base de dados em uso, mas

preferencialmente quando o servidor esteja ocioso, para que os
usuários não sintam diferença na performance (válido especialmente
em casos de bases de dados muito grandes).
Com a versão corrente do Firebird, execute os seguintes passos,
onde usuario é o owner (dono) da base de dados, senha é a senha desse
usuário no Firebird, basedados é o caminho completo para o arquivo
da base de dados no servidor, e arqbackup é o caminho completo para
o arquivo de backup no servidor:
gbak -user usuario -pas senha -b -v -g -se service_mgr
basedados arqbackup
Caso o processo de backup falhe, indicando uma possível

corrupção na base de dados, tire-a do ar, faça uma cópia física do
arquivo por segurança, e use o gfix para validá-la:
gfix -v -full -user usuario -pas senha basedados
Caso o gfix reporte transações em limbo, execute-o novamente,

dessa vez usando o parâmetro -mend.
Alguns tipos de corrupção não podem ser

corrigidas pelo gfix. Nesse caso, sugiro contratar os
serviços de recuperação da FireBase, em
www.firebase.com.br/parceria_ibaid.php.
Quando finalmente conseguir fazer o backup, restaure-o com a

seguinte linha de comando:
gbak -user usuario -pas senha -c -v -se service_mgr arqbackup
basedados
Nunca restaure um backup por cima da base de

dados existente. Geralmente é uma receita para
desastres – restaure usando um nome diferente.
Fique atento à saída durante o processo de restauração! Se o gbak

reportar duplicidade em chaves primárias ou únicas, ou violação de
chaves estrangeiras quando estiver criando os índices dessas chaves,

56
um erro será exibido, mas o processo de restauração não será

interrompido. No final, os índices afetados permanecerão inativos, e
a base de dados será deixada em modo de shutdown single. Você deve
corrigir os problemas manualmente (removendo as duplicidades, etc).
Depois, reative os índices (alter index <nome> active), e coloque
a base de dados online, usando o gfix -online normal.
Corrigir os problemas antes de começar a migração

da base de dados reduzirá o tempo que o servidor
ficará parado.
Problemas com a codificação de caracteres
Se estiver usando o Firebird 2.1 ou 2.5, então faça essa verificação

antes de iniciar a migração. Caso esteja usando uma versão mais antiga
do Firebird, a verificação terá que ser feita no momento de restaurar
o backup no Firebird 3, pois o gbak dessas versões não são capazes
de identificar esses problemas.
O Firebird utiliza o charset UNICODE_FSS para armazenar os
dados nas tabelas de sistema (RDB$...), strings e código fonte de
objetos (procedures, triggers, etc.).
Antes da versão 2.1, existiam bugs que faziam com que o Firebird
não convertesse os caracteres multi-byte enviados pelo cliente para o
padrão UNICODE_FSS, portanto, fazendo com que essas
informações fossem gravadas em um formato inválido nas colunas
declaradas com esse charset.
A partir do Firebird 2.1, esses strings “malformados” começaram a
ser recusados. Nesse caso, se uma base de dados possui esse tipo de
problema, ao tentar restaurá-la, o gbak será interrompido, exibindo
um erro de malformed string, tanto para a metadata como para os dados,
por exemplo:
gbak: ERROR:Malformed string
gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option.
Para resolver o problema, dois parâmetros foram acrescentados ao

gbak do Firebird 2.5, permitindo corrigir os strings malformados
durante o processo de restauração de um backup. O gbak do Firebird

57
2.1 não possui esses parâmetros, sendo necessário utilizar os scripts de

correção localizados na pasta misc/upgrade/metadata.
Para corrigir o problema, verifique se a mensagem de erro
apresentada se refere a problemas nos metadados (metadata) ou nos
dados (data), e repita o processo de restauração, dessa vez utilizando
os parâmetros -fix_fss_metadata e/ou -fix_fss_data na linha de
comando do gbak.
Ambos os parâmetros devem ser seguidos da indicação do charset
que foi usado na criação dos objetos/dados problemáticos (ex:
win1252, utf8, etc.), portanto, é necessário que você saiba em qual
charset a informação original foi enviada para o Firebird.
A opção -fix_fss_data só deve ser usada se houver

tabelas criadas pelo usuário com campos definidos
com o charset unicode_fss.
Esses parâmetros fazem com que os metadados sejam convertidos

do charset informado, e gravados na nova base de dados codificados
corretamente em unicode_fss.
A situação fica um pouco mais complicada se, em uma mesma
base de dados, houver problemas de codificação onde os objetos
tenham sido criados com diferentes charsets. Nesse caso, os
parâmetros “-fix...” não devem ser usados, sendo necessário corrigir
manualmente através da execução dos scripts de correção presentes na
pasta misc/upgrade/metadata da instalação do Firebird 2.1/2.5.
Nunca utilize os parâmetros -fix_fss_metadata e/ou

-fix_fss_data mais que uma vez, em uma mesma base
de dados, ou poderá até mesmo corrompe-la!
Lembre-se: só utilize esses parâmetros caso a tentativa inicial de

restauração de um backup tenha falhado devido ao erro de “malformed
string”! Quando usados sem necessidade, eles podem até mesmo
corromper a base de dados!

58
Certificando sua metadata
É altamente aconselhável, antes de migrar sua base de dados para

o Firebird 3, certificar que a metadata da mesma não possui alguma
incompatibilidade com a nova versão do SGBD. Por exemplo, o uso
de palavras que passaram a ser reservadas em queries, nomes de
variáveis, etc. podem invalidar a metadata do seu banco, e impedir que
sua aplicação funcione corretamente.
Infelizmente, o processo de backup/restore não faz esse tipo de
verificação, ou seja, você só ficará sabendo que o problema existe, ao
tentar executar uma query que contenha uma palavra agora reservada,
ou recompilar o código de procedures/triggers que tenham variáveis
definidas como palavras reservadas.
A forma mais rápida e prática para validar a metadata de uma base
de dados existente é extrai-la para um script, e usar esse script para gerar
uma nova base de dados em um servidor Firebird 3. Qualquer
inconsistência na metadata retornará um erro durante a execução do
script, e você poderá então corrigi-lo da forma que julgar mais
apropriada.
Se a metadata inicial não passou na validação, depois que corrigi-la
(de forma que a base de dados seja criada no Firebird 3 sem erros)
você acabará com uma metadata diferente da original. Nesse caso,
temos duas opções para migrar essa base de dados:
1. Crie um script de alteração de metadata, que corrija os

problemas encontrados, e aplique-o na base de dados
recém restaurada no Firebird 3, ou...
2. Crie a base de dados no Firebird 3 usando o script com a
metadata corrigida, e faça um PUMP dos dados da base
antiga para a base nova, lembrando que, para isso, você
precisará ter o servidor antigo e o novo funcionando ao
mesmo tempo.
Dependendo da complexidade de sua metadata e do tipo de

problema identificado, a opção de PUMP pode ser a saída mais rápida
e simples. A ferramenta IB DataPump pode ser usada para esse
trabalho (www.firebase.com.br/downloads.php?id=67).

59
Aproveite a etapa de migração da base de dados

para o Firebird 3, para certificar que a metadata da
base é totalmente compatível com essa versão do
servidor, evitando surpresas futuras!
Abaixo temos um exemplo de metadata problemática:

CREATE TABLE ATABLE (
CORR INTEGER,
CAMPO_A VARCHAR(100)
);
CREATE TABLE OFFSET (
CAMPO1 INTEGER,
CAMPO2 VARCHAR(100)
);
SET TERM ^ ;
CREATE PROCEDURE TESTE
AS
declare variable OVER integer;
begin
select A.CORR
from ATABLE A
into :OVER;
end^
SET TERM ; ^
As palavras em destaque passaram a ser reservadas no Firebird 3.

No entanto, ao executar um backup no servidor antigo, e um restore no
servidor novo, nenhum erro será retornado! O problema vai aparecer
depois!
A seguir, temos a metadata da mesma base de dados, recém
restaurada no Firebird 3, e extraída pelo isql:
SET SQL DIALECT 3;
/* CREATE DATABASE 'd:\TESTEMETADATA.FB3' PAGE_SIZE 8192
DEFAULT CHARACTER SET WIN1252; */
COMMIT WORK;
SET AUTODDL OFF;
SET TERM ^ ;
/* Stored procedures headers */
CREATE OR ALTER PROCEDURE TESTE AS
BEGIN EXIT; END ^
SET TERM ; ^

60
COMMIT WORK;
SET AUTODDL ON;
/* Table: ATABLE, Owner: SYSDBA */
CREATE TABLE ATABLE ("CORR" INTEGER,
CAMPO_A VARCHAR(100));
/* Table: OFFSET, Owner: SYSDBA */
CREATE TABLE "OFFSET" (CAMPO1 INTEGER,
CAMPO2 VARCHAR(100));
COMMIT WORK;
SET AUTODDL OFF;
SET TERM ^ ;
/* Stored procedures bodies */
ALTER PROCEDURE TESTE AS
begin
select A.CORR
from ATABLE A
into :OVER;
end ^
SET TERM ; ^
COMMIT WORK;
SET AUTODDL ON;
Observe que as palavras (agora reservadas) CORR e OFFSET

passaram a ser mostradas no script automaticamente entre aspas
duplas (“”), mas note que isso só aconteceu quando elas apareceram
em nomes de objetos (como tabelas, campos, procedures, etc.). Repare,
no entanto, que nenhuma “correção automática” foi feita pelo isql ao
exibir o código da procedure TESTE, que referencia as palavras
(agora) reservadas CORR e OVER!
Isso não impedirá que a procedure seja executada com sucesso no
Firebird 3, já que o processo de backup/restore não recompila as
procedures e triggers, permanecendo, portanto, a BLR (Binary Language
Reference - versão compilada da rotina) criada no servidor anterior.
Mas veja o que acontece ao tentar criar uma nova base de dados
no Firebird 3, usando esse mesmo script extraído pelo isql:
C:\firebird3>isql -i d:\script.sql
Dynamic SQL Error
-SQL error code = -104
-Token unknown - line 2, column 18
-OVER
At line 33 in file d:\script.sql

61
O script não pôde ser executado com sucesso, parando na linha 33,
que neste caso, é:
Problema semelhante iria acontecer se o DBA tentasse alterar o

código da procedure TESTE, sem adaptar o código de forma a usar
aspas duplas ao referenciar a variável OVER e o campo CORR:
ALTER PROCEDURE TESTE AS

declare variable "OVER" integer;
begin
select A."CORR"
from ATABLE A
into :"OVER";
end ^
A certificação da metadata garante que ela está

compatível com o Firebird 3, mas não garante que
sua aplicação está livre de problemas. É necessário
validar também os selects, updates, etc. codificados
diretamente na aplicação, para evitar problemas
semelhantes aos descritos anteriormente.
Para mais informações, veja o item “Palavras reservadas” no

capítulo “Firebird 3 e aplicações existentes”.
Lembre-se que ao referenciar objetos usando aspas

duplas, eles se tornam sensíveis a
maiúsculas/minúsculas (case sensitive), portanto,
você deve referencia-los escrevendo-os exatamente
da mesma forma que foram declarados.

62
Migrando a base de dados para o Firebird 3
Caso tenha seguidos os passos de validação descritos

anteriormente, recomendo a seguinte sequência de operações, para
migrar uma base de dados para a ODS 12:
Ainda com a versão corrente do Firebird instalada, execute os
passos a seguir, onde usuario é o owner (dono) da base de dados, senha
é a senha desse usuário no Firebird, basedados é o caminho completo
para o arquivo da base de dados no servidor, e arqbackup é o caminho
completo para o arquivo de backup no servidor:
1. Tire o Firebird do ar.

2. Renomeie a base de dados para qualquer outro nome, a
fim de impedir que novas conexões aconteçam e alterem
os dados durante o processo de migração.
3. Coloque o Firebird no ar novamente.
4. Faça o backup da base de dados:
gbak -user usuario -pas senha -b -v -g -se
service_mgr basedados arqbackup
Lembre-se de tirar o Firebird do ar para fazer uma

cópia física da base de dados, garantindo também
que não haja conexões ativas alterando a base de
dados enquanto o processo de migração está sendo
feito.
Ao fazer um backup com o gbak, ele terá os dados
existentes na base no momento em que o backup foi
iniciado. Por isso é importante renomear a base de
dados, de forma a impedir qualquer novo acesso
que poderia alterar os dados, pois essas alterações
não estariam presentes na base restaurada.
Se você sobrescrever a base de dados original
durante o restore e ocorrer algum problema, caso
não haja uma cópia armazenada, sua base de dados
pode estar perdida.
Instale e inicie o Firebird 3. Se estiver mantendo a mesma máquina

servidora, remova o Firebird anterior antes de instalar o Firebird 3.
Caso pretenda manter as duas versões do Firebird gravadas no

63
servidor, lembre-se de desativar um dos serviços e não executá-los ao

mesmo tempo. Se quiser manter as duas versões em execução
simultânea, será necessário configura-las manualmente, de forma que
usem portas tcp/ip e nomes de serviços diferentes. Mais informações
sobre o processo de instalação do Firebird 3 podem ser vistas no
capítulo que trata desse assunto.
Antes de restaurar a base de dados no Firebird 3,

lembre-se de já ter inicializado a base de dados de
segurança, criando os usuários necessários.
1. Restaure o backup anteriormente criado: gbak -user usuario

-pas senha -c -v -se service_mgr arqbackup basedados
2. Se nenhum erro foi apresentado no final do processo,
então você já tem uma base com a ODS 12 que pode ser
usada no Firebird.
O parâmetro -se service_mgr faz com o backup

seja executado dentro do processo do Firebird, via
API de serviços, o que pode dar um ganho de
velocidade de até 30% em relação ao tempo normal
do backup/restore, sem o uso desse parâmetro.
Lembre-se que ao usar a API de serviços, o arquivo
de backup será gerado localmente em um drive do
servidor, portanto, ao passar o caminho para a base
de dados e para o arquivo de backup, tenha certeza
de estar informando um caminho válido no
servidor.
Migrando servidores 24x7
A migração de servidores 24x7 em produção sem a possibilidade

de downtime, ou seja, que não podem ficar fora do ar, requer um
esforço extra no processo de migração. Como já foi mencionado, o
Firebird 3 não consegue abrir bases de dados com ODS menor que
12, obrigando o usuário a fazer um backup/restore a fim de atualizar a

64
estrutura da base de dados. O problema é que, dependendo do

tamanho da base de dados, esse processo pode demorar horas para
completar! Se o sistema não tiver uma “janela de tempo livre” para
que o processo seja realizado, a situação fica complicada.
A sugestão para esses casos é implementar um esquema de
replicação de dados. Dessa forma, os dados seriam replicados do
servidor “antigo” para o servidor FB 3. No momento desejado,
quando as bases estiverem sincronizadas, as aplicações passariam a
usar o novo servidor, e o antigo seria “aposentado”.
Esse conceito exige um certo trabalho, especialmente para quem
ainda não tem replicação implementada. No entanto, ele traz um
benefício extra, pois a replicação pode se tornar um recurso
permanente, servindo como uma solução de “hot backup”, onde a
réplica poderia ser usada em casos de acontecer algum desastre no
servidor de produção.
Além disso, os dois servidores permaneceriam ativos durante a
migração, e a base réplica poderia ser “testada” para se ter certeza que
as queries usadas pelas aplicações estão rodando perfeitamente no
Firebird 3.
Como acelerar o processo de backup/restore
A seguir listo algumas dicas para tornar o processo de

backup/restore o mais rápido possível:
1. Utilize o parâmetro -g durante o backup, para não perder

tempo com a coleta de lixo, visto que a base será restaurada
logo em seguida;
2. Utilize o parâmetro -se service_mgr, tanto no backup como no
restore, fazendo com que o processo ocorra dentro do
Firebird (mais rápido);
3. Utilize drives SSD (Solid State Drives), que tem uma
velocidade muito maior do que os HDs;
4. Procure não ter outro tipo de atividade consumindo I/O
de disco, durante o processo;
5. Se houver índices em tabelas enormes na base de dados, e
bastante memória RAM no servidor, pode ser interessante
aumentar o parâmetro SortMemSize no firebird.conf do

65
servidor novo, para que o Firebird utilize mais memória

durante a criação dos índices no momento da restauração
do backup. Após a finalização do restore, você pode ajustar
o parâmetro novamente, para um valor mais apropriado
para o uso diário. Cuidado para não exagerar no valor, pois
pode fazer com que o sistema operacional faça swap,
tornando o servidor uma “carroça”.

66
Usuários no Firebird
3
O Firebird 3 introduz grandes mudanças no gerenciamento de
usuários e no papel do SYSDBA, prepara-se para renovar seus
conceitos!
Usuários no Firebird 3
67
O Firebird 3 trouxe mudanças significativas em relação ao

gerenciamento de usuários do SGBD. Até a versão 2.5, os usuários
do Firebird eram sempre centralizados por servidor, ou seja, eram
criados no arquivo isc4.gdb, security.fdb e security2.fdb (dependendo da
versão do Firebird utilizada).
O arquivo de segurança padrão do Firebird 3 se

chama security3.fdb
O modelo de usuários centralizados traz seus prós e contras.

Vejamos:
Prós: O gerenciamento de usuários pode ser simplificado,

especialmente em casos onde há múltiplas bases de dados no servidor,
acessadas pelos mesmos usuários. Nesse caso, basta criar o usuário
uma única vez, e atribuir os direitos de acesso aos objetos da base de
dados conforme desejado, em cada base de dados. Ou seja, não é
necessário criar o mesmo usuário repetidamente nas diferentes bases
de dados que ele irá acessar, simplificando, portanto, o gerenciamento
dos mesmos.
Contras: Qualquer usuário existente consegue logar em qualquer

base de dados do servidor, bastando para isso saber o alias ou o
caminho de acesso ao arquivo. Apesar do acesso aos objetos da base de
dados (tabelas, views, procedures, etc.) ser controlado através de grants,
não há como impedir, por exemplo, que algum usuário crie novos
objetos na base de dados.
Fica claro, portanto, que se ganha na facilidade de gerenciamento,

mas se perde no controle de quais bases de dados o usuário pode
acessar e, consequentemente, na segurança.
Não há como migrar a base de dados de

segurança das versões anteriores do Firebird,
para o Firebird 3. Portanto, todos os usuários
deverão ser recriados no Firebird 3.
68
Usuários locais
O Firebird 3 introduz o conceito de usuários locais, por base de

dados. Nele, é possível definir que os usuários ficarão armazenados
localmente, no mesmo arquivo da base de dados, ou até mesmo em
uma base de dados independente, e não mais de forma centralizada,
no security3.fdb.
Para que isso seja possível, uma estrutura de tabelas similar à do
security3.fdb existe em qualquer base de dados com a ODS 12.
Note que o Firebird 3 permite nomear a base de dados de
segurança com qualquer nome desejado, ou seja, você pode definir
que sua base de dados central de usuários não se chamará security3.fdb
(que é o padrão), e sim centralusers.fdb, e definir até mesmo que ela
ficará armazenada em um diretório específico do servidor, diferente
do diretório padrão de instalação do FB.
Tudo isso é possível devido a introdução de um novo parâmetro
chamado SecurityDatabase . Por padrão, esse parâmetro vem
definido no firebird.conf como $(root)/security3.fdb, significando que o
arquivo de segurança ficará armazenado na raiz da instalação do
Firebird, e se chamará security3.fdb. Note que esse parâmetro também
pode ser definido por base de dados, no arquivo databases.conf (antigo
aliases.conf), permitindo especificar um arquivo de segurança
individualmente, para cada base de dados!
Abaixo temos um exemplo de um databases.conf definindo três
apelidos para três bases de dados (base1, base2 e base3). A base1 está
configurada de forma que a lista de usuários ficará armazenada no
arquivo c:\DBUsers\usuarios_base1.fdb. Já a base2 está configurada de
forma que ela mesmo armazenará a lista de usuários, de forma local.
A base3 está configurada apenas com o apelido, portanto, seus
usuários ficarão armazenados no BD de segurança padrão, definido
no firebird.conf.
base1 = c:\bancos\base1.fdb
{
SecurityDatabase = c:\dbUsers\usuarios_base1.fdb
}
{
SecurityDatabase = base2
}
69
A especificação da base de dados de segurança no

parâmetro SecurityDatabase pode ser feita através do
apelido ou especificando o caminho completo para
o arquivo.
Lembre-se que um arquivo de segurança sempre foi, e continua

sendo, uma base de dados “normal” do Firebird. Sendo assim, para
criar uma nova base de dados de segurança, basta criar uma base de
dados, usando, por exemplo, o isql:
C:\firebird3> isql -user sysdba
SQL> create database ' c:\DBUsers\usuarios_base1.fdb';
Observe a necessidade de entrar no isql usando o parâmetro -user

sysdba, mesmo que ainda não exista um sysdba criado.
Sua base de dados de segurança foi criada, no entanto, ela não
contém qualquer usuário, nem mesmo o SYSDBA! Sendo assim, o
próximo passo é criar nela o usuário SYSDBA, ou qualquer outro
usuário desejado:
SQL> connect base1;
SQL> create user sysdba password 'minhasenha’;
SQL> commit;
SQL> exit;
A sequência de comandos acima conecta na base de dados recém

criada, e cria um usuário chamado sysdba com a senha definida como
minhasenha. Note que o nome do usuário não é sensível a
maiúsculas/minúsculas, mas a senha é, portanto, preste atenção!
O Firebird 3 nem mesmo requer a existência de um

usuário chamado SYSDBA! Para bases de dados
onde o SYSDBA não existe na lista de usuários, o
owner da base de dados (ou seja, quem a criou) é
considerado o usuário “administrador” dela.
70
Senhas
Diferente do que você possa pensar, as senhas dos usuários não

são armazenadas na base de dados de segurança! Ao invés disso, o
Firebird armazena um hash da senha informada, tornando impossível,
por exemplo, recuperar uma senha propriamente dita, pois ela não
fica gravada em nenhum lugar! Quando você loga no Firebird, ele
compara o hash da senha usada para login com o hash armazenado na
base de segurança.
É importante lembrar que, até a versão 2.5, apenas os oito
primeiros caracteres/bytes da senha eram considerados no cálculo do
hash. Se uma senha tivesse mais de 8 caracteres, todos os caracteres a
partir do nono (inclusive) eram ignorados!
No Firebird 2.0, o algoritmo usado para calcular o hash passou a
ser o SHA1 (anteriormente, era o DES – Data Encryption Standard),
aumentando a segurança, mas mantendo a mesma limitação de
considerar apenas 8 caracteres no cálculo.
Até a versão 2.5, quando você definia uma senha

como ‘masterkey’, para calcular o hash da senha, era
considerado apenas ‘masterke’, ou seja, você
conseguiria logar com esse usuário digitando a
senha como masterkey, masterke1234,
masterkeeeeeee, etc.
O Firebird 3 passa a considerar, para o cálculo do hash, até 255

caracteres da senha! A exceção é se você configurar o FB 3 para usar
o esquema de autenticação legada (LegacyAuth), ao invés da padrão
(SRP). Nesse caso, ele continuará a usar apenas os 8 primeiros
caracteres.
Não use senhas curtas, muito menos senhas obvias

como, por exemplo, “12345”, “senha”, nomes ou
datas de aniversário. Uma senha de cinco caracteres
pode ser descoberta em segundos, através de um
ataque de força bruta, enquanto uma senha de dez
caracteres poderia levar séculos para ser quebrada.
Encoraje os usuários a usar senhas misturando
71
caracteres maiúsculos e minúsculos, além de

símbolos ($, %, @, etc). O uso de geradores de
senha também pode ajudar na definição de uma
senha aleatória segura.
Recomendo usar apenas caracteres ASCII na

definição de usuários e senhas. Apesar do Firebird
3 aceitar usuários e senhas definidos com caracteres
multi-byte (ex: UTF8, etc.), isso não foi amplamente
testado, e exige uma atenção redobrada no sentido
de que a página de código utilizada no ambiente
(sistema operacional) seja a mesma do charset
utilizado no SQL da aplicação cliente (set names). A
“complicação” aumenta ainda mais no Windows,
onde o console (prompt de comando) geralmente
usa uma página de código diferente da usada pelas
aplicações GUI. No Brasil, por exemplo, o prompt
de comando do Windows usa a página de código
850, e as aplicações GUI usam a 1252.
Inicializando a base de dados de segurança
O instalador do Firebird permite criar e definir a senha do

SYSDBA durante o processo de instalação. No entanto, caso ocorra
algum problema durante a criação do mesmo, ou caso você não esteja
usando o instalador, então a base de segurança estará “vazia” (sem
usuários definidos, nem mesmo o SYSDBA).
Existem duas maneiras de inicializar a base de dados de segurança,
criando, por exemplo, um SYSDBA.
A primeira delas utiliza o utilitário gsec. Para tanto, siga os seguintes
passos:
1. Tenha certeza que o processo do Firebird não esteja em

execução.
2. Abra um prompt de comando e, no diretório de instalação
do Firebird 3, digite:
gsec -user SYSDBA
72
gsec>add SYSDBA -pw masterkey

gsec>quit
Um usuário chamado SYSDBA será criado com a senha masterkey.

Note que, por mais estranho que possa parecer, é necessário chamar
o gsec passando como usuário o SYSDBA (-user sysdba), mesmo ele
ainda não existindo!
O uso do gsec no Firebird 3 não é mais aconselhado,

visto que agora é possível gerenciar os usuários
através de comandos SQL. O gsec, bem como a API
de Serviços, só funcionam para gerenciar usuários na
base de dados de segurança padrão.
A segunda forma de se inicializar a base de segurança, sem usar o

gsec, é através do isql e dos novos comandos SQL de gerenciamento
de usuários. Para tanto, é necessário estar conectado à alguma base de
dados já existente. Felizmente, a instalação padrão do Firebird já traz
uma base de exemplo (employee.fdb), portanto, podemos conectar nela.
Mas como conectar em uma base de dados, sendo que ainda não
existem usuários criados no Firebird?! Simples! Conectaremos através
de uma conexão embarcada (embedded), pois na conexão embarcada, o
Firebird não faz a validação das credenciais de login! Siga os passos
abaixo, para inicializar a base de dados de segurança:
1. Tenha certeza que o processo do Firebird 3 não está em

execução. Isso garante que a conexão ao employee.fdb será
feita no modo embarcado.
2. Abra um prompt de comando, e chame o isql como no
exemplo abaixo:
isql -user SYSDBA employee
SQL>create user SYSDBA password 'masterkey';
SQL>commit;
SQL>quit;
3. Inicie o Firebird.
Observe que chamamos o isql passando apenas employee, ao invés

do caminho completo para a base de dados employee.fdb. Isso se deve
73
ao fato do Firebird 3 já vir com um apelido (alias) configurado como

employee no databases.conf, apontando para a base de dados de exemplo.
Sempre que um usuário é criado com o nome de SYSDBA, ele
assume automaticamente direitos de administrador, portanto, não é
necessário atribuir o role RDB$ADMIN a ele.
Apesar de usarmos a senha masterkey nos exemplos

desse livro, é altamente aconselhado que não se
use essa senha em servidores em produção,
pois ela é de conhecimento público e, portanto, não
oferece qualquer segurança!
Gerenciamento de usuários via SQL
O Firebird 3 traz um conjunto completo de instruções SQL para

gerenciamento de usuários. Indo mais além, com a nova possibilidade
de ter diferentes bases de dados de segurança, o uso do SQL torna-se
a única forma de gerenciar usuários definidos em bases de segurança
que não seja a padrão (security3.fdb).
Abaixo temos o conjunto de instruções SQL específicas para o
gerenciamento de usuários:
CREATE USER nome {PASSWORD ‘senha’} [ options ]
[ TAGS ( tag [, tag [, tag ...]] ) ] [USING PLUGIN nome]
ALTER USER nome SET [PASSWORD ‘senha’] [ options ]
ALTER CURRENT USER SET [PASSWORD ‘senha’] [ options ]
CREATE OR ALTER USER nome SET [PASSWORD ‘senha’] [ options ]
DROP USER nome [USING PLUGIN nome];
Onde OPTIONS pode ser:

FIRSTNAME 'string value'
MIDDLENAME 'string value'
LASTNAME 'string value'
ACTIVE
INACTIVE
74
Observe a clausula USING PLUGIN, disponível de forma

opcional em cada um dos comandos. Através dela, é possível indicar
qual plug-in de gerenciamento de usuários será usado na ação do
comando.
O parâmetro UserManager pode ser configurado tanto no
firebird.conf como a nível de banco de dados (no databases.conf), e indica
qual é o plug-in padrão usado para gerenciar os usuários na base de
segurança. Se for informado mais que um, o primeiro da lista é
considerado o plug-in padrão.
Ao gerenciar usuários via SQL, é necessário que

você esteja logado em uma base de dados já
existente. A base de dados de segurança onde os
usuários serão gerenciados é aquela definida no
firebird.conf, ou no arquivo databases.conf, quando a
base de dados conectada fizer uso de uma base de
segurança própria.
O plug-in padrão de gerenciamento de usuários no Firebird 3 é o

SRP.
Criando usuários
A criação de um novo usuário se dá através do comando create user

ou create or alter user.
Quando se cria um usuário, é necessário, no mínimo, passar a
senha que será utilizada pelo mesmo. Outros atributos, como o
firstname (primeiro nome), active, etc. são opcionais.
Pela primeira vez no Firebird, temos a opção de ativar ou desativar
usuários, e de definir tags atribuindo um nome e/ou valor para elas.
Um usuário desativado continua existindo na base de segurança,
nas não conseguirá mais se logar. Durante a criação do usuário,
podemos determinar se ele será criado ativado ou desativado, através
do uso da cláusula active ou inactive.
Apenas o SYSDBA pode criar novos usuários. A

exceção são usuários para os quais foram
75
atribuídos o role rdb$admin na base de dados

de segurança, e estejam logados com esse role.
Abaixo temos alguns exemplos de criação de usuários. Os

comandos podem ser executados em qualquer cliente SQL, incluindo
o isql, que acompanha o Firebird. Lembre-se que tudo que vem depois
de um “--” é tratado como comentário:
create user Albert password 'e=mc2'; -- cria um usuário Albert
com a senha e=mc2.
create user Albert password 'e=mc2' firstname 'Albert' lastname

'Einstein' inactive; -- cria um usuário Albert com a senha
e=mc2, e atribui o primeiro nome (Albert) e o último nome
(Einstein), deixando o usuário inativo (sem poder se logar).
create user Albert password 'e=mc2' inactive tags

(grau='genio', especialidade = 'matematica');
O comando acima cria o usuário Albert e especifica duas tags à ele.

A primeira tag foi chamada grau, e definida como ‘genio’, e a segunda
tag foi chamada de especialidade, e definida como ‘matematica’. As tags
atribuídas ficam associadas ao usuário (Albert), podendo ser
consultadas, modificadas ou removidas quando necessário.
Os valores atribuídos as tags são do tipo varchar, e

não podem exceder o limite de 255 bytes.
Os nomes dos usuários não são sensíveis à

maiúsculas/minúsculas. Na verdade, eles sempre
serão armazenados em maiúsculas, sendo que
ao se fazer o login, o Firebird compara o usuário
informado convertendo-o para maiúsculas. O
mesmo não é válido para as senhas, onde
maiúsculas/minúsculas fazem toda a
diferença.
76
Alterando usuários
Apenas o SYSDBA, ou um usuário logado com o role rdb$admin e

que tenha esse role atribuído na base de dados de segurança, pode
alterar outros usuários. Um usuário “comum” pode alterar apenas
suas próprias informações, limitando-se ao nome completo, senha e
as tags.
Exemplo de alterações de usuários:
alter user albert active; -- torna o usuário albert ativo.
alter user albert set tags (especialidade = 'fisica'); --

altera o usuário albert, especificando a tag chamada
“especialidade” com o valor “física”.
alter user albert set tags (drop especialidade); -- remove a

tag “especialidade” no usuário albert.
No caso do usuário logado desejar alterar suas próprias

informações, pode-se usar a forma simplificada do comando, como
no exemplo abaixo:
alter current user set password 'mestre'; -- altera a senha do
usuário logado para “mestre”.
Removendo usuários
O comando responsável por apagar usuários previamente criados

é o DROP USER. Apenas o SYSDBA, ou um usuário logado com o
role rdb$admin e que tenha esse role atribuído na base de dados de
segurança, pode apagar usuários.
O comando abaixo remove o usuário albert, criado anteriormente:
drop user albert;
Não se esqueça de dar um commit após os comandos

de manipulação de usuários, para que a ação seja
efetivada. Caso utilize a opção set ddl do isql, os
comandos serão “commitados” automaticamente).
77
Tabelas sec$users e sec$user_attributes
Duas novas tabelas “virtuais” estão disponíveis no Firebird 3,

permitindo listar os usuários existentes, e também seus atributos.
Abaixo temos a estrutura da tabela sec$users:
SQL> show table sec$users;
SEC$USER_NAME (RDB$USER) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
SEC$FIRST_NAME (SEC$NAME_PART) VARCHAR(32) CHARACTER SET UNICODE_FSS Nullable
SEC$MIDDLE_NAME (SEC$NAME_PART) VARCHAR(32) CHARACTER SET UNICODE_FSS Nullable
SEC$LAST_NAME (SEC$NAME_PART) VARCHAR(32) CHARACTER SET UNICODE_FSS Nullable
SEC$ACTIVE (RDB$BOOLEAN) BOOLEAN Nullable
SEC$ADMIN (RDB$BOOLEAN) BOOLEAN Nullable
SEC$DESCRIPTION (RDB$DESCRIPTION) BLOB segment 80,
subtype TEXT CHARACTER SET UNICODE_FSS Nullable
SEC$PLUGIN (RDB$PLUGIN) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
O nome dos campos são auto-explicativos, mas dois merecem

atenção especial:
SEC$ADMIN – quando true, indica que o usuário possui o role

rdb$admin na base de dados de segurança podendo, portanto,
gerenciar outros usuários;
SEC$PLUGIN – especifica qual plug-in de gerenciamento de
usuários está associado ao usuário em questão;
O Firebird 3 permite o uso de vários plug-ins de

gerenciamento de usuários (ex: SRP,
LegacyUserManager, etc.). Isso faz com que exista a
possibilidade da tabela sec$admin retornar usuários
“repetidos”, por exemplo, você pode ter dois
SYSDBAs, um gerenciado pelo SRP e outro pelo
LegacyUserManager.
Abaixo temos a estrutura da tabela sec$user_attributes,

responsável por armazenar as tags (atributos) definidos para os
usuários:
SQL> show table sec$user_attributes;
SEC$USER_NAME (RDB$USER) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
SEC$KEY (SEC$KEY) VARCHAR(31) CHARACTER SET UNICODE_FSS Nullable
SEC$VALUE (SEC$VALUE) VARCHAR(255) CHARACTER SET UNICODE_FSS Nullable
SEC$PLUGIN (RDB$PLUGIN) CHAR(31) CHARACTER SET UNICODE_FSS Nullable
78
Sendo que:
sec$user_name – armazena o nome do usuário;
sec$key – armazena o nome da tag
sec$value – armazena o valor da tag
sec$plugin – armazena o nome do plugin de gerenciamento de
usuários
As tabelas permitem recuperar via select, as informações de

qualquer usuário desejado. Abaixo temos um exemplo do resultado
de um select, executado pelo SYSDBA:
SELECT U.SEC$USER_NAME as LOGIN, A.SEC$KEY as TAG,
A.SEC$VALUE as "VALUE", U.SEC$PLUGIN "PLUGIN"
FROM SEC$USERS U
LEFT JOIN SEC$USER_ATTRIBUTES A ON (U.SEC$USER_NAME =
A.SEC$USER_NAME) and (U.SEC$PLUGIN = A.SEC$PLUGIN);
Exemplo de retorno:
LOGIN TAG VALUE PLUGIN
=========== ================ ============= ==================
SYSDBA <null> <null> Srp
SYSDBA <null> <null> Legacy_UserManager
ALBERT ESPECIALIDADE matematica Srp
ALBERT GRAU genio Srp
JOAO <null> <null> Srp
Abaixo, o resultado do mesmo select, dessa vez executado pelo

usuário Albert, logado sem o role rdb$admin, ou seja, como um
usuário “comum”. Observe que são retornadas apenas as
informações sobre ele mesmo:
============ ================== ======= ========
A seguir, o resultado do mesmo select, novamente executado pelo

usuário Albert, mas dessa vez logado com o role rdb$admin:
79

======== =============== ============= ====================
SYSDBA <null> <null> Srp
SYSDBA <null> <null> Legacy_UserManager
JOAO <null> <null> Srp
Notou que o resultado obtido é exatamente o mesmo do sysdba?

Fica constatado que atribuir o role rdb$admin à um usuário comum,
lhe dá poderes de “SYSDBA”.
A coluna MON$SEC_DATABASE foi

adicionada à tabela MON$ATTACHMENTS, e
retorna o tipo de base de dados de segurança que
está sendo usada na conexão:
• Default: security3.fdb;
• Self: a própria base de dados armazena os
usuários;
• Other: uma base de dados de segurança
específica;
Preparando um script para inserção de usuários no

novo servidor
Infelizmente, não é possível “migrar” a base de dados de segurança

das versões anteriores para o Firebird 3. Isso significa que todos os
usuários existentes terão que ser criados no Firebird 3!
Para aqueles que fazem o controle de usuários armazenados
localmente em suas aplicações (os usuários existem dentro da
aplicação, e não como usuários do Firebird) e usam sempre o mesmo
usuário para se logar no Firebird, a tarefa é simples, pois haverá um
número reduzido de usuários a serem criados na base de dados de
segurança do Firebird 3. Provavelmente, apenas o SYSDBA e mais
alguns poucos. Já para quem faz o controle de usuários no próprio
Firebird, haverá provavelmente algumas dezenas/centenas de
usuários para serem criados.
80
Sendo assim, recomendo que antes de migrar de servidor, seja

preparando um script de criação dos usuários. Agora que o Firebird
permite o gerenciamento de usuários via SQL, essa tarefa fica bem
mais fácil!
Para obter a lista de todos os usuários criados no servidor Firebird
anterior, podemos recorrer ao gsec, conforme exemplo abaixo:
C:\firebird25\bin>gsec -display -database c:\firebird25\security2.fdb

user name uid gid admin full name
------------------------------------------------------------------------------
SYSDBA 0 0 Sql Server Administrator
JOAO 0 0
JOSE 0 0
MARIA 0 0
Podemos redirecionar a saída do gsec para um arquivo texto, e

depois editar esse arquivo texto, de forma a deixar apenas os nomes
dos usuários, e inserir manualmente o comando CREATE USER e
as senhas, linha a linha, ficando algo como:
create user JOAO password ‘senha_joao’;

create user JOSE password ‘senha_jose’;
create user MARIA password ‘senha_maria’;
commit; -- Não esqueça do COMMIT!
Infelizmente (ou melhor, felizmente!), não há como recuperar as

senhas dos usuários existentes, portanto, caso você saiba a senha dos
mesmos, terá que informá-las manualmente no script, ou poderá
definir uma senha padrão e orientar os usuários a alterarem-na
posteriormente.
Outra forma de obter a lista de usuários é conectando diretamente
no arquivo security2.fdb e obte-la através de select. O problema é que,
nas versões mais recentes do Firebird, não é mais possível conectar
na base de segurança que está em uso. Podemos contornar isso
tirando o Firebird do ar e copiando a base de dados de segurança para
outro diretório, e depois conectando na cópia para recuperar os
usuários através de um select, que também será responsável por montar
as linhas do script:
81
select 'create user ' || R.RDB$USER_NAME ||

' password ''' || cast(cast(trunc(rand() * 1000000000) as
integer) as varchar(10)) || '''' ||
coalesce(' firstname ''' || R.RDB$FIRST_NAME || '''', '') ||
coalesce(' middlename ''' || R.RDB$MIDDLE_NAME || '''', '') ||
coalesce(' lastname ''' || R.RDB$LAST_NAME || '''', '') || ';'
from RDB$USERS R;
Esse método tem a vantagem de permitir extrair também o primeiro

nome, nome do meio, e último nome, quando essas informações existirem.
Além disso, podemos atribuir para cada usuário criado, uma nova
senha “randômica”. No exemplo, uma senha numérica aleatória será
gerada para cada usuário, através do uso da função interna RAND().
O resultado seria algo do tipo:
create user SYSDBA password '871892958' firstname 'Sql'
middlename 'Server' lastname 'Administrator';
create user JOAO password '671411450';
create user JOSE password '723543343';
create user MARIA password '140440819';
commit; -- Não esqueça do COMMIT!
Lembre-se de inicializar a base de segurança do Firebird 3, antes

de executar o script de criação de usuários. Remova o SYSDBA do
script gerado, visto que a base de segurança já foi inicializada e,
portanto, o SYSDBA já existe.
Não esqueça de dar um commit no final do script, para que os
usuários sejam de fato criados.
Em versões muito antigas do Firebird, as funções

RAND e TRUNC não existem nativamente. Nesse
caso, é necessário usar funções similares,
disponíveis através de UDFs.
O script de criação de usuários pode ser usado para

cria-los tanto na base de dados de segurança
padrão, como em bases de dados específicas, ou até
mesmo localmente, dentro da base de dados da
aplicação, quando a mesma estiver configurada
para ser sua própria base de segurança.
82
Caso pretenda utilizar o Firebird 3 com

autenticação legada, ao invés da padrão (SRP),
tenha certeza que ao criar os usuários, o servidor já
esteja configurado para usar o plug-in
Legacy_UserManager. Você também pode especificar
explicitamente o plug-in a ser usado, em cada create
user do script, através da cláusula using plugin
Legacy_UserManager.
A partir do Release Candidate 2 do Firebird 3, foi adicionado ao

pacote um script de criação de usuários (security_database.sql), que usa
um método semelhante ao descrito anteriormente, mas age de uma
forma um pouco diferente.
Para usar o script security_database.sql que acompanha o Firebird,
proceda da seguinte forma:
1. No servidor antigo, faça um backup da base de dados de

segurança (ex: security2.fdb) usando o gbak, ex:
gbak -b -user SYSDBA -pas masterkey
{host/path}security2.fdb security2.gbk
2. No Firebird 3, restaure o backup anteriormente criado:
gbak -c -user SYSDBA -pas masterkey security2.gbk
{host/path}security2-ods12.fdb
3. Execute o script de migração de usuários:
isql -user sysdba -pas masterkey -i
security_database.sql {host/path}security2-ods12.fdb
O script de migração pode ser visto abaixo, com alguns

comentários sobre o que está sendo feito:
set term ^;
execute BLOCK returns(USR varchar(31), PASSWD varchar(36))
as
declare variable FRST varchar(32);
declare variable MDDL varchar(32);
declare variable LST varchar(32);
declare variable ATTR varchar(4096);
declare variable SQL varchar(4096);
declare variable UID int;
declare variable GID int;
begin
-- Recupera os campos referente ao nome completo do usuario
for select RDB$USER_NAME, RDB$FIRST_NAME, RDB$MIDDLE_NAME,
RDB$LAST_NAME,
RDB$UID, RDB$GID, UUID_TO_CHAR(GEN_UUID())
83
from RDB$USERS
where RDB$USER_NAME is not null and
upper(RDB$USER_NAME) != 'SYSDBA' -- pula o usuário
SYSDBA
into :USR, :FRST, :MDDL, :LST, :UID, :GID, :PASSWD
do
begin
-- Monta o SQL de criacao de usuarios
SQL = 'create or alter user ' || USR || ' password ''' ||
PASSWD || '''';
if (FRST is not null) then
SQL = SQL || ' firstname ''' || FRST || '''';
if (MDDL is not null) then
SQL = SQL || ' middlename ''' || MDDL || '''';
if (LST is not null) then
SQL = SQL || ' lastname ''' || LST || '''';
SQL = SQL || ' active';
-- recupera o GID se houver
ATTR = '';
if (UID is not null) then
ATTR = 'uid=''' || UID || '''';
if (GID is not null) then
begin
if (char_length(ATTR) > 0) then
ATTR = ATTR || ', ';
ATTR = ATTR || 'gid=''' || GID || '''';
end
if (char_length(ATTR) > 0) then
begin
SQL = SQL || ' tags (' || ATTR || ')';
end
execute statement SQL; -- cria o usuario
suspend; -- retorna o usuario e a senha gerada
end
end^
commit ^
exit ^
O script lê os usuários existentes na base de securança “antiga”,

recuperando os nomes e atributos, e cria esses mesmos usuários no
Firebird 3, com uma senha aleatória gerada pela função interna
gen_uuid. Quando executado, o script exibirá o nome dos usuários e as
respectivas senhas recém criadas. Observe que o script está
configurado para não migrar o SYSDBA.
Escolha o método de migração que julgar mais interessante/
conveniente, de acordo com sua necessidade.
84
Protegendo os
dados armazenados
Saiba porque o assunto é muito mais complexo do que parece, e a
solução pode se estender além do próprio Firebird...
Protegendo os dados armazenados

85
Um assunto polêmico e controverso entre os usuários do Firebird

sempre foi “como proteger a base de dados” contra “ladrões” ou
“abelhudos”. O tema, que por si só já é complexo, fica ainda pior
quando estamos falando de SGBDs de código aberto, afinal, se
qualquer um pode ter acesso ao código fonte do Firebird, baixa-lo,
altera-lo (inclusive removendo partes do código envolvidas na
segurança dos dados) e compila-lo, gerando uma versão
“personalizada”, como poderíamos proteger as informações?
Apesar do assunto não ser diretamente parte do propósito desse
livro (migração para o Firebird 3), decidi escrever algo sobre ele.
É fato que o Firebird 3 trouxe melhorias na segurança, como a
criptografia dos dados trafegados pela rede, usuários locais na base de
dados (dando mais independência quando se tem vários BDs em um
mesmo servidor), etc. No entanto, nada disso adianta se o ambiente
onde o servidor se encontra não oferecer o mínimo de segurança
esperada em um ambiente empresarial.
Infelizmente, para piorar a situação, é comum encontrarmos o
Firebird instalado em ambientes totalmente “desprotegidos”,
especialmente em pequenos comércios, onde não há qualquer política
de segurança definida, ou nem mesmo um profissional de TI que
cuide do servidor e do ambiente de rede. Para esses, é praticamente
impossível garantir a segurança das informações. Se não há nem
mesmo a preocupação de configurar usuários e permissões de acesso
aos diretórios do servidor, é um contrassenso imaginar que de alguma
forma, qualquer arquivo ou informação armazenada ali estaria segura.
Para piorar a situação, com o passar do tempo, algumas
“gambiarras” foram surgindo, dando uma falsa ilusão de segurança,
especialmente quando a intenção era não deixar o SYSDBA acessar a
base de dados. Por exemplo, o método de criar uma ROLE com o
nome SYSDBA, fazendo com que o Firebird impedisse o login do
mesmo na base de dados, é totalmente ineficiente, sendo muito
simples remover a role editando o arquivo em um editor hexadecimal.
Talvez seja ainda mais simples levar o arquivo para outro servidor e
criar um dos usuários que tem direito de acesso à base, atribuindo a
ele uma senha conhecida. Lembre-se que o Firebird 3 não permite
mais manipular diretamente as tabelas de sistema, portanto, não é
mais possível criar um ROLE chamado SYSDBA.
Outro método totalmente ineficaz é criar um database trigger que
verifique, no momento da conexão, o nome do usuário logado, e caso

86
ele seja o SYSDBA ou qualquer outro usuário “indesejado/não

autorizado”, aborte a conexão imediatamente. O detalhe é que não é
difícil logar na base de dados sem disparar o trigger de conexão, por
exemplo, através do isql -nod, tornando esse tipo de proteção
praticamente inútil.
Fora isso, nenhuma das “gambiarras” descritas impediria que
qualquer um que tivesse acesso físico à base de dados, entrasse nela
através de uma conexão embedded que, como sabemos, não faz
autenticação de usuário.
Fica obvio que essas “gambiarras” podem até dificultar o acesso
dos mais leigos, mas nunca impedir o acesso de alguém experiente.
Criando um ambiente seguro
A primeira dica pode parecer boba, mas visto a imensa quantidade

de servidores que já encontrei por aí, onde quem instalou o Firebird
nem se deu ao trabalho de alterar a senha padrão do SYSBDA, me
obriga a gritar em alto e bom som: Nunca instale o Firebird usando
a senha masterkey! Hoje em dia, qualquer criança com acesso à
internet saberia da existência dessa senha!
Devemos lembrar também que o arquivo de base de dados
Firebird só precisa ser acessível pelo processo do Firebird e,
quando muito, pelo administrador. Exato! A aplicação cliente não
precisa ter acesso físico à base de dados! Usuários “comuns” também
não precisam e nem devem ter acesso físico ao arquivo, impedindo,
por exemplo, que consigam copia-los.
Sendo assim, tão logo um servidor Firebird seja configurado, é
importantíssimo restringir o acesso aos arquivos das base de dados,
impedindo que gatunos consigam copia-la.
Outro cuidado que devemos ter é em relação aos arquivos de
backup. Não adianta restringir o acesso aos arquivos das bases
de dados, se seus backups ficarem armazenados desprotegidos,
em diretórios onde qualquer um tenha acesso, ou gravados em
CDs/DVDs jogados em cima da mesa.
Não deixe que usuários comuns tenham acesso ao console
do servidor, e garanta que eles não saibam a senha do
administrador do sistema operacional!

87
Criptografando a base de dados
O Firebird 3 traz um novo recurso que permite a criptografia das

bases de dados. Através do uso de um plug-in de criptografia, é
possível fazer com que o Firebird grave as páginas de dados, blobs e
de índices de forma criptografada.
No entanto, um dos fatores mais importantes que garantem a
eficácia de qualquer proteção via criptografia, além do próprio
algoritmo utilizado, é a senha! Um “gatuno” pode até mesmo roubar
o arquivo da base de dados, mas será impossível acessar as
informações se ele não tiver acesso ao plug-in de criptografia
utilizado, e saiba a senha criptográfica.
Tão importante quanto a força do algoritmo

criptográfico, é como tratar o armazenamento da
senha. Abaixo alguns cenários possíveis, e seus
inconvenientes:
Hardcoded no plug-in de criptografia: Hacker rouba a

DLL do plug-in, levando a chave junto.
Hardcoded nos softwares clientes: Hacker decodifica o

binário e tem acesso à chave
Armazenar em dispositivo externo (ex: pendrive, token usb,

etc): Hacker rouba o dispositivo e a DLL do plug-in
e tem acesso.
Usar um dispositivo de criptografia externo (ex: HSM):

Rouba a DLL do plug-in e o dispositivo e terá
acesso.
Digitada manualmente ao carregar o plug-in: Depende da

pessoa estar disponível. Passível de erros de
digitação
Propositalmente, o Firebird 3 não traz qualquer plug-in “padrão”

para criptografia de base de dados. Essa decisão foi tomada devido à

88
natureza Open Source do projeto. Se o código de um plug-in de

criptografia está disponível publicamente, qualquer um poderá baixa-
lo, estuda-lo, entender como ele trabalha com as senhas, etc.
tornando-o ineficaz, ou passando uma falsa sensação de segurança,
onde o usuário se sentiria protegido usando o plug-in padrão, quando
na verdade essa segurança seria ilusória.
Sendo assim, cada desenvolvedor deverá criar seu próprio plug-in
de criptografia, tomando muito cuidado na questão de onde
armazenar/recuperar a senha. É provável que com o passar do
tempo, empresas codifiquem e disponibilizem seus próprios plug-ins,
facilitando a vida daqueles que não quiserem criar suas próprias
soluções.
Apesar de uma instalação típica do Firebird não trazer um plug-in
de criptografia padrão, podemos encontrar um exemplo de tal plug-
in, escrito em C++, no arquivo DbCrypt.cpp, armazenado no
subdiretório examples\dbcrypt, da pasta de instalação do Firebird.
A API de criptografia do Firebird 3 também traz métodos que
facilitam, por exemplo, o fornecimento da senha criptográfica via
aplicação cliente, onde ela seria enviada do cliente para o Firebird
através da rede (em uma conexão criptografada, que é o padrão do
Firebird 3). Um exemplo dessa técnica pode ser visto no arquivo
CryptKeyHolder.cpp, também disponível em examples\dbcrypt. Note, no
entanto, que um hacker experiente poderia criar uma versão
modificada do Firebird, que gravasse em um arquivo qualquer, ou
mesmo no firebird.log, a senha recebida durante a conexão com a base.
Comandos especiais foram criados, permitindo
criptografar/descriptografar bases de dados “on the fly”, sem que seja
necessário acesso exclusivo à base! Ao ativar a criptografia, o Firebird
iniciará o processo de codificação da base, sem que os usuários
conectados percebam, e continuará em background, até que seja
finalizado.
Mesmo que uma base de dados esteja criptografada,

um backup gerado pelo gbak criará um arquivo de
backup sem qualquer tipo de criptografia, portanto,
é importante não deixar que as cópias de segurança
caiam nas mãos erradas.

89
Não faz parte do propósito desse livro ensinar a codificar um plug-

in de criptografia, ou mesmo como utilizar um. Todas as informações
necessárias estão no Release Notes e nos exemplos que acompanham o
Firebird.
Conclusão
Para garantir que seus dados não serão roubados, siga os seguintes
passos:
1. Nunca use a senha masterkey.

2. Restrinja o acesso físico ao arquivo da base de dados
somente para o Firebird e o administrador do sistema.
3. Não deixe os arquivos de backup acessíveis para qualquer
um.
4. Utilize um plug-in de criptografia para codificar a base de
dados, e tenha certeza que os “gatunos” não terão acesso
ao plug-in e à senha de criptografia.
Se o passo 4 for levado a sério, ele somente já impede que os dados

possam ser acessados por pessoas mal intencionadas.

90
Melhorias no
protocolo de
comunicação
Criptografia dos dados trafegados, compressão e otimizações
Melhorias no protocolo de comunicação

91
Criptografia dos dados trafegados
Até o Firebird 2.5, os dados trafegavam pela rede, entre o cliente

e o servidor, de forma totalmente aberta. Através de sniffers, era
possível capturar facilmente os pacotes trafegados, e extrair
informações deles. A solução adotada por alguns era criar uma VPN
criptografada, usando, por exemplo, softwares como o Zebedee (
http://www.winton.org.uk/zebedee). A boa notícia é que o Firebird
3 traz criptografia nativa para os dados trafegados!
De fato, o padrão em uma nova instalação do Firebird 3 é ter a
criptografia no protocolo de comunicação ativada, e recomendo que
assim permaneça.
A criptografia pode ser ligada/desligada através do parâmetro
WireCrypt no firebird.conf. Esse parâmetro pode receber três valores:
• Required – exige criptografia na conexão.

• Enabled – permite conexões criptografadas.
• Disabled – não permite conexões criptografadas.
A definição se a conexão se estabelecerá com ou sem criptografia

se dá na combinação da configuração do parâmetro WireCrypt, tanto
do lado cliente (que está requisitando a conexão), como do servidor.
A tabela abaixo mostra as combinações possíveis:
Cliente Servidor
Disabled Enabled Required
Disabled Desativada Desativada Rejeitada
Enabled Desativada Ativada Ativada
Required Rejeitada Ativada Ativada
Status da criptografia dependendo da configuração do WireCrypt no
cliente e no servidor. As opções destacadas são as padrão.
Conforme podemos ver, o padrão do parâmetro WireCrypt no lado

servidor é Required, o que fará com que todas as tentativas de conexão
sem criptografia sejam rejeitadas. Já no lado cliente, o padrão é
Enabled, fazendo com que o cliente consiga conectar servidores

92
configurados tanto para exigir criptografia, como configurados para

não exigir.
A criptografia padrão utilizada no trafego de dados no Firebird 3
é a RC4 (pt.wikipedia.org/wiki/RC4), sendo possível utilizar outros
padrões de criptografia, através do uso de outros plug-ins e da
configuração do parâmetro WireCryptPlugin. O valor padrão desse
parâmetro é Arc4, significando que a criptografia utilizará o método
Alleged RC4 (o mesmo padrão utilizado em conexões SSL). Você pode
desenvolver seu próprio plug-in de criptografia, ou utilizar plug-ins
que venham a ser desenvolvidos e disponibilizados por terceiros.
Na RC4, a definição da chave que será usada para criptografar os
dados é totalmente automática, e realizada no momento da conexão
entre o cliente o servidor (handshake), portanto, não há de se
preocupar com isso.
Não há criptografia dos dados “trafegados” entre a

aplicação cliente e o processo do Firebird, quando
o acesso à base de dados se dá através do protocolo
XNET (conexão local, disponível apenas no
Windows).
Alguns podem se perguntar se o uso de criptografia no tráfego dos

dados pode reduzir a performance da comunicação cliente/servidor.
O fato é que, com o atual poder de processamento dos
microcomputadores, a diferença, se houver alguma, será
imperceptível.
O gráfico abaixo faz um comparativo na velocidade de diferentes
tipos de algoritmos de criptografia, e fica claro que o RC4 é um dos
mais eficientes.

93
Fonte: http://www.javamex.com/tutorials/cryptography/ciphers.shtml
A título de curiosidade, abaixo temos como ficaria a string “Firebird

Developers Day” criptografada usando RC4 e a senha
“essaeminhasenha”.

94
Compactação do tráfego
Outra novidade introduzida no Firebird 3 é a possibilidade de usar

compactação nos dados trafegados entre o cliente e o servidor. Quem
ativa a compactação dos dados é o cliente, no momento da conexão,
através do parâmetro WireCompression = true.
O padrão do Firebird 3 é ter a compressão desligada.
A compactação, quando ativa, é feita usando a biblioteca Zlib
(www.zlib.net). Essa biblioteca precisa estar presente tanto no
servidor como no computador cliente. Observe que o instalador do
Firebird já traz a biblioteca zlib adequada.
Compactar dados consome recursos da CPU,

portanto, só é aconselhado ativar a compactação
quando o acesso entre cliente e servidor estiver
sendo feito através de WAN (ex: Internet), pois em
conexões de rede local, muito provavelmente a
diferença será imperceptível, isso se não for pior!
Quando houver poucos dados sendo trafegados, a
diferença também provavelmente será mínima.
Em testes realizados com um cliente (Brasil) acessando (via

Internet) um servidor Firebird 3 remoto, hospedado nos Estados
Unidos, o ganho obtido com a compactação em selects retornando
uma grande quantidade de registros foi expressivo, conforme
veremos mais adiante nesse capítulo.
Um fator que afeta diretamente a eficiência da

compactação de dados é o tipo de informação
trafegada. Dados textuais geralmente tem uma alta
taxa de compactação. Outros dados, como imagens
jpeg, arquivos zip, etc. já são compactados, portanto,
não há benefício algum em aplicar compactação
nesse tipo de informação.
Como dito anteriormente, quem ativa a compactação na conexão

é o cliente que a está requisitando. Pensando que, muitas vezes, uma

95
mesma aplicação cliente pode fazer conexões com diferentes

servidores, sendo que alguns podem estar na rede local, outros podem
estar em locais remotos, acessados via internet, link de rádio ou
satélite, seria interessante ter uma forma da aplicação cliente escolher
se a compactação deve ou não estar ativa em uma determinada
conexão. Infelizmente, configurar o parâmetro WireCompression no
firebird.conf do cliente faria com que a configuração valesse para todas
as conexões realizadas por ele. Felizmente, a configuração a nível de
conexão pode ser feita pela aplicação através do DPB (Database
P arameter B lock). Componentes de acesso nativo ao Firebird, como o
IBObjects, geralmente oferecem uma forma de configurar o DPB no
momento da conexão. Provavelmente, com a chegada do Firebird 3,
os autores desses componentes disponibilizarão métodos mais
práticos para fazer esse tipo de configuração.
Para os usuários de Delphi e componente IBObjects, o método
abaixo configura a conexão com a compactação ativada, através do
evento onCustomizeDPB do componente IB_Connection:
procedure TForm1.IB_Connection1CustomizeDPB(Sender:
TIB_Connection; var ABufPtr: Integer;
var ABuffer: array of Byte);
const isc_dpb_config = 87;
begin
Sender.BuildDPBStr(ABufPtr, ABuffer, isc_dpb_config,
'WireCompression=true');
end;
Ao usar o isql para conectar em um servidor

Firebird 3, pode-se executar o comando show version
para confirmar se a compressão está ativada para a
conexão. Quando ativa, o resultado do comando
exibirá um flag “Z” no final, como no exemplo
abaixo:
Firebird/Windows/Intel/i386 (remote server),
version " WI-V3.0.0.32366 Firebird 3.0 Release
Candidate 2/tcp (B153max)/P13:CZ
Melhorias para uso em redes de alta latência
O protocolo de comunicação do Firebird é conhecido por ser

“tagarela” demais, ou seja, ele gera muita conversa entre o cliente e o

96
servidor durante a execução das tarefas. Em uma rede local, isso não
atrapalha em nada, mas em redes com alta latência (ex: internet), a
diferença chega a ser gritante.
Em redes, o termo latência é usado para

determinar o tempo gasto para que um pacote vá
da origem até o destino, e volte (roundtrip).
Se você já acessou um servidor Firebird remoto via internet, deve

ter percebido que a velocidade da “comunicação” é muito inferior a
obtida em uma rede local. Isso fez com que o Firebird ganhasse fama
de ser um banco de dados lento para uso na Internet.
Alternativas para amenizar o problema geralmente se baseavam
em, mais uma vez, apelar para VPNs com compressão de dados, etc.
ganhando com isso um pouco de performance. Outra solução, mais
robusta, é o uso de n-tier (multicamadas), o que pode ser inviável no
caso de sistemas legados desenvolvidos no modelo Cliente/Servidor.
O Firebird 2.1 já havia trazido melhorias no protocolo de
comunicação, diminuindo o número de roundtrips em até 50%,
deixando-o em média 30% mais rápido em redes com alta latência.
Mesmo assim, a performance obtida continuava longe da ideal.
Durante a nona edição do Firebird Developers Day, foram coletadas
doações dos participantes, a fim de patrocinar o desenvolvimento de
melhorias no protocolo de comunicação do Firebird. Dmitry
Yemanov, chefe da equipe de desenvolvimento do Firebird, assumiu
o compromisso de implementa-las, e o resultado pode ser visto no
Firebird 3.0
Basicamente, as melhorias foram implementadas em duas
situações:
• Dados “nulos” agora trafegam em bitmaps. Anteriormente,

os nulos ocupavam 4 bytes + o espaço definido para o
campo! Sendo assim, um fetchall de vários registros
contendo muitos campos nulos será extremamente mais
rápido no Firebird 3!
• O algoritmo de pre-fetch agora considera o tamanho real dos
dados trafegados, gerando uma maior densidade dos
dados. Anteriormente, para determinar quanta informação

97
caberia em um pacote trafegado, o Firebird considerava o

tamanho declarado do campo, e não o tamanho efetivo da
informação armazenada nele!
Infelizmente, ainda há situações onde o protocolo se mostra lento,

e a principal se refere ao tráfego de blobs! O Firebird não consegue
transferir o conteúdo de um blob juntamente com outros dados. Para
transferir um blob, é necessário fazer uma chamada separada, que pode
gerar até 3 roundtrips!
Para efeito comparativo, o gráfico abaixo mostra a diferença de
tempo em um fetchall retornando 10.000 registros de um cadastro de
clientes. As barras azuis são referentes a cadastros reais, onde vários
dos campos eram nulos. As barras vermelhas se referem a mesma
tabela de clientes, onde os campos que estavam nulos foram
totalmente preenchidos com informação randômica.
A escala do gráfico está em segundos.

É nítida a diferença de performance (para melhor) no Firebird 3.
A melhor configuração combinou o uso da compressão do tráfego
(WireCompression) e a configuração do parâmetro TcpRemoteBufferSize
em 32kb, sendo que esse último precisa ser configurado no firebird.conf
do servidor para ter efeito.

98
O uso do parâmetro TcpRemoteBufferSize deve ser

feito com cautela. Aumentar o tamanho do buffer
tcp/ip significa que mais dados poderão ser
trafegados em um único pacote, o que pode ser
benéfico em situações como a mostrada no gráfico,
onde um grande volume de informações estava
sendo transferido. O benefício se inverte nas
situações onde poucas informações são retornadas,
por isso, use com cuidado. O padrão do Firebird
para esse parâmetro é de 8.192 bytes (8Kb).
Ainda para efeito de comparação, o próximo gráfico compara a

performance do Firebird em relação ao MySQL. Nos testes, foi
utilizado o MySQL 5.3.6, contendo a mesma tabela de clientes usada
no Firebird, com exatamente os mesmos dados. Fica demonstrado
que o Firebird 3 foi mais rápido que o MySQL, no fetch de 10.000
registros, nos quatro testes realizados.
A situação muda um pouco de figura se você adicionar campos

blobs aos dados trafegados. Um workaround que pode ajudar bastante,
no caso de blobs textuais onde você sabe que o conteúdo não
ultrapassará 32.765 caracteres, é retornar o blob fazendo um cast como
varchar (32765).
O ambiente utilizado para os testes está descrito abaixo. Os
gráficos foram extraídos da minha palestra sobre “Usando o Firebird
em redes de alta latência”, realizada no 12º Firebird Developers Day.

99

100
String de conexão
Saiba como dizer ao Firebird qual protocolo de transporte deve ser
usado na conexão.
String de conexão
101
Sintaxe “legada”
A string de conexão serve para dizer ao Firebird qual protocolo de

transporte será usado na comunicação com o servidor (local/xnet,
tcp/ip, netbeui/wnet), qual a base de dados (através de um alias ou do
caminho completo para o arquivo), além de possibilitar informar em
qual porta está o servidor desejado (ou mesmo o nome do serviço).
Usuários da linguagem Delphi, e possivelmente de outras
linguagens e/ou tecnologias de acesso, podem nem mesmo estar
familiarizados com o formato das strings de conexões, visto que os
componentes de acesso permitem defini-las “em partes”, através de
propriedades/parâmetros dos componentes de conexão (servidor,
path, porta, etc.). Internamente, os componentes montam a string
baseada nos valores informados nas propriedades, antes de
contatarem o servidor.
A sintaxe da string de conexão é:
Para TCP/IP (INET):

<host> [ / <porta>] : <path para o arquivo do banco de dados ou alias>
Para NetBEUI (WNET):

\\ <host> [ @ <porta | nome do serviço>] \ <path para o arquivo do
banco de dados ou alias>
O path para o arquivo segue as regras do sistema operacional do

host. Por exemplo, em sistemas baseados em Posix, ele é sensível à
caixa.
Abaixo temos alguns exemplos de strings de conexão, extraídos do

Release Notes:
Conexão via TCP/IP especificando o arquivo da base de dados:

192.168.0.11:/db/mydb.fdb
192.168.0.11:C:\db\mydb.fdb
myserver:C:\db\mydb.fdb
localhost:/db/mydb.fdb
www.siteremoto.com:/databases/mydb.fdb
String de conexão
102
Conexão via TCP/IP usando um ALIAS (apelido):

192.168.0.11:mydb
myserver:mydb
localhost:mydb
Conexão via TCP/IP, especificando uma porta diferente da

padrão (3050), por exemplo, a 3051:
192.168.0.11/3051:C:\db\mydb.fdb
192.168.0.11/3051:mydb
myserver/3051:/db/mydb.fdb
localhost/3051:/db/mydb.fdb
myserver/3051:mydb
localhost/3051:mydb
Conexão via TCP/IP especificando um nome de serviço do

Firebird diferente do padrão:
192.168.0.11/fb_db:C:\db\mydb.fdb
192.168.0.11/fb_db:mydb
localhost/fb_db:/db/mydb.fdb
myserver/fb_db:/db/mydb.fdb
myserver/fb_db:mydb
localhost/fb_db:mydb
No TCP/IP, pode-se usar o IP ou o nome do host

para indicar a máquina servidora. Usar o IP só é
aconselhado se tiver certeza que ele é fixo, caso
contrário, toda vez que o IP do servidor mudar,
será necessário alterar sua string de conexão.
Usar o nome do host também pode falhar em
situações onde a máquina não consiga traduzi-lo
para o IP correspondente, seja por falha de
configuração da rede, do dns, hosts, etc.
Conexão via NetBeui (somente Windows):

\\myserver\C:\db\mydb.fdb
\\myserver@fb_db\C:\db\mydb.fdb
\\myserver@3051\C:\db\mydb.fdb
String de conexão
103
Conexão local:
/db/mydb.fdb
C:\db\mydb.fdb
mydb
O uso da barra normal (/) ou da barra invertida (\),

no caminho da base de dados, não faz diferença,
pois o Firebird a ajustará automaticamente, de
acordo com o sistema operacional utilizado. No
entanto, por questão de clareza, recomendo usar o
separador padrão do Sistema Operacional
executado no servidor.
Sintaxe baseada em URL
O Firebird 3 continua aceitando o padrão legado para as strings de

conexão, e introduz uma nova sintaxe, baseada no formato das URLs:
[ <protocol> : // [ <host> [ : <port> ] ] ] / <arquivo da base
de dados ou alias>
<protocol> ::= INET | WNET | XNET
Onde:
INET = TCP/IP
WNET = NetBeui (named pipes)
XNET = Conexão local via shared memory
Os protocolos XNET e WNET (NetBeui) estão

disponíveis apenas no Windows.
Através da nova sintaxe, podemos especificar exatamente como

pretendemos realizar a conexão com o Firebird, como nos exemplos
abaixo:
String de conexão
104
Conexão via TCP/IP usando o path para a base de dados:

inet://192.168.0.11//db/mydb.fdb
inet://192.168.0.11/C:\db\mydb.fdb
inet://myserver/C:\db\mydb.fdb
inet://localhost//db/mydb.fdb
inet://www.siteremoto.com:/databases/mydb.fdb
Conexão via TCP/IP usando alias (apelido):

inet://192.168.0.11/mydb
inet://myserver/mydb
inet://localhost/mydb
Conexão via TCP/IP especificando a porta 3051:

inet://192.168.0.11:3051/C:\db\mydb.fdb
inet://192.168.0.11:3051/mydb
inet://myserver:3051//db/mydb.fdb
inet://localhost:3051//db/mydb.fdb
inet://myserver:3051/mydb
inet://localhost:3051/mydb
Conexão via TCP/IP, especificando o nome do serviço:

inet://192.168.0.11:fb_db/C:\db\mydb.fdb
inet://192.168.0.11:fb_db/mydb
inet://localhost:fb_db//db/mydb.fdb
inet://myserver:fb_db//db/mydb.fdb
inet://myserver:fb_db/mydb
inet://localhost:fb_db/mydb
Conexão via NetBeui:

wnet://myserver/C:\db\mydb.fdb
wnet://myserver:fb_db/C:\db\mydb.fdb
wnet://myserver:3051/C:\db\mydb.fdb
Conexão local, via NetBEUI:

wnet://C:\db\mydb.fdb
Conexão “loopback” (localhost), via TCP/IP:

inet:///db/mydb.fdb
inet://c:\db\mydb.fdb
String de conexão
105
É necessária atenção especial em relação a como o Firebird

entenderá uma string de conexão onde não é especificado o nome do
host, como no exemplo abaixo:
c:\databases\base.fdb
Nesse caso, presume-se que desejamos fazer uma conexão local,

visto que não foi especificado o nome do host. No entanto, também
não especificamos se desejamos fazer uma conexão embedded, xnet ou
mesmo loopback.
O firebird.conf traz, por padrão, uma lista de providers na seguinte
sequência: Remote, Engine12 (embedded) e loopback. Ao receber o pedido
de conexão com a string acima, o Firebird percorre a lista de providers,
na sequência definida (da esquerda para direita), até chegar em um
que aceite a conexão.
No exemplo dado, o primeiro provider (Remote) irá falhar, visto que
não há um nome de host definido. Com isso, o pedido de conexão será
passado para o segundo provider (Engine12), que estabelecerá então
uma conexão embedded.
Mas e se desejássemos que a conexão fosse local via xnet, e não
embedded? Aí a única solução seria especificar o protocolo xnet na string
de conexão, como no exemplo abaixo:
xnet://c:\databases\base.fdb
Alguns podem estar se perguntando quando seria

interessante utilizar o protocolo xnet ao invés do
embedded, para fazer uma conexão local. Um
possível cenário seria se o servidor Firebird
estivesse rodando no modo SuperServer e já
existissem conexões ativas na base de dados. A
tentativa de conectar na mesma base via embedded
resultaria em erro, pois o arquivo já está aberto em
modo exclusivo. No entanto, a conexão via xnet
funcionaria, pois ela seria estabelecida através do
servidor SuperServer já em execução.
String de conexão
106
Uma forma fácil de confirmar qual tipo de conexão

foi estabelecida, usando o isql, é executar o
comando show version, como nos exemplos abaixo:
SQL>show version;
version "WI-V3.0.0.32136 Firebird 3.0 Release
Candidate 1/tcp (meuservidor)/P13:C"
SQL>show version;
version "WI-V3.0.0.32136 Firebird 3.0 Release
Candidate 1/XNet (meuservidor)/P13"
Outra forma é checar o campo

MON$REMOTE_PROTOCOL da tabela
mon$attachments.
Endereços IPv6
O Firebird 3 suporta conexões TCP/IP usando endereços IPv6.

No entanto, endereços nesse formato usam como separadores o
símbolo de dois pontos “:”, que também é usado pelo Firebird para
separar o nome do host do alias/caminho_da_base_de_dados na string de
conexão.
Para resolver essa ambiguidade, ao especificar um endereço IPv6
em uma string de conexão, devemos passar o endereço entre colchetes
“[ ]”, como nos exemplos abaixo:
SQL>connect '[2014:2015:::1]:employee';
SQL>connect '[1234:1234:1234::5]/3051:c:\DBs\banco.fdb';
Um novo parâmetro do firebird.conf, chamado

IPv6V6Only, pode ser usado para forçar o Firebird
a aceitar somente conexões TCP/IP com IPv6. Para
tanto, basta configurar o parâmetro como true. O
padrão (false) faz com que o Firebird aceite tanto
IPv4 como IPv6.
String de conexão
107
Firebird 3 e
aplicações legadas
Saiba quais cuidados devemos ter com aplicações existentes, para que
funcionem bem com o Firebird 3.
Firebird 3 e aplicações legadas

108
O Firebird 3 introduziu uma nova API orientada a objetos (C++),

no entanto, foi mantida total compatibilidade com a API antiga, ou
seja, a nova fbclient poderá ser usada por aplicações legadas, pois todas
as chamadas de API já existentes continuam funcionando.
No entanto, existem alguns outros pontos de atenção que devem
ser observados.
Aplicações feitas em .NET
Até o momento em que esse livro foi escrito, o .NET Provider do

Firebird não tinha sido atualizado para suportar criptografia no
protocolo de comunicação, nem autenticação via SRP (padrão no
Firebird 3).
O .NET Provider implementa o protocolo de comunicação do
Firebird de forma nativa, ou seja, ele não usa a fbclient para se
comunicar com o servidor. Sendo assim, precisará ter sua
implementação nativa do protocolo atualizada, para que possa
suportar os novos recursos de criptografia, compactação e
autenticação via SRP.
Isso significa que para que uma aplicação que usa o .NET Provider
consiga se conectar ao Firebird 3, os seguintes parâmetros precisam
ser alterados no firebird.conf:
WireCrypt = enabled
O padrão do WireCrypt é required, obrigando todos os clientes a se

conectarem com criptografia ativada. Alterando para enabled, o
servidor passa a aceitar também conexões sem criptografia.
AuthServer = Legacy_Auth, Srp, Win_Sspi
O padrão para AuthServer é SRP, no entanto, para o .NET Provider

conseguir se conectar, será necessário alterar para a autenticação
“legada” (menos segura). A definição do AuthServer também pode ser
feita por banco de dados, através do databases.conf.
Tanto AuthServer como AuthClient podem ser

definidos também por conexão, através do DPB
(Database Parameter Block).

109
Aplicações usando Jaybird
Jaybird é o driver JDBC para aplicações em Java. Similar ao .NET

Provider, o Jaybird implementa o protocolo de comunicação do
Firebird de forma nativa (em Java puro, sem depender da fbclient),
além de possibilitar que a conexão seja feita através da biblioteca
cliente do Firebird.
No momento em que esse livro foi escrito, a implementação nativa
do protocolo de comunicação no Jaybird não havia sido atualizada de
forma a suportar autenticação SRP, criptografia e compressão dos
dados trafegados. Segundo Mark Rotteveel, responsável pelo driver,
a criptografia no tráfego deve estar disponível na versão 3.1 do
Jaybird, com chances de ser antecipada para a versão 3.0 (que contará
com a autenticação via SRP). Já a compressão de dados não tem um
prazo definido para implementação.
Sendo assim, atuais usuários do Jaybird 2.2 que desejam utilizar a
implementação nativa do protocolo de comunicação, terão que
configurar o Firebird 3 de forma a usar a autenticação legada
(LegacyAuth), e desligar a criptografia dos dados trafegados
(WireCrypt).
WireCrypt = Enabled
AuthServer = Srp, Win_Sspi, Legacy_Auth
UserManager = Srp, Legacy_UserManager
Para mais informações sobre como usar o Jaybird com o Firebird

3, sugiro a leitura da página
github.com/FirebirdSQL/jaybird/wiki/Jaybird-and-Firebird-3.0-
beta-2 ou goo.gl/yp2ZwW. O FAQ do Jaybird está disponível em
www.firebirdsql.org/file/documentation/drivers_documentation/ja
va/faq.html ou goo.gl/9GQ6NC.
O Jaybird pode ser configurado de forma a usar a

biblioteca cliente do Firebird (fbclient), ao invés da
implementação nativa do protocolo de
comunicação. Isso permite usar o Jaybird para
conectar ao Firebird 3 com conexões SRP,

110
criptografadas e/ou com compressão de dados! No

entanto, a fbclient deve estar disponível no path de
pesquisa do sistema operacional onde o Jaybird está
sendo usado, e as bibliotecas jaybird22 ou
jaybird22_x64 devem constar no java.library.path.
Para indicar ao Jaybird que se deseja usar a fbclient,
a string de conexão JDBC deve mencionar “native”,
seguindo o seguinte formato:
jdbc:firebirdsql:native:host[/port]:<database>
Tipo lógico (boolean )
O Firebird 3 introduz um novo tipo de dado lógico, o famoso

boolean. No entanto, antes de criar objetos no banco de dados usando
esse tipo, tenha certeza que a tecnologia de acesso ao Firebird usada
em suas aplicações já o suporte, caso contrário, ela não será capaz de
“entender” a informação e você terá problemas!
Por exemplo, aplicações usando a velha BDE, que está estagnada
há muito anos, com certeza não serão capazes de entender esse novo
tipo de dado.
Conectando o FB 3 usando uma fbclient antiga
É sempre recomendável usar uma versão da biblioteca cliente do

Firebird que seja da mesma versão que o servidor instalado, pois isso
permite aproveitar todas as melhorias possíveis. Se por alguma razão
você precisa conectar no Firebird 3 usando uma fbclient “antiga”, será
necessário configurar o firebird.conf de forma a usar a autenticação
legada, e aceitar conexões sem criptografia:
WireCrypt = enabled
AuthServer = Legacy_Auth, Srp, Win_Sspi
Lembre-se que a autenticação legada é bem menos segura do que

a nova autenticação via SRP.

111
Performance de queries
Pode ser que após a mudança para o Firebird 3 (ou mesmo para
qualquer versão do Firebird), queries que anteriormente tinham uma
boa performance, passem a apresentar performance ruim (apesar de
raro, pode acontecer!). As principais razões para justificar tal
comportamento são:
1. Bases de dados que estavam com as estatísticas dos índices

desatualizadas, pela necessidade de fazer um backup/restore
para migrar para o Firebird 3, terão as estatísticas
atualizadas, o que pode fazer com que o otimizador
escolha um novo PLANo de acesso para determinadas
consultas. Às vezes, o otimizador se engana na escolha do
plano, e a performance acaba sendo prejudicada.
2. Em toda nova versão do Firebird, o otimizador sofre
melhorias em sua lógica, com o intuito de se tornar mais
eficiente/inteligente. No entanto, algumas vezes essas
melhorias produzem “efeitos colaterais”, podendo fazer
com que ele escolha PLANos não tão eficientes para
algumas queries.
Se estiver sofrendo com alguma das opções acima, reporte no

tracker do Firebird (tracker.firebirdsql.org), para que os core-developers
analisem o caso e determinem se é uma falha do otimizador, para que
possam corrigi-lo. Como solução de curto prazo, pode-se tentar
forçar um PLANo, ou mesmo usar de artifícios para alterar a query,
fazendo com que o otimizador escolha outro plano.
O Firebird não atualiza as estatísticas dos índices

automaticamente. Elas são atualizadas apenas
quando o índice é criado, reconstruído, ou quando
o comando SET STATISTICS é executado. A
maioria das aplicações não possuem rotinas para
forçar a atualização das estatísticas dos índices,
ocasionando situações onde elas não refletem mais
a realidade dos dados. É importante que os
desenvolvedores tenham isso em mente, e

112
implementem rotinas nas aplicações, que

recalculem as estatísticas de tempos em tempos.
Palavras reservadas
As palavras abaixo passaram a ser reservadas no Firebird 3. Isso

significa que se você tiver variáveis ou campos usando essas palavras,
deverá renomeá-los para uma palavra não reservada, ou referencia-los
nos selects, etc. usando “ ” (aspas duplas).
BOOLEAN REGR_AVGX SCROLL

CORR REGR_AVGY SQLSTATE
COVAR_POP REGR_COUNT STDDEV_POP
COVAR_SAMP REGR_INTERCEPT STDDEV_SAMP
DELETING* REGR_R2 TRUE
DETERMINISTIC REGR_SLOPE UNKNOWN
FALSE REGR_SXX UPDATING*
INSERTING* REGR_SXY VAR_POP
OFFSET REGR_SYY VAR_SAMP
OVER RETURN
RDB$RECORD_VERSION ROW
As palavras marcadas com * já eram reconhecidas pelo Firebird,

mas não eram reservadas.
O uso de aspas duplas em identificadores só é

suportado no Dialeto 3! Se sua base de dados ainda
usa Dialeto 1, a única opção será renomear os
identificadores que passaram a ser palavras
reservadas no Firebird 3.
Observe que nenhum erro será reportado no momento da

restauração de um backup criado em uma versão anterior do Firebird.
O problema virá à tona quando a aplicação executar queries
referenciando objetos da base de dados definidos com palavras que
passaram a ser reservadas, ou quanto o DBA tentar recompilar triggers
e procedures que tenham referências à palavras reservadas em seu

113
“corpo”. A solução mais fácil para o problema é alterar o código das

queries, procedures e triggers, de forma que referenciem esses objetos
usando aspas duplas, lembrando que ao fazer isso, eles se tornam
sensíveis a maiúsculas/minúsculas.
Durante a migração para o Firebird 3, preste

atenção se seu banco de dados pré-existente faz
referência a alguma palavra que passou a ser
reservada no Firebird 3. Uma forma fácil de
verificar é extrair a metadata da base (no servidor
antigo) para um script, e tentar criar uma nova base
de dados no Firebird 3, usando a metadata extraída.
Verifique o capítulo “Migrando uma base de dados já
existente” para maiores informações.
Manipulação de Tabelas de Sistema (RDB$...)
As tabelas de sistema existem em todas as bases de dados Firebird, e

são identificadas pelo nome, que sempre começa com RDB$. Elas
armazenam informações sobre a metadata do banco de dados, ou seja,
nomes de tabelas, campos, tipos, tamanhos, códigos de procedures,
triggers, etc. Antes do Firebird 3, as tabelas de sistema eram ativas, ou
seja, atualizando seus dados consequentemente alterava a metadata da
base de dados. Apesar de não recomendado, algumas aplicações
manipulam os dados das tabelas de sistema, e como não havia
qualquer tipo de validação em relação a consistência das alterações,
elas poderiam até mesmo resultar em uma base de dados logicamente
corrompida.
O Firebird 3 não permite mais manipular as tabelas de sistema
diretamente! Se uma aplicação realiza esse tipo de operação, terá que
ser adaptada de forma a usar SQL DDL, que fazem uma série de
validações lógicas evitando a execução de alterações inválidas.
Com a ampliação dos comandos SQL no Firebird 3, praticamente
todas as operações que antes só podiam ser feitas através da
manipulação das tabelas de sistema, agora podem ser feitas
“oficialmente”, via SQL DDL.
A única exceção fica por conta do campo que armazena o código
fonte de procedures e triggers, nas tabelas RDB$PROCEDURES e

114
RDB$TRIGGERS, respectivamente. Como ainda não existe uma

forma oficial de “apagar/esconder” o código fonte, o que muitas
vezes é desejado por questões de proteção de direitos autorais ou da
“inteligência” das regras de negócio, o Firebird 3 ainda permite
manipular esses campos.
Alguns podem estar se perguntando como a

procedure/trigger continua funcionando, depois de ter
seu código apagado. O fato é que quando uma
procedure/trigger é criado, o Firebird compila o
código fonte em uma linguagem chamada BLR
(Binary Language Representation) e armazena o código
compilado dentro da base de dados, portanto, ele
não depende do código fonte para executar a
rotina.
Abaixo, temos um exemplo de script que apaga o código das

procedures e triggers em uma base de dados.
update RDB$PROCEDURES
set RDB$PROCEDURE_SOURCE = null
where ((RDB$SYSTEM_FLAG = 0) or (RDB$SYSTEM_FLAG is null));
commit;
update RDB$TRIGGERS T
set T.RDB$TRIGGER_SOURCE = null
where ((T.RDB$SYSTEM_FLAG = 0) or (T.RDB$SYSTEM_FLAG is null))
and
not exists(select C.RDB$TRIGGER_NAME
from C.RDB$CHECK_CONSTRAINTS
where C.RDB$TRIGGER_NAME =
T.RDB$TRIGGER_NAME);
commit;
Alguns usuários também tinham o costume de

apagar o código fonte de views, manipulando
diretamente a tabela rdb$relations. Isso não será mais
possível no Firebird 3.
Tenha muito cuidado ao apagar os códigos das

procedures e triggers, pois se eles não estiverem

115
disponíveis em pelo menos uma base de dados de

referência ou em scripts sql, você ficará em uma
situação complicada quando precisar alterá-los.
Testando as Queries de suas aplicações
Já foi dito que a mudança de uma versão do Firebird pode implicar

em diversos problemas com queries já existentes, desde performance
ruim, até “quebra” devido ao uso de novas palavras reservadas, etc.
Uma aplicação geralmente é composta por centenas de queries, com
os mais variados propósitos, desde a visualização de informações em
tela, até geração de relatórios, etc.
Uma dica que pode ajudar na certificação de aplicações existentes
para uso com o Firebird 3, é usar a ferramenta FBScanner, da
IBSurgeon, para logar e testar as queries na nova versão do servidor.
O FBScanner faz parte do pacote HQBird, que consiste em uma
série de ferramentas de análise, monitoramento e otimização de
servidores Firebird. Ele funciona como um proxy entre as estações e
o servidor, permitindo logar toda a comunicação. Com isso, você
pode instalar o FBScanner ainda quando estiver usando a versão
anterior do Firebird, configura-lo de forma que monitore a
comunicação, e armazene os selects em um log. Depois de alguns dias
de monitoramento, você terá um log que contém grande parte dos
selects utilizados em suas aplicações.
O FBScanner permite “rodar” os comandos logados, ou seja, de
posse da base de dados de log obtida ainda com a versão anterior do
Firebird, pode-se montar um servidor Firebird 3 para testes, fazer o
backup/restore da base de dados nele, e usar o FBScanner Log Analyzer
para “rodar” os selects logados previamente. A ferramenta mostrará o
resultado da execução dos comandos em uma grade, com as
informações de performance, permitindo comparar o tempo de
execução da query no servidor antigo com o novo tempo, além do
PLAN antigo e o novo PLAN. As informações da grade podem ser
exportadas para uma planilha Excel.

116
Ao comparar o tempo de execução das queries,

tenha em mente que fatores “externos” podem
influenciar no resultado, especialmente se o cache do
sistema operacional (ou do Firebird) estiver “frio”
ou “quente”. Obviamente, o resultado de queries
executadas quando a maior parte das informações
se encontra em cache será sempre melhor do que se
o Firebird precisar busca-las no disco, e vice-versa.
O HQBird pode ser adquirido com um “super desconto” através

dos links disponíveis na página de parceria com a FireBase:
www.firebase.com.br/parceria_ibaid.php ou goo.gl/lWxD9L. Existe
também uma versão de avaliação que funciona por alguns dias, assim,
você pode testar antes de compra-lo. Um “Guia do Usuário” em
português pode ser baixado em
ibsurgeon.com/download/docs/FBScanner3UserGuide_PTBR.pdf
ou goo.gl/xaj1lx.
Caso você pretenda usar o FBScanner para logar a

comunicação em um servidor Firebird 3, terá que
ativar a autenticação legada e desligar a criptografia
no firebird.conf. A ferramenta também pode ser
usada na forma de um plug-in da Trace API, ao
invés de ser instalada como proxy.
Obtendo o número de conexões via

mon$attachments
É comum que as aplicações cliente utilizem a tabela mon$attachments

para recuperar as informações das conexões ativas (IP do cliente,
aplicativo, etc.) ou mesmo para saber quantos usuários estão
conectados na base de dados em um determinado momento.
Quem usa esse método com o Firebird SuperServer deve ficar
atento a uma alteração introduzida no Firebird 3, onde conexões de
sistema (criadas pelo próprio Firebird) agora também são exibidas nas
tabelas de monitoramento.
Por exemplo, veja a situação abaixo, onde o select foi executado em
uma base de dados onde apenas um usuário estava conectado:

117
isql employee
Database: employee, User: SYSDBA
SQL> select count(*) from mon$attachments;
COUNT
=====================
3
SQL> select mon$user, mon$system_flag from mon$attachments;
MON$USER MON$SYSTEM_FLAG
=============================== ===============
SYSDBA 0
Cache Writer 1
Garbage Collector 1
Note que, mesmo havendo apenas um usuário conectado na base,

o count retornou 3. No segundo select, podemos ver que as outras duas
conexões tem o campo mon$system_flag como 1, indicando que são
conexões de sistema, criadas pelo próprio Firebird, e não por um
usuário comum.
Sendo assim, se desejarmos obter a lista ou o número de usuários
ativos em um determinado momento, devemos usar o comando
como no exemplo abaixo:
SQL> select count(*) from mon$attachments
where mon$system_flag = 0;
COUNT
=====================
1

118
Apêndices
Apêndices
119
Macros
Uma série macros pré-definidos são disponibilizados de forma a
facilitar a referência dos diretórios, nos arquivos de configuração. A
sintaxe dos macros segue o padrão $(nome_do_macro).
$(root)
Diretório raiz de instalação do Firebird.
$(install)
Diretório onde o Firebird foi instalado. Inicialmente, $(install) e $(root)
são idênticos. No entanto, $(root) pode ser sobrescrito pela configuração da
variável de ambiente FIREBIRD.
$(this)
Diretório onde o arquivo de configuração atual está localizado.
$(dir_conf)
Diretório onde o firebird.conf e o databases.conf estão localizados.
$(dir_secdb)
Diretório onde a base de dados de segurança padrão está localizada.
$(dir_plugins)
Diretório onde os plug-ins estão localizados.
$(dir_udf)
Diretório padrão onde as UDFs estão localizadas.
$(dir_sample)
Diretório onde os arquivos de exemplos estão localizados.
$(dir_sampledb)
Diretório onde a base de dados de exemplo (employee.fdb) está
localizada
$(dir_intl)
Diretório onde os módulos de internacionalização estão localizados.
$(dir_msg)
Apêndices
120
Diretório onde o arquivo de mensagens (firebird.msg) está localizado.

Geralmente tem o mesmo valor de $(root), podendo ser sobrescrito pela
variável de ambiente FIREBIRD_MSG.
Observe que você pode incluir um arquivo de configuração dentro

de outro, através da diretiva “include”, por exemplo:
include meu_arquivo.conf
O path relativo para o arquivo referenciar no include é baseado na

localização do arquivo de configuração que contém a diretiva include.
O uso de caracteres coringas (* e ?) são reconhecidos na diretiva
include, a fim de incluir todos os arquivos que correspondem a máscara
especificada, por exemplo:
include $(dir_plugins)/config/*.conf
Incluiria todos os arquivos com a extensão .conf, localizado no

diretórios de plug-ins, subdiretório config.
Anteriormente, todos os parâmetros cujos valores

eram expressos em bytes, agora podem ser
referenciados em kbytes, megabytes ou gigabytes (K, M
e G – em maiúsculas).
Entradas de configuração
Como vimos anteriormente, o antigo arquivo aliases.conf agora se

chama databases.conf, e permite configurar diversos parâmetros,
além do apelido de uma base de dados.
Quando usado apenas para definir um alias, o formato continua o
mesmo:
base1 = c:\base_de_dados\meubanco1.fdb
base2 = c:\base_de_dados\meubanco2.fdb
emp = $(dir_sampleDb)\employee.fdb
...
No entanto, quando quisermos definir alguns parâmetros a nível

de base de dados, a sintaxe torna-se um pouco mais complexa.
Apêndices
121
Basicamente, logo abaixo da linha que define o apelido da base de

dados, devemos acrescentar os parâmetros desejados, entre chaves
{ }, por exemplo:
#Exemplo
emp = $(dir_sampleDb)\employee.fdb
{
UserManager = LegacyUserManager
WireCrypt = disabled
}
No exemplo acima, definimos um alias chamado emp que aponta

para a base de dados de exemplo (employee.fdb), e instruímos o Firebird
que ao conectar em emp, a autenticação dos usuários será feita pelo
plug-in LegacyUserManager, e a criptografia dos dados trafegados estará
desligada.
Tudo que vier após um # será considerado comentário e ignorado.
Os parâmetros abaixo configuram a engine do banco de dados. O

propósito de cada um deles pode ser visto no release notes, ou nos
comentários contidos nos próprios arquivos de configuração.
DatabaseGrowthIncrement
DeadlockTimeout
DefaultDbCachePages
EventMemSize
FileSystemCacheThreshold
ExternalFileAccess
GCPolicy
LockAcquireSpins
LockHashSlots
LockMemSize
MaxUnflushedWrites
MaxUnflushedWriteTime
SecurityDatabase
ServerMode
UserManager
WireCrypt
WireCryptPlugin
Os parâmetros abaixo são relacionados ao “lado cliente”.

AuthClient
Providers
Os parâmetros abaixo só podem ser definidos no momento da

conexão, via DPB/SPB.
Apêndices
122
ConnectionTimeout
DummyPacketInterval
IpcName
RemoteAuxPort
RemotePipeName
RemoteServiceName
RemoteServicePort
TCPNoNagle
Apêndices
123
Glossário
BDE: Borland Database Engine – mecanismo de acesso a
diferentes bancos de dados, entre eles dBase, Paradox, InterBase©,
SQLServer, Oracle, etc. Foi amplamente utilizada em projetos
desenvolvidos com as linguagens de programação da Borland, como
o Delphi, CBuilder, etc. Apesar de facilitar a vida do desenvolvedor,
sua performance com SGBDRs era deficitária, pois em troca da
facilidade de programação, ela deixava de utilizar vários recursos
específicos de cada SGBD. Atualmente está descontinuada.
BLOB: O termo surgiu não como um acrônimo mas sim uma

referencia a um filme de terror de Steve McQueen de 1958. A
referência de BLOB em bases de dados apareceu inicialmente na
Rdb/ELN da DEC. Hoje blob é usado como uma abreviação para
Binary Large Object. Campos utilizados para armazenar informações
binárias ou textuais sem tamanho previamente definido. No Firebird,
pode ter diferentes subtipos (ex: text, binary).
BLR: Mais uma vez, BLR não nasceu como um acrônimo, apesar
das letras serem as iniciais do gerente do projeto Rdb/ELN da DEC.
Por definição, BLR era um formato simples para representar queries
SQL, ou as linguagens QUEL e DGML (já extintas). Hoje a sigla
representa Binary Language Representation, linguagem utilizada
dentro da engine do Firebird. Procedures, triggers, views, etc. são
compilados na forma de BLR, e armazenados dentro do banco de
dados.
Character set: Determina os símbolos de caracteres disponíveis

para uso. A maioria das línguas compartilham alguns caracteres, como
os dígitos de 0 a 9. Outros caracteres são específicas para uma ou mais
línguas. O mapeamento de caracteres para sua representações binárias
varia entre países e fabricantes de computadores, e até mesmo entre
aplicativos em uma plataforma para um único país. Os mapeamentos
de um conjunto de caracteres para valores binários são chamados de
conjuntos de caracteres ou páginas de código. O Firebird suporta
Glossário
124
diversos conjuntos de caracteres. No entanto, se você estiver

escrevendo um aplicativo que lida com mais de um idioma, considere
usar o UTF-8 por ser uma codificação universal, mesmo que ele
consuma mais espaço do que um conjunto de caracteres projetado
para um idioma específico.
Chave estrangeira: Veja Foreign Key.
Chave primária: Identifica um único registro em uma tabela.

Pode ser composta por um (chave simples) ou mais (chave composta)
campos dessa tabela. No Firebird, quando uma chave primária é
criada, um índice único é criado automaticamente.
Collation: determina como os caracteres de um determinado

character set são comparados e/ou ordenados entre si. Através de um
collate, podemos definir que um “á” equivale, para efeitos de
comparação e ordenação, a um “ã”, “à”, “â”, etc., ou que “a” é menor
e precede um “ã” que por sua vez precede um “à”, etc. Diferentes
países usam diferentes collations. As vezes, um mesmo país usa mais
de uma collation em diferentes aplicações. O Firebird suporta diversas
collations.
Commit: Ato de encerrar uma transação fazendo com que todas

as operações associadas a ela sejam efetivamente gravadas na base de
dados e se tornem visíveis para outras transações.
CommitRetaining: Confirma uma transação fazendo com que

todas as operações associadas a ela sejam efetivamente gravadas.
Diferente do Commit, o CommitRetaining mantém o contexto
transacional ativo. Não é aconselhado o uso de CommitRetaining em
transações de longa duração, pois pode prejudicar a performance
bloqueando a garbage collection no BD.
Concurrency: Ver Isolamento transacional.
Consistency: Ver Isolamento transacional.
dbExpress: Interface de acesso a bancos de dados criada pela

Borland. Permite que se padronize o método de acesso aos dados,
Glossário
125
independente de qual SGBD seja utilizado, bastando especificar o

driver adequado.
DBMS: Database Management System. Um conjunto de

programas que permite armazenar, modificar e extrair informação de
uma base de dados. O DBMS recebe a requisição de informações dos
aplicativos, e devolve os dados apropriados. Um DBMS gerencia a
concorrência e previne conflitos entre os usuários.
DDL: Data Definition Language – é a parte dos comandos SQL

destinada à manipulação dos metadados (estrutura do BD).
Dirty Read: Ver Isolamento transacional
Delphi: IDE/Linguagem de programação para Windows,

MacOS, iOS e Android, baseada no Pascal, criada pela Borland e
atualmente nas mãos da Embarcadero©, amplamente utilizada no Brasil,
Rússia e em vários outros países.
DML: Data Manipulation Language – comandos SQL destinados

à manipulação dos dados no banco de dados.
DPB: Database Parameter Block – é um buffer em memória

contendo parâmetros de configuração, passado via API no momento
da conexão com uma base de dados.
DSQL: Ver Dynamic SQL .
Dynamic SQL: Instruções SQL disponíveis para programas que

montam e enviam comandos em tempo de execução para o SGBD,
como por exemplo, programas feitos em Delphi.
Embedded Server: Configuração do Firebird que permite acessar

as bases de dados sem necessidade de instalar o Firebird.
FDB: Extensão adotada como padrão para os bancos de dados

criados no Firebird 1.5 e posteriores. A extensão do arquivo é apenas
uma convenção, e não significa nada para o Firebird.
Glossário
126
FireBase: Maior site em português dedicado ao bancos de dados

Firebird. Possui lista de discussão, artigos, dicas, downloads, etc.
Oferece também serviços comerciais de consultoria e
desenvolvimento: www.firebase.com.br
Firebird Foundation: Fundação criada para viabilizar o contínuo

desenvolvimento do Firebird, angariando fundos para pagar os
desenvolvedores que trabalham para o Projeto.
Foreign Key: Tipo especial de chave não única, utilizada para

definir regras de integridade entre os dados.
Função Definida pelo Usuário: Ver UDF.
Fundação Firebird: Ver Firebird Foundation.
Gatilho: Ver Trigger.
Gbak: Utilitário de linha de comando responsável pela geração e

restauração de backups de bases de dados. Durante o backup, o gbak
faz uma cópia dos metadados e dos dados o banco de dados. No
restore, o gbak cria uma base vazia e a popula com os metadados e
dados.
GDB: Extensão padrão utilizada em bancos de dados InterBase©.

Faz referência ao nome do antigo fabricante do InterBase©, a Groton
DataBase Systems. A extensão GDB não é recomendada no
Windows, pois ela tem um significado especial para esse sistema
operacional.
Gfix: Utilitário de linha de comando responsável por detectar e

corrigir possíveis erros nos arquivos de bancos de dados, além de
configurar alguns parâmetros como escrita síncrona/assíncrona, etc.
GPre: Pré-processador do Firebird – dependendo da plataforma,

suporta diferentes linguagens para gerar aplicações com embedded
SQL, incluindo C, COBOL e ADA.
Glossário
127
GSec: Utilitário de linha de comando responsável por manipular

as informações de segurança no servidor, como criação de usuários,
alteração de senhas, etc. No Firebird 3, o gsec está descontinuado,
sendo recomendado usar os novos comandos SQL para gerenciar os
usuários.
Gstat: Utilitário de linha de comando responsável pela

recuperação de estatísticas do banco de dados, como fragmentação
dos índices, etc.
IBO: InterBase Objects. Pacote de componentes de acesso

nativo desenvolvido por Jason Wharton e distribuído sob a licença
Trustware. Atualmente é o pacote de componentes mais completo para
o InterBase© e Firebird. Tem garantia de compatibilidade dada pelo
autor, tanto para o IB como para o FB, possuindo inclusive
componentes visuais de edição nativos (grids, edits, etc.) criados
especificamente para trabalhar com os recursos do IB/FB
(www.ibobjects.com). Os brasileiros podem registrar o IBO pagando
um preço reduzido, através do link www.firebase.com.br/IBO.php.
IBSurgeon: Empresa localizada na Rússia (www.ibsurgeon.com),

referência em recuperação de bases de dados corrompidas e
otimização de performance. Fabrica diversas ferramentas para
otimização de bases de dados, monitoramento de servidores,
recuperação de bases de dados, etc. A FireBase é parceira exclusiva
da IBSurgeon no Brasil. Os brasileiros podem comprar os produtos
com descontos especiais através da página
www.firebase.com.br/parceria_ibaid.php.
IBX: InterBase Express. Pacote de componentes de acesso

nativo, derivado do FreeIB e incluído em algumas distribuições do
Delphi, a começar pelo Delphi 5. Atualmente estagnado, e sem
garantia de compatibilidade com o Firebird.
Integridade Referencial: Permite a definição de relacionamentos

do tipo “pai-filho”, onde um “pai” não pode ser removido sem que
antes os filhos sejam apagados.
Glossário
128
Interactive SQL: Utilitário de linha de comando do Firebird, para

enviar comandos ao servidor e obter resultados de queries.
InterBase Express: Ver IBX.
InterBase Objects: Ver IBO.
ISC: InterBase Software Corporation©. Empresa que pertencia a

Borland, e que foi absorvida por ela em 1998.
Isolamento transacional: Determina como uma transação irá

interagir com outras transações acessando o mesmo banco de dados,
no que diz respeito à visibilidade das informações e concorrência. Os
4 modos de isolamento são Dirty Read, Read Commited, RepeatableRead
(Concurrency) e RepeatableRead Stability (Consistency). O modo DirtyRead
não é suportado pelo Firebird.
ISQL: Ver I nteractive SQL .
JRD: Jim’s Relational Database. É o nome do kernel do

InterBase©/Firebird, em referência ao seu criador, Jim Starkey.
Log de Transações: Alguns SGBDs armazenam um histórico de

todas as transações realizadas no BD em um arquivo de log. Quando
uma falha ou problema ocorre no SGBD, esse log é utilizado para
determinar o que deve ser confirmado e o que deve ser desfeito para
deixar o banco de dados em um estado consistente novamente. A
arquitetura de Versioning usada no Firebird dispensa o log de transações.
MGA: Multi-Generational Architecture. Conhecida também

como Versioning. É o nome do sistema de gerenciamento de
concorrência idealizado por Jim Starkey e utilizado no InterBase©
Firebird e no PostgreSQL.
NetBEUI: NetBIOS Extended User Interface (ou WNET), é um

protocolo de rede baseado no NetBIOS, muito simples e que suporta
no máximo 255 computadores.
Glossário
129
Null value: Indica que o valor de um campo não foi especificado,

ou seja, está indefinido. Note que NULL não é um valor, mas sim um
estado. Um campo “vazio” não significa que está nulo.
ODBC: Open Database Connectivity. Interface que permite que

uma aplicação acesse diversos SGBDs de forma padrão, bastando
para isso utilizar o driver ODBC específico para o SGBD desejado.
ODS: Ver On Disk S tructure.
OLE/DB: Padrão criado pela Microsoft para acessar dados

relacionais e não relacionais, e que oferece uma performance superior
que o ODBC. O ADO é uma camada que roda em cima do ODBC.
On Disk Structure: Indica a versão da estrutura do arquivo do

banco de dados.
Primary Key: Ver Chave Primária.
Procedural SQL: Linguagem disponível para escrita de Triggers,

Stored Procedures e blocos de código no IB/FB.
Procedure: Ver Stored Procedures.
PSQL: Ver Procedural SQL.
RDBMS: Relational Database Management System. Um banco

de dados baseado no modelo relacional criado por E.F. Codd.
Permite a definição de estruturas de dados, operações de
armazenamento e recuperação das informações, e definição de regras
de integridade. Os dados e os relacionamentos entre eles são
organizados em tabelas. Uma tabela é uma coleção de linhas (ou
registros), sendo que cada linha em uma tabela contém os mesmos
campos.
ReadCommited: Ver Isolamento transacional.
Repeatable Read: Ver Isolamento transacional.
Glossário
130
Repeatable Read Stability: Ver Isolamento transacional.
RI: Referential Integrity - Ver Integridade Referencial
RollBack: Ato de cancelar uma transação, fazendo com que todas

as operações associadas a ela sejam desfeitas. O rollback encerra a
transação associada.
RollBackRetaining: Cancela uma transação, fazendo com que

todas as operações associadas a ela sejam desfeitas. Diferente do
RollBack, o RollBackRetaining mantém o contexto transacional ativo, e
deve ser evitado em transações de longa duração, pois bloqueia a
garbage collection.
SGBD: Sistema Gerenciador de Bancos de Dados. Ver DBMS.
SGBDR: Sistema Gerenciador de Bancos de Dados Relacional.

Ver RDBMS.
SPB: Service Parameter Block – buffer em memória passado via

API, para definir parâmetros via API de Serviços do Firebird.
SQL: Structured Query Language. É a linguagem utilizada para

“conversar” com os bancos de dados relacionais. Por ser uma
linguagem declarativa, especifica o que se quer obter como resultado,
e não como a engine deve fazer para obtê-lo.
Stored Procedures: Procedimentos armazenados dentro do

banco de dados (pré-compilados)
Sweep: Processo que libera o espaço que não está mais em uso
pelo Firebird, como, por exemplo, espaço ocupado por registros
apagados ou versões temporárias de registros, para que seja
reutilizado no armazenamento de novas informações, além de
avançar a OIT. Pode ser iniciado automaticamente ou manualmente.
Percorre todos os registros de todas as tabelas do banco de dados e,
portanto, pode ocasionar queda de performance no servidor
enquanto estiver sendo executado.
Glossário
131
Tabelas de Sistema: São tabelas utilizadas pelo Firebird para

definir toda a estrutura do banco de dados, inclusive das próprias
tabelas de sistema. Seus nomes iniciam com RDB$.
Transação: Unidade lógica que engloba um ou mais

comandos/operações realizadas no banco de dados. Se a transação
falhar, todas as operações associadas a ela podem ser desfeitas (rolled
back), caso contrário, são confirmadas (commited).
Transaction Log: Ver Log de Transações.
Trigger: Ações (procedimentos) associados a uma tabela e

disparados por eventos ocorridos nessa tabela, como por exemplo a
inserção, remoção ou alteração de informação.
UDF: User Defined Function – função definida pelo usuário.

Recurso que permite que os usuários criem funções para serem
utilizadas dentro do banco de dados, possibilitando a extensão das
funcionalidades do mesmo. As UDFs são armazenadas em
bibliotecas compartilhadas (DLLs no Windows ou Shared Objects no
Linux).
Unique key: um valor que identifica cada registro (ou tupla) em

uma tabela, distinguindo-os dos outros registros.
XNET: Protocolo de transporte, disponível apenas no Windows,

para conexões locais (através de memória compartilhada).
WNET: Ver NetBEUI.
Zeos/ZeosDBO: Pacote de componentes Free e Open Source

para Delphi que permitem acesso nativo a diversos SGDBs, entre eles
o InterBase© e o Firebird (www.zeoslib.net)
Glossário

Guia Firebird 3 Rev1 - 01

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guia Firebird 3 Rev1 - 01

Enviado por

Direitos autorais:

Formatos disponíveis

1

Guia de Migração para o Firebird 3

Copyright 2016 © Carlos Henrique Cantu

Nenhuma parte deste livro poderá ser reproduzida, transmitida e/ou

Edição, diagramação, finalização e publicação:

Migrando a base de dados para o Firebird 3 ......................... 62

Entradas de configuração .................................................... 120

Este livro é dedicado à minha esposa Elizabeth, minha filha

Carlos Henrique Cantu

Carlos Henrique Cantu

www.firebase.com.br / blog.firebase.com.br / www.firebirdnews.org

Segue a lista de pessoas/empresas (em ordem alfabética, dois

Acesys Tecnologia em Adilson Pazzini

Daniel Simões de Almeida Daniel Yamamoto

Leandro Irgang Leonardo Wascheck –

Saac.Software Sady Moreira

Muito obrigado a todos!

Ignorar o assunto abordado poderá induzir a uma

O assunto requer atenção especial!

Ignorar o assunto abordado poderá comprometer

No final do livro há um glossário que pode ser consultado quando

Caso encontre algum erro, encaminhe por e-mail

Noções básicas, mas

Noções básicas, mas essenciais!

Antes de adentrarmos nas especificidades do Firebird 3, é

SuperServer vs. Classic vs. SuperClassic

O Firebird pode funcionar com três arquiteturas (modos)

Noções básicas, mas essenciais!

Cache de páginas do Firebird

Cache do Sistema (Operacional/Arquivos)

Cache do dispositivo de armazenamento

Arquivo da base de dados

A quantidade de memória alocada para o cache de páginas do

Quando o valor de buffers (gravado no header da

É aí que aparece a primeira diferença entre as arquiteturas do

Noções básicas, mas essenciais!

A seguir, comentarei as características das três arquiteturas do

Na versão Classic, cada conexão com o banco de dados é atendida

Um dos principais motivos de uma possível queda

O fato de cada conexão ser atendida por um processo

Noções básicas, mas essenciais!

Apesar de não ser uma situação muito comum,

Lembre-se também que cada processo do Firebird consumirá

No modelo SuperServer, as conexões são atendidas por threads de

Noções básicas, mas essenciais!

Outra desvantagem é que (até a versão 2.5) o SuperServer não

No Firebird 2.5, é possível fazer com que o SS use

O SuperClassic é um híbrido entre o Classic e o SuperServer.

Noções básicas, mas essenciais!

A versão embarcada (embedded) do Firebird permite distribuir o

Note, no entanto, que o Firebird embedded não faz autenticação

Noções básicas, mas essenciais!

Arquiteturas Nome do SMP Cache de Acesso Threads/

Qual arquitetura escolher?

É difícil criar uma regra ou “receita de bolo” válida para todas as

Classic – Pode ser usado em servidores multiprocessados,

SuperClassic – Pode ser usado em servidores multiprocessados

Noções básicas, mas essenciais!

A arquitetura SuperServer merece uma atenção especial, pois sua

SuperServer no Firebird 2.5 – De forma geral, deve ser usado

SuperServer no Firebird 3 – A SuperServer é a arquitetura

Dmitry Yemanov, atual chefe da equipe de

No Firebird 3, a arquitetura a ser usada (CS, SS ou SC) é definida