Antes que você saia instalando o Oracle 10g e colocando a mão na massa para valer, você deve avaliar um detalhe importante: Como será o seu ambiente de “Laboratório”. Já escrevi sobre a importância de se ter um ambiente de produção, um de homologação e um de teste. Agora é a vez de se criar um quarto ambiente. Vejamos como utilizá-lo e como ele se integra com os outros 3 ambientes já existentes.
Entre os ambientes de banco de dados, o único que a Oracle não cobra pelo licenciamento é o laboratório. Além do ambiente de produção, a Oracle cobra licenças para o seu ambiente de testes, homologação, stand by, etc. Para isso, o seu ambiente de produção e desenvolvimento não podem depender em momento algum do laboratório. Esta é uma regra que deve estar clara. Então para que ele serve? Para testar unica e exclusivamente o SGDB e saber como ele se comporta. Você não vai utilizar o laboratório apenas para testar a migração do Oracle 9i para o 10g ou 11g. Você vai utilizar ele para validar cada novo patch de correção ou para testar funcionalidades que nunca foram exploradas antes.
De certa forma, o laboratório é o parque de diversões do DBA. Lá ele pode fazer uma carga com os dados reais das aplicações e levar o ambiente ao limite. Apesar disso, ele deve estar por perto não apenas durante um processo de migração. Você pode precisar dele quando menos espera. Imagine que você por um acaso do destino encontre um bug no Oracle e você tenha que aplicar um patch. Você não vai aplicar o patch direto no seu ambiente de produção/homologação/testes. Você vai testar primeiro ele no laboratório. Vai analisar se ele oferece impacto em outras aplicações. Se realmente vale a pena aplicar o patch ou se é melhor conviver com o bug do jeito que está, etc. Se um dia você resolver aplicar um
“patch set” que é o equivalente da Oracle a um “service pack” da Microsoft, os testes se tornam mais importantes ainda, pois você pode ter certeza que muitas características do SGDB vão sofrer alterações relevantes. O oracle 10g por exemplo está no “Release 2” ou seja, na versão “10.2”. Já saíram alguns patch sets para o 10.2. Em março saiu o 3º patch set, estando hoje na versão “10.2.0.3”. Mas não despreze os pequenos patchs que você consegue aplicar em poucos minutos com o OPatch. Uma pequena alteração no CBO (Cost Base Optimizer) pode virar de ponta cabeça o desempenho de todas as suas consultas. E mais, um patch em uma área que pode não parecer diretamente relacionada com outra pode ter efeitos colaterais inesperados.
Em resumo, mexer no seu SGDB, seja qual for, exige muita responsabilidade e muitos testes. A validação destes testes deve ser feita de maneira progressiva. Nunca pense em mudar alguma coisa direto do laboratório para a produção. Vá com calma, independente se você está migrando de versão, de release, de point release ou mesmo aplicando um pequeno e inofensivo patch. O ideal é fazer os testes no laboratório e depois aplicar as alterações no ambiente de testes, homologação e por último na produção.
Bom, você pode ter se convencido de que ter o laboratório é necessário, não apenas para um projeto de migração de versão. Mas vai imaginar que o orçamento da empresa não vai comportar um servidor dedicado só para isso. Já vai lembrar de um servidor que estava para se aposentar ou até mesmo um desktop. Mas agora respire fundo e pense. Você vai conseguir realmente testar as funcionalidades que deseja neste ambiente? Quais as chances de você ter resultados diferentes do laboratório no ambiente de produção? Se pensar com cuidado, verá que um desktop está fora de cogitação para realizar testes. HDs IDE ou SATA (por mais eles estejam a cada dia mais rápidos, etc, etc, etc) não são opções viáveis para um servidor de laboratório. Você sempre deve se aproximar o máximo possível do seu ambiente de produção, mas… bom, todo orçamento tem limite. Então o que fazer?
A primeira coisa a se pensar é que se o seu servidor de produção vai migrar, então seria bom migrar para um novo hardware também. O seu servidor de laboratório poderá ser o novo servidor. Migrar o servidor de produção para uma nova versão na mesma máquina é muito arriscado. Você não tem como voltar atrás se alguma coisa der errado. Se você utilizar o novo servidor, fará o favor de testar bem o novo hardware e ter uma idéia realista de como será o desempenho dele num futuro próximo. Como um servidor de produção não deve estar ativo por mais de 3 ou 4 anos, o upgrade de hardware acaba muitas vezes casando com o upgrade de software. Além do mais, por tradição as novas versões com suas novas funcionalidades costumam trazer ganhos de performance acompanhados com aumento no consumo de recursos de hardware. No Oracle 11g por exemplo a exigência mínima de memória saltou de 512MB para 1GB.
Mas, você vai querer manter um laboratório só para testar novas versões ou patch. Você pode querer começar a testar o 11g só para verificar qual tipo de ganho sua empresa terá e decidir se vale a pena migrar mais rápido (eu diria que daqui a um ano é rápido para uma versão nova como o 11g) ou esperar mais tempo. Você vai querer manter o laboratório ativo para testar patchs de segurança e outros que venham a aparecer. A partir do lançamento da versão 10.2.0.3 em março de 2007, já foram publicados mais de 400 patchs até setembro. Isto é sério ao ponto de ambientes críticos manterem equipes especializadas em aplicações de patchs, pois saber o que aplicar, quando e como não é tão simples quanto parece. Se quiser manter um laboratório para esta finalidade, você pode pensar em fazer algumas concessões como possuir até metade do espaço em disco original no ambiente de produção. Um corte deste tipo exigirá que você carregue as tabelas das aplicações com uma fração das linhas originais. Isto pode dar um certo trabalho, pois você terá que manter as restrições de integridade entre as tabelas intactas. Neste caso, você deve se lembrar que você não tem testes de desempenho válidos neste ambiente. Os planos de consulta irão mudar radicalmente no ambiente de produção. Se você for aplicar as alterações validadas num servidor de laboratório limitado mas aplicar as alterações primeiro no ambiente de testes e depois no servidor de homologação, você poderá resolver os problemas de desempenho no ambiente de homologação antes de chegar no ambiente de produção. Isto é claro, se o ambiente de homologação for realmente semelhante ao ambiente de produção.
Em uma empresa menor, pode ser inviável manter 4 ambientes. O custo para se manter 4 servidores para cada ambiente de produção é bem pesado. Ninguém disse que brincar de banco de dados seria barato, mas existe uma regra em TI que deve sempre ser lembrada: “O valor do cofre não pode ser maior que valor dos objetos que você quer guardar nele”. O custo/benefício deve ser avaliado. Principalmente os riscos devem ser avaliados:
- Migrar de versão de banco de dados nem sempre é uma opção se você deseja continuar a ter suporte do seu fornecedor. Você pode desejar migrar de versão atraído por novas funcionalidades ou aumento de desempenho. Mas é fato que todo software deixa de receber suporte e atualizações de segurança depois de um tempo. No caso da Oracle, é seguro estar na penúltima versão. Com o lançamento do 11g, está na hora de pensar seriamente em migrar para o 10g, uma vez que o 9i será descontinuado pela Oracle.
- Migrar de hardware a cada 3 ou 4 anos não é uma opção. Você pode até continuar utilizando o servidor depois deste período para operações menos críticas, mas este não costuma ser o caso dos bancos de dados em produção. Os DBAs podem e devem se considerar privilegiados na hora de fatiar o orçamento de investimento na área de TI.
- Você nunca vai conseguir testar 100% o desempenho da sua aplicação no laboratório, o que significa que você sempre vai estar sujeito gargalos imprevistos. Por outro lado, de 90 a 99% dos problemas (dependendo do tipo de testes que você executou) podem ser detectados com testes de desempenho. É muito mais fácil lidar com 1% a 10% de problemas no ambiente de produção, do que 100%.
- Considere seriamente a possibilidade de realizar operação paralela entre ambiente de produção e laboratório por um ciclo do software – como um mês numa folha de pagamento – incluindo a época de fechamento – como a geração de rotinas anuais. Negocie isto com os usuários da aplicação e exponha francamente para eles qual é o risco de não fazê-lo. Imagine uma base de dados de contabilidade que você migre e só depois de quase um ano, no fechamento do ano fiscal, você descobre sérios problemas. Distribua o risco!
- Quanto maior o seu gargalo de desempenho no ambiente de produção, maior será o desejo de migrar para novas versões. Ambientes onde o desempenho é sempre crítico e uma preocupação constante devem investir pesado no ambiente de laboratório e homologação.
Se você chegou aqui e acha tudo isso uma extravagancia e desperdício de recursos, lembre-se que em geral os testes por mais que tenham sido feitos com esmero (o que em geral não acontece na prática), eles nunca simulam o ambiente real de forma fidedigna. Uma expressão que traduz isso muito bem é “Shit happens“. E quem já viu, sabe que certas situações não podem ser expressadas com vocabulário formal. A questão no final será: você poderia ter prevenido isso? A resposta a esta pergunta lhe dirá se você continuará ou não empregado!
