Blog Polo-iT

(por Robson Dias) Os que defendem a máxima de que: “…o que está funcionando não requer upgrade…”, versão moderna do “…em time que está ganhando não se mexe…”, não são páreos para a velocidade da tecnologia.

Pensando nisto, lembrei de um artigo que lí a alguns anos sobre Ned Ludd, líder do movimento luddita e responsável por excessos que começaram em uma simples aversão ao novo, à expansão tecnológica e consequentemente substituição da manufatura pela indústria, conhecida mais tarde como Revolução Industrial.

Ned Ludd deu início à rebelião contra a Revolução Industrial e às tecnologias implantadas principalmente na indústria têxtil. As investidas de Ludd e seus seguidores contra a modernização, podem ser comparadas às dos nossos contemporâneos “Sem Terra”. Invadiram fábricas, detruíram teares, e ameaçaram matar quem os tentasse impedir.

Só para termos uma idéia do teor das ameaças do “General Ludd” - como passou a ser chamado - transcreví a carta abaixo, recebida pelo dono de uma tecelagem do leste da Inglaterra.

“Possuímos informações de que você é um dos proprietários que têm um desses detestáveis teares mecânicos e meus homens me encarregaram de escrever-lhe, fazendo uma advertência para você se desfazer deles…atente para que se eles não forem despachados até o final da próxima semana enviarei um dos meus lugar-tenentes com uns 300 homens para destruí-los, e, além, disso, tome nota de que se você nos causar problemas aumentaremos o seu infortúnio queimando o seu edifício reduzindo-o a cinzas; se você tiver o atrevimento de disparar contra os meus homens, eles têm ordem de assassiná-lo e de queimar a sua casa. Assim você terá a bondade de informar aos seus vizinhos de que esperem o mesmo destino se os seus tricotadores não sejam rapidamente desativados…”
Ass.: General Ludd, março de 1812.

Imaginem um Neoluddita em dias atuais enviando uma carta (mesmo porque não o faria via e-mail) a Bill Gates ou Larry Ellison, ameaçando-os para abortar o lançamento do Windows 7 ou o Oracle 11?!

Claro que um movimento com este nível de truculência não teria como seguir adiante. Mas, ainda assim, não há como deixarmos de lembrar que convivemos no dia a dia com pessoas com aversão (porém incomparavelmente mais tolerantes) ao novo e às constantes inovações tecnológicas. Recentemente, meu pai já na casa dos 60 anos foi renovar a sua carteira de habilitação e ao ouvir seu relato sobre o sucesso na avaliação do Detran, perguntei-lhe qual a parte mais difícil da prova. Ele prontamente me respondeu:

- Foi guiar aquela setinha na tela do computador! Não sei porque essa invenção de tudo agora ser com computador!

Algumas tecnologias marcam tanto, que as inovações não conseguem apagar-lhes por inteiro. É o caso dos mais modernos aparelhos celulares ainda utilizarem o termo “chamadas discadas” quando sabemos que a uns bons anos não fabricam mais telefones com discos e sim com teclas.

Quando a atuação profissional é especificamente na área da tecnologia da informação, como no nosso caso, as atualizações não são somente desejáveis e sim imprescindíveis para manter-se “vivo“. A sequência: Treinamento -> Certificação -> Prática, faz-se cada vez mais necessária no mundo da TI. São os sistemas operacionais, os sistemas gerenciadores de bancos de dados, as linguagens de programação, todos em marcha de renovação constante. E claro que os ganhos com estas mudanças são inegáveis.

Que me perdoem os Neoludditas, mas tecnologia é fundamental!

(por Joel Menezes)

Auditar a nossa documentação de backup baseadas nas políticas de backup adotadas por nossos clientes, me fez refletir sobre esse assunto tão negligenciado por gestores de TI e não menos valorizado por técnicos responsáveis pela salvaguarda desses ativos tão importantes e cruciais para continuidade dos negócios das empresas que são as suas bases de dados.

A noção de Contingencia nos dias de hoje vem tomando um rumo diferente da sua origem que aconteceu basicamente nos tempos dos ambientes de Mainframes que tinham elevadas despesas de manutenção, esse plano descrevia as seqüências de restauração ou substituição dos componentes envolvidos em falhas, com o foco na redução do seu tempo de parada.

O Plano de Contingencia por ser um conjunto de atividades alternativas devem ser previamente planejados com foco na manutenção das atividades de negocio das empresas sem que sofram risco de serem interrompidas, independentemente da falha que venha ocorrer.

O plano de contingência deve ser levado a sério pelos altos executivos da empresa, pois segundo Sêmola (2003, p.99) “… de cada cinco empresas que possuem interrupção nas suas operações por uma semana, duas fecham as portas em menos de três anos”. Pode-se observar que o Plano de continuidade é uma premissa básica para o desenvolvimento sólido de uma organização. Vale lembrar que mesmo fazendo parte dos planos de recuperação de desastres e continuidade, a contingência não garante continuidade, garante apenas que serão encontrados meios de planejar de acordo com as necessidades e limitações existentes.

O setor de Tecnologia da Informação tem grande importância para o desenvolvimento do país, onde este depende diretamente do avanço tecnológico para seu crescimento. Hoje, qualquer empresa depende diretamente dos computadores para guardar seus dados e informações que possuem valores incalculáveis. A perda de informações digitais pode decretar a falência de uma empresa por mais conceituada que esta seja.

A origem das paradas não planejadas está sempre associada a desastres como enchentes, furacões, terrorismo e incêndios, mas há muitas outras origens para estes tipos de ocorrências que não são catastróficas, como por exemplo a perda de um arquivo de um banco de dados, o que também pode até levar uma empresa à falência.

Os problemas de segurança hoje se multiplicam de forma alarmante segundo Beal (2005, p. 91) “No caso de uma rede conectada à Internet, a mera segurança física dos equipamentos conectados já não garante nenhuma proteção: os recursos da rede deixam de estar num endereço físico para pertencer ao chamado “ciberespaço”, ambiente virtual criado pela rede mundial de computadores, e precisam ser protegidos contra quebra de segurança causada por ameaças externas (invasões, ataques de negação de serviço etc.) e internas (erros,abusos de privilégio, fraudes etc.).”

É importante saber que para se ter um sistema mais seguro é necessário um acompanhamento minucioso desse sistema. É preciso se estabelecer regras, personalizadas para cada empresa, cada situação conforme Sêmola (2003, p.105) “Estabelece padrões, responsabilidades e critérios para o manuseio, armazenamento, transporte e descarte das informações dentro do nível de segurança estabelecido sob medida pela e para a empresa; por tanto, a política deve ser personalizada”.

O ataque terrorista ocorrido em 11 de Setembro de 2001 demonstra um exemplo de como a administração de sobrevivência de negócios pode ser falha, em caso de má elaboração do plano de contingência. Por volta de 85 empresas simplesmente deixaram de existir, pois os seus respectivos centros de backup estavam localizados na torre vizinha e os autores do plano não pensaram que ambas pudessem cair ao mesmo tempo. Caso o backup estivesse em outra localidade, muito provavelmente tais empresas estivessem com suas atividades retomadas nos dias atuais.

Os administradores devem estar conscientes de que o investimento em um plano de continuidade de negócios é muito útil e um dia pode ser extremamente necessário, em alguns casos, vital.

Os estágios do plano de continuidade e sobrevivência mostram a necessidade de uma integração mais ampla desses fatores e evidenciam a ligação que há entre os fatores tecnológicos e organizacionais da empresa.

Para se fazer uma analise de impacto nos negócios é preciso analisar os processos da empresa para se ter uma idéia de como os aspectos de segurança podem se relacionar com tais processos. A política da empresa deve ser analisada, riscos devem ser identificados, falhas internas, operações críticas, tempo de resposta da recuperação de processos etc. Tudo isso deve estar referenciado no manual prático do plano de contingência da empresa.

O plano de continuidade de negócios e o sistema de sobrevivência são dois conceitos muito parecidos. É fato que a preocupação com a segurança tem aumentado em vários setores da indústria, mas isso cabe aos responsáveis pela organização tomar medidas cabíveis ao ramo em que atuam. Pesquisas devem ser feitas, e regras implementadas em todos os setores da empresa com o objetivo de reduzir ao máximo as vulnerabilidades existentes.

Segundo Beal (2005, p. 172) “Compreender claramente as características da organização, sua estrutura, suas capacidades, objetivos, estratégias, restrições legais de atuação e natureza dos ativos de informação, em termos de seus valores tangíveis e intangíveis, é fundamental para que se possam definir critérios adequados para avaliar os riscos e selecionar as melhores alternativas entre as medidas de proteção para reduzi-los.”
Qualquer impacto na geração de receitas por conta de paradas na produção pode ocasionar perdas significativas no faturamento e, principalmente na reputação da indústria para com o mercado. Assim o emprego dos Planos de Continuidade de Negócios e de Recuperação de Desastres é essencial para garantir a existência da empresa.

Não podemos nos enganar ao afirmar que backup do site, contingencia externa de servidores e banco de dados, sistema de armazenagem de primeira linha(storage) garantem a continuidade dos negócios, pois NÃO garantem. Todo esse processo de negócios realizados pelas empresas e que devem estar protegidos de interrupções, são por pessoas executados e pessoas precisam de orientação pontual, planejada e especifica, sem isso, não se garante a continuidade dos negócios da empresa somente por ela possuir bons sistemas de backup ou equipamentos de primeira linha.

Não há sistema perfeito nem segurança perfeita, mas muitas são as formas de contingência que podem ser adotadas e farão a grande diferença quando o imprevisto já estiver previsto.

Joel Chagas Menezes é Administrador de Empresas, pós-graduado em Qualidade e Governança de TI e faz parte do corpo docente da graduação da UNIFACS além de trabalhar com bancos de dados há mais de 20 anos. Como sócio da Polo-iT, atua na Gerência de Suporte e é o responsável pela gestão da qualidade nos processos do DBA Center.

(por Marcelo Medrado)

Em todos estes anos trabalhando com bancos de dados, havia sempre um questionamento recorrente sobre qual o melhor SGBD do mercado. E o mais engraçado é que, da mesma forma que se observa conversas sobre times de futebol, bandas prediletas e religião, sempre existem opiniões que tangem ao fanatismo ao se defender o seu “banco de dados predileto”.

Mesmo evoluindo minha carreira juntamente com o Oracle há várias versões, confesso que me esforço para não ser xiita em nenhum momento e sempre me mantenho informado sobre os seus concorrentes. Vejo que o mercado evoluiu bastante e hoje nós já possuímos diversos “players” que não só fazem bonito como já incomodam os gigantes Oracle, DB2 e MS SQLServer.

Dos SGBDs que me aprofundei mais, gostaria de fazer um paralelo entre os dois bancos de dados mais usados no mundo: Oracle 10g e MS SQLServer 2005.

“Mas pera lá, por que você não está comparando o Oracle 11g com o SQL 2008?”, podem me perguntar alguns. A resposta é simples: Por que o parque instalado de bancos Oracle 10g e MSSQL 2005 é muito superior ao do seus irmãos mais “modernos”. Da mesma forma, as colocações feitas aqui são baseadas na percepção empírica de como as tão divulgadas funcionalidades de cada um deles funcionam de verdade na vida real.

É importante ressaltar que eu pretendo pontuar vantagens reais em relação aos dois produtos. Não farei nenhum tipo de comparação sobre características pouco aproveitadas como a possibilidade de se poder criar 32.000 colunas no Oracle contra “somente” 1024 do SQLServer 2005 (apesar de quê tenho uma curiosidade mórbida de descobrir se alguém, por algum motivo, trocou o seu SGBD por não conseguir satisfazer seus desejos masoquistas se criar tabelas com mais de 1024 colunas). Da mesma forma, partirei do princípio que esta comparação envolve ambientes de tamanho médio com máquinas low-end pois não só a limitação do sistema operacional da Microsoft como a própria estrutura do seu banco de dados não permite que o mesmo seja executado em ambientes maiores, com servidores high-end e aplicações extremamente complexas e críticas. Vamos aos tópicos:

Concorrência, Locks e Versionamento

Um dos grandes saltos do SQL Server 2005 em relação às versões anteriores foi o trabalho feito em relação à concorrência no acesso às informações. Uma das grandes reclamações pré-2005 era justamente sobre falta de eficiência neste quesito. Na prática, metade dos problemas de qualquer grande base em SQL Server 2000 se resumia a locks.

Nesta nova versão, o SGBD da Microsoft adotou um novo nível de isolamento chamado “Snapshot Isolation”. Trocando em miúdos o MS SQLServer (finalmente) agora tem a capacidade de criar versionamento de linha - um recurso que garante que se crie uma fotografia do banco no início de uma transação independente dos inserts, deletes e updates até que a mesma chegue ao fim.

No Oracle, não existe tal funcionalidade porém este comportamento pode ser simulado através do Flashback Database e também de consultas baseadas em timestamp, que são capazes de trazer informações como elas “eram” num tempo passado (obviamente, respeitando-se os limites parametrizáveis de retenção).

Ambas as bases agora trabalham com locks em todos os níveis - tabela, linha e coluna - porém o SQL Server 2005 possui uma controversa funcionalidade que permite que se habilite uma forma de consultar dados ainda não efetivados de outras transações.

Reorganização Online de Dados e Índices

Historicamente, o MSSQL Server possuía poucas possibilidades de reorganização em comparação aos seus grandes concorrentes DB2 e Oracle. Basicamente, índices podiam ser reorganizados, sempre com a necessidade de um lock exclusivo. A partir da versão analisada, o SQL já permite reorganização de índices sem a geração de locks, mesmo gerando um overhead de processamento razoável.

O Oracle já possui diversas funcionalidades relacionadas à reorganização de tabelas e índices. Na prática, pode-se mover uma tabela inteira no Oracle sem bloqueá-la gerando um pequeno lock apenas no momento da finalização do processo. Além disso, o Oracle 10g trouxe a possibilidade de se compactar/reorganizar tabelas movendo os blocos de forma contígua e liberando o espaço final, reduzindo fragmentação e espaço utilizado na tablespace.

Estratégias de Backup, Manutenção e Recovery

É impressionante a simplicidade de se executar tarefas no MSSQL Server 2005. Digo, com propriedade, que quem já está acostumado à dureza das scripts complexas em diferentes plataformas necessárias ao Oracle vai se sentir “nas nuvens” ao criar uma rotina de backup e manutenção no Management Studio do SGBD da Microsoft. As rotinas são criadas em forma de fluxo, como num diagrama gerado no Visio, onde você diz graficamente o que você quer, como você quer e como a rotina deve se comportar de acordo com o status de execução de cada tarefa. Simplesmente Perfeito. Em compensação, as possibilidades de backup me pareceu insuficiente para todos os cenários existentes e demasiadamente frágil.

Diferente do Oracle, não existe uma separação completa entre logs e dados, estes logs não podem ser movidos ou armazenados pois se acumulam num grande arquivo e não há a possibilidade de se manter backups redundantes. Em outras palavras, ao se fazer um backup FULL de sua base de dados, automaticamente os anteriores são invalidados. As estratégias de backup incremental são bem eficientes e úteis e satisfazem qualquer necessidade de bancos pequenos a médios. Para piorar o quadro, não existe nenhuma metodologia de exportação lógica de informações, possibilitando a restauração de uma única tabela ou usuário.

O Oracle, por sua vez, possui inúmeras possibilidades de backup diferentes. Desde as metodologias de backup físico online (cópia dos datafiles e criação de backupsets) até as diferentes formas de se gerenciar estas estruturas (automaticamente, através da flash_recovery_area que faz a gestão automática da retenção dos arquivos ou manualmente, através de scripts manuais gerenciados pelo DBA). Para alívio de alguns (e desespero de outros) as rotinas de backup na versão 10g podem ser configuradas através do Database Console, ferramenta web de administração que reúne diversas funcionalidades.

Em se tratando de recuperação, o MSSQL Server 2005 possui maior flexibilidade pois cada banco de dados possui informações de consistência próprios o que permite que bancos diferentes sejam recuperados de backups diferentes (feitos em momentos diferentes, inclusive). Por outro lado, existem diversas técnicas de recuperação (além de parâmetros não-documentados) que fazem qualquer cenário de catástrofe recuperável bastando que se mantenha uma estratégia de backup eficiente.

A ferramenta de exportação de dados lógicos do Oracle também é um show à parte: Ela possibilita que você gere um arquivo contendo todas as informações lógicas necessárias para se restaurar a base de dados inteira, em plataformas e arquiteturas diferentes.

Ambas as bases oferecem funcionalidades à parte: Anexar bases avulsas (MSSQL), transportar tablespaces entre arquiteturas diferentes (Oracle), Voltar toda uma base de dados a um momento específico do tempo (Oracle), Migrar planilhas do Excel e bases do Access de forma transparente (MSSQL), entre outras. A cada nova versão, mais flexível se tornam as técnicas de movimentação de dados.

Espelhamento

O SQL Server 2005 possui uma nova modalidade de espelhamento Ativo-Passivo semelhante ao Oracle Dataguard, através de aplicação de logs de transação. A sua simplicidade e eficiência impressionam até aos fans mais inveterados da Oracle pois pode ser implementado com alguns bocados de cliques. Para que o failover seja automático, é necessário criar uma terceira instância, chamada de forma nada criativa de “testemunha”. Este terceiro membro, tem a “nobre missão” de monitorar as bases e controlar automaticamente quem está ativo e quem está inativo/sincronizando.

No Oracle, o Dataguard faz as honras, com sua complexidade e sofisticação colocando à prova o conhecimento de qualquer DBA (de fato, existe uma certificação Oracle somente para esta funcionalidade). Ele não só faz o simples espelhamento de instância no modo ativo-passivo como pode ser usado como base para relatórios e outras diversas funcionalidades que seriam dignas de um post exclusivo neste blog.

Desenvolvimento

Confesso que fui surpreendido com o poder da linguagem Transact SQL (ou T-SQL para os íntimos) embarcada no MSSQL Server 2005. Ela não só possui todos os requisitos para se desenvolver qualquer tipo de programação estruturada nas procedures e funções como também possui uma compatibilidade nativa com toda a estrutura .NET possibilitando a escrita de procedimentos diversas linguagens (como C# e Visual FoxPro) de forma transparente. Da mesma forma, pode-se utilizar todas as APIs do Windows dentro das procedures e funções, algo que somente um SGBD e um sistema operacional com mesmo “pai e mãe” poderiam proporcionar. Funcionalidades como TRY/CATCH (comparável ao EXCEPTION do PL/SQL do Oracle), operadores relacionais, PIVOT, ROW_NUMBER e várias outras funções de ranking de linha. Existe também um suporte nativo ao XML que deixa o XML DB do Oracle com inveja.

O Oracle, por sua vez, vem evoluindo desde a versão 8i no quesito “funções analíticas” e hoje existem quase 100 funções suficientemente poderosas para enfrentar a facilidade do T-SQL. Ironicamente, até hoje o Oracle ainda não implementou a função PIVOT, disponível apenas na utilização de pacotes especiais na option OLAP, instalada separadamente.

Funcionalidades Exclusivas do Oracle 10g

LogMiner:
Esta funcionalidade provê uma forma de extrair todas as DMLs e DDLs executadas na base de dados historicamente, através dos logs de transação. É muito utilizado em auditorias, replicação ou criação de scripts de rollback. Apesar do MSSQL Server 2005 não ter algo semelhante, existem ferramentas de terceiros que podem interpretar os arquivos de log. Da mesma forma uma funcionalidade avançada chamada DDL Notification Event permite que eventos sejam disparados sempre que DDLs e DMLs sejam executados.

Flashback Query:
Outra fantástica funcionalidade do Oracle 10g que permite que consultas sejam feitas num cenário de tempo anterior ao atual. Isso quer dizer que pode-se consultar dados que estavam na tabela X na noite anterior. Da mesma forma, pode-se habilitar a recuperação de um objeto deletado, da mesma forma que se faz na lixeira do Windows. É o Oracle Recycle Bin.

Auditoria:
Com novas extensões do parâmetro AUDIT_TRAIL, todas as queries executadas podem ser auditadas incluindo as bind variables. No MSSQL Server, somente o SQL Trace pode fornecer alguma informação desta natureza mas não mostra bind variables e gera um grande overhead na performance do banco de dados.

Funcionalidades Exclusivas do MSSQL Server 2005

Identity:
Uma das funcionalidades mais úteis que o Oracle NÃO POSSUI é o campo identity numa tabela. Campos assim têm a capacidade de auto-incrementar a primary key de forma prática e simples. As sequences do Oracle são extremamente úteis e poderosas mas geram grandes sobrecargas de administração em ambientes mais complexos. Na prática, a única forma de simular isto no Oracle é criando triggers de auto-incremento.

Notification Services:
Esta funcionalidade possibilita a implementação de sistemas de notificação que disponibilizam, de forma personalizada, informações em tempos determinados, para qualquer dispositivo. Esta informação pode incluir alerta de reposição de estoque, alerta de produto indisponível e qualquer outra informação “consultável” no banco de dados. O fato dele ser integrado com o Windows possibilitando executar DLLs, e softwares, enviar e-mails e SMSs faz do Notification Services uma ferramenta poderosa.

Reporting Services:
É um serviço de geração de relatórios capaz de criar belos PDFs e com uma excelente IDE. Apesar do Reporting Services não chegar aos pés do Oracle Reports rodando sobre o Oracle IAS, o fato dele estar integrado ao SGBD é uma vantagem considerável.

Resumo da Ópera

Não subestime o poder das funcionalidades do MSSQL Server 2005. Trata-se de um banco de dados amadurecido e robusto que possui diversos atrativos ligados à simplicidade da administração, usabilidade e interface superiores e a praticidade de estar intrísecamente ligado ao sistema operacional.

Infelizmente, a comparação termina por aí. Testes atuais mostram que o Oracle possui performance semelhante ao MSSQL 2005 em plataformas Windows e seu desempenho cresce exponencialmente em plataformas UNIX e arquiteturas RISC. A possibilidade muito superior de customização de memória e parâmetros relacionados a I/O, uso de blocos de leitura e escrita, cursores e processos fazem do Oracle um banco de dados muito mais completo e robusto, portanto que se pague o preço referente ao seu custo.

Que me desculpem os DBAs Xiitas, mas eu não consigo visualizar um cenário onde existam requisitos técnicos que façam o MSSQL SQLServer uma escolha melhor para um ambiente. Notem que eu disse “requisitos técnicos”. A utilização de tecnologia Microsoft em todo parque, o conhecimento prévio da tecnologia, a limitação técnica da infraestrutura de servidores, a integração com o .NET e o custo menor de administração fazem do MSSQL Server 2005 uma excelente opção.

A Polo-iT hoje oferece administração de bases de dados Oracle e SQL Server, por um custo x benefício inigualável com monitoramento reativo e pró-ativo 24x7.

Qual deles você escolhe?

Marcelo Medrado é DBA Oracle há 9 anos além de trabalhar com dimensionamento de hardware e desenvolvimento de aplicações. Como sócio da Polo-iT, atua no DBA Center prestando consultoria a clientes Oracle e SQLServer e faz parte do núcleo de desenvolvimento das ferramentas de monitoria de bancos de dados da empresa.

(por Fábio Nepomuceno)

Na atual configuração do mercado e dos negócios, precisamos de informações de forma imediata. A concorrência agressiva e a velocidade em que as coisas acontecem nos obrigam a tomar decisões rápidas. Por isso faz-se necessário mantermos as informações estratégicas da organização “sempre a mão”.

Diante deste cenário as empresas investem em sistemas que garantem integridade e velocidade no acesso a seus dados. O SGBD Oracle desde 1992 oferece essas vantagens e não pára de evoluir, como bem colocado por Constantino Jacob no último post deste blog (Você ainda está no Oracle 7?).

Mas de nada adianta todo poder deste referido SGBD se a equipe responsável pelo desenvolvimento das consultas não conhecer formas de extrair o máximo de desempenho da ferramenta.

Em seguida são listadas algumas dicas de como utilizar toda a força do SGBD Oracle em favor de consultas mais rápidas:

1) Bind Variables

O uso de variáveis de ligação (Bind variables) em procedures, triggers, functions, packages e na própria aplicação traz o benefício da redução do uso de memória no servidor, pois não é necessária a fase de “parse” durante a execução do comando.

Exemplo:

select * from notas_fiscais where departamento_id = 63;
select * from notas_fiscais where departamento_id = 68;

Usando uma Bind Variable chamada v_departamento_id, a consulta ficaria assim:

select * from notas_fiscais where departamento_id = :v_departamento_id;

Para que os comandos se tornem iguais, você deve sempre usar variáveis no lugar de dados fixos, como mostra o exemplo acima.

2) Use índices nas tabelas cuidadosamente

2.1)Use índices em colunas que são freqüentemente usados na clausula WHERE de consultas da aplicação ou de consultas usadas por usuários finais.

2.2)Indexe as colunas que são freqüentemente usadas para juntar (JOIN) as tabelas nas diferentes consultas. Prefira fazer JOIN pelas chaves primarias e chaves estrangeiras. Use índices únicos em chaves primárias e índices não únicos em chaves estrangeiras (FOREIGN KEY). Índices únicos são melhores que os não únicos devido a melhor seletividade. Portanto dê preferência a seleção de dados através das chaves primárias.

2.3) Use índices apenas em colunas que possuem uma baixa porcentagem de linhas com valores iguais. Quanto menos distintos forem os valores para uma coluna, obtemos mais velocidade no acesso aos dados desta tabela utilizando essa coluna indexada.

2.4) Não use índices em colunas que são usadas apenas com funções e/ou operadores (diferente de “=”) na clausula WHERE.

As seguintes cláusulas no WHERE não farão uso do índice mesmo que ele esteja disponível:

A.COL1 > A.COL2
A.COL1 < A.COL2
A.COL1 >= A.COL2
A.COL1 <= A.COL2
COL1 IS NULL
COL1 IS NOT NULL
COL1 NOT IN (value1, value2)
COL1 != expression
COL1 LIKE ‘%teste’

No último exemplo de cláusula, o uso do “%” no inicio da string acaba por suprimir a parte por onde coluna é indexada e por isso o índice não é usado. Por outro lado, COL1 LIKE ‘teste%’ ou COL1 LIKE ‘teste%teste%’ faz uso do índice resultando em uma busca por faixas limites.
Quaisquer expressões, funções ou cálculos envolvendo colunas indexadas não farão uso do índice se ele existir. No exemplo a seguir, o uso da função SQL UPPER vai impedir a utilização do índice provocando assim uma consulta FULL TABLE SCAN.

SELECT DEPT_NAME
FROM DEPARTMENT
WHERE UPPER(DEPT_NAME) like ‘SALES%’;

2.5) Não indexe colunas que são freqüentemente modificadas ou quando a eficiência ganha através da criação de um índice não valha a pena devido à perda de desempenho em operações de INSERT, UPDATE e DELETE. Com a criação do índice, estas operações perderão em desempenho devido à necessidade de manter o índice correto.

3) Planos de Execução (Explain Plan)

Sempre que possível faça uso do Explain Plan, pois se for indicado que na consulta existe: Table Access (Full). Isso indica que na tabela está ocorrendo leitura sem a utilização de índices. Desta forma a consulta fica “pesada”, dependendo das quantidades de registros que contém na mesma, aumentando o tempo de retorno.
A dica é: Quando temos um plano de acesso de uma query com está situação, devemos observar a quantidade de itens que a tabela possui. É interessante criar um índice para tabelas com mais de 2000 registros.

4) Use o WHERE ao invés de HAVING para filtrar linhas

Evite o uso da clausula HAVING junto com GROUP BY em uma coluna indexada. Neste caso o índice não é utilizado. Além disso, exclua as linhas indesejadas na sua consulta utilizando a clausula WHERE ao invés do HAVING. Se a tabela FUNCIONARIO possuísse um índice na coluna DEPARTAMENTO_ID, a seguinte consulta não faria uso dele:

SELECT DEPARTAMENTO_ID,
SUM(SALARIO)
FROM FUNCIONARIO
GROUP BY DEPARTAMENTO_ID
HAVING DEPARTAMENTO_ID = 100;

Entretanto, a mesma consulta pode ser escrita para explorar o índice:

SELECT DEPARTAMENTO_ID,
SUM(SALARIO)
FROM FUNCIONARIO
WHERE DEPARTAMENTO_ID = 100
GROUP BY DEPARTAMENTO_ID;

5) Especifique as colunas do índice na clausula WHERE

Em um índice composto a consulta apenas utilizará o índice se as colunas do índice estiverem especificadas na clausula WHERE. A seguinte consulta usará o índice composto baseado na chave primária (NOTA_ID, ITEM_ID, PRODUTO_ID) da tabela ITENS_NOTAS_FISCAIS.

SELECT VALOR_ITEM
FROM ITENS_NOTAS_FISCAIS
WHERE NOTA_ID = 27
AND ITEM_ID = 100;

SELECT VALOR_ITEM
FROM ITENS_NOTAS_FISCAIS
WHERE PRODUTO_ID = 5555;

Nenhuma das consultas acima se beneficiará do uso do índice composto.
A mesma consulta pode ser reescrita para tirar vantagem do índice.

SELECT VALOR_ITEM
FROM ITENS_NOTAS_FISCAIS
WHERE NOTA_ID > 0
AND ITEM_ID > 0
AND PRODUTO_ID = 5555;

6) Quando não utilizar índices

Se você estiver selecionando mais de 15 % das linhas de uma tabela, um FULL TABLE SCAN é geralmente mais rápido do que o acesso pelo índice. Quando o acesso por índice causar lentidão ao invés de apresentar um ganho de desempenho pode utilizar algumas técnicas para eliminar o uso do índice:

Para colunas numéricas:
SELECT NOME
FROM FUNCIONARIO
WHERE SALARIO+0 = 50000;

Para colunas alfanuméricas
SELECT NOME
FROM FUNCIONARIO
WHERE DDD || ‘’ = ‘071′;

Um índice também não é usado se o Oracle tiver que realizar uma conversão implícita de dados.
Para o exemplo a seguir, SALARIO é uma coluna numérica na tabela FUNCIONARIO e uma string é convertida num valor numérico:

SELECT NOME
FROM FUNCIONARIO
WHERE SALARIO = ‘50000′;

Quando a porcentagem de linhas acessadas é menor que 15 % da tabela, então o uso do índice será bem mais performático.

A Polo-iT possui os melhores profissionais com grande conhecimento de ambientes reais de alta criticidade poderá lhe auxiliar no seu projeto de melhoria de performance de consultas, desenvolvimento de aplicações e modelagem de rotinas. Possuímos a solução certa, sob medida para a sua empresa e com excelente retorno.

Espero que as dicas sejam úteis. E até o próximo blog.

Fábio Nepomuceno é Analista de Sistemas e atua há 9 anos como especialista em desenvolvimento de aplicações baseadas em Oracle Forms e Reports, PL/SQL e Oracle Applications. Possui vasto conhecimento em criação de consultas complexas utilizando todo o potencial oferecido pelo Oracle para aplicações contábeis, financeiras e administrativas em geral.

(por Constantino Jacob)

O ano era 1993. Nesta época, eu trabalhava com um banco de dados relacional chamado XDB (XDB Enterprise Server - não tem nada haver com o Oracle XDB) e sofria indo para o Pólo Petroquímico à noite, devido há algum travamento do mesmo. Não era fácil. O XDB rodava sob o OS/2 - estável como uma rocha - mas o banco era ruim mesmo.

O XDB, se comparado com as bases dBase e com meus trabalhos com Clipper, era uma revolução. Pelo menos eu achava isso.

Neste mesmo ano, Joaquim Godinho, meu amigo de longas datas, me falava maravilhas de um tal SGBD Oracle. Extremamente caro, mas extremamente poderoso. Fazer um update e bloquear a tabela inteira? Bloquear uma página? Ah, isso não existia com o Oracle 7 - o bloqueio era por registro - e demoraria muito tempo para a concorrência chegar neste nível. Tive que esperar um ano para ter a oportunidade de trabalhar com o Oracle. E tal fato me deixou muito mal acostumado.

Não havia Internet da forma como conhecemos hoje (e consequentemente, não havia Oracle Technet e Metalink - os sites de suporte online da Oracle) e sequer vinha alguma documentação em CD-ROM. O cliente que comprava o Oracle 7 recebia de 10 a 15 livros sobre o banco (e o produto vinha em fitas DAT). Eu até diria que não havia BUGs. O erro era sempre do desenvolvedor. Completando o quadro, eu ainda trabalhava com o Oracle Forms 4.5 que, para mim, continua sendo a IDE mais produtiva que eu já vi. Pena que a ferramenta parou de evoluir (mas isso é assunto para outro blog) . . .

Mal qual o motivo deste saudosismo? Não, não é saudade. Depois de muitos anos de estrada, e tendo visto diversos ambientes diferentes, eu constatei que a maioria dos sistemas são desenvolvidos como se fossem rodar no… Oracle 7! Se criam as tabelas, as chaves primárias, constraints de integridade referencial, e quando muito triggers e stored procedures. Tecnologias disponíveis no produto desde 1992.

Esses recursos são ótimos, mas são básicos. Os outros recursos que vieram com as outras versões basicamente não são usados. Suporte a OO - a falta de uma padronização, que só foi retomada no ANSI-SQL99, prejudicou a sua adoção. Mas o Oracle já o utiliza desde a versão 8. E se houvesse algum problema de programação, que você não conseguisse resolver com PL/SQL ? Java Stored Procedure nele, disponível a partir do Oracle 8i. São centenas de recursos. Indices baseados em funções (8i, 9i). Consultas hierarquicas, merge, External Tables, Tecnologia FlashBack, expressões regulares, envio de email pelo banco, suporte ao XML. A cada versão, mais novidades.

Não estou dizendo aqui que o desenvolvedor tenha que usar todos, mas pelo menos, deveria conhecer os principais recursos. O site http://otn.oracle.com disponibiliza uma vasta documentação sobre o produto. Nós, da Polo-iT, sempre que possível indicamos qual o melhor recurso presente no Oracle para resolver determinado problema. Os clientes geralmente ficam surpresos com a versatilidade do produto (e eu estou me prendendo apenas nos recursos mais voltados para o desenvolvimento). O assunto é vasto, terei muito o que escrever.

Um abraço a todos e até o próximo post.

Constantino Jacob é DBA Oracle há 10 anos além de especialista em infraestrutura para aplicações Java x Oracle e desenvolvimento em plataforma Oracle. Como sócio da Polo-iT, atua na gerência de Tecnologia e faz parte do núcleo de desenvolvimento das ferramentas de monitoria do DBA Center.

Em todos os segmentos, nos deparamos com bons e maus profissionais. Em alguns, a balança da ética pende para o positivo, em outros sensivelmente para o negativo (quando viram inspiração para piadas e até roteiros teatrais) e em alguns casos a medida torna-se morna, estável como os pratos da balança de Themis.

Na TI não é diferente. Nestes anos de militância na área da Tecnologia da Informação, tenho convivido com “representantes” de ambos grupos. De técnicos que não vêem a hora do seu turno acabar para verem-se livres daquele suplício do atendimento, a técnicos que ficam maravilhados ao fazer “aquilo” funcionar e manterem-se ávidos pelo próximo atendimento-desafio.

Prefiro não rotular os primeiros como “maus-técnicos”. Sinceramente prefiro pensar que são pessoas que estavam perdidas na estação e pegaram o primeiro trem que lhes abriu a porta. Se o destino não lhe for agradável, não haverá prazer e principalmente comprometimento. Tudo deverá ser feito com a máxima rapidez (quando for feito) e sobrar-lhe tempo para fazer o que descobriu realmente gostar. Ou os atendimentos serão realizados letargicamente, para que nenhuma outra tarefa lhe seja delegada naquele período. Não têm o “mote” do suporte.

Os segundos identificam-se bit a bit com as atividades que lhes são delegadas e mais, acabam indo adiante ao “atendimento concluído” e passando para a próxima etapa: “satisfação do solicitante”. Estes sim, pegaram um trem não somente para sair da estação, mas O trem com linha definida: A linha traçada na palma de sua mão.

Estas variantes de “bons” e “maus” profissionais são encontradas em várias esferas hierárquicas. Os gestores não estão isentos apenas por terem alcançado uma posição elevada na “cadeia alimentar da TI”. Existem sim, os comprometidos com uma das principais métricas da Gestão de TI: Eficácia & Custos, onde a eficiência do produto deve ter um peso bem maior que o custo. Existem os comprometidos apenas com o politicamente correto e existem os que… bem, não precisamos ir tão fundo.

Já tive a oportunidade de passar 36 horas ininterruptas em um atendimento complexo com o meu então gestor e neste período de tempo pude analisar o ítem comprometimento. Por que ele estaria aquele tempo todo naquele atendimento e não simplesmente delegou aos demais técnicos que o resolvessem? Podendo ser ainda pior, estabelecendo um prazo para a conclusão daquela correção e pronto? Mas esta resposta me veio naturalmente com o tempo. Aquele gestor foi um técnico que pegou o trem correto e traçado anteriormente. Claro que somado-se a isso, temos algumas vertentes como personalidade, caráter e educação doméstica.

Ainda na Tecnologia da Informação, temos a área comercial. Esta às vezes é eleita injustamente como o desvio padrão negativo da ética na TI. Injustamente porque devemos abolir o preconceito e paradigmas de que o vendedor ou consultor técnico apenas nos visita com olhos de cifrão e vê nosso negócio apenas como sua comissão, seu sustento. Existem sim, os apaixonados pelas soluções, que vibram quando estas são implantadas e tornam-se um caso de sucesso. Mas também não há como negar que existem figurinhas carimbadas nesta área que logo são identificadas como “vendedores de bigorna”, ou seja, apenas vendem uma vez naquele cliente e região. Nesta área, classifico 3 tipos: O Caxias, O Ingênuo e O Mau-caráter:

O Caxias é aquele sujeito bastante comedido, preserva muito mais o seu nome e sua carteira de clientes do que a sua comissão e tem verdadeira fobia de ver seu NOME atrelado a um serviço ruim ou não prestado conforme oferecido. Tem vida longa no mercado.

O Ingênuo é aquele que muitas vezes até acredita que tem o melhor serviço, a melhor solução, o melhor produto e o menor custo. Na maioria das vezes é o cliente quem o situa de que seu serviço tem falhas e não corresponde exatamente ao que foi oferecido. Acaba conseguindo manter-se no mercado porque alguns de seus produtos realmente funcionam.

O Mau-Caráter é sem sombra de dúvidas o pior. Ele tem plena consciência de que o produto que oferece não tem qualidade e às vezes sequer existe; tem consciência de que aquele serviço para o cliente é vital. E vital literalmente por às vezes se tratar de uma administração de um banco de dados de um hospital ou um laboratório de análises clínicas e ainda assim pensar apenas no dinheiro que irá faturar com aquela venda. Infelizmente este é um fato, não uma abstração. É o intitulado consultor técnico ou vendedor que faz o técnico que o acompanha enrubescer quando faz uso das mais diversas mentiras para promover um produto e pede a sua confirmação, aprende palavrinhas chaves mais “impactantes” e abusa delas. Tem vida curta no mercado, avidez pela riqueza - porém sem sucesso - e uma coleção de vários empreendimentos que tentou e obviamente não deram certo. Mas como um bom insistente, recomeça com novos golpes, digo, novas vendas.

Mas enfim, levantemos a bandeira da ÉTICA NA TI.

Onde estão meus indicadores de performance? Como são feitos os meus backups? Quem os testa regularmente? Como saber se o meu ambiente está configurado para máximo desempenho? Como reagir de forma pró-ativa aos problemas que podem ocorrer em meu banco de dados de produção?

Questionamentos como estes fazem parte de qualquer empresa que possua um ambiente de TI. O alto custo de profissionais especializados, a falta de ferramentas específicas e os problemas de documentação e padronização de procedimentos fazem com que muitos gestores confiem na sorte para manter seus serviços disponíveis o máximo de tempo possível.

O DBA Center é a solução ideal para quem deseja manter seu ambiente de TI sempre disponível e com o máximo de desempenho. Seus módulos abrangem todo o escopo de administração de bancos de dados através de serviços de diagnóstico, configuração, customização, tuning, documentação e demais serviços operacionais e estratégicos que garantam a disponibilidade e integridade do seu ambiente.

Nossos sistemas de monitoria pró-ativa e reativa são o fruto de anos de sólida experiência em administração de bancos de dados. Sua inteligência artificial se baseia em indicadores de desempenho customizados e em regras de decisão estruturadas de acordo com os melhores métodos de administração, detecção preemptiva de problemas e análise de não-conformidades inerentes à rotina operacional do cliente.

Como sabemos que cada ambiente possui uma realidade, procuramos moldar nossos serviços de acordo com as suas necessidades oferecendo uma série de diferenciais:

- Proatividade
- Monitoria 24x7
- Custo X benefício inigualável
- Sistemas de monitoria inteligentes
- Relatórios de acompanhamento e performance
- Equipe de Especialistas

Entre em contato conosco! A Polo-iT possui a solução certa, sob medida para a sua empresa e com excelente retorno.