Arquitetura De Banco De Dados Para Ambientes De Teste

Este artigo descreve algumas features do banco de dados Oracle e suas funcionalidades para implementação em ambientes compartilhados voltados a testes de softwares.

Arquitetura de Banco de Dados para ambientes de teste

Ambiente de teste é toda a infraestrutura onde os testes de funcionalidades de sistemas serão executados. Sua finalidade é propiciar a realização de testes em condições conhecidas e controladas. Para que esses testes possam ser realizados e entregues nos prazos estipulados, é necessário que cada área envolvida desenvolva uma arquitetura que vise obter o melhor rendimento dos componentes de hardware e software para tais finalidades. Este artigo descreve algumas features do banco de dados Oracle e suas funcionalidades para implementação em ambientes compartilhados voltados a testes de softwares.

Em que situação o tema útil

Desenhar e implementar uma arquitetura de banco de dados para ambientes de testes compartilhados auxilia no processo de administração e capacidade de processamento em rotinas de testes, homologações e certificações de sistemas.

Como todos os profissionais de TI já estão cansados de saber, sempre é necessário achar um jeito de fazer mais com menos. Quem nunca ouviu aquela máxima “É necessário pensar fora da caixa”? Essa busca por obter mais e melhores resultados com menos recursos tem sido uma constante no cotiano destes profissionais. Infelizmente, alguns diretores e gerentes definem os valores gastos com hardware e software como custos, e não como investimentos, ainda mais quando estamos falando de ambientes voltados a testes de sistemas. É essa busca do “fazer mais com menos” que torna o mundo dos profissionais de insfraestrutura de TI mais empolgante e desafiador.

Para um administrador de banco de dados essa realidade não é diferente. Muitas vezes somos questionados sobre problemas de performance de ambientes, cujos diagnósticos frequentemente já temos conhecimento e devemos trabalhar na solução para que tenhamos tempos de respostas aceitáveis das bases adminsitradas em cenários de testes. Isso não é novidade para quem já está há alguns anos lidando com TI no mercado de trabalho, porém, aos novos profissionais, saibam que, apesar de todo avanço da tecnologia, ainda enfrentamos problemas do tipo. Por falarmos em avanço tecnológico, este artigo descreve algumas features disponíveis aos DBAs Oracle que necessitam otimizar desempenho e um melhor gerenciamento de seus ambientes de testes compartilhados.

Quando estamos falando em ambientes de testes, o chamado “mundo perfeito” seria se possuíssemos ambientes segregados, com recursos dedicados à cada finalidade, ou seja, com recursos de hardware disponíveis a ambientes de desenvolvimento, outros a ambientes de testes de softwares, homologação e pré-produção. Na realidade, muitas vezes, isso não tem se aplicado.

Sendo assim, o intuito deste artigo é explicar como desenvolver uma arquitetura para ambientes compartilhados de testes. Falando resumidamente, um servidor de banco de dados englobando todas as funcionalidades e o ciclo de testes de sistemas de uma companhia.

Algumas features aqui abordadas estão disponíveis desde versões mais antigas do banco de dados Oracle, outras são mais novas, porém, todas acrescentam muito ao processo de melhoria de desempenho de ambientes de bases de testes. Apesar disso, algumas organizações ainda relutam em utilizar. Algumas vezes essas oposições à utilização de alguns recursos disponíveis nem se dão pelo fato de serem necessários investimentos, e sim pelo desconhecimento. Neste artigo, o objetivo consiste em desenhar uma arquitetura para otimizarmos ambientes compartilhados de banco de dados Oracle voltados ao ciclo de testes de sistemas.

ASM

Um dos principais gargalos que temos em ambientes de testes são os discos. Além das atividades de Entrada/Saída (I/O) necessitarem ser muito bem administradas para que tenhamos uma boa performance das bases de dados, na maioria dos casos, as empresas não dispõem de discos nobres para ambientes de testes. Com isso, já imaginou, em um ambiente com cerca de cinquenta instâncias Oracle, como seria a administração de I/O se optássemos por utilizar esse ambiente de teste em file system?

Teríamos que montar um mapa da divisão dos discos e dos fs utilizados para que soubéssemos cada atividade em disco sendo executada por cada base de dados para que não houvesse contenção em disco devido a alguns bancos de maior fluxo de transações estarem compartilhando os mesmos discos com outras bases de menor importância.

O ASM (Automatic Storage Management) é a feature da Oracle que simplifica a vida do DBA. Ela auxilia na administração de arquivos de bancos de dados Oracle permitindo ao DBA referenciar grupos de discos para armazenamento dos arquivos de banco, em vez de necessitarem apontar discos individualmente. A funcionalidade do ASM, que é uma extensão do OMF (Oracle Managed Files), realiza o “striping” de datafiles, controlfiles e redo log files, ou seja, o ASM distribui, dentre os discos disponibilizados nos grupos de discos, estes arquivos de banco de dados automaticamente, sem ser necessário o apontamento de forma individual para cada criação de tablespaces, novos datafiles, redos, etc. Basta apontar em qual grupo de disco que você deseja criar o novo arquivo de banco de dados e o ASM, automaticamente, distribui nos discos disponíveis.

Dentre os benefícios do ASM, temos: gerenciamento automático de datafiles, redo log files, controlfiles, etc.; balanceamento de I/O entre os discos dos grupos de discos, maximizando a performance para que não haja contenção de I/O devido a transações estarem acontecendo apenas em alguns discos específicos; gerenciamento de discos através de uma instância Oracle; dentre outros já conhecidos por nós DBAs. Na Figura 1, está um desenho de uma distribuição de discos, grupos de discos e arquivos de bancos de dados que foram definidos nessa arquitetura elaborada para o ambiente de testes.

Figura 1. Distribuição de discos e grupos de discos no Oracle ASM.

Neste desenho, foram separados discos específicos para datafiles (dados e índices), redo log files e para a Flash Recovery Area, denominada RECO. Nesta arquitetura está representada como seria a segregação de recursos para ambientes de testes, contemplando apenas seis bancos de dados, divididos em desenvolvimento, testes e homologação. Cabe lembrar, para quem está entrando no universo de bancos de dados Oracle, que datafiles e redo log files são I/O concorrentes, sendo assim, devemos separá-los em discos diferentes para