Par Techopedia Staff, 19 avril 2017
À retenir: l' animateur Eric Kavanagh discute des prévisions avec le Dr Robin Bloor, Rick Sherman et Bullett Manale de l'IDERA.
Vous devez vous inscrire à cet événement pour voir la vidéo. Inscrivez-vous pour voir la vidéo.
Eric Kavanagh: Mesdames et messieurs, encore une fois bonjour et bienvenue dans la série de webémissions Hot Technologies! Je m'appelle Eric Kavanagh, je serai votre hôte pour le séminaire Web d'aujourd'hui, intitulé «Économiser du temps, de l'argent et des ennuis avec des prévisions optimales». Bien sûr, j'ai raté la première partie du titre, «Les meilleurs plans mis en place». Nous parlez toujours de cela dans cette émission. Alors, Hot Technologies est bien sûr notre forum pour comprendre quels sont les produits sympas dans le monde aujourd'hui, le monde de la technologie d'entreprise, ce que les gens font avec eux, comment ils fonctionnent, tout ce genre de choses amusantes.
Et le sujet d'aujourd'hui, comme je le suggère, concerne les prévisions. Vraiment, vous essayez de comprendre ce qui va se passer dans votre organisation. Comment allez-vous satisfaire vos utilisateurs, quoi qu'ils fassent? S'ils font de l'analyse, s'ils font du vrai travail, ils font face à de vrais clients avec des systèmes transactionnels, quel que soit le cas, vous voulez comprendre comment vos systèmes fonctionnent et ce qui se passe, et c'est ce que nous ' Je vais en parler aujourd'hui. C'est assez drôle parce que les prévisions ne sont pas quelque chose que j'aime faire, parce que je suis superstitieux, comme je pense que si je fais trop de prévisions, de mauvaises choses se produiront, mais ce n'est que moi. Ne suivez pas mon exemple.
Alors, voici nos présentateurs aujourd'hui, le vôtre vraiment dans le coin supérieur gauche, Rick Sherman appelle de Boston, notre copain Bullett Manale de l'IDERA et notre propre Dr Robin Bloor. Et avec cela, je vais céder la parole à Robin et rappeler aux gens: Posez des questions, ne soyez pas timides, nous aimons les bonnes questions, nous les poserons à nos présentateurs et à d'autres aujourd'hui. Et avec ça, Robin, emportez-le.
Robin Bloor: OK, eh bien, comme je suis en pole position comme on dit, je pensais que je raconterais une histoire SQL aujourd'hui, parce que c'est le contexte de la discussion qui va se passer et ça ne sera pas forcément en conflit avec parce que Rick ne se concentre pas sur cela et ne se heurtera pas à ce que Rick a à dire. Donc, l'histoire de SQL, il y a des choses intéressantes à propos de SQL parce qu'il est tellement dominant. Vous voyez, c'est une faute de frappe, SQL est un langage déclaratif. L'idée était que vous pouviez créer une langue dans laquelle vous demanderiez ce que vous vouliez. Et la base de données déterminerait comment l'obtenir. Et cela a plutôt bien fonctionné, en fait, mais il y a un certain nombre de choses qui valent la peine d'être dites à ce sujet, les conséquences de fonder l'ensemble de l'industrie informatique sur un langage déclaratif. L'utilisateur ne connaît pas ou ne se soucie pas de l'organisation physique des données, et c'est la bonne chose à propos du langage déclaratif - il vous sépare de tout cela, et même vous inquiétez - demandez simplement ce que vous voulez et la base de données ira le chercher.
Mais l'utilisateur n'a aucune idée si la façon dont ils structurent la requête SQL va affecter les performances de la requête et c'est un peu un inconvénient. J'ai vu des requêtes qui sont des centaines et des centaines de lignes, qui ne sont qu'une seule requête SQL, vous savez, commence par «sélectionner» et continue simplement avec des sous-requêtes et ainsi de suite et ainsi de suite. Et il s'avère que si vous voulez une collection particulière de données à partir d'une base de données, vous pouvez la demander de différentes manières avec SQL et obtenir la même réponse si vous avez une certaine familiarité avec les données. Ainsi, une requête SQL n'est pas nécessairement la meilleure façon de demander des données, et les bases de données répondront tout à fait différemment selon le SQL que vous y insérerez.
Et donc, SQL affecte réellement les performances, donc les gens qui utilisent SQL, c'est vrai pour eux, c'est aussi vrai pour les programmeurs SQL qui utilisent SQL et ils sont encore moins susceptibles de penser à l'impact qu'ils vont avoir, parce que la majeure partie de leur attention est en fait sur la manipulation des données et non sur l'obtention, la mise en place des données. Et il en va de même pour les outils de BI, j'ai vu le SQL qui obtient, si vous le souhaitez, des outils de BI de diverses bases de données et il faut dire que beaucoup de cela est, eh bien, je ne le ferais pas t écrire des requêtes SQL comme ça. C'est quelqu'un qui a créé, si vous voulez, un petit moteur qui, quels que soient les paramètres, va jeter du SQL, et encore une fois, ce SQL ne sera pas nécessairement un SQL efficace.
Ensuite, j'ai pensé mentionner le décalage d'impédance, les données utilisées par les programmeurs étant différentes des données lors de leur tri. Ainsi, notre DMS stocke les données dans des tableaux, organisé le code orienté objet sont principalement des codeurs, programment de nos jours la forme orientée objet et ils ordonnent les données dans les structures objet, donc il ne correspond pas l'un à l'autre. Il est donc nécessaire de traduire de ce que le programmeur pense que les données sont à ce que la base de données pense de ce que sont les données. Ce qui semble avoir dû faire quelque chose de mal pour que ce soit le cas. SQL a DDL pour la définition des données, il a DML - langage de manipulation de données - sélectionner, projeter et joindre, pour obtenir ces données. Maintenant, il y a très peu de mathématiques et très peu de choses basées sur le temps, donc c'est le langage imparfait, même s'il faut dire qu'il a été étendu et continue d'être étendu.
Et puis, vous obtenez le problème de la barrière SQL, qui est toujours plus droit que le diagramme, en ce sens que beaucoup de gens posaient des questions pour des raisons analytiques, une fois qu'ils ont obtenu la réponse aux termes de données de la question, veulent poser une autre question. Donc, cela devient une chose de dialogue, eh bien, SQL n'a pas été conçu pour les boîtes de dialogue, il a été conçu pour demander ce que vous voulez à la fois. Et cela vaut la peine de le savoir, car il existe des produits qui abandonnent réellement SQL afin de rendre possible la conversation entre l'utilisateur et les données.
En termes de performances de base de données - et ce genre de propagation à tout - oui, il y a du CPU, de la mémoire, du disque, des surcharges réseau et il y a le problème de verrouillage de plus d'une personne souhaitant avoir une utilisation exclusive des données à un moment donné point dans le temps. Mais il y a aussi de mauvais appels SQL, il y a énormément à faire si vous optimisez réellement le SQL, en termes de performances. Ainsi, les facteurs de performance de la base de données: mauvaise conception, mauvaise conception de programme, simultanéité de la charge de travail manquante, équilibrage de charge, structure de requête, planification de la capacité. C'est la croissance des données. Et en quelques mots, SQL est pratique, mais il ne s'auto-optimise pas.
Cela dit, je pense que nous pouvons passer à Rick.
Eric Kavanagh: Très bien, Rick, permettez-moi de vous donner les clés de la voiture WebEx. Emportez-le.
Rick Sherman: Très bien, super. Eh bien merci Robin, comme nous avons commencé au début de la présentation, mes graphismes sont encore assez ennuyeux, mais nous allons y aller. Donc, je suis d'accord avec tout ce dont Robin a parlé du côté SQL. Mais ce que je veux me concentrer un peu maintenant, c'est la demande de données, que nous allons parcourir très rapidement, l'offre comme dans les outils utilisés dans cet espace ou le besoin d'outils dans cet espace.
Tout d'abord, il y en a dans chaque article que vous lisez sur les mégadonnées, beaucoup de données, les données non structurées provenant du cloud, les mégadonnées partout que vous pouvez imaginer. Mais la croissance du marché des bases de données a toujours été avec SQL, la base de données relationnelle probablement à partir de 2015, représente toujours 95% du marché des bases de données. Les trois principaux fournisseurs relationnels détiennent environ 88% des parts de marché dans cet espace. Donc, nous parlons toujours, comme Robin l'a dit, de SQL. Et en fait, même si nous recherchons sur la plate-forme Hadoop, Hive et Spark SQL - que mon fils, qui est un scientifique des données, utilise tout le temps maintenant - est certainement le moyen dominant pour les gens d'accéder aux données.
Maintenant, du côté de la base de données, il existe deux grandes catégories d'utilisation des bases de données. L'une concerne les systèmes de gestion de bases de données opérationnelles, donc la planification des relations d'entreprise, la gestion des relations avec les clients, les ERP Salesforce, Oracles, EPIC, N4, etc., du monde. Et le, il y a une grande quantité et une quantité croissante de données qui se trouvent dans les entrepôts de données et autres systèmes basés sur l'intelligence d'affaires. Parce que tout, peu importe où et comment il est capturé, stocké ou traité, est finalement analysé et il y a donc une énorme demande et une augmentation de l'utilisation des bases de données, en particulier des bases de données relationnelles sur le marché.
Maintenant, nous avons la demande, nous avons d'énormes quantités de données à venir. Et je ne parle pas vraiment seulement des mégadonnées, je parle de l'utilisation des données dans toutes sortes d'entreprises. Mais en accompagnant cela du côté de l'offre, pour les personnes qui peuvent gérer ces ressources, nous avons d'abord, nous avons une sorte de pénurie de DBA. Selon le Bureau of Labor Statistics, de 2014 à 2024, les emplois DBA n'augmenteront que de 11% - maintenant ce sont les personnes qui ont des titres d'emploi DBA, mais nous en parlerons dans une seconde - contre les 40- plus le pourcentage de croissance annuelle des données. Et nous avons beaucoup de DBA; en moyenne, cette même étude a parlé de l'âge moyen est assez élevé par rapport à d'autres professions informatiques. Et puis nous avons beaucoup de gens qui quittent le terrain, pas nécessairement à la retraite, mais qui passent à d'autres aspects, à la gestion, etc.
Maintenant, une partie de la raison pour laquelle ils partent, c'est parce que le travail DBA devient de plus en plus difficile. Tout d'abord, nous avons des administrateurs de bases de données gérant eux-mêmes de nombreuses bases de données différentes, des bases de données physiques, situées partout, ainsi que différents types de bases de données. Maintenant, cela peut être relationnel ou il peut s'agir d'une autre base de données, de types de base de données également. Mais même si c'est relationnel, ils peuvent avoir n'importe lequel, un, deux, trois ou quatre fournisseurs différents qu'ils essaient de gérer. Les administrateurs de base de données s'impliquent généralement après la conception de la base de données ou de l'application. Robin a expliqué comment les bases de données ou les applications sont conçues, comment SQL est conçu. Eh bien, lorsque nous parlons de modélisation de données, de modélisation ER, de modélisation ER étendue, de modélisation dimensionnelle, de modélisation dimensionnelle avancée, peu importe, généralement les programmeurs d'applications et les développeurs d'applications conçoivent avec leur objectif final à l'esprit - ils ne conçoivent pas pour l'efficacité de la structure de la base de données elle-même. Nous avons donc beaucoup de mauvaise conception.
Maintenant, je ne parle pas des fournisseurs d'applications d'entreprise commerciale; ils ont généralement des modèles ER ou des modèles ER étendus. Ce dont je parle, c'est qu'il y a beaucoup plus de processus métier et d'applications créés par les développeurs d'applications dans chaque entreprise - ce ne sont pas nécessairement ceux qui sont conçus pour l'efficience ou l'efficacité du déploiement. Et les administrateurs de base de données eux-mêmes sont surchargés de travail et ils ont parfois une responsabilité 24/7, ils continuent à obtenir de plus en plus de bases de données. Je pense que cela a un peu à voir avec le fait que les gens ne comprennent pas très bien ce qu'ils font ou comment ils le font. Leur propre petit groupe et les gens continuent de penser: «Eh bien, tous ces outils sont tellement faciles à utiliser que nous pouvons continuer à utiliser de plus en plus de bases de données sur leur charge de travail», ce qui n'est pas le cas.
Ce qui nous amène aux DBA à temps partiel et accidentels. Nos équipes informatiques sont petites et ne peuvent pas nécessairement se permettre un DBA dédié. C'est maintenant le cas des petites et moyennes entreprises, où l'expansion des bases de données et des applications de bases de données a explosé au cours de la dernière décennie et continue de se développer. Mais c'est aussi le cas des grandes entreprises, qui font généralement de l'entreposage de données et de l'analyse décisionnelle depuis très, très longtemps. Il y a longtemps, nous avions l'habitude d'obtenir des DBA dédiés à ces projets; nous n'obtenons plus de DBA dédié. Nous sommes responsables de la conception de la base de données, ce qui est bien, si c'est quelqu'un qui a de l'expérience. Mais en général, les administrateurs de bases de données sont des développeurs d'applications, ils jouent souvent ce rôle en tant que partie à temps partiel de leur travail, ils n'ont pas de formation formelle et, encore une fois, ils le conçoivent pour leurs objectifs finaux, ils sont ne pas le concevoir pour des gains d'efficacité.
Et il y a beaucoup de différence entre la conception et le développement, par rapport au déploiement et à la gestion. Donc, nous avons le «penny sage, livre idiot», avec une petite tirelire là-bas, en évitant d'obtenir les compétences et les ressources nécessaires dans les projets. Pensant que tout le monde est de «Revenge of the Nerds», ma petite photo là-bas. Maintenant, en ce qui concerne ce dont les gens ont besoin, nous avons donc une utilisation croissante des bases de données et des données en SQL. Nous avons un nombre restreint de DBA - des personnes qui sont compétentes et expertes dans ces situations de réglage, de conception, de gestion et de déploiement. Et nous avons de plus en plus d'administrateurs de bases de données à temps partiel ou accidentels, des gens qui n'ont pas suivi la formation officielle.
Alors, quelles sont certaines des autres choses qui entrent également dans le problème du fait que ces bases de données ne sont pas également optimisées ou gérées également? Tout d'abord, de nombreuses personnes supposent que le système de base de données lui-même dispose d'outils suffisants pour se gérer lui-même. Maintenant, les outils deviennent de plus en plus faciles à faire - conception et développement - mais c'est différent que de faire une bonne conception, une bonne gestion, une planification des capacités, une surveillance, etc. pour le déploiement. Donc, tout d'abord, les gens supposent qu'ils ont tous les outils dont ils ont besoin. Deuxièmement, si vous êtes un DBA à temps partiel ou accidentel, vous ne savez pas ce que vous ne savez pas.
Je suppose que j'ai oublié une partie de la phrase, de sorte que la plupart du temps, ils ne comprennent tout simplement pas ce qu'ils doivent même regarder dans la conception ou lorsqu'ils gèrent ou exploitent les bases de données. Si ce n'est pas votre profession, vous ne comprendrez pas ce que vous devez faire. Troisièmement, SQL est un outil incontournable, alors Robin a parlé de SQL et de la façon dont SQL est parfois construit, ou souvent est construit. Et l'un de mes coups de cœur dans l'entreposage de données BI, la migration des données, l'espace d'ingénierie des données est qu'au lieu d'utiliser des outils, les gens ont tendance à écrire du code SQL, des procédures stockées, même s'ils utilisent un outil d'intégration de données coûteux ou un outil de BI coûteux, ils l'utilisent souvent vraiment juste pour exécuter des procédures stockées. Alors que l'importance de comprendre la conception de bases de données, la construction de SQL, devient de plus en plus importante.
Et enfin, il y a cette approche en silo, dans laquelle des personnes individuelles examinent des bases de données individuelles. Ils ne regardent pas comment les applications fonctionnent et interagissent entre elles. Et ils regardent aussi souvent les bases de données par rapport aux applications pour lesquelles ils les utilisent. Ainsi, la charge de travail que vous obtenez sur la base de données est critique dans la conception, critique dans le réglage, critique dans la tentative de comprendre comment planifier la capacité, etc. Donc, en regardant la forêt depuis les arbres, les gens sont dans les mauvaises herbes, en examinant les tables et les bases de données individuelles et en ne regardant pas l'interaction globale de ces applications dans la charge de travail.
Enfin, les gens doivent examiner les domaines clés sur lesquels ils doivent se pencher. Lorsqu'ils envisagent de gérer des bases de données, ils doivent d'abord y penser, développer des mesures de performance centrées sur l'application, ils doivent donc examiner non seulement la façon dont ce tableau est structuré, comment il est particulièrement modélisé, mais comment est-il utilisé? Donc, si vous avez une application d'entreprise qui est due à la gestion de la chaîne d'approvisionnement, si vous retirez des commandes du Web, si vous faites de la BI - quoi que vous fassiez - vous devez regarder qui l'utilise, comment ils en l'utilisant, quels sont les volumes de données, quand cela va se produire. Ce que vous essayez vraiment de rechercher, ce sont les temps d'attente, car quoi qu'il en soit, toutes les applications sont jugées en fonction du temps qu'il faut pour faire quelque chose, que ce soit une personne ou simplement l'échange de données entre des applications ou des processeurs. Et quels sont les goulots d'étranglement? Bien souvent, lorsque vous essayez de déboguer des problèmes, bien sûr, vous essayez vraiment de voir quels sont les véritables goulots d'étranglement - pas nécessairement comment tout régler, mais comment vous débarrasser et augmenter les performances dans les temps d'attente et le débit - tout ce que vous devez regarder.
Et vous devez vraiment séparer la capture des données, les transactions, les aspects de transformations dans la base de données ainsi que les analyses. Chacun d'eux a des modèles de conception différents, chacun d'eux a des modèles d'utilisation différents et chacun d'eux doit être réglé différemment. Donc, vous devez penser à la façon dont ces données sont utilisées, quand elles sont utilisées, à quoi elles sont utilisées et déterminer quelles sont les mesures de performances et quelles sont les principales choses que vous souhaitez analyser liées à cette utilisation. Maintenant, lorsque vous envisagez de surveiller les performances, vous voulez regarder les opérations de la base de données elle-même; vous voulez regarder à la fois les structures de données, donc les index, le partitionnement et d'autres aspects physiques de la base de données, même la structure de la base de données - que ce soit le modèle ER ou le modèle dimensionnel, quelle que soit sa structure - toutes ces choses ont un impact sur les performances, en particulier dans les différents contextes d'analyse de capture de données et les transformations qui se produisent.
Et comme Robin l'a mentionné du côté SQL, il est essentiel de regarder le SQL qui est exécuté par ces différentes applications sur ces bases de données et de le régler. Et en examinant les charges de travail globales des applications et l'environnement d'infrastructure sur lequel ces bases de données et applications s'exécutent. Donc, que les réseaux, les serveurs, le cloud - quoi qu'ils fonctionnent - examinant également l'impact que ces applications et ces bases de données ont dans ce contexte, tout cela a l'interaction de pouvoir régler la base de données.
Et enfin, lorsque vous regardez des outils, vous voulez pouvoir regarder les trois différents types d'analyses liées à cela. Vous voulez regarder l'analyse descriptive: ce qui se passe et où, liée à la base de données et aux performances de l'application. Vous voulez avoir la possibilité de faire des analyses de diagnostic pour comprendre non seulement ce qui se passe, mais pourquoi cela se produit, où sont les goulots d'étranglement, où sont les problèmes, qu'est-ce qui fonctionne bien, qu'est-ce qui ne fonctionne pas bien? Mais être capable d'analyser et d'analyser les zones problématiques afin de les résoudre, que ce soit pour la conception ou tout ce que vous devez faire.
Et enfin, le type d'analyse le plus agressif ou proactif est de faire une analyse prédictive, une modélisation analytique prédictive, peu importe. Nous savons que la base de données et les applications fonctionnent dans ce contexte, si nous augmentons la capacité, si nous obtenons plus d'utilisateurs, si nous faisons plus de débit, quoi que nous fassions, pouvoir projeter quoi, comment et où ça va impact sur la base de données, les applications, nous permet de planifier et de déterminer de manière proactive, où sont les goulots d'étranglement, où les temps d'attente pourraient souffrir et ce que nous devons faire pour réparer les choses. Nous voulons donc disposer d'outils capables de mettre en œuvre les mesures de performances, de surveiller les performances, comme dans ces trois types d'analyse. Et c'est mon aperçu.
Eric Kavanagh: D'accord, permettez-moi de vous le remettre - ce sont deux excellentes présentations, soit dit en passant - laissez-moi le remettre à Bullett Manale pour le reprendre à partir de là. Et les gens, n'oubliez pas de poser de bonnes questions; nous avons déjà du bon contenu. Enlevez-le, Bullett.
Bullett Manale: Ça sonne bien. Merci Eric. Donc, beaucoup de ce que Rick et Robin ont dit, évidemment je suis d'accord à 100%. Je dirais que j'ai remonté cette diapositive, parce que je pense que cela convient, je ne sais pas pour ceux d'entre vous qui sont des fans de "A-Team" dans les années 80, John Hannibal Smith avait un dicton qu'il avait toujours dire: «J'adore quand un plan se met en place», et je pense que lorsque vous parlez en particulier de SQL Server, sur lequel nous nous concentrons, qui est le produit dont nous allons parler aujourd'hui, SQL Diagnostic Manager, c'est certainement l'une de ces choses que vous devez avoir; vous devez être en mesure d'exploiter les données dont vous disposez et être en mesure de prendre des décisions à partir de ces données, et dans certains cas, vous ne cherchez pas une décision; vous cherchez quelque chose pour vous dire quand quelque chose va manquer de ressources, quand vous allez manquer de ressources, quand vous allez avoir un goulot d'étranglement, ce genre de choses.
Il ne s'agit pas seulement de surveiller une métrique spécifique. Donc, avec Diagnostic Manager, l'une des choses qu'il fait très bien va vous aider en termes de prévisions et de compréhension spécifiques aux charges de travail et nous allons en parler beaucoup aujourd'hui. L'outil est destiné au gestionnaire de données, au DBA ou au DBA intérimaire, donc beaucoup de choses dont Rick parlait, le DBA intérimaire est tellement vrai. Dans de nombreux cas, si vous n'êtes pas un DBA, il y aura beaucoup de points d'interrogation que vous aurez quand viendra le temps de gérer un environnement SQL, des choses que vous ne savez pas. Et donc vous cherchez quelque chose pour vous aider, vous guider tout au long de ce processus et vous informer également sur le processus. Et donc, il est important que l'outil que vous utilisez pour ce genre de décisions vous donne un aperçu des raisons pour lesquelles ces décisions sont prises, il ne vous dit pas seulement: «Hé, fais ça».
Parce que je suis le DBA par intérim, je pourrais éventuellement être le DBA à part entière avec l'expertise et les connaissances nécessaires pour appuyer ce titre. Donc, cela dit, lorsque nous parlons d'être un administrateur de base de données - je montre toujours en quelque sorte cette diapositive en premier, parce que le DBA a des rôles différents et selon l'organisation avec laquelle vous êtes, vous allez avoir, ceux-ci vont varier d'un endroit à l'autre - mais généralement, vous serez toujours en quelque sorte responsable de votre stockage, de votre planification de ce stockage et de votre compréhension de l'anticipation, je devrais dire, de la quantité d'espace que vous allez avoir besoin, que ce soit pour vos sauvegardes, ou que ce soit pour les bases de données elles-mêmes. Vous devrez comprendre et évaluer cela.
De plus, vous devrez être en mesure de comprendre et d'optimiser les choses selon les besoins, et au fur et à mesure que vous effectuez la surveillance de l'environnement, il est évidemment important que vous apportiez les modifications nécessaires en fonction de choses qui changer dans l'environnement lui-même. Ainsi, des choses comme le nombre d'utilisateurs, des choses comme la popularité des applications, la saisonnalité d'une base de données, tout doit être pris en compte lorsque vous faites vos prévisions. Et puis, de toute évidence, examiner d'autres choses pour pouvoir fournir les rapports et les informations nécessaires pour prendre ces décisions. Dans de nombreux cas, cela signifie faire une analyse comparative; cela signifie être en mesure d'examiner spécifiquement une métrique particulière et de comprendre quelle a été la valeur de cette métrique au fil du temps, afin que vous puissiez anticiper où elle va aller de l'avant.
Donc, ce que fait beaucoup l'outil Diagnostic Manager a ces capacités et les gens l'utilisent tous les jours pour pouvoir faire des choses comme les prévisions, et j'ai mis ici la définition de la planification des capacités. Et c'est une définition assez large et en fait assez vague, qui est juste le processus de détermination de la capacité de production nécessaire à une organisation pour répondre aux demandes changeantes de ses produits, et au bout du compte, c'est vraiment de cela qu'il s'agit: c'est sur la possibilité de prendre des informations que vous avez d'une manière ou d'une autre et de prendre ces informations et de prendre des décisions pour vous aider à progresser au cours du cycle de vie de vos bases de données. Et donc, les types de choses qui sont les raisons pour lesquelles les gens doivent le faire sont évidemment avant tout, dans la plupart des cas, pour économiser de l'argent. Les entreprises, évidemment, c'est leur objectif principal: gagner de l'argent et économiser de l'argent. Mais dans le processus, cela signifie également être en mesure de s'assurer que votre temps d'arrêt, il n'y a pas de temps d'arrêt. Et être en mesure de vous assurer que vous atténuez les risques de panne, afin de l'empêcher de se produire pour commencer, en d'autres termes, de ne pas attendre que cela se produise et de réagir ensuite.
En plus d'être en mesure d'augmenter globalement la productivité de vos utilisateurs, les rendre plus efficaces afin que vous puissiez faire plus de travail est évidemment la clé ici, ce sont donc les types de choses qui, en tant que DBA ou quelqu'un impliqué dans les prévisions ou la capacité la planification devra être capable de parcourir les informations pour pouvoir prendre ces décisions. Et puis, dans l'ensemble, cela va évidemment vous aider à éliminer le gaspillage, non seulement en termes d'argent, mais aussi en termes de temps et en termes de ressources générales qui pourraient être utilisées pour d'autres choses, éventuellement. Ainsi, être en mesure d'éliminer ces déchets afin de ne pas avoir de coûts d'opportunité liés aux déchets eux-mêmes.
Donc, cela dit, quels sont les types de questions que nous recevons, spécifiques à la personne qui est un DBA? Quand vais-je manquer d'espace? C'est un gros problème, non seulement combien d'espace je consomme maintenant, mais quand vais-je manquer, en fonction des tendances et de l'histoire passée? Même chose avec les instances réelles de SQL, les bases de données, quels serveurs puis-je consolider? Je vais en mettre sur les machines virtuelles, qu'est-ce qui a du sens en termes de bases de données que je vais consolider et sur quelles instances de SQL devraient-elles résider? Il faut pouvoir répondre à tous ces types de questions. Parce que dans la plupart des cas, si vous êtes DBA ou DBA intérimaire, vous allez le consolider à un moment donné de votre carrière. Dans de nombreux cas, vous allez le faire de façon continue. Donc, vous devez être en mesure de prendre ces décisions rapidement, sans jouer à des jeux de devinettes en ce qui concerne cela.
Nous avons parlé des goulots d'étranglement et de l'endroit où ils se produiront ensuite, en étant en mesure d'anticiper, encore une fois, au lieu d'attendre qu'ils se produisent. Donc, évidemment, toutes ces choses dont nous parlons ont du sens dans le sens où vous vous appuyez sur des données historiques, dans la plupart des cas, pour pouvoir générer ces recommandations, ou dans certains cas, être en mesure de formuler des décisions vous-même, pour être en mesure de trouver ces réponses. Mais cela me rappelle le, quand vous entendez les annonces radio pour quelqu'un qui vend des titres ou quelque chose comme ça, c'est toujours "les performances passées ne sont pas indicatives des résultats futurs" et ce genre de choses. Et la même chose vaut ici. Vous allez avoir des situations où ces prévisions et ces analyses peuvent ne pas être exactes à 100%. Mais si vous traitez des choses qui se sont passées dans le passé et ce qui est connu, et être capable de prendre et de faire le «et si» avec beaucoup de ces types de questions, vous allez vous heurter à, est très précieux et cela vous amènera beaucoup plus loin que de jouer au jeu de devinettes.
Donc, ces types de questions vont évidemment se poser, alors comment nous traitons beaucoup de ces questions avec Diagnostic Manager, tout d'abord nous avons des capacités de prévision, étant en mesure de le faire dans la base de données, sur la table également comme le lecteur ou le volume. Pour pouvoir non seulement dire: «Hé, nous sommes pleins d'espace», mais dans six mois, dans deux ans, dans cinq ans, si je fais un budget pour cela, combien d'espace disque vais-je avoir besoin de budget? Ce sont des questions que je vais devoir poser, et je vais devoir pouvoir utiliser une méthode pour le faire plutôt que de deviner et de mettre mon doigt en l'air et d'attendre de voir de quelle façon le vent souffle, ce qui est malheureusement souvent la façon dont beaucoup de ces décisions sont prises.
De plus, pouvoir - on dirait que ma diapositive a été interrompue un peu - mais être en mesure de fournir une aide sous forme de recommandations. Donc, c'est une chose de pouvoir vous montrer un tableau de bord plein de métriques et de pouvoir dire: «OK, voici toutes les métriques et où elles en sont», mais ensuite de pouvoir en faire ou avoir une certaine compréhension de quoi faire, basé sur cela est un autre saut. Et dans certains cas, les gens sont suffisamment éduqués dans le rôle de DBA pour pouvoir prendre ces décisions. Et nous avons donc quelques mécanismes dans l'outil qui vous aideront à cela, que nous vous montrerons dans une seconde. Mais être en mesure de montrer non seulement quelle est la recommandation, mais aussi de fournir un aperçu de la raison pour laquelle cette recommandation est faite, puis en plus de cela, dans certains cas, être en mesure de proposer un script qui automatise la la correction de ce problème est également idéale.
Passant à la suivante ici, que nous verrons, il s'agit simplement de comprendre d'une manière générale jusqu'au niveau métrique ce qui est normal. Je ne peux pas vous dire ce qui n'est pas normal si je ne sais pas ce qui est normal. Et donc, avoir un moyen de mesurer cela est essentiel et vous devez être en mesure de prendre en considération plusieurs types de domaines, par exemple - ou je devrais dire des délais - différents groupes de serveurs, être en mesure de le faire de manière dynamique, du point de vue des alertes, en d'autres termes, au milieu de la nuit, pendant ma fenêtre de maintenance, je m'attends à ce que mon processeur fonctionne à 80% sur la base de toute la maintenance en cours. Donc, je pourrais vouloir augmenter mes seuils plus haut, pendant ces délais par rapport à peut-être au milieu de la journée, quand je n'ai pas autant d'activité.
Ce sont des choses qui seront évidemment environnementales, mais des choses que vous pouvez appliquer à ce qui est géré, pour être en mesure de vous aider à gérer cet environnement plus efficacement et de le rendre plus facile à faire. L'autre domaine, évidemment, est de pouvoir fournir globalement les rapports et les informations nécessaires pour pouvoir répondre à ces types de questions «et si». Si je viens d'apporter une modification à mon environnement, je veux comprendre quel a été cet impact, afin de pouvoir appliquer cette même modification à d'autres instances ou à d'autres bases de données de mon environnement. Je veux pouvoir avoir des informations ou des munitions pour pouvoir faire ce changement avec une certaine tranquillité d'esprit et sachant que ce sera un bon changement. Donc, pouvoir faire ce rapport comparatif, pouvoir classer mes instances de SQL, pouvoir classer mes bases de données les unes par rapport aux autres, pour dire: «Quel est mon plus gros consommateur de CPU?» Ou lequel prend le plus de temps en termes d'attente et de choses comme ça? Donc, une grande partie de ces informations seront également disponibles avec l'outil.
Et puis, le dernier mais non le moindre, c'est juste une capacité globale dont vous avez besoin d'un outil qui sera capable de gérer n'importe quelle situation qui se présentera à vous, et donc ce que je veux dire par là, si vous avez un grand environnement avec un Dans de nombreux cas, vous allez probablement rencontrer des situations où vous devez extraire des métriques qui ne sont traditionnellement pas des métriques qu'un DBA voudrait même surveiller dans certains cas, en fonction de cette situation particulière. Donc, avoir un outil que vous pouvez, qui est extensible, pour être en mesure d'ajouter des mesures supplémentaires et de pouvoir utiliser ces mesures sous la même forme et de la même manière que vous les utiliseriez si vous utilisiez un outil prêt à l'emploi métrique, par exemple. Donc, être en mesure d'exécuter des rapports, d'être en mesure d'alerter, de base - toutes les choses dont nous parlons - est également un élément clé pour pouvoir faire ces prévisions et faire en sorte que vous obteniez les réponses que vous recherchez. être en mesure de prendre ces décisions, aller de l'avant.
Maintenant, comme Diagnostic Manager le fait, nous avons un service centralisé, un groupe de services qui s'exécute, collecte des données par rapport aux instances de 2000 à 2016. Et puis ce que nous faisons, c'est que nous prenons ces données et que nous les mettons dans un référentiel central, puis ce que nous ferons avec ces données, évidemment, c'est que nous faisons beaucoup pour être en mesure de fournir des informations supplémentaires. Maintenant, en plus de cela - et l'une des choses qui ne sont pas ici - est que nous avons également un service qui fonctionne au milieu de la nuit, qui est notre service d'analyse prédictive, et qui fait un certain nombre de calculs et aide à comprendre et vous aider en tant qu'administrateur de base de données ou administrateur de base de données intérimaire, pour être en mesure de faire ce type de recommandations, afin de fournir également des informations en termes de références.
Donc, ce que j'aimerais faire, et ce n'est qu'un exemple rapide de l'architecture, le gros point à retenir ici est qu'il n'y a pas d'agents ou de services qui sont réellement assis sur les instances que vous gérez. Mais ce que j'aimerais faire, c'est simplement vous amener à l'application ici et vous faire une démo rapide. Et permettez-moi de sortir aussi, et d'y arriver. Alors, faites le moi savoir, je pense Eric, pouvez-vous voir ça?
Eric Kavanagh: Je l'ai maintenant, oui.
Bullett Manale: D' accord, je vais donc vous présenter quelques-unes des différentes parties sur lesquelles j'ai parlé. Et pour commencer, commençons par le genre de choses qui sont plus dans le sens de quelque chose que vous devez faire, ou voici quelque chose qui est un moment dans le futur et nous allons vous donner un aperçu à ce sujet. Et c'est pouvoir vraiment anticiper - ou devrais-je dire dynamiquement anticiper - les choses lorsqu'elles se produisent. Maintenant, dans le cas des rapports, l'une des choses que nous avons dans l'outil est trois rapports de prévision différents. Et dans le cas, par exemple, d'une prévision de base de données, ce que je ferais probablement dans le cas de pouvoir anticiper la taille d'une base de données sur une période de temps, et je vais vous donner quelques exemples de cela . Donc, je vais prendre ma base de données d'audit, qui est assez intensive en E / S - elle contient beaucoup de données. Nous avons, voyons, nous allons faire celui-ci ici, et prenons simplement la base de données des soins de santé ici.
Mais le fait est que je ne vois pas seulement ce que l'espace est là-dessus, je peux dire: «Écoutez, prenons la valeur des données de l'année dernière» - et je vais ici un peu ici, Je n'ai pas vraiment un an de données, j'ai environ deux mois de données - mais, parce que je choisis un taux d'échantillonnage de mois ici, je vais pouvoir anticiper ou prévoir dans ce cas les 36 prochaines unités parce que notre taux d'échantillonnage est fixé à des mois - c'est-à-dire une unité, est un mois - et ensuite je pourrais, pour ensuite exécuter un rapport me montrer essentiellement où nous anticiperions notre croissance future, pour ces trois bases de données. Et nous pouvons voir que nous avons un degré différent de différence, ou d'écart, entre les trois bases de données différentes, en particulier en ce qui concerne la quantité de données qu'elles consomment historiquement.
Nous pouvons voir que les points de données représentent les données historiques, puis la ligne va nous fournir les prévisions, ainsi que les chiffres à l'appui. Nous pouvons donc le faire au niveau de la table, nous pouvons le faire même au niveau du lecteur, où je peux anticiper la taille de mes disques, y compris les points de montage. Nous serions en mesure de prévoir ce même type d'informations, mais encore une fois, en fonction du taux d'échantillonnage, cela me permettra de déterminer combien d'unités et où nous prenons ce que nous voulons prévoir. Notez également que nous avons différents types de types de prévisions. Vous bénéficiez donc de nombreuses options et de flexibilité lorsque vient le temps de faire les prévisions. Maintenant, c'est une chose que nous ferons, en vous donnant en fait une date précise et en disant: «Hé, à cette date, c'est là que nous prévoyons la croissance de vos données.» En plus de cela, cependant, nous pouvons vous fournir d'autres informations liées à certaines des analyses que nous effectuons pendant les heures creuses et au service lorsqu'il s'exécute. Certaines des choses qu'il fait, c'est qu'il essaie d'anticiper les choses qui se produiront probablement, en se basant sur l'histoire du moment où les choses se sont produites dans le passé.
Donc, nous pouvons voir ici, en fait, une prévision nous donne un aperçu de la probabilité que nous ayons des problèmes tout au long de la soirée en raison de choses qui se sont encore produites dans le passé. Donc, évidemment, c'est génial, surtout si je ne suis pas un DBA, je peux regarder ces choses, mais ce qui est encore mieux si je ne suis pas un DBA, c'est cet onglet d'analyse. Donc, avant que cela ne soit ici dans l'outil, nous allions passer en revue et montrer le produit aux gens et ils seraient "C'est génial, je vois tous ces chiffres, je vois tout, mais je ne sais pas quoi faire" (rires) "À la suite de cela." Et donc ce que nous avons ici, est une meilleure façon pour vous d'être en mesure de comprendre, si je vais prendre des mesures pour aider à la performance, si je vais prendre des mesures pour égaliser aider à la santé de mon environnement, être en mesure d'avoir un moyen hiérarchisé de fournir ces recommandations, ainsi que des conseils utiles dans les informations pour en savoir plus sur ces recommandations et avoir même des liens externes vers certaines de ces données, qui me montreront et amenez-moi aux raisons pour lesquelles ces recommandations sont faites.
Et dans de nombreux cas, pouvoir fournir un script qui automatiserait, comme je l'ai dit, la correction de ces problèmes. Maintenant, une partie de ce que nous faisons ici avec cette analyse - et je vais vous montrer quand je vais configurer les propriétés de cette instance, et je vais à la section de configuration de l'analyse - nous avons beaucoup de catégories différentes qui sont répertoriés ici, et en partie, nous avons l'optimisation d'index et l'optimisation de requête. Donc, nous évaluons non seulement les métriques elles-mêmes, et des choses comme ça, mais aussi des choses comme les charges de travail et les index. Dans le cas ici, nous allons en fait faire une analyse d'index hypothétique supplémentaire. Donc, c'est une de ces situations où je ne veux pas, dans de nombreux cas, je ne veux pas ajouter d'index si je n'en ai pas besoin. Mais à un moment donné, il y a une sorte de point de basculement, où je dis: «Eh bien, la table atteint la taille ou les types de requêtes qui s'exécutent dans la charge de travail ont du sens maintenant pour ajouter un index. Mais cela n'aurait pas eu de sens peut-être six semaines avant. »Donc, cela vous permet d'obtenir dynamiquement cette idée des choses qui, comme je l'ai dit, amélioreront probablement les performances en fonction de ce qui se passe dans l'environnement, de ce qui se passe dans les charges de travail et faire ce genre de choses.
Et vous obtenez donc beaucoup de bonnes informations ici, ainsi que la possibilité d'optimiser ces choses automatiquement. C'est donc un autre domaine où nous pourrions aider, en termes de ce que nous appelons l'analyse prédictive. Maintenant, en plus de cela, je dois dire, nous avons également d'autres domaines qui, je pense, se prêtent généralement à vous aider à prendre des décisions. Et lorsque nous parlons de prendre des décisions, une fois de plus, être en mesure de regarder des données historiques, fournissez un aperçu pour nous amener là où nous devons être pour améliorer cette performance.
Maintenant, l'une des choses que nous pouvons faire est que nous avons un visualiseur de base qui nous permet de choisir sélectivement la métrique que nous voulons - et laissez-moi en trouver une décente ici - Je vais utiliser SQL CPU, mais le fait est que vous peut revenir sur plusieurs semaines pour peindre ces images pour que vous puissiez voir quand vos valeurs aberrantes sont, pour voir de manière générale où cette valeur se situe dans les périodes de temps que nous avons collectées des données. Et puis, en plus de cela, vous remarquerez également que lorsque nous passons à l'instance proprement dite, nous avons la possibilité de configurer nos lignes de base. Et les bases de référence sont une partie très importante pour pouvoir automatiser les choses ainsi que pouvoir être notifié des choses. Et le défi, comme la plupart des administrateurs de bases de données vous le diraient, est que votre environnement ne fonctionne pas toujours de la même manière, tout au long de la journée, par rapport à la soirée et ainsi de suite, comme nous l'avons mentionné plus haut dans l'exemple avec les périodes de maintenance, lorsque nous avoir des niveaux élevés de CPU ou quoi que ce soit qui pourrait arriver.
Donc, dans le cas ici, avec ces lignes de base réelles, nous pouvons avoir plusieurs lignes de base, donc je pourrais avoir une ligne de base par exemple, c'est pendant mes heures de maintenance. Mais je pourrais tout aussi facilement créer une base de référence pour mes heures de production. Et le point de faire cela est lorsque nous entrons dans une instance de SQL et que nous avons en fait ces multiples lignes de base, nous pourrions alors anticiper et être en mesure d'effectuer un certain type d'automatisation, un certain type de correction ou simplement d'alerte en général, différemment spécifique à ces fenêtres de temps. Donc, l'une des choses que vous verrez ici, ce sont ces lignes de base que nous générons qui utilisent les données historiques pour fournir cette analyse, mais plus important encore, je peux modifier ces seuils statiquement, mais je peux aussi les automatiser dynamiquement. Donc, à mesure que la fenêtre de maintenance, ou je devrais dire que la fenêtre de la ligne de base de maintenance s'ouvre, ces seuils basculeraient automatiquement en fonction des charges que je rencontre pendant cette fenêtre de temps, par rapport à peut-être au milieu de la journée lorsque mes charges sont pas autant, lorsque les charges de travail ne sont pas aussi impactantes.
Donc, c'est autre chose à garder à l'esprit, en termes de référence. Évidemment, cela vous sera très utile, en ce qui concerne également la compréhension de ce qui est normal et la capacité de comprendre également, engagez-vous lorsque vous allez également manquer de ressources. Maintenant, l'autre type de chose que nous avons dans l'outil, qui va vous aider à prendre des décisions, en plus de la référence et de la possibilité de configurer des alertes autour de ces lignes de base et des seuils que vous créez dynamiquement, c'est comme je l'ai dit plus tôt, juste pouvoir exécuter une multitude de rapports qui m'aident à répondre aux questions sur ce qui se passe.
Donc, par exemple, si j'avais 150 instances que je gère - dans mon cas, je ne le fais pas, nous devons donc jouer au jeu de simulation ici - mais si j'avais toutes mes instances de production et que je devais comprendre où est le domaine sur lequel j'ai besoin d'attention, en d'autres termes, si je ne dispose que d'un temps limité pour effectuer un certain type d'administration afin d'améliorer les performances, je veux me concentrer sur les domaines clés. Et donc, avec cela dit, je serais en mesure de dire: "Sur la base de cet environnement, classer mes instances les unes par rapport aux autres et me donner ce classement par canal de contention." Donc, que ce soit l'utilisation du disque, l'utilisation de la mémoire, les attentes, que ce soit le temps de réponse, je peux corréler - ou devrais-je dire classer - ces instances les unes par rapport aux autres. Évidemment, l'instance qui est en haut de chaque liste, si c'est la même instance, c'est probablement quelque chose sur laquelle je veux vraiment me concentrer, car elle est évidemment encore une fois en haut de la liste.
Donc, vous avez beaucoup de rapports dans l'outil qui vous aident en termes de classement de l'environnement au niveau de l'instance; vous pouvez également le faire au niveau de la base de données, où je peux classer mes bases de données les unes par rapport aux autres. En particulier pour les seuils et les zones que je peux définir, je peux même configurer des caractères génériques ici si je le souhaite, pour me concentrer uniquement sur des bases de données particulières, mais le fait est que je peux comparer mes bases de données de la même manière. En outre, en ce qui concerne les autres types d'analyse comparative et le plus important de cet outil, c'est l'analyse de base que nous avons. Donc, si vous faites défiler vers le bas jusqu'à la vue du service ici, vous verrez qu'il existe un rapport de statistiques de base. Maintenant, ce rapport va évidemment nous aider à comprendre non seulement quelles sont les valeurs des métriques, mais pour une instance spécifique, je pourrais sortir, et pour n'importe laquelle de ces métriques, être en mesure de regarder les lignes de base de ces métriques.
Donc, quoi que ce soit, en pourcentage ou tout ce que je pourrais dire et dire: «Voyons la référence pour cela éclaté au cours des 30 derniers jours», auquel cas cela va me montrer les valeurs réelles par rapport à la référence et Je serais en mesure de prendre certaines décisions en utilisant cette information, évidemment, alors c'est une de ces situations, où cela dépendra de la question que vous vous posez à l'époque. Mais cela va évidemment vous aider pour beaucoup de ces questions. J'aimerais pouvoir dire que nous avions un rapport qui fait tout, et c'est un peu comme le rapport facile, où vous appuyez et appuyez sur le bouton et il répond simplement à chaque question «et si» à laquelle vous pourriez jamais répondre. Mais la réalité est que vous allez avoir beaucoup d'attributs et beaucoup d'options pour pouvoir choisir parmi ces menus déroulants afin de pouvoir formuler les questions de type «et si» que vous recherchez .
Bon nombre de ces rapports visent donc à pouvoir répondre à ce type de questions. Et donc, il est très important également que ces rapports et en plus, toutes les choses que nous vous avons déjà montrées dans l'outil, comme je l'ai mentionné précédemment, aient la flexibilité d'incorporer de nouvelles métriques, d'être gérées, même de pouvoir créer des compteurs ou des requêtes SQL qui sont incorporées dans vos intervalles d'interrogation, pour être en mesure de m'aider à répondre à ces questions, que peut-être prêts à surveiller, vous pouvez ajouter ce genre de choses. Et vous pourrez alors faire toutes les mêmes choses que je viens de vous montrer: baseline, exécuter des rapports, et créer des rapports à partir de cette métrique, et être en mesure de répondre et de faire beaucoup de ces différents types de choses que je vous montre ici.
Maintenant, en plus de cela - et l'une des choses que nous avons évidemment rencontrées récemment - c'est d'abord, tout le monde basculait ou passait aux machines virtuelles. Et maintenant, nous avons beaucoup de gens qui se dirigent vers le cloud. Et il y a beaucoup de questions qui se posent autour de ce genre de choses. Est-il judicieux pour moi de passer au cloud? Vais-je économiser de l'argent en passant au cloud? Si je devais mettre ces choses sur une machine virtuelle, sur une machine à ressources partagées, combien d'argent puis-je économiser? Ces types de questions vont évidemment se poser également. Donc, beaucoup de ces choses gardent à l'esprit, avec Diagnostic Manager, nous pouvons ajouter et tirer des environnements virtualisés de VMware et Hyper-V. Nous pouvons également ajouter des instances qui sont sur le cloud, afin que vos environnements comme Azure DB, par exemple, ou même RDS, nous puissions également extraire des métriques de ces environnements.
Il y a donc beaucoup de flexibilité et beaucoup de capacité à répondre à ces questions en ce qui concerne les autres types d'environnements vers lesquels nous voyons des gens se diriger. Et il y a encore beaucoup de questions à ce sujet, et comme nous voyons des gens consolider ces environnements, ils devront également pouvoir répondre à ces questions. Donc, c'est un assez bon aperçu, je dirais, de Diagnostic Manager, en ce qui concerne ce sujet. Je sais que le sujet de l'intelligence d'affaires a été abordé et nous avons également un outil d'intelligence d'affaires dont nous n'avons pas parlé aujourd'hui, mais il va également vous donner un aperçu en termes de réponse à ce type de questions en ce qui concerne votre cubes et tous ces différents types de choses, aussi. Mais j'espère que cela a été un bon aperçu, au moins en termes de la façon dont ce produit peut aider à formuler un bon plan.
Eric Kavanagh: Très bien, bonnes choses. Ouais, je vais le jeter à Rick, s'il est toujours là. Rick, tu as des questions?
Rick Sherman: Oui, donc d'abord, c'est super, j'aime ça. J'aime particulièrement l'extension aux machines virtuelles et aux clouds. Je vois que beaucoup de développeurs d'applications pensent que si c'est dans le cloud, ils n'ont pas besoin de le régler. Donc-
Bullett Manale: D'accord, nous devons encore payer pour cela, non? Vous devez toujours payer pour tout ce que les gens mettent sur le cloud, donc s'il fonctionne mal ou s'il cause beaucoup de cycles CPU, c'est plus d'argent que vous devez payer, donc ce n'est pas le cas, vous encore besoin de mesurer ce genre de choses, absolument.
Rick Sherman: Oui, j'ai vu beaucoup de mauvaises conceptions dans le cloud. Je voulais vous demander si ce produit serait également utilisé - je sais que vous avez mentionné le produit BI et que vous avez des tonnes d'autres produits qui interagissent les uns avec les autres - mais pourriez-vous commencer à examiner les performances SQL, les requêtes individuelles dans cet outil? Ou serait-ce d'autres outils qui seraient utilisés pour cela?
Bullett Manale: Non, ce serait, absolument. C'est l'une des choses que je n'ai pas couvert et je voulais le faire, c'est la partie des requêtes. Nous avons beaucoup de façons différentes d'identifier les performances des requêtes, qu'elles soient liées, en particulier aux attentes comme nous le voyons ici, ou qu'elles soient liées à la consommation de ressources des requêtes dans leur ensemble, il existe de nombreuses façons d'analyser les requêtes performance. Il s'agit de la durée, du processeur, des E / S, et encore une fois, nous pouvons également examiner les charges de travail elles-mêmes pour fournir des informations. Nous pouvons fournir les recommandations dans la section d'analyse et nous avons également une version Web qui fournit des informations sur les requêtes elles-mêmes. Je peux donc obtenir des recommandations sur les index manquants et la possibilité de visualiser le plan d'exécution et tout ce genre de choses; c'est aussi une capacité. Donc, absolument, nous pouvons diagnostiquer les requêtes de sept façons jusqu'à dimanche (rires) et être en mesure de fournir cet aperçu en termes de nombre d'exécutions, que ce soit la consommation de ressources, les attentes, la durée, toutes ces bonnes choses.
Rick Sherman: OK, super. Et puis quelle est la charge sur les instances elles-mêmes avec toute cette surveillance?
Bullett Manale: C'est une bonne question. Le défi de répondre à cette question est, est-ce que cela dépend, c'est comme n'importe quoi d'autre. Beaucoup de ce que notre outil a à offrir, il offre une flexibilité et une partie de cette flexibilité est que vous pouvez lui dire quoi collecter et ce qu'il ne faut pas collecter. Ainsi, par exemple, avec les requêtes elles-mêmes, je n'ai pas à collecter les informations d'attente, ou je le peux. I can collect information related to queries that surpass a duration of time, of execution. As an example of that, if I were to go into the configure query monitor and I were to say, “Let's change this value to zero, ” the reality is that just basically makes the tool collect every query that runs and that's really not the spirit of why that's there, but generally speaking if I wanted to provide a full sample of data for all the queries, I could do that.
So, it's very relative to what your settings are, generally speaking, out of the box. It's anywhere from about 1–3 percent overhead, but there's other conditions that will apply. It also depends on how much port queries are running on your environment, right? It also depends on the method of collection of those queries and what version of SQL it is. So, for example, SQL Server 2005, we're not going to be able to pull from extended events, whereas so we would pull from a trace to do that. So, it would be a little bit different in terms of the way we would go about gathering that data, but that said, like I said, we've been around for I guess since about 2004 with this product. It's been around a long time, we've got thousands of customers, so the last thing we want to do is have a performance monitoring tool that causes performance problems (laughs). And so we try to steer clear of that, as much as possible, but generally speaking, like so about 1–3 percent is a good rule of thumb.
Rick Sherman: OK, and that's pretty low, so that's terrific.
Eric Kavanagh: Good. Robin, any questions from you?
Robin Bloor: I'm sorry, I was on mute. You've got a multiple database capability, and I'm interested in how 'cause you can look at multiple databases and therefore you can know a larger resource base is possibly divided up between various virtual machines and so on and so forth. I'm interested in how people actually use that. I'm interested in what the customers are doing with that. Because that looks to me, well, it certainly, when I was messing about with databases, something I never had on hand. And I would only ever consider one instance in any meaningful way at any given point in time. So, how do people use this?
Bullett Manale: Generally speaking, you're talking about in general just the tool itself? How they're using it? I mean, generally, it's about being able to have a central point of presence of the environment. Having peace of mind and knowing that if they stare at a screen and they see green, they know everything is good. It's when problems happen and obviously most of the cases from a DBA's perspective, a lot of times those problems happen when they're in front of the console, so being able to be notified as soon as the problem is happening. But in addition to that, being able to understand when the problem does happen, being able to get to the heart of the information that is providing them some context in terms of why it's happening. And so that's, I think, the biggest part: being proactive about it, not being reactive.
Most of the DBAs I talk to – and I don't know, it's a good percentage of them – unfortunately are still in the reactive type of environment; they wait for a consumer to approach them to tell them there's a problem. And so, we see a lot of people trying to break away from that and I think that's a big part of the reason why people like this tool is that it helps them to be proactive but it also provides them the insight into what is going on, what's the problem, but in a lot of cases, what we find at least – and maybe it's just the DBAs telling us this – but the DBAs, the perception is it's always their problem, even if it's the application developer that wrote the application that didn't write it properly, they're the ones that are going to be taking the blame, 'cause they're taking that application into their systems or servers and then when the performance is bad, everybody points to the DBA says, “Hey it's your fault.”
So this tool is, a lot of times, is going to be used to help in terms of making the case for the DBA to say, “Hey, this is where the problem lies and it's not me.” (Laughs) We need to improve this, whether it be changing the queries or whatever it might be. In some cases it will fall in their bucket in terms of their responsibility, but at least having the tool to be able to help them understand that and know that, and doing it in a timely way is obviously the ideal approach.
Robin Bloor: Yeah, most of the sites that I'm familiar with, but it has been a while since I've been out there, looking at various multi-database sites, but mostly what I used to find was that there would be DBAs that focused on a handful of databases. And those would be the databases, that if they ever went down, it would be a real big problem for the business, and so on and so forth. And the other ones, they'll just be collecting stats every now and then to see they didn't run out of space and they'd never look at them at all. And while you were doing the demo I was looking at this and I was thinking well, in one way or another, you extend, just by providing something like this for databases that were often, nobody cared too much about, because they have data growth, they have application growth at times as well. You're extending DBA coverage in quite a dramatic way. So that's what the question is really about, is it that with a set of tools like this, you end up being able to pretty much give a DBA service to every database that is in the corporate network?
Bullett Manale: Sure, I mean, the challenge is, is that like you said pretty eloquently, is like there's some databases that the DBAs care about and then there's some they don't care about as much. And the way that this particular product, the way it's licensed is on a per-instance basis. So, there is, I guess you'd say, a threshold of when people decide “Hey, this isn't a critical enough instance that I want to manage it with this tool.” That said, there are other tools that we do have that are more, I guess, catering to those less important instances of SQL. One of them would be like the Inventory Manager, where we do light health checks against the instances, but in addition to that what we do is we do discovery, so we identify new instances that have been brought online and then, from that point, as a DBA I can say, “OK, here's a new instance of SQL, now is it Express? Is it the free version or is an enterprise version?” That's probably a question I want to ask myself, but secondly, how important is that instance to me? If it's not that important, I might have this tool going out and doing it, generic, what I would call generic health checks in the sense that they're the elemental types of things I care about as a DBA: Is the drive filling up? Is the server responding to issues? The main things, right?
Whereas with Diagnostic Manager, the tool I was just showing you, it's going to get down to the query level, it's going to get down into the recommendation of indexes, looking at the execution plan and all that good stuff, whereas this is mainly focused on who owns what, what is it that I own and who's responsible for it? What service packs and hot fixes do I have? And are my servers running with the main ingredients of what I would consider to be a healthy instance of SQL? So to answer your question, there is a little bit of a mix. When we have people looking at this tool, they're typically looking at a more critical set of instances. That said, we have some folks that buy every instance that they have and manage it, so it just depends. But I tell you, overall, there's definitely a threshold of those folks that consider their environment is important enough to have a tool like this to manage those instances.
Robin Bloor: Okay, another question before I hand it on to Eric. The impression one gets, just from watching the industry is that databases still have a life, but all of the data is pouring into all of these data lakes and so on and so forth. That's the hype, really, and the hype never reflects the reality, so I'm interested in what kind of reality you're perceiving out there? Are the important databases within an organization, are they experiencing the traditional data growth, which I used to think of as 10 percent a year? Or are they growing more than that? Is big data making these databases balloon? What's the picture you see?
Bullett Manale: I think a lot of cases we're seeing some of the data being moved into those other segments where it makes more sense, when there's other technologies that are become available. As of recent, some of the bigger data stuff. But these databases, I would say, it's hard to generalize in a lot of cases 'cause everybody is a little bit different. Generally speaking, though, I do see some divergence. I see, like I said, people are moving to the elastic models in a lot of cases, because they want to grow the resources and not so much in other areas. Some folks are moving to the big data. But it's hard to get a feel for, you say, the perception, because generally speaking the folks I'm talking to all have the traditional databases and are using this on a SQL Server environment.
That said, I'd say in terms of SQL itself, I definitely still think it's gaining market share. And I think that there's a lot of folks that are still heading towards SQL from other places like Oracle, because it's more affordable and seems to be obviously, as SQL versions become more advanced – and you're seeing this with the more recent things that are going on with SQL, in terms of encryption and all of the other capabilities that are making it an environment or a database platform – that is obviously very mission critical capable, I guess. So, I think we're seeing that as well. Where you're seeing a shift, it's still happening. I mean, it was happening 10 years ago, it's still, I think, happening in terms of SQL Server, where the environment's growing and the market share is growing.
Robin Bloor: OK, Eric, I presume the audience has a question or two?
Eric Kavanagh: Yeah, let me throw one quick one over to you. It's a pretty good question, actually. One of the attendees is asking, will this tool tell me if a table may need an index to speed up the query? If so, can you show an example?
Bullett Manale: Yeah, so I don't know if I have one for a specifically adding an index, but you can see here, we have fragmentation recommendations here. I also just believe we just had and this was part of the Diagnostic Manager offering the web-based version, where it's telling me I have a missing index. And we can view those recommendations and it'll tell us the potential gain of that by indexing that information. The other thing I should just mention is that when we do the recommendations, for many of these, the script will be built for it. That one's not a good example, but you would be able to see, yes, the situations where an index – either a duplicate index, or the addition of an index – would improve performance, and like I said earlier, we do a lot of that through hypothetical index analysis. So, it really helps in terms of understanding the workload, to be able to apply that to the recommendation.
Eric Kavanagh: That's great stuff, and this will give me a good segue to the final comments here. Robin and I and Rick as well, have heard over many years now, there's talk about self-tuning databases. It's a self-tuning database! All I can tell you is: Don't believe them.
Bullett Manale: Don't believe the hype.
Eric Kavanagh: There may be some small little things that get done dynamically, but even that, you might want to check it out and make sure it's not doing something you don't want it to do. So, for quite some time, we're going to need tools like this to understand what's happening at the database level and like Robin said, data lakes are fascinating concepts, but there's probably about as much chance of them taking over as there is of there being a Loch Ness Monster anytime soon. So, I would just say again, the real world has a lot of database technology, we need people, DBAs, to look at this stuff and synthesize it. You can tell, you need to know what you're doing to make this stuff work. But you need the tools to give you the information to know what you're doing. So, bottom line is DBAs are going to be doing just fine.
And big thanks to Bullett Manale and our friends at IDERA. And of course, Rick Sherman and Robin Bloor. We do archive all of these webcasts, so hop online insideanalysis.com or to our partner site www.techopedia.com for more information on all that.
And with that, we'll bid you farewell, folks. Thanks again, we'll talk to you next time. Prends soin de toi. Bye Bye.
