Por Techopedia Staff, 19 de abril de 2017
Takeaway: O anfitrião Eric Kavanagh discute as previsões com o Dr. Robin Bloor, Rick Sherman e Bullett Manale da IDERA.
Você deve se registrar neste evento para ver o vídeo. Registre-se para ver o vídeo.
Eric Kavanagh: Senhoras e Senhores Deputados, 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, "Os melhores planos estabelecidos". sempre fale sobre isso neste programa. 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 nós ' vou falar sobre 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 sou só eu. 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, vamos colocá-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 com 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 sobre a linguagem declarativa - ela o separa 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 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; portanto, as pessoas que usam o SQL são verdadeiras, também os programadores de SQL que usam o SQL e são ainda menos propensos a pensar no impacto que terão, porque a maior parte do foco é 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. Eu já vi o SQL que obtém, se você preferir, extrair as ferramentas de BI de vários bancos de dados e é preciso dizer que muito disso é, bem, eu não iria ' Não escreva consultas SQL assim. 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 maioria das vezes, codificadores, programando formulários orientados a objetos hoje em dia e solicita dados em estruturas de objetos, para que não mapeie 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 seja necessário dizer que foi estendida e continua sendo 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, há memória, há disco, há sobrecarga de rede e há 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, muito 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 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 continuar. Então, eu concordo com tudo o que Robin falou no lado SQL. Mas o que quero concentrar um pouco agora é a demanda por dados, pelos quais passaremos muito rapidamente, o suprimento como nas ferramentas usadas naquele espaço ou a necessidade das ferramentas naquele espaço.
Primeiro, há alguns 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 estamos conversando, como Robin falou, sobre SQL. E, de fato, mesmo se estivermos procurando na plataforma Hadoop, o Hive e o Spark SQL - que meu filho, que é 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. Além disso, existe uma quantidade grande e crescente de dados nos armazéns de dados e em outros sistemas baseados em business intelligence. Porque tudo, independentemente de onde e como é capturado, armazenado ou negociado, 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 falando apenas sobre big data, mas 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 só crescerão 11% - agora são pessoas que têm cargos no DBA, mas falaremos disso em um segundo - em comparação aos 40- mais por cento de espaço anual de crescimento 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, geralmente programadores de aplicativos e desenvolvedores de aplicativos projetam com o objetivo final em mente - eles não estão projetando para a eficiência de a 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 são os que não são necessariamente projetados para a eficiência ou 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 obtendo mais e mais bancos de dados. Eu acho que isso tem um pouco a ver com as pessoas não entenderem direito 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 normalmente fazem análise de inteligência de negócios de data warehouse, por um longo, longo tempo. Há muito tempo, costumávamos obter DBAs dedicados para esses projetos; nunca mais temos um DBA dedicado. Somos 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, eles são não projetá-lo para obter eficiência.
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 meio período ou acidentais, pessoas que não receberam o treinamento formal.
Então, quais são algumas das outras coisas que também estão entrando no problema 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 se tornando 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 tempo parcial ou acidental, não sabe o que não sabe.
Acho que esqueci algumas frases aqui, para que muitas vezes elas 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 de BI cara, eles geralmente a usam 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 examinam 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. Ao planejar o gerenciamento de bancos de dados, eles precisam primeiro 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 eles estão usá-lo, 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 que aconteça, 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 taxa de transferência - tudo o que você precisa examinar.
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 são usados 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ê estiver 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 modelo ER ou modelo dimensional, seja ele estruturado - todas essas coisas tenham impacto no desempenho, especialmente nos diferentes contextos da análise de captura de dados e nas transformações que acontecem.
E como Robin mencionou no lado do SQL, é fundamental analisar o SQL que está sendo executado por esses aplicativos diferentes nesses bancos de dados e ajustá-lo. 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 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ê olha as ferramentas, deseja ver 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 contexto, se aumentarmos a capacidade, se conseguirmos mais usuários, se fizermos mais produtividade, o que estivermos fazendo, conseguir projetar o que, como e onde impactar 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 ótimas apresentações - a propósito - deixe-o entregar a Bullett Manale para levá-lo de lá. 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 esse slide, porque acho que é adequado, não sei para aqueles de vocês que são fãs do “A-Team” nos anos 80, John Hannibal Smith tinha um ditado que sempre dizia: diga: "Adoro quando um plano é elaborado" e acho que, quando você está falando particularmente do SQL Server, que é onde estamos focando, que é o produto sobre o qual falaremos hoje, SQL Diagnostic Manager, é definitivamente uma daquelas coisas que você precisa ter; você precisa aproveitar os dados que possui e tomar decisões a partir desses 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 falaremos 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".
Como eu sou o DBA atuante, eventualmente eu posso ser o DBA completo com a experiência e o conhecimento reais para apoiar esse título. Dito isso, 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ê terá, elas vão variar de um lugar para outro - mas, normalmente, você sempre será de alguma forma responsável pelo seu armazenamento, pelo planejamento desse armazenamento e pelo entendimento de antecipar, devo dizer, quanto espaço você precisará necessário, seja para seus backups ou 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 mudar dentro do próprio ambiente. 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ê faz 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 analisar especificamente 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 ela 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 de mudança 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. Sendo assim, é possível 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? Essa é grande, 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 eu 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 sobre as quais estamos falando, fazem sentido no sentido de que você depende de dados históricos, na maioria dos casos, para gerar essas recomendações ou, em alguns casos, formular decisões por conta própria, para poder encontrar 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 assim, é sempre "o 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 ser capaz de fazer e fazer o que acontecer com muitos desses tipos de perguntas, é muito valioso. e isso vai muito além do jogo de adivinhação.
Portanto, esses tipos de perguntas obviamente aparecerão; 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 também como a unidade ou o volume. Ser capaz não apenas de dizer: "Ei, estamos cheios 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 de espaço vou gastar? precisa de orçamento 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 onde o vento sopra, que é muitas 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 ter alguma compreensão sobre 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 nisso, que mostraremos 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 veremos, geralmente é apenas um entendimento, até o nível métrico, do que é normal. Não posso lhe dizer o que não é normal se não souber o que é normal. E assim, 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 agrupamentos de servidores, podendo fazer isso dinamicamente, de uma 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 em andamento. 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 que você pode aplicar ao que está sendo gerenciado, para poder 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 acabei de fazer uma alteração no meu ambiente, quero entender qual foi esse impacto, para poder aplicar essa 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ê tiver um ambiente amplo com um Em muitos casos, 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 você poder adicionar métricas adicionais e usá-las da mesma forma e da mesma forma que você as usaria se estivesse usando uma ferramenta pronta para uso métrica, por exemplo. Portanto, poder gerar relatórios, alertar sobre a linha de base - tudo o que estamos falando - também é uma parte essencial de poder fazer essa previsão e torná-la para que você obtenha as respostas que procura. ser capaz de tomar 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. O que faremos 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 grande diferencial aqui é que não há agentes ou serviços que estejam nas instâncias que você está gerenciando. Mas o que eu gostaria de fazer é 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 nas quais falei. E, basicamente, vamos começar com o tipo de coisas que estão mais ao longo das linhas, aqui é algo que você precisa fazer, ou aqui é algo que é um ponto no tempo no futuro e nós vamos 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 vou dar alguns exemplos disso . Então, vou usar meu banco de dados de auditoria, que é bastante intensivo em E / S - há muitos dados nele. Temos, vamos ver, vamos fazer isso aqui, e vamos pegar o banco de dados de assistência médica aqui em cima.
Mas o ponto é que não estou vendo apenas o espaço, posso dizer: "Olha, vamos pegar o valor do ano passado" - e vou ficar aqui um pouco, Eu realmente não tenho dados de um ano, tenho cerca de dois meses - mas, como estou escolhendo uma taxa de amostragem de meses aqui, poderei antecipar ou prever isso caso as próximas 36 unidades, porque nossa taxa de amostragem esteja definida para meses - ou seja, uma unidade, é um mês - e 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, a linha nos fornecerá 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 levaremos 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 faremos, ao fornecer uma data específica e poder dizer "Ei, nesta data, é aqui que anteciparemos o crescimento dos seus dados". Além disso, porém, podemos fornecer a você outras informações 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 é melhor ainda se eu não sou um DBA, é essa guia de análise. Então, antes que isso estivesse aqui na ferramenta, nós mostrávamos o produto para as pessoas e elas diziam “Isso é ótimo, eu vejo todos esses números, vejo tudo, mas não sei o que fazer” (risos) “Como resultado disso.” E 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 equilibrar ajudar com a saúde do meu ambiente, poder ter uma maneira ordenada de fornecer essas recomendações, além de dicas úteis de 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 leve-me à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 estamos fazendo aqui com esta análise - e mostrarei a você quando eu configurar as propriedades dessa instância, e eu vou para a seção de configuração da análise -, temos muitas categorias diferentes que são listados aqui, e parte disso, temos otimização de índice e otimização de consulta. Portanto, estamos avaliando não apenas as próprias métricas e coisas assim, mas também as cargas de trabalho e os índices. No caso aqui, faremos algumas análises hipotéticas 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, existe um ponto de inflexão, onde eu 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 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 permita escolher seletivamente qualquer métrica que desejarmos - e deixe-me encontrar uma decente aqui - vou usar o CPU SQL, mas o ponto é que você você pode voltar ao longo de várias semanas para pintar essas figuras para que você possa ver quando estão os seus discrepantes, para ver em 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, são as linhas de base que geramos usando os dados históricos para fornecer essa análise, mas, mais importante, posso alterar esses limites estaticamente, mas também posso automatizá-los dinamicamente. Portanto, à medida que a janela de manutenção, ou devo dizer, a janela da linha de base de manutenção, esses limites mudarão 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 estiverem não tanto, quando as cargas de trabalho não são tão impactantes.
Então, isso é algo a ter em mente, em termos de linha de base. Obviamente, isso será realmente útil para você, em termos de entender também 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 mentira aqui - mas se eu tivesse todas as minhas instâncias de produção e precisava entender onde está na á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 principais. 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, seja o uso do disco, o uso da memória ou o aguardar, seja no tempo de resposta, sou capaz de correlacionar - ou melhor, classificar - essas instâncias uma contra a outra. Obviamente, a instância que está no topo de cada lista, se é a mesma instância, é 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, em relação 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 quer que eu possa dizer e dizer: "Vamos ver a linha de base para isso nos últimos 30 dias", nesse caso, ele 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 depende da 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 responde apenas a todas as perguntas "e se" que você poderia responder. Mas a realidade é que você terá muitos atributos e muitas opções para poder 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, todas as coisas que já mostramos na ferramenta, como mencionei antes, tenham flexibilidade para incorporar novas métricas, que sejam gerenciadas e até capazes de 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 previstas para o monitoramento, 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 lhe mostrando aqui.
Agora, além disso - e uma das coisas com as quais obviamente nos deparamos ultimamente - primeiro, foi todo mundo 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 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 relacionadas ao seu 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, eu jogarei fora para Rick, se ele ainda estiver lá fora. 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 estiverem na nuvem, não precisam ajustá-los. Então-
Bullett Manale: Certo, ainda temos que pagar por isso, certo? Você ainda precisa pagar por tudo o que as pessoas estão colocando na nuvem; portanto, se estiver executando mal ou causando muitos ciclos de CPU, será necessário pagar mais dinheiro; ainda precisa medir essas coisas, absolutamente.
Rick Sherman: Sim, eu já vi muitos projetos 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, existem várias maneiras de analisar a consulta desempenho. Quer se trate de 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 próprias instâncias 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 próprias consultas, 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 para o monitor de consulta de configuração e dissesse: "Vamos mudar esse valor para zero", a realidade é que basicamente faz com que a ferramenta colete todas as consultas que são executadas e essa não é realmente a espírito do porquê está lá, 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 às suas configurações, geralmente falando, prontas para uso. Está entre 1 e 3% de sobrecarga, mas há 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 poderemos extrair de eventos estendidos, enquanto que extrairíamos um rastreamento para fazer isso. Portanto, seria um pouco diferente em termos de como coletar esses dados, mas isso disse, como eu disse, que estamos por aí, acho que desde 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 é fantástico.
Eric Kavanagh: Bom. 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 olhar para vários bancos de dados e, portanto, saber que uma base de recursos maior 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, na maioria dos casos, da perspectiva de um DBA, muitas vezes esses problemas acontecem quando estão na frente do console, podendo ser notificado assim que o problema está acontecendo. Mas, além disso, ser capaz de entender quando o problema ocorre, ser capaz de chegar ao coração das informações que estão fornecendo algum contexto em termos de por que está acontecendo. Penso que essa é a maior parte: ser proativo, não ser reativo.
A maioria dos DBAs com quem 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 da razão pela 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 é que sempre é problema deles, mesmo que seja o desenvolvedor do aplicativo que escreveu o aplicativo que não foram escritos corretamente, eles são os responsáveis pela culpa, porque eles estão levando esse aplicativo para seus sistemas ou servidores e, quando o desempenho é ruim, todo mundo aponta para o DBA, "Ei, a culpa é sua."
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 coletam 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 realmente: é 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 este produto em particular, a forma como é licenciado é por instância. Acho que você diria que existe um limite 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 fazemos acho que existem mais, atendendo àquelas 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 é o Express? É a versão gratuita ou é uma versão corporativa? ”Essa é provavelmente uma pergunta que 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 integridade, no sentido de que são os tipos elementares de coisas com as quais me importo como DBA: a unidade está se enchendo ? O servidor está respondendo a problemas? As principais coisas, certo?
Considerando que, com o Diagnostic Manager, a ferramenta que eu acabei de mostrar, 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 que olham 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, em geral, há 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 passar para 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, na verdade, 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 estamos vendo alguns dados serem movidos para outros segmentos nos quais faz mais sentido, quando há outras tecnologias 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 geralmente as pessoas com quem estou conversando têm os bancos de dados tradicionais e estão usando isso 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 muitas pessoas ainda estão indo 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, acho que também estamos vendo isso. Onde você está vendo uma mudança, isso ainda está acontecendo. Quero dizer, isso estava acontecendo há 10 anos, acho que ainda está acontecendo em termos do SQL Server, onde o ambiente está crescendo 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 dar uma rápida para 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 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 isso nos dirá o potencial de ganho disso ao indexar 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ê seria capaz de 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 sobre bancos de dados de autoajuste. É um banco de dados de autoajuste! 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 dar uma olhada e se certificar de que não está fazendo algo que você não quer que faça. Então, por algum tempo, precisaremos de ferramentas como esta para entender o que está acontecendo no nível do banco de dados e, como Robin disse, lagos de dados são conceitos fascinantes, mas provavelmente há tantas chances de eles assumirem o controle quanto os 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, precisa saber o que está fazendo para fazer essas coisas funcionarem. Mas você precisa das ferramentas para fornecer informações para saber o que 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, vamos dizer adeus, pessoal. Obrigado novamente, falaremos com você na próxima vez. Cuidar. Tchau tchau.
