uoldiveo - Dicas para tirar os projetos do papel e cumprir os prazos

3 dicas para tirar os projetos do papel e cumprir os prazos

Projeto em TI é uma atividade crítica recorrente, assim como os seus requisitos: as necessidades são urgentes, os cronogramas são apertados e as expectativas do cliente estão lá em cima. O ponto é que mesmo com todo o empenho das equipes, ao longo das semanas, é possível observar que os projetos não saem do papel da forma idealizada e, pior, com prazos completamente estourados.

Mas como evitar os motivos que levam ao caos tantos projetos de TI?

1 – Tenha claro o escopo contratado

O primeiro e mais típico dos motivos que levam ao caos são os mal-entendidos com relação ao que o cliente deseja versus o que ele contratou, considerando a capacidade de entrega do fornecedor. O entendimento do projeto é fundamental e vai determinar o seu sucesso ou fracasso. Você realmente entendeu a necessidade do cliente e o escopo que foi contratado? Você possui recursos suficientes para cumprir a proposta?

Pode parecer óbvio, porém é primordial avaliar o contrato assinado pela área comercial. A situação é mais comum do que se imagina, sobretudo em empresas de pequeno e médio portes. E em muitas empresas grandes que não possuem tanta maturidade em TI, o que é comum em setores como saúde, agricultura, construção civil, entre outras.

2 – Planeje a contratação dos recursos

Apresente um cronograma viável frente à complexidade do projeto. Em muitos casos, os projetos já começam atribulados porque não foram avaliados os recursos necessários para as tarefas. Além disso, não há tempo hábil para contratações ou treinamentos. Ou seja: não há recursos disponíveis dentro de casa.

Esse cenário conturbado dá origem a outras grandes dificuldades que atrapalham os cronogramas e tiram o sono dos gerentes de projeto, como por exemplo a má comunicação.

3 – Defina bem o papel do gerente de projetos

Podemos dizer que o gerente desempenha uma função que vai além de escriba. É ele quem vai realizar a documentação do projeto e registrar todos os passos necessários para concretizar uma tarefa dentro de um modelo de segurança, pontuando os prazos, negociando possíveis atrasos e fazendo novos acordos. O gerente de projetos precisa ser alguém com capacidade de comunicação com todos os envolvidos – tanto stakeholders quanto sua própria equipe – garantindo que o projeto flua dentro do esperado.

Vale lembrar que a capacidade de negociação do gerente é um dos grandes desafios para o cumprimento dos prazos. Quem nunca se deparou com “brigas” via e-mail com inúmeras pessoas copiadas, com réplicas e tréplicas de acusações, normalmente com o assunto se desviando do foco inicial? Além de ser uma situação vexatória, demonstra a falta de sensibilidade do gerente em avaliar a proposta técnica e estudar com sua equipe antes de conversar com cliente.

A importância de manter o cronograma em dia

Cumprir prazos significa manter o cliente satisfeito e se comprometer com ele, mas para tal é preciso fazer cálculos dentro do universo de trabalho disponível. Muitas vezes, a área comercial faz propostas audaciosas e a área técnica precisa correr para entregar, faça chuva ou faça sol. Isso não é saudável e qualquer erro pode comprometer o relacionamento com o cliente.

Outro ponto é a famosa definição de prioridades: ninguém quer ouvir que tal item em um projeto é mais importante do que outro. Porém, é preciso saber a hora de negociar prazos, pois nem sempre é possível dar vazão a todas as tarefas simultaneamente.

Por fim, entregar um projeto dentro do prazo e com todas as exigências do contrato exige uma comunicação bastante alinhada entre toda a equipe, além de muito jogo de cintura para negociação de cronogramas. Não se engane: os recursos são sempre limitados e quanto mais clareza você conseguir estabelecer em um projeto, melhor para todos.

 

Luis Francisco Felizola Soares

Gestão na nuvem: ainda um desafio para o CIO

Gestão na nuvem: ainda um desafio para o CIO

A área de tecnologia da informação vem passando por uma importante transformação nos últimos anos: os CIOs estão deixando de realizar investimentos altos em máquinas e capacitação técnica para apostarem na contratação de tecnologias como serviços, como por exemplo o SaaS, PaaS e IaaS.

Neste ponto, a cloud computing torna-se a bola da vez, já que as empresas precisam cada vez mais de flexibilidade, escalabilidade e mobilidade para alavancarem os seus negócios.

Até aí tudo seguindo o ritmo natural. Porém, o ponto que vem tirando o sono de muitos gestores começa depois dessa etapa. Agora que o datacenter e as aplicações já estão na nuvem como fica a gestão desses serviços?

Quando uma empresa reduz boa parte da infraestrutura física e migra para a nuvem, ela está em busca de escalabilidade e flexibilidade, mas precisa continuar tendo o controle do que está acontecendo com seus dados.

Muitos gestores de TI estão se perdendo no processo de digitalização dos negócios.

Não adianta investir em transformação digital se não conseguir gerir de forma eficiente o ambiente.

Mas cabe à TI controlar isso sozinha?

 

Busque um parceiro para ajudar no processo de gestão da nuvem

Planejar e gerenciar a infraestrutura de TI é um passo fundamental para ter sucesso na estratégia de migração para a nuvem, principalmente quando se fala de negócios digitais.

Por isso, mais do que nunca, o profissional de TI deve estar focado na evolução do negócio e não apenas acompanhar a performance das “luzinhas” dos sistemas.

O melhor a fazer nesse caso é contar com o apoio de um parceiro como o UOL DIVEO, por exemplo, que vai ajudá-lo a gerir seus sistemas e aplicações em cloud. Isso é essencial para ter a orquestração dos ativos e serviços da empresa de modo estratégico, olhando a TI como um todo.

A digitalização do negócio é um caminho sem volta. Portanto, não adianta partir para essa jornada, se não consegue gerir de forma eficiente os recursos na nuvem. Isso vai ocasionar estouro no orçamento e uma série de outros problemas relacionados à infraestrutura de TI.

O UOL DIVEO é um player agnóstico, que trabalha com todas as nuvens públicas e também com a nuvem privada. Assim, está pronto para apoiar o cliente para qualquer caminho que ele decida seguir.

Portanto, deixe de perder noites de sono tentando resolver sozinho a gestão dos ativos na nuvem. Busque o apoio de um especialista para ajudar a solucionar essa questão.

 

Rodrigo Balleroni

 

Negócios digitais: a mudança está lá fora

Negócios digitais: a mudança está lá fora

Nos últimos anos o tema transformação digital vem marcando constante presença nas pautas de diversos CIOs. Afinal, a empresa que não digitalizar seu negócio corre o sério risco de ficar obsoleta e perder espaço no mercado.

Mais do que utilizar a tecnologia de forma intensiva, como tem acontecido no agronegócio, que hoje usa dispositivos para aumentar da sua competitividade, a verdadeira transformação digital está acontecendo na relação das empresas com seus clientes.

Os consumidores, hoje hiperconectados, estão em busca de soluções e respostas em tempo real. Tanto é verdade que, dificilmente, vemos um jovem indo a uma agência bancária. Até mesmo os mais antigos, porém antenados em tecnologia, optam por realizarem transações financeiras por aplicativos.

E os exemplos estão presentes em nossas vidas o tempo todo. A chamada de um táxi, a escolha da rota com menos trânsito, o lugar para se hospedar, tudo está mudando a partir do momento que as empresas viram a oportunidade em conectar o cliente à tecnologia e entregar mais valor.

O mais curioso é que essas empresas, assim como Facebook (maior plataforma de conteúdo do mundo), Alibaba (maior empresa de revenda de varejo do mundo), Skype e Netflix existem apenas digitalmente. O Uber não possui frota própria, Netflix não tem salas de cinema e o Airbnb não possui hotéis próprios.

 

O que isso nos mostra? Simples:

A desmaterialização democratizou a tecnologia.

 

A digitalização provoca a desmaterialização, que potencializa a democratização de uso. O smartphone é um ótimo exemplo. Desmaterializou diversos equipamentos físicos como CDs, gravadores, GPS, câmeras fotográficas, filmadoras, etc, que estão agora embutidos em um único dispositivo, o próprio smartphone.

Esse acesso mais barato à tecnologia tem permitido às empresas inovarem e com isso ir de encontro com o que as pessoas buscam: facilidade, imediatismo e uma nova experiência de uso.

É preciso ficar atento a um ponto importante que, quando mal interpretado, pode comprometer o sucesso da transformação digital:

Somos uma sociedade híbrida – parte orgânica, parte digital – e justamente por isso o processo de digitalização deve ocorrer com foco no negócio e pessoas, e não na TI.

Mobilidade, Social, IoT, Big Data, Cloud, etc. estão relacionadas à transformação, mas como atores da transformação e não como agentes.

 

Cloud computing como vetor de transformação

Qual a relação de novas tecnologias como Cloud Computing dentro deste cenário de inovação e transformação das empresas?

Antes de cloud, inovações passavam por fazer previsões detalhadas e então realizar grandes investimentos para atendê-las. Além disso, o processo para contratação de novos recursos passava por diversas áreas como comercial, arquitetura, jurídico, compras, implantação, etc.

Com cloud computing toda essa burocracia é simplificada, passando o controle para as mãos do cliente. Desta forma, testar e identificar erros rapidamente permite levar a inovação para o centro do negócio.

A quantidade de novos recursos disponíveis dentro das plataformas de cloud computing conecta as empresas a um mundo totalmente novo e completamente favorável à inovação.

E nós ainda não vimos nada. Nos próximos dez anos muitas das empresas que conhecemos e que são líderes em seus mercados sequer existirão. Outras, que estão surgindo agora, tomarão seu lugar sem dar tempo para reação. A questão para os executivos das grandes empresas que ainda não se reinventaram é decidir, hoje, de que lado querem estar. Decidir em dois ou três anos já será tarde demais.

 

Gustavo Villa

Alavancando a performance do seu e-commerce com TI

O número de profissionais dedicados exclusivamente ao planejamento e gestão de infraestrutura de E-Commerce está crescendo. E existem motivos de sobra para isso: cada vez mais percebe-se o valor de pessoas especialistas numa área que é missão crítica para muitas empresas, sejam elas dedicadas ou não ao varejo online. Um cliente disposto a comprar que não encontra o site disponível naquele momento pode não voltar mais tarde.

O objetivo do trabalho do Gestor de Infraestrutura de e-Commerce é projetar, desenvolver e manter o business rodando de forma a atender alguns objetivos essenciais:

  • Trabalhar para ter uma infraestrutura de padrões abertos, segura, e escalável para futuras necessidades;
  • Ter bem definido o modelo de sustentação do negócio;
  • Ter a visão da correta estratégia de Cloud que melhor se adequa ao seu negócio para os próximos anos

Ainda, o profissional deve estar muito familiarizado com alguns conceitos básicos e funcionalidades de componentes de Hardware e Software, especificação de níveis de serviço (SLA’s), gerenciamento da operação e uma noção de todos os componentes e ambientes satélites do seu e-Commerce (ERP, Gateway de Pagamento, Antifraude, Recomendações, Service Center, Emissão de NF-e, Gestão de Conteúdo, etc).

Além disso, é muito importante que o Gestor de Infraestrutura conheça os componentes de Hardware e Software do seu ecossistema (Middleware, Banco de Dados, Servidores Web, Balanceadores, Storage) e sua forma de escalonamento. Conhecer como esses componentes podem ser escalados é informação crucial para preparar o seu ambiente para eventos sazonais que certamente exigirão de seus componentes a manutenção dos níveis de resposta razoáveis para o usuário final.

Como avaliar uma infraestrutura de e-Commerce? Existem diversas maneiras e indicadores para auxiliar nesta tarefa. Alguns que podemos citar:

  • Flexibilidade:a capacidade de responder rapidamente à necessidade de up e downscaling com base na necessidade do negócio;
  • Custos:CapEx e OpEx relacionados aos custos de aquisição e manutenção para servidores, licenças e outros itens de hardware e software. Não esquecer a parte relativa à manutenção/suporte anual dos fornecedores da plataforma & implementação
  • Segurança e Compliance de TI:de que forma as informações sensíveis armazenadas pela plataforma estão protegidas? Estou inserido em uma indústria regida por leis específicas e/ou políticas de privacidade particulares? É possível que, dado o contexto, as informações geridas pela plataforma precisem estar regidas por algum tipo de regulamentação
  • Confiabilidade:como meus clientes são afetados por fatores como disponibilidade de serviços e cumprimento dos SLA’s internos da minha plataforma? Normalmente o cliente final (usuário do site) é impactado em medida equivalente à entregue pelos nossos fornecedores
  • Gerenciamento de serviços centralizado e Cloud-ready:fatores como suporte oferecido pelos fabricantes e funções para controle e monitoramento com visão 360º dos componentes da plataforma

O desempenho e-Commerce é outro fator bastante importante. Mais importante ainda é poder diagnosticar com rapidez eventuais relatos de lentidão no acesso ao site, seja via monitoramento do usuário real ou de monitores de pontos vitais específicos, e agir mitigando a má experiência de navegação do usuário naquele momento no site. Alguns exemplos:

  • Monitoramento contínuo dos tempos de resposta das principais páginas do site (TTFB | Time-to-First-Byte e Load Time)
  • Desempenho de rede com foco em tempos de resposta ponta a ponta (interno e externo), bem como a banda internet disponível
  • Monitoramento dos sinais vitais dos componentes da plataforma (CPU/memória/disco)
  • Monitoramento DNS
  • Avaliação de serviços de terceiros, principalmente aqueles que são executados de forma síncrona

A Compasso – uma empresa UOL DIVEO – é especialista na implementação de Plataformas de E-Commerce, tendo entregue dezenas de projetos nesta área ao longo dos últimos 5 anos. A Compasso atua no planejamento, design, implementação e sustentação de projetos de E-Commerce. Além disso, hoje sustenta e gere a infraestrutura de E-Commerce de grandes varejistas no Brasil.

Neste ano, a Compasso prestigia cinco de seus clientes que estão concorrendo ao Prêmio E-Commerce Brasil, a maior e mais importante premiação do segmento. Encerra hoje (19/07) a fase de votação popular.

  • Inovação em Tecnologia: Loja Natura
  • Inovação em Tecnologia: Profissional Rony Meisler, Reserva
  • Inovação em Vendas: Lojas Renner
  • Inovação em Operação: Livraria Cultura
  • Inovação em Experiência: Loja Farm

Sentimos muito orgulho do sucesso dos nossos clientes, mais ainda por fazer parte dele!

 

Como inserir Design Thinking na sua empresa

Olá,

Sou idealizador do Congresso Nacional de Design Thinking (CONATHINK) realizado durante o último mês de março. Ao total reunimos 29 experts de Design Thinking que ministraram 38 palestras ao longo de 7 dias.

Este evento me proporcionou contato com milhares de pessoas interessadas em inovação e um dos questionamentos que mais escutei durante os 7 dias do congresso foi referente a dificuldade de inserir a inovação dentro das empresas. Em 100% dos casos o maior ofensor apontado pelas pessoas foi a cultura avessa aos valores defendidos pelo Design Thinking.

Ok, nós sabemos que a cultura da maioria das empresas foi forjada no passado, onde os valores praticados eram outros, muitas vezes contrários aos valores defendidos pelo Design Thinking. Isto realmente acaba sendo uma barreira muito grande e difícil de ser superada pela maioria dos Design Thinkers que se aventuram nesta missão.

Mas existe um caminho ainda pouco praticado que pode te levar ao sucesso, mesmo que a cultura da sua empresa não esteja 100% alinhado com os valores defendidos pelo Design Thinking.

O segredo está em não tentar mudar a empresa e sim trabalhar a forma como você está tentando introduzir o Design Thinking neste ambiente. Quer saber como?

EXERCITE OS 3 PILARES DO DESIGN THINKING: empatia, colaboração e experimentação.

A minha sugestão para você conseguir realizar isto é aplicar o Design Thinking para implantar o Design Thinking?

Pode parecer estranho, mas este é um bom caminho a se seguir.

Vamos iniciar pelo 1º pilar, a empatia.

Se você avaliar um pouco mais a fundo verá que os stakeholders da sua empresa não são contrários ao Design Thinking ou a inovação em si. Você só deve identificar qual o verdadeiro motivo que está travando o processo, a famosa segunda camada.

Defina sua persona e aplique o mapa da empatia. Provavelmente você irá se deparar com problemas como alocação de pessoas, demandas que já chegam com uma solução definida, o medo de que as falhas da fase de prototipação tornem o projeto mais caro ou impacte na credibilidade do time, a dificuldade para garantir uma data já acordada com stakeholders e por aí vai.

A grande questão é que você tem que conhecer exatamente qual é a tua barreira, pois ter essa clareza que possibilitará planejar um plano de ação para superá-la.

É possível puxar esta frente sozinho, mas se você encontrar entusiastas da inovação que possam te apoiar nesta caminhada será muito bem-vindo. Aqui você estará trabalhando o 2º pilar, a colaboração.

Assim como em um projeto padrão do Design Thinking a colaboração gera um ambiente muito propício a inovação, pois a diversidade estimula a criatividade. Mas atenção, é fundamental que as pessoas recrutadas sejam entusiastas da inovação.

O 3º pilar é um dos mais importantes no processo de introduzir o Design Thinking em uma empresa e geralmente é ignorado. Antes de ‘vender’ o Design Thinking para sua empresa, experimente.

A melhor forma de experimentar neste caso é identificar um problema conhecido na tua empresa e trabalhar em sua solução aplicando o Design Thinking. E atenção, todas empresas possuem problemas conhecidos. Esta é a oportunidade que você terá para aplicar o Design Thinking sem ninguém te cobrar por uma data. Nesta fase isto é importante, pois o time ainda está se habituando ao Design Thinking e você precisará prototipar e testar quais caminhos deve seguir. Também é nesta etapa que você deve eliminar todas as objeções mapeadas no mapa da empatia.

Ao finalizar este projeto você terá seu 1º case de sucesso, que deverá ser usado para abrir portas para o Design Thinking na sua empresa, e deverá eliminar todas as objeções que seus stakeholders possuíam.

De forma breve este são os passos que eu indico para introduzir o Design Thinking na sua empresa.

 

Grande abraço,

Rodrigo Muniz

Alterando as permissões e notificações do seu projeto no JIRA

No post anterior já mostrei como customizar tipos diferentes de Issue para o projeto, assim como customizar ou melhorar os Workflows e também associá-los aos diferentes tipos de Issue.

Neste post, mostrarei algumas dicas para customizar permissões e notificações do projeto.

Assim como nos Schemes anteriores (Issue Type e Workflows), ao criar um projeto as permissões e notificações assumem uma configuração padrão, porém é possível alterá-las de acordo com a necessidade. A forma de criação de Permissões e Notificações é muito semelhante, portanto, ao visualizar a forma de adicionar permissões, basta “trocar” para a parte de notificações que o conceito será basicamente o mesmo.

  1. Visualizando as permissões

Ao acessar a administração do seu projeto, do lado direito vá até o item Permissions e clique no Scheme que estará como “Default Permission Squeme”. Na tela apresentada, perceba que o Scheme associado ao projeto, poderá estar compartilhado com vários outros projetos, veja:

 

 

Ao observar que há itens compartilhados com outros projetos, o cuidado na alteração de regras de permissões é redobrado, pois isso afetará os outros projetos que compartilham esse Scheme. É aí onde entra a customização de permissões específicas para o seu projeto.

  1. Criando um Squeme específico

Para criar um Scheme para o seu projeto, clique na engrenagem do canto superior direito do JIRA e logo após em Issues.

No menu esquerdo e no canto inferior, clique em Permission Schemes:

No fim da página exibida, clique no botão Add Permission Scheme Para mudar o Scheme, clique do lado direito superior no botão Actions e na próxima tela dê um nome e descrição para o Scheme a ser criado e clique em Add.

 

  1. Associando o Scheme criado ao projeto

Com o Scheme de permissões adicionado, você precisará agora associá-lo ao seu projeto e depois partir para a edição das permissões. Retorne a administração do projeto, e clique novamente no item Default Permission Scheme (conforme exibido no item 1). Ao lado direito superior, clique na engrenagem, clique em Actions e logo após em “Use a different Scheme”. Na tela exibida, selecione o Scheme criado anteriormente e clique em Associate.

 

 

  1. Editando as permissões

Após ter associado o Scheme de permissões criado, já é possível fazer a edição das permissões. Perceba que a tela exibida é semelhante à do Scheme default, mas agora é sua que está sendo apresentada. Para editar, na mesma engrenagem do lado direito superior, clique em “Edit Permissions”.

 

Para cada permissão há uma descrição de qual é a função da mesma. Para adicionar uma permissão clique do lado direito em Add. As permissões poderão ser adicionadas para Grupos, usuários específicos, Líder do projeto no JIRA, entre outros.

 

 

Adicionadas as permissões do projeto, você poderá alterar as notificações do mesmo conforme a sua necessidade também. A forma de fazer a criação e também a associação das permissões é muito semelhante, bastando voltar à administração do projeto e ao invés de ir na parte de permissões ir na parte de Notificações do projeto.

Espero mais uma vez que essas dicas o ajudem caso esteja utilizando essa ferramenta para o controle de suas atividades.

Até o próximo post 😉

[ ]´s

Melo

Oracle lock tx

Oracle – O Lock TX

Falamos superficialmente sobre como os locks funcionam no Oracle, também de problemas frequentes com eles relacionados, como o lost update, block e o deadlock.

Agora é hora de olhar com um pouco mais de detalhe como as coisas funcionam internamente. Neste artigo vamos focar no lock TX e sua relação com as ITLs.

Mostraremos também uma nova feature do Oracle 12c com relação a permissão de leitura x lock.

DML Lock

Basicamente temos 3 classes de lock no Oracle que se subdividem:

– DML Lock

– DDL Lock

– Internal Lock e Latch.

DML (Data Manipulation Language) são instruções SQLs que se propõem a alterar determinado dado. Os locks deste tipo visam manter estas alterações consistentes mesmo que ocorram de forma “concorrente”. Mas note que não há alteração concorrente, então o melhor a se dizer é que os locks apenas gerenciam, de certa forma, a alteração por ordem de chegada.

Outro ponto importante é que, durante o tempo em que estamos alterando os dados, não seja permitido alterações estruturais ou em mesmo drop da tabela. O Oracle irá cuidar de tudo isso sem que você perceba ou, pelo menos, que você quase não perceba.

Lock TX

O termo TX está geralmente ligado a expressão “transaction” e é com isto que este tipo de lock está relacionado. Um lock TX é adquirido sempre que uma transação inicia e ela se inicia sempre que modificamos um dado (INSERT, UPDATE, DELETE, …) ou declaramos a intenção de alterá-lo (SELECT FOR UPDATE). Ela finalizará com um COMMIT ou um ROLLBACK.

Haverá apenas um lock TX independentemente do número de linhas, blocos ou tabelas que sua transação envolva. É importante notar que, mesmo assim, esta não é uma operação custosa. Diferente de outras implementações, o Oracle não centraliza a gestão de locks em estruturas como “lock manager”. Como dito no artigo anterior, o Oracle se baseia nas ITL (Interested Transaction List) de cada bloco para fazer esta gestão.

Desta forma, o lock estará sempre junto com o dado e ao consultá-lo (ou tentar alterá-lo) será possível descobrir se está livre. O melhor disto é que o caminho para ler ou modificar é o mesmo e direto, sem precisar passar por algum lock manager, diminuindo assim o overhead em momentos em que há muita alteração e muito locks.

Usaremos o famoso SCOTT para demonstração dos casos que veremos aqui. Então, se quiser reproduzir nosso teste, basta criá-lo em seu DB. Lembrando que estamos usando o 12c, que traz uma importante mudança com relação a permissão de leitura de dados e que citaremos ainda neste artigo.

Primeiro teste que faremos será verificar o número de linhas na v$lock versus o número de linhas alteradas. Vamos lockar uma linha da dept e em seguida todas as linhas.

SCOTT@orcl > select * from dept;

DEPTNO DNAME          LOC

———- ————– ————-

10 ACCOUNTING     NEW YORK

20 RESEARCH       DALLAS

30 SALES          CHICAGO

40 OPERATIONS     BOSTON

Ao realizar uma alteração (sem commit), podemos ver o lock.

SCOTT@orcl > update dept set loc = ‘SAO PAULO’ where DEPTNO = 40;

1 row updated.

SYS@orcl >

SELECT s.username,

l.sid,

trunc(l.id1 / power(2, 16)) undoseg,

bitand(l.id1, to_number(‘ffff’, ‘xxxx’)) + 0 slot,

l.id2 seq,

l.lmode,

l.request,

l.type,

l.block

FROM   v$lock     l

JOIN   v$session  s

ON     l.sid      = s.sid

WHERE  l.type     = ‘TX’

AND    s.username = ‘SCOTT’;

 

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         245          5         13       2729     6       0 TX        0

 

E ao alterar todas as linhas com a mesma sessão:

SCOTT@orcl > update dept set DNAME = lower(DNAME);

4 rows updated.

 

Consultando a fila de locks:

SYS@orcl >/

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         245          5         13       2729     6       0 TX        0

 

Ou seja, independente de alterar uma linha ou várias, o lock é feito por transação. Além disso, você deve ter notado que a query traz alguns campos “estranhos”. Eles servem exatamente para identificar a transação[1]. Veja só:

SYS@orcl >select XIDUSN, XIDSLOT, XIDSQN from v$transaction;

XIDUSN    XIDSLOT     XIDSQN

———- ———- ———-

5         13       2729

 

Não vamos entrar em muitos detalhes, mas para não deixar tão inexplicável, o Oracle possui duas colunas para registrar 3 informações: Undo segment number, slot e sequence, por isso precisamos desta manipulação.

O importante aqui é notar que o lock aponta para os mesmos valores de USN, SLOT e SQN da transação, então uma transação, um lock.

 

BLOCKs

 

Agora vamos conferir como os blocks funcionam. Alteramos (sem COMMIT) todas as linhas da tabela DEPT.

SCOTT@orcl > update dept set loc = ‘SAO PAULO’;

4 rows updated.

 

Temos todas as linhas lockadas, o que ocorre se outra transação tentar alterar alguma linha da DEPT?

Bom, como já era esperado, a sessão fica aguardando:

SCOTT@orcl > update dept set loc = ‘SAO PAULO’ where DEPTNO = 10;

Como fica a fila de locks na v$lock?

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         421          4         24       2469     0       6 TX        0

SCOTT         244          4         24       2469     6       0 TX        1

 

Vemos uma informação interessante: A sessão com SID 244 que já possuía o lock, agora consta com BLOCK = 1 identificando que ela está fazendo alguém esperar.

A nova sessão (SID=421) fez um request de lock, mas sem sucesso. Veja que as informações a respeito da transação apontam para aquela que possui o lock.

É desta forma conseguimos identificar quem está locando quem.

SQL>

SELECT a.sid, ‘ is blocking ‘, b.sid

FROM   v$lock a

JOIN   v$lock b

ON     a.id1 = b.id1

AND    a.id2 = b.id2

WHERE  a.block = 1

AND    b.request > 0;

SID ‘ISBLOCKING’         SID

———- ————- ———-

244  is blocking         421

 

 

ITLs

 

E as ITLs, o que tem a ver com isso? Bom, agora o assunto fica um pouco mais interessante. Vamos precisar de um dump do bloco onde estão os dados da DEPT para entender. Além disso, para ilustrar o valor default do INITRANS, vamos ver como está na tabela:

SYS@orcl >

SELECT owner,

table_name,

ini_trans

FROM   dba_tables d

WHERE  d.table_name = ‘DEPT’

AND    d.owner      = ‘SCOTT’;

OWNER        TABLE_NAME       INI_TRANS

———— ————— ———-

SCOTT        DEPT                     1

 

Vamos identificar o block/datafile:

SYS@orcl >

SELECT DISTINCT dbms_rowid.rowid_block_number(ROWID) blk,

dbms_rowid.rowid_relative_fno(ROWID) file_no

FROM   scott.dept;

BLK    FILE_NO

———- ———-

181          6

 

Agora o dump do block:

SYS@orcl >alter session set tracefile_identifier=’ABONACIN’;

Session altered.

SYS@orcl >alter system dump datafile 6 block 181;

System altered.

 

O arquivo de trace será gerado no mesmo diretório do seu alert.

-rw-r—–. 1 oracle oinstall  197 Feb 26 13:30 orcl_ora_9742_ABONACIN.trm

-rw-r—–. 1 oracle oinstall 5.0K Feb 26 13:30 orcl_ora_9742_ABONACIN.trc

 

[oracle@hostlab trace]$ cat orcl_ora_9742_ABONACIN.trc

 

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0005.00d.00000aa9  0x0100073b.0254.34  —-    4  fsc 0x0000.00000000

 

Pode ser utilizado uma calculadora comum do Windows para constatar que AA9 hexa corresponde a 2729 decimal, 00d -> 13, 0005 -> 5, valores associados ao undo segment number, slot e sequence.

 

 

E o número 4 na coluna Lck, o que significa? Vamos seguir com os testes. Feito ROLLBACK, vamos alterar uma linha e fazer um dump.

SCOTT@orcl > update dept set loc = ‘Sao Paulo’ where deptno = 10;

1 row updated.

 

Locks:

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         244          4         24       2469     6       0 TX        0

 

ITL:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.25  —-    1  fsc 0x0000.00000000

 

Vamos fazer o update na mesma transação, em outra linha.

SCOTT@orcl > update dept set loc = ‘Maringá’ where deptno = 20;

1 row updated.

 

Locks (continuamos com apenas um):

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         244          4         24       2469     6       0 TX        0

 

ITL:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.26  —-    2  fsc 0x0000.00000000

 

E assim por diante. Veremos que esta coluna representa a quantidade de linhas deste bloco que estão lockadas por esta transação. Ao fazer um update nas 4 linhas:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0009.003.000005db  0x01000a41.00c1.21  C—    0  scn 0x0000.0018b4fb

0x02   0x0004.018.000009a5  0x010007de.02a7.27  —-    4  fsc 0x0000.00000000

 

 

Como vimos, há duas ITLs neste bloco. O que significa que apenas duas transações podem alterá-lo simultaneamente. O que acontece se uma terceira transação tentar alterar uma linha da DEPT?

SCOTT@orcl > update dept set loc = ‘São Paulo’ where DEPTNO = 10;

1 row updated.

SCOTT@orcl > update dept set loc = ‘Maringá’ where deptno = 20;

1 row updated.

SCOTT@orcl > update dept set loc = ‘Salvador’ where deptno = 30;

1 row updated.

 

Os locks foram obtidos, como é possível?

USERNAME      SID    UNDOSEG       SLOT        SEQ LMODE REQUEST TYPE  BLOCK

———- —— ———- ———- ———- —– ——- —– —–

SCOTT         421          7         23       2490     6       0 TX        0

SCOTT         244         10         19       3574     6       0 TX        0

SCOTT         127          8         17       2844     6       0 TX        0

 

Vamos ver novamente o dump do bloco. Com isso, vemos que agora temos três ITLs.

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0007.017.000009ba  0x01000504.02bb.12  —-    1  fsc 0x0000.00000000

0x02   0x000a.013.00000df6  0x010006fc.035e.2a  —-    1  fsc 0x0000.00000000

0x03   0x0008.011.00000b1c  0x01000c33.02a1.05  —-    1  fsc 0x0000.00000000

 

Pontos importantes sobre isso são:

– As ITLs não sofrem shrink. Uma vez criadas, permanecerão no bloco.

– O bloco é criado com duas (ou o valor definido pela INITRANS) e utilizam o espaço livre do bloco caso mais transações concorram no mesmo bloco.

– O valor máximo é de 255, independentemente de haver espaço livre ou não.

Vamos ilustrar também este último ponto. Criamos uma tabela com linhas curtas para que ocupem apenas um bloco e uma tablespace com bloco de 32k.

SQL> alter system set db_32k_cache_size=100M;

System altered.

 

SQL> create tablespace TESTEITL datafile ‘/u01/app/oracle/oradata/orcl/testeitl01.dbf’ size 100M BLOCKSIZE 32K;

Tablespace created.

 

SCOTT@orcl >

CREATE TABLE tb_itl

(col_id  INT,

col_txt VARCHAR2(10)) TABLESPACE TESTEITL;

Table created.

 

SCOTT@orcl >

INSERT INTO tb_itl

SELECT rownum, ‘A’

FROM   dual

CONNECT BY LEVEL <= 300;

300 rows created.

 

SCOTT@orcl > COMMIT;

Commit complete.

 

SCOTT@orcl >

SELECT dbms_rowid.rowid_block_number(ROWID) blk,

dbms_rowid.rowid_relative_fno(ROWID) file_no,

count(*)

FROM   scott.tb_itl

GROUP  BY dbms_rowid.rowid_block_number(ROWID) ,

dbms_rowid.rowid_relative_fno(ROWID);

BLK    FILE_NO   COUNT(*)

———- ———- ———-

35          7        300

Ou seja, as 300 linhas estão no mesmo bloco. Um dump inicial irá mostrar apenas 2 ITLs e após nosso teste, veremos 255.

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0020.002.00000002  0x01000772.0000.04  –U-  300  fsc 0x0000.0032f0aa

0x02   0x0000.000.00000000  0x00000000.0000.00  —-    0  fsc 0x0000.00000000

 

Agora vamos fazer uma “manobra” para que sejam alteradas 300 linhas por transações diferentes. O teste consiste em abrir recursivamente uma AUTONOMOUS TRANSACTION. Esperamos que após 255 transações não seja mais possível que isto ocorra. Usaremos a procedure abaixo para isso.

CREATE OR REPLACE PROCEDURE do_update(pnLinha IN NUMBER) AS

PRAGMA        AUTONOMOUS_TRANSACTION;

vrItl         tb_itl%ROWTYPE;

veResBusy     EXCEPTION;

PRAGMA        EXCEPTION_INIT(veResBusy, -54);

BEGIN

–fazemos select for update para lockar a linha com col_id = pnLinha

SELECT *

INTO   vrItl

FROM   tb_itl

WHERE  col_id = pnLinha

FOR    UPDATE NOWAIT;

 

–chamamos recursivamente para update da linha com col_id = pnLinha + 1

do_update(pnLinha + 1);

 

COMMIT;

EXCEPTION

WHEN veResBusy THEN

dbms_output.put_line(‘Nao conseguimos lockar a linha de col_id: ‘ || pnLinha);

COMMIT;

WHEN no_data_found THEN

dbms_output.put_line(‘Todos os registros foram lockados.’);

COMMIT;

END;

/

 

Resultado:

SCOTT@orcl > exec do_update(1);

Não conseguimos lockar a linha de col_id: 256

PL/SQL procedure successfully completed.

 

E por fim, conferindo as ITLs:

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x0033.002.00000002  0x010008a2.0000.03  –U-    1  fsc 0x0000.0032f7a1

0x02   0x0032.002.00000002  0x01000892.0000.03  –U-    1  fsc 0x0000.0032f7a3

0xfe   0x00fe.000.00000002  0x010017d2.0000.01  –U-    1  fsc 0x0000.0032f645

0xff   0x00ff.000.00000002  0x010017e2.0000.01  –U-    1  fsc 0x0000.0032f643

 

GRANT READ

 

Por fim, vamos falar de um privilégio novo do Oracle 12c relacionado com lock, o GRANT READ. Em versões passadas, tínhamos apenas o grant de SELECT. O problema é que o privilégio de SELECT permite o SELECT FOR UPDATE e embora alguém pudesse apenas “ler” o registro, podia declarar o interesse de alterá-lo, causando o lock.

O Oracle 12c traz esta new feature. Vejamos como funciona, de forma simples. Concedemos privilégio de SELECT para um user e de READ para outro e comparamos o resultado.

SCOTT@orcl > grant select on dept to hr;

Grant succeeded.

 

SCOTT@orcl > grant read on dept to oe;

Grant succeeded.

 

SCOTT@orcl > conn hr/hr

Connected.

 

HR@orcl > select * from scott.dept for update;

 

DEPTNO DNAME          LOC

———- ————– ————-

10 ACCOUNTING     SAO PAULO

20 RESEARCH       DALLAS

30 SALES          CHICAGO

40 OPERATIONS     BOSTON

 

HR@orcl > conn oe/oe

Connected.

 

OE@orcl > select * from scott.dept for update;

select * from scott.dept for update

*

ERROR at line 1:

ORA-01031: insufficient privileges

 

CONCLUSÃO

 

Finalizamos mais uma parte da nossa análise e ainda temos bastante assunto pela frente. Falamos de propriedade de ITL e qual a relação entre os locks TX e ITL.

 

Ficarão para os próximos artigos o lock TM e os de DDL, além de outras coisas como leitura consistente, multi versões que uma linha pode ter.

 

 

[1] https://docs.oracle.com/database/121/REFRN/GUID-FAE908F8-24B1-4B90-8FC5-86FCB532431C.htm#REFRN30291

[2] Oracle Database Transactions and Locking Revealed, Thomas Kyte, Darl Kuhn, 2014

 

 

4 fatores importantes sobre nuvem e continuidade de negócios que você precisa saber agora mesmo

Os departamentos de TI estão sob constante pressão para disponibilizar novas tecnologias que permitam que a empresa mantenha dados críticos, aplicações, processos seguros e em funcionamento 24 x 7.

Some a isto ofertas de nuvem que permitem que a empresa terceirize parte da responsabilidade pela gestão e garantia de segurança e confiabilidade e temos o ambiente perfeito para a continuidade de negócios e recuperação de desastres ser deixada para segundo plano frente aos desafios do dia-a-dia de gerenciamento de TI.

Ao utilizar serviços baseados na nuvem é fácil perder de vista os principais riscos de continuidade de negócios e por isso listamos aqui 4 pontos importantes que você deveria ter em mente enquanto utiliza cloud computing para sua empresa.

 

1. Continuidade de negócios é mais que recuperação de desastres

A indústria é permeada com termos como “continuidade de negócios” e “recuperação de desastres”, o que pode torná-lo confuso para os líderes empresariais. Mesmo o termo “recuperação de desastres” leva a maioria dos profissionais de TI para o caminho errado.

Soluções de DR são normalmente utilizadas para “cenários de desastres” e “desastres” relacionados a causas naturais não são a causa mais comum de interrupção de TI.

Falhas de software, hardware e erro humano são as principais categorias responsáveis ​​por algum tipo de interrupção no negócio.

As empresas precisam de parar de pensar apenas em desastres e começar a considerar maneiras de evitar interrupções.

 

2. As nuvens nem sempre incluem alta disponibilidade e / ou garantia de continuidade de negócios

A todo momento o serviço de nuvem é entregue a partir de um Data Center.

Se esse Data Center tiver problemas, o fornecedor de nuvem pode mover suas cargas de trabalho rapidamente para um novo Data Center?

Sempre verifique como a empresa lida com isto para poder decidir como se preparar para isto.

Muitas vezes os players de nuvem pública disponibilizam maneiras de garantir a continuidade de negócios utilizando replicação de dados em Data Centers localizados em regiões distintas.

Fique atento: este recurso não é padrão na oferta de nuvem e precisa ser configurado individualmente na maioria dos casos.

 

3. A localização dos servidores garante mais do que latência

A nuvem não é um lugar mágico – onde seus arquivos são armazenados fisicamente realmente importa.

A localização dos servidores da nuvem pode afetar a velocidade de acesso e preços, mas é um erro pensar em localização apenas por este prisma.

Quando falamos em continuidade de negócios, localização em região diferente da principal e eventualmente o uso de fornecedores distintos realmente é algo a ser considerado.

 

4. Backup nem sempre é parte da oferta padrão

Fornecedores de nuvem nem sempre oferecem backup de dados armazenados dentro das métricas necessárias para o negócio de sua empresa.

Alguns fornecedores sequer oferecem backup dos dados como parte padrão de sua oferta.

Por padrão assuma que o fornecedor não oferece garantias e verifique com o mesmo como ele lida com backup, antes de definir um plano para isto.

 

Continuidade de negócios é um tema importante para você?

Se você quiser discutir os cenários de continuidade de negócios, com garantia de alta disponibilidade, segurança e conectividade integradas às ofertas em nuvem, entre em contato conosco pelo telefone (11) 3092 6161 ou pelo nosso formulário de contato.

 

LOCKS – Oracle

Quem trabalha com banco de dados relacionais já deve ter tido problema com Locks diversas vezes. Podem deixar apps lentas, deixá-las completamente paradas, e naturalmente vem a dúvida: por que precisamos deles?

Eles não são tão ruins assim e ao final espero que entenda que eles são, na verdade, indispensáveis. São quem permitem que sistemas multi-users possam ser escaláveis de forma consistente. Atuam para que apenas uma transação de cada vez possa alterar um determinado dado, formando uma fila com todos que tem esta intenção.

Imagine você alterando uma linha da tabela de empregados. Enquanto pretendia alterar o “salário”, outra pessoa foi e alterou o “nome” do mesmo registro. Embora não pareça algo muito preocupante, você consegue imaginar a “bagunça” quando várias sessões tentam alterar o dado ao mesmo tempo? E no caso de alguém que queira aumentar 1.000 no salário e outra aumentar 10%: a ordem de execução vai afetar o resultado final.

Enfim, para começar é importante entender que Lock é a forma que o banco de dados tem de organizar as transações e se manter consistente. Alterações nas tabelas respeitam a ordem de chegada. Chegou primeiro, atualiza primeiro. Chegou depois e tem alguém atualizando? Espere até a conclusão. E aqui nascem os problemas.

Neste artigo tentaremos mostrar um pouco de como os Locks funcionam. Não dá para se falar de maneira global porque cada banco de dados acaba implementando de forma diferente, então focaremos na implementação do Oracle. Há, obviamente, vários conceitos relacionados e vamos tratando deles no decorrer do artigo. Como tem assunto para um livro, vamos dividir em uma pequena série de artigos.

Aqui falaremos de conceitos como transações e seu papel no contexto da aplicação. Também abordaremos um problema comum de apps multi-users, os chamados lost updates. Em seguida vamos para os problemas relacionados ao banco de dados como bloqueios, uma estrutura do cabeçalho do bloco de dados chamado ITL e deadlock.

Nos próximos artigos desta série, vamos mergulhar um pouco mais para descobrir como o Oracle trabalha internamente para gestão de Locks e transações e também como ele trata as multi versões de uma linha.

 

TRANSAÇÃO

 

Primeiramente, vamos entender como um banco de dados é alterado e o que há de especial nesta mudança. Parece simples, não?

SQL> update hr.employees set FIRST_NAME = ‘Adriano’, LAST_NAME = ‘Bonacin’ where EMPLOYEE_ID = 206;

1 row updated.

Neste momento (até o commit ou rollback) o banco de dados, de maneira simplificada:

– Está protegendo esta linha para que ninguém a altere;

– Protegendo a tabela para que ninguém a drope;

– Criou uma forma de desfazer a alteração;

– Criou uma forma para refazer.

E tudo isto depois de verificar se havia espaço livre na tabela, se eu tinha permissão para fazer a alteração, entre outras coisas.

Por default, o Oracle não confirma a alteração, embora seja otimizado para isso (e não para rollbacks). Assim, é importante garantir que o commit seja efetuado para não deixar o registro bloqueado. Que fique claro, porém, que as apps também podem ter uma arquitetura que já faça a alteração e o commit automaticamente.

Quando efetuado o commit e recebido o OK do banco de dados, um DB (A C I D) garante que a partir daquele momento seu dado não será mais perdido (Durabilidade). Você ainda pode perder o banco de dados inteiro, mas aí é outra conversa.

Resumindo, chamamos de transação esta operação de iniciada com um update (ou insert, delete, …) e finalizada com commit (ou rollback) que leva o DB de um estado consistente a outro.

 

LOST UPDATES

 

Tratando de transações e Locks do ponto de vista da aplicação, um problema comum ocorre quando vários usuários podem alterar o mesmo dado, o chamado de lost update (alteração perdida). Considere o cenário abaixo como exemplo:

1 – O usuário A consulta os dados do cliente 1 para ajustar seu endereço.

2 – O usuário B consulta os dados do mesmo cliente 1 para também ajustar o endereço.

3 – O usuário A altera o endereço para “Av Brigadeiro Faria Lima”.

4 – O usuário B altera o endereço para “Av Brigadeiro F Lima”.

Qual o resultado final? O último? O primeiro? Um mix?

Para aumentar a possibilidade trabalhar em concorrência (escalabilidade) sem estes conflitos (de perder alterações), geralmente apps usam diferentes metodologias: “Lock Pessimista” e “Lock Otimista”.

Basicamente:

– Pessimista: declaramos (Lock) que vamos alterar o dado (select for update) quando o consultamos. O próximo que tiver intenção de alterar, fica aguardando.

– Otimista: lemos o dado sem o Lock e garantimos na hora da alteração que ele estava exatamente como lemos (outra sessão pode ter alterado entre ler e alterar).

 

BLOCKs

 

Este é o principal efeito negativo, quando uma sessão possui um Lock de determinado dado e outra faz o request do mesmo. A sessão que chegou depois ficará aguardando (completamente congelada) até que o dado solicitado seja liberado.

Os bloqueios podem ocorrer com SELECT FOR UPDATE, quando duas sessões consultam alguma linha em comum. Neste caso, há uma cláusula NOWAIT que pode ser adicionada e a segunda sessão tomará um erro ao invés do block.

No caso dos INSERTS, há dois cenários em que ocorrem comumente. No primeiro, a tabela deve ter PK ou algum outro índice único e ambas as sessões estão tentando inserir a mesma chave. No segundo, duas tabelas devem ter FK e o insert na filha ocorre enquanto outra sessão inseriu na tabela pai (mas ainda não comitou).

Com UPDATEs, DELETEs e MERGEs, a prevenção seria a melhor forma estar livre. Tentar lockar a linha antes da alteração com SELECT FOR UPDATE NOWAIT e só então concluir a manipulação do dado.

 

LOCK ESCALATION

 

Um outro termo que talvez você veja por aí, mas que não ocorre com o Oracle, é o Lock Escalation. Em alguns DBs a forma de gestão de lock depende de um Lock Manager. Uma estrutura de tabela em memória que registra as alinhas que estão lockadas.

Porém, quando o número de linhas lockadas de uma mesma tabela é consideravelmente grande, o DB prefere escalar o lock para o bloco/tabela inteira. Fica mais fácil para gestão, mas provavelmente teremos linhas lockadas sem a real necessidade.

O Oracle não usa este tipo de gerenciamento de lock. Para lockar uma linha, o Oracle vai até o DB Block e armazena ali a transação que alterou (ou tem a intenção de) a linha, independentemente do número de linhas. Será sempre assim, nunca haverá o Lock Escalation.

 

ITL

 

Interested Transaction List (ITL) são estruturas do cabeçalho do bloco (DB block header) onde são armazenadas as transações que desejam alterar linhas daquele bloco. É ocupada uma entrada por transação e não por linha lockada. Assim, uma transação pode lockar 300 linhas do bloco que apenas uma entrada das ITLs será utilizada.

Associado a isso, estão os eventos de espera como o “enq: TX – allocate ITL entry” que ocorre quando a requisição de alterações no mesmo bloco por transações (sessões) diferentes é alta.

As ITLs estão diretamente relacionadas com os parâmetros INITRANS e MAXTRANS dos segmentos, que representam o número mínimo e máximo de transações ocorrendo no mesmo bloco. Após escolher o número mínimo, este valor pode crescer se houver espaço livro no bloco.

INITRANS: Número de entradas iniciais do bloco, cujo default é 2 (mesmo que você solicitar 1).

MAXTRANS: Número máximo de transações, que desde o Oracle 10g é 256.

Uma conclusão imediata disto é que não será possível mais que 256 transações por bloco, embora este seja um número mais do que adequado na grande maioria das vezes.

 

 

DEADLOCKs

 

Os deadlocks são no mínimo assustadores, mas é a forma que o DB tem de evitar locks cíclicos. Veja o cenário abaixo:

– Sessão A possui lock no empregado 200

SQL> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

– Sessão B possui lock no departamento 200

SQL> select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update;

DEPARTMENT_ID DEPARTMENT_NAME

————- ——————————

200 Operations

– Sessão A tenta lockar o departamento 200 (lockado por B)

SQL> select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update;

… fica congelada

– Sessão B tenta lockar o empregado 200 (lockado por A)

SQL> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

… fica congelada

 

Veja o que ocorreu com a sessão A:

select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update

*

ERROR at line 1:

ORA-00060: deadlock detected while waiting for resource

No alert do DB é registrado este evento:
ORA-00060: Deadlock detected. See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors. More info in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_32577.trc.

E a informação no trace (apenas algumas partes):

*** 2017-02-12 10:21:29.714

*** SESSION ID:(241.57407) 2017-02-12 10:21:29.714

*** MODULE NAME:(SQL*Plus) 2017-02-12 10:21:29.714

*** CLIENT DRIVER:(SQL*PLUS) 2017-02-12 10:21:29.714

DEADLOCK DETECTED ( ORA-00060 )

See Note 60.1 at My Oracle Support for Troubleshooting ORA-60 Errors

[Transaction Deadlock]

The following deadlock is not an ORACLE error. It is a

deadlock due to user error in the design of an application

or from issuing incorrect ad-hoc SQL. The following

information may aid in determining the deadlock:

—– Information for the OTHER waiting sessions —–

current SQL:

select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update

—– End of information for the OTHER waiting sessions —–

 

Information for THIS session:

—– Current SQL Statement for this session (sql_id=1fu1jghcq3ydc) —–

select DEPARTMENT_ID, DEPARTMENT_NAME from departments where DEPARTMENT_ID = 200 for update

Como se pode ver, o trace traz algumas informações importantes na investigação do que pode ter ocorrido. A principal é o SQL que a minha sessão tentou executar e não conseguiu.

Em apps de grande porte, casos comuns de deadlock são com FK não indexadas. Quando se altera/exclui dados da chave na tabela pai, o Oracle coloca lock full nas tabelas filhas que não possuem índice nos mesmo campos. Com a tabela inteira lockada, a chance de alguém precisar destes dados é maior.

O fato que talvez cause uma certa estranheza em quem nunca se aprofundou no assunto é que este lock full ocorre apenas durante a execução do DML na tabela pai e não durante toda a transação.

Para ilustrar, vamos usar o seguinte cenário:

– Table pai: hr.departments (PK: department_id)

– Table filha: hr.employees (FK: department_id)

– por default, há um índice na hr.employees.department_id. Foi dropado: DROP INDEX EMP_DEPARTMENT_IX;

Se o lock durar apenas durante o DML na pai, poderemos lockar uma linha na filha após a conclusão.

SESSAO 1> DELETE departments d WHERE  d.department_id = 170;

1 row deleted.

Elapsed: 00:00:00.00

SESSAO 2> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

Elapsed: 00:00:00.01

Ok, conforme esperado. E como podemos então perceber este lock que dura 00:00:00.00 s? Bom, neste caso, se já houver algum registro lockado na filha, não será possível concluir o DML na pai. Faremos rollback nas duas e começaremos na ordem inversa.

SESSAO 2> select EMPLOYEE_ID, FIRST_NAME, LAST_NAME from employees where EMPLOYEE_ID=200 for update;

EMPLOYEE_ID FIRST_NAME           LAST_NAME

———– ——————– ————————-

200 Jennifer             Whalen

Elapsed: 00:00:00.00

SESSAO 1> DELETE departments d WHERE  d.department_id = 170;

… aguardando

Sempre devemos indexar as colunas das FKs? Não necessariamente. De forma simplificada, se você faz join com pai e filha e/ou pensa em alterar a chave (ou excluir) de uma tabela pai, é importante que na filha exista um índice.

 

CONCLUSÃO

 

Falamos um pouco de pontos positivos e negativos do lock. Negativos quando nos geram problemas de performance, positivos quando nos garantem a consistência dos dados. Falamos também de alguns fenômenos relacionados como o Lost Update, Blocks e Deadlocks.

Após esta breve introdução sobre o conceito, nos artigos seguintes aprofundaremos um pouco. Falaremos do tipo de lock, modo de lock tanto para DML como DDL. Revisitaremos o assunto das FKs, com uma riqueza maior de detalhes.

Até lá!

Adriano Bonacin

JIRA – Customizando tipos de Issue e Workflow

No post sobre o JIRA, falamos que trata-se de uma ferramenta que possibilita a organização de atividades de um projeto, desde o rastreamento de bugs, novas features, melhorias, etc.

Neste post, trarei dicas um pouco mais específicas para customizar um projeto.

Criando o projeto

Possuindo os acessos necessários, para criar um projeto você deverá clicar no menu superior em “Projects” e “Create” e selecionar o tipo de projeto a ser criado. Em qualquer um deles, é possível fazer customizações específicas posteriormente. Para o exemplo do post, utilizei o “Simple Issue Tracking”.

Depois de criado o projeto, o mesmo poderá ser visualizado conforme abaixo:

Para acessar a “administração” do projeto, basta clicar no item “Project Administration” do lado esquerdo inferior (vide imagem acima). Na tela exibida, será possível customizar diversos itens, tais quais: Issue Types, Workflow, Screens, Fields, Versions, Components, Roles, Permissions e Notifications.

 

Customizando Issue Types

No exemplo do post utilizei um projeto padrão (Simple Issue tracking). Ele traz dois tipos de Issue: tasks e subtasks. Mas digamos que você queira adicionar algum outro tipo de Issue. Para isso, no item “Issue Types” você deverá clicar no “Scheme” que tem o nome do projeto criado, no caso do exemplo o nome “APBLOG: Simple Issue Tracking Workflow Scheme”.

Perceba que o Scheme, trata-se de um agrupamento dos tipos de Issue do seu projeto. Para editar, clique do lado direito superior em “Actions” e Edit Issue Types:

Na tela exibida, caso queira novos tipos de Issue no seu projeto, basta clicar sobre o mesmo do lado direito (Available Issue Types) e arrastar para o esquerdo (Issue Types for Current Scheme). É possível ainda alterar o nome do esquema para o nome que você desejar e também adicionar tipos de Issues “não existentes” na tela (por exemplo um tipo de Issue com o nome “posts de blog”)

No fim da página basta clicar em salvar para que as alterações se concluam.

 

Customizando Workflows

É possível ainda, editar o Workflow padrão de seus projetos e também inserir Workflows diferentes para cada tipo de Issue do projeto. Isso poderá auxiliar quando existirem status variados para tipos de Issues diferentes, ou até mesmo outros campos a serem preenchidos (veremos isso em próximos posts).

 

Para editar o Workflow, novamente no modo de administração do projeto, vá até o item de Workflows e clique no “lápis” ao lado do Workflow com o nome do projeto, veja abaixo:

 

Veja que também há um lápis nesta tela. Ao clicar neste, será possível editar o Workflow “visualmente” porém, é possível também editar através de texto clicando no botão “Text”. No caso de edição “visual” será possível adicionar novos status e as “transitions” que são as conexões entre os status.

É possível também associar um Workflow diferente para cada tipo de Issue do seu projeto. Para tanto, retorne ao modo de administração do projeto e clique no “Scheme” do Workflow.

 

Perceba que é exibido apenas um Workflow que é o mesmo exibido anteriormente na edição.

Para adicionar um Workflow no Scheme será necessário clicar em “Add Workflow” e em “Add Existing”.

 

Mas porque “Add Existing”? É isso mesmo, será necessário ter um outro Workflow criado para adicioná-lo e veremos isso logo. Por enquanto imagine aqui que este já existe, assim será exibida uma lista com os Workflows existentes.

 

Selecione o Workflow desejado e clique em Next. Atribua o Workflow ao tipo de Issue desejado e clique em Finish.

 

Para criar um Workflow “separado” do projeto, basta clicar no menu superior direito em no ícone de engrenagem, clicar em “Issues” e logo após no menu ao lado esquerdo em “Workflows”. E é possível sim do mesmo modo, adicionar um Scheme de Workflow separado do projeto (você poderá usar um Scheme diferente do padrão se desejar).

 

Clique do lado direito em “Add Workflow”, no pop-up dê um nome ao Workflow e clique em Add.

 

 

A mesma tela de edição de Workflow que já foi exibida anteriormente aparecerá e já mostrei anteriormente como este poderá ser adicionado ao seu Scheme.

Por enquanto é isso pessoal, espero que para quem usa o JIRA as dicas ajudem de alguma maneira.

Até o próximo post.

 

[ ]´s

Melo