Cloud Híbrida ou Multicloud: entenda as diferenças

Investir em cloud computing é uma estratégia mandatória para as empresas que precisam de mais agilidade, disponibilidade de infraestrutura de TI e mudança de modelo de investimento.

Segundo um estudo da Harvard Business Review, realizado com 452 executivos de TI, quanto mais os serviços de cloud computing tornam-se confiáveis, mais as empresas conseguem se adaptar a eles rapidamente e notar seus benefícios. Ainda de acordo com o estudo, 40% dos entrevistados garantiram que o uso da nuvem aumentou a receita de sua empresa e 36% afirmaram que a adoção fez a margem de lucro subir.

 

Mas qual nuvem é mais indicada para o seu negócio?

Muito tem se falado sobre as vantagens da cloud Híbrida e de Multicloud, mas o mercado ainda tem dificuldade em compreender as diferenças entre as nomenclaturas.

A princípio, elas podem parecer insignificantes, e muitos executivos, incluindo aqueles que sabem o que estão falando, usam os dois termos de forma ambígua, gerando ainda mais confusão e incerteza.

 

Vamos começar explicando o que Multicloud significa

Multicloud envolve o uso de múltiplos serviços em nuvem, mas não é só isso. É ainda a combinação de tecnologia, proximidade com o negócio do cliente e pessoas. Ao adotarem a nuvem, as empresas buscam maneiras inovadoras para alavancar a tecnologia. Logo, diferentes nuvens são mais adequadas para diferentes necessidades.

Empresas com características tipicamente digitais estão modificando os mercados tradicionais, proporcionando novas experiências aos clientes. Ao mesmo tempo, as companhias convivem com o desafio de manter sistemas e processos legado, sendo desafiadas a buscar na transformação digital inovação e agilidade.

Para isso, as diversas aplicações têm diferentes requisitos de nuvem e algumas não funcionam adequadamente em ambiente de nuvem. Nesse ponto, o Multicloud se faz efetivo, permitindo que empresas utilizem nuvens com tecnologias e características diferentes.

 

Confira 7 motivos para optar por Multicloud:

 

  1. Orquestração

A utilização da orquestração permite, por meio de código e a automação, definir a infraestrutura executada em várias nuvens.

 

  1. Armazenamento de dados resiliente

Considerando que há diferença entre os principais fornecedores de nuvens, é importante ressaltar a latência desejada, a durabilidade dos objetos e a recuperação de dados. Se a redundância é algo vital para o seu negócio, considere a utilização de diversos provedores em nuvem.

 

  1. Flexibilidade de recursos

Ao utilizar os diversos recursos oferecidos entre provedores, é possível montar táticas combinando API entre nuvens e assim, contar com soluções completamente customizadas e diferenciadas do mercado. Além disso, também pode proporcionar uma grande economia de recursos financeiros.

 

  1. Segurança

Com a combinação entre ambientes diferentes, a segurança conquistada por meio da identificação e autenticação entre diversas nuvens é fortalecida dentro da sua estratégia.

Mas para garantir um ambiente seguro, é preciso contar com reforço otimizado para ambientes virtuais e distribuições híbridas, além de aumentar visibilidade para proteger seus dados, não importando onde eles residem. Outro ponto importante é dispor de soluções que detectem as ameaças mais avançadas e que possa corrigi-las.

Os controles e suas políticas de segurança devem ser integrados, para que a segurança seja distribuída de maneira consistente por todas as instâncias de nuvem. Vale ainda estender os mesmos controles e políticas de segurança utilizados em seus servidores físicos aos ambientes virtualizados e às distribuições de nuvens pública e privada.

 

  1. Otimização em nível global

O multicloud oferece a utilização de diversos provedores ao redor da rede, garantindo presença global levando em conta as características locais.

 

  1. TI como serviço

O Multicloud facilita a evolução da TI para um ‘service broker’, suportando as empresas na otimização do consumo e recursos de acordo com as melhores soluções.

Da mesma forma, como em qualquer projeto não ficamos restritos à apenas um único fornecedor, o mesmo pensamento se estende à estratégia Multicloud. Atuar com diversos modelos de clouds, em um formato pensado exclusivamente para o negócio do cliente, garante a melhor performance.

 

Importante:

Uma estratégia Multicloud pode contar com soluções de nuvens públicas, privadas ou híbridas. As empresas que utilizam Multicloud podem estar usando nuvem híbrida em muitos casos, mas não obrigatoriamente.

 

 

Esclarecendo a nuvem Híbrida

A nuvem híbrida é baseada na combinação de nuvens privadas e pública, mas não necessariamente de fornecedores diferentes.

Usando políticas de provisionamento, utilização e gestão por meio de vários serviços em nuvem internos e externo é possível utilizar uma nuvem pública para ganho de escala e economia financeira e em outros casos a nuvem privada com características personalizadas para workloads muito específicos.

A grande vantagem do híbrido é a diversidade de opções para escolher.

 

Mas afinal, o que é mais vantajoso?

Não existe melhor ou pior. Tudo depende do momento do seu negócio. Empresas que utilizam Multicloud também podem utilizar nuvem híbrida. Basta saber que a abordagem Multicloud permite às empresas utilizar nuvens com tecnologias e características diferentes e com muito mais possibilidades de fornecedores.

A melhor forma de decidir o que faz mais sentido para sua empresa é contratando um fornecedor agnóstico, capaz de avaliar a melhor opção de forma isenta. Em conjunto, vocês podem analisar as necessidades do negócio e definir a estratégia mais adequada.

O Multicloud UOLDIVEO, por exemplo, é uma abordagem criada para ajudar as empresas a promoverem a transformação digital dos negócios utilizando as melhores características de cada fornecedor. Mais do que flexibilidade e agilidade, esse conceito  fortalece o papel estratégico da TI.

Entre suas vantagens, está o fato de funcionarem em diversas nuvens como AWS, MIcrosoft, Google, VMware, Openstack e até mesmo uma combinação delas, geridas pela mesma empresa, com atendimento único e especializado.

Há ainda outros benefícios oferecidos pelo UOLDIVEO como consultoria da jornada para a nuvem, o que garante mais segurança sobre a estratégia de negócios, além de suporte premium dos fabricantes para qualquer volume de consumo, implantação, sustentação e otimização da infraestrutura.

 

UOLDIVEO

 

Sua empresa está preparada para o próximo desastre?

A palavra desastre está associada a perdas, que podem ser de diversas naturezas e proporções. Quando alguém na Pixar acidentalmente executou um comando de exclusão no local que armazenava o filme Toy Story 2, um ano de trabalho foi apagado. O sistema de backup falhou e… adivinhem! Não havia mais filme.

 

Foi um verdadeiro desastre. Mas os desastres podem ocorrer de diversas maneiras: queda de energia, erro humano, falhas operacionais, ataques maliciosos e podemos mencionar até mesmo os desastres naturais, que muitas vezes fogem do nosso controle. Uma coisa é certa: em todos os casos, ter um plano preventivo é fundamental para anular seus efeitos ou, ao menos, minimizá-los.

 

Sua empresa tem um plano de contingência?

Segundo a edição mais recente do Relatório Global de Fraude & Risco, publicado anualmente pela consultoria Kroll, aproximadamente uma a cada quatro empresas (23%) sofreu nos últimos 12 meses pelo menos uma violação de sistema resultando em perda de dados de clientes ou funcionários. O problema é o segundo maior fator de vulnerabilidade – atrás apenas da infestação por vírus/worms – e o quarto mais recorrente no mundo empresarial.

 

O estudo entrevistou cerca de 550 executivos dos mais diferentes setores em todo o mundo que são responsáveis ou que influenciam diretamente as decisões quanto a programas e estratégias de segurança e combate a fraudes.

 

A segurança cibernética é a mais ameaçada. Ataques, roubos ou perda de informações sigilosas foram reportados por 85% dos respondentes, a maior taxa de incidência no mesmo período. Chama também a atenção o fato de que a maioria desses eventos se dá por vulnerabilidade de software, citado por 26% dos participantes.

 

Muitas empresas ainda adotam backups lentos, destinado à recuperação de ambiente e máquinas individuais – o que não representa uma solução abrangente de recuperação de aplicação e dados. Ou ainda, mantém DRs internos com alto custo e investimentos e sem a possibilidade de aumentar rapidamente sua capacidade. Além disso, em caso de desastre, a proteção fica comprometida.

 

Recuperação de desastre como serviço (DRaaS)

Atualmente, já chegaram ao mercado soluções de DRs com foco na recuperação de desastres de nível corporativo, sem a necessidade de investimento de capital. São soluções que permitem RPO (Recovery Point Objetive) de 15 minutos a até 24h, com implementação simples e realizada em poucos minutos. Com apenas um clique, é possível replicar e salvar as informações.

Simples, rápido, seguro, econômico e implementado por especialistas: essas são as características das soluções DRaaS – recuperação de desastres como serviço.

 

Veja mais sobre os benefícios desta modalidade:

  • Facilidade de uso da ferramenta
  • Recursos disponíveis da ferramenta
  • Custo inferior a soluções de DR tradicionais
  • Suporte dedicado e monitoramento
  • Planejamento e execução de testes de desastre

 

Com uma replicação assíncrona, simples e segura, o DRaaS é uma maneira fácil para iniciar sua jornada para a nuvem e começar a se beneficiar de uma TI ágil e escalável.

 

O UOLDIVEO tem atendido o mercado corporativo com serviços que permitem a continuidade dos negócios inclusive em casos de infecção por malwares / ransomwares.

Quer debater mais sobre abordagens para recuperação de desastre? Entre em contato conosco e compartilhe com a gente suas dúvidas.

 

UOLDIVEO

 

Como contratar os serviços certos para a nuvem?

Sempre que um tema ganha popularidade, traz consigo também suas distorções. Discursos parecidos, ofertas similares, players surgindo a todo momento, mas na prática é preciso compreender a importância de se encontrar um parceiro confiável para que sua experiência seja a mais tranquila possível.

 

A computação em nuvem atua na espinha dorsal do negócio. Traz consigo números de grande envergadura. Um levantamento da consultoria IDC apontou que dois terços das empresas globais já utilizam cloud computing e que tais serviços devem movimentar US$ 43,6 bilhões até 2020.

 

Não há mais como fugir!

 

É justamente pela popularidade do tema que grande parte das companhias ainda estão receosas sobre quais serviços podem ser colocados em cloud computing. Assim, muitas vezes, deixam de dar uma chance à tecnologia por questões de confiança na segurança das informações, performance, disponibilidade e a incerteza nos modelos com custos variáveis (que costumam ser flexíveis, de acordo com a utilização).

 

Ocorre também o contrário: algumas empresas, por impulso, migram muitas aplicações para a nuvem de uma só vez, sem o devido planejamento.

 

Se você tem dúvidas sobre quais serviços podem funcionar em cloud computing, vamos esclarecer a seguir:

 

1. Infraestrutura como serviço (IaaS)

Conhecidos como IaaS, os serviços de infraestrutura em nuvem são os que mais crescem no mundo. Quer ver um dado surpreendente? De acordo com o Gartner a infraestrutura de serviço foi responsável por 38,4% do faturamento total no mercado de cloud computing em 2016.

 

2. Plataforma como serviço (PaaS)

Esse é o modelo menos conhecido de cloud computing.  A PaaS fornece a infraestrutura necessária para que os desenvolvedores de software construam novos aplicativos ou aumentem as funcionalidades de soluções já existentes. Esse modelo é atrativo para empresas que precisam criar aplicativos customizados, e também para os desenvolvedores de software e empresas que vendem soluções para nichos específicos.

 

3. Software como serviço (SaaS)

Permite definir um modelo no qual os softwares são mantidos por um fornecedor. Dessa forma, os clientes podem usar a aplicação sem que TI precise se preocupar com infraestrutura, banco de dados, middleware, etc.

Tenha em mente que seja lá qual for o serviço de cloud computing contratado, todos os modelos tem benefícios. Essa é a principal dica para que os resultados do seu projeto em cloud computing mantenham alta performance e contribuam para a produtividade da companhia.

 

UOLDIVEO

 

Sua TI está preparada para se transformar em TN?

A transformação digital enfrentada pelas companhias traz à tona um novo desafio: fazer com que a TI se torne TN, ou seja, Tecnologia de Negócios.

 

Embora o termo seja relativamente novo, essa sigla decorre de uma longa evolução tecnológica que leva o mercado a compreender como a tecnologia pode incrementar os resultados de grandes companhias.

 

Algumas delas já estão realizando a migração para esse nível na prática, utilizando conhecimento para apoiar o negócio e fazendo interface não apenas com o usuário, mas com toda a empresa.

 

TI como apoiadora do negócio como um todo

O desafio é grande. Abraçar a transformação digital significa que a área de TI deve conversar de igual para igual com as demais áreas. Se avaliarmos o nível dos sistemas e informações utilizados versus o que existe para a TI e traçarmos um paralelo, seria o mesmo que dizer que a TI está vivendo na época das planilhas, enquanto o negócio vive a era do Business Intelligence.

 

No alto escalão das companhias, as reflexões envolvem discussões estratégicas. De acordo com um estudo do Gartner, 80% dos CEOs têm iniciativas de modelos de negócios digitais, porém 70% deles têm um líder digital, sendo 20% deles CIOs. Dentro desse contexto, 40% dos CEOs acham que os CIOs têm habilidades para ser o líder digital, e 10% dos CEOS mencionam o CIO como fonte primária de informação.

 

Transformar a TI em TN significa contar com uma tecnologia totalmente voltada ao “core business” da empresa, permitindo que a informação evolua para conhecimento e, consequentemente, para o aumento das vendas e melhorias de processos com foco nos lucros. Isso gerará ainda mais valor para a área.

 

Negócios digitais

Um levantamento do IDC apontou que 83% das empresas já usa ou pretende usar um ambiente de nuvem híbrida. Cerca de 73% delas concordam que um modelo de nuvem híbrida cria uma caminho para os negócios digitais. Ainda segundo a pesquisa, a transformação digital proporcionada pelas nuvens híbridas ajuda as organizações a melhorarem a agilidade da TI e ainda transformam as iniciativas de implementação do negócio digital em um processo mais rápido, fácil e econômico.

 

As empresas que desenvolverem uma capacidade digital plena, abrangendo desde a concepção e o desenvolvimento, até a implementação e o gerenciamento das soluções, são aquelas que vão se sobressair nos próximos anos. Elas terão mais condições de evoluir seus negócios digitais continuamente, com agilidade, além de oferecer níveis elevados de sofisticação e escala.  

 

Com o apoio da computação em nuvem, os serviços digitais serão mais ágeis e disponíveis sob demanda. Assim será mais simples automatizá-los e personalizá-los para promover melhores experiências aos clientes.

 

A migração para a nuvem nos tempos atuais é um movimento quase inevitável às empresas de todos os segmentos. Algumas delas ainda estão descobrindo as melhores formas de fazer essa migração; outras já erraram e estão buscando melhorar. Esses são apenas o primeiro passo para que a tecnologia seja finalmente vista como fundamental para os negócios.

 

UOLDIVEO

 

A importância do parceiro consultivo na estratégia Multicloud

Pensar numa estratégia Multicloud pode levar uma empresa a associar, num primeiro momento, a algo extremamente complexo. O checklist, sem dúvida, envolve uma série de requisitos de autenticação, segurança, integração, integridade dos dados e disponibilidade dos serviços.

De fato, a disponibilidade da tecnologia em abundância tornou-se uma commodity. E onde está o diferencial de um parceiro efetivo? Onde encontrar um fornecedor que vá além dos critérios técnicos e comerciais e pense em todos os aspectos estratégicos de um projeto.

 

Confira 5 temas importantíssimos numa estratégia Multicloud:

 

1 – Seleção da melhor nuvem – Nuvem privada, pública ou híbrida? Essa é uma questão inevitável, pois implica em autenticações, logs e controle de acesso, permissões, configurações e cobrança entre as nuvens. Na estratégia Multicloud, todos esses requisitos são pensados de forma estratégica, do planejamento à operação, passando até por fatores fora da curva. Isso permite extrair o melhor de cada nuvem, impactando na qualidade, performance e otimização de recursos na entrega de resultados.

 

2 – O DNA do projeto define a jornadaCada projeto tem um DNA e este fator é que define a sua jornada. Entender a maturidade das aplicações é estratégico. As características e requisitos suportados por cada nuvem como custo, desempenho, flexibilidade, abrangência e simplicidade de uso necessitam ser analisadas. Dessa forma, somente uma abordagem Multicloud possibilita a evolução para um modelo de TI dinâmico, ágil e flexível.

 

3- Disponibilidade dos serviços– Quem contrata quer um serviço sem interrupções. E como prever tudo isso quando estamos tratando de camadas de hardware, software e infraestrutura? Tudo é pensado de forma integrada quando uma estratégia Multicloud é adotada. Estamos falando aqui, entre outros itens, de gestão de identidade, gestão de capacidade, gestão de configuração, automação e billing.

 

4 – Controles financeiros – Pelo volume de itens envolvidos e por tudo rodar nas nuvens, ter o controle financeiro sem dúvida é um grande desafio. A estratégia Multicloud permite maior controle interno de infraestrutura, oferecendo, simultaneamente, total atenção ao cliente, na face para o mercado. Isso representa uma melhoria de performance contínua na eficiência operacional e assegura maior satisfação para o cliente.

 

5 – Versatilidade do parceiro – É fundamental contar com um parceiro que domine tecnologias diferentes e que tenha experiência em projetos de diversas complexidades. Dificilmente você encontra tanta versatilidade aproveitando somente sua equipe interna, pois seria necessário manter grandes talentos e isso tem um custo muito alto.

 

Em empresas como o UOLDIVEO, não há apenas um profissional especializado, mas sim dezenas deles. Formamos e treinamos uma equipe de profissionais que une os aspectos técnicos e consultivos a uma longa trajetória de sucesso, endereçando a adequada solução aos projetos de seus clientes com robustez e segurança.

 

Isso só é possível porque o UOLDIVEO continuamente evolui sua oferta, colocando-se no lugar do seu cliente, ao pensar naqueles assuntos que asseguram tanto o sucesso do negócio, quanto tiram as noites de sono dos líderes de equipe, em função de um risco possível.

 

Apontar problemas e soluções para assuntos básicos de hardware, software e infraestrutura é simples. Mas quando a estratégia Multicloud é missão crítica do negócio do cliente, o compromisso toma outras proporções.

 

Nessa direção, em menos de um ano, o UOLDIVEO firmou parcerias com os principais players do mercado de tecnologia, como Microsoft Azure, Google Cloud Platform e Amazon Web Services (AWS), endossadas com os mais elevados níveis de certificação em cada marca. Ou seja, trabalhar com pleno domínio as tecnologias ícones de padrão de mercado representa um diferencial único de atuação.

 

UOLDIVEO

 

Do you WannaCry? Veja por que este ransomware é só a ponta do Iceberg

O tema ransomware não é nada novo, mas o que realmente significa? Podemos dizer que ransomware é um código malicioso usado por criminosos digitais para sequestrar dados e orquestrar ataques com o objetivo de desvio financeiro ou extorsão (cyber extorsão). O motivo para o ataque de ransomware é sempre monetário, onde a vítima é informada que o ataque está ocorrendo e é detalhadamente instruída de como o pagamento deve ser feito para obter sua as informações novamente. Importante deixar claro que não existe nenhuma garantia de que esta devolução vai realmente ser feita. Geralmente é usada moeda virtual (bitcoin) para proteger a identidade dos criminosos e dificultar o rastreamento do dinheiro pago.

 

O modelo padrão de funcionamento do ransomware baseia-se em mudar a senha do logon da vítima e criptografar o disco do computador infectado. Após esta atividade o computador é reiniciado com o objetivo de mostrar a mensagem indicando as instruções para pagamento. Segundo a Carbon Black, um importante fornecedor de hardwares e softwares de segurança, o ano de 2016 demonstrou um crescimento de 50% nos ataques de ransomware a industrias quando comparado ao ano de 2015. Empresas de manufaturas demonstraram um crescimento de 21,8% e empresas de energia e utilitários apresentaram um aumento de 16,4%. Este crescimento foi baseado em diversos fatores, dentre eles temos:

  • Grande quantidade de frameworks ou kits para desenvolvimento de variações de ransomware existentes ou para a criação de novas famílias de ransomware encontrados facilmente na Deep/Dark Web;
  • Uso a preços irrisórios de programas focados em Ransomware as a Service (RaaS) objetivando a elaboração de um ataque com pouquíssimo esforço;
  • Empresas continuam sem política para atualização de sistemas operacionais, deixando que funcionem com falhas muito antigas em seus ambientes;
  • Ausência de proteções adequadas para o correio eletrônico. Grande parte dos ataquem entram no ambiente corporativo pelo correio eletrônico iludindo o destinatário a abrir arquivos anexados ou a instalar aplicativos em seus computadores;
  • Não elaboração de treinamento dos usuários destacando as armadilhas dos criminosos cibernéticos ou mesmo a inexistência de política de segurança nos ambientes corporativos.

 

Infelizmente a tendência de 2016 foi mantida não só para ransomware, mas também para as ameaças disfarçadas, também conhecida como trojans. Segundo o relatório Desenvolvimento de ameaças de computador, elaborado pelo Kaspersky Lab, uns dos mais respeitados centros de estudos de ameaças digitais, foram identificadas 11 novas famílias de trojans e 55.679 novas modificações foram identificadas só no primeiro trimestre de 2017. Os maiores vetores de ataques são os navegadores Web, em segundo lugar o sistema operacional Android, em terceiro lugar estão os ataques focados em documentos do Microsoft Office. Os próximos vetores de ataques são as aplicações feitas com a linguagem de programação Java, aplicações envolvendo Adobe Flash e documentos em PDF.

 

Realmente o ano de 2017 foi a concretização de uma tendência de crescimento que começou em 2014. Época quando o número de dispositivos móveis começou a crescer assustadoramente em comparação com os anos anteriores e hoje não temos só a possibilidade de contaminar dispositivos móveis, mas também de atacar dispositivos ligados ao conceito de IoT. Segundo um estudo da GSMA Intelligence, o braço de pesquisa da GSMA, em 2020 teremos quase três quartos da população mundial conectada. Imagine o que aconteceria se estes dispositivos forem dominados por atacantes digitais.

 

E a cada ano as surpresas são mais devastadoras, estejam elas focadas em ransomware ou não. No final de 2016 vivenciamos o maior ataque digital deixando diversas empresa sem acesso internet atingindo 665Gbps de tráfego e mais de 130 milhões de pacotes por segundo para contaminar ambientes em mais de 164 países. Este ataque foi associado ao malware Mirai que envolveu mais de 500.000 dispositivos sob domínios dos atacantes digitais. O Brasil foi o segundo pais com maior concentração de computadores contaminados com o Mirai nesta época. A falha foi na ausência de procedimentos adequados que deveriam guiar a mudança da senha padrão dos usuários administrativos. Algo básico que deveria ser orientado de maneira automática pelos fabricantes de hardwares.

 

Muitas vezes para olhar o presente e validar o futuro devemos olhar para o passado. Em 2003, o mundo sofreu com o malware SQL Slammer, criado para explorar uma vulnerabilidade em ambientes Microsoft SQL Server 2000 desatualizados. No final de 2016 este ataque retornou a ocorrer com origem fundamentada nos países China, Vietnã, México e Ucrânia.

 

Com tudo isto em mente, como foi o ataque digital guiado pelo WannaCry criou cerca de 200.000 infecções em mais de 150 países e como ele continua a se espalhar? Primeiro precisamos observar que os computadores afetados exibiam mensagens com pedidos de resgate entre US$ 300 e US$ 600. O segundo elemento importante é que pesquisadores estimam a criação do WannaCry baseada na divulgação de uma vulnerabilidade (EternalBlue) pelo grupo de atacantes digitais Shadow Brokers. A vulnerabilidade possibilita a execução remota de código e foi corrida pela Microsoft em 14 de março de 2017 (MS17-010). Nesta época, a própria Microsoft considerou-a como crítica, afetando sistemas operacionais como Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8.1/8.1 TR, Windows Server 2012/2012 R2, Windows 10 e Windows Server 2016.

 

Sem dúvida que é um cenário mais do que crítico. Se olharmos com cuidado, veremos que existe algo em comum entre o os malwares SQL Slammer e o Mirai com o ransomware WannaCry. Vejo que além do componente humano, que por padrão adiciona centenas de falhas, existe a ausência de procedimentos para a análise e correção de vulnerabilidades. Observe que temos 14 anos desde a criação do SQL Slammer e o problema continua o mesmo, sendo tratado da mesma maneira por grande parte das empresas em diversos países ao redor do mundo. Esta é a verdadeira explicação de termos hoje algo tão devastador.

 

Por esta razão diversas empresas posicionadas na Espanha, Taiwan, Rússia, Portugal, Ucrânia, Turquia e Reino Unido foram afetadas pelo WannaCry. Segundo a própria Telefônica, 85% dos seus computadores em Madri foram contaminados, fazendo com que seus funcionários retornassem para casa a pedido da própria empresa. Imagine o prejuízo financeiro! Segundo o jornal valor Econômico, mais de 220 companhias com mais de 1,1mil computadores comprometidos foram alvo do WannaCry no Brasil.

 

Em 2014 escrevi um artigo descrevendo algumas ameaças presentes em SmartPhones e o mais incrível é que o discurso para a proteção pode ser aplicado ao cenário que temos hoje, mesmo sendo ele algo muito pior do que o existente em 2014. Segundo a Nokia Threat Intelligence Report, o mercado de malware para mobile banking está tão aquecido que cresceu 400% em 2016. Junte isto com a pesquisa da FGV mostrando que o Brasil já tem um smartphone para cada habitante (208 milhões de smartphones) e teremos um oceano de possibilidades para os terroristas digitais.

 

Se você está ainda não está preocupado com o WannaCry, deveria. E também deveria estar preocupado com o malware Adylkuzz, pois as previsões apontam para algo muito pior do que o WannaCry. Apesar de explorar as mesmas vulnerabilidades, o comportamento é diferente, não havendo bloqueio do acesso ao computador, usando o ambiente infectado como parte da sua botnet. Botnets podem conter centenas de milhares de computadores controlados remotamente com computadores prontos para responder a pedidos dos atacantes digitais.

 

Os desafios não são os mesmos, são bem maiores, mas os erros sim, são exatamente os mesmos cometidos no passado. Os erros cometidos pelas empresas de hoje são os mesmos cometidos a 14 anos atrás. Continuamos fornecendo artefatos, criando possibilidades gigantes para os atacantes digitais. Se você sente que vive em um momento de calmaria, possivelmente você se encontra no olho do furacão.  Vejo mais do que uma tempestade se aproximando, vejo um verdadeiro furação!

 

Denis Souza

 

Links indicados:

Ransomware móvel triplicou no primeiro trimestre de 2017

Ransomware e phishing estão no topo das ameaças corporativas

51% das empresas brasileiras foram vítimas de ataques ransomware no ano passado

O Adylkuzz é mais perigoso do que o WannaCry

Relatório sobre desenvolvimento de ameaças de computador

Grupo de atacantes ShadowBrokers

Prejuizo financeiro para as empresas com o WannaCry

Mais de 220 companhias são alvo de vírus no país

 

 

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 – 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

 

 

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