Blog do Marcio Almeida

Quem não foi, perdeu, quem foi, certamente irá no próximo…
Este último evento foi mais bem organizado e a qualidade das palestras e palestrantes manteve-se no ótimo nível do evento anterior.
Para mim, várias novidades, vários novos conceitos, várias oportunidades de fazer contato com profissionais Oracle.
Além dos encontros, que não exisitiam para profissionais de nossa área, ainda tem os workshops que são de grande necessidade para profissionais que já não estão mais no nível básico.
Deixo aqui as minhas congratulações à equipe que vem se empenhando para se superar a cada evento, e tem tido muito sucesso nessa jornada.

Tem vezes que necessitamos fazer consultas ou atualizações em massa e não tem opção, vamos inevitavelmente fazer full em uma tabela muito grande.
Se já procuramos diversas opções e não encontramos nenhum outro recurso inteligente, podemos minimizar o impacto deste processamento dividindo seu trabalho entre as diversas CPUs do servidor.
Obviamente este processo não server para servidores monoprocessados, se tem um único servidor, não tem com quem compartilhar o trabalho…
No meu caso tenho servidores quad-core, já trabalhei com servidores AIX, HP, Solaris com múltiplos processadores, nestes casos a opção é bastante interessante…
Quando lançamos um processo ao sistema operacional, ele pega um processador e, caso o mesmo encontra-se disponível, temos até cem por cento de uso desse processador, em servidores multiprocessados, temos um processador em cem por cento e os demais inativos.
Usando o processamento paralelo, nós podemos utilizar todas as CPUs em um único processo, o que vai dar um ganho significativo no processo…
alter table t1 parallel (degree 12);
Aqui você define que a tabela t1 irá executar processos em modo paralelo abrindo doze processos, como tenho um RAC com 3 nós com processadores quad-core, estaria usando toda a capacidade dos servidores, é claro que isso não é muito recomendado, é bom sempre deixar alguns processadores para os outros processos…
select cod_cliente, count(*) from t1
where cod_cliente in (3098, 3653, 3185)
group by cod_cliente;
Esta consulta, que normalmente demoraria alguns minutos, por se tratar de uma tabela com milhões de registros, é executada em poucos segundos, pois estou usando o máximo de recursos dos meus servidores.
alter table giss.tb_boletos noparallel;
Não esquecer de “desmarcar” a tabela do modo paralelo…
Como a Oracle também gosta de facilitar a vida de seus usuários… Sim ela não gosta só de complicar, ela ajuda também… risos…
Select /*+ Parallel (t1, 12) */ cod_cliente, count(*) from t1
where cod_cliente in (3098, 3653, 3185)
group by cod_cliente;
Esta opção faz a mesma coisa…

Você também pode usar em opções de processos DML :
alter session enable parallel dml;
insert /*+ parallel (t1,4,1) */ into t1
select * from t2;
commit;
alter session disable parallel dml;

Como tudo nesta vida, esta opção tem que ser usada com equilíbrio, pois pode haver situações em que tentamos acertar uma ponta e destruimos outra…

Procurando no famoso site : http://www.ora-code.com encontramos :
ORA-12545:Connect failed because target host or object does not exist
Cause: The address specified is not valid, or the program being connected to does not exist.
Action: Ensure the ADDRESS parameters have been entered correctly; the most likely incorrect parameter is the node name. Ensure that the executable for the server exists (perhaps "oracle" is missing.) If the protocol is TCP/IP, edit the TNSNAMES.ORA file to change the host name to a numeric IP address and try again.

Aqui começam os problemas, o erro é intermitente, aliás, é o que mais incomoda qualquer profissional, é o erro intermitente, se não funciona é mais simples, quando hora funciona, hora não, é difícil identificar.
Uma vez que, eventualmente a conecção se estabelece, não é erro no TNSNAMES nem no LISTENTER, pois seria a primeira opção.
Em um dos milhares de sites que falam sobre o assunto vei o grande dica, esse erro acontece SEMPRE em instalações NOVAS, o que é o meu caso.
Em outras informações que fui pesquisando, e a conclusão é que, em algum lugar a definição do nome da máquina e/ou IP estava errado, quando se fazia determinado caminho, a conecção se perdia.
Para variar, brigas homéricas com o pessoal de infraestrutura e finalmente descobrimos que era um DNS reverso que não havia sido configurado corretamente.
Quando acertou esse pequeno detalhe, TUDO voltou a funcionar maravilhosamente.

Por mais superficial que seja a descrição dos erros da Oracle, tenha sempre em mente que aponta para o caminho do gol, portanto veja as possíveis variações, mas sempre dentro do tema sugerido pela Oracle, pois o caminho fatalmente é por ai…

Um dos grandes desafios do DBA é identificar qual o processo que está “comendo” a CPU e Memória e Disco.
Depois de identificar, o novo desafio é trabalhar o processo de forma a deixar de ser um glutão de recursos e tornar-se um aliado da performance.
Dividirei em três partes esses grandes glutões.
Primeiro, aquele que destroi a CPU…
Alguns processos podem consumir 100% de CPU sem grande dificuldade, inclusive de identificar esse tipo de glutão. São aquelas consultas mal desenvolvidas ou extremamente complexas, as principais vilãs são as que possuem consultas recursivas e sub-consultas.
Segundo, aquele que consome a Memória…
São aquelas consultas com o famoso “select * from tabela”. Essas consultas tem dois crimes graves associados a ela, traz todas as colunas da tabela e não tem restrições nem parâmetros, portanto não usa índice. Outras vilãs, são as consultas que fazem produto carteziano, isto é, em alguma das tabelas referenciadas não é usado o índice, acaba acontecendo que, para cada linha consultada o SGBD é obrigado a verificar toda a tabela, gerando um consumo de Memória absurdo e CPU também.
Terceiro e não menos importante, o devorador de Disco…
Existem dois casos bastante claros de devoradores de discos, pouca memória ou uso excessivo de memória pode gerar swap, isto é, o SGBD acaba usando o disco para auxiliar a memóra. Outro grande glutão é a péssima modelagem de dados, em algum tempo / espaço algum lunático disse que é interessante ter os dados duplicados pois facilita consultas, portanto você acaba tendo a informação duplicada em diversas tabelas ao invés de ter somente as chaves de referência, isso acaba gerando um consumo desnecessário por disco, que depois de algum tempo mostra-se um grande vilão,

O que fazer para deter esses grandes vilões ?

1. Ter sempre um AD ou pelo menos um DBA para auxiliar na confecção de projetos de Bancos de Dados, pois modelar o banco de acordo com as telas, como muito desenvolvedor faz, é um grande erro.
2. As consultas mais complexas devem ser sempre desenvolvidas em conjunto com um DBA qualificado, pois existem mais recursos dentro de um SGBD do que sugere a nossa vã filosofia.
3. Consultas não são otimizadas apenas pelo “custo”, mas tem que ver a cardinalidade e I/O também, aliás, todo o trace deve ser cuidadosamente analisado.
4. Configurar o banco de acordo com a necessidade do cliente, pois cada cliente tem uma necessidade e cada necessidade requer um tipo de atenção diferenciada, instalar bancos “padrão” só serve para pequenas empresas, mesmo assim com restrições.
5. Atenção especial ao dia a dia, todos os detalhes tem que ser verificados e comparados com os dias anteriores para se evitar distorções e surpresas desagradáveis.

O Oracle RAC é uma ferramenta bastante interessante que é amplamente utilizada por grandes empresas.
Por que grandes empresas ? Por dois motivos bastante simples…
1. Sua implementação é bastante cara (servidores, storage e licenças)
2. Só é aplicável quando se tem um número bastante grande de processos simultâneos.

Quando nos deparamos com a necessidade de implementar essa funcionalidade, percebemos, primeiramente, que há um gargalo bastante evidente nos processos, o servidor está trabalhando com carga total e não está dando conta de todas as requisições. às vezes tenta-se aumentar o número de webs, rever toda a aplicação e chega-se à conclusão de que, nem mesmo um servidor mais potente resolveria a situação.

Primeiro passo é justamente aumentar o poder de processamento e memória, dá um alívio temporário mas não dura muito a alegria.
Passamos então para resolução de gargalos, compra-se uma storage, pois o I/O é um dos principais gargalos dentro de um banco de dados, ganha-se um novo e temporário fôlego.
Percebe-se que há a necessidade de duplicar a capacidade de processamento, não com equipamento mais potente e sim com outro servidor dividindo o trabalho. Algumas empresas criam outros bancos de dados para dividir a carga, é uma solução, porém com o crescimento da emrpesa, você irá se deparar com inúmeros servidores independentes, quando pensa em formar um Data Warehouse (DW) você está com um grande problema, captar informações de todos os servidores distribuídos.
Como uma das funções de um DBA é “prever” o futuro, é mais sensato implementar o Oracle RAC, pois as informações estão agrupadas, facilitando um posterior trabalho de DW.

Para se implementar um serviço de RAC, é necessário, antes de mais nada, uma storage, pois os dados tem que ser compartilhados, e o melhor lugar para isso é dentro de uma storage.
Necessita de pelo menos dois servidores, um servidor não seria RAC (óbvio), e é aqui que começam os problemas…
A aplicação suporta vários servidores ? A grande maioria das aplicações fazem muito LOCK de linha e às vezes até mesmo de tabela, o que, em uma arquitetura compartilhada, é puro assassinato…
Após a configuração do aplicativo, adequando-o à nova situação, temos a configuração dos acessos, normalmente por AIS ou algum aplication server que gerencie os aplicativos. o balanceamento é de extrema importância, pois uma má configuração pode gerar um efeito gangorra, isto é, as conecções vão todas para um nó e depois, quando este nó começa a se tornar pesado as conecções “migram” para o outro nó. Quando está bem configurado, cada nó receberá o mesmo número de conecções.
Também temos o problema de muitos nós compondo um RAC, quanto mais nós mais complexo se torna a configuração e implementação dos recursos, não é simplesmente “engatar” novos nós, é uma cirurgia minunciosa e que deve ser feita com muito cuidado.
Depois de tudo configurado e funcionando, temos dois pontos importantes para destacar, a estratégia de backup / recover e contingência. Itens a ser tratados posteriormente.

Por diversas vezes acreditamos que o TOP de tecnologia é a solução de todos os nossos problemas, e com isso incorremos em problemas graves de indisponibilidade, falhas, latência, etc…
O que realmente a empresa necesita ? Sem “viajar na maionese” devemos desenvolver um projeto de acordo com as necessidades da empresa, não dos fornecedores.
Trabalhei em um projeto, a alguns anos, a empresa tinha uma base de dados com três gigas de dados, com crescimento pequeno, mesmo que fosse cem por cento ao ano… Foram comprados dois servidores Dell, com trezentos gigas de discos cada, ambos redundantes, sendo um servidor contingência do outro.
Com o levantamento que fiz, foram adquiridos servidores pelo menos vinte vezes superior ao que a empresa necessitava, com essa diferença financeira seria possível adquirir servidores de impressão (que era necessário na época), servidores de e-mail, de arquivos, etc…
Já tive problemas em um cliente pois o forneceor de software reclamava da demora do banco de dados, quando fui fazer a avaliação, percebi que, junto com a migração que fizemos do Oracle 9i para o 10g, o aplicativo também havia sofrido alterações, e começou a apresentar problemas de performance. O fornecedor do aplicativo afirmou que nada havia sido alterado, a empresa queria voltar à versão anterior, comprar máquinas mais potentes, dispensar a consultoria em bancos de dados (eu), entre outras coisas…
Consegui, depois de muito custo e muito suor e muita noite sem dormir (já que os processos rodavam à noite), provar que o problema era no aplicativo, desfizeram as alterações e tudo voltou a funcionar corretamente, não foi necessário desfazer o upgrade do banco nem comprar equipamentos mais potentes, foi apenas necessário identificar onde se encontra o gargalo.
Existem momentos que a empresa quer colocar o banco de dados em RAC, com vários nós, vários servidores WEB, storage, contingência usando DataGuard, etc…
Vamos começar verificando primeiro se realmente a empresa precisa de tudo isso ou se é delírio da área de TI. Temos que ver o orçamento da empresa, pois só em licenças Oracle, isso custará muito dinheiro. Trabalhar sem licença é possível, mas é ilegal e não tem suporte, algo tão complexo sem suporte é suicídio…
Quantos nós de RAC a aplicação suporta, pois se for uma aplicação com muitos “locks” de tabela, não adianta encher de nós, pois o sistema não vai rodar mais rápido…
Para se ter uma aplicação em RAC, é imprescindível uma storage, e não é tão simples trabalhar com esse equipamento, necessário suporte técnico.
Usar o DataGuard pode trazer um grande custo à aplicação, principalmente se desejar manter as atualizações on-line.
Sem se esquecer da estratégia de backup e restore, que necessitam de equipamentos adequados, pessoal qualificado e todo esquema de proteção às fitas.
Já passei por empresas que uma simples mudança na forma de trabalhar significou um ganho de muitas horas no processamento e no desempenho dos funcionários. É claro que nem sempre seremos ouvidos com as soluções mais adequadas, mas o importante é fazermos a nossa parte com dedicação.
O desenho de um projeto megalomaníaco é realmente muito tentador, o problema é que esse tipo de projeto ganha vida e se torna indomável na maioria das vezes, projetos desenhados para atender à necessidades da empresa dificilmente saem do controle.
Nem sempre o melhor caminho é o te alta tecnologia, certamente o melhor caminho é o que leva ao objetivo desejado.