Artigo Java Magazine 43 - Oracle para Desenvolvedores Java

Em muitos artigos sobre Sistemas Gerenciadores de Bancos de Dados já publicados na Java Magazine, sempre demos ênfase a projetos e produtos open source, tanto por uma opção pelo software FOSS (Free/Open Source Software) quanto pela facilidade dos leitores de poder baixar da internet um SGBD sem custo para acompanhar o artigo. Já foram abordados bancos como o MySQL, Derby e HSQLDB, os dois últimos implementados em Java. Mas o fato é que para muitas aplicações e empresas, em especial as de maior parte, predomina a opção pelos "grandes" produtos comerciais.

Segundo pesquisa do Gartner Group [1], o Oracle possui 48% do mercado mundial de SGBDs relacionais, seguido pelo IBM DB2 com 22%, Microsoft SQL Server com 15%, e Teradata e Sybase com 3% cada. Todos os demais dividem os 8% restantes deste mercado. Estes números representam volumes de vendas em dólares (num total de US$ 14 bilhões em 2006), por isso os bancos de baixo custo ou gratuitos aparecerão com fatias ínfimas nesta conta mesmo que tenham muitos usuários. Mas qualquer que seja a leitura destes números, é difícil não ver que a Oracle detém a fatia do leão, especialmente em grandes empresas. Isso torna valioso, para qualquer currículo, conhecer este produto, bem como os outros bancos comerciais mais usados. No Brasil, me parece que o Oracle [2] e SQL Server são os mais utilizados, pois o DB2 e Sybase têm menor penetração por aqui.

Os novos SGBDs "Express"

Até há pouco, o custo dos "bancões" os tornava inacessíveis para clientes e fornecedores de software de pequeno porte, ou para estudantes e desenvolvedores independentes. Uma opção intermediária eram os programas de parceria, nos quais uma assinatura relativamente baixa dá acesso a praticamente todos os produtos do fornecedor. Mas isso somente para desenvolvimento, não para produção, e o custo desses programas ainda é alto para indivíduos.

Graças à pressão dos SGBDs livres ou de baixo custo, que estão cada vez mais capazes, hoje há uma opção melhor. Existe uma nova geração de releases gratuitos dos grandes bancos: Oracle XE (Express Edition), Microsoft SQL Server Express, e IBM DB2 Express-C. Estes produtos "Express" têm funcionalidade similar à dos produtos pagos e podem ser usados inclusive para produção – mas têm alguns limites. Em especial, todos eles suportam um máximo de 4 gigabytes de dados por servidor. Tais limites não afetam estudantes, nem a maioria dos desenvolvedores (tarefas que exigem grandes bases de dados, como testes de carga, geralmente só são viáveis no ambiente do cliente, pois também exigirão servidores de alto desempenho). Já para produção, são boas opções para aplicações de pequeno a médio porte – o mesmo mercado que já vinha sendo erodido pelos SGBDs gratuitos. Em outras palavras, SGBDs relacionais viraram commodity, pelo menos no low-end.

Por outro lado, estes bancos “Express” não são open source. Seus fontes continuam guardados a sete chaves e é extremamente improvável que isso mude. Assim, para os adeptos do movimento FOSS, não há muita novidade: são produtos gratuitos, mas não livres.

Perspectivas de uso dos bancos Express

Quem adotar os bancos Express para produção poderá usá-los indefinidamente, se suas bases de dados não excederem os limites permitidos. É possível contornar estes limites com vários servidores [3], mas isso não é muito conveniente. Por mais que suas tabelas atuais sejam pequenas e você ache que nunca chegará aos gigabytes, é bom ter um "plano B".

Se os dados crescerem demais, você sempre poderá migrar para a versão completa do mesmo produto. Este upgrade terá risco zero e dificuldade mínima, pois o produto é igual e os dados nem precisarão ser migrados. Haverá o custo da licença comercial, mas se você precisa fazer este upgrade porque sua empresa cresceu, a lógica é que possa arcar com o preço. Esse é o plano dos fornecedores dos bancos Express.

Outra opção, se você crescer mas não quiser gastar, será migrar para um banco gratuito sem limites de capacidade, como MySQL ou PostgreSQL. A dificuldade desta opção depende da disciplina de não se tornar dependente de recursos específicos do banco. Afinal de contas, se você escolher um Oracle ou DB2 no lugar de um MySQL, deve ter bons motivos para isso. Precisa de funcionalidades do "bancão" (veremos alguns exemplos), tem profissionais que já o conhecem, quer usar uma aplicação que não suporta qualquer SGBD (ex.: pacotes de ERP) etc. Por isso, não faz sentido adotar hoje um banco de grande porte e prever um "downgrade" futuro se os dados crescerem. Ainda mais porque, quando os dados crescem muito – passando da barreira dos 4 Gb – aí sim, você pode precisar de um produto de alta capacidade.

Neste artigo, veremos uma versão gratuita do principal representante dos SGBDs relacionais comerciais, o Oracle 10g XE. Você verá como instalar e configurar este gerenciador de banco de dados e utilizá-lo para desenvolvimento Java.

Características dos grandes SGBDs

Chamo produtos como o Oracle, DB2 ou Microsoft SQL Server de "grandes" não só devido à suas participações de mercado, mas porque são realmente volumosos. Para o Oracle 10g XE, por exemplo, o instalador tem 206 Mb, a documentação tem 0,5 Gb, e o software instalado (sem contar documentação ou dados de aplicações) chega a 1,2 Gb. O consumo de memória não ficará por menos de 100 Mb – e conseguir que fique tão baixo exigirá algum trabalho, pois por default, o instalador irá configurar a base de dados para usar bem mais, podendo alocar centenas de megabytes se você tiver alguns Gb de RAM. (Mas usará no máximo 1 Gb de RAM – um limite da versão Express do Oracle.)

Os produtos também são incrivelmente complexos, exigindo anos de experiência e estudo para um bom domínio dos seus recursos... No caso específico do Oracle, não digo "domínio completo" porque isso é humanamente impossível [4].

No aspecto positivo, são produtos com enorme escalabilidade, sendo capazes de gerenciar terabytes de dados e fazer uso eficiente dos servidores de maior porte existentes, com centenas de discos e CPUs. Também oferecem um volume impressionante de funcionalidades.

O desempenho bruto (velocidade de execução de consultas e atualizações) também costuma ser superior, mas isso nem sempre acontece, especialmente para aplicações mais modestas (em complexidade ou em volume). Assim como uma picape de 1,8 tonelada, apesar do motor 4.0, pode ser menos ágil nas curvas que um carro popular 1.0 de 400 Kg, um SGBD leve poderá ser mais eficiente para operações que não necessitem das funcionalidades de um banco peso-pesado.

Um último fator importante é a confiabilidade. Os grandes SGBDs comerciais são produtos sobre cujas costas funcionam bancos, agências governamentais, hospitais, operadoras de telefonia. Assim, possuem características excepcionais em tolerância a falhas, clustering, recuperação de desastres, backup, ferramentas de monitoração e diagnóstico etc. É raro ver estes produtos falhando ou perdendo dados, sem que a causa seja falha de hardware ou humana.

Instalando o Oracle 10g XE

Para instalar o Oracle 10g XE, você pode baixar o instalador de oracle.com/technology/software/products/database/xe. Usuários brasileiros devem preferir o download Universal, que possui suporte mais completo à localidade brasileira e à língua portuguesa. Executando o instalador, a única opção que você pode fazer é o diretório de instalação. Escolha um disco com pelo menos 1,7 Gb livres. Em seguida, o instalador pedirá a senha inicial para os usuários SYS e SYSTEM (o Oracle possui vários logins de administração; o SYS é o mais privilegiado, mas também mais "perigoso" em mãos inábeis).

Após copiar os arquivos, o instalador irá criar uma base de dados inicial, num subdiretório oradata/xe dentro do diretório escolhido para instalação. Isso parecerá estranho para quem já instalou qualquer outra versão do Oracle, pois seus instaladores e ferramentas de configuração tradicionais permitem selecionar um enorme número de configurações, mas no XE não se pode selecionar nem mesmo o diretório dos dados. É uma limitação para os iniciantes, mas os usuários mais experientes poderão mover os dados para outro diretório ou recriar e configurar a base de dados à vontade, manipulando os arquivos de inicialização e configuração do Oracle e os "controlfiles" da base. Outro problema potencial é que o Oracle exigirá usar a porta 8080, não permitindo selecionar outra porta." [...] continue lendo...