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…

Depois de duas semanas suando muito, trabalhando bastante, eis que não conseguimos atingir os alvos almejados.
Fomos com o espírito preparado para ganhar muito ouro !! Mentira…
Fomos de cabeça baixa, como azarões, que só conseguiria alguma medalha com muita sorte.
Mas não foi o que aconteceu, ganhamos algumas medalhas com muita raça, pois é isso que o brasileiro tem de sobra. Não tem patrocínio, no máximo PAItrocínio como o caso do nadados, não tem apoio, mas cobrança tem, isso tem de sobra.
Ouvi o Galvão Bueno (sim, por um momento de delírio estava assintindo a programação da Globo) dizendo que deveríamos investir nas nossas crianças, ouvi também cutucando os jogadores da seleção masculina de futebol… Pura hipocrisia, pois nunca vi a Globo mostrando campeonato de Taekwondo, a menina que conseguiu medalha foi por méritos próprios, nunca vi incentivar esgrima, hipismo, vela ou qualquer outro esporte que não fosse o futebol, às vezes mostram vôlei, quando o Brasil está em um campeonato mundial, ou então tênis, quando o Guga está no auge, dá para perceber que faz tempo que não falam em tênis por lá…
Nós não assistimos, não procuramos, não incentivamos, não patrocinamos (um lutador de judô ficou muito tempo sem mudar de faixa por que não possuia R$ 1.500,00 para mudança de faixa, treinando em um nível inferior)
A culpa de não chegar ouro na bagagem de nossos atletas é toda nossa !
Os méritos das medalhas que chegaram é toda dessa gente bronzeada que luta muito e deixa sua vida pessoal para conquistar um sonho.
Quem sabe para as próximas olimpíadas tenhamos atletas mais bem qualificados e melhor apoiados, principalmente por mim e você.

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…

Vivemos rodeados de lixo. A sociedade “civilizada” tem gerado tanto lixo que muito em breve teremos problemas sérios do que fazer com tanto dejeto. Só em material de construção, temos um percentual bastante significativo, se formos olhar no campo alimentício, o desperdício é realmente assustador…
Andando pelas ruas, vemos lixo sonoro e visual, além daqueles que respiramos em forma de fumaça, entramos em casa e temos mais lixo, lixo no rádio, na televisão, em revistas e jornais. Somos uma comunidade que vive em meio de lixo.

Trazendo para a nossa atividade profissional, vemos uma quantidade de lixo assustadora, eu sou do tempo em que em um simples disquete de 3 e 1/2 (1.44 MB) cabia não só o editor de texto (saudades do WordStar) como os documentos editados.
É verdade que evoluímos (?!?) mas qual o proço dessa evolução ? Diz um comentário (meio) irônico sobre a área de informática :
“A informática surgiu para resolver problemas que antes dela não existiam”
O pior de tudo é que, em parte é uma grande verdade, tudo anda mais complexo e mais difícil de entender, programas não são mais cadastro, consulta e relatório, tem processamentos complexos, exigindo cada vez mais recursos de máquina, mais memória, mais disco, mais e mais…
Antigamente uma conexão de 14 kbps era o sonho de consumo de muitoas empresas, hoje uma conexão de 4 GBps é considerada lenta, imprópria para muitas empresas.
Nós geramos uma quantidade absurda de lixo virtual, isso sem contar o que surge em nossas caixas de e-mail diariamente (na minha surgem pelo menos 100 mensagens/dia só com SPAM), mas estou falando de nossos sistemas, nossos bancos de dados, nossas aplicações que, ao invés de serem mais enchutas, requerem mais e mais recursos.
Quando eu aprendi a programar, no bom e velho COBOL, nós otimizávamos cada recurso ao máximo, pois as máquinas, com 16 MB de memória, não podiam com programas mal escritos, hoje, com máquinas parrudas, os programadores fazem de qualquer forma, e ainda reclamam que a máquina tem “apenas” 2 GB de memória, “um absurdo” dizem eles… Já trabalhei com servidores com 256MB de memória e achei o máximo, o top de tecnologia, hoje coloco meus bancos em servidores com 16 GB de memória e fico procurando onde melhorar a performance.
Somos todos geradores de lixo, de forma consciente ou não, geramos mais do que vamos necessitar e acabamos jogando em nossas lixeiras virtuais muito recurso que poderia ser melhor aproveitado se utilizado de forma adequada. Programas mal feitos, bancos mal customizados, web mal construídas, equipamentos mal dimensionados e por aí vai…
Vejo uma necessidade urgente de diminuírmos a nossa geração de lixo, físico e virtual, pois o nosso planetinha não vai nos comportar por muito tempo ainda….

Veio sem muito alarde, chegou devagar, como um sonho bom, foi se materializando na minha frente foi se formando escondidinho, crescendo em velocidade assombrosa, longe da vista, mas dentro do coração.
Chegou com data marcada, esperado com festa e muita alegria.
Cada dia é uma surpresa e uma alegria. Cada dia uma nova descoberta. Cada dia um novo sorriso.
Tudo mudou, não temos mais tempo, não temos mais prioridades, não temos mais vontade, e, por incrível que possa parecer, não temos intenção nenhuma de mudar qualquer coisa que seja.
Só quem tem esse tipo de invasor sabe a alegria que é.
Um grande abraço a todos os PAIS, este é o primeiro de muitos anos que poderei comemorar esta data com um sorriso no rosto, pois tenho um novo ser em minha vida.
Para quem é pai, um conselho, aproveite cada instante, por que não volta mais e o tempo passa MUITO rápido…

Um ótimo dia dos pais para todos…

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.

É inevitável, computador deixar de funcionar por motivos inexplicáveis, discos pifarem, rede ir para o espaço, roubo e outras variáveis que deixarão o sistema fora do ar.
O que é, ou pelo menos deveria ser, evitável é a perda definitiva dos dados e indisponibilidade do sistema.
A estratégia de backup tem que ser mais do que uma recuperação eventual de dados, tem que ser uma solução definitiva em caso de catástrofe. Levando-se em consideração até mesmo a perda dos servidores (caso de roubo), necessitando a instalação, configuração e restabelecimento dos serviços até o último momento quando os mesmos foram indisponibilizados.
Cabe ao DBA, organizar o ambiente de forma que os dados sempre estejam disponíveis, pois a função de um administrador é manter a empresa funcionando, haja o que houver.
Outros problemas que costumam parar o funcionamento do banco de dados, são o mal planejamento de crescimento da área de dados, mal dimensionamento do equipamento, que servirá para armazenar e processar os dados, má distribuição de tablespaces, entre outros problemas.
Já passei pela constrangedora situação de não haver mais espaço em disco para a manutenção do banco de dados, cheguei ao cúmulo de desligar a geração de archives pois não havia mais espaço.
Mas isso não foi problema de administração da equipe técnica, foi um problema de quem “assina o cheque”. Quando fomos questionados do porque o sistema estava “capenga”, mostrei as dezenas de e-mails, que vinham de mais de um ano, alertando o problema, quando a casa caiu não tive problemas com a famosa “caça aos culpados”, pois além de estar devidamente documentado, eu havia alertado com antecedência suficiente para que se fossem tomadas as decisões. Se tomaram a decisão errada, a culpa já não é minha…
Além de definir as estratégias, é necessário uma luta constante e insistente para que as mesmas sejam estabelecidas e cumpridas, já passei por empresas cujo backup era feito regularmente, porém nunca haviam testado as fitas ou até mesmo o retorno do mesmo, forcei um teste apenas para descobrir que os logs estavam OK, só que não havia backup, mais de um Tera de dados sem backup. É claro que o responsável foi conhecer a rua mais de perto, contratamos um responsável de verdade e regras mais rígidas para backup, teste e retorno periódicos.
Há situações em que identificamos o crescimento da massa de dados e de usuários em progressão geométrica, quando apenas mais disco não é o suficiente, mostra-se necessário mais máquina, mais servidores, implementação de RAC, mais WEBs, mais infraestrutura de um modo geral, essas necessidades tem que ser preventinamente identificadas e relatadas ao dono da empresa, pois é fundamental que a empresa não pare em momento algum, principalmente por uma “dormida no ponto” de nossa parte.
Quanto mais rapidamente nós agirmos, mais rapidamente decisões são tomadas e menor o impacto de um eventual desastre.
Sua empresa encontra-se preparada para um desastre ? O dia onze de setembro mostrou que existem empresas preparadas para um desastre, outras empresas morreram junto com a queda dos aviões, pois tinham todos os ovos na mesma cesta…