Bom, depois de escrever sobre algumas vantagens do PostgreSQL em relação ao Oracle, chegou a hora de fazer o inverso. Eis aqui algumas características do Oracle que eu realmente sinto falta no PostgreSQL.

• Triggers de sistema. O Oracle possui a capacidade de disparar gatilhos quando você inicia o SGDB, quando um usuário se conecta, quando realiza uma operação de DDL, etc. Isso ajuda muito para quem quer realizar auditorias e construir alguns esquemas especiais de segurança. Além disso, o Oracle possui o AUDIT que que é um comando que utiliza uma estrutura pronta para auditar diferentes eventos;
• O PostgreSQL também tem ferramentas para gerar logs, mas o Oracle realiza isso com maior nível de controle, permitindo especificar uma sessão específica. Isto ajuda muito para monitorar uma ação específica dentro de um ambiente de produção.
• O Oracle permite de indicar um tablespace separado para o Tablespace TEMP e UNDO. Isto permite um ajuste de desempenho melhor, particularmente colocando o tablespace TEMP em outro disco em aplicações de BI que fazem consultas enormes. É claro que você consegue fazer isto no PostgreSQL utilizando links simbólicos, mas esta não é a forma mais elegante de se fazer isto. A versão 8.3 do PostgreSQL já deve trazer avanços neste sentido.
• Fine -Grained Access, é uma ferramenta do Oracle que permite o acesso a determinadas linhas de uma tebela de acordo com o perfil do usuário conectado. Este é um recurso interessante que em aplicações corporativas podem ajudar um bocado.
• Maior flexibilidade na definição dos arquivos de log de transação. No Oracle é possível determinar o tamanho e o local de cada log, além de fazer um espelhamento se você desejar. O PostgreSQL permite alterar o tamanho dos arquivos de log alterando um parâmetro no código fonte e também é possível criar links simbólicos para alterar a posição dos arquivos de log. No entanto, acho que o Oracle tem uma solução mais robusta neste ponto.
• O Oracle tem a possibilidade de criar tablespaces com diferentes tamanhos de bloco e buffers específicos para cada tamanho de bloco. Num ambiente que mistura características de OLTP com BI, isto pode ser interessante. É claro que oideal seria separar os dois ambientes em servidores distintos. No entanto esta opção confere ao Oracle uma flexibilidade adicional no ajuste de performance e uso do disco.
• SQLLoader é uma ferramenta para importação de grandes volumes de dados em arquivos texto em diversos formatos. E uma ferramenta realmente robusta e flexível que pode lhe ajudar a fazer ETL, migrar dados de plataformas distintas, etc.
• O Oracle permite a paralelização de operações pesadas, incluindo backups lógicos, importações via SQLLoader, consultas longas, etc. No PostgreSQL, você tem o PGPool II que permite a paralelização de consultas pesadas, mas não tem ferramentas para outras situações. Você também pode disparar duas operações de backup lógico em separado definindo partes diferentes do banco de dados para a operação. No entanto, crieio que a opção de paralelização seja uma alternativa interessante.
• O RAC (Real Aplication Cluster) é uma solução conhecida de cluster de banco de dados no Oracle. O RAC é uma solução que permite escalar o Oracle horizontalmente além de prover uma considerável tolerância a falhas. O PostgreSQL tem a capacidade de escalar verticalmente melhor que o Oracle, mas não tem ainda uma solução para escalar horizontalmente, nem uma solução para tolerância a falhas que seja síncrona, apesar de em Linux existirem soluções para isto. Existe um projeto chamado PGCluster II que promete fazer uma implementação semelhante ao RAC no PostgreSQL.
• As ferramentas de monitoramento da Oracle são realmente úteis. A partir do Oracle 10g o “Database Control” tem facilidades realmente interessantes e acredito que a versão 11g tenha melhorado mais ainda isso. Existe um projeto chamado Cedrus que promete cobrir boa parte deste vácuo no PostgreSQL. No entanto, já existem ferramentas como o Munin, que fazem um bom monitoramento do servidor e possui algumas extensões para o Oracle, PostgreSQL e MySQL, além de ser simples criar novas extensões.
• Ajuste automático de memória. O Oracle possui alguns parâmetros de inicialização se ajustam limites de memória para o Oracle e deixa ele distribuir este espaço entre as diversas áreas internas. Isto realmente pode simplificar muito o trabalho do DBA. Já ouvi falar que o pessoal da SUN tem interesse em investir em mecanismos deste tipo no PostgreSQL, mas isto ainda deverá levar alguns anos para se concretizar.
• Os índices do tipo bitmap ajudam muito em colunas de baixa cardinalidade e poucas gravações. O PostgreSQL tinha programado para implementar esta funcionalidade na versão 8.3 mas adiou para a versão 8.4. No entanto os índices bitmap são utilizados na memória (mas não em disco) no PostgreSQL em durante uma busca.
• O Particionamento de tabelas do Oracle também tem algumas vantagens sobre o particionamento do PostgreSQL como o particionamento por hash e outras funcionalidades que ajudam a dar manutenção em tabelas particionadas.
• Controle de transações dentro de um bloco PL/SQL. Isto é algo que me faz falta no PostgreSQL quando você precisa de funções mais complexas. No PostgreSQL todo o bloco PL roda dentro de uma única transação, enquanto do Oracle você pode declarar o begin, commit, rollback e savepoint dentro do PL/SQL.
• Visões materializadas, são coisas possíveis de serem feitas utilizando-se gatilhos e funções no PostgreSQL, mas é bem mais fácil quando você já tem uma estrutura sintática pronta para isso como no Oracle.
• O Jobs Scheduler é ferramentas do Oracle que permite o disparo de ações específicas através do agendamento em horário específico, se repetindo ou não em intervalos programados. Muitas pessoas resolvem esta ausência utilizando o CRON do Linux, mas o Job Scheduler tem uma série de funcionalidades interessantes, além de permitir tratar tudo via SQL.

É claro que o Oracle tem a mania de abocanhar o mundo e oferece uma miríade de funcionalidades, algumas exóticas e certamente algumas que eu não conheço. Se você sentiu falta de algum item, por favor deixe a sugestão nos comentários. Muito do que está aqui acaba sendo importante para quem pretende migrar de Oracle para PostgreSQL e não sabe se vai encontrar as funcionalidades que espera.

Bom… todos sabem que o Oracle possui uma miríade de recursos bacanas e interessantes. Alguns deles o PostgreSQL realmente não tem, e alguns eu acredito que nunca terá (até porquê a equipe do PostgreSQL tem uma visão diferente em vários pontos da Oracle). Não estou dizendo que o PostgreSQL é melhor que o Oracle ou vice versa… estou dizendo apenas que escolher um SGDB não é como escolher uma roupa para dar de presente. Não basta olhar a marca e se deslumbrar com comerciais fantásticos, shows de luzes e coquiteis luxuosos. Você tem que conhecer as funcionalidades de cada um e saber onde está entrando. E o que quero demonstrar aqui é que o PostgreSQL também revela suas qualidades! É comum pessoas perguntando sobre recursos que o PostgreSQL tem que o Oracle não tem… aqui vai uma pequena lista. Por favor sinta-se a vontade para acrescentar novos itens nos comentários.

• Readline: para quem está acostumado com o bash, sabe como é bacana poder utilizar algumas facilidades providas por esta maravilhosa biblioteca. Completar comandos e histórico de comandos são duas coisas que tornam a experiência em modo texto muito agradáveis. Eu sei que o SQLPLUS tem muitas funcionalidade interessantes, mas o psql é realmente uma ferramenta muito mais agradável devido ao uso do Readline e para mim isto significa perda de produtividade e aumento na curva de aprendizado do SQLPLUS.
• Maior flexibilidade com as linguagens com as PLs. O PostgreSQL tem suporte ao PL/pgSQL, está implantando o PSM e tem suporte a PL/Python, PL/Ruby, PL/PHP, PL/PERL etc. E ainda tem a possibilidade de cria-las no modo TRUSTED e UNTRUSTED. Isso é uma mão na roda e aproxima muito o time de desenvolvedores dos DBAs.
• LIMIT e OFFSET, estas duas cláusulas não fazem parte do padrão SQL, mas a maioria dos SGDBs implementam. Se você tiver que paginar páginas de uma consulta (coisa que você sempre deve fazer ao retornar mais de 100 linhas numa página web por exemplo) utilizando o ROWNUM, você verá que o mundo poderia ser mais simples.
• Uma das primeiras coisas que eu descobri quando comecei a utilizar o Oracle: você não pode criar uma tabela e colocar uma sequência como valor padrão para um campo. Isto é só um pequeno detalhe, mas convenhâmos, é bem prático utilizar um insert sem ter de lembrar o nome da sequência atrelada ao campo;
• O Dollar Quoting é uma característica do PostgreSQLque nos permite evitar situações incômodas onde precisamos escapar aspas simples e duplas. Quando se utiliza PL, isto pode se tornar um tanto incômodo. Além disso o Dollar Quoting é um bom aliado na luta contra o SQL Injection
• Algo irritante no Oracle é o nome atribuído a objetos criados implicitamente. Se você cria uma chave primária e não atribui um nome explicitamente, tanto o PostgreSQL quanto o Oracle atribuem um nome para a sua PK. Mas enquanto o nome atribuído pelo Oracle é algo como SYS1328909 o PostgreSQL utiliza nomes muito mais inteligentes, através de um padrão de nomenclaturas inteligível. Num ambiente de testes onde os desenvolvedores esqueçam de atribuir todos os nomes explicitamente, o caos passa a reinar rapidamente nos nomes de objetos do Oracle.
• Se você quer uma funcionalidade avançada que o PostgreSQL oferece, ela se chama GiST. O GiST é uma infraestrutura para a criação de novos típos de índices para novos tipos de dados. Com ele é possível criar aplicações com demandas muito específicas com um excelente desempenho sem muito esforço. É claro que não é qualquer um que vai utilizar isso (assim como não é qualquer um que utiliza uma série de funcionalidades avançadas do Oracle), mas o leque de opções que isto abre é enorme. Existem algumas implementações de índices utilizando o GiST prontos para você utilizar. Eles mostram o poder de adaptação que o PostgreSQL possui para demandas específicas.
• Conformidade com o padrão SQL2003. Sim… o Oracle possui diversas coisas estranhas como usar o VARCHAR2 ao invés de VARCHAR, não utiliza o as visões do catálogo de sistema padrão e inúmeras coisas estranhas que são heranças antigas do Oracle que parecem que não tem melhorado muito nas últimas versões. O tipo de dados TIMESTAMP por exemplo, só surgiu na versão 9i. O mais simples tipo de dados, o BOOLEAN simplesmente não existe no Oracle. Se você quer saber mais sobre isso, compare você mesmo a lista de compatibilidade do Oracle e do PostgreSQL.
• Melhor integração com o SO. Você já atualizou uma Distribuição Linux com um Oracle instalado? Prepare-se para muita dor de cabeça, pois o processo é no mínimo delicado. Para quem utiliza uma distribuição Linux como o Debian, isso mal passa pela cabeça do DBA. Você atuliza o SO junto com o PostgreSQL e pronto. Outra coisa interessante é que você pode utilizar os redirecionamentos do shell para jogar a saída de uma exportação direto na entrada de uma importação. Isso economiza tempo de disco. Na verdade o PostgreSQL se ajusta muito bem com o Padrão POSIX, enquanto a Oracle insiste em criar suas próprias regras como o OFA (Optimal Flexibe Architeture).
• Você pode subir um Oracle num 486?? O Oracle é pesado, um verdadeiro dragão devorador de recursos. A versão 11g que foi lançada recentemente pede um mínimo de 1GB de memória no servidor. O PostgreSQL é bem mais flexível neste sentido. Você pode subir um PostgreSQL para testes no seu próprio desktop em 2 minutos e já sair testando sem ter que se preocupar muito com isso. Eu particularmente chego a ter 2 ou 3 versões do PostgreSQL rodando no meu desktop sem problemas. Agora dê uma olhada no procedimento de instalação do Oracle e você verá porquê poucas pessoas sabem colocar ele no ar de maneira adequada!
• Suporte a um número maior de arquiteturas. Por incrível que pareça, o Oracle não roda no FreeBSD por exemplo. Vale a pena comparar as arquiteturas suportadas pelo Oracle e PostgreSQL.
• Independência de suporte. Todo mundo pergunta se o PostgreSQL tem suporte confiável no Brasil. Tem sim, não vou me pronunciar a favor de um ou outro aqui, mas temos empresas muito competentes aqui no Brasil. Mas alguém já se perguntou como é o suporte da Oracle??? Como eles são detentores do código fonte do Oracle, só eles podem lhe oferecer um contrato de suporte mais profundo. Pergunte a um DBA Oracle como é o suporte da Oracle e você irá se surpreender! Já no PostgreSQL você não encontra este problema, você pode escolher a empresa que vai lhe prestar suporte. Se você não gostou do suporte de uma empresa… chame outra! Está com medo de ninguém segurar o rojão quando um problema mais sério acontecer? Quem disse que a Oracle não vai lhe deixar na mão? Bom, quer conhecer o suporte da Oracle, saiba o que mais de 90% das pessoas conhecem por suporte é na verdade apenas o acesso ao Metalink. Mas suponhamos que você precise de algo um pouco específico mais onde o Oracle não lhe atende? Bom, o mais provável é que a Oracle lhe diga NÃO ou se você der sorte estará diante de um orçamento monstruoso. Se você precisar de algo diferente no PostgreSQL, você pode entrar em contato com qualquer um dos seus desenvolvedores (existem alguns no Brasil) e solicitar uma nova funcionalidade. Você vai pagar apenas as horas de desenvolvimento dele e se ele achar que a funcionalidade é importante, você provavelmente verá ela implementada na Próxima versão do PostgreSQL e nunca mais terá de se preocupar com isso. Acredite ou não, várias funcionalidades do PostgreSQL que você usa hoje, surgiram assim. Veja o exemplo dos SkyTools. Existem empresas menores que tem contratos de manutenção com desenvolvedores do PostgreSQL e utilizam versões modificadas com particularidades mais bizarras e funcionam sem problemas. Um detalhe… se você não gostar do desenvolvedor, você simplesmente contrata outro, uma vez que você não precisa estar amarrado a ele.
• Acesso aos desenvolvedores. Você já perguntou alguma coisa a um desenvolvedor do Oracle? No postgreSQL isso é tranquilo, basta entrar na lista de discussão dos desenvolvedores. Um exemplo de como isso pode ser útil é saber o que esperar das próximas versões. Todo o ciclo de desenvolvimento é transparente, você sabe o que será implementado na próxima versão, e o que estão querendo implementar nas próximas. Saber para onde o seu SGDB vai dá muita segurança para o DBA.
• Acesso aos paths de correção independente de pagar licenciamento. Todo mundo fica com o orçamento apertado durante algum tempo. Mas se você deixar de pagar o suporte da Oracle, prepare-se para ficar vulnerável. As atualizações só estão disponíveis para quem está com seus pagamentos em dia;
• Você não precisa fazer um curso sobre licenciamento antes de iniciar o uso do PostgreSQL. Independente do custo das licenças, saber quais recursos você vai precisar licenciar com a Oracle, é um verdadeiro tormento. A cada versão as opções de licenciamento mudam e um número maior de opções pagas separadamente são oferecidas. O Oracle Forms começou como uma ferramenta gratúita que numa nova versão passou a ser paga e hoje está sendo descontinuada. Muitos orçamentos estouram porquê no meio do projeto se descobre que uma funcionalidade importante não foi prevista no contrato de licenciamento. Isso quando você não instala opções não licenciadas sem querer. Para licenciar um Oracle, você deve começar lendo “Software Investment Guide” que é um documento de 61 páginas explicando quando uma licença se aplica ou não, dependendo da arquitetura de SGDB que você quer montar. Depois precisa conhecer a diferença entre as 5 versões básicas do Oracle: “Express Edition”, “Personal Edition”, “Standard Edition”, “Standard Edition One” e “Enterprise Edition”. Aí você vai ter que conhecer cada uma das 15 opções do Enterprise Edition que são licenciadas a parte e ver se você vai precisar de algumas delas no seu projeto. Depois disso você precisa conhecer as opções de licenciamento e definir a melhor métrica a ser utilizada: por processador ou por usuários nomeados. Pronto, agora é definir o número de licenças para a sua arquitetura dentro da métrica escolhida e multiplicar pelo custo da licença de cada componente que você vai comprar. Não esqueça de incluir no mínimo o suporte standard da Oracle que custa em média 20% do custo total das suas licenças ao ano. Este custo só lhe dá acesso ao metalink, que inclui uma base de conhecimento, acesso aos paths de correção e pedidos de suporte via web. Se você quiser um suporte de verdade, aquele que você acha que o PostgreSQL não tem então você vai ter que fazer um novo estudo de custos baseado no SLA desejado.
• Linux é Linux, não importa qual distribuição você utilize. O Oracle roda em qualquer distribuição Linux atual. Eu já utilizei por um bom tempo em Debian e fiquei muito satisfeito com o resultado. Mas se você deseja ter qualquer nível de suporte da Oracle, você só vai poder utilizar 3 ou 4 distribuições homologadas por eles (incluindo a versão da própria Oracle que é uma cópia do Red Hat). Isto não significa que estas são as melhores distribuições Linux do mercado (embora sejam muito boas). A questão é que você não pode escolher. Da mesma forma, não é qualquer hardware que você pode utilizar para para rodar o Oracle, tem que se um hardware homologado. Estes dias vi que a Oracle homologava algumas soluções de NFS fornecido por terceiros. Isto significava que se você comprasse uma solução de NFS de um dos parceiros homologados pela Oracle, eles lhe dariam suporte. Depois a Oracle desistiu da parceria e deixou de homologar estas soluções (pois ela lançou sua própria versão de NFS). Quem comprou a solução indicada pela Oracle simplesmente deixou de ter uma solução homologada, o que significa: nada de suporte para você.
• Poder publicar benchmarks! Você já viu um artigo com uma comparação entre desempenho do PostgreSQL e o Oracle? Não? E provavelmente não verá. A Oracle pode processar qualquer um que publique testes de desempenhos comparativos com o Oracle sem a sua autorização. Isto faz parte do licenciamento do Oracle. Assim é fácil dizer que é mais rápido sempre! Aliás, vou te dizer que o PostgreSQL pode ser utilizado em projetos que envolvam tecnologia militar, pode ser utilizado por cubanos e iraquianos, brasileiros, etc, etc, etc…

Este é a primeira parte de uma série de três textos que quero escrever sobre sobre o Log de Transações de SGDBs. A primeira parte é uma explicação inicial sobre o que é um log de transações e para que ele serve. Espero escrever em breve mais duas partes falando mais detalhadamente sobre como uma transação ocorre dentro do SGDB e outra falando sobre configurações de Alta Disponibilidade e desempenho envolvendo o Log de Transações.

D

Todo SGDB relacional que eu conheço usa logs de transação. O Oracle chama isso de “Redo Log” o PostgreSQL chama de “Write Ahead Log”, o DB2 chama de “Active Log” e o MySQL chama de “Binary Log”, mas todos tem. O log de transações é uma forma engenhosa dos SGDBs conseguirem garantir o “D” do ACID. A questão é simples: você precisa garantir que após a conclusão com sucesso de uma transação, com um COMMIT, este dado dure no banco de dados, mesmo que alguma falha aconteça, como a falta de luz. Isto significa que de alguma forma os dados devem ser gravados em disco e não estarem simplesmente na memória. Esta é uma exigência que tem um profundo impacto no projeto de um SGDB. Para lidar com isso, a melhor forma de garantir isso não é gravar os dados direto nos datafiles. Este tipo de gravação tem um custo alto pois:

• A órdem da gravação é randômica;
• Uma operação de UPDATE pode fazer com que os dados que antes cabiam num bloco de dados não caibam mais, exigindo algum tipo de reorganização;
• Você tem que atualizar não só os dados como os índices também;
• Você tem que gerenciar o espaço livre em disco;
• Um mesmo dado pode ser alterado várias vezes num curto espaço de tempo;

É claro que em algum momento você deverá gravar todos os dados alterados, mas os SGDBs preferem gravar os dados a partir dos buffers em memória onde eles tem algorítimos que gerenciam a operação de gravação em disco com muito mais eficiência. Então o que ocorre é que o SGDB trabalha com os buffers de memória o tempo todo e grava os dados destes buffers nos datafiles de tempos em tempos, num processo conhecido como “Checkpoint”.

Bom, eu disse que a cada COMMIT, você precisa gravar em disco as informações sobre os dados alterados. Se houver uma falta de energia depois do COMMIT e antes do Checkpoint você terá problemas! O que é feito é criar um log com todas as alterações realizadas nos dados. Este log tem de seguir rigorosamente a lógica de realizar uma gravação para cada transação confirmada. No caso de uma falta de energia, ao reiniciar o servidor, o SGDB vai utilizar o log de transação para recuperar todas as transações concluídas depois do último Checkpoint. É assim que o “D” do ACID é garantido.

Arquivamento

Os logs de transação são um mal necessário. É um mal porquê ele é um grande gargalo de desempenho no SGDB. É necessário porquê você não está disposto a arcar com os riscos de perder os seus dados. Para ter um impacto de desempenho menor, a gravação dos logs é sempre feita de forma sequêncial e não aleatória. Ou seja o log é um arquivo que vai crescendo de forma incremental. No entanto estes logs não crescem de maneira indefinida. Eles possuem um formato finito e quando o arquivo atinge este tamanho ele inicia um novo arquivo de log.Os arquivos de logs trabalham de forma rotativa, reaproveitando arquivos de logs antigos. Uma coisa importante a saber sobre eles é que eles tem tamanho e quantidade predefinidas. Alguns SGDBs tem maior ou menor facilidade em configurar opções neste sentido. Em ambientes de teste, o reaproveitamento dos logs não constitui um problema, mas em ambientes de produção é importante realizar uma cópia dos logs antes deles serem reaproveitados. A cópia destes logs é conhecida como arquivamento. O arquivamento é fundamental para a recuperação no caso de perda um datafile. Se você tiver perdido um datafile, você pode recuperar ele de um backup realizado em fita ou outro meio. No entanto, este datafile estará com as informações desatualizadas a partir da data do backup. É aí que os log arquivados entram em ação. Após recuperar o datafile, você pode utilizar todos os logs arquivados após o backup para recriar as transações naquele datafile específico. Desta forma, uma boa estratégia de backup em ambiente de produção deve incluir o backup físico dos datafiles e a realização do arquivamento dos logs de trasação.
Além disso, graças ao arquivamento dos logs, alguns recursos interessantes podem ser implementados, como veremos a seguir.

Point In Time Recovery (PITR):

O PITR é um recurso sofisticado que lhe possibilita realizar não apenas recuperar os seus dados em caso de uma falha, mas voltar para um ponto específico no tempo, como alguns minutos antes de alguém apagar uma tabela ou realizar alguma outra transação catastrófica. O PITR pode ser uma verdadeira máquina do tempo. Algumas ferramentas de PITR permitem restaurar apenas uma parte dos dados para um ponto no passado.

Backup On Line

O backup físico do banco de dados (em contraste com o backup lógico) é uma parte fundamental numa estratégia de recuperação de desastres. A forma mais comum de fazer isso é desativar totalmente o SGDB e copiar todos os arquivos do banco de dados (tente um dia copiar estes arquivos com o SGDB no ar e você verá o seu emprego sumindo sob os seus pés como num alçapão). Os backups físicos deste tipo são conhecidos como backup off line. Eles funcionam muito bem, mas podem ser um problema em ambientes 24/7. A cópia dos arquivos pode demorar algumas horas e ficar se backup não costuma ser uma idéia muito inteligente. Graças a existência dos logs de transação, é possível realizar o chamado backup on line onde o backup físico pode ser realizado sem tirar o SGDB do ar. No backup on line o processo de backup envia um comando para o SGDB que adia a realização do Checkpoint e os datafiles podem ser copiados mesmo com o banco de dados no ar. Assim que a cópia termina, um novo comando é enviado para o SGDB e o Checkpoint é liberado. Alguns SGDBs permitem que o backup on line seja feito para cada TABLESPACE individulmente. Em bancos de dados muito grandes ou com um grande volume de transações, isto pode ser uma boa idéia, pois você adia o Checkpoint somente para um TABLESPACE de cada vez.

Um detalhe importante é que para realizar backups on line, o arquivamento dos logs se torna obrigatório!

Stand By

Um outra coisa muito interessante que é possível se fazer com os logs de arquivamento, é a criação do SGDB em Stand By e outras técnicas de replicação Master/Slave. A idéia é simples: você pode criar um clone do seu servidor de produção num servidor secundário conhecido como Stand By e deixar ele sincronizado com o seu servidor de produção. Para isso você tem de criar outro SGDB idêntico e com uma cópia idêntica dos datafiles (backup off line). A partir do momento em que os servidor de produção volta ao ar após a cópia dos datafiles, você passa a exportar os log do ambientes de produção para o Stand By. Em caso de falha do ambiente de produção, você pode subir o Stand By que irá recuperar todos os logs arquivados até atingir a mesma posição do ambiente de produção.

O Stand By consistem um plano de contingência muito interessante e pode ter diferentes tipos implementações com características peculiares:

• Normalmente os logs são exportados do ambiente de produção somente no momento do arquivamento, portando o o Stand By está sempre um pouco defasado em relação ao ambiente de produção. Existem soluções de Stand By que são síncronas e só realizam o COMMIT após a confirmação da gravação do log no servidor de produção e no Stand By. Este tipo de solução, torna a gravação dos logs de transação um gargalo de desempenho ainda maior e devem ser implementados com cautela e uma excelente conexão de rede entre os servidores de produção e Stand By.
• Normalmente os logs só são importados no Stand By no momento em que ele é ativado (o SGDB fica inativo por padrão) e então o processo de recuperação dos logs é iniciado. É possível realizar recuperações programadas num intervalo regular de tempo para não acumular uma quantidade de logs muito grande para serem recuperados. Em outros casos, é utilizado o Stand By on line, onde os SGDB fica sempre no ar e vai aplicando os logs imediatamente após ele receber os logs do servidor de produção. Com o Stand By on line, é possível utilizar ele para realizar consultas, mas não para realizar gravações. Um Stand by on line pode ser muito útil para extrair relatórios pesados sem sobrecarregar as operações de OLTP no ambiente de produção;
• Normalmente os dados relativos ao Stand By se aplicam a todos os dados existentes na instância de produção. Existem implementações de Stand By que filtram os logs da instância de produção, replicando apenas uma parte objetos no banco de dados de produção.

Há alguns tempos eu postei aqui sobre dois novos blogs falando sobre PostgreSQL, hoje vou comentar sobre alguns artigos que andei sapeando neste fim-de-semana sobre bancos de dados. Não são muitos, portanto eu aceito novas contribuições.

• Vantagens de um DBA é de um blog novo com foco principalmente em MySQL;
• Comparação entre o PostgreSQL 8.2 e o Firebird 2.0 ;
• </depesz> este cara está no PlanetPostgreSQL mas tem se destacado por escrever artigos muito interessantes, sobre PostgreSQL numa velocidade impressionante!
• Entrevista com Bruce Momjian, desenvolvedor do PostgreSQL, na Information Week;
• Stream de audio de entrevista com Josh Berkus, desenvolvedor do PostgreSQL, feita pelos entrevistadores Randal Schwartz and Leo Laporte;
• Outro blog novo sobre PostgreSQL, desta vez de um mexicano;
• El nuevo paradigma de las bases de datos, artigo do site espanhol siliconnews.es discutindo a estratégia da Oracle, Microsft e IBM frente ao avanço dos SGDBs livres;
• DB Runas, site argentino especializado em artigos sobre Bancos de Dados. Já publiquei alguns artigos por lá no ano passado. Parece que de uns tempos para cá alguém anda linkando meus artigos deste blog. Não sei quem é exatamente, mas quero agradecer o interesse e aproveitar para dizer que muitos dos links daqui eu encontrei acompanhando este site. Parabéns pelo trabalho pessoal.

Agora só para lembrar… 15/09/2007 será o Software Freedom Day!

É comum aparecer alguém na lista do PostgreSQL perguntando sobre um bom plano de hospedagem para o PostgreSQL. Sei que existem alguns, mas nunca tive a oportunidade de testar um. Na verdade, seria uma boa idéia criar uma lista de provedores!

Então porque estou escrevendo sobre isso? Bom a questão é que hospedar um PostgreSQL não é tão simples assim. Se você está querendo hospedar uma aplicação que faz uso de banco de dados fora da empresa (ou fora da sua casa) é porque você quer se beneficiar com o ganho de escala de uma empresa de hospedagem, ou seja gastar menos com: banda de Internet, manutenção de servidores e segurança da rede. A opção de hospedar uma aplicação fora também tem várias opções com preços bem variados que aumentam geometricamente:

• Hospedagem em servidor compartilhado com acesso FTP;
• Hospedagem em servidor compartilhado com acesso SSH;
• Hospedagem em máquina virtual compartilhada com acesso SSH e root;
• Locação de servidor dedicado;
• Locação de espaço físico Rack, banda de internet e outros serviços em Data Center;

Hospedagem em servidor compartilhado

Se você quer hospedar um blog ou um ou mais sites simples, um serviço de hospedagem com servidor compartilhado deve ser mais do que suficiente. Você não tem que se preocupar com a configuração dos servidores, segurança ou manutenção do servidor. Basta colocar o seu código numa pasta do servidor, criar um banco de dados e pronto. Se você tiver um mínimo de conhecimento com shell, poderá utilizar um acesso via SSH que é muito versátil e seguro. Com 10 dólares por mês, você consegue hospedar um site com milhares de visitas por dia.

E onde entra o banco de dados nisso? Bons provedores de hospedagem em servidores compartilhados possuem bancos de dados em servidores dedicados bem como um servidor de e-mail dedicado, um servidor web dedicado e por aí vai. Porém estes servidores são compartilhados com vários clientes do provedor. Isto significa que você não poderá ter acesso a várias configurações do banco de dados. Mas o pior mesmo é que você não poderá distribuir a carga de I/O do banco de dados em diversos discos. Note que em sites onde a maior parte das operações em banco de dados são de leitura e a maior parte das operações de leitura são executadas sobre as as mesmas páginas - quem já viu estatísticas de acesso de um site, sabe que mais de 90% dos acessos ocorre sobre menos de 10% do conteúdo. Isto significa que o servidor web (que na maior parte dos casos será o nosso amigo Apache) irá cachear estas páginas e o banco de dados irá cachear o resultado das consultas mais frequentes. O resultado disso é que os servidores raramente consultam os seus discos e você tem um site onde o maior gargalo é a velocidade de processamento e a banda de internet disponível.

Se você está utilizando uma aplicação onde a maior parte das operações são de leitura… você provavelmente não precisa do PostgreSQL!!! Já escrevi sobre isso por aqui, e sei que o tema é polêmico, mas o PostgreSQL é um exagero nestes casos. O SQLite seria mais que suficiente. No entanto a maioria dos provedores costuma ter um servidor de MySQL compartilhado e como muitas soluções livres para aplicações web o utilizam… acaba sendo a primeira opção dos projetos web.

Hospedagem em máquinas virtuais

As maquinas virtuais são o pior e o melhor de dois mundos. Você tem a flexibilidade de um servidor dedicado e pode instalar tudo o que você quiser nele, configurando exatamente como você quer. Por outro lado você pode ter recursos de máquina tão limitados ou mais que um servidor compartilhado. Isto significa que um projeto pequeno, mas que não se enquadre num plano de acesso compartilhado padrão pode se encaixar bem neste tipo de plano. Em geral, você também não conseguirá fazer muitos ajustes em bancos de dados em máquinas virtuais, pois você não tem muito controle sobre os discos do servidor. Isto pode variar um pouco de plano para plano. No entanto você pode ajustar os parâmetros de memória do seu servidor da forma com que desejar. Vale lembrar que a memória de um servidor virtual compartilhado costuma ser bem pequena, o que novamente não é uma boa notícia para quem quer utilizar o PostgreSQL. Em ambientes com pouca memória o SQLite e o BDB são opções muito interessantes.

Servidor Dedicado

Bom, não é segredo para nenhum DBA ou SysAdmin (e não deveria ser para nenhum desenvolvedor também) que se você tem um mínimo de preocupação o com desempenho dos seus bancos de dados, você precisa de um servidor dedicado só para o banco de dados. Discos SCSI ou SAS não são opcionais (esqueça definitivamente que existe SATA) e o uso do plural não é casual. Com alguns GB de memória ECC(não vale a pena passar muito de 4GB se você utiliza um SO de 32 bits…) você terá um bom servidor de Banco de Dados. É claro que é possível ser um pouco mais modesto. Se você for muito mais modesto, pode ser que você consiga se virar com um servidor compartilhado. Por outro lado, se você precisar hospedar um Oracle RAC num data center, pode ser que o ganho de escala comece a fazer pouco sentido e valha a pena hospedar tudo dentro da sua empresa.

Se você vai optar por alugar os seus servidores ou vai comprar as suas próprias máquinas dentro de um data center a decisão é sua. Em todo caso, vale a pena realizar alguns testes para saber se você realmente precisa de um servidor dedicado. Testes de carga são difíceis de se fazer, mas quando você está prestes a lançar mão de um orçamento considerável para hospedar alguns servidores dedicados, vale a pena fazer algumas considerações para ver se um bom servidor compartilhado não lhe atende.

Particularmente, eu acredito que aplicações com muita escrita em banco de dados se sentem mais a vontade quando guardados dentro da sua empresa e perto dos olhos do seu DBA. Se você estiver falando de dados confidenciais, então fique longe de Data Centers. Lembre-se que ao fim e ao cabo, quem tem acesso físico ao servidor sempre tem acesso aos dados. O ganho de escala, neste momento, está limitado principalmente a banda de internet, já que num servidor de dicado você tem que arcar com o equipamento e com a manutenção do SO e SGDB. Já ouvi falar de algumas empresas que tem seus negócios completamente hospedados fora, mas também já ouvi falar de roubo de informações confidenciais. No entanto, uma aplicação de Supply Chain, por exemplo, podem se uma boa pedida para um data center respeitável.

Conclusão

Quando você decide por hospedar um banco de dados fora da sua companhia, é fundamental conhecer bem quais as opções de mercado e o que se pode esperar destas soluções em termos de escalabilidade, segurança e desempenho:

• Utilize um serviço que lhe permita crescer sem transtornos. As demandas sempre crescem e você não vai querer ficar trocando de provedor a cada vez que precisar de mais recursos de sistema. Fique sempre atento a opções de memória e discos se o desempenho do banco de dados for um fator importante para você;
• Faça uma boa pesquisa sobre a confiabilidade da empresa que você pretende contratar. Se vai armazenar dados que são relativamente sigilosos, triplique os esforços neste sentido. Conheça bem as opções de backup e SLA do provedor antes de fechar negócio;
• Conheça a sua aplicação e saiba como ela utiliza o banco de dados. Quanto mais leve for a demanda sobre o banco de dados, mais compensador será hospedar fora. Se o desempenho do banco de dados for um gargalo, então um estudo mais minucioso com testes de carga são recomendados. As aplicações web, tradicionalmente não utilizam muita escrita ou consultas complexas, o que pode lhe deixar menos preocupado com isso. Mas isso tem mudado muito nos últimos anos, com aplicações web cada vez mais complexas. Neste caso avalie se realmente vale a pena hospedar os seus SGBS fora.