Quantos DBAs são necessários para trocar a lâmpada?

 Uma das dificuldades na gestão do serviço de DBAs é dimensionar de forma eficiente a equipa (DBA BOX). A maioria das equipas de DBAs encontra-se a operar com um número deficiente de elementos.

A principal causa para esta situação é a ideia que menos elementos, acarretam menos custos. No imediato esta suposição pode ser verdade, mas a médio e longo prazo não. A equipa de DBAs com excesso de trabalho, pode cometer erros e constrangimentos de operação e de manutenção que originem custos superiores ao salário de vários elementos da equipa de DBAs.

Esta mensuração não é uma ciência exacta e depende muito do ambiente envolvente: 

• Os SLAs, quanto mais restrito é o nível de serviço, mais exigente é para a equipa de DBAs a efectivação do mesmo. Existem situações em que as respostas das base de dados (resultados das instruções de SQL) é na casa dos milésimos de segundo e esta é uma situação mais difícil de garantir suporte, manutenção e administração do que a base de dados com SLAs em que as respostas (resultados das instruções de SQL) é na casa dos segundos, também o cumprimentos das melhores práticas recomendadas pelo ITIL no suporte a base de dados (incident Management, problem Management, configuration Management, change Management, release Management) e uma gestão de serviço prestado pela DBA BOX pressupõe um controlo das operações, onde é necessário possuir o número de elementos que garantam o seu cumprimento.

  

• Os requisitos de desempenho, quanto maiores forem as necessidades de desempenho das bases de dados mais exigente é o seu suporte, manutenção e administração.

 

• A experiência, competência e empenho individual de cada elemento da equipa de DBAs é muito importante no dimensionamento da equipa.

 

• O impacto da indisponibilidade, quanto maior o custo monetário e de imagem do cliente numa indisponibilidade, maior será a pressão na equipa de DBAs e na suas operações.

 

• O número de SGBDR, o número de base de dados associadas e a sua dimensão, o número de utilizadores, número de processos suportados e a sua tipologia, influência bastante o número de elementos necessário na equipa de DBAs. É necessário realizar manutenção, administração, validar cópias de segurança, produzir documentação, planear a melhoria contínua, garantir a disponibilidade e o desempenho das bases de dados, melhorar instruções de SQL.

 

• No caso das equipas de desenvolvimento não possuírem as competências suficientes no desenvolvimento de instruções de SQL complexo, é necessário que existe essa competência no seio da equipa de DBA para melhorar o desempenho das instruções de SQL.

 

Como alguém já disse é só fazer a conta e obtêm o resultado, neste caso o número de elementos das equipas de DBAs (DBA BOX).

João Paulino

Institucionalizar o BRIEFING/DEBRIEFING e “VOO de cadeira” nas operações da DBA BOX

BRIEFING/DEBRIEFING e “VOO de cadeira” são termos oriundo do meio aeronáutico, como conhecedor do meio, com muito agrado os acolho no meio informático. É importante que não sejam utilizados em vão nas TI’s.

O BRIEFING é uma reunião de informação táctica antecedente à partida para uma missão aérea na qual participam os PILOTOS AVIADORES, onde é explicado o conteúdo da missão, as manobras a realizar e os objectivos a atingir.

O DEBRIEFING é uma reunião em que participam os PILOTOS AVIADORES após a missão aérea, onde são analisados e aferidos os resultados da missão, respectivas manobras e se detectam os aspectos a serem especificamente melhorados.

O “VOO de cadeira” é um treino de preparação onde os PILOTOS AVIADORES simulam todas a manobras e movimentos que vão executar na missão, como se de um voo real se tratasse.

Para assegurar uma elevada proficiência nas suas intervenções as DBA BOX, tal como os PILOTOS AVIADORES asseguram nas suas missões, aquelas devem realizar BRIEFING/DEBRIEFING e “VOO de cadeira“.

O “VOO de cadeira” será um treino de preparação onde o elemento ou os elementos da DBA BOX simulam em ambiente de teste, todos os passos das acções a realizar num ambiente de produção de base de dados.

O BRIEFING será a reunião, onde são alinhados os pormenores da intervenção, revisto o plano e os seus objectivos.

O DEBRIEFING é uma reunião, onde são analisados e aferidos os resultados da intervenção, respectivas acções e se detectam os aspectos a serem melhorados.

No meio militar a falha tem um preço muito alto, falhar ou não, pode ser a diferença entre a vida e morte.

João Paulino

2009 é o ano da DBA BOX Agile

Este ano de 2009 é derradeiro no que respeita à transição das DBA BOXs para uma metodologia “Agile” e alinhamento com ITSM, regidas pelas recomendações do ITIL.

A atitude egocêntrica, desalinhada e reactiva que cerca de 90% das DBA BOXs que prestam apoio de administração e manutenção de base de dados em Portugal, é uma das causas, senão a maior de problemas e incidentes, que acontecem em base de dados.

É completamente errada a postura de dificultar os processos de negócio do cliente, de ser resistente a mudanças. Assiste-se a comportamento errados na demora de realizar tarefas/acções com elevado grau de maturidade com o intuito do cliente sentir na pele a necessidade e dependência que têm da DBA BOX. A ausência de análise e gestão de risco na maioria das acções realizadas, falta de planos de continuidade são exemplos da fraca qualidade na tentativa de prestar um serviço.

Ainda pior é a forma de agir em “Cartel” que algumas DBA BOXs apresentam. Não é nada raro o cliente saber que um dos seus sistemas apresenta lentidão, proceder à detecção da causa, ser informado pelos administradores de sistema que os HOSTs que suportam as base de dados se encontram com carga elevada (seja CPU ou I/O) e quando a DBA BOX é contactada, informa que não há qualquer lentidão ou carga nas bases de dados. Neste tipo de BDA BOX não existe responsabilidade, idoneidade, proficiência, enfim reina a falta de profissionalismo. Quem não sabe é como quem não vê, quantas vezes a DBA BOX não tem sequer a percepção real do seu comportamento e as consequências nos processos do cliente e do seu negócio.

Afaste os seus sistemas de base de dados deste tipo de DBA BOXs e fuja deles como o diabo foge da cruz.

A DBA BOX não é mais uma ilha isolada no IT, onde ninguém consegue aceder, para onde as comunicações são difíceis e os seus habitantes são hostis e não colaborativos.

É necessário criar pontos de comunicação e acesso à ilha da DBA BOX, alinha-la com metodologias Agile e regê-la pelas recomendações do ITIL apoiada por ITSM. É um enorme passo no sentido de fazer com que seja proficiente, responsável, proactiva, colaborativa e alinhada com o seu cliente.  É forma correcta de obter, gerir e melhorar o nível e qualidade esperada do serviço.

 

João Paulino

A Crise e o seu reflexo na DBA BOX

A Crise e o seu reflexo na DBA BOX

Como resultado da actual crise ou por simples falta de recursos humanos e ainda sobre o capa da redução de custo a que os departamentos de TI se encontram sujeitos, estes recorrem a préstimos de DBA BOX externas. Não me parece uma opção descabida, no entanto há que ter cautela, e porquê? Bom, vou tentar explicar e abordando as diferentes vertentes na gestão de serviços da DBA BOX associada a práticas “ITSM/ITIL” e metodologias “Agile”.

Será que os elementos da DBA BOX são suficientes para trocar a sua lâmpada?

O que quero perguntar é se DBA BOX possui recursos suficientes para garantir a correcta e eficiente administração e manutenção do conjunto de base de dados a seu cargo, e nos sistemas considerados críticos uma disponibilidade operacional contínua numa base 24 X 7.

Quais as normas, e processos que a DBA BOX está sujeita e deve cumprir?

Qual é a garantia que são cumpridos todos os procedimentos, que as cópias de segurança são fiáveis e encontram-se em condições de serem utilizadas, as regras de segurança, confidencialidade estão a ser contempladas?

Os dados mais críticos e sensíveis estão a salvo de acções de má fé ou de espionagem?

Qual o método e métricas de avaliação de desempenho de cada elemento da DBA BOX?

A qualquer momento sabe-se quem é o recurso responsável por determinada intervenção? Ou estão encapsulados na DBA BOX? Recursos eficazes, correctos e com brio profissional têm nome e constroem um portfólio.

Quem é que controla, verifica e auditas as acções da DBA BOX?

Cerca de 75% dos problemas com base de dados são originados por erro humano. Uma parte por negligência ou desleixo, mas a maioria por falta de proficiência. As coisas más acontecem, e acontecem de um modo muito fácil e rápido!

Além de prometer que se fornece um nível de serviço da DBA BOX, é necessário garantir e efectivar essa promessa. Para se alcançar esse objectivo é necessário gerir a DBA BOX de forma alinhada com as necessidades e perspectiva do cliente em deternimento do tecnológico. Reduzir os custos e entregar valor ao negócio, migrar de uma prática de perspectiva tecnológica para uma prática de serviço.

É imprescindível retribuir condignamente o cumprimento dos requisitos e expectativas do cliente e do seu negócio ao nível da qualidade do serviço da DBA BOX, aquele deverá ser capaz de avaliar e mesurar a contribuição do serviço da DBA BOX na cadeia de valor do seu negócio. Para obter essa métrica deve-se colocar o cliente a participar na avaliação contínua e no entendimento do serviço da DBA BOX e as suas expectativas futuras do mesmo e preparação para os desafios empresariais do cliente.

O objectivo do PCDA ou ciclo de Deming é tornar claros e ágeis os processos envolvidos na gestão, neste caso na gestão de qualidade do serviço da DBA BOX e divide-se em quatro passos:

 - Planear

 - Executar

 - Verificar

 - Agir

 Fase 1. Planear (PLAN)

Esta fase é desenvolvida tendo como base as necessidades e orientações do cliente e do seu negócio. Quando é iniciada esta fase deve ter em consideração 3 pontos importantes:

                – Determinar os objectivos, incidindo nos itens de controlo.        

                – Estabelecer e o percurso para atingir os objectivos.

                – Seleccionar pelos métodos a utilizar para alcançar os objectivos.

Após decidir os objectivos, recorre-se a uma metodologia correcta para alcançar os resultados pretendidos.

Fase 2. Executar o Plano(DO)

                – Treinar para alcançar a proficiência na metodologia a ser utilizada.

                – Executar o processo cumprindo o método.

                – Recolher a informação pertinente para verificação e validação do processo.

As tarefas devem ser executadas exactamente e cumprindo os planos.

Fase 3. Verificar os resultados do Plano Executado (CHECK)

                – É durante esta fase que são validados os processos e avalia-se os resultados obtidos:

                – Verificar se as acções foram realizadas de acordo com o padrão.

                – Comparar os valores/resultados com o padrão/norma/boas práticas.

Aferir se os itens de controlo correspondem aos dos objectivos.

 

Fase 4. Realizar acções correctivas ao Plano Executado e Verificado(ACT)

                – Estas acções devem ser baseadas nos resultados da fase 3.

                – Se os resultados se desviarem do padrão, iniciar as acções necessárias para os corrigir.

                – Caso se encontrem fora do padrão, deve-se investigar a causa ou origem e providenciar acções de prevenção e correcção.

Melhorar de forma continuada o processo de trabalho e o método.

A DBA BOX Ágil encontra-se envolvida e comprometida com a segurança, disponibilidade, confidencialidade, evolução e comportamento dos dados numa ou várias Base de Dados. Para além das competências técnicas tradicionais de administração, programação, modelação de dados, realização de testes, etc, deverá possuir conhecimentos sobre os processos de software, bem como competências que lhe permitam uma colaboração efectiva com profissionais de outras BOX’s, por exemplo: equipas de desenvolvimento, arquitectos e engenheiros de  Base de Dados, para esta colaboração a DBA BOX deverá possuir conhecimentos gerais de OOP, UML entre outras. A acção da DBA BOX deverá ser evolutiva e interactiva e tem que adaptar-se ao modernos processos de desenvolvimento (i.e.: Unified Process  ou XP).

 

João Paulino

Database Architect 

Livro sobre as melhores práticas no redimensionamento e melhoramento da MS SQL Server BOX

Este é um dos projectos que tenho para este segundo semestre, o outro ainda é segredo provavelmente sobre o outro SGBDR, mas mais prático. Estes dois projectos serão de livre distribuição e em formato electrónico. Aliás a estruração e planificação dos mesmos manteram-me afastado da “lides” bloguistas.

João Paulino

Nota: Projecto alterado, aguardem as novidades!!!

João Paulino

Database Architect/Arquitecto de Base de Dados

 É o profissional especialista de TI que produz, define, analisa, desenha, recomenda as características, funcionalidades, requisito(s) da(s) Base(s) de Dados relativamente à arquitectura do(s) sistema(s) e da arquitectura do software.

 Responsabilidades, características, especialização, formação e tarefas do Arquitecto de Base de Dados.

• 1. Analisar e compreender de forma relevante;
  • 1.1.1. Especificações dos requisitos.
  • 1.1.2. Convenções.
  • 1.1.3. Documentação de Administração dos produtores de SGBDR’s.
• 2. Arquitectura de Base de Dados;
  • 2.1.1. Avaliar requisitos de relevância/impacto sobre as Bases de Dados.
  • 2.1.2. Realizar o planeamento de capacidade das Bases de Dados.
  • 2.1.3. Assegurar que a arquitectura do sistema e do software abordam devidamente a persistência.
  • 2.1.4. Determinar a tecnologia de Dados adequada (i.e., relacional ou objecto)
  • 2.1.5. Avaliar e seleccionar os SGBDR’s a serem incorporados nas aplicações de software.
  • 2.1.6. Determinar onde as Bases de Dados serão disponibilizadas em sistemas de aplicações distribuídas multi-camadas (i.e., Bases de Dados Relacionais em Servidores Dedicados de Base de Dados, Base de Dados de Objectos na middle tier e Base de Dados Relacionais na camada de backend da infrastrutura).
  • 2.1.7. Avaliar e seleccionar correctamente e de modo apropriado os equipamentos de armazenamento (NAS, DAS, SAN e Robot’s de Tape para Backup).
  • 2.1.8. Produzir os modelos lógicos para as Bases de Dados.
  • 2.1.9. Determinar se o software de acesso à Base de Dados necessita modificações.
  • 2.1.10. Colaborar com outros profissionais para determinar:
    • 2.1.10.1. O impacto das alterações da Base de Dados nos outros sistemas.
    • 2.1.10.2. O custo ao nível de recursos humanos para alteração nas Base de Dados.
  • 2.1.11. Especifica as autorizações dos utilizadores:
    • 2.1.11.1. Quais os utilizadores que acedem a determinada Base de Dados.
    • 2.1.11.2. A que Dados os utilizadores acedem em determinada Base de Dados.
  • 2.1.12. O nível de acesso aos Dados (i.e., create, select, update, delete)
  • 2.1.13. Avaliar de forma adequada a plataforma que suporta as Base de Dados.
  • 2.1.14. Providenciar/Normalizar modelos de código fonte:
    • 2.1.14.1. Acesso a Base de Dados.
    • 2.1.14.2. Stored Procedures, Views, Functions, Triggers.
  • 2.1.15. Produzir os itens relacionados com a Base de Dados nas áreas do desenvolvimento/implantação e operações:
    • 2.1.15.1. Plano de Implantação.
    • 2.1.15.2. Manual de Instalação.
    • 2.1.15.3. Manual de Operações.

Perfil

Para cumprir esta função, o profissional Arquitecto de Base de Dados deverá possuir as seguintes características pessoais, conhecimentos técnicos, formação e experiência.

• 1. Características pessoais;
  • 1.1.1. Pensamento lato e abstracto que permita:
    • 1.1.1.1. Trabalhar confortavelmente e estrategicamente num alto nível de abstracção
    • 1.1.1.2. Ter uma visão geral sem pormenores supérfluos.
    • 1.1.1.3. Ter uma visão para além dos evidentes problemas e possíveis conexões entre os mesmo que pareçam não estar relacionados.
    • 1.1.1.4. Capacidade de reconhecer questões essenciais subjacentes a situações complexas.
  • 1.1.2. Capacidade de realizar e aplicar a engenharia nas seguintes situações:
    • 1.1.2.1. Requisitos que provoquem conflitos significativos na arquitectura.
    • 1.1.2.2. Decisões que envolvam competição por persistência, especialmente as Bases de Dados.
  • 1.1.3. Capacidade de identificar requisitos arquitectónicos e suas ramificações na arquitectura das Base de Dados.
  • 1.1.4. Capacidade de captar de uma forma clara e inequívoca o contexto da aplicação e da arquitectura do sistema, em particular base de dados herdadas.
  • 1.1.5. Capacidade de estimar e projectar a actual e futura dimensão:
    • 1.1.5.1. Da Base de Dados (i.e., média e número máximo de tabelas/classes e registos/objectos).
    • 1.1.5.2. Hardware necessário (i.e., número e dimensão dos servidores de Base de Dados, Discos de Storage e Sistemas de Backup)
  • 1.1.6. Capacidade de realizar confortavelmente tarefas de arquitectura em simultâneo.
  • 1.1.7. Capacidade de tomar importantes decisões, mesmo com informação incompleta ou em conflito.
  • 1.1.8. Alta capacidade de gerir e prioritizar os múltiplos desafios em simultâneo e concorrentes, tais como: questões, ambiguidades e contradições que são normais ocorrerem durante o processo de desenho e arquitectura das Base de Dados.
  • 1.1.9. Capacidades consolidadas na análise e resolução de problemas.
  • 1.1.10. Excelentes capacidades de comunicação verbais e escritas, capacidade de explicar e documentar a arquitectura da Base de Dados a diversas audiências
  • 1.1.11. Sólidas competências de construção e motivação de equipas.
• 2. Especialização;
  • 2.1.1. Conhecimentos aprofundados e práticos:
    • 2.1.1.1. Tarefas, técnicas e ferramentas de arquitectura de Base de Dados.
    • 2.1.1.2. Modelação lógica e física de Dados.
    • 2.1.1.3. Teoria de modelação de Base de Dados, incluí normalização de dados, replicação de dados, integridade de dados e segurança de dados.
    • 2.1.1.4. Desenvolvimento baseado em componentes, conceitos, modelos, infra-estrutura e interfaces.
    • 2.1.1.5. Tecnologias de infra-estrutura e de integração de sistemas utilizadas para implementar as arquitecturas de sistemas, conhecimento dos fabricantes e produtos disponíveis.
    • 2.1.1.6. Como desenvolver e implementar arquitecturas para aplicações distribuídas e acedida por várias plataformas heterogéneas.
    • 2.1.1.7. Conceitos de Object-oriented (OO), como Abstracção, Encapsulação, Herança e polimorfismo.
    • 2.1.1.8. Linguagens de Modulação (i.e., UML, OML, Modelação E-R, ) incluído a capacidade de produzir e interpretar os documentos e diagramas associados.
    • 2.1.1.9. Ferramentas de modelação de Base de Dados.
    • 2.1.1.10. Standards e orientações gerais de Arquitectura.
  • 2.1.2. Sólidos conhecimentos:
    • 2.1.2.1. Teóricos e práticos de ferramentas de Administração de Base de Dados.
    • 2.1.2.2. Principais padrões e mecanismos de persistência reutilizáveis.
    • 2.1.2.3. Modelos de arquitecturas de Base de Dados para aplicações específicas ou famílias de aplicações.
    • 2.1.2.4. Mecanismos de segurança das Base de Dados.
    • 2.1.2.5. Conceitos e técnicas de Engenharia.
    • 2.1.2.6. Objectos, casos de uso, processos e modelagem funcional.
    • 2.1.2.7. Arquitectura de Hardware e Software.
    • 2.1.2.8. Redes e equipamentos de rede.
    • 2.1.2.9. Conhecimentos teóricos e práticos de ferramentas de Engenharia de Software.
    • 2.1.2.10. Conhecimentos Básicos:
      • 2.1.2.10.1 Domínio da Aplicação.
      • 2.1.2.10.2 Negócio da Empresa cliente.
    • 2.1.2.11. Conhecimentos teóricos e práticos de ferramentas de testes e integração.
    • 2.1.2.12. Ferramentas de gestão de configurações, controlo de configurações.
• 3. Formação;
  • 3.1.1. Bacharelato, licenciatura ou outro ciclo superior de estudos em Engenharia Informática, Engenharia Informática e de Sistema, Engenharia de Sistemas e Informática, Engenharia Informática e de Computadores, Engenharia Electrotécnica e de Computadores, Informática, Matemática Informática ou equivalente.
  • 3.1.2. Formação Profissional dos fabricantes de SGBDR’s (i.e., Oracle, Microsoft, IBM, MySQL, etc.)
  • 3.1.3. Prática em:
    • 3.1.3.1. Projectos, tarefas relevantes, técnicas, produtos.
    • 3.1.3.2. Ferramentas, conceitos e diagramas de modelagem de Dados.
    • 3.1.3.3. SGBDR’s.
    • 3.1.3.4. Técnicas e Conceitos de Data Warehouse
    • 3.1.3.5. Auto-formação e actualização na leitura de livros, revistas e artigos da especialidade.
• 4. Tarefas;
  • 4.1.1. Arquitectura de persistência e Base de Dados:
    • 4.1.1.1. Seleccionar os padrões da Arquitectura.
    • 4.1.1.2. Concepção da Arquitectura lógica.
    • 4.1.1.3. Concepção da Arquitectura Física.
    • 4.1.1.4. Concepção do Mecanismo da Arquitectura.
    • 4.1.1.5. Reutilização da Arquitectura
    • 4.1.1.6. Documentação da Arquitectura.
    • 4.1.1.7. Garantia da Integridade da Arquitectura.
    • 4.1.1.8. Ambientes de Engenharia, incluí fornecedores SGBDR’s.
    • 4.1.1.9. Avaliação de SGBDR’s
    • 4.1.1.10. Selecção de SGBDR’s.
    • 4.1.1.11. Implementação;
      • 4.1.1.11.1. Planeamento da implementação.
  • 4.1.2. Operações;
  • 4.1.2.1. Documentação das Operações, incluí:
    • 4.1.2.1.1. Documentação incluindo operações: (tarefas operacionais de administração de Base de Dados, tarefas Operacionais, tarefas de instalação de Base de Dados e software associado).
  • 4.1.3. Engenharia da Qualidade;
    • 4.1.3.1. Controle de Qualidade – Avaliação de requisitos.
    • 4.1.3.2. Inspeccionar e avaliar o desenho da Base de Dados.
  • 4.1.4. Documento do design da Base de Dados.
  • 4.1.5. Componente de Software.
  • 4.1.6. Garantia de Qualidade – Auditoria do Desenvolvimento da Base de Dados.
  • 4.1.7. Técnicas, tarefas relacionadas com a Base de Dados.
  • 4.1.8. Standards, modelos, validação e verificação do documento de design da Base de Dados.

João Paulino

Change Data Capture (CDC) chegou ao MS SQL Server na Versão 2008

CDC (Change Data Capture) é uma das novas e interessantes funcionalidades que chegou ao SQL Server (alguns de nós já a conhecíamos do ORACLE), permite detectar alterações (INSERT, DELETE, UPDATE) relativamente aos dados de uma tabela e replicá-las noutra tabela, sem recorrer aos tradicionais triggers ou outras metodologias mais rebuscadas.

MS SQL Server 2008 CDC

 

 

Link

João Paulino

MS SQL Server versus Oracle Database, tão diferentes e ao mesmo tempo tão próximos (1.ª Parte)

Este artigo pretende alertar para o cumprimento de boas práticas ao nível de programação SQL nos seus dialectos T-SQL para o caso do MS SQL Server e PL/SQL para o caso do Oracle Database, independentemente do SGBDR, estas práticas têm elevadíssimos benefícios.

 

Boas práticas de codificação em SQL, são muitas vezes simplesmente ignoradas, mas originam imensos custos para o projecto, aplicação ou sistema e até para a organização.  

 

Na minha opinião, um Programador de SQL,  possuir esta qualidade ou mesmo habilidade é uma atitude orientada aos objectivos, alinhamento com as necessidades do cliente ou negócio, profissionalismo e um óptimo estilo de programação em SQL e seus dialectos.

 

E refiro-me concretamente, no caso do Oracle à utilização de BIND VARIABLES, são fundamentais para o desempenho de um sistema.

 

Para se entender melhor passarei a explicar.

 

Imagine uma aplicação que é alvo de milhares de instruções de SQL numa tabela de Base de Dados, como as apresentadas a seguir:

 

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10735;

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10840;

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor = 10987;

 

Cada vez que a consulta é executada, o SGBDR Oracle primeiro analisa a SHARED POOL (zona de memória) a verificar se a instrução de SQL já foi alguma vez executada. Caso tenha já tenha sido executada, o plano de execução utilizado na anterior instância é reutilizado, e a instrução de SQL é executada.

 

No caso da instrução de SQL não ser encontrada na SHARED POOL, o SGBDR Oracle terá executar o processo de “parsing” ou seja análise da instrução de SQL e posteriormente realizar o estudo dos vários planos de execução para encontrar o melhor plano de acordo com as suas parametrizações, antes de executar a instrução propriamente dita. Este processo denomina-se “HARD PARSE”, e para uma Base de Dados OLTP (Online Transaction Processing) poderá consumir mais tempo do que a própria instrução de SQL.

 

Quando é procurada na SHARED POOL a exacta correspondência de uma instrução de SQL, só instruções exactamente iguais são consideradas. Se como no exemplo das Instruções SQL acima colocadas, forem submetidas instruções  de SQL únicas, em que o predicado da cláusula WHERE é sempre diferente (id_fornecedor = 10735, id_fornecedor = 10840, etc.) nunca será encontrada uma correspondência e será necessário realizar um “HARD PARSE”. O “HARD PARSE” é muito intensivo na utilização de CPU e envolve operações de como “LATCH” de chaves nas áreas de memórias partilhadas. Esta situação poderá não originar problemas num sistema com poucos dados e pouco solicitado, mas num sistema com bastantes dados, multi-utilizador e com muitas transacções e muitas delas distribuídas, poderá simplesmente colocá-lo de rastos, com centenas ou milhares de instruções a necessitarem de ser analisadas “HARD PARSE” em simultâneo. Associado a esta situação surge um problema, a contenção que é o resultado dos inúmeros “HARD PARSE” realizados, o “HARD PARSE” é imune a medidas reactivas tais como aumento da memória física, incremento do n.º de CPU’s e muitas outras mediadas de reacção. O “HARD PARSE” é um problema encontrado em muitos sistemas e aplicações empresariais.

 

A solução para este problema é a reutilização dos planos de execução, e esta pode ser alcançada recorrendo a “BIND VARIABLES”. As “BIND VARIABLES” não são mais nem menos do que variáveis de substituição que são colocadas nas posições dos literais (10735, 10840, 10987). Exemplo da mesma instrução, desta vez recorrendo a “BIND VARIABLE”:

 

SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;

 

Exemplo de SQL PLUS

 

SQL> variable fornecedor_numero number

SQL> exec :fornecedor_numero := 10987

SQL> SELECT u_nome, p_nome, c_postal FROM t_fornecedor WHERE id_fornecedor =: fornecedor_numero;

 

É muito fácil implementar a utilização de “BIND VARIABLES” em Java, C++ C# ou mesmo em VB.net. E como disse no início este problema não é só para o SGDBR Oracle, acontece ao mesmo ao MS SQL Server ou qualquer outro SGDBR. O MS SQL Server e SQL Bind Parameters serão abordados na 2.ª parte.

 

Continua…

 

 João Paulino

Terminar com o SELECT COUNT(*) FROM schema_name.table_name

Esta simples instrução ( SELECT COUNT(*) FROM schema_name.table_name) para tabelas de pequena dimensão não tem grande impacto, mas para tabelas grandes é muito prejudicial ao desempenho. Recomendo vivamente que não o utilizem nestas situações, porque para obter o número de linhas é realizado um full table scan à tabela em questão.

Apresento aqui algumas alternativas:

SQL Server BOX

/*******************************************************************************/

SQL Server 2000 e 2005
SP_MSTABLESPACE ‘schema_name.table_name’;

SQL Server 2005
SELECT TOTAL_ROWS = SUM(P_ST.ROW_COUNT)
FROM   SYS.DM_DB_PARTITION_STATS P_ST
WHERE  OBJECT_NAME(OBJECT_ID) = ‘table_name’
AND (INDEX_ID < 2);

/*******************************************************************************/

Oracle BOX

/*******************************************************************************/

SELECT OWNER,
TABLE_NAME,
NUM_ROWS
FROM DBA_TABLES
WHERE TABLE_NAME = ‘table_name’
AND OWNER = ‘schema_name; 

/*******************************************************************************/

Nota:É imprescindível que as tabelas possuam estatísticas actualizadas. Senão não há alternativa ao SELECT COUNT(*) FROM schema_name.table_name ou seus derivados. Ou há SELECT COUNT(1) FROM FROM schema_name.table_name ou seus derivados, escolha um campo que seja índex e not null.

João Paulino

Oracle Data Guard versus Microsoft SQL Server 2005 Database Mirroring

Coloco aqui um link para um artigo, que de um modo mais ou menos imparcial ( É da Oracle) compara duas propostas de funcionalidades de ”High Availability” distintas, mas como finalidades semelhantes. http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardDatabaseMirroring.html

João Paulino