COBIT 4.1 Foudation – Governança Corporativa

COBIT (Control Objectives for Information and related Technology) – Governança Corporativa de TI
By José Eduardo Fiamengui Jr – Rumo a certificação COBIT
1-) Foco da Governança Corporativa
Alinhamento Estratégico – focado em assegurar a integração entre os planos estratégicos de negócios e de TI, na definição, manutenção e validação dos propósitos de TI, e no alinhamento das operações de TI com as operações corporativas.
Entrega de Valor – executando propostas de valor através de um ciclo de entrega, assegurando que as entregas de TI atendem aos benefícios estabelecidos na estratégia e, principalmente, na otimização dos custos, comprovando o valor essencial de TI.
Gerenciamento de Recursos – a otimização e gerenciamento dos investimentos nos recursos críticos de TI: processos, aplicações, infra-estrutura e informação. Principalmente relativo à otimização do conhecimento e da infra-estrutura.
Gerenciamento de Risco – requerido com uma consciência pelos executivos seniores da corporação, o entendimento claro da vontade da organização por risco, a transparência sobre o significado dos riscos para a corporação e as responsabilidades do gerenciamento de riscos.
Medição de Desempenho – rastrear e monitorar a implementação da estratégia, conclusão de projetos, utilização de recursos, execução dos processos e entrega de serviços, utilizando, por exemplo, “balanced scorecards” (BSC) que traduzam a estratégia em ações para atingir as metas mensuráveis, além da verificação convencional.

2-) Estrutura do COBIT
Cobit1Figura 1
Detalhando COBIT
3-) Critérios da Informação
Para atender aos objetivos de negócio da organização, a informação precisa seguir determinados critérios de controle, que são denominados como os critérios da informação. São dividos em 3 categorias: Qualidade, Segurança e Fiduciary.

Efetividade ou Eficácia (Qualidade): A informação entregue precisa ser relevante e pertinente, entregue em tempo, de maneira correta, para a pessoa correta, de forma consistente e utilizável.

Eficiência (Qualidade): A informação entregue deve fazer o melhor uso possível dos recursos da organização. Deve-se buscar a máxima produtividade com o menor custo.

Confidencialidade (Segurança): A informação deve ser protegida para evitar divulgação indevida e ser conhecida apenas pelas pessoas que possuem permissão para isso.

Integridade (Segurança): A informação precisa ser correta, completa e consistente.

Disponibilidade (Segurança): A informação deve estar disponível sempre que for necessária para o negócio.

Conformidade (Fiduciary): A informação deve estar de acordo com as leis, regulamentos e contratos que afetem o negócio de alguma forma. As regras internas da empresa também são consideradas.

Confiabilidade (Fiduciary): A informação entregue para a gerência deve ser confiável para a tomada de decisão negocial.
Resumindo, as informações precisam ter qualidade, ser seguras, atender às leis e precisam ser confiáveis.

4-) COBIT – Componentes
Framework:
 Faz um link entre a TI e o negócio
 Organiza os processos e atividades de TI em um modelo mundialmente aceito
 Identifica os maiores recursos de TI a serem gerenciados
 Defini os processos a serem implementados
 Ajuda a focar no processo mais importante

Objetivos de Controle (Processos):
 São os Processos a serem implementados:

Planejar e Organizar: cobre o uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e metas. Ele também salienta que a forma organizacional e a infraestrutura da TI devem ser consideradas para que se atinjam resultados ótimos e para que se gerem benefícios do seu uso.
Adquirir e implementar: cobre a identificação dos requisitos de TI, a aquisição de tecnologia e a implementação desta dentro dos processos de negócio da companhia. Esse domínio também lida com o desenvolvimento de um plano de manutenção que a companhia adota para prolongar a vida do sistema de TI e de seus componentes.

Entregar e Suportar: foca aspectos de entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como os processos de suporte que permitem a execução de forma eficiente e efetiva. Esses processos de suporte também incluem questões de segurança e treinamento.

Monitorar e Avaliar: lida com a estimativa estratégica das necessidades da companhia e avalia se o atual sistema de TI atinge os objetivos para os quais ele foi especificado e controla os requisitos para atender objetivos regulatórios. Ele também cobre as questões de estimativa, independentemente da efetividade do sistema de TI e sua capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos.
Management Guidelines
Define as entradas, atividades dos processos e saídas que cada processo irá gerar. Além disso, se preocupa em definir as responsabilidades de cada atividade do processo através da matriz RACI(Responsible, Accountable, Consulted e Informed). O COBIT é uma biblioteca voltada a indicadores, e as orientações de gerenciamento sugerem que para cada processo sejam criados indicadores de desempenho de TI e de negócio. O COBIT sugere indicadores de negócio, pois cada processo de TI existe para suportar um ou mais processos de negócio.

Estrutura de cada processo:
Processo

Cobit2

Modelos de Maturidade
E no final da descrição de cada processo há um modelo de avaliação de maturidade do processo, que é dividido:
Níveis
i) Inexistente (0): não se aplica processo de gestão
ii) Inicial (1): os processos são ad hoc e desorganizados
iii) Repetitivo mas intuitivo(2) (não documentado): os processos seguem um padrão definido
iv) Definido (3) (escrito e comunicado): processos documentados e comuicados
v) Gerenciado e Medido (4): Processos são monitorados e mensurados
vi) Otimizado (5): Melhores práticas são seguidas e automatizadas

Os modelos de maturidade são importantes para saber qual grau de maturidade de um dado processo na organização, além de se poder estabelecer através dele onde se quer chegar.

5-) COBIT – O Integrador
O COBIT não se preocupa em COMO IRÁ SER IMPLEMENTADO, e sim em, O QUE SERÁ IMPLEMENTADO.

Cobit3

Figura 2

Com isso é entram os demais frameworks como ITIL, ISO27001, entre outros, que se preocupam em como IMPLEMENTAR … . É um integrador de todos estes Frameworks.
6-) Conclusão:
Governança Corporativa: Instrumento do CIO para gerenciar a TI (Tecnologia da Informação) em organizações e base para a implementação da Governança Corporativa.
Principais Objetivos: Eliminar riscos e perdas e Agregar valor às organizações.
Principais Beneficios: TI mais transparente e Maiores orçamentos.

7-) Referencias Bibliográficas
[1] http://www.governancadeti.com/2010/08/uma-visao-geral-do-cobit/
[2] http://www.trainning.com.br/download/COBIT_41.pdf
[3] http://books.google.com.br/books?id=u4CiQmnBWucC&pg=PA7&lpg=PA7&dq=cobit+materials&source=bl&ots=I7zEDnLJdB&sig=XfErCBURHMeJAD-yX7wSflGW1Ns&hl=en&sa=X&ei=W5W0UJrJH5Lw8ASxxoH4Ag&ved=0CG8Q6AEwCDge#v=onepage&q=cobit%20materials&f=false

Publicado em Cobit | Publicar um comentário

Capacity Planning (Parte 2)

Capacity Planning (Continuação)

Agora que conhecemos a teoria para a realização de um projeto capacity planning, vamos analisar quais as métricas devem ser coletadas para cada camada que constitui o sistema computacional.
Primeiramente, temos que definir thresholds que indicam níveis de conforto satisfatórios, por exemplo 50 GB de redo diário. Ultrapassando esse nível, os tamanhos dos arquivos têm de ser reajustados para manter o tempo de leitura recomendado pelo Oracle (15 a 30 min).
Depois disso, será necessário colidir as métricas do Oracle com as métricas coletadas pelos outros componentes do sistema computacional. As métricas que devem ser coletadas são:
i) CPU: utilização, run-queue, context switches (voluntárias e involuntárias), interrupções, system calls;
ii) Storage: Número de IOPS/second, Queue Depth, Tamanho de IOPS, Tempo de resposta, throughput;
iii) Filesystem: crescimento e tempo de resposta;
iv) Memória: memória física consumida, swap in/out e Page faults;
v) Rede: Throughput e detalhes do netstat –s e kstat; e
vi) Servidor de aplicação (supondo IIS): time-taken, bytes-sent, bytes-received, status, cs-uri-stem, cs-uri-query, cs(cookie), cs(referrer).
Do monitoramento do servidor de aplicação, podemos retirar as informações plotadas na figura 4:

Figura4

As métricas que devem ser coletadas para uma análise detalhada do banco de dados:

  • Users (transactions, logons, parses);
  • Redo activity;
  • Temp activity;
  • Tablespace e espaço usado pelos objetos;
  • Pga usage;
  • Sga usage;
  • Parallel Operations;
  • I/O Operations; e
  • File Stats e Temp Stats.

Para Wait events:

Analisar os top waits events, events idle e parallel (PX*) waits (se houver), conforme pode ser visto na figura 5:

Figura5

 

A decomposição do tempo de resposta mostra que events idle e parallel não são significativos no dia analisado desta base. Então vamos detalhar rapidamente os principais wait events plotados na figura 5:

  • CPU: tempo gasto de CPU para processamento das operações
  • Db file scattered read: tempo gasto com leituras multiblocks
  • Db file seqüencial read: tempo gasto com leituras single-blocks
  • Buffer busy waits: este evento indica uma contenção (problema de lentidão) e análise deve ser aprofundada para que seja descoberta se esta contenção ocorre, por exemplo, em um bloco de índice ou de dados, ou até no header do bloco e para cada um destes casos há uma solução diferente que são melhor explicada através do metalink: Case Study: Buffer Busy Waits Issue [ID 358303.1].

Após a coleta de todas as métricas citadas acima deve se montar tabelas com a sumarização dos dados para cada servidor e BD monitorados e os thresholds definidos juntamente com a área de negócio.

Darei mais exemplos no próximo post de como fazer a correlação entre negócio e hardware.

 

Abraços

José Eduardo Fiamengui Jr

 

 

 

Publicado em Oracle | Publicar um comentário

Capacity Planning (parte 1)

Capacity Planning (Parte 1)

Por José Eduardo Fiamengui Jr

Publicação completa feita na revista SQL Magazine

É cada vez mais comum nas organizações de TI gerenciar, analisar e corrigir problemas de desempenho que os usuários relatam. No mundo perfeito, os administradores se preparam com antecedência a fim de evitar gargalos, utilizando-se do que chamamos de capacity planning. Esse tipo de projeto tem por objetivo determinar a capacidade de produção para responder a novas demandas, fornecendo níveis satisfatórios de serviços aos usuários e mantendo, assim, uma boa relação custo-benefício. Neste contexto, este artigo visa a detalhar teoricamente um projeto de capacity planning, bem como mostrar quais são e como coletar as métricas importantes para a realização desse tipo de projeto.

A Figura 1 mostra os três pilares fundamentais para a realização de um capacity planning.

Vamos, então, detalhar cada um desses pilares.

Determinar os níveis de serviços requeridos pelos usuários

O primeiro passo em projeto de capacity planning é categorizar o trabalho realizado pelo sistema e alinhar as expectativas dos usuários do modo como o trabalho é realizado.

Nessa fase, o capacity planning deve focar seus esforços em:

Who: quem realiza o trabalho (usuário ou departamento);

What: qual tipo de trabalho é realizado (relatório de finanças);

How: como o trabalho é realizado (rotina batch); e

Establish Service Levels: acordar um nível satisfatório entre service provider (provedor do serviço) e o service consumer (cliente). O service levels é frequentemente definido pela perspectiva do usuário, tipicamente em tempo de resposta e throughput.

O processo global de estabelecimento de requisitos em nível de serviço exige primeiro uma compreensão dos workloads (cargas de trabalho) e service que é a classificação lógica do trabalho realizado em um computador do sistema, como mostrado na Figura 2.

Figura 2

A partir deste entendimento inicial, como estabelecer os níveis de serviço?

Os níveis de serviço devem ser estabelecidos conforme as metas plausíveis para o negócio e, para tanto, será necessário conhecer, no mínimo:

Os processos de negócio envolvidos com determinado serviço;

A prioridade para o negócio do serviço;

O crescimento esperado da procura pelo serviço durante os próximos anos;

O pior tempo de resposta aceitável para o serviço; e

Sazonalidade do serviço.

Não são necessários acordos formais e assinados pela TI e a área de negócios, mas é recomendável garantir que ambas as partes recebam as informações supracitadas. Estabelecidos tais acordos, o Capacity poderá garantir um desempenho adequado a um custo mínimo.

Analisar a capacidade de processamento instalada

Devemos analisar a capacidade atual para que ela seja alinhada às expectativas de tempo de resposta dos usuários.

Nessa fase é necessário:

Comparar as medidas de todos os itens referenciados nos acordos de nível de serviço com seus objetivos, o que fornece a resposta sobre a capacidade atual estar ou não adequada ao que esperam os usuários;

Analisar o uso de todos os dispositivos envolvidos no sistema CPU, memória, dispositivo de I/O, banco de dados, servidor de aplicação, entre outros; e

Mensurar o tempo de resposta e a utilização de recursos para cada workload e determinar quais recursos do sistema estão sendo mais consumidos para cada workload.

Como mensurar o uso global de recursos?

É importante realizar o monitoramento de cada um dos recursos envolvidos no sistema computacional, verificando se algum deles está saturado (utilização próxima ou igual a 100%). Caso haja saturação, os workloads que utilizam tal recurso estarão susceptíveis a apresentar tempos piores de resposta. O tempo de resposta pode ser definido segundo a fórmula abaixo:

Tempo de Resposta = Tempo de Serviço + Tempo de Espera (Wait Events)

Por isso, mostra-se importante também o detalhamento de cada workload com relação aos recursos utilizados, refletido em algo semelhante à Figura 3. Por exemplo, imagine um comando ou processo que obtenha o relatório das apólices de seguro fechadas no último mês e um detalhamento de onde é gasto o tempo para completar este workload.

Figura 3

Dimensionar a capacidade necessária para atender os níveis de serviços atuais e futuros

Utilizando as previsões de crescimento do negócio e os requisitos do sistema, deve-se implementar as alterações necessárias para manter os mesmos níveis de serviço alinhados com as perspectivas de crescimento do negócio.

Nessa fase será necessário conhecer:

Crescimento esperado do negócio;

Requisitos para novas funcionalidades/aplicações; e

Consolidação dos itens acima com as métricas coletadas pelos dispositivos atuais.

Publicado em Uncategorized | Publicar um comentário

Itil – Gerenciamento de Serviços de TI

ITIL (Information Technology Infrastructure Library)

O Infra-estrutura de TI de hoje exige uma atenção maior na solicitação dos clientes, oferecendo soluções de qualidade e com pleno alinhamento com os objetivos de negócio, só assim o gerenciamento de serviços pode evoluir.

Vamos neste post explicar o que é ITIL e alguns passos para iniciar sua implementação:

O que é ITIL?

É uma metodologia amplamente adotada para Gerenciamento de Serviços de TI pelo mundo. Ela fornece um guia de melhores práticas para identificar, planejar, entregar e realizar suporte de serviços de TI agregando valor ao negócio.

Processos ITIL:

Suporte:
Gerenciamento de Incidentes
Gerenciamento de Problemas
Gestão da Mudança
Gerenciamento da Configuração
Gerenciamento de Liberação

Entrega:
Gerenciamento da Capacidade
Gestão Financeira
Gerenciamento de Disponibilidade
Gerenciamento de Nível de Serviço
Gerenciamento da Continuidade do Serviço

Para iniciar a implementação do ITIL, podemos utilizar o The Office of Government Commerce (OGC), proprietária do ITIL, fornece recursos online que podem avaliar a IT Organization e fornecer diversos materiais para download no Website (http://www.itil.co.uk/online_ordering/online_ordering.htm).

Como iniciar a implementação:

Determinar Objetivos: depois de saber como a organização está, alinhe com seus superiores até que ponto eles querem chegar com a implementação das melhores práticas do ITIL. Pode se usar uma estrutura de maturidade para marcar resultados da avaliação e determinar o nível que sua organização tentará alcançar. A pontuação pode variar de 0 a 5, onde zero indica ausência e 5 indica otimização. Pode se ter a idéia que todos os níveis de serviço estejam em 5 (otimização), no entanto isso pode ter um custo muito elevado.

Avaliar Gaps: verificar as lacunas existentes entre “Onde estamos” e “Onde queremos chegar”.

Foco no processo: depois de analisarmos as lacunas, temos que determinar qual processo deve ser focado e isso pode ser uma tarefa árdua. Minha recomendação para esse caso é com o Gerenciamento de Incidentes não chegou a um estado CONTROLADO (nível 3), o correto seria começar por lá, o Gerenciamento de Incidentes é um processo fundamental que muitos outros irão depender, pois seu objetivo é restaurar a operação normal o mais rápido possível para os clientes.

Iniciar o projeto: Iniciar um plano de projeto mostrando como a TI mudará seus processos e como isso será implementado e efetivamente implementá-lo. Durante essa fase você identificará as atividades que serão monitoradas e medidas. A seleção dessas atividades vai depender dos objetivos do negócio.

Medir: uma vez que o projeto já concluído e as alterações no processo de TI foram implementadas é hora de tirar as métricas, que o ITIL ajudou a identificar ao longo do processo. Exemplo:

Percetual (%) de redução no tempo para responder um chamado, Percentual (%) de stakeholders satisfeitos com o atendimento, entre outros. Dessa forma será possível prever se os objetivos do negócio serão atingidos.

Melhoria Contínua: nenhum processo é perfeito, então explicar, a organização a importância dos esforços de melhoria contínua. Como o processo é testado ao longo do tempo, os funcionários irão sugerir refinamentos adicionais.

A execução global das melhores práticas de ITIL não é algo que ocorrerá durante uma noite. A adoção dessas práticas exigirá uma mudança de cultura para a organização do seu cliente, além das mudanças previstas para os processos em si.

Publicado em Itil, Uncategorized | Publicar um comentário

Oracle Collections (Bulk)

By Oradeep: José Eduardo Fiamengui Júnior

O que é ?
Um tipo de cursor para retorno de dados. Com bulk collect, o PL/SQL engine conversa com o SQL engine para retornar muitas linhas a cada interação, reduzindo o número de interações e normalmente o tempo de resposta.
Até aqui encontramos em qualquer site, mas vamos ao como é processado isso tudo por dentro do Oracle:

Temos 2 engines diferentes dentro da memória do banco de dados para processamento dos SQLs (comandos).

Engine1: Bloco PL/SQL (Ifs, declares, whiles, var, etc…)

Engine2: Comando SQL (select, update, delete, insert), para o processamento de cada um dos comandos SQLs contidos no bloco PL/SQL é necessário uma interação entre os engines (vai SQL e volta DADO) e a partir daí todo o processamento do comando SQL (… PARSE, BIND, EXECUTE, FETCH), um maior detalhamento dessas fases foi feito no artigo STATISTICS.

Process: Convencional BINDS

 

Processamento(linha-a-linha)

Process: BULK COLLECT BINDS

Processamento(Bulk Collect)

Bulk Binds Collect fazem um código PL/SQL retorne muitas linhas de um cursor em apenas uma chamada ao invés de uma linha por vez. Esse tipo de código normalmente reduz o consumo de CPU e executa mais rapidamente, pois reduz leituras lógicas e tempo de processamento.

Bulks Collect utilizam a PGA para armazenar seus dados, e a PGA é alocada normalmente por sessão (Conexão Dedicada). Vários bulks executando ao mesmo podem ocasionar problemas de alto consumo de memória, por isso a opção LIMIT (limitando as linhas retornadas) DEVE ser utilizada pelos desenvolvedores.

Partindo para a prática, criei 2 cenários para teste:

a) Implementação de Inserção via Cursor Simples:

Implementação-CursorSimples

 

b) Implementação de Bulk Bind Collect:

Implementação-BulkCollect

Análise Comparativa entre os 2 processos: Trace

Utilizei para ambos os casos:
alter session set events ‘10046 trace name context forever, level 8’ ;
tkprof .trc .txt sys=no sort=fchela explain=teste/teste

a) Implementação (Cursor Simples)

Trace-CursorSimples

b) Implementação (Bulk Collect)

Trace-BulkCollect

 


Houve uma pequena variação na quantidade de linhas (9 linhas), pois as implementações foram feitas em dias diferentes e acredito que já tinha criado outros objetos em meu database. Ainda assim a conclusão que chegamos é bem clara: o tempo de resposta para essa quantidade de registros caí em aproximadamente 85%.
Uma diferença considerável e que aumentará, conforme o aumento na quantidade de registros processados.
Agora que entendemos um pouco mais sobre Collections vale lembrar que é possível utilizar esse recursos também com operações de DELETE e UPDATE.

Grande abraço a todos!, e como esse Post deve fechar o ano de 2011:

Gostaria de desejar um *** Feliz Natal e um Ano Novo repleto de realizações ***

Publicado em Oracle | 2 Comentários

Oracle RAC

Vamos aproveitar esse post para escrever de um tema bem atual: Oracle RAC. O objetivo aqui é tratar alguns novos conceitos e analisarmos algumas diferenças entre uma single instance.

Arquitetura:

Arquitetura Oracle Rac

Novos componentes:
Oracle Clusteware: realiza serviços básicos no nível do sistema operacional que permitem que software Oracle rode em modo de clustering, componente essencial para a instalação do Oracle Rac
Voting Disk: é uma partição de disco compartilhada entre os nós do RAC onde pode ser verificar os membros da estrutura e seu status
OCR: registro das informações dos membros: Vip Address, service, database, asm, entre outros

Instância:

Instance

Novos componentes:

Cache Fusion: mecanismo que garante a coerência entre os caches, realiza a transferência dos blocos da holding instance para request instance
Cluster Private High Speed Network: Interconnect
Global enqueue service: coordena o acesso aos blocos de dados dos nós garantindo a coerência
Global cache service: processo que implementa o Cache Fusion
LMD: gerenciam a requisições de acesso aos blocos e deadlocks
LMON: gerenciam a queda das instância e recuperação no caso de falha
LMSx: gerenciam a quantidade de mensagens remotas
 
Contenção de DMLs, Querys e Serialização
 
DMLs e Querys intensivas num pequeno conjunto de blocos
 

GC Buffer Busy

Conseqüência

Re-masterização de blocos via interconnect entre os nós ocasionando lentidão
 

Solução

Módulos que utilizem tabelas diferentes podem ser configurados para entrada em apenas uma das instâncias (configuração de failover no listener) / configuração de serviços

Sequences

CACHE or NO CACHE

Quando no cache é utilizado o dicionário de dados tem que ser atualizado com a requisição NEXTVAL. Isso significa que o row cache gerar um lock com essa requisição. Múltiplas sessões requisitando um nextval gera o wait event “row cache lock”.

Quando cache + ordering são utilizados e o parâmetro cluster_database = true,  a sessão requer um NEXTVAL é necessário conseguir um lock exclusivo na shared pool para obter o valor. Quando múltiplas requisitam o mesmo valor o wait event gerado é ‘DFS lock Handle’ também uma contenção, que pode ser resolvida por exemplo aumentando o valor de cache.

 

A configuração que gera menor impacto em termos de performance é:

 

CACHE e NOORDER (default)

Essa configuração tem menor impacto de performance no RAC, cada instance armazena um número diferente no cache e não serão globalmente ordenadas, gerando gaps

 

Gaps em seqüences sempre são possíveis, quando ocorre falha e/ou rollback de transações!

Best Practises

Algumas boas práticas, porém de qualquer forma recomendo a leitura das notes elencadas ao final do artigo pois há muito mais que isso:

Designer

Eliminar qualquer ponto de falha na arquitetura

Exemplo: Incluir Cluster Interconnect Redundancy (NIC bonding), múltiplos paths no storage, utilizando 2 HBAs, Disk mirroring / Raid

ASM fortemente recomendado para a versão 10g e obrigatório na versão 11g

 

Network

Switch (ou redundante switches) são necessários e altamente recomendados para private network (crossover cables não são suportados). Se utilizarem uma VLAN deverá ser configurada 1:1 para evitar congestionamentos. (Vlan Settings: 9761210).
Vips e Scan Vips (Recomendável a partir de 11gR2) devem ser o mesmo na sub-rede e na interface pública
As interfaces de rede devem ter o mesmo nome em todos os nós (eth1 -> eth1 suporta o Vip e eth2 -> suporte a interface privada)

 

Storage

Utilizar múltiplas HBAs
Assegurar a utilização de discos NFS juntamente com ASM
No mínimo 4 LUNs de mesmo tamanho em tamanho e desempenho (Cada LUN em um Raid Grupo separado)
Apenas 2 diskgroups são necessários (ASM) um para flash recovery area e o outro para área de dados
Criar uma retundância externa
 

Cluster e Grid Infra-estrutura

Recomenda-se utilização de RAW ou Block Devices na área dos voting disks
Se a versão do BD é 11.2.0.2 pode se utilizar NIC retundancy para o interconnect

Note: 1210883.1

 

Instalação

Verificar os pré-requisitos do Cluster com o utilitário cluvfy
Instalar o ASM em paths diferentes do Oracle Home, garantindo disponibilidade e facilidade para realização de upgrades

 

 Notes Interessantes:

RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent) [ID 810394.1]
Where Should the CRS Home be Placed? [ID 549196.1]
When Starting the Database with Srvctl [ID 749515.1]
Transactional Sequences in Applications in a RAC environment [ID 561414.1]
RAC and Sequences [ID 853652.1]

 

Publicado em Oracle | Publicar um comentário

Oracle índices

Oracle – Entendendo um pouco mais sobre índices

Os índices certamente não resolverão todos os seus problemas de desempenho, mas se bem utilizados são de grande ajuda para a busca de dados de forma eficiente. Aliás criar índices para variadas colunas, sem visualizar a Clausula WHERE e a Seletividade não é uma boa tática, mas isso é tema para outros posts. Vamos tentar quebrar alguns paradigmas sobre índices, são eles:

a)      Com o tempo, índices se tornam desbalanceados e, com isso, requerem uma reconstrução (rebuild) para um bom desempenho

b)      Índices com valores sempre crescente ou monôtonico (nunca diminuem ex.: Sequences) tendem a piorar sua performance com o passar do tempo, pois precisam de “re-balanceamento”

Um pouco da estrutura de um índice B*Tree:

  • Leaf Nodes: contêm entradas que se referem diretamente as linhas das tabelas;
  • Branch Nodes: contêm entradas que se referem a “Leaf Nodes”; e
  • Um único Root Node: que é um “Ramo” , o topo da estrutura da árvore

O número de entradas em um “Branch Block” é determinado em parte pelo DB_BLOCK_SIZE, bem como o comprimento dos valores dos dados. Cada entrada em um “Leaf Block” consiste em linhas com 2 colunas. A primeira coluna é o valor do dado propriamente dito e a segunda coluna é o ROWID.

O ROWID (“endereço” físico do dado) que é uma pseudo-coluna de cada tabela de seu database e contêm as seguintes informações:

Partes do ROWID Significado
AAADVH (até 6º caracter) Segmento
AAE (3 caracteres seqüentes) Datafile@tablespace
AAAADk (6 caracteres sequentes)  Block@datafile
AAA (3 últimos caracteres) Número de linhas no bloco

 Há diversos tipos de índices: Bitmap, Reverse Keys, Function Based Index, Index Descending … . Cada um desses tem características diferentes e cada um deles apresenta ganhos de desempenho com um tipo de acesso aos dados. Já perceberam que para fazer um post completo sobre índices seria uma leitura muito, muito, muito extensa e provavelmente ainda faltaria muitas coisas. Mas vamos continuar com os pontos mais importantes:

O Blevel é considerado por alguns DBAs como um balizador para um Index Rebuild! O Blevel é o número de níveis que o índice tem gerado. Mesmo para índices muito grande, ele dificilmente será superior a 4. Cada Blevel representa um I/O adicional que deve ser realizado na árvore do índice!

Voltando ao assunto sobre o Rebuild relacionado ao Blevel, se você tem um índice com crescimento monotônico (uma chave que é uma sequência que só aumenta e nunca diminui), e as entradas são deletadas, porém nunca são re-utilizadas, um rebuild PODE SER útil e o Blevel aqui poderia ser um indicador, mas a análise não pode basear-se apenas nesse número. Tomas Kytes tem grandes discussões sobre esse tema, uma delas, pode ser acompanhada por: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112#43555424746793.

A perda de performance, não ocorre porque o índice fica “desbalanceado”, pois o balanceamento é realizado conforme a inserção de dados. A perda de performance, pode ocorrer porque o índice se torna mais espaçado, com mais blocos livres. Na maioria das vezes esse problema ocorre devido a exclusões de linhas o que resulta em entradas de índices não re-utilizadas.

Algumas notas da própria Oracle com o objetivo de encontrarmos quais indices devem ser rebuildados(Script: Lists All Indexes that Benefit from a Rebuild [ID 122008.1] ), ( Index Rebuild, the Need vs the Implications [ID 989093.1] ) e ( Script to investigate a b-tree index structure [ID 989186.1] ).

A solução após as devidas análises e caso chegue-se a conclusão de que a performance (diminuição de blocos lidos em SQLs) ou o ganho em termos de espaço em disco irão compensar a janela de manutenção para o rebuild …. mãos a obra!!!!

Bom artigos sobre rebuild podem ser encontrados em www.dbazine.com e procurem artigos de performance sobre o assunto de autoria de Jonathan Lewis, alguns deles: Unbalaced Indexes? ( www.dbazine.com/jlewis13.shtml ) e When should you rebuild an index? ( www.dbazine.com/jlewis14.shtml ).

Índice é um assunto muito interessante e muito vasto! Por isso e para falarmos de outras métricas interessantes que influenciam o otimizador a utilizar ou não um determinado índice, precisaremos de muitos e muitos posts. Ao longo do post, espero ter quebrado os dois mitos citado no início desse. 

Abraços espero ter ajudado a entenderem um pouco sobre índices. 

By José Eduardo Fiamengui Júnior

Publicado em Oracle | Publicar um comentário