Arquivo

Arquivo de maio, 2009

Inteligência em bancos de dados

25, maio, 2009 Sem comentários
Todo desenvolvedor que tenha um conhecimento razoável sobre banco de dados já passou pela dúvida sobre como lidar com a possibilidade de concentrar boa parte das regras de negócio dentro do banco de dados.

Atualmente, com a disponibilidade de várias linguagens de programação, isto se torna cada vez mais tentador: a Oracle possui além do consagrado PL/SQL, suporte a Java, o PostgreSQL chegou num estado de arte suportando uma infinidade de linguagens de programação dentro de seu SGDB e agora já faz um ano que o MySQL também possui sua própria implementação de linguagem procedural.

Mas o uso desgovernado deste tipo de expediente pode trazer algumas desvantagens. Longe de querer ditar melhores práticas, gostaria aqui de discutir um pouco este tema que tem me intrigado por algum tempo.

Nos primórdios da informática, onde reinavam solenes apenas os computadores de grande porte, não havia a opção de distribuir a carga de processamento em várias máquinas separadas. Os SGDBs relacionais também começaram a nascer somente no final da década de 70 com o DB2, Oracle e Ingres. Sendo assim, toda a aplicação se concentrava em geral na mesma máquina.
Com o surgimento dos microcomputadores veio a revolução da arquitetura cliente-servidor no final da década de 80. A idéia era criar aplicações rodando em microcomputadores (clientes) e armazenar as informações em SGDBs que ficassem em máquinas mais confiáveis (servidores). Com isso foi possível adquirir servidores com um preço bem mais acessível que os computadores de grande porte, uma vez que a carga de processamento da aplicação ficou distribuída nos microcomputadores dos usuários.

Nesta época, linguagens como o VB e o Delphi invadiram o mercado construindo aplicações cliente servidor com pães numa padaria. As aplicações cliente-servidor em boa parte foram muito bem sucedida, mas em ambientes corporativos elas começaram a apresentar uma performance muito insatisfatória. Conforme o tamanho do código cresce e as aplicações vão ficando mais pesadas várias coisas acontecem:

  • O código fica difícil de manter (bem, isto não é nenhuma novidade…)
  • Em transações longas, onde muito cálculo é utilizado, as máquinas utilizadas no cliente tem baixa capacidade de processamento, tornando a operação lenta.
  • Em transações longas com várias consultas ao banco de dados, o tráfego de rede é muito alto e gera um gargalo de desempenho.
  • Pequenas falhas na rede durante o processamento de transações longas podem no mínimo obrigar toda a operação a ser reiniciada.

É neste ponto em que entra em cena a linguagem procedural embutida no banco de dados. Com isso, é possível disparar gatilhos em circunstâncias determinadas e executar procedures e funções dentro do SGDB. O ganho de velocidade em aplicações cliente-servidor é realmente fantástico em transações longas.

Mas como tudo na vida , algumas pessoas se empolgaram! A idéia destas pessoas foi a de utilizar as aplicações no cliente apenas para exibir e receber informações, deixando todo o processamento das informações dentro do SGDB. Uma vantagem interessante desta técnica ocorre quando você possui mais de uma aplicação acessando o mesmo banco de dados. Um exemplo disto poderia ser uma aplicação cliente-servidor tradicional utilizada para alimentar e processar as informações, uma planilha extraindo informações complexas do banco de dados e uma aplicação web fazendo consultas de informações específicas. Neste ponto, centralizar toda a “inteligência” ou “regras de negócio” dentro do SGDB facilita a vida de quem tem que manter o código destas diferentes aplicações.

E qual a desvantagem disto? Bem, os ajustes de desempenho do SGDB tem que mudar drasticamente. Antes a coisa mais importante no desempenho de um banco de dados transacional era a velocidade dos seus discos. Com o acúmulo de tarefas de processamento da aplicação dentro do SGDB na mesma máquina o processador começa a assumir um papel cada vez mais importante. O resultado disto pode ser um SGDB muito lento.

Enquanto isto novas tendências de mercado começaram a ganhar força: Programação Orientada a Objeto e Aplicações Web. Na programação orientada a objeto, as linguagens procedurais perdem seu papel, pois estão muito mais próxima da lógica relacional dos SGDBs, embora o Sr. C. J. Date afirme que a maior parte dos fundamentos da P.O.O. estão na teoria relacional. Seja como for, outra tendência que ganhou força com a orientação a objetos é a programação em camadas. Com isso, o aplicativo começa a ser dividido em unidades funcionais, sendo que algumas delas certamente ficarão a cargo de servidores dedicados com maior capacidade de processamento, e conexão de rede dedicada com o SGDB. O mesmo acontece naturalmente em aplicações Web onde o processamento não é realizado em um computador cliente e sim no servidor web (ou em mais servidores se a aplicação for realizada em várias camadas).

Hoje se fala muito em camadas de abstração de bancos de dados e em frameworks MVC. Eles permitem que você desenvolva a aplicação sem se preocupar com qual banco de dados está utilizando. Desta forma, as linguagens procedurais nos SGDBs perderiam completamente sua função! A idéia é realmente tentadora.

No entanto, quando estudamos as boas opções no mercado, verifica-se a existência de brechas para enviar comandos específicos para cada SGDB. Isto ocorre porque se a abstração de SGDB fosse perfeita, certamente não precisaríamos de diferentes SGDBs no mercado. Há momentos em que é preciso acessar funcionalidades específicas de cada SGDB que as camadas de abstração não são capazes de lidar diretamente. Quando se precisa de funcionalidades avançadas e/ou alto desempenho em longas transações, as linguagem procedurais ainda são utilizadas mesmo em aplicações com várias camadas como no modelo MVC.

É claro que as camadas de abstração de dados tendem a evoluir, assim como o padrão SQL tem evoluído. No entanto estamos longe de uma padronização das linguagens procedurais dentro de bancos de dados, além de haverem novas funcionalidades sendo implementadas todos os dias nos SGDBs relacionais. Dito isto, é provável que aplicações continuem se beneficiando de camadas de abstração de dados, no entanto elas não cobrirão plenamente as necessidades de grandes aplicações corporativas, devendo haver sempre brechas para acessar diretamente as funcionalidades especificas de cada SGDB.

Enfim não existe uma regra clara para utilização de linguagens procedurais dem SGDBs. Existem funcionalidades como prover auditabilidade, gerar logs e realizar a carga de dados complexos onde estes são consagrados, além do processamento de longas transações com velocidade e confiabilidade ainda imbatíveis.

Em sistemas pequenos, a centralização da inteligência da aplicação dentro de SGDBs é aceitável, porém com o aumento de aplicações Web e frameworks como o Ruby On Rails, esta não parece ser uma tendência de longo prazo.

Por fim, este assunto é bastante polêmico e não existem regras formais para o uso de linguagens procedurais em SGDBs. A criatividade e o bom censo dos desenvolvedores e DBAs podem sempre apontar para novos rumos ou demonstrar equívocos.

Categories: Geral Tags:

Uma visão geral sobre Backup & Recover

6, maio, 2009 Sem comentários

Um assunto muito pouco abordado entre os profissionais Oracle, e que sempre causa estresse e problemas quando necessário, é a eficiência da estratégia de backup & recover de um determinado banco de dados da empresa, pois todos só prestam atenção nesse assunto quando é necessário e já estão com a corda no pescoço.

Para ter uma eficiente estratégia de backup & recover, primeiramente deve-se conhecer a infra-estrutura que a empresa oferece para adequar as soluções de backup e planejar quais estratégias e técnicas que serão aplicadas. E quando estamos falando de infra-estrutura, diversos pontos devem ser destacados, como:

  • Rede LAN dedicada para backup & recover;
  • Dispositivos de Fita (DLT, LTO e DDS) disponíveis para armazenamento;
  • Se existe uma necessidade de storage para backup em disco, é viável uma aquisição?;
  • Se existem servidores dedicados para testes e validação de restore e recover;
  • A empresa possui outro site para planejar estratégias de backup;
  • Se a empresa centraliza backups de outras unidades, qual o tamanho da banda de rede.

O segundo ponto que deve ser analisado é a política de backup de cada banco de dados, tratado de forma única, pois em banco de dados, por mais que sejam padronizadas as instalações, arquitetura e funcionalidades de cada base, necessita de políticas de backup customizadas, onde a aplicação da empresa que irá ditar as principais regras, e existem pontos que merecem atenção, como:

  • Tempo para janela de recuperação;
  • Tempo de retenção dos dados;
  • Agendamento das rotinas de backup, exemplo: diária, semanal, mensal ou anual;
  • Volumetria que será armazenada;
  • Nível de proteção dos dados;
  • Tipos de backups que serão executados;
  • Definição dos procedimentos de backup, restore e recover.

Os dois pontos citados são o início para enxergar as deficiências da empresa ao elaborar as estratégias de backup, são os principais pontos que devem ser levantados para posteriormente planejar as melhores técnicas e políticas adequadas para as bases.

Não adianta o DBA ter diversas ideias e soluções de armazenamento e recuperações ótimas se a empresa não permite ou não suporta tais tarefas. Seria uma frustração para o profissional tentar implementar uma solução sem sucesso ou com diversos problemas e que não conseguisse atingir o principal objetivo que é a segurança dos dados e disponibilidade do banco de dados.

Em relação ao assunto, soluções de backup, existem diversas no mercado, a própria Oracle oferece diversas soluções de backup interessantes, como Oracle Secure Backup, Data Guard, Stand-by Database, Recovery Manager (RMAN) e Legato Single Server. Outros produtos de terceiros podem oferecer soluções adequadas a sua empresa, como: CA BrightStor ArcServer e Backup Exec, Symantec NetBackup, IBM Tivoli ou EMC NetWorker. Tudo é uma questão de analise, planejamento e execução na implantação da solução e, é claro, verificar se o valor da solução está dentro do orçamento do departamento de TI.

Agora, aos DBAs, existem técnicas e práticas que podemos aplicar para complementar as estratégias de backup existentes e outras práticas que devem possuir requisitos citados no início, principalmente na parte de infra-estrutura. Quando vamos pensar em backup & recover, O que lhe vem na cabeça? Vamos montar uma lista com as opções:

  • Backup cold;
  • Backup hot;
  • Backup por tablespace;
  • Backup do control file;
  • Export do banco de dados;
  • Arquivos de carga (originadas do ETL ou de algum outro processo);
  • Cópia fria de um servidor para o outro;
  • Cópia dos objetos de banco;
  • E, na pior das hipóteses, garantia de alguma coisa no ambiente de desenvolvimento e homologação.

OK! Percebeu que estamos falando de um assunto delicado e de forma abrangente, sem determinar o que será feito, se existe procedimento para tal, quais as garantias que vou ter e sempre pensando naquela frase linda e determinante:
Backup bom é aquele que volta.

Agora, vamos discutir um pouco sobre os tipos de backups citados acima.

Backup Frio (Cold Backup), backup realizado com o banco de dados offline, ou seja consistente. O backup cold pode ser feito de modo automatizado através do RMAN (Recovery Manager) ou através de scripts shell (Linux/Unix) ou batch (Windows), onde para o formato manual do backup, pode envolver a cópia até mesmo dos arquivos de redo log, no RMAN não é necessário. Interessante ter um backup frio na sua estratégia de backup.

Backup Quente (Hot backup), backup realizado com o banco de dados online, ou seja inconsistente. O backup HOT é um dos principais tipos de backup realizados nos ambientes de produção, pois não é necessário a parada do banco de dados, quando está em modo ARCHIVELOG, porém, uma estratégia de backup HOT pode envolver a utilização de níveis de backups incrementais, como:

  • Backup incremental nível 0, ou backup base;
  • Backup incremental nível 1, 2, 3 e 4.

Ao colocar esses níveis de backup na sua estratégia, irá ganhar performance, redução de volumetria de backup gerado e aumentar o nível de disponibilidade dos dados, dando mais eficiência à recuperação. Acho que é a opção mínima de backup para o ambiente de produção.

Backup por tablespace, backup realizado para uma determinada tablespace, tendo como opção até mesmo a seleção dos datafiles que poderão ser copiados, pode ser feito manualmente e automaticamente, mas em alguns banco de dados existem tablespaces que armazenam as principais tabelas da aplicação, em que pode forçar uma parada crítica da aplicação. Então, vem a pergunta valendo 1 milhão: Se eu peder uma tablespace com tabelas de alta criticidade à aplicação, tenho que voltar o meu banco de dados por completo?
A resposta é simples: se traçou um bom planejamento e tem recursos de hardware disponível, poderá aplicar uma técnica apenas de recuperação da tablespace e seus respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode ser realizado manualmente ou automatizado com RMAN, onde não é necessário voltar seu backup por completo, porém, é necessário uma máquina auxiliar nessa atividade ou espaço em disco suficiente na própria máquina que ocorreu o problema, com isso, podemos recuperar partes do banco de dados de forma completa e deixar a aplicação operante.

Backup por control file, é o bakcup de um dos principais arquivos do banco de dados, onde armazena todas as informações do banco de dados com checkpoint, valor de scn, origem dos datafiles, tablespaces, nome do banco de dados, backupsets e etc. Esse backup pode ser feito manualmente ou automático pelo RMAN ou até mesmo por um trace diretamente do SQL*PLUS, usando o comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE.

Export do banco de dados, é uma espécie de backup lógico, ou seja, poderá realizar um backup completo ou por usuário do banco de dados, porém, muitos se enganam quando deixam apenas um EXPORT, ou apenas DMP (Dump) como é conhecido no mercado, pois o EXPORT não garante a segurança total dos dados e com isso poderá ter perda de dados, o que geralmente para uma empresa não é muito bom. Basta analisar um simples exemplo prático.
Imagine que tenho um banco de dados que é atualizado todos os dias, com INSERT/DELETE/UPDATES diários, um bom e velho OLTP (Online Transaction Processs), e na minha estratégia de backup tenha apenas um Export (ou DMP, como preferir) realizado sempre às 07:00Hs da manhã.
Em uma bela sexta-feira às 17:45Hs da tarde, o servidor que hospeda esse banco de dados teve problemas nos discos internos, perdeu-se archived logs do dia e um maravilhoso “crash” na base. Sua recuperação ficou impossível, o que você tem na mão para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manhã, e o que aconteceu com todas as movimentações das 07:00Hs até as 17:45Hs? Vão sumir? Você não tem archived logs e a base está totalmente inconsistente para recuperação. Resultado final: muito café e cigarros para falar esse cenário com o seu gerente.
Isso é apenas um cenário que ocorre em muitas empresas, onde as Leis de Murphy podem ocorrer, e quando ocorre sua reputação pode estar em jogo. E pior, existem muitos ambientes que estão com esse cenário atualmente.

Arquivos de carga, é considerado backup, principalmente para ambiente de Data WareHouse onde existe uma alta volumetria de dados e os bancos de dados não trabalham em ARCHIVELOG, pois, como você poderia recuperar os dados que foram apagados acidentalmente nos dias 20 e 21 de uma tabela de FATO ou de alguma dimensão importante do seu DW? Com Mágica? Export poderia resolver o problema também, mas trazer um export FULL de um DW não seria muito legal (esperar cansa!), e nesse caso, como estamos falando de apenas 2 dias, por que não os arquivos de carga desses dias! Usando o mesmo processo de ETL poderia refazer a carga e completar a tabela novamente com seus respectivos dados, em bem menos tempo.

Cópia fria de um banco de dados, é uma opção muito interessante para implementar na estratégia de backup da empresa onde tem bancos de dados praticamente abertos ao público, ou seja, até o porteiro sabe a senha do owner da aplicação e o estagiário treina seus primeiros comandos DML diretamente na base de produção, porque somente a produção tem uma volumetria para ele testar o tempo e a eficiência do seu DELETE.
E quando estamos falando de cópia fria, não precisa ser as práticas do “Old School”, baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra máquina. É uma solução também dependendo do ambiente, mas por que não optar por um DUPLICATE DATABASE, usar um Data Guard (Lógico ou Físico), Stand-by database, ou um backup online na produção e restore em outra máquina, com o RMAN, isso é possível até entre diferentes plataformas, de um Linux para Windows. Olha que maravilha! Desde jeito você consegue uma imagem da sua produção e consultar essa imagem para reparar os “ensinamentos” do estagiário na produção! Recomendação: Depois ensina o controle ROLLBACK! rs.

Cópia dos objetos do banco de dados, esse é um ponto interessante também, principalmente quando sua empresa não tem definição de ambientes, como desenvolvimento, homologação e produção. Poucos DBAs se atentam nisso, mas quando é necessário voltar uma procedure que foi alterada em produção e essa alteração não ajudou em nada ou pior, só complicou as coisas! Qual a sua estratégia para voltar isso? Montar um owner em alguma base de teste ou na sua própria máquina e realizar um IMPORT do owner da aplicação sem registros e posteriormente pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologação? Ou mandar o desenvolvedor se virar? Quais as alternativas!
Para resolver esse simples probleminha, basta começar a realizar um backup lógico dos objetos do banco de dados, pode usar as próprias views do dicionário de dados do Oracle, como dba_source, dba_triggers, dba_views, dba_mviews e etc, usar o pacote DBMS_METADATA, gerar um DDL script com o Export ou até mesmo para os adeptos de programas gráficos como PL/SQL Developer, SQL Developer e TOAD gerar um “scriptão” a partir deles!

Nessa simples solução, que pode economizar tempo, menos estresse e agilizar o objeto correto ao banco de dados, vai gastar apenas tempo para preparar os scripts e, posteriormente, realizar os agendamentos necessários e mandar para FITA, eles podem gerados em arquivos com os nomes e tipos dos objetos, um script completo do owner da aplicação com a data do backup e etc. Fica a gosto do cliente!

Percebeu que existem diversos tipos, formas, tamanhos, técnicas, soluções e práticas de backup, uma boa estratégia de backup varia muito conforme o ambiente e os recursos que a empresa oferece, e também as estratégias que o DBA irá implementar na empresa. O banco de dados Oracle oferece para você um leque de opções, basta saber aplicar essas opções. É igual ao antigo slogan do um ótimo produto da NESTLE.

Existem 1001 maneiras de preparar sua Estratégia de backup, invente a sua!

Fonte: www.imasters.com.br

Categories: Geral Tags: