Leve embora: O apresentador Eric Kavanagh discute as previsões com o Dr. Robin Bloor, Rick Sherman e IDERAs Bullett Manale.
Você deve se registrar neste evento para ver o vídeo. Registre-se para ver o vídeo.
Eric Kavanagh: Senhoras e senhores, olá mais uma vez e bem-vindos de volta à série de webcast da Hot Technologies! Meu nome é Eric Kavanagh, serei o anfitrião do seminário on-line de hoje, chamado “Economizando tempo, dinheiro e problemas com previsões ideais”. É claro que perdi a primeira parte do título de lá: “Os melhores planos estabelecidos”. Sempre conversamos sobre isso neste show. Portanto, é claro que o Hot Technologies é o nosso fórum para entender o que alguns dos produtos interessantes estão por aí no mundo de hoje, o mundo da tecnologia corporativa, o que as pessoas estão fazendo com eles, como funcionam, todo esse tipo de coisa divertida.
E o tópico hoje, como sugiro, trata de previsão. Realmente, você está tentando entender o que está acontecendo em sua organização. Como você vai manter seus usuários felizes, não importa o que eles estejam fazendo? Se eles estão analisando, se estão realizando um trabalho real, estão enfrentando clientes reais com sistemas transacionais, qualquer que seja o caso, você quer entender como seus sistemas estão funcionando e o que está acontecendo, e é isso que se fala hoje. É meio engraçado porque fazer previsões não é algo que eu gosto de fazer, porque sou supersticioso, como acho que se fizer previsões demais, coisas ruins vão acontecer, mas isso é só comigo. Não siga minha liderança.
Então, aqui estão nossos apresentadores hoje, o seu verdadeiramente no canto superior esquerdo, Rick Sherman está discando de Boston, nosso amigo Bullett Manale da IDERA e nosso próprio Dr. Robin Bloor. E com isso, vou entregá-lo a Robin e lembrar às pessoas: faça perguntas, não seja tímido, adoramos boas perguntas, bem, apresentá-las aos nossos apresentadores e outros hoje. E com isso, Robin, leve embora.
Robin Bloor: OK, bem, como estou na pole position como eles dizem, pensei em contar uma história sobre SQL hoje, porque é o pano de fundo para o que a discussão vai continuar e inevitavelmente não entrará em conflito porque Rick não está focado nisso. , e não entrará em conflito com o que Rick tem a dizer. Então, a história do SQL, há algumas coisas interessantes sobre o SQL porque são muito dominantes. Veja, isso é um erro de digitação, SQL é uma linguagem declarativa. A ideia era que você pudesse criar um idioma no qual solicitasse o que queria. E o banco de dados descobriria como obtê-lo. E funcionou bastante bem, na verdade, mas há várias coisas que vale a pena dizer sobre isso, as consequências de basear todo o setor de TI em uma linguagem declarativa. O usuário não conhece ou se preocupa com a organização física dos dados, e isso é bom com a linguagem declarativa - ele separa você de tudo isso e até se preocupa com isso - basta pedir o que quiser e o banco de dados vai buscá-lo.
Mas o usuário não tem idéia de como a estrutura da consulta SQL afetará o desempenho da consulta e isso é um pouco negativo. Eu já vi consultas com centenas e centenas de linhas, que são apenas uma solicitação SQL, você sabe, começa com "select" e continua com subconsultas e assim por diante. E, na verdade, acontece que, se você deseja uma coleta específica de dados em um banco de dados, pode solicitá-los de várias maneiras diferentes com o SQL e obter a mesma resposta se você tiver alguma familiaridade com os dados. Portanto, uma consulta SQL não é necessariamente a melhor maneira de solicitar dados, e os bancos de dados responderão de maneira bastante diferente, de acordo com o SQL que você coloca neles.
E assim, o SQL realmente afeta o desempenho, de modo que as pessoas que usam o SQL são verdadeiras, também são os programadores de SQL que usam o SQL e são menos propensos a pensar no impacto que terão, porque a maior parte do foco deles está na manipulação de dados e não na obtenção e colocação de dados. E o mesmo se aplica às ferramentas de BI. Já vi o SQL que obtém, se você preferir, extrair ferramentas de BI de vários bancos de dados e é preciso dizer que muito disso é, bem, eu não escreveria consultas SQL Curtiu isso. Alguém criou, se você preferir, um pequeno motor que, quaisquer que sejam os parâmetros, lançará algum SQL e, novamente, esse SQL não será necessariamente um SQL eficiente.
Então pensei em mencionar a incompatibilidade de impedância, os dados que os programadores usam são diferentes dos dados que eles classificam. Portanto, nosso DMS armazena dados em tabelas, organiza o código orientado a objetos na sua maioria codificadores, atualmente está programando formulários orientados a objetos e eles ordenam dados em estruturas de objetos, para que não sejam mapeados um para o outro. Portanto, é necessário traduzir do que o programador pensa que os dados são para o que o banco de dados pensa quais são os dados. O que parece que devemos ter feito algo errado para que esse seja o caso. O SQL possui DDL para definição de dados, possui DML - linguagem de manipulação de dados - seleciona, projeta e ingressa para obter esses dados. Agora, há muito pouca matemática e muito pouco material baseado em tempo, por isso é a linguagem imperfeita, embora deva-se dizer que foi estendida e continua a ser estendida.
E então, você obtém o problema da barreira do SQL, que é sempre mais reto que o diagrama, pois muitas pessoas estavam fazendo perguntas por razões analíticas, uma vez que obtiveram a resposta aos termos de dados da pergunta, quer fazer outra pergunta. Então, torna-se uma coisa de diálogo, bem, o SQL não foi criado para diálogos, foi criado para perguntar o que você deseja de uma só vez. E vale a pena saber disso, porque existem alguns produtos por aí que realmente abandonam o SQL para tornar possível a conversa entre o usuário e os dados.
Em termos de desempenho do banco de dados - e esse tipo de extensão se espalha por tudo - sim, há CPU, memória, disco, sobrecarga de rede e o problema de bloqueio de mais de uma pessoa que deseja usar exclusivamente os dados em um determinado momento. ponto no tempo. Mas também há chamadas SQL ruins, há muito o que pode ser feito se você realmente otimizar o SQL, em termos de desempenho. Portanto, fatores de desempenho do banco de dados: design incorreto, design incorreto do programa, simultaneidade de carga de trabalho ausente, balanceamento de carga, estrutura de consulta, planejamento de capacidade. Isso é crescimento de dados. E, em poucas palavras, o SQL é conveniente, mas não se otimiza automaticamente.
Dito isto, acho que podemos passar para Rick.
Eric Kavanagh: Tudo bem, Rick, deixe-me lhe dar as chaves do carro WebEx. Leve embora.
Rick Sherman: Tudo bem, ótimo. Bem, obrigado Robin, quando começamos no início da apresentação, meus gráficos ainda são muito chatos, mas vamos em frente. Então, eu concordo com tudo o que Robin falou no lado SQL. Mas o que eu quero agora concentrar um pouco é a demanda por dados, que passam muito rapidamente, o suprimento como nas ferramentas usadas naquele espaço ou a necessidade das ferramentas naquele espaço.
Primeiro, há alguns artigos em todos os artigos que você lê relacionados a big data, muitos dados, dados não estruturados vindos da nuvem, big data em todos os lugares que você pode imaginar. Mas o crescimento do mercado de banco de dados tem sido continuamente com o SQL, banco de dados relacional provavelmente a partir de 2015, ainda é 95% do mercado de banco de dados. Os três principais fornecedores relacionais têm cerca de 88% da participação de mercado nesse espaço. Então, ainda estávamos conversando, como Robin falou, sobre SQL. E, de fato, mesmo se estivesse procurando na plataforma Hadoop, o Hive e o Spark SQL - que meu filho, que é um cientista de dados, usa o tempo todo agora - é certamente o caminho dominante para as pessoas acessarem os dados.
Agora, no lado do banco de dados, existem duas grandes categorias de uso de bancos de dados. Um deles é para sistemas operacionais de gerenciamento de banco de dados, de modo que o planejamento de relacionamento corporativo, o gerenciamento de relacionamento com clientes e os ERPs da Salesforce, Oracles, EPICs, N4s etc. do mundo. E há uma quantidade grande e crescente de dados nos armazéns de dados e outros sistemas baseados em inteligência de negócios. Porque tudo, independentemente de onde e como é capturado, armazenado ou transacionado, acaba sendo analisado e, portanto, há uma enorme demanda e aumento no uso de bancos de dados, principalmente bancos de dados relacionais no mercado.
Agora, temos a demanda, temos enormes quantidades de dados chegando. E não estou realmente falando apenas sobre big data, estou falando sobre o uso de dados em todos os tipos de empresas. Mas, acompanhando isso, do lado da oferta, para as pessoas que podem gerenciar esses recursos, temos primeiro, temos uma escassez de DBA. Segundo o Bureau of Labor Statistics, de 2014 a 2024, os empregos no DBA crescerão apenas 11% - agora são pessoas que têm cargos no DBA, mas falamos sobre isso em um segundo - contra os mais de 40% espaço de crescimento anual de dados. E nós temos muitos DBAs; em média, o mesmo estudo falou sobre a idade média é bastante alta em comparação com outras profissões de TI. E então temos muitas pessoas saindo do campo, não necessariamente se aposentando, mas mudando para outros aspectos, ingressando na administração ou qualquer outra coisa.
Agora, parte do motivo pelo qual eles estão saindo, é porque o trabalho no DBA está ficando cada vez mais difícil. Primeiro, temos DBAs gerenciando muitos bancos de dados diferentes, físicos, localizados em todo o lugar, bem como diferentes tipos de bancos de dados. Agora isso pode ser relacional ou pode ser outro banco de dados, tipos de banco de dados também. Mas, mesmo que seja relacional, eles podem ter um, dois, três, quatro fornecedores diferentes que realmente estão tentando gerenciar. Os DBAs geralmente se envolvem após o design do banco de dados ou do aplicativo. Robin falou sobre como os bancos de dados ou aplicativos são projetados, como o SQL é projetado. Bem, quando falamos sobre modelagem de dados, modelagem de ER, modelagem de ER estendida, modelagem de dimensão, modelagem dimensional avançada, o que quer que seja, tipicamente programadores de aplicativos e desenvolvedores de aplicativos projetam com o objetivo final em mente - eles não estão projetando a eficiência da própria estrutura de banco de dados . Portanto, temos muito design inadequado.
Agora, não estou falando sobre os fornecedores de aplicativos corporativos comerciais; eles geralmente têm modelos de ER ou modelos de ER estendidos. O que estou falando é que há muito mais processos e aplicativos de negócios sendo criados pelos desenvolvedores de aplicativos em todas as empresas - esses não são necessariamente projetados para garantir a eficiência ou a eficácia da implantação. E os próprios DBAs estão sobrecarregados e, às vezes, têm responsabilidade 24 horas por dia, 7 dias por semana, e continuam recebendo mais e mais bancos de dados. Eu acho que isso tem um pouco a ver com as pessoas não entenderem o que fazem, ou como fazem. O seu pequeno grupo e as pessoas continuam pensando: "Bem, todas essas ferramentas são tão fáceis de usar, podemos continuar usando mais e mais bancos de dados em sua carga de trabalho", o que não é o caso.
O que nos leva aos DBAs em tempo parcial e acidentais. Temos equipes de TI que são pequenas e não podem necessariamente pagar um DBA dedicado. Agora isso é verdade para pequenas e médias empresas, onde a expansão do banco de dados e dos aplicativos de banco de dados explodiu na última década e continua a se expandir. Mas também é o caso das grandes corporações, que costumam fazer análise de inteligência de negócios em data warehouse, por muito, muito tempo. Há muito tempo, costumávamos obter DBAs dedicados para esses projetos; nunca mais temos um DBA dedicado. Foram responsáveis por projetar o banco de dados, o que é bom, se é alguém que tem experiência.Mas, em geral, os DBAs são desenvolvedores de aplicativos, geralmente assumem esse papel como parte de seu trabalho de meio período, não têm treinamento formal e, novamente, estão projetando-o para seus objetivos finais, não o estão projetando para obter eficiências.
E há muita diferença entre design e desenvolvimento, versus implantação e gerenciamento. Portanto, temos o “centavo sábio, o tolo da libra”, com um cofrinho lá, pulando para obter as habilidades e os recursos necessários nos projetos. Pensando que todo mundo é de "A Vingança dos Nerds", minha pequena foto lá. Agora, na medida do que as pessoas precisam, temos um uso crescente de bancos de dados e dados no SQL. Temos um número restrito de DBAs - pessoas qualificadas e especializadas nessas situações de ajuste e design, gerenciamento e implantação. E temos mais e mais DBAs em período parcial ou acidental, pessoas que ainda não receberam o treinamento formal.
Então, quais são algumas das outras coisas que também estão entrando na questão do fato de que esses bancos de dados não estão sendo ajustados ou gerenciados também? Primeiro, muitas pessoas assumem que o próprio sistema de banco de dados possui ferramentas suficientes para se gerenciar. Agora, as ferramentas estão ficando cada vez mais fáceis - design e desenvolvimento -, mas isso é diferente de fazer um bom design e um bom gerenciamento, planejamento de capacidade, monitoramento etc. para implantação. Então, primeiro, as pessoas assumem que possuem todas as ferramentas necessárias. Segundo, se você é um DBA em part-time ou acidental, não sabe o que não sabe.
Acho que esqueci algumas frases aqui, para que muitas vezes eles simplesmente não entendam o que precisam olhar no design ou quando estão gerenciando ou operando os bancos de dados. Se essa não é sua profissão, você não entenderá o que precisa fazer. Terceiro, é que o SQL é uma ferramenta essencial, então Robin falou sobre o SQL e como o SQL às vezes é construído, ou frequentemente é construído. E também um dos meus problemas no armazenamento de dados de BI, migração de dados, espaço de engenharia de dados é que, em vez de usar ferramentas, as pessoas tendem a escrever código SQL, procedimentos armazenados, mesmo que estejam usando uma ferramenta cara de integração de dados ou uma ferramenta cara. Ferramenta de BI, eles costumam realmente usá-lo apenas para executar procedimentos armazenados. Para que a importância de entender o design do banco de dados, a construção do SQL, esteja se tornando cada vez mais importante.
E, finalmente, existe essa abordagem de silo, na qual pessoas individuais analisam bancos de dados individuais. Eles não analisam como os aplicativos funcionam e interagem entre si. E eles também costumam olhar os bancos de dados versus os aplicativos para os quais eles os usam. Portanto, a carga de trabalho que você obtém no banco de dados é crítica no design, crítica no ajuste, crítica na tentativa de descobrir como planejar a capacidade etc. Então, olhando a floresta das árvores, as pessoas estão no mato , observando as tabelas e bancos de dados individuais e não observando a interação geral desses aplicativos na carga de trabalho.
Finalmente, as pessoas precisam olhar para as principais áreas em que precisam. Quando eles planejam gerenciar bancos de dados, primeiro precisam pensar sobre, desenvolver algumas métricas de desempenho centradas em aplicativos, para que eles observem não apenas como essa tabela está estruturada, como é particularmente modelada, mas como é usada? Portanto, se você tem um aplicativo corporativo que é devido no gerenciamento da cadeia de suprimentos, se está recebendo pedidos da Web, se está fazendo BI - o que quer que esteja fazendo -, precisa ver quem está usando, como está usando, quais são os volumes de dados , quando isso vai acontecer. O que você realmente está procurando é o tempo de espera, porque, não importa o quê, todos os aplicativos são julgados pelo tempo que leva para fazer algo, seja uma pessoa ou apenas o intercâmbio de dados entre aplicativos ou processadores. E quais são os gargalos? Muitas vezes, quando você está tentando depurar problemas, é claro, está realmente tentando ver quais são os gargalos reais - não necessariamente como ajustar tudo, mas como você se livra e aumenta o desempenho nos tempos de espera e na taxa de transferência - seja qual for você precisa olhar.
E você realmente precisa separar os aspectos de captura de dados, transações, transformações no banco de dados e análise. Cada um deles tem padrões de design diferentes, cada um deles tem diferentes padrões de uso e cada um deles precisa ser ajustado de maneira diferente. Portanto, você precisa pensar em como esses dados são usados, quando usados, para que servem e descobrir quais são as métricas de desempenho e quais são as principais coisas que você deseja analisar relacionadas a esse uso. Agora, quando você está olhando para monitorar o desempenho, deseja ver as próprias operações do banco de dados; você deseja examinar as estruturas de dados, para que os índices, particionamento e outros aspectos físicos do banco de dados, até mesmo a estrutura do banco de dados - seja seu modelo de ER ou modelo dimensional, porém estruturado - todas essas coisas tenham impacto no desempenho , especialmente nos diferentes contras da análise de captura de dados e nas transformações que acontecem.
E, como Robin mencionou no lado do SQL, analisar o SQL que está sendo executado por esses aplicativos diferentes nesses bancos de dados e ajustá-lo é fundamental. E observando as cargas de trabalho gerais de aplicativos e o ambiente de infraestrutura em que esses bancos de dados e aplicativos são executados. Portanto, para que as redes, os servidores, a nuvem - independentemente do que eles estejam executando - também analisem o impacto que esses aplicativos e esses bancos de dados têm nesse contexto, todos têm a possibilidade de ajustar o banco de dados.
E, finalmente, quando você estiver analisando ferramentas, poderá analisar os três tipos diferentes de análise relacionados a isso. Você deseja analisar a análise descritiva: o que está acontecendo e onde, relacionado ao banco de dados e ao desempenho do aplicativo. Você deseja ter a capacidade de fazer análises de diagnóstico para descobrir não apenas o que está acontecendo, mas por que está acontecendo, onde estão os gargalos, onde estão os problemas, o que está funcionando bem, o que não está funcionando bem? Mas ser capaz de analisar e detalhar as áreas problemáticas para abordá-las, seja para design ou para o que você precisa fazer.
E, finalmente, o tipo mais agressivo ou proativo de análise é realmente fazer algumas análises preditivas, modelagem de análise preditiva, qualquer que seja. Sabemos que o banco de dados e os aplicativos funcionam nesse caso, se aumentarmos a capacidade, se conseguirmos mais usuários, se fizermos mais taxa de transferência, o que estiver fazendo, poder projetar o que, como e onde isso afetará o banco de dados, os aplicativos, permite planejar e descobrir proativamente onde estão os gargalos, onde os tempos de espera podem sofrer e o que precisamos fazer para consertar as coisas. Portanto, queremos ter ferramentas capazes de implementar as métricas de desempenho, monitorar o desempenho, assim como esses três tipos de análise. E essa é a minha visão geral.
Eric Kavanagh: Tudo bem, deixe-me entregá-lo a - essas são duas grandes apresentações, a propósito - deixe-o entregar a Bullett Manale para levá-lo a partir daí. E pessoal, não se esqueça de fazer boas perguntas; já temos um bom conteúdo. Vá embora, Bullett.
Bullett Manale: Parece bom. Obrigado, Eric. Então, muito do que Rick disse e Robin disse, obviamente eu concordo com 100%. Eu diria que puxei este slide para cima, porque acho adequado, não sei para aqueles que são fãs do “A-Team” nos anos 80, John Hannibal Smith tinha um ditado que sempre dizia: “Eu amo quando um plano é elaborado ”, e eu acho que quando você está falando particularmente do SQL Server, que é o local em que estamos focando, que é o produto sobre o qual falaremos hoje, o SQL Diagnostic Manager, é definitivamente uma daquelas coisas que você tem que ter; você precisa aproveitar os dados que possui e tomar decisões com base nesses dados e, em alguns casos, não está procurando uma decisão; você está procurando algo para lhe dizer quando algo vai ficar sem recursos, quando você vai ficar sem recursos, quando você vai ter um gargalo, esse tipo de coisa.
Não se trata apenas de monitorar uma métrica específica. Portanto, com o Diagnostic Manager, uma das coisas que ele faz muito bem é ajudá-lo em termos de previsão e entendimento específico das cargas de trabalho, e falaríamos sobre isso hoje. A ferramenta é voltada para o gerenciador de dados, o DBA ou o DBA ativo, portanto, muitas das coisas que Rick estava mencionando, o DBA ativo é tão verdadeiro. Em muitos casos, se você não é um DBA, haverá muitos pontos de interrogação que você terá quando chegar a hora de gerenciar um ambiente SQL, coisas que você não sabe. Então, você está procurando algo para ajudá-lo, conduzi-lo por esse processo e também educá-lo no processo. E, portanto, é importante que a ferramenta que você usa para esse tipo de decisão lhe dê algumas dicas sobre os motivos pelos quais essas decisões estão sendo tomadas, não apenas dizendo: "Ei, faça isso".
Por ser o DBA atuante, eventualmente eu poderia ser o DBA completo com a experiência e o conhecimento reais para apoiar esse título. Portanto, quando falamos em ser um administrador de banco de dados - eu sempre mostro esse slide primeiro, porque o DBA tem algumas funções diferentes e, dependendo da organização com a qual você está, você vai ter, elas variam de de um lugar para outro - mas normalmente, você sempre será de alguma forma responsável pelo seu armazenamento, seu planejamento e seu entendimento de antecipar, devo dizer, quanto espaço você precisará, seja para backups ou se é para os próprios bancos de dados. Você precisará entender e avaliar isso.
Além disso, você precisará entender e otimizar as coisas conforme a necessidade e, ao monitorar o ambiente, é obviamente importante que você faça alterações conforme necessário, com base nas coisas que mudam no ambiente. em si. Portanto, coisas como o número de usuários, a popularidade de aplicativos, a sazonalidade de um banco de dados, tudo deve ser considerado quando você estiver fazendo sua previsão. E então, obviamente, observando outras coisas em termos de poder fornecer os relatórios e as informações necessárias no que se refere à tomada dessas decisões. Em muitos casos, isso significa fazer uma análise comparativa; significa poder olhar especificamente para uma métrica específica e entender qual foi o valor dessa métrica ao longo do tempo, para que você possa antecipar para onde vai avançar.
Então, o que grande parte da ferramenta Diagnostic Manager faz com esses recursos e as pessoas o usam todos os dias para poder fazer coisas como previsão, e eu coloquei aqui a definição de planejamento de capacidade. E é uma definição bastante ampla e, na verdade, bastante vaga, que é apenas o processo de determinar a capacidade de produção necessária para uma organização atender às demandas variáveis de seus produtos e, no final das contas, é exatamente isso: sobre poder obter informações de uma maneira ou de outra, tomar essas informações e tomar decisões para ajudá-lo a avançar à medida que avança no ciclo de vida de seus bancos de dados. E assim, os tipos de coisas que são as razões pelas quais as pessoas precisam fazer isso são, obviamente, em primeiro lugar, na maioria dos casos, para economizar dinheiro. As empresas, obviamente, esse é o seu principal objetivo é ganhar dinheiro e economizar dinheiro. Mas no processo, junto com isso, também significa ser capaz de garantir que seu tempo de inatividade não ocorra. E poder garantir que você reduza qualquer chance de tempo de inatividade, impedindo que isso aconteça para começar, ou seja, sem esperar que isso aconteça e depois reagir a ele.
Além de poder aumentar a produtividade de seus usuários, tornando-os mais eficientes para que você possa realizar mais negócios, é obviamente a chave aqui; portanto, esses são os tipos de coisas que, como o DBA ou alguém envolvido na previsão ou capacidade o planejamento terá que ser capaz de percorrer as informações para poder tomar essas decisões. E, em geral, isso obviamente ajudará a eliminar o desperdício, não apenas em termos de dinheiro, mas também em termos de tempo e de recursos geralmente que poderiam ser usados para outras coisas, possivelmente. Portanto, ser capaz de eliminar esse desperdício para que você não tenha custos de oportunidade vinculados ao próprio desperdício.
Então, com isso dito, quais são os tipos de perguntas que recebemos, específicas para a pessoa que é um DBA? Quando vou ficar sem espaço? É um grande problema, não apenas quanto espaço estou consumindo agora, mas quando vou acabar, com base nas tendências e na história passada? A mesma coisa com as instâncias reais do SQL, os bancos de dados, quais servidores posso consolidar? Vou colocar um pouco nas VMs, o que faz sentido em termos de quais bancos de dados vou consolidar e em quais instâncias do SQL eles devem residir? Todos esses tipos de perguntas precisam poder ser respondidos. Porque na maioria dos casos, se você é um DBA ou DBA atuante, você o consolidará em algum momento de sua carreira. Em muitos casos, você fará isso continuamente. Portanto, você precisa tomar essas decisões rapidamente, não jogar jogos de adivinhação quando se trata disso.
Conversamos sobre gargalos e onde eles ocorrerão a seguir, podendo antecipar isso mais uma vez, em vez de esperar que eles aconteçam. Portanto, obviamente, todas essas coisas estavam falando, faz sentido no sentido de que você conta com dados históricos, na maioria dos casos, para poder gerar essas recomendações ou, em alguns casos, formular decisões por conta própria, para poder venha com essas respostas. Mas isso me lembra de que, quando você ouve os anúncios de rádio de alguém que vende títulos ou algo parecido, seu sempre "desempenho passado não é indicativo de resultados futuros" e esse tipo de coisa. E a mesma coisa se aplica aqui. Você terá situações em que essas previsões e análises podem não estar 100% corretas. Mas se você está lidando com coisas que aconteceram no passado e no conhecido, e sendo capaz de fazer e fazer o que acontecer com muitos desses tipos de perguntas, você vai se deparar com isso é muito valioso e você vai muito além do jogo de adivinhação.
Portanto, esses tipos de perguntas obviamente vão surgir; portanto, como lidamos com muitas dessas perguntas com o Diagnostic Manager, primeiro temos recursos de previsão, podendo fazer isso no banco de dados, na mesa e no unidade ou o volume. Para poder não apenas dizer: "Ei, estava cheio de espaço", mas daqui a seis meses, daqui a dois anos, daqui a cinco anos, se eu estiver fazendo um orçamento para isso, quanto espaço em disco vou precisar fazer? para? Essas são perguntas que vou ter que fazer, e vou precisar usar algum método para fazer isso, em vez de adivinhar e colocar o dedo no ar e esperar para ver para que lado o vento sopra, o que é muito algumas vezes, infelizmente, a maneira como muitas dessas decisões são tomadas.
Além disso, ser capaz de - parece que meu slide foi cortado um pouco - mas ser capaz de fornecer assistência na forma de recomendações. Portanto, uma coisa é poder mostrar um painel cheio de métricas e dizer: "OK, aqui estão todas as métricas e onde elas estão", mas depois poder fazer algumas ou entender o que fazer com base nisso é outro salto. E, em alguns casos, as pessoas são instruídas o suficiente no papel do DBA para poder tomar essas decisões. E, portanto, temos alguns mecanismos na ferramenta que ajudarão com isso, que mostram em apenas um segundo. Mas ser capaz de mostrar não apenas o que é a recomendação, mas também fornecer algumas dicas sobre por que essa recomendação está sendo feita e, além disso, além disso, em alguns casos, ser capaz de realmente criar um script que automatize o a solução para esse problema também é ideal.
Passando para o próximo aqui, que bem vê, é apenas um entendimento geral até o nível métrico do que é normal. Não posso lhe dizer o que não é normal se não sei o que é normal. E, portanto, ter uma maneira de medir isso é essencial e você deve levar em consideração vários tipos de áreas, por exemplo - ou, devo dizer, prazos - diferentes grupos de servidores, podendo fazer isso dinamicamente, a partir de um perspectiva de alerta, em outras palavras, durante o meio da noite, durante minha janela de manutenção, espero que minha CPU esteja funcionando a 80% com base em toda a manutenção que está ocorrendo. Portanto, talvez eu queira aumentar meus limiares mais alto, durante esses períodos de tempo e talvez no meio do dia, quando não estou tendo tanta atividade.
Essas são algumas coisas que obviamente serão ambientais, mas as que você pode aplicar ao que está sendo gerenciado, para ajudá-lo a gerenciar esse ambiente com mais eficiência e facilitar o processo. A outra área, obviamente, é a capacidade de fornecer, de maneira geral, os relatórios e as informações para poder responder a esses tipos de perguntas "e se". Se eu acabei de fazer uma alteração no meu ambiente, quero entender qual foi esse impacto, para poder aplicar a mesma alteração a outras instâncias ou outros bancos de dados no meu ambiente. Quero poder ter alguma informação ou munição para poder fazer essa mudança com alguma tranquilidade e sabendo que será uma boa mudança. Portanto, poder fazer esse relatório comparativo, poder classificar minhas instâncias do SQL, poder classificar meus bancos de dados uns contra os outros, para dizer: “Qual é o meu maior consumidor de CPU?” Ou qual deles está demorando mais tempo? termos de espera e coisas assim? Portanto, muitas dessas informações também estarão disponíveis com a ferramenta.
E então, por último, mas não menos importante, é apenas uma habilidade geral de que você precisa de uma ferramenta capaz de lidar com qualquer situação que surgir, e então o que quero dizer com isso é que, se você tem um ambiente amplo com muito Em algumas instâncias, você provavelmente encontrará situações em que precisará extrair métricas que tradicionalmente não são métricas que um DBA gostaria de monitorar em alguns casos, dependendo dessa situação específica. Portanto, ter uma ferramenta extensível para adicionar métricas adicionais e usá-las da mesma forma e da mesma maneira que você as usaria se estivesse usando uma ferramenta pronta para uso métrica, por exemplo. Portanto, poder gerar relatórios, alertar, baseline - todas as coisas estavam falando - também é uma parte essencial de poder fazer essa previsão e torná-lo para que você obtenha as respostas que procura para poder fazer essas decisões, avançando.
Agora, da maneira que o Diagnostic Manager faz isso, temos um serviço centralizado, um grupo de serviços que executa, coleta dados em instâncias de 2000 a 2016. E então o que fazemos é pegar esses dados e colocá-los em um repositório central e, em seguida, o que fazemos com esses dados, obviamente, é que fazemos muito para poder fornecer mais informações. Agora, além disso - e uma das coisas que não estão aqui - é que também temos um serviço que é executado no meio da noite, que é o nosso serviço de análise preditiva, que faz uma trituração de números e ajuda a entender e ajudá-lo como um DBA ou DBA ativo, a fim de poder fazer esses tipos de recomendações e também fornecer algumas dicas em termos de linhas de base.
Então, o que eu gostaria de fazer, e este é apenas um exemplo rápido da arquitetura, o ponto principal aqui é que não existem agentes ou serviços que realmente estejam nas instâncias que você está gerenciando. Mas o que eu gostaria de fazer é realmente levá-lo para o aplicativo aqui e fazer uma demonstração rápida. E deixe-me sair também, e fazer isso acontecer. Então, deixe-me saber, eu acho Eric, você consegue ver isso?
Eric Kavanagh: Entendi agora, sim.
Bullett Manale: OK, então eu vou levá-lo através de algumas dessas partes diferentes em que falei. E, basicamente, vamos começar com o tipo de coisas que são mais parecidas com as seguintes, algo que você precisa fazer, ou aqui é algo que é um ponto no tempo no futuro e que lhe dará algumas dicas sobre isso. E isso é ser capaz de realmente antecipar - ou devo dizer, antecipar dinamicamente - as coisas enquanto elas estão acontecendo. Agora, no caso de relatórios, uma das coisas que temos na ferramenta são três relatórios de previsão diferentes. E no caso, por exemplo, de uma previsão de banco de dados, o que eu provavelmente faria na situação de antecipar o tamanho de um banco de dados por um período de tempo, e eu apenas darei alguns exemplos disso. Então, eu vou pegar meu banco de dados de auditoria, que é bastante intensivo em E / S - há muitos dados nele. Temos, vamos ver, bem, faça este aqui, e vamos apenas pegar o banco de dados de assistência médica aqui.
Mas a questão é: não estou vendo apenas o espaço, sou capaz de dizer: "Veja, vamos aproveitar os dados dos últimos anos" - e vou ficar aqui um pouco, não tenho anos no valor de dados, tenho cerca de dois meses no valor de dados - mas, como estou escolhendo uma taxa de amostragem de meses aqui, poderei antecipar ou prever neste caso as próximas 36 unidades porque nossa taxa de amostragem está definida para meses - isto é uma unidade, é um mês - e então eu seria capaz de, em seguida, executar um relatório para basicamente me mostrar onde anteciparíamos nosso crescimento futuro, para esses três bancos de dados. E podemos ver que temos um grau variável de diferença, ou variação, entre os três bancos de dados diferentes, particularmente a quantidade de dados que eles estão consumindo historicamente.
Podemos ver que os pontos de dados aqui representam os dados históricos e, em seguida, as linhas nos fornecerão a previsão, juntamente com os números para respaldar isso. Para que possamos fazer isso no nível da mesa, podemos fazer isso mesmo no nível da unidade, onde posso prever o tamanho das minhas unidades, incluindo pontos de montagem. Poderíamos prever esse mesmo tipo de informação, mas mais uma vez, dependendo da taxa de amostragem, me permitirá determinar quantas unidades e para onde levamos o que queremos prever. Observe também que temos diferentes tipos de previsão. Assim, você obtém muitas opções e flexibilidade na hora de fazer a previsão. Agora, isso é uma coisa que se deve fazer: fornecer uma data específica e poder dizer: "Ei, nesta data, é onde anteciparemos o crescimento de seus dados". Além disso, podemos fornecer a você com outras idéias relacionadas a algumas das análises que realizamos durante o horário de folga e ao serviço quando ele é executado. Algumas das coisas que faz é tentar antecipar as coisas que provavelmente acontecerão, com base na história de quando as coisas ocorreram no passado.
Para que possamos ver aqui, na verdade, uma previsão está nos fornecendo algumas dicas sobre a probabilidade de termos problemas durante a noite com base em coisas que mais uma vez aconteceram no passado. Então, obviamente, isso é ótimo, especialmente se eu não sou um DBA, posso ver essas coisas, mas o que é ainda melhor se eu não sou um DBA, é essa guia de análise. Então, antes que isso estivesse aqui na ferramenta, mostraríamos o produto às pessoas e elas seriam "Isso é ótimo, eu vejo todos esses números, vejo tudo, mas não sei o que fazer" (risos) "como como resultado disso. ”E, portanto, o que temos aqui é uma maneira melhor de você entender, se eu vou tomar uma ação para ajudar no desempenho, se eu vou tomar uma ação para até ajudar na saúde de meus ambiente, poder ter uma maneira classificada de fornecer essas recomendações, além de dicas úteis em informações para aprender mais sobre essas recomendações e, na verdade, ter até links externos para alguns desses dados, que me mostrarão e me levarão às razões pelas quais essas recomendações são feitas.
E, em muitos casos, ser capaz de fornecer um script que automatize, como eu disse, a correção desses problemas. Agora, parte do que estava fazendo aqui com esta análise - e mostrarei quando for configurar as propriedades dessa instância e vou para a seção de configuração da análise -, temos muitas categorias diferentes listadas aqui e parte disso, temos otimização de índice e otimização de consulta. Portanto, avaliamos não apenas as próprias métricas e coisas assim, mas também as cargas de trabalho e os índices. No caso aqui, faça algumas análises hipotéticas adicionais adicionais. Portanto, é uma daquelas situações em que não quero, em muitos casos, não quero adicionar um índice se não precisar. Mas, em algum momento, há um ponto de inflexão, onde digo: “Bem, a tabela está chegando ao tamanho ou aos tipos de consultas em execução na carga de trabalho que agora fazem sentido adicionar um índice. Mas isso não faria sentido talvez seis semanas antes. ”Portanto, isso permite que você obtenha dinamicamente esse insight sobre coisas que provavelmente, como eu disse, melhoram o desempenho com base no que está acontecendo no ambiente, no que está acontecendo nas cargas de trabalho e fazendo esse tipo de coisa.
E, assim, você obtém muitas informações boas aqui, além da capacidade de otimizar essas coisas automaticamente. Portanto, essa é outra área em que poderíamos ajudar, em termos do que chamamos de análise preditiva. Agora, além disso, devo dizer, também temos outras áreas que acho que geralmente se prestam a ajudá-lo a tomar decisões. E quando falamos em tomar decisões, mais uma vez, poder analisar dados históricos, fornecemos algumas dicas para nos levar aonde precisamos estar para melhorar esse desempenho.
Agora, uma das coisas que podemos fazer é ter um visualizador de linha de base que nos permite escolher seletivamente qualquer métrica que desejarmos - e deixe-me encontrar uma decente aqui - vou para o uso da CPU SQL, mas o ponto é que você pode ir volte ao longo de muitas semanas para pintar essas figuras para você ver quando estão os valores extremos, para ver de maneira geral onde esse valor cai dentro dos períodos de tempo em que coletamos dados. Além disso, você também notará que, quando formos para a instância atual, temos a capacidade de configurar nossas linhas de base. E as linhas de base são uma parte realmente importante de poder automatizar as coisas, além de poder ser notificado sobre elas. E o desafio, como a maioria dos DBAs diria, é que seu ambiente nem sempre está funcionando da mesma forma, durante o dia, contra a noite e outros enfeites, como mencionamos anteriormente no exemplo com os períodos de manutenção, quando ter altos níveis de CPU ou o que quer que esteja acontecendo.
Portanto, no caso aqui, com essas linhas de base reais, podemos ter várias linhas de base; portanto, posso ter uma linha de base, por exemplo, durante minhas horas de manutenção. Mas eu poderia facilmente criar uma linha de base para minhas horas de produção. E o ponto de fazer isso é quando entramos em uma instância do SQL e, na verdade, temos essas várias linhas de base; poderíamos antecipar e poder executar algum tipo de automação, algum tipo de correção ou apenas alerta em geral, diferentemente específico para essas janelas de tempo. Portanto, uma das coisas que você verá aqui é que essas linhas de base que geramos estão usando os dados históricos para fornecer essa análise, mas o mais importante é que posso alterar esses limites estaticamente, mas também posso automatizá-los dinamicamente. Assim, à medida que a janela de manutenção, ou devo dizer, a janela da linha de base de manutenção, esses limites mudariam automaticamente específicos para as cargas que estou encontrando durante essa janela de tempo, em comparação com talvez no meio do dia, quando minhas cargas não forem tão muito, quando as cargas de trabalho não são tão impactantes.
Então, isso é algo a ter em mente, em termos da linha de base. Obviamente, isso será realmente útil para você, em termos de entender o que é normal e ser capaz de entender, envolver-se quando você também estiver ficando sem recursos. Agora, o outro tipo de coisa que temos na ferramenta, que o ajudará a tomar decisões, além da linha de base e da capacidade de configurar alertas em torno dessas linhas de base e dos limites que você cria dinamicamente, é como eu disse anteriormente, apenas poder gerar uma infinidade de relatórios que me ajudam a responder perguntas sobre o que está acontecendo.
Então, como exemplo, se eu tivesse 150 instâncias que estou gerenciando - no meu caso, não, então temos que jogar o jogo de fingir aqui - mas se eu tivesse todas as minhas instâncias de produção e precisava entender onde é a área em que preciso de atenção, em outras palavras, se tiver apenas um tempo limitado para executar algum tipo de administração para melhorar o desempenho, quero me concentrar nas áreas-chave. E assim, com isso dito, eu seria capaz de dizer: "Com base nesse ambiente, classifique minhas instâncias umas contra as outras e me dê essa classificação por canal de contenção". Portanto, se o uso do disco, o uso da memória, se espera, seja o seu tempo de resposta, sou capaz de correlacionar - ou melhor, classificar - essas instâncias umas contra as outras. Obviamente, a instância que está no topo de cada lista, se for a mesma, provavelmente é algo que eu realmente quero focar, porque obviamente está mais uma vez no topo da lista.
Portanto, você tem muitos relatórios na ferramenta que o ajudam em termos de classificação do ambiente no nível da instância; você também pode fazer isso no nível do banco de dados, onde posso classificar meus bancos de dados um contra o outro. Particularmente nos limites e áreas que posso definir, posso até configurar caracteres curinga aqui, se quiser, para focar apenas em bancos de dados específicos, mas o ponto é que posso comparar meus bancos de dados da mesma maneira. Além disso, no que diz respeito a outros tipos de análise comparativa e a grande ferramenta, é a análise de linha de base que temos. Portanto, se você rolar para a visualização de serviço aqui, verá um relatório estatístico de linha de base. Agora, obviamente, este relatório nos ajudará a entender não apenas quais são os valores das métricas, mas para uma instância específica que eu poderia publicar e, para qualquer uma dessas métricas, poder realmente olhar as linhas de base dessas métricas.
Portanto, seja o que for, como uma porcentagem ou o que eu poderia falar e dizer: "Vamos ver a linha de base para isso nos últimos 30 dias", caso em que me mostrará os valores reais em relação à linha de base e Eu seria capaz de tomar algumas decisões usando essas informações, obviamente, então essa é uma daquelas situações em que vai depender de qual é a pergunta que você está perguntando no momento. Mas isso obviamente irá ajudá-lo em muitas dessas perguntas. Eu gostaria de poder dizer que tivemos um relatório que faz tudo isso, e é como o relatório fácil, onde você pressiona e abotoa e ele apenas responde a todas as perguntas "e se" que você poderia responder. Mas a realidade é que você terá muitos atributos e muitas opções para escolher nessas opções para formular as perguntas do tipo "e se" que você está procurando.
Portanto, muitos desses relatórios são voltados para a capacidade de responder a esses tipos de perguntas. E, portanto, é realmente importante também que esses relatórios e, além disso, tudo o que já mostramos na ferramenta, como mencionei anteriormente, tenha flexibilidade para incorporar novas métricas, para ser gerenciado e até mesmo para criar contadores, ou consultas SQL que são incorporadas aos seus intervalos de pesquisa, para poder me ajudar a responder a essas perguntas, que talvez não estejam disponíveis no momento em que não esperávamos monitorar, você pode adicionar essas coisas. E você poderá fazer as mesmas coisas que acabei de mostrar: linha de base, gerar relatórios e criar relatórios a partir dessa métrica, além de poder responder e fazer vários tipos diferentes de coisas que estou mostrando aqui.
Agora, além disso - e uma das coisas com as quais obviamente nos deparamos um pouco ultimamente -, primeiro, todo mundo está lançando ou alternando para VMs. E agora temos muitas pessoas que estão indo para a nuvem. E há muitas perguntas que surgem sobre esse tipo de coisa. Faz sentido para mim mudar para a nuvem? Vou economizar dinheiro mudando para a nuvem? Se eu colocar essas coisas em uma VM, em uma máquina de recursos compartilhados, quanto dinheiro posso economizar? Esses tipos de perguntas, obviamente, também serão apresentados. Portanto, lembre-se de que muitas dessas coisas, com o Diagnostic Manager, podemos adicionar e extrair dos ambientes virtualizados do VMware e Hyper-V. Também podemos adicionar instâncias que estão na nuvem, para que seus ambientes, como o Azure DB, por exemplo, ou mesmo o RDS, possamos extrair métricas desses ambientes.
Portanto, há muita flexibilidade e muita capacidade de responder a essas perguntas no que se refere a outros tipos de ambientes para os quais vemos pessoas indo. E ainda há muitas perguntas sobre esse assunto, e como vemos as pessoas consolidando esses ambientes, elas também precisam ser capazes de responder a essas perguntas. Portanto, é uma visão geral muito boa, eu diria, do Diagnostic Manager, no que se refere a este tópico. Sei que o assunto de business intelligence surgiu e também temos uma ferramenta para business intelligence sobre a qual não falamos hoje, mas também fornecerá uma visão em termos de resposta a esses tipos de perguntas no que se refere a seus cubos e todos esses tipos diferentes de coisas também. Mas espero que tenha sido uma boa visão geral, pelo menos em termos de como este produto pode ajudar a formular um bom plano.
Eric Kavanagh: Tudo bem, coisas boas. Sim, vou jogar para Rick, se ele ainda estiver por aí. Rick, alguma pergunta sua?
Rick Sherman: Sim, então primeiro, isso é ótimo, eu gosto. Eu particularmente gosto de estender para VMs e nuvens. Vejo muitos desenvolvedores de aplicativos pensarem que, se estiver na nuvem, não precisam ajustá-lo. Assim-
Bullett Manale: Certo, ainda temos que pagar por isso, certo? Você ainda tem que pagar por tudo o que as pessoas estão colocando na nuvem; por isso, se estiver funcionando mal ou causando muitos ciclos de CPU, mais dinheiro você precisará pagar, então não precisa, ainda precisa medir essas coisas, absolutamente.
Rick Sherman: Sim, eu já vi muitos designs ruins na nuvem. Eu queria perguntar, esse produto também seria usado - eu sei que você mencionou o produto de BI e você tem vários outros produtos que interagem entre si - mas você começaria a analisar o desempenho do SQL, consultas individuais nesta ferramenta? Ou seriam outras ferramentas que seriam usadas para isso?
Bullett Manale: Não, isso seria absolutamente. Essa é uma das coisas que eu não cobri e pretendia, é a parte das consultas. Temos várias maneiras diferentes de identificar o desempenho da consulta, seja relacionado a, especificamente a espera, como vemos nesta exibição aqui ou relacionado ao consumo de recursos das consultas em geral, e existem várias maneiras de analisar a consulta desempenho. Quer seja a duração, CPU, E / S e, mais uma vez, também podemos observar as próprias cargas de trabalho para fornecer algumas dicas. Podemos fornecer as recomendações na seção de análise e também temos uma versão baseada na Web que fornece informações sobre as próprias consultas. Para que eu possa obter recomendações sobre índices ausentes e a capacidade de visualizar o plano de execução e todo esse tipo de coisa; também é uma capacidade. Portanto, absolutamente, podemos diagnosticar consultas de sete maneiras até o domingo (risos) e poder fornecer esse insight em termos de número de execuções, seja consumo de recursos, esperas, duração, todas essas coisas boas.
Rick Sherman: OK ótimo. E então qual é a carga nas instâncias em si com todo esse monitoramento?
Bullett Manale: É uma boa pergunta. O desafio de responder a essa pergunta é, depende, é como qualquer outra coisa. Muito do que nossa ferramenta tem a oferecer, ela fornece flexibilidade e parte dessa flexibilidade é que você pode dizer o que coletar e o que não coletar. Por exemplo, com as consultas em si, não preciso coletar as informações de espera ou posso. Posso coletar informações relacionadas a consultas que ultrapassam uma duração de tempo, de execução. Como exemplo disso, se eu fosse ao monitor de consulta de configuração e dissesse: "Vamos alterar esse valor para zero", a realidade é que basicamente faz com que a ferramenta colete todas as consultas que são executadas e isso realmente não é o espírito do porquê disso, mas de um modo geral, se eu quisesse fornecer uma amostra completa de dados para todas as consultas, eu poderia fazer isso.
Portanto, é muito relativo ao que suas configurações estão, de um modo geral, prontas para uso. Está entre 1 e 3% de sobrecarga, mas existem outras condições que serão aplicadas. Também depende da quantidade de consultas de porta em execução no seu ambiente, certo? Também depende do método de coleta dessas consultas e de qual versão do SQL é. Assim, por exemplo, o SQL Server 2005, não seria possível extrair de eventos estendidos, enquanto que extraímos um rastreio para fazer isso. Portanto, seria um pouco diferente em termos de como coletar esses dados, mas isso disse, como eu disse, que já existia há cerca de 2004 com este produto. Já faz muito tempo, temos milhares de clientes, então a última coisa que queremos fazer é ter uma ferramenta de monitoramento de desempenho que cause problemas de desempenho (risos). E, portanto, tentamos evitar isso, tanto quanto possível, mas de um modo geral, cerca de 1% a 3% é uma boa regra geral.
Rick Sherman: OK, e isso é muito baixo, então isso é fantástico.
Eric Kavanagh: Boa. Robin, alguma pergunta sua?
Robin Bloor: Me desculpe, eu estava mudo. Você tem um recurso de vários bancos de dados e estou interessado em saber como você pode analisar vários bancos de dados e, portanto, saber que uma base maior de recursos possivelmente está dividida entre várias máquinas virtuais e assim por diante. Estou interessado em saber como as pessoas realmente usam isso. Estou interessado no que os clientes estão fazendo com isso. Porque isso me parece, bem, certamente, quando eu estava mexendo com bancos de dados, algo que eu nunca tinha à mão. E eu consideraria apenas uma instância de maneira significativa a qualquer momento. Então, como as pessoas usam isso?
Bullett Manale: De um modo geral, você está falando, em geral, apenas da própria ferramenta? Como eles estão usando isso? Quero dizer, geralmente, é sobre poder ter um ponto central de presença do meio ambiente. Tendo paz de espírito e sabendo que, se eles olham para uma tela e vêem verde, sabem que tudo está bem. É quando os problemas acontecem e, obviamente, a maioria dos casos da perspectiva dos DBAs, muitas vezes esses problemas acontecem quando eles estão na frente do console, podendo ser notificados assim que o problema está acontecendo. Mas, além disso, ser capaz de entender quando o problema ocorre, ser capaz de chegar ao cerne das informações que estão lhes fornecendo algum contras em termos de por que isso está acontecendo. E isso é, eu acho, a maior parte: ser proativo, não ser reativo.
A maioria dos DBAs com os quais converso - e não sei, é uma boa porcentagem deles - infelizmente ainda está no tipo reativo de ambiente; eles esperam que um consumidor os aproxime para dizer que há um problema. E assim, vemos muitas pessoas tentando romper com isso e acho que essa é uma grande parte do motivo pelo qual as pessoas gostam dessa ferramenta é que ela as ajuda a serem proativas, mas também fornece a elas o insight do que está acontecendo , qual é o problema, mas em muitos casos, o que encontramos pelo menos - e talvez sejam apenas os DBAs nos dizendo isso - mas os DBAs, a percepção é sempre o problema deles, mesmo que seja o desenvolvedor do aplicativo que escreveu o aplicativo que não o escreveram corretamente, eles serão os culpados, porque eles levarão esse aplicativo para seus sistemas ou servidores e, quando o desempenho for ruim, todo mundo aponta para o DBA e diz: "Ei, é sua culpa".
Portanto, essa ferramenta muitas vezes será usada para ajudar o DBA a dizer: “Ei, é aqui que está o problema e não sou eu.” (Risos) Precisamos melhore isso, seja alterando as consultas ou o que quer que seja. Em alguns casos, ele cairá no balde em termos de responsabilidade, mas pelo menos ter a ferramenta para ajudá-los a entender isso e saber disso, e fazê-lo em tempo hábil é obviamente a abordagem ideal.
Robin Bloor: Sim, na maioria dos sites que eu conheço, mas já faz um tempo desde que eu estive por aí, olhando para vários sites com vários bancos de dados, mas principalmente o que eu costumava encontrar era que haveria DBAs focados em um punhado de bancos de dados. E esses seriam os bancos de dados, que, se algum dia fossem desativados, seria um grande problema para os negócios e assim por diante. E os outros, eles apenas colecionam estatísticas de vez em quando para ver que não ficaram sem espaço e nunca olharam para elas. E enquanto você estava fazendo a demonstração, eu estava olhando para isso e pensando bem, de uma maneira ou de outra, você estende, fornecendo algo parecido com isto para bancos de dados que costumavam ser, ninguém se importava muito, porque eles têm crescimento de dados , eles também têm crescimento de aplicativos. Você está estendendo a cobertura do DBA de uma maneira bastante dramática. Então, é disso que se trata, é que, com um conjunto de ferramentas como essa, você acaba conseguindo praticamente fornecer um serviço de DBA para todos os bancos de dados que estão na rede corporativa?
Bullett Manale: Claro, quero dizer, o desafio é que, como você disse de maneira bastante eloquente, há alguns bancos de dados com os quais os DBAs se importam e outros que não se importam tanto. E a maneira como esse produto em particular, a forma como é licenciado é por instância. Então, acho que você diria que existe um limiar de quando as pessoas decidem: "Ei, essa não é uma instância crítica o suficiente para que eu queira gerenciá-la com esta ferramenta". Dito isso, existem outras ferramentas que temos mais , Eu acho, atendendo a essas instâncias menos importantes do SQL. Uma delas seria como o Gerente de inventário, onde fazemos verificações de integridade leves nas instâncias, mas, além disso, o que fazemos é a descoberta, para identificar novas instâncias que foram colocadas on-line e, a partir desse ponto, como DBA, posso dizer: “OK, aqui está uma nova instância do SQL, agora é Express? É a versão gratuita ou é uma versão corporativa? ”Essa é provavelmente uma pergunta que eu quero me perguntar, mas em segundo lugar, qual a importância dessa instância para mim? Se não for tão importante, eu posso ter essa ferramenta, genérica, o que eu chamaria de verificações genéricas de saúde, no sentido de que são os tipos elementares de coisas com as quais me importo como DBA: a unidade está enchendo? O servidor está respondendo a problemas? As principais coisas, certo?
Considerando que com o Diagnostic Manager, a ferramenta que eu estava apenas mostrando a você, vai descer para o nível de consulta, vai para a recomendação de índices, olhando para o plano de execução e todas essas coisas boas, enquanto isso é focado principalmente sobre quem possui o quê, o que é que possuo e quem é responsável por isso? Quais service packs e hot fixes eu tenho? E meus servidores estão rodando com os principais ingredientes do que eu consideraria uma instância saudável do SQL? Então, para responder sua pergunta, há um pouco de mistura. Quando temos pessoas olhando para essa ferramenta, elas geralmente estão olhando para um conjunto mais crítico de instâncias. Dito isto, temos algumas pessoas que compram todas as instâncias que possuem e gerenciam, então isso depende. Mas eu digo a você, no geral, que definitivamente existe um limite para as pessoas que consideram seu ambiente importante o suficiente para ter uma ferramenta como essa para gerenciar essas instâncias.
Robin Bloor: Ok, outra pergunta antes de entregá-lo a Eric. A impressão que se tem ao observar o setor é que os bancos de dados ainda têm vida, mas todos os dados estão sendo derramados em todos esses lagos de dados e assim por diante. Esse é o hype, realmente, e o hype nunca reflete a realidade, então estou interessado em que tipo de realidade você está percebendo por aí? Os bancos de dados importantes de uma organização estão enfrentando o crescimento tradicional de dados, que eu pensava 10% ao ano? Ou eles estão crescendo mais do que isso? O big data está fazendo com que esses bancos de dados sejam insuficientes? Qual é a imagem que você vê?
Bullett Manale: Eu acho que muitos casos estavam vendo alguns dados sendo movidos para outros segmentos onde faz mais sentido, quando há outras tecnologias que estão disponíveis. Recentemente, algumas das maiores informações sobre dados. Mas eu diria que esses bancos de dados são difíceis de generalizar em muitos casos, porque todo mundo é um pouco diferente. De um modo geral, porém, vejo alguma divergência. Vejo, como eu disse, as pessoas estão adotando os modelos elásticos em muitos casos, porque querem aumentar os recursos e não tanto em outras áreas. Algumas pessoas estão migrando para o big data. Mas é difícil entender, você diz, a percepção, porque de um modo geral as pessoas com quem converso têm os bancos de dados tradicionais e o estão usando em um ambiente do SQL Server.
Dito isto, eu diria que, em termos de SQL, eu definitivamente ainda acho que está ganhando participação de mercado. E acho que há muitas pessoas que ainda estão se dirigindo para o SQL de outros lugares como Oracle, porque é mais acessível e parece óbvio, à medida que as versões do SQL se tornam mais avançadas - e você está vendo isso com as coisas mais recentes que estão acontecendo com o SQL, em termos de criptografia e todos os outros recursos que o tornam um ambiente ou uma plataforma de banco de dados - que obviamente é muito capaz de oferecer uma missão crítica, eu acho. Então, eu acho que estávamos vendo isso também. Onde você está vendo uma mudança, isso ainda está acontecendo. Quero dizer, isso estava acontecendo há 10 anos, ainda acho que está acontecendo em termos do SQL Server, onde os ambientes crescem e a participação no mercado está crescendo.
Robin Bloor: OK, Eric, presumo que o público tenha uma pergunta ou duas?
Eric Kavanagh: Sim, deixe-me jogar uma rápida sobre você. É uma pergunta muito boa, na verdade. Um dos participantes está perguntando: essa ferramenta me informa se uma tabela pode precisar de um índice para acelerar a consulta? Se sim, você pode mostrar um exemplo?
Bullett Manale: Sim, então eu não sei se tenho um para adicionar especificamente um índice, mas você pode ver aqui, temos recomendações de fragmentação aqui. Eu também acredito que tínhamos acabado de fazer isso e isso fazia parte do Diagnostic Manager que oferece a versão baseada na Web, onde está me dizendo que tenho um índice ausente. E podemos visualizar essas recomendações e nos informarão sobre o ganho potencial disso indexando essas informações. A outra coisa que devo mencionar é que, quando fazemos as recomendações, para muitas delas, o script será construído para isso. Esse não é um bom exemplo, mas você poderá ver, sim, as situações em que um índice - um índice duplicado ou a adição de um índice - melhoraria o desempenho e, como eu disse anteriormente, fazemos muitas através de análise hipotética de índices. Portanto, realmente ajuda em termos de compreensão da carga de trabalho, para poder aplicá-la à recomendação.
Eric Kavanagh: Isso é ótimo, e isso me dará uma boa sequência dos comentários finais aqui. Robin, eu e Rick também ouvimos há muitos anos falar de bancos de dados de autoajuste. É um banco de dados de auto-ajuste! Tudo o que posso dizer é: não acredite neles.
Bullett Manale: Não acredite no hype.
Eric Kavanagh: Pode haver algumas pequenas coisas que são feitas dinamicamente, mas mesmo assim, você pode querer dar uma olhada e garantir que não esteja fazendo algo que você não quer que faça. Então, por algum tempo, precisaríamos de ferramentas como essa para entender o que está acontecendo no nível do banco de dados e, como Robin disse, os lagos de dados são conceitos fascinantes, mas provavelmente há tantas chances de que eles assumam o controle quanto o de haver. um monstro do Lago Ness em breve. Então, eu diria apenas que o mundo real tem muita tecnologia de banco de dados, precisamos de pessoas, DBAs, para examinar essas coisas e sintetizá-las. Você pode dizer que precisa saber o que está fazendo para fazer essas coisas funcionarem. Mas você precisa das ferramentas para fornecer as informações para saber o que você está fazendo. Então, o ponto principal é que os DBAs estão indo muito bem.
E muito obrigado a Bullett Manale e nossos amigos na IDERA. E, claro, Rick Sherman e Robin Bloor. Nós arquivamos todos esses webcasts, então acesse o site insideanalysis.com ou o site parceiro www.techopedia.com para obter mais informações sobre tudo isso.
E com isso, bem, adeus, pessoal. Mais uma vez obrigado, bem falar com você na próxima vez. Cuidar. Tchau tchau.