Índice:
Por Techopedia Staff, 9 de maio de 2016
Takeaway: O apresentador Eric Kavanagh entrevista Mark Madsen, Dez Blanchfield e Bullett Manale sobre latência e desempenho.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Parceiro de conteúdo Techopedia
A equipe do Techopedia é afiliada ao Bloor Group e pode ser contatada usando as opções à direita. Para informações sobre como trabalhamos com parceiros do setor, clique aqui.- Perfil
- Local na rede Internet
Eric Kavanagh: Senhoras e senhores, olá e bem-vindos de volta à Hot Technologies! Sim, de fato! Meu nome é Eric Kavanagh, este é o nosso programa Hot Tech, uma parceria com nossos bons amigos da Techopedia. Entre on-line no Techopedia.com para obter as últimas novidades no amplo campo da tecnologia corporativa; eles, é claro, cobrem também itens de consumo. Nós nos concentramos na empresa aqui em nosso programa, e é isso que faremos hoje.
Há um ponto sobre o seu verdadeiramente e o suficiente sobre mim, me escreva no Twitter @eric_kavanagh, adoro o Twitter, adoro conferir essas coisas, é uma ótima maneira de ficar em contato com as pessoas e ter boas conversas, e assim por diante uma conversa.
Então, do que estamos falando? Este ano é quente, é todo um universo de oportunidades que olhamos hoje no mundo do gerenciamento de informações, e o que estamos falando hoje será consultas, acelerando consultas.
Acho que esqueci de mencionar o título, "Performance Play: Diga adeus à latência". Bem, quem quer latência? Ninguém quer latência, latência é quando você fica sentado, clica no botão e espera que algo aconteça, e ninguém quer isso. As crianças não gostam, não acham legal, os adultos também não gostam. Todos nós fomos prejudicados pela velocidade da web, e queremos coisas rapidamente, queremos agora, e falaremos sobre isso hoje em nosso programa.
O analista Mark Madsen está hoje conosco da Third Nature, um de nossos frequentadores regulares. Nosso novo cientista de dados, Dez Blanchfield, ligando de Sydney, na Austrália. E então Bullett Manale, sim, de fato, esse é o nome dele, na verdade deveria ser dois T's. Bullett Manale é o convidado da Idera, uma empresa muito, muito interessante, que faz muitas coisas. Eu já os conheço, e um deles comprou uma empresa chamada Precise há um tempo. Eu sabia que o CEO deles, Zohar Gilad, como é esse o nome? Ele era um cara inteligente.
Mas, pessoal, você desempenha um papel significativo neste webcast nas perguntas que você faz; portanto, não se acanhe, envie suas perguntas a qualquer momento - você pode fazê-lo usando o componente de perguntas e respostas do console de webcast, que está lá em baixo no canto inferior direito. Você também pode conversar comigo e eu converso com os palestrantes. Já temos alguém ligando da Itália, então, “Ciao, ciao. Come stai? ”Tudo bem, com isso eu vou empurrar a primeira linha de Mark, vou entregar o baralho para Mark. Mark, agora você tem o WebEx. Leve-o embora, o chão é seu.
Mark Madsen: Obrigado, Eric. Não vou começar pelo meio, vou começar pelo começo. Apenas alguns comentários para iniciar a discussão com Dez e Idera, uma espécie de estado do estado com desenvolvimento, bancos de dados e operações. E você sabe, se você olhar para isso, ainda temos esse tipo de problema de dois mundos no mercado de banco de dados e aplicativos, porque os desenvolvedores veem os DBAs como as pessoas que os incomodam. Você precisa criar modelos de dados, não pode ter acesso a isso, não pode criar aquilo, não pode colocar um índice em todas as colunas de todas as tabelas do banco de dados para torná-lo mais rápido. E, claro, por que precisamos dos modelos? São apenas estruturas de dados, se as alterarmos, você não pode simplesmente escrevê-las em um formato serializado?
O problema é que os desenvolvedores conhecem código e aplicativos, mas duas coisas que geralmente não sabem são concorrência, programação simultânea e bancos de dados e os sistemas operacionais subjacentes a eles. Como desenvolvedor de kernel, sistemas operacionais e bancos de dados, posso dizer que simultaneidade e paralelismo são realmente difíceis, e muitas das coisas que você aprende para obter um bom desempenho do seu código começam a desmoronar quando você está trabalhando com um banco de dados. E o desempenho parece ótimo, o ambiente de teste parece ótimo e o ambiente de perguntas e respostas, e depois atinge o sistema real e, de repente, não é tão bom. Por ser multifacetado, como o código funciona com o banco de dados, como funciona com o ambiente e práticas muito simples podem ter efeitos drásticos, dependendo de qual escala você está executando.
E quando você começa a falar sobre aplicativos externos, é claro, aplicativos voltados para o exterior, aplicativos da Web, podem ser realmente difíceis, porque as coisas ficam ótimas até que de repente elas ficam planas, e não são. Você atingirá esses planaltos interessantes que exigem muitas nuances para entender.
O outro lado das coisas é a visão do DBA. A visão do DBA é que existem operações, elas passam a maior parte do tempo, 80 a 90% em operações, e talvez 10 a 20% lidando com as coisas de desenvolvimento que estão acontecendo antecipadamente. Dessa perspectiva, você paga agora ou mais tarde e, se estiver gastando todo o seu tempo adiantado, terá uma chance muito melhor mais tarde, em oposição ao desenvolvimento que tende a explorar um recurso espaço e tentando descobrir a melhor maneira de fazer as coisas. E, portanto, temos problemas, e agora temos metodologias incompatíveis - implantação contínua, acumulando seus aplicativos sempre que estiverem prontos, executando o envio periódico de código, trabalhando em uma loja que pratica desenvolvedores. Esse tipo de coisa acelera o desenvolvimento, mas todas as práticas em torno do banco de dados e o que os DBAs fazem e para que os gerentes de sistema foram treinados, as práticas de operações de TI não acompanharam o ritmo.
Se você pensar bem, a maioria dos DBAs opera em um ambiente de controle de alterações, em comparação com um ambiente de implantação contínua. É tudo sobre estabilidade e controle, versus velocidade de mudança e reversibilidade. Implantação contínua, se você não pode desistir da mudança, está com problemas, então tudo precisa ser construído para ser facilmente reversível e comutável por código, o que não é o modo como o banco de dados relacional, as práticas de desenvolvimento e as práticas de gerenciamento funcionaram. .
Você também está enfrentando esses problemas de ter que ser mais proativo, se puder, como DBA, porque, quando você ouve sobre um problema, cem mil pessoas estão preenchendo formulários de reclamação em seu site. Isso faz com que você precise de coisas novas que você não sai do seu ambiente antigo. Você sabe, coisas como melhor monitoramento e alerta. Ao mesmo tempo, os bancos de dados estão se multiplicando, temos mais aplicativos do que nunca para oferecer suporte a mais coisas do que nunca, eles estão dentro, estão fora, estão por toda parte. E com conjuntos de dados mais independentes para análises, as pessoas estão iniciando bancos de dados por toda a parte porque, é claro, agora é fácil, você pode configurar uma máquina virtual. Se você possui um provedor de nuvem ou uma nuvem interna, pode abrir as coisas imediatamente, e isso altera todo o caminho de compra.
O antigo caminho das compras era: "Tenho tempo para obter um servidor, colocá-lo em um rack, alocar espaço, obter armazenamento, instalar o banco de dados e fazer as coisas", em comparação com alguém passando o cartão de crédito e indo em cinco minutos. Se você fizer isso, esse ambiente de desenvolvimento moderno estará operando em um ritmo muito diferente e, portanto, é fácil criar bancos de dados, e isso apenas cria esse problema de proliferação, como nada que já vimos antes. E isso já dura dez anos, isso não é novidade para ninguém, mas também significa que os ambientes operacionais cresceram em complexidade.
Todo o ambiente do servidor cliente realmente mudou, porque não é mais um mundo de servidores cliente. Naquela época, você tinha um servidor, um banco de dados. Se algo estava errado, você sabia para qual servidor ir, sabia como gerenciar os recursos, porque a melhor prática era um banco de dados, um servidor. A virtualização começou a dividir isso, a nuvem o divide ainda mais, porque o que você acha que é um servidor de banco de dados, é apenas software. Então o ambiente não é real. É o que contém o ambiente que é a realidade, e pode ser um rack de lâminas ou um grande servidor dividido em pedaços, você realmente não sabe.
Tudo sobre administração de banco de dados e gerenciamento de desempenho e quais bancos de dados foram construídos com controle rígido com um servidor ou um punhado de servidores e alguns bancos de dados, você não pode controlar tudo. Você está sentado em uma máquina, mas a largura de banda não pode ser particionada facilmente pelos gerenciadores virtuais; portanto, tudo pode ficar bem com a memória e a CPU, mas você está com um gargalo em algum recurso que não pode ser tratado e, em seguida, quando Se você tentar consertá-lo, o modelo antigo estaria trabalhando duro, obtendo um servidor maior e fazendo algo assim, agora poderia ser muito simples, basta adicionar um curso virtual, apenas adicionar memória à VM e está resolvido. Mas o que acontece se sua VM estiver em um servidor superlotado e precisar migrar? Ou o que acontece se você tem o tamanho de um sistema AWS e o tamanho máximo foi atingido, agora para onde você vai?
Então você tem todos esses problemas em que o ambiente faz parte do banco de dados agora, você empacota um ambiente com um banco de dados, todos os recursos especiais, tudo no aplicativo faz parte da configuração, a configuração é empurrada para fora. Isso é do ambiente de banco de dados, é muito mais difícil de gerenciar e controlar.
Se você observar o que os centros de banco de dados estão fazendo, eles estão sentados em suas mãos, certo? Estamos nos afastando dessa ideia de tratar bancos de dados e servidores como animais de estimação. Servidores têm nomes, você os trata como se fossem coisas únicas, você os trata como gado, está gerenciando um rebanho. E o problema com o gerenciamento de rebanhos é que, se você não os controlar, eles poderão eventualmente debandar, e uma debandada não é uma coisa boa. Precisamos de melhores ferramentas de monitoramento, precisamos de melhores maneiras de lidar com essas coisas e sabemos o que foi afetado. No modelo antigo, era mais fácil porque suas operações e todos os seus sistemas de controle informavam, mas quando o nome do servidor é um código UPC, é meio difícil descobrir as coisas.
Você não pode pagar alertas falsos, não pode comprar coisas que dizem: "Há um problema com esta máquina e essa máquina hospeda 30 bancos de dados". Você não pode se dar ao luxo de ter coisas sem histórico. Os consoles de monitoramento são ótimos quando acendem, mas se a luz vermelha ficar verde novamente e você não souber o porquê, e você não tiver nenhum histórico para analisar o que estava levando a isso, e quais contexto era, você está com problemas. Precisamos de sistemas que nos monitorem, precisamos de um melhor monitoramento, lidando com os problemas intermitentes cursivos que mantêm esse histórico de dados.
Coisas melhores e limites simples de métricas que nos fornecem métricas importantes, mas não nos guiam diretamente para o que é normal, o que é anormal e a frequência com que esses problemas ocorrem. Na verdade, estamos falando de uma combinação de ambiente de monitoramento e de lidar com desempenho, e os fornecedores estão sentados em suas mãos. Eles não nos deram ferramentas melhores. Temos sistemas com mais CPU e memória do que sabemos o que fazer com tudo isso, e ainda assim confiamos em modelos de intervenção manual, não colocamos a máquina em funcionamento, nos guia, nos leva ao ponto de problemas, não chegamos a esse novo estilo, que é "Há um problema aqui, você pode fazer isso para corrigi-lo" ou "Há um problema de desempenho, na verdade é com essa instrução SQL específica; aqui estão três coisas que você poderia fazer" use para corrigir essa instrução SQL. ”Aplicando heurísticas, aplicando modelos de aprendizado de máquina que podem observar os padrões de uso do seu sistema para detectar problemas e evitar alertas falsos. Usando a máquina para fazer o que ela faz de melhor, para aumentar o DBA ou para aumentar a pessoa que precisa lidar com problemas de desempenho.
Essa é a nova maneira, em oposição ao estilo antigo. Há um problema com esse banco de dados, as coisas são lentas e, por isso, temos novas técnicas, novas maneiras de fazê-lo, e devemos aplicá-las, e é para lá que o mercado está caminhando. Você está vendo isso começar a surgir, não com os grandes fornecedores, mas com empresas de terceiros, e isso está refletindo algo que aconteceu 20 anos atrás, quando os fornecedores de banco de dados não forneceram nada para ajudar a gerenciar os sistemas. Então é assim que é a direção do mercado e, com isso, gostaria de devolvê-lo a Eric.
Eric Kavanagh: Tudo bem, vou entregá-lo para Dez. E Dez, leve embora, o chão é seu.
Dez Blanchfield: Obrigado, Mark. Você fez um trabalho fantástico ao cobrir o componente técnico dele. Vou abordar isso de um ângulo um pouco diferente para destacar o que aconteceu no resto do mundo, no que diz respeito ao impacto nas empresas e nos bancos de dados ao seu redor. Deixe-me pular para o meu primeiro slide.
Por trás do que você acabou de abordar do lado técnico e do desenvolvedor, estou vendo empresas tendo que enfrentar o desafio de dados e bancos de dados em particular, e obviamente tivemos essa mudança significativa no sentido de esse conceito de big data, mas os bancos de dados efetivamente ainda são o coração e a alma de onde as organizações retêm suas informações de negócios, desde a porta da frente até o back office. Cada parte da organização é tocada por um banco de dados de algum tipo e alimentada por um banco de dados, e muito raramente eu participo de discussões de projetos ou de alguma forma de conversa estratégica inovadora em uma organização onde o tópico do banco de dados ou sistema de banco de dados não surge, e sempre há perguntas sobre os tipos de coisas que acabamos de ouvir sobre desempenho e segurança e como o desenvolvimento aborda esse desafio, onde os bancos de dados se encaixam e nossa percepção dos ambientes e aplicativos. ambientes com os quais conversar, e quanto a dispositivos e mobilidade?
Ainda é um tópico muito, muito quente, e há muito, muito tempo, no grande esquema das coisas, no que diz respeito à tecnologia moderna. Até esse ponto, acredito que é fato que quase tudo o que fazemos em nossas vidas cotidianas, ou seja, em nossas vidas diárias, agora está sendo suportado por alguma forma de banco de dados. Quando pensamos em tudo o que está à nossa volta, seja uma conta que é enviada diariamente pelo correio para algum serviço que estamos comprando, ela está inevitavelmente sendo impressa por um sistema que está conversando com um banco de dados e estamos lá. Nossos telefones possuem bancos de dados com os contatos, registros de chamadas e outras coisas.
Onde quer que vamos, há alguma forma de banco de dados por trás da conversa e dos sistemas que estamos usando, e na maioria das vezes eles são bastante transparentes para nós, mas o fato é que eles estão lá. Por isso, pensei em abordar rapidamente por que isso se tornou um pouco problemático em um período muito curto de tempo. No começo, o conceito de banco de dados veio desse adorável senhor, Edgar Codd. Enquanto trabalhava na IBM, ele mudou o mundo no que diz respeito ao gerenciamento de dados, criando um conceito ao qual nos referimos agora como um banco de dados relacional.
No começo, o banco de dados era um banco de dados e a vida era boa, era bastante direta tanto em colunas quanto em referências, e assim por diante, e tabelas, e o desenvolvimento de software era bastante direto, e o desempenho não era tão grande assim - era uma nova tecnologia emocionante. Acessamos os bancos de dados por meio de algum tipo de terminal, e você realmente pode criar muita confusão no final de um terminal 3270 em um mainframe e, invariavelmente, outros tipos de terminais, esses outros sistemas surgiram. E na maioria dos casos, os terminais de estilo antigo eram muito parecidos com o que os ambientes da web são agora, e isso significa que você preencheu um formulário na tela do próprio terminal e pressionou Enter e desligou. disparar como um pacote, como uma solicitação, e o sistema de back-end lidaria com isso. É basicamente o que acontece em um navegador da Web atualmente, quando você digita um link em um navegador da Web e esse formulário geralmente não volta em tempo real ao sistema, embora com o AJAX atualmente, esse não seja o caso.
Mas então aconteceu algo, o futuro chegou e, mais recentemente, a Internet, e quase ontem, em um segundo web 2.0, e logo na esquina, temos a Internet das Coisas. E no processo do futuro, o mundo do banco de dados explodiu e as interações com os bancos de dados tornaram-se algo que todos nós fizemos por padrão, não era o caso de você ir a algum lugar para fazer algo, como comprar um bilhete para um avião e quiser viajar para o outro lado do planeta, alguém teve que digitar no terminal todos os seus detalhes e acessar um banco de dados e imprimir um bilhete.
Quase tudo o que fazemos agora, seja um táxi no Google com um aplicativo, seja um serviço de Internet banking, tudo o que fazemos no dia-a-dia, com algum tipo de sistema, é alimentado por um banco de dados. E quando a Internet surgiu, isso foi um pouco mais fácil de trazer para nós, nossa vida cotidiana por meio de um navegador da Web e, em seguida, a Web 2.0 apareceu e as coisas se tornaram móveis, e a escala das coisas explodiu. De fato, minha linha favorita neste tópico é que, "A Internet conectou tudo, a Web 2.0 tornou móvel e social, e as coisas ficaram muito, muito grandes e agora temos a Internet e as coisas e, e a IoT … Caramba!" Nem começamos a imaginar o impacto da Internet das Coisas quando se trata do mundo nos sistemas de banco de dados.
Então, em termos modernos, o que costumávamos considerar um terminal tornou-se efetivamente essas coisas: telefones celulares, vários tipos de tablets, tablets de tela grande de uso pessoal ou corporativo, laptops e a área de trabalho tradicional de alguma forma. Nessa imagem, você pode ver quase todas as formas de interface que estamos usando agora para conversar com sistemas e aplicativos de banco de dados que são alimentados por eles, desde os pequenos gadgets em nossas mãos que andam por aí e que parecemos estar colados a tudo o caminho para as versões um pouco maiores, iPads e outros tablets e Microsoft Surfaces, para laptops comuns, que invariavelmente agora são o caso em ambientes profissionais e assim por diante. As pessoas tendem a ter um laptop e não uma área de trabalho fixa, mas são, na minha opinião, o terminal moderno e parte do motivo pelo qual os bancos de dados estão enfrentando todos os tipos de desafios na parte do desempenho do gerenciamento de nossas vidas, e não apenas no desenvolvimento.
Portanto, presumo que seja um dos maiores desafios que as empresas ainda enfrentam no dia-a-dia. Todos pensavam que os bancos de dados eram nossos únicos problemas, não são. Então, por que todo esse barulho? Bem, quando passamos de um extremo ao outro com todas as coisas relacionadas aos bancos de dados, do ponto de vista comercial, e o Mark cobriu os componentes técnicos muito, muito bem, mas no sentido comercial, como organização, pensamos nos bancos de dados. Estamos lidando com tudo, desde o front end básico de design e desenvolvimento. Quando uma empresa inicia, eles pensam em desenvolver aplicativos, desenvolver um recurso ou até mesmo implementar um aplicativo existente de alguma forma. Alguma forma de design e desenvolvimento precisa ocorrer e é preciso pensar muito em como esses sistemas de banco de dados serão implementados, suportados e gerenciados, e os desempenhos rastreados e assim por diante.
A integração do ambiente e dos aplicativos de banco de dados e os tipos de API, os tipos de acesso que estão sendo fornecidos agora estão ficando cada vez mais desafiadores, mais complexos. Administração, suporte e backups diários, novamente, são coisas que pensávamos que foram resolvidas, mas, de repente, a escala ficou muito maior e as coisas mudaram mais rapidamente, e o volume é muito maior; o tamanho dos ambientes, os sistemas de banco de dados precisavam suportar a velocidade com que as transações estavam se movendo.
Pense em um banco de dados em um ambiente de negociação de frequência muito, muito alta. Não há como os seres humanos acompanharem isso, é apenas um cluster de máquinas lutando contra outro cluster de máquinas para realizar transações, compras e vendas em alta frequência e o volume em quais essas transações acontecem. Pense em um cenário moderno, como o lançamento antecipado de um filme da Netflix, no qual você não está falando apenas de centenas ou milhares, ou mesmo centenas de milhares, potencialmente milhões de pessoas que desejam ver esse filme a partir do momento em que foi lançado. Todas essas informações são capturadas, rastreadas, registradas e analisadas em uma plataforma de banco de dados.
E depois há o mundo sempre ativo em que vivemos agora, 24 horas por dia, 7 dias por semana, não apenas siga o Sol, mas sempre há alguém acordado à meia-noite querendo fazer alguma coisa, e o horário comercial segue o Sol em todo o mundo. Portanto, o tempo de atividade e a disponibilidade são, por padrão, um clima agora, ter uma interrupção realmente não é algo aceitável. E redundância, se houver um problema de desempenho ou se precisarmos de uma janela de manutenção para fazer uma atualização, um patch ou uma segurança, precisamos poder cortar de um ambiente de banco de dados para outro e fazê-lo de maneira integrada e automática.
Segurança e padrões e conformidade, tivemos algumas coisas bem grandes no mundo ultimamente, em especial a GFC, e por isso temos uma série de novos desafios a serem enfrentados em relação à conformidade, segurança e padrões correspondentes, e precisamos para poder relatar sobre eles em tempo real e, idealmente, em forma de painel. Não queremos enviar uma equipe de macacos para um data center tentando encontrar coisas, precisamos que o sistema nos diga isso imediatamente, em tempo real.
E os dois grandes e divertidos sobre os quais quase ninguém fala, geralmente os empurram para debaixo do tapete e esperamos que eles nunca levantem a cabeça feia, mas a recuperação de desastres e a continuidade dos negócios - essas são também as coisas que deveriam, por a maior parte ocorre automaticamente, se necessário.
Poderíamos passar dias conversando sobre os tipos de coisas que podem dar errado em ambientes de banco de dados e que os humanos geralmente respondem, mas agora precisamos de sistemas e ferramentas para fazer isso por nós. Um exemplo é a violação de dados e, portanto, quando pensamos em bancos de dados, e faço essa pergunta abertamente de várias formas: o que acontece com os bancos de dados quando tiramos os olhos da bola e algo crítico dá errado? Especialmente se não houver um sistema observando desempenho e segurança e outros aspectos importantes da execução de bancos de dados.
Bem, o que poderia acontecer é isso, esta é uma captura de tela de algumas das violações recentes nos últimos dois a três anos. Invariavelmente, todos eles vêm de um sistema de banco de dados e, invariavelmente, houve algum problema de segurança ou controle ou acesso, e no canto superior esquerdo, estamos vendo 152 milhões de contas da Adobe, onde todos os detalhes desses clientes foi violado. E se as ferramentas apropriadas estivessem em vigor para rastrear e capturar o incidente e controlar a segurança, podemos ter evitado alguns deles, as primeiras centenas de registros roubados podem ter nos alertado, e teríamos parou os próximos cento e cinquenta milhões.
Então chegamos ao ponto principal de toda essa jornada, levada a cabo, ou seja: por que precisamos de sistemas melhores? Por que não podemos simplesmente jogar mais corpos nessa coisa, que atravessamos bem e verdadeiramente o ponto de inflexão na minha opinião, e certamente acredito que há um caso que tem sido evidência ultimamente, de que lançamos mais DBAs, administradores e mais pessoas em isso não resolve o problema. Precisamos de um melhor conjunto de ferramentas e um melhor conjunto de sistemas.
Aqui estão meus cinco principais motivos pelos quais acredito apoiar isso, e eles são classificados em ordem de importância, com base no que estou vendo nessas empresas e estados privados que são ambientes controlados, nos desafios que enfrentam nos ambientes de banco de dados, e gerenciá-los.
Segurança e conformidade - número um. Você sabe, controlando quem tem acesso, de onde eles têm acesso, quando têm acesso, com que frequência eles têm acesso, de onde eles acessaram. Potencialmente, os dispositivos em que eles realmente tocaram e os tipos de coisas que eles visualizaram e a conformidade com isso. Ter seres humanos executando relatórios 30 dias depois para nos dizer se as coisas estão bem simplesmente não é mais apropriado, isso precisa acontecer em tempo real.
Desempenho e monitoramento - parece um acéfalo, mas invariavelmente não é. Independentemente de estarmos usando ferramentas de código aberto ou algumas ferramentas comerciais de terceiros, invariavelmente não perdemos o barco, de muitas maneiras, com os tipos de monitoramento de desempenho necessários e os detalhes e a capacidade de responder a tempo .
Detecção e resposta a incidentes - tem que ser uma coisa instantânea em tempo real e, invariavelmente, precisamos de um sistema para fazer isso por nós, ou pelo menos nos alertar rapidamente para que possamos lidar com isso, para que os poucos problemas que surgirem sejam tratados com rapidez e não fique fora de controle.
Gerenciamento e administração - novamente, pensamos que esses problemas foram resolvidos, não são. O objetivo dos problemas enfrentados pelas equipes de banco de dados, principalmente os DBAs em que um sistema deve cuidar de nós, ainda não resolvemos esse problema, ainda é uma coisa real.
E desde o front-end com design e desenvolvimento, quando começamos a criar essas ferramentas, criamos os ambientes de banco de dados, podemos lançar as ferramentas apropriadas nas plataformas de desenvolvimento e teste e integração. Isso ainda não é algo fácil para nós, e toda essa jornada nos leva à mesma mensagem: que, em minha opinião, precisamos de sistemas e ferramentas melhores para nos ajudar a obter os resultados de que precisamos. nosso ambiente de banco de dados; portanto, as empresas que estão agregando valor aos nossos clientes. Não podemos continuar jogando mais corpos e mais DBAs, a balança é muito grande, a velocidade é muito rápida e o volume é muito alto. Com isso, Eric, posso passar para você.
Eric Kavanagh: Eu amo isso, temos muito terreno coberto por lá, pessoal, muitas pistas em potencial, e vamos em frente e entregamos as chaves para Bullett em apenas um segundo.
Bullett Manale: Tudo bem.
Eric Kavanagh: Oh, vamos tirar isso e Bullett, agora estou entregando a você, e a palavra é sua.
Bullett Manale: Tudo bem, obrigado. Eu acho que muitos pontos positivos foram feitos. Eu queria falar rapidamente por apenas um segundo sobre Idera, quem somos, e depois vamos pular. Vou falar sobre a ferramenta na qual penso que muitas dessas coisas que estamos falando, podemos tipo de conjunto e tipo de discussão sobre algumas das áreas em que elas alinham, com essa ferramenta, o produto Diagnostic Manager.
Agora, o que eu quero fazer primeiro, é apenas dar uma idéia de quem é Idera; estamos no mercado desde 2003 e, portanto, começamos com apenas as ferramentas do SQL Server, e é nisso que vamos focar hoje, seria o produto Diagnostic Manager. Mas você pode ver todos os itens que temos aqui, e recentemente, como mencionado anteriormente, adquirimos o Precise e, através da aquisição, também temos o Embarcadero, e por isso temos um bom portfólio de produtos.
Em termos de monitoramento de desempenho, em termos do SQL Server, o produto sobre o qual quero falar, que alinha esses tópicos que estamos discutindo, é o Diagnostic Manager. Agora, este é um produto que existe desde bem próximo ao início dos dias de Idera, e tive a sorte de fazer parte disso desde cerca de 2005. E eu já vi muitas mudanças em termos de SQL Server, a mudança do físico para o virtual, todo esse tipo de coisa que aconteceu, e também as necessidades dos DBAs à medida que os ambientes crescem e esses tipos de coisas.
O que eu comecei foi o usuário típico do nosso produto é o DBA e, portanto, quando estamos conversando com pessoas pela primeira vez, com possíveis clientes, são principalmente os DBAs com quem estamos conversando. Não estamos conversando com os gerentes de TI, nem com os diretores, pode chegar a esse nível em algum momento, mas o início inicial é que o DBA tem um problema, o DBA tenta corrigi-lo e, muitas vezes, Você fará o download e teste o produto como parte disso. Você pode obter o gerenciador de dados, o DBA ou o DBA ativo, o cara que tem a sorte de ser o mais técnico da sala, em alguns casos. Agora, quando você chegar aos ambientes corporativos maiores, obviamente, obterá os DBAs completos, normalmente eles serão os que usam a ferramenta. E eu fui em frente e apenas adicionei um pouco de sinopse aqui da Wikipedia. Isso meio que repassa as responsabilidades do DBA, como diz a Wikipedia, é o que eles fazem.
Se você ler a lista aqui, muitas dessas coisas, não vou ler, mas você terá muitas das coisas típicas em que pensaria e, em uma delas, terá monitoramento e otimizar o desempenho do banco de dados, e esse é bem grande. E o interessante é que, quando você fala com o DBA, eles sempre são os culpados primeiro, quando se trata de problemas, e pode não ser realmente culpa deles, mas quando há um problema de desempenho, geralmente com um aplicativo que está ligado a um banco de dados DBA, eles são os responsáveis pela culpa; portanto, eles sempre procuram os motivos pelos quais a culpa não é deles. Em muitos casos, é isso que eles podem usar essa ferramenta, o Diagnostic Manager, para ajudá-los.
Mas no final do dia, também, se o banco de dados não estiver funcionando, muitas dessas outras coisas realmente não importam, seus aplicativos não funcionam, então não importa para muitas delas. coisas. Em primeiro lugar, queremos garantir que o usuário experimente da maneira como a conhecemos, não diminua, é algo que os DBAs estão sempre buscando. E acho que, se você examinar os motivos pelos quais as pessoas normalmente compram e usam o produto SQL Diagnostic Manager, um dos primeiros motivos, provavelmente não o principal, nem o último nem o menos, mas é quase o mesmo, e, dependendo de com quem você fala, esses motivos, quase um ou dois deles sempre são, existe algum tipo de necessidade por aí.
Mas o primeiro é apenas ter essa visão centralizada das instâncias como um SQL que eles estão gerenciando. E o mais engraçado é que, em muitos casos, se você perguntar a um DBA: "Quantas instâncias você gerencia?" O número muda com tanta frequência que, em alguns casos, eles não têm muita certeza. Então, você precisa de algo mais do que apenas poder exibir tudo na tela. Você deseja capturar essas informações, entender essas informações e, dessa forma, é uma das coisas com as quais o Gerenciador de Diagnóstico pode definitivamente ajudar, é poder fornecer a você esse tipo de visão do ambiente.
E não é apenas uma visão do ambiente, mas é uma visão com a qual o DBA, o administrador do banco de dados, se sente confortável e é um console centrado no DBA, se você preferir. É feito para um administrador de banco de dados. Existem muitas ferramentas de monitoramento por aí, muitas ferramentas de desempenho por aí, mas, como eu disse, no final do dia, o DBA quer uma ferramenta projetada para um DBA, porque há muitas coisas específicas para o que elas fazem no seu dia a dia.
E com isso dito, você tem o SCOM, o HPF, todas essas outras tecnologias, mas elas querem algo que seja específico do que estão fazendo. Acho que podemos ajudar nessa área com este produto, você verá quando entrarmos em um segundo. A outra coisa que vemos com o DBA, que definitivamente é uma das coisas que abordamos anteriormente, é que eles precisam ver o que está acontecendo, obviamente, e precisam procurar em toda a empresa e tenha um pouco de tranquilidade em saber o que está acontecendo. Mas, ao mesmo tempo, eles não estão sentados olhando para os consoles.
Lembra-se de todos aqueles pontos que você viu na lista que acabei de encontrar? Eles também têm que fazer essas outras coisas, por isso não se trata apenas de esperar que os incêndios se apagem. Em muitos casos, haverá reuniões ou muitas janelas de manutenção relacionadas ao administrador do banco de dados estão sendo executadas no meio da noite enquanto eles dormem, portanto, eles precisam ter a capacidade de voltar e ver o que aconteceu . Em muitos casos, se você não percebe algo quando está acontecendo, depois que o problema desaparece, ou pelo menos no SQL Server, torna-se um tipo de problema em que você está lidando com a situação em que não percebe. tem mais restos desse problema. E esses problemas desaparecem, e os remanescentes, o que significa que você tem menos com o que solucionar problemas, menos informações para trabalhar.
Com isso dito, essa é definitivamente uma das coisas com as quais o Diagnostic Manager pode ajudar, é fornecer a você essa visão do passado para consultar as informações do passado: "Eu tive um alerta de bloqueio, tive problemas de impasse?" tivemos coisas que estavam acontecendo em termos de nossos recursos? ”Eu posso voltar e consultar essas informações. Eu posso me aprofundar em pontos específicos no tempo. Eu seria capaz de fazer todas essas coisas diretamente de dentro da ferramenta.
Todas essas coisas, apesar de ser um aplicativo interno ou externo, o DBA quer saber, porque deseja poder ver o que está causando o problema. Realmente não importa se foi alguém dentro da organização ou alguém fora da organização que escreveu o código; eles ainda querem poder isolá-lo, para que saibam que o problema está acontecendo e que sabem de onde ele está vindo.
Portanto, desempenho e responsabilidade são uma parte essencial do que nosso produto faz. Podemos fornecer todos esses detalhes, e o que é legal, é que você tem a capacidade de detalhar. Se houver um gargalo, você poderá correlacioná-lo ao aplicativo, ao usuário, ao banco de dados e à consulta. E mais uma vez, é uma espécie de arma fumegante. Você obtém uma correlação direta entre quando essa consulta é executada, o que está fazendo? E não se trata apenas da consulta em si, em termos de execução por si mesma, mas também da consulta com o tempo piorando? E essas coisas também podem ser respondidas, com o produto, que é definitivamente algo que, se você está tentando ser proativo, é bom poder dizer: "Ei, aqui está uma consulta que correu mal, mas, rapaz, olhe para ela à medida que avança, podemos ver que está cada vez pior, e posso fazer algo a respeito ".
Se formos para a próxima área aqui; e isso é provavelmente - eu diria que este é um dos grandes. Uma das perguntas que faço quando mostro nosso produto é: sempre perguntarei ao administrador do banco de dados: "Como você ouve sobre um problema relacionado aos bancos de dados do SQL Server?" E é muito engraçado, porque na maioria das vezes - agora concedido, na maioria das vezes eles estão olhando para o nosso produto, porque em muitos casos eles estão tentando resolver uma necessidade específica. Mas é interessante ouvir o tipo inicial de coisa - pelo menos com o SQL Server, é que era uma espécie de - você sabe, nos primeiros dias do SQL Server você tinha o SQL Server e depois o Oracle. E todo mundo tinha Oracle, e o SQL Server era como o, por falta de uma expressão melhor, o enteado ruivo dos bancos de dados, quando ele começou.
E, à medida que a Microsoft adicionava mais recursos, tornou-se um pouco mais uma ferramenta corporativa. E, obviamente, percorreu um longo caminho desde então. Mas o ponto é que, uma vez, você poderia argumentar que os bancos de dados não eram considerados críticos na época. E isso mudou com o tempo. Agora, por causa disso, em muitos casos, as pessoas estão tentando entender e dizendo: “Você sabe o que? Eu tenho todos esses bancos de dados do SQL Server, estou tentando entender o problema. "E, em vez de ouvir sobre os problemas do suporte técnico ou sobre as pessoas específicas que - como os próprios usuários, eles ' eles estão procurando maneiras de contornar essas situações antes que elas aconteçam.
E assim, com o Diagnostic Manager, essa é uma das coisas que também estamos tentando fazer, que é no mínimo capaz de fazer com que o DBA seja o primeiro a saber sobre essas situações ou problemas, para que eles possam fazer algo sobre isso, exatamente quando eles acontecem, ou para dar um passo adiante, para analisar esses sistemas que está monitorando. E poder fornecer conselhos proativos que melhorarão o desempenho dessa instância e poder fazer isso regularmente. Por exemplo, precisamos adicionar um índice, com base na carga de trabalho; esses tipos de coisas, as ferramentas capazes de fazer também. Então, veremos muito disso na ferramenta.
A outra coisa e a última coisa que está nesta lista, que é uma espécie de descrição mais geral, mas é algo definitivamente digno de nota. E, especialmente, à medida que você entra em situações maiores de nível corporativo, nas quais há muitas instâncias, sempre haverá algo obscuro que eu vou querer monitorar, se for o administrador do banco de dados, por exemplo. E o que tentamos fazer é antecipar em termos do que o DBA típico vai querer monitorar.
Com isso dito, você também seria capaz em termos de - sempre haverá algo novo. Por isso, fornecemos uma maneira de adicionar as métricas necessárias para monitorar e gerenciar após a adição do ponto de instalação. Portanto, quaisquer contadores PerfMon, contadores WMI, objetos de contador do SQL Server; todos esses podem ser incorporados à ferramenta. Você pode adicionar consultas adicionais que podem ser incorporadas aos seus intervalos de pesquisa.
E a última coisa que também vale a pena notar é que podemos adicionar e realmente nos comunicar com o vCenter e o Hyper-V para poder extrair as métricas desses ambientes. Porque uma das coisas que identificamos com o DBA é que elas normalmente não fazem parte das operações especificamente. E eles normalmente não têm, você sabe, o ambiente do vCenter, disponível para eles ou esses tipos de coisas disponíveis para eles.
E o problema é que, se eles estão lidando com uma instância do SQL Server e recebem recursos alocados, mas essa instância é virtualizada, pode parecer que eles têm todos os recursos do mundo, quando estão apenas monitorando o que é no sistema operacional convidado. A realidade é que, no host, pode haver 30, 40 ou 50 ou 100 outras VMs que eles estão tentando acessar e conter esses mesmos recursos. E a única maneira de realmente ver isso é se comunicar com esses outros ambientes e com essas interfaces, neste caso, o que fazemos.
Você pode adicionar esses outros tipos de contadores à ferramenta. Agora, não se trata apenas de monitorar esses contadores, mas de criar esses novos contadores que você apresenta ao produto, torná-los parte da ferramenta, como se fossem uma métrica pronta para uso. . Uma coisa pronta para uso que você deseja monitorar; então isso significa ser capaz de incorporá-los em seus painéis. Significa poder adicioná-los a seus próprios relatórios personalizados, obviamente definir limites e alertá-los, mas também baseline-los e poder defini-los com algum conhecimento, de onde defini-los com base em coisas como sua linhas de base e o que é normal. Então, você tem muitos tipos de coisas que também estão no produto.
O que eu meio que lhe forneci é o que eu chamo de "produtos essenciais para o Diagnostic Manager", e eu posso ir em frente e dar um gostinho disso ao entrar no produto. O que vou fazer é compartilhar minha tela, tudo bem, e apenas arrastar isso para cima.Então, o que você verá, este é o console do Diagnostic Manager.E, como mencionei antes, indo para o primeiro produto principal, poder ver coisas do tipo de uma visão de nível corporativo.Há muitos exemplos diferentes disso na ferramenta.Temos um tipo de visualização em miniatura, temos uma visão semelhante a uma grade.Também temos, em termos de flexibilidade, também possui um console baseado na Web. O console baseado na Web tem outras visualizações disponíveis, como mapas importantes e coisas assim. Mas o ponto é que você tem essa capacidade de olhar e ver as coisas em um nível alto, mas à medida que os problemas ocorrem, você vai se aprofundar um pouco mais na ferramenta e ver o problema específico e tenha alguma maneira de entender e saber o que está acontecendo. E obviamente isso é muito importante.
Agora, em termos de poder realmente ver o que aconteceu no passado; se eu estiver olhando para um problema que aconteceu ontem ou uma semana atrás, nessa situação, você terá a necessidade de poder acessar uma instância específica do SQL. E a boa notícia é que, se você souber a que horas esse problema ocorreu no produto, poderá ir diretamente para o navegador de histórico. E eu posso apontar para uma hora específica do dia; pode ser de algumas semanas atrás, pode ser de ontem. Mas, seja qual for o dia que eu escolher no calendário, serão apresentados os diferentes intervalos de pesquisa. Nesse caso, agora, estou vendo efetivamente o que teria visto se estivesse vendo o console em 20 de abril às 13:37.
Então, eu posso voltar no tempo e, assim que fizer isso, todas as diferentes guias que vemos aqui refletirão esse momento específico, incluindo as consultas que podem ter sido ruins, incluindo talvez se Eu tive sessões com bloqueio. Todo esse tipo de coisa apareceria na ferramenta, e obviamente me permitirá aproveitar essas informações históricas para poder, você sabe, corrigir o problema. Agora, nessa observação, quando estamos falando sobre a história, a outra coisa que vale a pena notar aqui é que não é apenas usar a história para corrigir problemas. Essa história é muito valiosa, obviamente, por outras razões. E um dos grandes é ser capaz de tomar decisões com eficiência e ser capaz de tomar decisões rapidamente, com as informações corretas. Então, toda essa história, todas as informações que estamos coletando, podemos denunciar.
Se alguém vier até mim e disser: "Eu tenho esse ótimo aplicativo novo. Isso mudará o mundo como o conhecemos. Ah, pelo jeito que exige um banco de dados, e pelo jeito que vai realmente atrelar o E / S na máquina em que esse banco de dados está. " Se eu sei disso, posso aproveitar essas informações para poder fornecer uma classificação de todos os meus servidores de produção, com base, talvez, nos últimos sete dias da coleta. E eu seria capaz de chegar rapidamente à conclusão de quais instâncias fazem mais sentido para empregar esse banco de dados. Portanto, é esse tipo de informação histórica que também é obviamente muito valiosa.
Em termos das próprias consultas; em termos de análise das consultas, temos várias maneiras diferentes de fazer isso na ferramenta. E o que eu mais gosto de ver é o Query Waits View, porque o Query Waits View é muito útil em termos de capacidade de avaliação. Se estiver ocorrendo um gargalo, ser capaz de identificar essencialmente todas as áreas diferentes que estão afetando essa consulta específica; não apenas a consulta em si e qual é o impacto dessa consulta, mas também, sabe, de qual aplicativo ele veio, de qual sessão ele veio, qual usuário o chamou e tudo mais, eu posso ver que, obviamente, informações em tempo real, mas também tenho a capacidade de analisar esses dados do passado. E isso é uma das coisas aqui, e eu comecei um script, mas tenho que esperar que ele meio que apareça.
Enquanto esperamos por isso, eu quero - e sei que estamos com pouco tempo, então eu queria falar um pouco também sobre alertar a notificação como proativa. E quando você está falando sobre esse tipo de coisa, como eu disse, sendo a parte proativa, há muitas ferramentas que alertam. A parte mais difícil é não enviar um email. A parte difícil não está gravando no log de eventos ou gerando uma interceptação SNMP. A parte difícil é saber quando enviar esse alerta nos momentos apropriados. E, com isso, é preciso fazer alguns cálculos, entender: "O que há nessa instância em particular e o que é normal no que diz respeito a essa instância?"
E, portanto, para todas as métricas que fazem sentido, baseamos essas métricas. Na verdade, mostramos a linha de base, o limite em que está definido atualmente. E a outra coisa legal é que, digamos, defino meus limites neste caso seis e dez apenas para este exemplo. Daqui a seis semanas, se eu voltar a essa instância, essa linha de base poderá mudar completamente, porque uma das coisas que fazemos quando calculamos a linha de base, por padrão, é um cálculo contínuo de sete dias. Por isso, está sempre me fornecendo uma versão atualizada da linha de base. E o que acontece se essa linha de base mudar para meus limites? Nesse caso, eu posso ver e alertar recomendações que basicamente dizem: "Ei, você tem um limite provavelmente definido incorretamente, específico para onde vemos o limite e, obviamente, onde está a linha de base, você provavelmente vai estar recebendo um alerta para algo que é uma ocorrência normal ".
E, em vez de tratar um sintoma de algo normal, sou capaz de identificar esse tipo de situação em que o limite real está definido incorretamente. E o que isso me permite fazer, obviamente, é definir os limites de acordo com onde vou receber um alerta. Sei que é mais um apelo à ação do que uma investigação para ver se é realmente um problema. E acho que parte da ferramenta é realmente útil em termos da própria linha de base e de poder calcular.
Agora, com este produto, você pode realmente ter várias linhas de base; você pode defini-los por diferentes períodos de tempo e ajustar dinamicamente os limites com base em suas linhas de base, o que também é parte muito importante do tipo de adaptação às alterações que acontecem diariamente nas instâncias do SQL Server . Agora, neste caso aqui, abordamos muitas das configurações dos limites e mostrando as linhas de base. Mas, no que diz respeito aos alertas reais, a notificação em si, o interessante do Diagnostic Manager, é que ela fornece vários perfis de alerta. Portanto, se você tem, por exemplo, um perfil de plantão das 2:00 às 05:00, posso ter um perfil específico apenas para esse intervalo de tempo e definir todas as condições e as configurações apropriadas aqui pela minha resposta.
Agora, a questão da resposta é que, em alguns casos, sim, posso enviar um e-mail ou disparar e gerar uma interceptação SNMP ou gravar no log de eventos. Há muitas outras coisas que podemos fazer, mas, enquanto falo com os DBAs, o que eles realmente gostam é o fato de que, na maioria dos casos, grande parte do trabalho realizado é repetitivo. São coisas que eles sabem exatamente quando o problema está acontecendo, o que fazer para corrigi-lo. Eles apenas têm que ir e intervir. E, assim, à medida que você cresce seu ambiente, como você tem mais instâncias, isso se torna muito mais difícil de fazer. Portanto, uma das coisas que você pode fazer dentro da ferramenta que eu acho que vale a pena notar é que você tem a capacidade de configurar uma condição, mas com base nessa condição para poder definir uma resposta para executar um script, executar um job, para executar um executável. E o ponto é que, se você decidir executar um script, eu posso usar parâmetros, dentro desse script que estará no tempo de execução, preenchidos com as informações reais.
Portanto, se houver problemas com um banco de dados específico, o script será projetado para ser executado exatamente no banco de dados em que o problema está acontecendo. Portanto, você pode resolver os problemas dinamicamente de maneira automatizada e, ainda assim, ainda posso receber um e-mail para retornar e dizer-me: "Ei, houve um problema, mas, a propósito, foi corrigido". O script foi executado e, como DBA, você sabe disso, mas na verdade não precisava intervir. Agora, na mesma nota sobre ser proativo, obviamente também temos outro recurso aqui, que é o recurso "Analisar". E, o que isso fará é fazer uma verificação regular na instância do SQL. E, em alguns casos, fará um mergulho mais profundo em termos do que está procurando. Coisas como análise de índice hipotético serão realizadas. Eu adiciono um índice? Eu removo um índice? Obviamente, todo esse tipo de coisa vai ajudar no meu desempenho, mas mais uma vez, é tudo uma questão de ser proativo. É sobre ser capaz de tomar decisões antes que as coisas quebrem e fazê-las funcionar melhor. E, em muitos casos, é isso que estamos tentando fazer aqui.
Voltando ao Query Waits, sobre o qual falávamos anteriormente; como você pode ver, há um grande pico aqui. Eu executei um script anteriormente que apenas causou alguma atividade de espera e, como mencionei antes, temos uma maneira realmente única de detalhar essas informações. Se eu quero ver qual aplicativo foi; Eu posso ver que ele estava vindo do aplicativo NoSQL. Poderíamos ver o banco de dados ao qual estava vinculado, a sessão, o usuário e, se eu quiser, também posso classificá-lo em termos de minhas esperas. Então, posso dizer, de todas as esperas que estavam acontecendo naquela janela de tempo, quais estavam acontecendo mais? E se eu perceber que, quando isso aconteceu mais, a coisa mais legal é que eu posso detalhar esse tipo de espera e ver todos os comandos. Se você olhar aqui, eles estavam fazendo essa espera ocorrer. E também posso ver principalmente qual aplicativo era o que estava causando essa espera.
Por isso, destaca-se como um polegar dolorido. Posso dizer imediatamente: "Esse é o aplicativo que está causando meu gargalo. Agora, qual foi a consulta que foi executada? Qual usuário a executou? Em qual banco de dados ela foi executada?" E assim por diante. Então, espero que isso faça sentido, e isso também ajuda em termos de garantir que você não tenha a latência em seu ambiente, no que se refere aos seus bancos de dados. Espero que isso seja útil. Vou avançar neste momento e passá-lo de volta, e acho podemos continuar a partir daí.
Eric Kavanagh: Com certeza. Então, acho que vou falar com nossos especialistas do dia. Mark, talvez primeiro você queira comentar e fazer algumas perguntas. Então Dez, você pode entrar.
Mark Madsen: Sim, obrigado, eu realmente gostei de assistir um pouco disso. É um monitoramento muito mais inteligente do que estou acostumado a ver. Estou curioso com o gerenciamento dos dados por trás disso; o gerenciamento das métricas que você pode rastrear e, por exemplo, procure por coisas como mudar linhas de base em particular, que é um dos meus pontos problemáticos para animais de estimação, com painéis. Como você lida com esses dados, e a segunda parte disso é com, você sabe, métricas de linha de base, como tipo de mudança - você tem a capacidade de alterar automaticamente os limites também, para que eu não precise voltar e redefinir os limites manualmente, quando uma linha de base muda?
Bullett Manale: Você sabe, e o mais legal é que você pode decidir isso. Você pode fazer qualquer um. Posso definir um limite e transformá-lo em uma configuração estática ou marque a caixa para dizer: "Torne este um limite dinâmico, que mudará conforme minhas linhas de base mudam". E eu tenho a capacidade e a ferramenta de definir uma janela padrão tempo para minha linha de base, mas, se necessário, talvez eu tenha uma janela de linha de base separada, por exemplo, da minha janela de manutenção das 2:00 da manhã, digamos até 5:00 da manhã, porque vou taxar minha CPU, minhas unidades e tudo mais, porque é nesse momento que fazemos toda a manutenção, que automaticamente, se eu tivesse selecionado, ajustaria automaticamente meus limites para ficar fora do normal para aquelas métricas que Eu escolho fazer isso. Isso me permitiria. Basicamente, você tem a capacidade de definir janelas de tempo, que são suas janelas de linha de base, e cada janela pode ser tratada como uma entidade separada, em termos de ajuste dinâmico da linha de base que pode ser feito, e você pode adicionar quantas janelas da linha de base Você precisa, se isso faz sentido. Você pode ter uma janela de fim de semana, um dia da semana durante o horário de trabalho, uma janela de manutenção que acontece no meio da noite e assim por diante.
Mark Madsen: Obrigado.
Bullett Manale: Acho que voltamos à primeira parte da pergunta e coletamos todas essas informações. Eu realmente não falei sobre a arquitetura, mas temos um repositório de back-end, que você tem controle total sobre a retenção desses dados, mas também temos um serviço que é executado no meio da noite que passa todos os nossos cálculos de linha de base, e os dados são coletados e coletados e compreendidos. E, obviamente, além disso, você também tem vários relatórios que podemos usar para relatar suas linhas de base, para métricas específicas. E você ainda pode comparar suas linhas de base do mesmo servidor, pela mesma métrica por diferentes períodos de tempo. Você pode ver se há diferenças que ocorreram ou qual é o delta. Também existem muitos tipos de opções.
Eric Kavanagh: Dez.
Dez Blanchfield: Uma pergunta rápida que tenho para você - há um amplo espectro do que essa ferramenta pode fazer. Você está vendo uma aceitação no uso dele no estágio inicial de desenvolvimento agora, ou ainda é principalmente uma ferramenta de ambiente de produção? Em outras palavras, os desenvolvedores estão obtendo acesso e usando-os durante o desenvolvimento inicial e testando a fase de integração? Ou ainda é usado predominantemente em ambientes de produção?
Bullett Manale: Eu diria que, na maioria das vezes, vemos isso em ambientes de produção. Depende das situações, mas na maioria das vezes eu diria principalmente produção e nós - e também é justo mencionar que temos preços diferentes para ambientes de desenvolvimento e teste, por isso é um pouco mais atraente. Vemos pessoas usando-o para esses ambientes, mas eu diria que, se eu tivesse que lhe dar uma resposta de uma maneira ou de outra, eu diria que são principalmente os ambientes de produção em que estamos vendo as pessoas fazerem um investimento para este produto .
Dez Blanchfield: Claro, sim, e foi interessante saber que você tem preços diferentes, porque obviamente existem cargas de trabalho diferentes, e quanto mais pesados os trabalhos serão, onde todo o trabalho real está sendo feito. Mas estou vendo muitas organizações, particularmente no governo e, certamente, na defesa, onde o desenvolvimento agora está obtendo o mesmo nível de investimento em ferramentas e sistemas que os ambientes de produção, porque eles estão realizando muito mais testes iniciais. Em defesa, por exemplo, há equipes que executam bilhões de testes, centenas de bilhões de testes em aplicativos e sistemas e ferramentas, e os monitoram antes mesmo de entrarem nos testes de integração, porque desejam garantir que haja um código criado e o banco de dados está sentado embaixo. Chega a cento e um milhão de iterações ou algo assim, enquanto você está no campo atirando em alguém, não dá "estrondo".
Bullett Manale: Claro.
Dez Blanchfield: No mundo dos bancos de dados da velha escola, na minha experiência, pensando que o ambiente de banco de dados é algo que resta apenas nos dados e alguns de vocês sabem, são muito raramente vistos e raramente mencionados; portanto, quando chegamos ao ponto agora em que ferramentas e aplicativos estão sendo desenvolvidos, principalmente em plataformas analíticas, agora estão em nossos aparelhos e dispositivos. Você está vendo os clientes trazerem a conversa sobre desempenho e gerenciamento de banco de dados para uma discussão mais cotidiana, em vez de apenas técnicos? E eu sei que você mencionou antes que predominantemente está conversando com DBAs, mas existe uma tendência agora no vocabulário geral? Você está vendo pessoas em que eles estão discutindo esses tópicos, em vez de apenas os geeks?
Bullett Manale: Bem, é difícil dizer. Quero dizer, como eu disse em grande parte, as pessoas com quem lidamos em termos do processo de vendas estão com os profissionais, que são os DBAs. Portanto, em termos de sua pergunta, você está apenas dizendo: "Em termos gerais, as pessoas da organização de TI estão se tornando mais conscientes do banco de dados?" Eu acho que é a pergunta e eu diria que provavelmente a resposta é "sim". Provavelmente não o vejo tanto, com base em onde estou, no dia-a-dia, mas acho que se estou entendendo sua pergunta, essa seria minha resposta, eu acho.
Dez Blanchfield: Sim, tudo bem. Provavelmente é uma pergunta carregada, desculpe, porque obviamente seus interesses predominantes no seu mundo são o lado técnico das coisas. Tenho curiosidade em saber que, nas minhas atividades diárias, vejo organizações começarem a trazer isso para a conversa muito cedo. Portanto, quando eles estão falando sobre novas iniciativas, novos projetos, novos programas de trabalho, uma das coisas que surgem imediatamente é: "Como o monitoramos, como o monitoramos, como lidamos com os problemas à medida que surgem, em vez de lançar, ir ao ar? "
Bullett Manale: Eu diria que -
Dez Blanchfield: Desculpe, vá em frente.
Bullett Manale: Eu diria que vejo uma tendência que acho que deveria dizer - você sabe, muitas vezes no passado você teria: "Tínhamos um problema e agora precisamos de uma ferramenta. " E acho que estamos vendo um pouco mais de aceitação em relação à instalação da ferramenta antes que o problema aconteça, se isso fizer sentido. Então, eu diria que definitivamente está se tornando mais normal, você sabe, “Ei, precisamos de uma ferramenta de monitoramento, precisamos de algo.” E as pessoas definitivamente estão vendo o valor desse produto, porque, como você disse anteriormente, adicionando DBAs e adicionando novas instâncias, você precisa de algo que gere isso. Você precisa de algo que ajude no gerenciamento disso, e é por isso que estamos vendo muita aceitação em torno deste produto também ou temos.
Dez Blanchfield: Pergunta rápida. Onde isso precisa morar? Ele precisa ficar na parte traseira da gravação na LAN, dentro do data center, o mais próximo possível dos ambientes de banco de dados ou é confortável em algum lugar, potencialmente fora da nuvem, uma nuvem de terceiros com algum tipo de túnel VPN ou acesso remoto a vários ambientes? Onde é que isso fica, no que diz respeito a ambientes e monitoramento?
Bullett Manale: Em termos de arquitetura, há um repositório de back-end, e esse é um banco de dados do SQL Server. Temos o console que pode ser um cliente gordo ou thin client; nós damos a opção de ambos. E também temos um thin client realmente voltado especificamente para dispositivos móveis. Mas em termos de onde isso pode realmente acontecer; ele pode ficar em um ambiente, na verdade a parte mais complicada, pois muitas das informações que precisamos coletar exige direitos administrativos, em alguns casos ou em muitos casos. Agora não fazemos você fazer isso; se desejar, você pode coletar dados e apenas as coisas que não podemos coletar, porque não temos direitos de administrador, apenas permitiremos que você não veja essas informações, se essa for a sua escolha.
Dependendo do tipo, como se você está falando sobre a AWS, alguns ambientes funcionam melhor que outros, mas, no que diz respeito ao ambiente em si, normalmente usando a autenticação SA para coletar os dados nas instâncias é tudo o que é necessário. Ou, se for um domínio não confiável, geralmente é quando você deseja fazer isso, mas vários domínios; contanto que haja uma confiança entre eles, podemos coletar contra eles. Realmente não importa se está em uma LAN ou na WAN, a própria coleção é bastante insignificante em termos da quantidade de dados que estamos coletando. Se tivermos uma conexão WAN de tamanho suficiente, não haverá problema. Eu já vi ambientes em que eles têm filiais onde eles têm servidores SQL em todo o país. E é um servidor em cada um desses locais diferentes, e eles estão monitorando-o centralmente. A parte complicada é apenas garantir que você tenha uma quantidade decente de conectividade para fazer isso. Felizmente, isso responde à sua pergunta, estava meio que em todo o mapa.
Dez Blanchfield: Sim, absolutamente. Obrigado. Então, duas perguntas rápidas que chegaram aos participantes nesta manhã; uma é: qual é o impacto de - geralmente vemos as ferramentas de monitoramento do sistema gerarem carga apenas monitorando as coisas, então a pergunta era: desculpe se rolou da minha tela agora, mas para parafrasear; monitorando estamos gerando carga nós mesmos? Existe um impacto mensurável da ferramenta, apenas observando o meio ambiente ou é um impacto insignificante?
Bullett Manale: Sempre haverá um pouco de impacto, pois ele precisa consultar a instância do SQL Server para recuperar os dados. A pergunta como você disse é: "É insignificante ou é significativo?" Fora da caixa que você está apontando para uma instância, é insignificante. Estamos fazendo isso há um bom tempo, como eu disse. Temos mais de 20.000 clientes e posso garantir que, se causar um impacto significativo no desempenho, não estaremos nos negócios. Com isso dito, também permitimos que o usuário decida o que eles querem monitorar. Então, acho que isso é importante, é que todo ambiente é um pouco diferente.
Um exemplo seria, com o componente de monitoramento de consultas, uma das coisas que temos a capacidade de fazer, é que podemos definir o limite do que você considera seu limite de normalidade. Portanto, pode ser com base no tempo de execução da consulta. Poderia ser baseado na CPU, E / S, mas como exemplo, digamos que configurei meu tempo de execução para zero milissegundos. O que estou dizendo para a ferramenta é efetivamente coletar todas as consultas executadas desde o último intervalo de extração e fazer parte da minha coleção histórica também.
Agora, quando fizermos isso, coletaremos qualquer quantidade de consultas em execução desde a última pesquisa. Agora isso é eletivo, e o usuário tem a capacidade de fazer isso. Dizemos: "É isso que você deve fazer"? Não. Mas também oferecemos a opção de fazer isso, caso você queira uma amostra de dados que permita coletar essas informações. De modo geral, você tem os meios dentro do ferramenta para configurá-lo e ajustá-lo exatamente como você deseja, com base no que você se sente confortável, mas você pode realmente abri-lo, se quiser, e coletar muitas informações adicionais que talvez você não necessariamente coletar, se isso faz sentido.
Dez Blanchfield: Sim, absolutamente. Sei que estamos demorando um pouco, mas há duas ótimas perguntas que quero fazer antes de encerrar. Ambos vêm diretamente para mim, mas acho que é melhor se você responder. A pergunta geralmente era: "Qual é o escopo do alcance da ferramenta no que diz respeito ao conhecimento dos sistemas existentes?" Então, podemos simplesmente conectar isso e detectar automaticamente a plataforma existente, saber o que é normal para essa plataforma e imediatamente como Mark estava falando anteriormente? Alguns dos conhecimentos básicos das plataformas, colocando, você sabe, eu não sei, poderia ser o Microsoft Dynamics. Qual é o escopo do conhecimento da plataforma com o que é normal e em algumas das ferramentas disponíveis no mercado que estão sendo usadas nos negócios?
Bullett Manale: Eu diria que, de um modo geral, quando começamos a coletar dados na instância SQL, trabalhamos com as melhores práticas para começar, em termos de nossos limites e onde eles estão definidos. Dito isso, também reconhecemos que com quem você está falando, em termos de práticas recomendadas, cada ambiente é diferente. O que faremos inicialmente, apenas coletamos os dados e o que recomendamos que as pessoas façam, você pode experimentar o produto por mais 14 dias, se precisar. Mas, após cerca de dois dias, você começará a ver os dados da linha de base preenchidos. Depois de ter informações de amostra suficientes para trabalhar, ele começará a fornecer o contexto em termos da linha de base, onde está o intervalo e todo esse tipo de coisa. A partir daí, se você quiser, poderá definir automaticamente seus limites a partir das informações que foram coletadas. É preciso um pouco de coleta e pesquisa iniciais para poder determinar o que é normal, para que você possa começar a mudar seus limites.
Mas o que acho que vale a pena notar também é que, quando você altera esses limites, isso pode ser feito grupo a grupo de suas instâncias. Pode ser específico para uma instância ou contra todas as instâncias, bem como a capacidade de criar itens como modelos, para que você possa dizer: "Esta é uma instância de produção, mas é o modelo que eu quero para atribuir a ele ". Portanto, quando uma nova instância de produção fica on-line, aplicamos automaticamente esses limites a ela, porque ela tem o mesmo tipo de hardware e geralmente possui as mesmas cargas de trabalho, para que também possamos fazê-lo dessa maneira. Espero que ajude nos termos da pergunta.
Dez Blanchfield: Sim, absolutamente. Na verdade, você realmente respondeu a outra pergunta que me veio à mente e foi: "Existe um download de teste?" Posso responder isso, eu sei. Tenho certeza de que você confirmará que há um download gratuito e acho que você disse que eram 14 dias a partir do site. Você pode baixá-lo e brincar com ele. Eu acho que rapidamente: "Que tipo de ambiente eu preciso para poder executar a avaliação? Posso executá-lo no meu laptop e brincar com ele ou preciso mesmo de um servidor?"
Bullett Manale: A principal coisa que ele precisa é de um repositório, um banco de dados do SQL Server que seja 2005 ou superior. Fora isso, existem alguns requisitos mínimos de recursos, um requisito .NET e é isso. Portanto, é apenas uma questão de instalar o produto e criar um banco de dados.
Dez Blanchfield: Perfeito. Uma última pergunta que colocarei em você, porque agora estamos sem tempo, mas rapidamente, cerca de duas ou três pessoas me perguntaram: "Preciso ser um DBA para poder realmente começar a trabalhar com isso e brincar com isso? ”
Bullett Manale: Não. Eu diria que, se você é um DBA, terá diferentes usos da ferramenta. Quero dizer, provavelmente haverá um pouco mais de valor se você é um DBA experiente. Você verá muito mais profundidade da ferramenta da qual poderá aproveitar. Mas também como um novo DBA, ou mesmo como uma pessoa que, que não é um DBA, temos muitas recomendações e estou nessa página agora. Essas recomendações são apresentadas regularmente, e o mais interessante é que elas fornecem as razões pelas quais as recomendações estão sendo feitas. Além disso, eles também terão links para conteúdo externo que descrevem mais detalhadamente os motivos pelos quais essas recomendações também estão sendo feitas. Então, isso será vinculado a sites externos da Microsoft, blogs e todo tipo de coisa assim, isso é externo.
Mas, para responder sua pergunta, é meio que, você sabe, se você é um DBA sênior, haverá coisas aqui, você provavelmente aproveitará, que provavelmente não seria um DBA novato. Mas, ao mesmo tempo, é uma espécie de ferramenta de aprendizado, porque, ao seguir essas recomendações, você começará a entender algumas dessas coisas por conta própria através do uso das recomendações.
Dez Blanchfield: Fantástico. Obrigado. Gostei muito da parte demo. A apresentação foi ótima. A demo foi fantástica. Rapidamente, a partir da memória, há todo um centro de recursos em seu site que eu recomendo que as pessoas vejam também. Lembro-me de passar por isso ontem à noite para obter alguns detalhes. Você tem várias coisas, desde seus blogs, dados e conversas até, de memória, a maior parte da documentação do seu produto on-line, sim?
Bullett Manale: Sim, está correto, e o formulário que você está consultando é o site community.idera.com. E então uma coisa que eu mencionaria também, antes que você perguntasse: "Será que vai reconhecer o meio ambiente?" Em termos de novas instâncias ou adição de instâncias, existe outra ferramenta que faz a descoberta de instâncias. E é tudo sobre inventário e gerenciamento de seu inventário. Eu apenas apontaria você nessa direção, em termos de realmente descobrir as instâncias. Mas, na realidade, o desempenho e o monitoramento, todo esse tipo de coisa sobre o qual falamos, é aí que o Diagnostic Manager entra em ação.
Dez Blanchfield: Fantástico. Olha, ótima cobertura. Gostei muito da sua apresentação. Adorei a demonstração ao vivo e isso é tudo de mim esta manhã, pois sei que passamos provavelmente 10 minutos ao longo do tempo. Eric, eu vou voltar para você.
Eric Kavanagh: Tudo bem. Eu simplesmente amei a demo. Estou feliz que você fez a demo. Fico feliz que pudemos dar uma boa olhada nisso enquanto passávamos pelas perguntas e respostas.
Bullett Manale: Ótimo.
Eric Kavanagh: Porque isso dá às pessoas uma idéia do que você está vendo, e realmente me surpreende pensar que ainda estamos aprendendo sobre como conversar com esses computadores, quando você se dedica a isso. Quero dizer, esse nível de diagnóstico é bastante sofisticado e está melhorando a cada dia. Estamos obtendo muito mais informações sobre o que realmente está acontecendo. Mas você realmente precisa de uma pessoa que negligencie essas coisas, leia e coloque essa capacidade cognitiva por trás do que está fazendo, certo?
Bullett Manale: Sim, quero dizer em muitos casos - eu gostaria de poder dizer que esse é um DBA na caixa, mas há muitas coisas acontecendo. Quero dizer, fornecemos orientação e ajudamos, mas no final do dia, exige que as pessoas tomem decisões sobre os dados que estamos apresentando. Eu não acho que isso vai mudar tão cedo.
Eric Kavanagh: Bem, isso é uma boa notícia para as pessoas reais por aí, pessoal.
Bullett Manale: Isso mesmo.
Eric Kavanagh: Você vai querer ter alguém assistindo a isso, uma equipe assistindo a isso, e você aprenderá, como ouviu Bullett aqui, observando essas recomendações que vai entender o que está acontecendo. E suponho que a partir dessa história, e acho que você tenha tocado nisso, Bullett, mas muito rapidamente, essa história permite que você reconheça padrões significativos e, portanto, seja capaz de identificá-los quando ocorrerem no futuro, certo?
Bullett Manale: Isso está correto. Uma das coisas que podemos fazer é acompanhar o desempenho de uma consulta ao longo do tempo. Também podemos obviamente observar outras coisas, como linhas de base e vê-las mudar, e obviamente receber alertas e coisas assim quando isso acontece, para que você definitivamente tenha essa capacidade.
Eric Kavanagh: Isso parece bom, pessoal. Não teríamos demorado muito aqui, mas eu queria chegar a essas perguntas. Muito obrigado pelo seu tempo e atenção. Arquivamos todos esses webcasts. Entre on-line no Techopedia.com ou no InsideAnalysis.com, você verá links de ambos os lugares.
E com isso, damos-lhe adeus. Mais uma vez obrigado, pessoal, nos encontraremos na próxima semana, mais três webcasts na próxima semana, terça, quarta e quinta-feira. Então, falaremos com você na próxima semana, pessoal. Cuidar. Tchau tchau.
Parceiro de conteúdo Techopedia
A equipe do Techopedia é afiliada ao Bloor Group e pode ser contatada usando as opções à direita. Para informações sobre como trabalhamos com parceiros do setor, clique aqui.- Perfil
- Local na rede Internet
