Atenção: esse artigo tem uma palestra complementar. Clique e assista!
Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Artigo no estilo: CursoDa configuração para Performance Tuning de um banco de dados em Cluster simulado, baseado na arquitetura Oracle RAC. Este artigo é o quarto de uma série sobre RAC.
Para que serve?
Para disponibilizar o acesso a um único banco de dados a partir de várias instâncias acomodadas em computadores diferentes, com boa performance e alta disponibilidade.
Em que situação o tema é útil?
Em casos onde a disponibilidade e o poder de processamento são características fundamentais do ambiente.
Nas edições anteriores, instalamos um Cluster (Nota DevMan 1) simulado em Oracle RAC 10gR2 utilizando Linux CentOS e ASM, rodando sobre VMware Server, e aprendemos como administrá-lo.
Nesta quarta parte da série de artigos sobre Oracle RAC, iremos demonstrar como deve ser feito o Performance Tuning (“Ajuste de Desempenho”) do Oracle RAC, e como a configuração de um banco de dados em Cluster difere de uma instalação Single Instance.
Um Cluster, ou aglomerado de computadores, é formado por um conjunto de computadores que utiliza um tipo especial de sistema operacional classificado como sistema distribuído.
Muitas vezes é construído a partir de computadores convencionais, os quais são ligados em rede e comunicam-se através do sistema, trabalhando como se fossem uma única máquina de grande porte.
Oracle RAC x Oracle Single Instance
Ao contrário do que se pensa, e do que a Oracle costuma dizer, uma aplicação que funciona bem em Single Instance (“Instância Única”) não necessariamente funcionará bem em Oracle RAC. Alguns detalhes podem fazer com que a aplicação tenha um desempenho muito inferior, ou até que não funcione corretamente.
Na verdade, é muito mais fácil fazer com que uma aplicação que utilize o Oracle RAC não tenha uma boa escalabilidade, do que o contrário. Isto vem do fato de que um Cluster é como um "amplificador de som": ele pode amplificar tanto boa música quanto ruídos horríveis. Da mesma forma, uma aplicação que "roda" bem em Single Instance terá um ótimo desempenho em Oracle RAC, enquanto uma outra aplicação que já tem um desempenho ruim em Single instance, ficará inutilizável em Oracle RAC. O Oracle RAC não é mais rápido, ele é mais poderoso, e você tem que saber utilizar este poder.
A seguir irei explicar os principais itens que devem ser considerados em Oracle RAC que podem fazer toda a diferença no desempenho da aplicação:
- Full Table Scans: os Full Table Scans (“Escaneamento Completo da Tabela”) são muito mais danosos ao desempenho do banco de dados em Oracle RAC do que em Oracle Single Instance. Isto ocorre porque cada nó, ao acessar um bloco de dados, precisa ter certeza que é o “dono” deste bloco, e para isso, precisa “perguntar” aos outros nós sobre a propriedade deste bloco, pois é possível que ele esteja sendo alterado por outro nó do Cluster. Desta forma, quanto mais nós o Cluster tiver, mais lentamente a aplicação se comportará caso execute muitos Full Table Scans. Ou seja, adicionar nós ao Cluster, neste caso, só iria piorar o desempenho!
- Sequences: pelo mesmo motivo dos Full Table Scans, as Sequences (Sequências) devem ser criadas com especial cuidado em ambiente Oracle RAC. O ideal é que sejam apenas utilizadas Sequences naturais (as Sequences próprias do Oracle, e não uma implementação feita pela aplicação), e sempre com os parâmetros CACHE e NOORDER.
- Bind Variables: O uso de literais, ao invés de variáveis do tipo Bind, é muito prejudicial ao Oracle RAC no caso de SQLs que são executados muitas vezes repetidamente, pois a SQL Library (“Biblioteca de SQL”) também é compartilhada entre os nós, e cada vez que um SQL é executado com literais, ele deve ser recompilado, e a SQL Library deve ser atualizada em cada nó do Cluster. Por exemplo, o comando “SELECT val_salario FROM funcionarios WHERE nom_funcionario = :1” deve ser utilizado, ao invés de “SELECT val_salario FROM funcionarios WHERE nom_funcionario = 'PORTILHO'”. Desta forma, o comando é reutilizável pela SQL Library, não importando o funcionário sobre o qual a consulta é feita.
- Optimizer Statistics, Histograms, e System Statistics: pelo motivo de poder fazer com que o CBO – Cost Based Optimizer (“Otimizador Baseado em Custo”) induza a Full Table Scans sem necessidade, e assim, leve o banco de dados a apresentar um desempenho ruim, no Oracle 10g, por padrão, as estatísticas já são coletadas automaticamente, por um Scheduler.
- Locally Managed Tablespaces: para que não surja um gargalo no dicionário de dados (que é único, compartilhado por todos os nós) do banco de dados, o ideal é que todas as tablespaces sejam do tipo LMT – Locally Maganed Tablespaces (“Tablespaces Gerenciadas Localmente”), e não do tipo DMT – Dictionary Managed Tablespaces (“Tablespaces Gerenciadas por Dicionário”). As tablespaces LMT são a opção padrão do Oracle 10g, portanto, basta que as novas tablespaces criadas não sejam com o tipo DMT.
...
