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

 

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

 

Ambiente de DR: sua empresa está realmente preparada?

Como a maioria dos profissionais de TI sabem, ambiente de contingência ou ambiente de DR (Disaster Recovery) é a infraestrutura que entrará em uso caso um problema grave ocorra por causa de incêndios, enchentes, quedas de energia, erro humano ou caso um malware/ransonware prejudique os servidores ou um datacenter. O ambiente de DR  permitirá que a empresa se mantenha em funcionamento enquanto o problema no ambiente produtivo está sendo solucionado.

Entendido o que é um ambiente de DR, precisamos ter em mente que não é consenso entre muitos gestores se devemos usar ou não usar um ambiente de DR, já que na maior parte do tempo ele não será usado. Mas esta não é a pergunta correta a ser feita. Eles deveriam estar se perguntando “qual será o prejuízo que a minha empresa terá se tivermos uma parada inesperada em algum sistema crítico para o negócio?

A palavra prejuízo neste texto nos leva a refletir sobre diversos aspectos. Dentre eles podemos citar danos à imagem, impacto na reputação do ambiente, perda de clientes, penalidades para o fechamento de contratos, riscos de ciberataques, ausência de treinamento para uma recuperação rápida e muitos outros pesadelos que tiram o sono de qualquer diretor financeiro.

De acordo com a empresa BackBox, especializada em backup e recuperações, 50% de todos os negócios já tiveram algum desastre ruim o bastante para interromper alguma aplicação, sendo 18,5 horas a média para o tempo de inatividade de uma aplicação (downtime). A mesma empresa afirma que pequenos negócios podem enfrentar perdas de US$ 8.000,00 por hora, enquanto empresas médias sofrem perdas entre US$74,000 a US$90,000 por hora. Já empresas de grande porte podem ter perdas que variam de US$700,000 a até US$800,000 por hora que a aplicação crítica ficou sem funcionar.

O estudo da BackBox aponta que cerca de 81% das paralizações duram pelo menos um dia e apenas 35% das pequenas empresas possuem planos de recuperação contra desastres. É impressionante observar que 75% das empresas pesquisadas informaram que seus planos contra paradas inesperadas (desastres) são inadequados. Comecei a me questionar quais passos estariam sendo desenhados de maneira errada?

Insatisfeito com os números, decidi examinar o que revelava o relatório “The State Of Disaster Recovery Preparedness 2017”, feito com a participação da Forrester Research e  o Disaster Recovery Journal. O relatório mostra diversos estudos, envolvendo estratégias para Continuidade de Negócio (BC-Business Continuity) e Recuperação de Desastres (DR-Disaster Recovery). O relatório entrevistou 73 tomadores de decisão, mostrando que:

Note que 45% (34%+11%) dos entrevistados não estão contentes com suas estratégias e sentem-se inseguros. Se realmente uma falha em seus sistemas críticos ocorrer estará em risco não só o impacto nos negócios, mas a reputação e a carreira de todos os responsáveis.

A mesma pesquisa revela que diversos motivos foram revelados para a criação de um ambiente para DR dentre eles podemos citar: competitividade e necessidade de permanecer online, motivos legais, custos das próprias empresas paradas, elevação de riscos naturais ou riscos causados pelo homem, elevação da disponibilidade de uma aplicação crítica, responsabilidade legal, ambiente de DR identificado como prioridade máxima pela diretoria.

Independente do motivo, desenvolver uma estratégia para a contratação de um ambiente de contingência é inevitável para qualquer empresa. Mas se a justificativa for custos, basta olharmos os valores que serão gastos com os prejuízos de uma parada inesperada em um ambiente crítico. Claramente estes custos são superiores do que os custos da grande maioria dos ambientes de contingência. É esta conta que os responsáveis pelo negócio de uma instituição devem fazer, sendo o papel dos gerentes de infraestrutura primordial para que esta visão seja considerada pela diretoria.

Ok, vamos assumir que a contratação do ambiente de DR é prioritária e foi aprovada pela diretoria, é importante destacar que frequentemente um ambiente de Backup é confundido com um ambiente de DR e isto pode trazer sérias complicações.

Pode-se dizer que Backup é a cópia de dados em um disco, fita ou em um ambiente de Cloud e o retorno desta informação em caso de necessidade pode ser muito longo e o tempo cíclico para elaborar a atualização dos dados tende a ser muito longo. Outro ponto importante é o baixo uso de automação, além de grande carga de horas da equipe de TI para guiar a recuperação do ambiente produtivo. Resumindo: muito suor e elevada possibilidade para grandes perdas financeiras.

Se imaginarmos os conceitos ligados a um ambiente de DR, veremos que o tempo entre replicações ou atualização das informações é chamado de RPO (Recovery Point Objective) e que o tempo para recuperar as informações e ativar o ambiente ou recuperar a aplicação prejudicada é chamado de RTO (Recovery Time Objective). Nem sempre isto é compreendido pelas empresas e o resultado é um projeto incompleto ou confuso. Importante destacar que:

 

“Não existem melhores práticas para serem usadas, tudo vai depender do negócio de cada empresa.”

 

Em um ambiente envolvendo o conceito de Disaster Recovery (DR) veremos que é indispensável a presença de mecanismos para a automação, estejam eles ligados a replicação de informações ou estejam eles ligados a orquestração para que as máquinas e bancos de dados sejam ligados na ordem correta.  Resumindo: temos aqui baixíssimo suor usando ferramentas para obter mínimas perdas financeiras.

Com isto em mente, muitas empresas acreditam que é suficiente, mas isto é um grande engano. É necessário ter uma equipe bem treinada, sendo apoiada por um bom run book. Um run book é um documento com a sequência de procedimentos e rotinas que devem ser seguidas por cada equipe envolvida no ambiente de DR.

Para finalizar, vamos imaginar um ambiente produtivo virtualizado que necessita ser protegido com a presença de uma estrutura de DR operando em um Data Center remoto. Quais as atividades recomendadas para a construção deste ambiente?

  • Primeiro deve-se mapear todas as aplicações realmente críticas para o negócio, juntamente com o impacto caso estas aplicações parem inesperadamente o seu funcionamento;
  • Depois é importante analisar se as aplicações identificadas estão devidamente configuradas, sem a configuração excessiva de disco, processamento ou memória RAM;
  • Com a validação do size correto das aplicações, é necessário analisar o impacto financeiro. Quanto tempo o negócio aceita ficar com suas principais aplicações sem atividade? O resultado desta análise é a definição do RPO e RTO;
  • Definidos o RTO e RPO, basta criar o run book;
  • O quinto ponto é o mais importante, estando ele centrado em pessoas. Sendo necessário:

I. Nomear uma equipe multidisciplinar para a elaboração das atividades quando for decretado o uso do ambiente de DR. Importante considerar não só membros da equipe técnica, mas também membros da diretoria ou da equipe jurídica. Deve-se nomear uma pessoa que será a representação da empresa para elaborar comunicados aos jornalistas e a mídia eletrônica, reduzindo as perdas na imagem da instituição;

II. Capacitar e treinar a equipe para elaborar simulações validando as atividades contidas com testes de DR. O resultado dos testes deve gerar um relatório com todos os pontos de melhoria;

III. Com os resultados das simulações, a equipe deve elaborar testes de DR duas vezes no ano. O resultado dos testes deve gerar um relatório apontando as evidências de cada atividade feita proporcionando auxílio ao processo de auditoria ou aos investidores da empresa;

Tenha em mente que as atividades “a” e “b” possuem o objetivo de reduzir custos do ambiente de DR. Este ambiente deve impactar minimamente a equipe envolvida, sem abrir mão de transparência, simplicidade operacional e deve-se ter suporte de uma equipe externa devidamente capacitada sempre que necessário.

 

Denis Souza

 

Links Recomendados:

 

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 UOLDIVEO – é 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!

 

Qual é a nova posição do CIO na era digital?

Tenho me deparado muito com essa indagação: qual é a nova posição do CIO nesse mundo digital?

O mundo digital abre possibilidades enormes para todos os profissionais: marketing, vendas, mas especialmente para o executivo de TI.

Para continuar sendo importante, o CIO precisa deixar de ser visto como centro de custo e precisa passar a ser visto como gerador de receita.

Esta característica fica muito clara em pesquisas constantemente publicadas pelo Gartner que mostra que, especialmente em países latino-americanos, a otimização de custos está entre as principais preocupações destes profissionais. Questão importante, mas que não estão relacionadas a estratégias de crescimento de uma empresa.

Para assumir o papel de líder de inovação e impulsionador do negócio, o executivo deve encarar essa nova etapa como uma enorme oportunidade e não como uma ameaça a sua posição atual.

A grande vantagem que o CIO tem é o enorme conhecimento, muitas vezes acumulado por anos de aprendizado e prática, que os novatos ou os oriundos de outras áreas não possuem. A “mão na graxa” nessas horas faz a diferença para conectar o negócio com a tecnologia.

Nunca se abriu um universo tão amplo de oportunidades como na era digital.

Toda a indústria está se transformando, das tradicionais gravadoras de música, varejo e até bancos estão sendo reinventados. Aplicativos são criados a todo momento para alegria, e ao mesmo tempo, arrepio de muitos.

E é justamente nesse cenário que o CIO pode e deve ter papel fundamental.

Agora, a postura tem que seguir o mesmo ritmo das mudanças. O profissional além de continuar se aprimorando deve se desapegar do jeito antigo de fazer as coisas.

É preciso se manter atento às negociações de SLA que correspondem à qualidade adequada ao serviço prestado, acompanhe os resultados (KPI), que devem estar disponíveis na maioria das vezes em real time, mas acima de tudo se manter focado no negócio.

Se o CIO não fizer isso, certamente alguém da organização fará.

Boa sorte e conte conosco!

 

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

 

 

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.