Framework Scrum

Objetivo:

O objetivo deste breve artigo é descrever um pouco do Scrum e dar algumas dicas para quem está se preparando para a certificação Scrum Master (PSM1).

Framework SCRUM

O framework Scrum é um conjunto de valores, princípios e práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa.

O Scrum foi desenvolvido para que seja utilizado em qualquer projeto de TI. Ele aproxima áreas de negócio e time de desenvolvimento, e desta forma, a expectativa é que os softwares produzidos atendam as expectativas dos usuários.

O Framework Scrum é baseado em Papéis, Eventos e Artefatos, explicados abaixo:

Scrum

Scrum

Papéis (Scrum Team)

Product owner: é o ponto central com poderes de liderança sobre o produto. Ele é o único responsável por decidir quais recursos e funcionalidades serão construídos e qual a ordem que devem ser feitos.
Scrum master: é responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum. Age como um Coach, executando a liderança do processo e ajudando a equipe Scrum (e o resto da organização) a desenvolver sua própria abordagem do Scrum, que tenha a melhor performance, respeitando as particularidades da organização. O Scrum master também tem um papel de facilitador. Ele deve ajudar a equipe a resolver problemas e fazer melhorias no uso do Scrum. Ele também é responsável por proteger a equipe contra interferências externas e assume um papel de liderança na remoção de impedimentos que podem atrapalhar a produtividade.
Development Team: é simplesmente a junção de todas as pessoas que trabalham no processo e desenvolvimento de Software (Arquiteto, Testers, Analista de Requisitos, Desenvolvedores, …) na metodologia tradicional em uma equipe multidisciplinar, e que são responsáveis pela concepção, construção e testes do produto.A equipe deve ser auto-organizada e auto- conduzida, normalmente possui entre 4 e 9 pessoas.
Eventos

Sprint planning: O product backlog pode representar muitas semanas ou até meses de trabalho, o que é muito mais do que pode ser concluído em um único sprint. Para determinar quais os subconjuntos de itens do Product Backlog mais importantes para construir no próximo sprint, o product owner, junto com o Scrum master e Development team devem realizar o Sprint Planning. A duração de um Sprint Planning é entre 4 e 8 horas considerando uma Sprint de 1 mês.
Daily scrum: Todos os dias, idealmente no mesmo horário e preferencialmente mesmo local, os membros da equipe de desenvolvimento devem realizar uma reunião com tempo definido (15 minutos ou menos), chamado Daily Scrum. Também conhecida como StandUp Meeting.
Sprint retrospective: tem como objetivo verificar necessidades de adaptações no processo de trabalho.
Sprint: são iterações ou ciclos de até um mês. O trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente. Sprints são timeboxed(duração fixa) para que tenham sempre um início e fim data fixa, e, geralmente, todos eles devem estar com a mesma duração.
Sprint review: realizada ao final da Sprint e tem como objetivo verificar e adaptar o produto que está sendo construído.Trata-se da apresentação do produto desenvolvido aos Stakeholders.
Artefatos

Product backlog: é um documento que está constantemente evoluindo. Os itens podem ser adicionados, excluídos e revisto pelo Product Owner por conta de mudanças nas condições de negócios, ou conforme a compreensão da equipe Scrum sobre o produto aumenta. O product owner e os stakeholders são responsáveis pela priorização do Product backlog.
Sprint backlog: contém todo o trabalho que será executado em uma Sprint.
Definition of done: A DoD é um acordo formal doScrumTeam que define claramente quais são os passos mínimos para a conclusão de um item potencialmente entregável. Serve como um contrato entre o ScrumTeam e o Product Owner, garantindo que todo o produto gerado pelo projeto estará dentro dos padrões de qualidade estabelecidos entre eles. É uma forma de se buscar a excelência, especialmente em um cenário multi-iterativo.
Dicas para estudar para a certificação Scrum Master (PSM1):

Prestar muita atenção nos eventos Timeboxed, os tempos são cobrados na certificação PSM 1 e perguntas na negativa (pegadinhas).
A prova só está disponível no idioma inglês, por isso é adequado estudar e acostumar com os termos em inglês
Há simulados na internet onde encontra-se perguntas muito parecidas a das provas:
http://www.knowledge21.com.br/simulado-de-scrum-para-a-prova-de-certificacao-da-scrum-alliance-certified-scrummaster/

http://www.gp4us.com.br/simulados-para-certificacao-scrum/

Site para a prova:
scrum.org
85% (quantidade de acertos)
Na própria página do scrum.org há um simulado de teste para a prova (com perguntas reais)

https://www.scrum.org/assessment-launch/start-psm-i
60 minutos pra responder 80 questões
Valor: $150,00
Leia o Scrum Guide ele contém tudo o que cairá na prova:
http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf

Recomendo a leitura de: Scrum a arte de fazer o DOBRO do trabalho na metade do TEMPO (Autor: Jeff Sutherland que é um dos co-criadores do Scrum), a venda pelo Kindle.
Detalho um pouco mais sobre o Scrum em:
https://oradeep.wordpress.com

Publicado em Uncategorized | Publicar um comentário

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