Arquivo

Archive for the ‘Consultoria em banco de dados’ Category

ApexSQL Refactor

Existe problema sem solução?

Achei esse texto interessante e resolvi compartilhar… muito bom!

Um homem comprou um carro, que tinha um defeito curioso. Mandou uma carta à fábrica relatando seu problema: “Não os culpo se não responderem. Sei downloadque parece loucura. Toda noite, depois do jantar, pego o carro e vou tomar sorvete. Quando compro sorvete de Creme, o carro não funciona. Quando compro de outro sabor, liga na hora. Por que isto ocorre?”
A carta foi parar na mesa do presidente da empresa, que destacou seu melhor Engenheiro para desvendar o mistério. Incrédulo, o Engenheiro chegou à casa do homem na hora em que ele saía para comprar sorvete. Os dois foram juntos a sorveteria. Pediram de Creme. Voltaram ao carro. Ligaram… Nada.

No dia seguinte, repetiram o passeio. Pediram de Baunilha. O carro pegou. No terceiro dia, de Nozes. Tudo bem. No quarto, Cereja. O motor perfeito. No quinto, Creme, de novo. O motor não deu sinal de vida. Inacreditável. A única conclusão possível: O carro era alérgico a sorvete de Creme. O que fazer diante dessa constatação? Trocar o óleo por creme antialérgico?

O engenheiro não podia acreditar naquilo. Passou uma semana cruzando dados e comparando hipóteses. Um dia, olhando suas anotações, achou uma pista: O homem levava menos tempo para comprar sorvete de Creme. Como era um sabor bastante pedido, o latão com Creme ficava à mão do atendente. Para pegar os outros sabores, tinha de lavar a concha, enxugá-la, dar alguns passos para pegar o sorvete e mais outros para entregá-los ao cliente. Além disso, o de Creme custava R$ 1,00. Os outros sabores, R$ 1,20. Como o homem nunca tinha 20 centavos trocados, quando comprava de Chocolate ou de Morango tinha de esperar para receber e conferir o troco. Isso representava 01 minuto a mais.

Com isso, o mistério ganhou nova configuração. Não se tratava de o carro gostar ou não de sorvete de Creme. A questão agora era: Por que ele não funcionava quando se levava menos tempo? O engenheiro abriu o motor, conectou aparelhos a várias peças e descobriu que havia um relé com uma ventoinha defeituosa, que causava um problema de resfriamento. Touché! (ou Eureka, se preferirem). Quando o homem comprava sabores como Flocos ou Pistache, a peça tinha mais tempo para se resfriar. Quando pedia de Creme, o serviço era mais rápido, o relé ainda estava quente e não funcionava. Estava esclarecido o mistério. Era só não embarcar nas aparências, estudar o problema com cuidado e encontrar o caminho certo.

Moral da história: Se você, caro amigo (a), se encontra desesperado, sem encontrar uma solução para seu problema, tenha calma. Coloque a cabeça para funcionar e analise os fatos. Por mais complicado que seja, não há problema sem solução.

Fonte

Acordo de Nível de Serviço (SLA)

Um passo importantíssimo para entregar o valor esperado pelos clientes com os serviços de TI é garantir que exista um acordo de nível de serviço, planejado por todas as áreas de TI bem como com o cliente final. Logicamente não basta existir um SLA (Service Level Agreements), ele deve ser cumprido, mas o fato de existir algum SLA já é o primeiro passo, por que significa que o mesmo foi discutido dentro da área de TI bem como com o cliente.

O SLA é útil para garantir que os serviços entregues atendem às expectativas de negócios, as metas de desempenho e os custos necessários para a entrega de um determinado serviço de TIC a um conjunto de clientes. Um SLA eficaz reflete a comunicação entre os clientes e usuários (os consumidores do serviço) e deverá traduzir-se na tabela de indicadores. Os objetivos de nível de serviço que são identificados, em seguida, serão usados para desenvolver e personalizar o scorecard de aderência para o serviço.

O SLA deve ser balanceado entre ser relevante e factível. Em geral, a disponibilidade desejada por todos é de 100%, mas isso, infelizmente, é irreal. O SLA deve conter um objetivo relevante a ponto de atingir o nível de serviço realmente necessário e exigido pelo negócio, mas também deve ser possível de ser entregue, não pode conter premissas ou promessas irreais.

Um SLA deve possuir a descrição e definição, em linguagem clara para o cliente, de todos os pontos importantes sobre o serviço de TIC. Por exemplo, descrição do serviço, seus requerimentos, necessidades de dados de entrada, saídas esperadas, horários de funcionamento do serviço, tempos de atendimento ao usuário em caso de problema, disponibilidade total esperada, tempo de retorno em caso de indisponibilidade, etc.

Cálculo de Disponibilidade

Um dos pontos mais comuns de ser descrito em um SLA é a disponibilidade esperada do serviço. Um indicador comum usado para medir a disponibilidade é o percentual de tempo que um serviço foi capaz de servir aos seus clientes e usuários.

  • Percentagem de disponibilidade = Tempo Total em Serviço / Tempo Total Esperado em Serviço

No caso de um serviço que é esperado que funcione 24 x 7, o tempo total esperado, no ano, é de 24 horas x 365 dias = 8760 horas.

Em geral, a disponibilidade desejada por todos é 100%, mas isso, infelizmente, é irreal. Num caso mais realista, a disponibilidade nos SLAs é medida em “noves”, ou seja, quantos “noves” no percentual são esperados. Um serviço que é esperado “3 noves” deve ter disponibilidade de 99,9%.

A tabela abaixo mostra os cálculos de disponibilidade em relação a um serviço 24×7, com base anual.

% Disponibilidade Horas Totais no Ano (24×7) Tempo máximo de indisponibilidade Horas Totais no Ano (8×5) Tempo máximo de indisponibilidade
90% 8760 horas 876 horas (36,5 dias) 2086 horas 208.6 horas (26 dias)
95% 8760 horas 438 horas (18,3 dias) 2086 horas 104 horas (13 dias)
99% (2 noves) 8760 horas 87 horas (3,6 dias) 2086 horas 20,86 horas (2,6 dias)
99,9% (3 noves) 8760 horas 8,76 horas 2086 horas 2 horas
99,99% (4 noves) 8760 horas 52,56 minutos 2086 horas 12,5 minutos
99,999% (5 noves) 8760 horas 5,3 minutos 2086 horas 1,25 minutos

Como pode ser reparado na tabela de tempos de indisponibilidade, o tempo máximo aceitável de indisponibilidade é alterado com a alteração do tempo total esperado de serviço (janela de funcionamento do serviço). No caso de um serviço em horário comercial (8×5), uma queda do sistema durante a madrugada, com o serviço voltando a funcionar antes ainda do horário comercial não afeta o cálculo de disponibilidade para efeitos do SLA, por que o serviço não tinha a obrigação de funcionar fora da sua janela estipulada.

O que deve ser considerado para confecção de um SLA?

A Microsoft recomenda considerar os seguintes pontos quando da criação e manutenção de SLAs e medições de disponibilidade:

  • Necessidades reais de negócio – Os custos de alcançar maior disponibilidade podem não valer a pena considerando os benefícios reais necessários. Analise a real disponibilidade de serviço de TIC que sua empresa realmente precisa antes de definir metas. Ter sempre meta de 24×7 com 99,999% de disponibilidade pode ser desejável para todos os serviços, mas obriga um enorme investimento em pessoas, processos e tecnologia a fim de atingir esse nível e poucos serviços realmente precisam disso.
  • Correta granularidade – Um sistema de TI, seja qual for, tem múltiplas medições e monitorações de disponibilidade, e não simplesmente funcionando e parado. Partes distintas podem estar funcionando enquanto outras podem ter algum problema de disponibilidade. Uma regra simples, clara e justa deve ser alcançada para que o cálculo não seja mais custoso que a informação resultante deste.
  • Responsabilidade e Cobrança – uma pessoa ou time deve ser responsável por cada medição, e deve ser garantido poder de decisão necessário para que seja feito o que é necessário para controlar o serviço e respeitar os SLAs.
  • Riscos Ordinários e Extraordinários – Falha de disco ou memória, bem como rede e falta de energia são riscos ordinários, previsíveis, que são parte do cotidiano. Você sabe que os enfrentará mais cedo ou mais tarde e deve se planejar para quando isso ocorrer. A maior probabilidade de indisponibilidade pode ser tratada analisando e previnindo riscos ordinários.
    O tipo de planejamento a ser feito para riscos extraordinários é bem diferente e deve inclusive levar em conta risco de perda de pessoal e instalações. São eventos mais raros e especiais, mas que devem ser avaliados se vale a pena prevení-los ou apenas conhecê-los e preparar reação em caso de ocorrência. Isso vai depender do custo da prevenção e também da quantidade e importância dos recursos envolvidos pelo risco.
  • Escopo e tolerâncias – métricas rígidas e absolutas podem trazer mais malefícios do que benefícios. Atritos entre áreas, avaliações e auditorias no cálculo do SLA e outros fatores podem ser resultados de intolerâncias. Em geral, recomenda-se trabalhar com médias e desvio padrão para cálculos de indicadores de SLA.
  • Mensurabilidade – cada item do SLA deve ter um indicador e meta determinada. O SLA deve ser oficializado em cima de valores trangíveis e objetivos, nunca sobre avaliações pessoais e subjetividade. Termos como “melhor”, “mais disponível”, “total”, etc. devem ser evitados, dando-se preferência para “10% de melhoria a cada ano”, ou ainda, “99% de disponibilidade claculada sobre a fórumula XXX =YYY / ZZZ”.
  • Margens de Erro – um outro aspecto da capacidade de medir algo é a margem de erro de medição. Por exemplo, a Microsoft possui dezenas de Active Directory Domain Controllers e Exchange Servers espalhados pelo mundo em diversos datacenters. Sincronização de horário entre todos os serviodres pode levar um certo tempo e ainda assim acontecer com pequenas diferenças de horário. Uma mensagem de ping pode ter o seu horário de chegada, visto por um servidor, milisegundos antes do seu horário de saída. Sabemos que isso é impossível, logo deve-se ao fato de sincronização e outros detalhes inerentes a distribuição e às margens de erro de medição. As objetivos de nível de serviço não devem ser tão pequenos e precisos que sejam da mesma ordem de grandeza que a margem de erro de medição.

Reunião de Revisão de Nível de Serviço

Conduzir uma reunião regular de Revisão de Nível de Serviço é uma forma importante de entender o estado atual do serviço. A revisão frequente dos dados atingidos mantém o foco de trabalho nos mais importantes indicadores de negócio, bem como pode alertar com boa antecedência para eventuais desvios aos objetivos dos SLAs.

Após a documentação e formalização do serviço do SAJ com mapa de serviço, SLAs, OLAs, e a tecnologia totalmente revisada e corretamente configurada, a manutenção dos níveis de serviço requerem criação de:

  • Procedimentos operacionais para todos os componentes do serviço, a fim de garantir que todas as engrenagens estão funcionando corretamente, e de suporte, a fim de garantir que o atendimento ao usuário está sendo feito conforme o acordado no SLA;
  • Disciplina e comprometimento do time a fim de colocarem em prática uma reunião de Revisão de Nível de Serviço com frequência mínima quinzenal.

Fonte: Ronaldo Smith Jr

Perda de dados custa às empresas brasileiras US$ 26 bilhões em 12 meses

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Companhias tiveram 17 horas de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos

A perda de dados e tempo de inatividade custou aproximadamente US$ 26 bilhões às empresas brasileiras no último ano. Mundialmente, o montante foi de US$ 1,7 trilhão. É o que apontou um estudo encomendado pela EMC, que indica que 62% dos profissionais de TI do Brasil não confiam integralmente em sua capacidade de recuperar informações após um incidente.

Além disso, 61% das organizações não têm plano de recuperação de desastres para cargas de trabalho emergentes; e apenas 4% têm planos para big data, nuvem híbrida e dispositivos móveis. De acordo com o levantamento, “nenhuma das organizações do Brasil são ‘Líderes’ em proteção de dados; 9% são ‘Adotantes’; 91% estão desatualizadas”, informa a fabricante.

Apesar de o número de incidentes estar em queda, o volume de dados perdidos por incidente cresce exponencialmente. De acordo com o estudo, 59% das empresas pesquisadas passaram por perda de dados ou tempo de inatividade nos últimos 12 meses.

Na média, as empresas tiveram 17 horas (mais de dois dias de trabalho) de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos.

Segundo a pesquisa, empresas com três ou mais fornecedores perderam quase cinco vezes mais dados em comparação com as que têm estratégia de um só fornecedor.

“As empresas com três fornecedores também tenderam a gastar, em média, US$ 15 milhões a mais na infraestrutura de proteção de dados, em comparação com as que têm apenas um”, informa o relatório.

O EMC Global Data Protection Index, realizado pela Vanson Bourne, pesquisou 3,3 mil responsáveis por decisões de TI de médias a grandes empresas em 24 países entre agosto e setembro de 2014.

Fonte: Site Computerworld

SOLUÇÃO DO DESAFIO DO GORDO – Qual a função do Ghost Cleanup?

Vitor Fava

Galera,

Resolvi responder nosso último DESAFIO DO GORDO utilizando o XEvents para demonstrar o funcionamento do Ghost Cleanup e explicar qual sua finalidade e possíveis problemas de performance que pode causar.

Caso tenham interesse em reproduzir o cenário descrito no vídeo, basta utilizar o script abaixo:

Espero que gostem e aproveitem também para inscreverem-se no blog, no canal do youtube e no grupo de discussão SQLManiacs.

Grande abraço.

Ver o post original

Azure Premium Storage… Testes com SQLIO

Blog - Fabiano Neves Amorim

Fala galera, faz tempo eim?

Bom, semana passada fiz uns testes em um cliente acho que a informação vai ser útil pra vocês.

Esse é um cliente que sofria demais com a péssima performance dos discos do Azure, todo a sua infra-estrutura de banco de dados está em VMs.

Depois de aplicar várias técnicas para minimizar o custo e melhorar a performance das operações de I/O, finalmente o storage premium ficou disponível (só pra País de primeiro mundo, adivinha se tem no Brasil?…) para compra, e conseguimos migrar tudo para o novo storage. Porém ficávamos sempre com aquela dúvida, e ai, vai melhorar mesmo? Quantos %? Qual a diferença de performance dos discos? … Para responder essas nossas dúvidas e ter certeza de que o novo storage está melhor, fiz alguns testes com SQLIO e criei alguns gráficos.

Antes de te mostrar os gráficos, deixa eu mencionar algumas técnicas que…

Ver o post original 331 mais palavras

Dicas para um DBA Iniciante – Criando um plano de manutenção

Vitor Fava

Galera,

No vídeo de hoje quero demonstrar como criar um plano de manutenção para executar as tarefas e checagens recomendadas em um ambiente de banco de dados SQL Server.

Espero que gostem e aproveitem para inscrever-se no blog, no canal do youtube e no grupo de discussão SQLManiacs.

Grande abraço a todos.


Ver o post original

%d blogueiros gostam disto: