Introdução Firebird 2.5

Introdução Firebird 2.5 Introdução Firebird 2.5 Admin em Qua 11 Jul 2012-16:29 Introdução Demorou, mas finalmente o Firebird 2.5 foi lançado, no dia 04/Outubro/2010. Diferente da versão anterior(2.1), que trouxe inúmeras novidades em termos de novos recursos, o FB 2.5 traz mais mudanças internas (nem sempre tão visíveis para o usuário), como forma de preparação para a tão aguardada versão 3.0. No entanto, alguns novos recursos adicionados são bem interessantes, e até ansiosamente aguardados pelo usuários.alguns desses recursos já foram expostos em artigos anteriores, e outros podem até passar despercebidos para os mais afoitos e desavisados. Neste artigo, apresentarei alguns dos novos recursos do FB 2.5, especialmente os que considero de maior importância. Para uma lista completa de todas as mudanças, leia o Release Notesdisponível em http://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes251.html Como de costume, o Firebird 2.5 permite acessar bancos de dados criados em versões anteriores do FB. No entanto, para aproveitar alguns dos novos recursos, é necessário que o BD esteja com a ODS 11.2 (utilizada pelo FB 2.5). Para atualizar a ODS de um banco de dados, veja o item Migrando um BD para o Firebird 2.5 a seguir. Instalaçãodo Firebird 2.5 O processo de instalação dofirebird 2.5 continua o mesmo das versões anteriores: simples, rápido e indolor. A principal diferença é que em alguns instaladores, como o da versão Windows, você terá a opção de escolher o uso da nova arquitetura SuperClassic durante o processo de instalação. No Linux, o SuperClassic vem junto no mesmo pacote que o Classic, sendo este último o padrão em uma instalação nova. Para alterar entre SuperClassic e Classic, deve-se usar oscript changemulticonnectmode.sh disponível na pasta bin do FB. Ao executar o script, certifique-se que o usuário do Linux tem direitos suficientes. O script perguntará qual modo você deseja ativar: process ou thread, sendo que process = Classic e thread = SuperClassic. SuperClassicx Classic x SuperServer As diferenças entre a arquitetura Classic e SuperServer já são conhecidas de longa data pelos usuários do Firebird. O SuperClassic é um híbrido entre as duas arquiteturas, sendo indicado para uso em máquinas multi-core/smp com grande quantidade deconexões. Diferente do Classic, onde existe um processo do Firebird servindo cada conexão, o SuperClassic usa threads (como o SuperServer) para servi-las.no entanto, o SuperClassic (diferente do SuperServer) não compartilha o cache entre as conexões, portanto, deve-se atentar para a definição correta do tamanho do cache, para não consumir toda a memória da máquina, gerando swap e lentidão. A fórmula básica para estimar o consumo de 1/9

memória do FirebirdClassic/SuperClassic é: Quantidade de memória consumida pelo cache = número de conexões simultâneas x número de páginas definidas para cache x tamanho do pagesize definido para o BD O SuperClassic utiliza menos recursos do sistema do que o Classic, tendo melhor escalabilidade. O SuperServer, na versão 2.5,consegue aproveitar mais de um núcleo/processador quando mais de um arquivo de BD é acessado. Ou seja, se você tem uma máquina multi-core, e mais de um bancode dados no Firebird, pode compensar alterar o parâmetro CPUAffinityMask do firebird.conf para que o Firebird possa utilizar mais processadores. Em versões anteriores, o SS sempre tinha apenas uma thread ativa em um determinado momento. Na versão2.5, haverá tantas threads ativas (ao mesmo tempo) quanto o número de BDs sendo acessados. Note que, no momento, o SuperServer não consegue usar adequadamente mais que um núcleo/processador para servir conexões a um mesmo BD (para isso, use o CS ou o SC). A versão 3.0 trará uma arquitetura multi-thread, com total aproveitamento de SMP, e com cache compartilhado, ou seja, o melhor dos mundos. Migrando um BD para o Firebird 2.5 O Firebird 2.5 cria os bancos de dados utilizando a ODS 11.2. Muitos dos novos recursos introduzidos nessa versão, só estão disponíveis em BDs com ODS 11.2, portanto, é interessante migrar os bancos de dados criados em versões anteriores do FB paraa nova ODS. A forma mais fácil de migrar é realizando um backup/restore do banco, já com o Firebird 2.5 rodando. Note que, para bancos criados em versões mais antigas do Firebird, alguns dados/metadados do banco podiam ter problemas referente à codificação dos caracteres, especialmente se você usou caracteres especiais, como acentos, etc. em comentários de procedures, etc. O Firebird 2.1 trazia scripts especiais para a correção destes problemas, mas o processo foi simplificado no Firebird 2.5, com a criação de novos parâmetros para o gbak,disponíveis no processo de restauração de um backup: FIX_FSS_D(ATA) <charset> FIX_FSS_M(ETADATA) <charset> Caso você não especifique esses parâmetros durante o restore, e o Firebird encontre problemas nos dados ou nos metadados, o gbak mostrará um aviso sugerindo o uso dos parâmetros acima para corrigir o problema. Mais informações podem ser obtidas nos arquivos disponíveis na subpasta misc\upgrade\metadata do diretório de instalação do Firebird. Dica: Ao se fazer um backup que será logo seguido de um restore, é interessante usar o parâmetro g do gbak, impedindo a coleta de lixo, geralmente tornando o processo de backup mais rápido. ClienteThread Safe 2/9

Até a versão 2.1 dofirebird, a biblioteca fbclient.dll não era thread-safe. Isso significa que se você utiliza múltiplas threads na sua aplicação, e essas threads realizam operações no banco de dados ao mesmo tempo, a única forma de garantir que tudo funcione corretamente é fazendo com que cada thread tenha sua própria conexão e transação com o banco de dados. Você até pode usar uma única conexão/transação na aplicação, desde que as threads não acessem o BD ao mesmo tempo. O Firebird 2.5 traz uma biblioteca cliente thread-safe! Isso quer dizer que não é mais necessário ter uma conexão e transação em cada thread na aplicação, para que as coisas funcionem corretamente. No entanto, todas as requisições enviadas ao banco dedados pela mesma conexão são serializadas, ou seja, se mais de uma threadfizer uma requisição ao BD, as requisições serão enviadas na sequência em que foram recebidas, e não simultaneamente. Caso sua aplicação precise que as requisições sejam enviadas "em paralelo", use o modelo onde cada thread possui sua própria conexão/transação com o banco. Embedded não exige mais acesso exclusivo O servidor embedded, que permite distribuir/utilizar o Firebird sem a necessidade de instalação do FB na máquina do usuário, foi alterado de forma que o arquivo de BD acessado não fica mais exclusivo a aplicação que o conectou. Portanto, agora é possível ter uma aplicação usando o FB embedded conectado a um BD, e ao mesmo tempo acessar esse mesmo BD de outras aplicações, ou utilitários (gbak, etc). A mudança foi possível pelo fato do embedded do FB 2.5 utilizar a arquitetura SuperClassic, ao invés dasuperserver, como acontecia nas versões anteriores, dispensando assim a necessidade de acesso exclusivo ao arquivo do BD. Gerenciamento de usuários via SQL Todos aqueles que já precisaram criar ou manipular usuários do Firebird em suas aplicações, sabem que isso só era possível através de funções da API do Firebird, ou via gsec.exe. O Firebird 2.5 permite que a manipulação de usuários (criação, alteração, remoção) seja possível através dos novos comandos CREATE / ALTER / DROP USER. Também foi criado um novo domínio chamado RDB$ADMIN, que pode ser atribuído a usuários comuns do BD, dando a eles privilégios de SYSDBA. Somente o SYSDBA (ou algum usuário para o qual tenha sido atribuído o role RDB$ADMIN, tanto no BD acessado como no BD de segurança) pode criar ou manipular usuários. Usuários comuns só podem alterar sua própria senha. Collate padrão para o banco Sabemos que sempre foi possível definir um CHARSET padrão para o banco de dados. Campos textuais (char, varchar, etc) assumem automaticamente o charset padrão do banco, caso outro charset não seja explicitamente especificado durante a criação do campo. 3/9

No entanto, definir um collate padrão para o BD era uma tarefa complicada, e que não sobrevivia a um backup/restore do banco. No FB 2.5, é possível definir o collate padrão durantea criação do banco, seguindo a sintaxe: create database <file name> [ page_size <page size> ] [ length = <length> ] [ user <user name> ] [ password <user password> ] [ set names <charset name> ] [ default character set <charsetname> [ [ collation<collation name> ] ] [ difference file <file name> ] Também é possível alterar o collate padrão para um charset, em um banco já existente, através do comando: ALTER CHARACTER SET<charset_name> SET DEFAULT COLLATION <collation_name> Devemos ficar atentos que lguns collates utilizam mais que um byte por caractere, o que pode influenciar nos limites de tamanhos das chaves de índices, e consumir espaço extra no BD. O Firebird 2.5 também trouxe collates case/accent insensitive para Unicode. Auditoria e rastreamento do servidor O Firebird 2.5 incorporou e melhorou os recursos de auditoria e rastreamento de sessões de usuários existentes no RedDB (banco de dados baseado no Firebird e desenvolvido pelaredsoft). Através dos novos recursos,é possível saber, em tempo real, tudo que está acontecendo no servidor, com a possibilidade de definir filtros a fim de auditar somente algumas operações. O detalhamento deste recurso exigiria um artigo completo dedicado a ele. Para todas as informações, leia o release notes, e baixe os slides do Douglas Tosi, do FDD. Usuários normais podem rastrear apenas suas próprias conexões. Usuários administradores (SYSDBA/OWNER) podem rastrear e gerenciar qualquer conexão. RemoteFileOpenAbility Sabemos que o Firebird sópermite acessar bancos de dados que estejam gravados em dispositivos locais na máquina servidora. No Linux, o parâmetro RemoteFileOpenAbility já permitia, há algum tempo, que o FB acessasse BDs gravados em drives NFS. O recurso foi ampliado, passando a funcionar também no Windows, para drives SMB/CIFS. Mas calma! Deve-se tomar muito cuidado com isso, pois as chances de se obter um banco de dados corrompido são muito maiores, devido a possíveis instabilidades na rede, ou situações errôneas onde mais de um servidor Firebird (em diferentes máquinas) estejam acessando o mesmo arquivo de BD 4/9

(haveria problemas na alocação e gerenciamento das travas, causando corrupção). A ativação deste parâmetro é recomendada apenas caso se deseje criar um arquivo shadow do banco de dados em um drive da rede, lembrando também que a rede é um gargalo para as operações de I/O, portanto, não aconselho usar esse recurso com redes inferiores a Gigabit. Enfim, use com cuidado, e antes de habilitá-lo, leia com atenção as informações sobre este parâmetro, disponíveis no arquivo firebird.conf. Cancelamento de conexões Agora é possível derrubar conexões através das tabelas de monitoramento do Firebird. Para tanto, basta executar um DELETE na tabela mon$attachments. O comando abaixo derruba todas as conexões, menos a que está executando o próprio comando: DELETE FROMMON$ATTACHMENTS WHERE MON$ATTACHMENT_ID <> CURRENT_CONNECTION; As transações abertas associadas às conexões que forem derrubadas, serão automaticamente desfeitas (rollback). Pode-se derrubar uma conexão especifica, bastando especificar o ID, como no exemplo abaixo: DELETE FROMMON$ATTACHMENTS WHERE MON$ATTACHMENT_ID = 10; -- Mata a conexão 10 Expressões regulares (regex) SIMILAR TO agora aceita expressões regulares, permitindo usos bastante interessantes, desde cláusulas WHERE até check constraints. A Wikipédia traz a seguinte definição para expressões regulares: Em ciência da computação, uma expressão regular (ou o estrangeirismo regex, abreviação do inglês regular expression) provê uma forma concisa e flexível de identificar cadeias de caracteres de interesse, como caracteres particulares, palavras ou padrões de caracteres. Expressões regulares são escritas numa linguagem formal que pode ser interpretada por um processador de expressão regular, um programa que ou serve um gerador de analisador sintático ou examina o texto e identifica partes que casam com a especificação dada. Um exemplo prático, para definir uma check constraint compatível com o padrão de números de telefone adotado no Brasil, seguindo oformato (xx) yyyy-yyyy, onde xx é o DDD, seria: check (telefone similar to '\([0-9]{2}\) [0-9]{4}\-[0-9]{4}' escape '\') A expressão regular acima fará com que a constraint só aceite telefones com DDD compostos de 2 dígitos (entre parêntesis), e telefones com 8 dígitos (separados por - em dois blocos de 4). Podem também ser usadas em consultas: select * from clientes where telefone similar to '\([0-9]{2}\) 1234\-%' escape '\'; O select acima retornará todos os clientes cujo telefone começa com 1234, independente do DDD. O release notes traz todas as informações necessárias sobre o que é suportado na implementação de expressões 5/9

regulares no FB 2.5. Infelizmente, não é possível utilizar as regex para fazer substituição em strings. Melhorias no Otimizador Já é tradição que a cada nova versão do Firebird, o otimizador de queries fique mais inteligente, e nessa versão não foi diferente! Vale ressaltar a mudança que faz com que o FB consiga utilizar um índice (quando disponível) em expressões usando NOT IN com subqueries, ex: Select... where campo not in (select ) Outra melhoria é referente ao consumo excessivo de memória quando havia múltiplos updates em uma mesma tabela. Acessoa outros bancos de dados Recurso amplamente aguardado por muitos usuários, permite que se possa conectar e executar operações em outras bases de dados, de dentro de procedures, triggers ou blocos PSQL! Com isso, passa a ser possível recuperar informações (select )ou executar comandos como insert,update,delete,etc, a partir do PSQL, em outras bases de dados. Para tanto, o comando EXECUTE STATEMENT foi turbinado com novos parâmetros, permitindo acessar bases externas, conforme sintaxe abaixo: [FOR] EXECUTE STATEMENT <query_text> [(<input_parameters>)] [ON EXTERNAL [DATA SOURCE] <connection_string>] [WITH {AUTONOMOUS COMMON} TRANSACTION] [AS USER <user_name>] [PASSWORD <password>] [ROLE <role_name>] [WITH CALLER PRIVILEGES] [INTO <variables>] Note que, ainda não é possível misturar em um mesmo select, tabelas que pertençam a diferentes bancos de dados. Caso seja necessário retornar dados trazidos de diferentes BDs, aconselho o uso do execute statement alimentando uma tabela temporária, que concentraria as informações vindas dos diferentes BDs em um único lugar. A intenção é que, em versões futuras do Firebird, seja possível até mesmo acessar bases de dados externas que não sejam Firebird, provavelmente através de ODBC. O execute statement também passa a aceitar parâmetros, o que era proibido anteriormente. Um uso interessante paraesse recurso,é armazenar logs de alterações de dados em um banco de dados separado do principal, conforme demonstrei no FDD, este ano. O exemplo pode serbaixado gratuitamente na área de downloads do site www.firebase.com.br Backup Incremental via API de serviços O Firebird, desde sua versão2.0, suporta backups incrementais através do utilitário nbackup. No Firebird2.5, foi adicionada a possibilidade de realizar os backups incrementais atravésda API de serviços, facilitando a integração deste procedimento em aplicaçõesgui. 6/9

O backup/restoreincremental, via API de serviços, também pode ser disparado através do utilitário fbsvcmgr, conforme exemplos: Criar um backup de nível 0: fbsvcmgrservice_mgr action_nbak dbname employee nbk_file e.nb0 nbk_level 0 Criar um backup de nível 1: fbsvcmgr service_mgr action_nbak dbname employee nbk_file e.nb1nbk_level 1 Restaura ro BD dos arquivos acima: fbsvcmgr service_mgr action_nrest dbname e.fdb nbk_file e.nb0 nbk_file e.nb1 Nova sinformações nas tabelas de monitoramento As tabelas de monitoramento foram adicionadas no Firebird 2.1, e permitem obter informações instantâneas sobre o que está sendo executado no banco de dados. Através delas, é possível recuperar informações sobre as conexões ativas, queries sendo executadas, etc. O Firebird 2.5 ampliou asinformações disponíveis em algumas das tabelas de monitoramento, possibilitando, por exemplo, obter informações sobre o uso de memória evariáveis contextuais. O select abaixo,listaos 10 comandos com maior consumo de memória, que estão sendo executados: SELECT FIRST 10 STMT.MON$ATTACHMENT_ID, STMT.MON$SQL_TEXT, MEM.MON$MEMORY_USED FROM MON$MEMORY_USAGE MEM NATURAL JOIN MON$STATEMENTS STMT ORDER BY MEM.MON$MEMORY_USED DESC Conclusão Neste artigo, listei as principais mudanças e novidades do Firebird 2.5. Para uma lista completa de todasas alterações, melhorias e novidades, é importante que você leia o ReleaseNotes, fonte de informação completa e oficial, disponível em cada release do Firebird. Última edição por Admin em Qui 12 Jul 2012-11:23, editado 1 vez(es) Admin Admin Mensagens: 11 Artigo Bacana paulo cesar em Qua 11 Jul 2012-16:54 7/9

Gostei do Tópico paulo cesar Mensagens: 1 Re: Introdução Firebird 2.5 Everson em Ter 17 Jul 2012-11:03 Ótimo artigo. Everson Mensagens: 1 Substring em campo Blob Admin em Ter 17 Jul 2012-16:36 Hoje atualmente no firebird 2.0 para fazermos um group by em campo blob temos que fazer um susbstring no mesmo. Já com a Versão mais atual não necessitamos mais de fazer isso, pois esse tipo de situação fora corrigido na versão 2.5. Outro detalhe que no firebird 2.0 quando se faz substring em campo blob o mesmo da retorno do tipo varchar e com a versão 2.5 o mesmo mudou, retorna como blob mesmo. Ai no caso tem que fazer um cast no campo para varchar para retornar como varchar. Admin Admin Mensagens: 11 Re: Introdução Firebird 2.5 Joanderson em Qua 18 Jul 2012-7:56 Muito bom artigo acerca das melhorias a partir da versão 2.5. 8/9

Joanderson Mensagens: 1 Ir para: Selecionar um fórum Ir Ferramentas de moderação: Selecionar Ir PERMISSÃO DESTE FÓRUM: Você pode responder aos tópicos neste fórum Você pode moderar este fórum Início phpbb Estatísticas Fale conosco Assinalar uma queixa Painel de Controle 9/9