De beste plannen: tijd, geld en problemen besparen met optimale voorspellingen

Schrijver: Roger Morrison
Datum Van Creatie: 23 September 2021
Updatedatum: 10 Kunnen 2024
Anonim
The Third Industrial Revolution: A Radical New Sharing Economy
Video: The Third Industrial Revolution: A Radical New Sharing Economy

Afhaal: Gastheer Eric Kavanagh bespreekt voorspellingen met Dr. Robin Bloor, Rick Sherman en IDERAs Bullett Manale.



Je moet je registreren voor dit evenement om de video te bekijken. Registreer om de video te bekijken.

Eric Kavanagh: Dames en heren, nogmaals hallo en welkom terug bij de Hot Technologies webcast-serie! Mijn naam is Eric Kavanagh, ik zal uw gastheer zijn voor het webseminar van vandaag, genaamd "Tijd, geld en moeite besparen met optimale voorspellingen". Natuurlijk heb ik het eerste deel van de titel daar gemist: "De beste plannen". We praten altijd daarover in deze show. Dus, Hot Technologies is natuurlijk ons ​​forum om te begrijpen wat sommige van de coole producten tegenwoordig op de wereld zijn, de wereld van de bedrijfstechnologie, wat mensen ermee doen, hoe ze werken, al dat soort leuke dingen.

En het onderwerp van vandaag behandelt, zoals ik suggereer, voorspelling. Je probeert echt te begrijpen wat er gaat gebeuren in je organisatie. Hoe gaat u uw gebruikers tevreden houden, wat ze ook doen? Als ze analyses doen, als ze echt werk doen, staan ​​ze voor echte klanten met transactionele systemen, wat het geval ook is, je wilt begrijpen hoe je systemen draaien en wat er aan de hand is, en dat is waar het vandaag goed over gaat. Het is een beetje grappig omdat voorspellen niet iets is dat ik graag doe, want ik ben bijgelovig, zoals ik denk dat als ik te veel voorspel, er slechte dingen zullen gebeuren, maar dat ben ik gewoon. Volg mijn aanwijzingen niet.


Dus, hier zijn onze presentatoren vandaag, de uwe echt in de linkerbovenhoek, Rick Sherman belt vanuit Boston, onze buddy Bullett Manale van IDERA en onze eigen Dr. Robin Bloor. En daarmee geef ik het over aan Robin en herinner ik mensen eraan: stel vragen, wees niet verlegen, we houden van goede vragen, stel ze vandaag aan onze presentatoren en anderen voor. En daarmee, Robin, haal het weg.

Robin Bloor: OK, nou, ik ben in de pole position zoals ze zeggen, ik dacht dat ik vandaag een SQL-verhaal vertel, omdat het de achtergrond is voor wat de discussie gaat en het zal onvermijdelijk niet botsen omdat Rick zich hier niet op concentreert , en zal niet botsen met wat Rick te zeggen heeft. Dus, het SQL-verhaal, er zijn een aantal interessante dingen aan SQL omdat het zo dominant is. Zie, dat is een typfout, SQL is een declaratieve taal. Het idee was dat je een taal kon maken waarin je zou vragen wat je wilde. En de database zou uitwerken hoe het te krijgen. En het is eigenlijk vrij goed uitgewerkt, maar er zijn een aantal dingen die het vermelden waard zijn, de gevolgen van het baseren van de hele IT-industrie op een verklarende taal. De gebruiker weet niet of geeft niet om de fysieke organisatie van de gegevens, en dat is het goede van de declaratieve taal - het scheidt u daarvan af, en maakt zich zelfs zorgen over - vraag gewoon om wat u wilt, en de database zal het gaan halen.


Maar de gebruiker heeft geen idee of de manier waarop ze de SQL-query structureren de prestaties van de query zal beïnvloeden en dat is een beetje een nadeel. Ik heb query's gezien die honderden en honderden regels lang zijn, die slechts één SQL-aanvraag zijn, weet je, begint met "select" en gaat gewoon door met subquery's, enzovoort. En het blijkt eigenlijk dat als u een bepaalde gegevensverzameling uit een database wilt, u er op veel verschillende manieren om kunt vragen met SQL, en hetzelfde antwoord krijgt als u enigszins bekend bent met de gegevens. Dus, één SQL-query is niet noodzakelijk de beste manier om gegevens te vragen, en databases zullen heel anders reageren volgens de SQL die u erin plaatst.

En dus beïnvloedt SQL de prestaties, dus mensen die SQL gebruiken, zijn waar voor hen, het geldt ook voor de SQL-programmeurs die SQL gebruiken en ze zullen zelfs minder waarschijnlijk nadenken over de impact die ze zullen hebben, omdat het grootste deel van hun focus gaat eigenlijk over het manipuleren van gegevens en niet over het verkrijgen, plaatsen van gegevens. En hetzelfde geldt ook voor BI-tools, ik heb de SQL gezien die, als je wilt, uit BI-tools van verschillende databases haalt en het moet gezegd worden, dat veel daarvan is, nou, ik zou geen SQL-vragen schrijven zoals dat. Zijn iemand heeft, als je wilt, een kleine motor gemaakt die, ongeacht de parameters, wat SQL weggooit en nogmaals, dat SQL niet noodzakelijkerwijs efficiënte SQL zal zijn.

Toen dacht ik dat Id de impedantie-mismatch noemde, de gegevens die programmeurs gebruiken verschillen van de gegevens zoals ze worden gesorteerd. Dus, onze DMS slaat gegevens op in tabellen, georganiseerd de object-georiënteerde code zijn meestal coders, programmeren tegenwoordig object-georiënteerde vorm en ze bestellen gegevens in objectstructuren, zodat het niet aan elkaar wordt toegewezen. Er is dus een noodzaak om te vertalen van wat de programmeur denkt dat de gegevens zijn naar wat de database denkt wat de gegevens zijn. Wat lijkt alsof we iets verkeerd hebben gedaan om dat het geval te laten zijn. SQL heeft DDL voor gegevensdefinitie, het heeft DML - taal voor het bewerken van gegevens - selecteren, projecteren en samenvoegen om die gegevens te verkrijgen. Nu, er is heel weinig wiskunde en heel weinig tijdgebaseerde dingen, dus het is de imperfecte taal, hoewel het moet worden gezegd dat het is uitgebreid en nog steeds wordt uitgebreid.

En dan krijg je het SQL-barrièreprobleem, dat altijd rechter is dan het diagram, maar veel mensen stelden vragen om analytische redenen, zodra ze het antwoord op de termen met vraaggegevens hadden gekregen, een andere vraag willen stellen. Dus het wordt een dialoog ding, nou, SQL was niet gebouwd voor dialogen, het was gebouwd om in één keer te vragen wat je wilt. En het is de moeite waard om dat te weten, want er zijn enkele producten die SQL in de steek laten om een ​​gesprek tussen de gebruiker en de gegevens mogelijk te maken.

In termen van databaseprestaties - en dit soort verspreidt zich naar alles - ja, er is CPU, er is geheugen, er is schijf, er zijn netwerkoverhead en er is het vergrendelingsprobleem van meer dan één persoon die exclusief gebruik van de gegevens op een gegeven wenst punt in de tijd. Maar er zijn ook slechte SQL-aanroepen, er kan ontzettend veel worden gedaan als je de SQL daadwerkelijk optimaliseert, qua prestaties. Dus, databaseprestatiefactoren: slecht ontwerp, slecht programma-ontwerp, ontbrekende gelijktijdigheid van werklast, taakverdeling, querystructuur, capaciteitsplanning. Dat is datagroei. En in een paar woorden, SQL is handig, maar het optimaliseert niet zelf.

Dat gezegd hebbende, denk ik dat we het aan Rick kunnen doorgeven.

Eric Kavanagh: Oké, Rick, ik zal je de sleutels van de WebEx-auto geven. Haal het weg.

Rick Sherman: Oké, geweldig. Nou bedankt Robin, want we zijn begonnen in het begin van de presentatie, mijn afbeeldingen zijn nog steeds behoorlijk saai, maar gaan er goed mee akkoord. Dus ik ben het eens met alles waar Robin het over de SQL-kant over had. Maar waar ik me nu een beetje op wil concentreren, is de vraag naar gegevens, die heel snel doorlopen, het aanbod zoals in tools die in die ruimte worden gebruikt of de behoefte aan de tools in die ruimte.

Ten eerste heeft elk artikel dat je leest te maken met big data, veel data, ongestructureerde data uit de cloud, big data overal waar je je kunt voorstellen. Maar de groei van de databasemarkt is voortdurend met SQL geweest, relationele database waarschijnlijk vanaf 2015, is nog steeds 95 procent van de databasemarkt. De top drie relationele leveranciers hebben ongeveer 88 procent van het marktaandeel in die ruimte. Dus, we praatten nog steeds, zoals Robin sprak, over SQL. En in feite, zelfs als we op het Hadoop-platform keken, is Hive en Spark SQL - die mijn zoon, die nu een datawetenschapper is, de hele tijd nu gebruikt - zeker de dominante manier voor mensen om gegevens te vinden.

Nu, aan de databasekant, zijn er twee brede categorieën van gebruik van databases. Een daarvan is voor operationele databasebeheersystemen, dus planning van bedrijfsrelaties, personeel voor klantrelaties, de Salesforce ERP's, Oracles, EPIC's, N4's, enz. Van de wereld. En de, er is een grote hoeveelheid en groeiende hoeveelheid gegevens in datawarehouses en andere op business intelligence gebaseerde systemen. Omdat alles, ongeacht waar en hoe het wordt vastgelegd, opgeslagen of verhandeld, uiteindelijk wordt geanalyseerd en dus is er een enorme vraag en toename van het gebruik van databases, met name relationele databases op de markt.

Nu, we hebben de vraag, we hebben enorme hoeveelheden gegevens binnen. En ik heb het niet alleen over big data, ik heb het over het gebruik van data in allerlei soorten bedrijven. Maar als aanvulling op de aanbodzijde, voor mensen die deze middelen kunnen beheren, hebben we eerst een soort DBA-tekort. We hebben volgens het Bureau of Labor Statistics van 2014-2024 dat de DBA-banen slechts met 11 procent zullen groeien - nu dat mensen zijn die DBA-functies hebben, maar daarover in een seconde praten - versus de 40-plus procent jaarlijkse datagroei. En we hebben veel DBA's; gemiddeld is datzelfde onderzoek over de gemiddelde leeftijd behoorlijk hoog vergeleken met andere IT-beroepen. En dan hebben veel mensen het veld verlaten, niet noodzakelijkerwijs met pensioen, maar verschuivend naar andere aspecten, in management, of wat dan ook.

Nu is een deel van de reden dat ze vertrekken, omdat de DBA-baan steeds moeilijker wordt. Ten eerste hebben we DBA's die veel verschillende databases zelf beheren, fysieke databases die zich overal bevinden, evenals verschillende soorten databases. Nu kan dat relationeel zijn, of het kunnen ook andere databases zijn, ook soorten databases. Maar zelfs als het relationeel is, kunnen ze een, twee, drie, vier verschillende leveranciers hebben die ze eigenlijk proberen te beheren. DBA's worden meestal betrokken na het ontwerp van de database of de applicatie. Robin sprak over hoe databases of applicaties worden ontworpen, hoe SQL wordt ontworpen. Nou, toen hadden we het over datamodellering, ER-modellering, uitgebreide ER-modellering, dimensiemodellering, geavanceerde dimensionale modellering, wat dan ook, typisch applicatieprogrammeurs en applicatie-ontwikkelaars ontwerpen met hun einddoel in gedachten - ze ontwerpen niet voor de efficiëntie van de databasestructuur zelf . We hebben dus veel slecht ontwerp.

Nu heb ik het niet over de leveranciers van commerciële zakelijke applicaties; ze hebben meestal ER-modellen of uitgebreide ER-modellen. Waar ik het over heb is dat er veel meer bedrijfsprocessen en applicaties worden gebouwd door applicatie-ontwikkelaars in elk bedrijf - dat zijn degenen die niet noodzakelijkerwijs zijn ontworpen voor efficiëntie of effectiviteit van de implementatie. En de DBA's zelf zijn overwerkt en ze hebben soms 24/7 verantwoordelijkheid, ze krijgen steeds meer databases. Ik denk dat dat een beetje mee te maken heeft dat mensen niet helemaal begrijpen wat ze doen, of hoe ze het doen. Hun eigen kleine groep en mensen blijven maar denken: "Nou, al deze tools zijn gewoon zo gemakkelijk te gebruiken, we kunnen gewoon steeds meer databases over hun werklast blijven gooien", wat niet het geval is.

Dat leidt ons naar de parttime en onbedoelde DBA's. We hebben IT-teams die klein zijn en ze zich niet per se een speciale DBA kunnen veroorloven. Dat geldt nu voor kleine tot middelgrote bedrijven, waar de uitbreiding van database en database-applicaties in het afgelopen decennium is geëxplodeerd en zich blijft uitbreiden. Maar het is ook het geval bij grote bedrijven, die meestal al heel lang datawarehousing en business intelligence-analyses uitvoeren. Lang geleden kregen we speciale DBA's voor die projecten; we krijgen nooit meer een speciale DBA. Waren verantwoordelijk voor het ontwerpen van de database, wat prima is, als het iemand is die ervaring heeft.Maar in het algemeen zijn de DBA's applicatie-ontwikkelaars, ze nemen die rol vaak als een parttime deel van hun werk aan, ze hebben er geen formele training in en nogmaals, ze ontwerpen het voor hun einddoelen, ze ontwerpen het niet voor efficiëntie.

En er is veel verschil tussen ontwerp en ontwikkeling, versus implementatie en beheer. Dus, we hebben de "cent wijs, pond dwaas", met een kleine spaarpot daar, overslaan op het krijgen van de vaardigheden en middelen die nodig zijn in de projecten. Ik denk dat iedereen uit "Revenge of the Nerds" komt, mijn kleine foto daar. Nu, voor zover wat mensen nodig hebben, hebben we een groeiend gebruik van databases en gegevens in SQL. We hebben een beperkt aantal DBA's - mensen die bekwaam en deskundig zijn in deze afstemmings- en ontwerp- en beheer- en implementatiesituaties. En we hebben meer en meer parttime of toevallige DBA's, mensen die niet de formele training hebben gehad.

Dus, wat zijn enkele van de andere dingen die ook aan de orde komen over het feit dat deze databases niet zo goed worden afgestemd of beheerd? Ten eerste gaan veel mensen ervan uit dat het databasesysteem zelf over voldoende hulpmiddelen beschikt om zichzelf te beheren. Nu worden de tools steeds eenvoudiger om te doen - ontwerp en ontwikkeling - maar dat is anders dan een goed ontwerp en goed beheer, capaciteitsplanning, monitoring, etc. voor implementatie. Dus in de eerste plaats gaan mensen ervan uit dat ze alle tools hebben die ze nodig hebben. Ten tweede, als je een parttime of accidentele DBA bent, weet je niet wat je niet weet.

Ik denk dat ik een deel van de zin daar ben vergeten, zodat ze vaak niet eens begrijpen waar ze zelfs naar moeten kijken in het ontwerp of wanneer ze de databases beheren of bedienen. Als dat niet jouw beroep is, zul je niet begrijpen wat je moet doen. De derde is dat SQL een go-to-tool is, dus Robin sprak over SQL, en hoe slecht SQL soms is geconstrueerd, of vaak is geconstrueerd. En ook een van mijn grootste huisdieren in de BI-datawarehousing, datamigratie, data engineering-ruimte is dat mensen in plaats van tools de neiging hebben om SQL-code te schrijven, opgeslagen procedures, zelfs als ze een dure tool voor gegevensintegratie of een dure gebruiken BI-tool, ze gebruiken het vaak alleen om opgeslagen procedures uit te voeren. Zodat het belang van het begrijpen van database-ontwerp, van de constructie van SQL, steeds belangrijker wordt.

En tot slot is er deze silobenadering, waarbij we individuele mensen naar individuele databases laten kijken. Ze kijken niet hoe de applicaties werken en met elkaar omgaan. En ze kijken ook echt vaak naar de databases versus de applicaties waarvoor ze ze gebruiken. Dus de werklast die je in de database krijgt, is van cruciaal belang in het ontwerp, cruciaal in het afstemmen, kritisch in het proberen te achterhalen hoe je capaciteit kunt plannen, enz. Dus, kijkend naar het bos vanuit de bomen, zitten mensen in het onkruid , kijkend naar de individuele tabellen en databases en niet naar de algehele interactie van deze applicaties in de werklast.

Ten slotte moeten mensen kijken naar de belangrijkste gebieden waar ze naar moeten kijken. Wanneer ze van plan zijn om databases te beheren, moeten ze eerst nadenken over, een aantal toepassingsgerichte prestatiestatistieken ontwikkelen, dus moeten ze niet alleen kijken hoe deze tabel is gestructureerd, hoe deze in het bijzonder is gemodelleerd, maar hoe deze wordt gebruikt? Dus als u een bedrijfstoepassing heeft die te maken heeft met supply chain management, als u bestellingen van internet afneemt, als u BI doet - wat u ook doet - moet u kijken naar wie het gebruikt, hoe zij het gebruiken, wat de datavolumes zijn , wanneer het gaat gebeuren. Waar je echt naar op zoek bent, zijn de wachttijden, want wat er ook gebeurt, alle applicaties worden beoordeeld op hoe lang het duurt om iets gedaan te krijgen, of het nu een persoon is of alleen de uitwisseling van gegevens tussen applicaties of processors. En wat zijn de knelpunten? Dus vaak wanneer u problemen probeert te debuggen, probeert u natuurlijk echt te kijken naar wat de echte knelpunten zijn - niet noodzakelijkerwijs hoe u alles kunt afstemmen, maar hoe u zich kunt ontdoen van en de prestaties kunt verhogen naar de wachttijden en doorvoer - ongeacht je moet kijken.

En u moet echt de gegevensverzameling, de transacties, de transformatieaspecten in de database scheiden, samen met de analyses. Elk van hen heeft verschillende ontwerppatronen, elk van hen heeft verschillende gebruikspatronen en elk van hen moet anders worden afgestemd. U moet dus nadenken over hoe deze gegevens worden gebruikt, wanneer ze worden gebruikt, waarvoor ze worden gebruikt en uitzoeken wat de prestatiestatistieken zijn en wat de belangrijkste dingen zijn die u wilt analyseren met betrekking tot dat gebruik. Als u nu kijkt naar het bewaken van de prestaties, wilt u de databasebewerkingen zelf bekijken; u wilt kijken naar zowel de datastructuren, dus de indexen, partities en andere fysieke aspecten van de database, zelfs de structuur van de database - of het ER-model of het dimensionale model, hoe het ook gestructureerd is - al die dingen hebben een impact op de prestaties , vooral in de verschillende nadelen van gegevensverzamelinganalyses en de transformaties die plaatsvinden.

En zoals Robin aan de SQL-kant zei, kijken naar de SQL die wordt uitgevoerd door deze verschillende applicaties in deze databases, en het afstemmen ervan is van cruciaal belang. En kijkend naar de algemene applicatieworkloads en de infrastructuuromgeving waarop deze databases en applicaties draaien. Zodat de netwerken, de servers, de cloud - ongeacht waar ze op draaien - ook kijken naar de impact die deze applicaties en deze databases hebben binnen dat con, hebben deze allemaal een wisselwerking tussen het kunnen afstemmen van de database.

En ten slotte, als u naar hulpmiddelen kijkt, wilt u de drie verschillende soorten analyses kunnen bekijken die daarmee verband houden. U wilt beschrijvende analyse bekijken: wat gebeurt er en waar, gerelateerd aan de database en de applicatieprestaties. U wilt de mogelijkheid hebben om diagnostische analyses uit te voeren om niet alleen uit te zoeken wat er gebeurt, maar waarom gebeurt het, waar zijn de knelpunten, waar zijn de problemen, wat loopt goed, wat loopt niet goed? Maar in staat zijn om de probleemgebieden te analyseren en te analyseren om deze aan te pakken, hetzij voor ontwerp, hetzij wat u ook moet doen.

En tot slot, het meest agressieve of proactieve type analyse is om daadwerkelijk voorspellende analyses uit te voeren, modellen voor voorspellende analyses, wat dan ook. We weten dat de database en de applicaties in deze con werken, als we de capaciteit verhogen, als we meer gebruikers krijgen, als we meer doorvoer doen, wat we ook doen, in staat zijn om te projecteren wat, hoe en waar dat de database beïnvloedt, de applicaties, stelt ons in staat om proactief te plannen en uit te zoeken, waar de knelpunten zijn, waar de wachttijden kunnen lijden en wat we moeten doen om dingen te repareren. We willen dus tools hebben die in staat zijn om de prestatiestatistieken te implementeren, de prestaties te bewaken, net als bij deze drie soorten analyses. En dat is mijn overzicht.

Eric Kavanagh: Oké, laat me het overhandigen - dat zijn trouwens twee geweldige presentaties - laat me dit overhandigen aan Bullett Manale om het vanaf daar over te nemen. En mensen, vergeet niet om goede vragen te stellen; we hebben al een aantal goede inhoud. Haal het weg, Bullett.

Bullett Manale: Klinkt goed. Bedankt, Eric. Dus, veel van wat Rick en Robin zeiden, ben het duidelijk met 100 procent eens. Ik zou zeggen dat ik deze dia naar boven heb getrokken, omdat ik denk dat het passend is, ik weet niet voor degenen onder jullie die 'A-Team'-fans zijn in de jaren '80, John Hannibal Smith had een gezegde en zei altijd:' Ik hou van wanneer een plan samenkomt, ”en ik denk dat wanneer je het hebt over met name de SQL Server, waar het over ging focussen, het product waar we het vandaag over zouden hebben, SQL Diagnostic Manager, het zeker een van die dingen is die je moet hebben; je moet in staat zijn om de gegevens die je hebt te gebruiken en beslissingen kunnen nemen op basis van die gegevens, en in sommige gevallen ben je niet op zoek naar een beslissing; je bent op zoek naar iets om je te vertellen wanneer iets middelen opraakt, wanneer je middelen opraken, wanneer je een bottleneck gaat hebben, dat soort dingen.

Het gaat niet alleen om het bewaken van een specifieke statistiek. Dus met Diagnostic Manager gaat een van de dingen die het heel goed doet u helpen op het gebied van prognoses en begrip specifiek voor de werklast en we zouden daar vandaag veel over gaan vertellen. De tool is afgestemd op de datamanager, de DBA of de acterende DBA, dus veel dingen waar Rick het over had, de acterende DBA is zo waar. In veel gevallen, als je geen DBA bent, zijn er veel vraagtekens die je zult hebben als het gaat om het beheren van een SQL-omgeving, dingen die je niet weet. En dus ben je op zoek naar iets om je te helpen, je door dat proces te leiden en je ook in het proces te onderwijzen. En dus is het belangrijk dat de tool die je voor dat soort beslissingen gebruikt, je enig inzicht geeft in de redenen waarom die beslissingen worden genomen, het vertelt je niet alleen: "Hé, doe dit."

Omdat ik de acterende DBA ben, ben ik uiteindelijk misschien de volwaardige DBA met de feitelijke expertise en kennis om die titel te ondersteunen. Dus dat gezegd hebbende, toen we het hadden over het zijn van een databasebeheerder - ik toon deze dia altijd eerst, omdat de DBA een aantal verschillende rollen heeft en afhankelijk van de organisatie waarmee je gaat werken, die gaan variëren van van de ene plaats naar de andere - maar meestal zul je altijd op een of andere manier verantwoordelijk zijn voor je opslag, je planning van die opslag en het begrip van anticiperen, ik zou moeten zeggen, hoeveel ruimte je nodig hebt, of het nu voor je back-ups is, of of het nu voor de databases zelf is. Je zult dat moeten begrijpen en beoordelen.

Bovendien moet je dingen kunnen begrijpen en optimaliseren wanneer dat nodig is, en terwijl je door de monitoring van de omgeving gaat, is het uiteraard belangrijk dat je wijzigingen aanbrengt zoals ze nodig zijn op basis van dingen die veranderen binnen de omgeving. zelf. Dus dingen als het aantal gebruikers, dingen als de populariteit van applicaties, de seizoensgebondenheid van een database, moeten allemaal in overweging worden genomen wanneer u uw prognoses doet. En dan, uiteraard kijkend naar andere dingen in termen van het kunnen leveren van de rapporten en de informatie die nodig is met betrekking tot het nemen van die beslissingen. In veel gevallen betekent dat vergelijkende analyse; het betekent in staat zijn om specifiek naar een bepaalde statistiek te kijken en te begrijpen wat de waarde van die statistiek in de loop van de tijd is geweest, zodat u kunt anticiperen waar deze naartoe gaat.

Dus wat veel van de tool Diagnostic Manager heeft, heeft die mogelijkheden en mensen gebruiken het elke dag om dingen te kunnen doen zoals voorspellen, en ik heb hier de definitie van capaciteitsplanning geplaatst. En het is een vrij brede en eigenlijk vrij vage definitie, wat slechts het proces is van het bepalen van de productiecapaciteit die een organisatie nodig heeft om aan de veranderende eisen voor haar producten te voldoen, en uiteindelijk is dat waar het allemaal om draait: het over het kunnen nemen van informatie die je op de een of andere manier hebt en het nemen van die informatie en het nemen van beslissingen om je vooruit te helpen naarmate je door de levenscyclus van je databases vordert. En dus zijn de soorten dingen die de reden zijn waarom mensen dit moeten doen, in de meeste gevallen uiteraard in de eerste plaats om geld te besparen. Bedrijven, dat is natuurlijk hun belangrijkste doel: geld verdienen en geld besparen. Maar tegelijkertijd betekent dat ook dat u ervoor kunt zorgen dat uw downtime geen downtime heeft. En in staat zijn om ervoor te zorgen dat u de kans op downtime verkleint, dus voorkomen dat het begint, met andere woorden, niet wachten tot het gebeurt en er vervolgens op reageren.

Naast het in staat zijn om de productiviteit van uw gebruikers in het algemeen te verhogen, is het natuurlijk de sleutel hier om ze efficiënter te maken zodat u meer zaken kunt doen, dus dit zijn dingen die de DBA of iemand die betrokken is bij voorspelling of capaciteit is planning zal door de informatie moeten moeten kunnen waden om die beslissingen te kunnen nemen. En dan, in het algemeen, zal dit duidelijk helpen om verspilling te elimineren, niet alleen verspilling in termen van geld, maar ook in termen van tijd en in termen van gewoon algemene middelen die mogelijk voor andere dingen kunnen worden gebruikt, mogelijk. Dus, in staat zijn om die verspilling te elimineren zodat je geen alternatieve kosten hebt die verbonden zijn aan de verspilling zelf.

Dus, met dat gezegd, wat zijn de soorten vragen die we krijgen, specifiek voor de persoon die een DBA is? Wanneer heb ik geen ruimte meer? Dat is een grote, niet alleen hoeveel ruimte ik nu consumeer, maar wanneer zal ik opraken, gebaseerd op de trends en de geschiedenis uit het verleden? Hetzelfde met de werkelijke exemplaren van SQL, de databases, welke servers kan ik consolideren? Ik ga wat op de VM's plaatsen, wat is logisch in termen van welke databases ik ga consolideren en op welke exemplaren van SQL moeten ze zich bevinden? Al die soorten vragen moeten beantwoord kunnen worden. Omdat in de meeste gevallen, als je een DBA bent of een DBA handelt, je het ergens in je carrière gaat consolideren. In veel gevallen zul je dat voortdurend blijven doen. Dus je moet die beslissingen snel kunnen nemen, en geen gokspellen spelen als het gaat om dat.

We hebben het gehad over knelpunten en waar ze zich vervolgens gaan voordoen. We kunnen daar opnieuw op anticiperen in plaats van te wachten tot ze gebeuren. Dus het was duidelijk dat al deze dingen het over hadden, logisch in die zin dat je in de meeste gevallen vertrouwt op historische gegevens om deze aanbevelingen te kunnen genereren, of in sommige gevallen om zelf beslissingen te kunnen formuleren, om verzin deze antwoorden. Maar het doet me denken aan, of wanneer je de radioadvertenties hoort voor iemand die effecten verkoopt of iets dergelijks, de altijd "in het verleden behaalde resultaten zijn geen indicatie voor toekomstige resultaten" en dat soort dingen. En hetzelfde geldt hier. U zult situaties hebben waarin deze voorspellingen en deze analyses mogelijk niet 100 procent kloppen. Maar als je te maken hebt met dingen die in het verleden en het bekende zijn gebeurd, en het 'wat als' kunt doen en doen met veel van dit soort vragen, waar je tegenaan loopt, is zeer waardevol en gaat het krijg je veel verder dan het spelen van het raadspel.

Dus, dit soort vragen komen duidelijk aan bod, dus hoe we veel van deze vragen behandelen met Diagnostic Manager, allereerst hebben we voorspellingsmogelijkheden, in staat om dit te doen in de database, aan de tafel en de schijf of het volume. Om niet alleen te kunnen zeggen: "Hé, was vol ruimte", maar zes maanden vanaf nu, twee jaar vanaf nu, vijf jaar vanaf nu, als ik dat budgetterend, hoeveel schijfruimte moet ik dan budgetteren voor? Dat zijn vragen die ik zal moeten stellen, en ik zal een methode moeten kunnen gebruiken om dat te doen in plaats van te raden en mijn vinger in de lucht te steken en te wachten om te zien hoe de wind waait, wat veel is van tijden, helaas, de manier waarop veel van deze beslissingen worden genomen.

Bovendien, in staat zijn om - het lijkt erop dat mijn dia daar een beetje is afgesneden - maar in staat zijn om wat hulp te bieden in de vorm van aanbevelingen. Het is dus één ding om je een dashboard vol met statistieken te kunnen laten zien en te kunnen zeggen: "OK, hier zijn alle metrieken en waar ze zijn", maar dan om wat te weten te komen over doen, op basis daarvan is nog een sprong. En in sommige gevallen zijn mensen voldoende opgeleid in de rol van DBA om die beslissingen te kunnen nemen. En dus hebben we enkele mechanismen in de tool die je daarbij kunnen helpen, die je binnen een seconde laten zien. Maar in staat zijn om niet alleen te laten zien wat de aanbeveling is, maar ook om enig inzicht te geven in waarom die aanbeveling wordt gedaan en daarnaast ook om in sommige gevallen daadwerkelijk een script te bedenken dat de oplossing van dat probleem is ook ideaal.

We gaan verder met de volgende hier, wat goed te zien is, het is gewoon algemeen gesproken tot op het metrische niveau begrijpen wat normaal is. Ik kan je niet vertellen wat niet normaal is als ik niet weet wat normaal is. En dus, het hebben van een manier om dat te meten is de sleutel en je moet rekening kunnen houden met meerdere soorten gebieden, bijvoorbeeld - of ik moet zeggen tijdframes - verschillende groepen servers, in staat zijn om dit dynamisch te doen, van een waarschuwend perspectief, met andere woorden, midden in de nacht, tijdens mijn onderhoudsvenster, verwacht ik dat mijn CPU op 80 procent draait op basis van al het onderhoud dat gaande is. Dus misschien wil ik mijn drempels hoger verhogen, gedurende die tijdspanne versus gedurende misschien midden op de dag, wanneer ik niet zoveel activiteit heb.

Dat zijn enkele dingen die duidelijk van invloed zijn op het milieu, maar dingen die je kunt toepassen op wat wordt beheerd, om je te helpen die omgeving efficiënter te beheren en het gemakkelijker te maken om dat te doen. Het andere gebied is natuurlijk in staat om alleen de rapporten en de informatie te geven om dat soort 'wat als'-vragen te kunnen beantwoorden. Als ik net een wijziging in mijn omgeving heb aangebracht, wil ik begrijpen wat die impact is geweest, zodat ik diezelfde wijziging kan toepassen op andere instanties of andere databases in mijn omgeving. Ik wil wat informatie of wat munitie kunnen hebben om die verandering met enige gemoedsrust te kunnen maken en wetende dat het een goede verandering zal zijn. Dus, in staat zijn om die vergelijkende rapportage te doen, in staat zijn om mijn instanties van SQL te rangschikken, in staat zijn om mijn databases tegen elkaar te rangschikken, om te zeggen: "Welke is mijn hoogste klant van CPU?" Of welke neemt het langst in wachttijden en dat soort dingen? Dus veel van die informatie zal ook beschikbaar zijn met de tool.

En dan, last but not least, is gewoon een algehele mogelijkheid dat je een tool nodig hebt die in staat zal zijn om elke situatie aan te pakken die op je weg komt, en wat ik daarmee bedoel is, als je een grote omgeving hebt met veel gevallen, zul je waarschijnlijk in situaties komen waarin je statistieken moet ophalen die traditioneel geen statistieken zijn die een DBA in sommige gevallen zelfs zou willen controleren, afhankelijk van die specifieke situatie. Dus, met een tool die je kunt, die uitbreidbaar is, om extra metrics toe te kunnen voegen en die metrics in dezelfde vorm en op dezelfde manier te kunnen gebruiken als je ze zou gebruiken als je out-of-the-box metriek, bijvoorbeeld. Dus, in staat zijn om rapporten uit te voeren, te kunnen waarschuwen, baseline - waar het allemaal over ging - is ook een belangrijk onderdeel van het kunnen doen van deze voorspelling en het maken van het zodat je de antwoorden krijgt die je zoekt om te kunnen maken die beslissingen, vooruit.

Nu de manier waarop Diagnostic Manager dit doet, hebben we een gecentraliseerde service, een groep services die wordt uitgevoerd, die gegevens verzamelt voor exemplaren van 2000 tot 2016. En wat we dan doen, is dat we die gegevens nemen en die in een centrale repository plaatsen en wat we goed met die gegevens kunnen doen, is natuurlijk dat we veel doen om verder inzicht te kunnen bieden. Nu, in aanvulling op dat - en een van de dingen die hier niet aan de orde zijn - hebben we ook een service die midden in de nacht draait, wat onze voorspellende analyseservice is, en dat een aantal rekenwerk doet en het helpt om te begrijpen en u helpen als een DBA of acterend DBA, om dat soort aanbevelingen te kunnen doen, om ook enig inzicht te kunnen bieden in termen van basislijnen.

Dus, wat Id graag doet, en dit is slechts een snel voorbeeld van de architectuur, het grote voordeel is dat er geen agenten of services zijn die daadwerkelijk aanwezig zijn op de instanties die u beheert. Maar wat Id graag doet, is je hier gewoon naar de applicatie brengen en je een snelle demo geven. En laat me ook gewoon uitgaan en dat laten gebeuren. Dus laat het me weten, denk ik Eric, kun je dat zien?

Eric Kavanagh: Ik heb het nu, ja.

Bullett Manale: OK, dus ik ga je door enkele van deze verschillende delen leiden waar ik het over had. En laten we in wezen beginnen met het soort dingen dat meer in de trant van dit is, iets dat u moet doen, of hier is iets dat in de toekomst een punt is en u hier enig inzicht in zou geven. En dit is in staat om echt te anticiperen - of ik zou dynamisch moeten anticiperen - op dingen terwijl ze gebeuren. In het geval van rapporten is een van de dingen die we in de tool hebben drie verschillende voorspellingsrapporten. En in het geval van bijvoorbeeld een databaseprognose, wat ik waarschijnlijk zou doen als ik gedurende een bepaalde periode op de grootte van een database zou kunnen anticiperen, en ik zal u daar slechts een paar voorbeelden van geven. Dus ik ga mijn auditdatabase gebruiken, die behoorlijk I / O-intensief is - er komen veel gegevens bij. We hebben deze, laten we eens kijken, doen deze hier, en laten we gewoon de gezondheidszorgdatabase hier ophalen.

Maar het punt is, ik zie niet alleen wat de ruimte hierop is, ik kan zeggen: "Kijk, laten we de gegevens van de laatste jaren meenemen" - en ik ga hier een beetje heen en weer gaan, ik heb niet echt een jaar aan gegevens, ik heb ongeveer twee maanden aan gegevens - maar omdat ik hier een steekproefpercentage van maanden kies, zal ik in dit geval de volgende 36 eenheden kunnen anticiperen of voorspellen omdat onze steekproefsnelheid is ingesteld op maanden - dat is een eenheid, is een maand - en dan zou ik in staat zijn om vervolgens een rapport uit te voeren om me in wezen te laten zien waar we onze toekomstige groei zouden verwachten, voor deze drie databases. En we kunnen zien dat we een variërende mate van verschil of variantie hebben tussen de drie verschillende databases, met name voor de hoeveelheid gegevens die ze historisch gebruiken.

We kunnen zien dat de gegevenspunten hier de historische gegevens vertegenwoordigen, en vervolgens de lijnen die ons de voorspelling zullen geven, samen met de cijfers om dat te ondersteunen. Dus we kunnen dat op tafelniveau doen, we kunnen dat zelfs op schijfniveau doen, waar ik kan anticiperen op hoe groot mijn schijven zullen worden, inclusief mount points. We zouden dit soort informatie kunnen voorspellen, maar nogmaals, afhankelijk van de steekproefsnelheid, kan ik opnieuw bepalen hoeveel eenheden en waar we hebben genomen wat we willen voorspellen. Merk ook op dat we verschillende soorten voorspellingstypes hebben. U krijgt dus veel opties en flexibiliteit als het gaat om het doen van de voorspelling. Dat is één ding goed doen, namelijk door u een specifieke datum te geven en te kunnen zeggen: "Hé op deze datum, dit is waar we de groei van uw gegevens zouden verwachten." Maar daarnaast kunnen we u ook voorzien van met andere inzichten die verband houden met sommige van de analyses die we tijdens de off hours uitvoeren en de service wanneer deze wordt uitgevoerd. Sommige van de dingen die het doet, is proberen te anticiperen op de dingen die waarschijnlijk zullen gebeuren, gebaseerd op de geschiedenis van wanneer dingen in het verleden plaatsvonden.

We kunnen hier dus eigenlijk zien dat een voorspelling ons enig inzicht geeft in de kans dat we de hele avond problemen hebben op basis van dingen die opnieuw in het verleden zijn gebeurd. Dus dit is duidelijk geweldig, vooral als ik geen DBA ben, kan ik naar deze dingen kijken, maar wat nog beter is als ik geen DBA ben, is dit tabblad Analyse. Dus voordat dit hier in de tool was, zouden we het product doorgeven aan mensen en ze zouden zijn: "Dat is geweldig, ik zie al deze cijfers, ik zie alles, maar ik weet niet wat ik moet doen" (lacht) "als een resultaat daarvan. ”En dus hebben we hier een betere manier om te begrijpen, als ik actie ga ondernemen om te helpen met de prestaties, als ik actie ga ondernemen om zelfs te helpen met de gezondheid van mijn omgeving, in staat zijn om een ​​gerangschikte manier te hebben om die aanbevelingen te geven, evenals nuttige tips in informatie om meer te leren over die aanbevelingen en zelfs externe links te hebben naar sommige van die gegevens, die me zullen tonen en me naar de redenen zullen brengen waarom deze aanbevelingen worden gedaan.

En in veel gevallen, in staat zijn om een ​​script te bieden dat, zoals ik al zei, de oplossing van deze problemen zou automatiseren. Nu, een deel van wat we hier met deze analyse deden - en ik laat je zien wanneer ik binnen ga om de eigenschappen van deze instantie te configureren, en ik ga naar de analyseconfiguratie-sectie - we hebben veel verschillende categorieën die hier worden vermeld, en deels hebben we indexoptimalisatie en query-optimalisatie. We evalueerden dus niet alleen de statistieken zelf, en dergelijke, maar ook dingen zoals de workloads en de indexen. In het geval hier, doe eigenlijk een aantal aanvullende hypothetische indexanalyses. Dus het is een van die situaties waarin ik niet wil, in veel gevallen wil ik geen index toevoegen als dat niet nodig is. Maar op een gegeven moment is er een soort omslagpunt, waar ik zeg: "Wel, de tabel is zo groot geworden of het soort vragen dat binnen de werklast loopt, is nu logisch om een ​​index toe te voegen. Maar het zou misschien zes weken eerder niet logisch zijn geweest. ”Dus dit stelt je in staat om dynamisch dat inzicht te krijgen over dingen die waarschijnlijk, zoals ik al zei, de prestaties zullen verbeteren op basis van wat er in de omgeving gebeurt, wat er gebeurt binnen de workloads, en dat soort dingen doen.

En dus krijg je hier veel goede informatie, evenals de mogelijkheid om deze dingen automatisch te optimaliseren. Dus dat is een ander gebied waar we zouden kunnen helpen, in termen van wat we voorspellende analyse noemen. Nu, naast dat, zou ik moeten zeggen, we hebben ook andere gebieden waarvan ik denk dat ze zich in het algemeen gewoon lenen om u te helpen beslissingen te nemen. En als we het hebben over het nemen van beslissingen, nogmaals, in staat zijn om naar historische gegevens te kijken, geef ons wat inzicht om ons te brengen waar we moeten zijn om die prestaties te verbeteren.

Nu, een van de dingen die we kunnen doen, is dat we een basisvisualisatie hebben waarmee we selectief kunnen kiezen welke statistiek we willen - en laat me hier een fatsoenlijke vinden - ik ga naar SQL CPU-gebruik, maar het punt is dat je kunt gaan gedurende vele weken om deze foto's te schilderen zodat u kunt zien wanneer uw uitschieters zijn, om in het algemeen te zien waar die waarde valt binnen de tijdsperioden waarin we gegevens hebben verzameld. En dan merk je bovendien dat wanneer we naar het eigenlijke exemplaar gaan, we de mogelijkheid hebben om onze basislijnen te configureren. En de basislijnen zijn echt een belangrijk onderdeel om dingen te kunnen automatiseren en om op de hoogte te kunnen worden gehouden. En de uitdaging, zoals de meeste DBA's je vertellen, is dat je omgeving niet altijd hetzelfde is, in de loop van de dag, versus de avond en wat niet zoals we eerder in het voorbeeld met de onderhoudsperioden vermeldden, toen we hoge CPU-niveaus hebben of wat dan ook.

Dus, in het geval hier, met deze werkelijke basislijnen, kunnen we meerdere basislijnen hebben, dus ik kan bijvoorbeeld een basislijn hebben, dat is tijdens mijn onderhoudsuren. Maar ik kon net zo gemakkelijk een basislijn maken voor mijn productie-uren. En het punt om dat te doen is wanneer we in een exemplaar van SQL ingaan en we deze meerdere basislijnen hebben, dan zouden we kunnen anticiperen en een soort automatisering, een soort remediëring of gewoon alarmering in het algemeen kunnen uitvoeren, anders specifiek voor die tijdvensters. Dus, een van de dingen die je hier zult zien, is dat deze basislijnen die we genereren de historische gegevens gebruiken om die analyse te bieden, maar nog belangrijker, ik kan deze drempels statisch wijzigen, maar ik kan deze ook dynamisch automatiseren. Dus, als het onderhoudsvenster, of ik zou moeten zeggen dat het onderhouds-basislijnvenster verschijnt, zouden deze drempels automatisch schakelen specifiek voor de belastingen die ik gedurende dat tijdsvenster tegenkom, versus misschien in het midden van de dag wanneer mijn belastingen niet zo zijn veel, wanneer de workloads niet zo impactvol zijn.

Dus dat is iets anders om in gedachten te houden, in termen van de basislijn. Het is duidelijk dat deze echt nuttig voor je zullen zijn, in termen van ook begrijpen wat normaal is en in staat zijn om ook te begrijpen, in te schakelen wanneer je ook te weinig middelen hebt. Nu, het andere soort ding dat we in de tool hebben, dat gaat je helpen beslissingen te nemen, naast de baselining en in staat zijn om waarschuwingen rond die basislijnen en de drempels die je dynamisch creëert, in te stellen, is zoals ik al eerder zei, gewoon in staat zijn om een ​​groot aantal rapporten uit te voeren die me helpen vragen te beantwoorden over wat er aan de hand is.

Dus, als een voorbeeld, als ik 150 exemplaren had die ik beheer - in mijn geval niet, dus moeten we het doen alsof-spel hier spelen - maar als ik al mijn productie-exemplaren had en ik moest begrijpen waar is het gebied dat ik aandacht nodig hebben, met andere woorden, als ik maar een beperkte hoeveelheid tijd heb om een ​​bepaald type administratie uit te voeren om de prestaties te verbeteren, wil ik me concentreren op de belangrijkste gebieden. En dus, met dat gezegd, zou ik kunnen zeggen: "Gebaseerd op die omgeving, rangschik mijn instanties ten opzichte van elkaar en geef me die rangorde per contentiepijp." Dus of het schijfgebruik, geheugengebruik, of het wacht, of het nu de responstijd is, ik kan deze instanties tegen elkaar correleren - of ik zou moeten rangschikken. Het is duidelijk dat het exemplaar bovenaan elke lijst staat, als het hetzelfde exemplaar is, dat is waarschijnlijk iets waar ik me echt op wil concentreren, omdat het duidelijk weer bovenaan de lijst staat.

U hebt dus veel rapporten in de tool die u helpen bij het rangschikken van de omgeving op instantieniveau; je kunt dit ook op databaseniveau doen, waar ik mijn databases tegen elkaar kan rangschikken. In het bijzonder voor drempels en gebieden die ik kan instellen, kan ik hier zelfs jokertekens instellen als ik dat wil, om me alleen op bepaalde databases te concentreren, maar het punt is dat ik mijn databases op dezelfde manier kan vergelijken. Wat betreft andere soorten vergelijkende analyses en de grote in deze tool, is ook de basisanalyse die we hebben. Dus als je hier naar de serviceweergave scrolt, zie je dat er een basisstatistiekenrapport is. Nu gaat dit rapport ons natuurlijk helpen om niet alleen te begrijpen wat de metrische waarden zijn, maar voor een specifiek geval zou ik kunnen uitgaan en voor elk van deze metrieken de basislijnen voor deze metrieken kunnen bekijken.

Dus wat het ook is, als een percentage of wat ik ook maar zou kunnen zeggen: "Laten we de basislijn hiervoor uitbreken in de afgelopen 30 dagen", in welk geval het me de werkelijke waarden ten opzichte van de basislijn laat zien en Ik zou natuurlijk een aantal beslissingen kunnen nemen met behulp van die informatie, dus dit is een van die situaties, waar het afhangt van welke vraag het is, dat je op dat moment stelt. Maar dit zal je natuurlijk voor veel van die vragen helpen. Ik wou dat ik kon zeggen dat we één rapport hadden dat het allemaal doet, en het lijkt een beetje op het gemakkelijke rapport, waar je op drukt en op de knop drukt en het beantwoordt gewoon elke 'wat als' vraag die je ooit zou kunnen beantwoorden. Maar de realiteit is dat je veel attributen en veel opties zult hebben om uit deze pull-downs te kunnen kiezen om die “what if” -type vragen te kunnen formuleren waarnaar je op zoek bent.

Veel van deze rapporten zijn dus gericht op het kunnen beantwoorden van dat soort vragen. En dus is het ook heel belangrijk dat deze rapporten en bovendien alle dingen die we je al in de tool hebben laten zien, zoals ik al eerder zei, de flexibiliteit hebben om nieuwe statistieken te integreren, te beheren, zelfs in staat zijn om tellers te maken, of SQL-vragen die zijn opgenomen in uw polling-intervallen, om me te helpen deze vragen te beantwoorden, dat u misschien dat soort dingen uit de doos kunt verwachten die we zouden volgen. En je zou dan in staat zijn om dezelfde dingen te doen die ik je net heb laten zien: baseline, rapporten uitvoeren en rapporten maken op basis van die statistiek, en in staat zijn om te antwoorden en veel van deze verschillende soorten dingen te doen die ik je hier laat zien.

Nu, in aanvulling op dat - en een van de dingen waar we de laatste tijd natuurlijk nogal wat tegenaan lopen - was het eerst, iedereen flippen of overschakelen naar VM's. En nu hebben we veel mensen die op weg zijn naar de cloud. En er zijn veel vragen die rond dit soort dingen opkomen. Heeft het zin om naar de cloud te verhuizen? Ga ik geld besparen door naar de cloud te verhuizen? Als ik deze dingen op een VM zou zetten, op een machine met gedeelde bronnen, hoeveel geld kan ik dan besparen? Dat soort vragen komen uiteraard ook aan de orde. Dus, veel van dat soort dingen houden in gedachten, met Diagnostic Manager kunnen we virtuele omgevingen van zowel VMware als Hyper-V toevoegen en gebruiken. We kunnen ook instanties toevoegen die zich in de cloud bevinden, dus uw omgevingen zoals Azure DB, of zelfs RDS, kunnen we ook statistieken uit die omgevingen halen.

Er is dus veel flexibiliteit en veel in staat om die vragen te beantwoorden met betrekking tot die andere soorten omgevingen waar we mensen naartoe zien gaan. En er zijn nog veel vragen rond dit soort dingen, en zoals we mensen zien consolideren die omgevingen moeten ze die vragen ook kunnen beantwoorden. Dus, dat is een redelijk goed overzicht, zeg maar, van Diagnostic Manager, wat dit onderwerp betreft. Ik weet dat het onderwerp business intelligence ter sprake kwam en we hebben ook een tool voor business intelligence waar we het vandaag niet over hadden, maar het zal je ook inzicht geven in het beantwoorden van dit soort vragen met betrekking tot je kubussen en al die verschillende soorten dingen ook. Maar hopelijk is dit een goed overzicht geweest, althans in termen van hoe dit product kan helpen bij het kunnen formuleren van een goed plan.

Eric Kavanagh: Oké, goed spul. Ja, ik gooi het weg voor Rick, als hij er nog is. Rick, vragen van jou?

Rick Sherman: Ja, dus eerst, dit is geweldig, ik vind het leuk. Ik hou vooral van de uitbreiding naar VM's en clouds. Ik zie veel app-ontwikkelaars denken dat als het in de cloud staat, ze het niet hoeven te tunen. Zo-

Bullett Manale: Juist, we moeten er nog voor betalen, toch? Je moet nog steeds betalen voor wat het ook is dat mensen in de cloud zetten, dus als het slecht draait, of als het veel CPU-cycli veroorzaakt, is het meer geld dat je moet betalen, dus het is niet nodig, je moet nog steeds meten dit spul, absoluut.

Rick Sherman: Ja, ik heb veel slechte ontwerpen in de cloud gezien. Ik wilde vragen of dit product ook zou worden gebruikt - ik weet dat u het BI-product noemde en u hebt tal van andere producten die op elkaar inwerken - maar zou u in deze tool gaan kijken naar SQL-prestaties, individuele vragen? Of zouden het andere hulpmiddelen zijn die daarvoor zouden worden gebruikt?

Bullett Manale: Nee, dit zou absoluut. Dat is een van de dingen die ik niet heb behandeld en die ik ook bedoelde, het gedeelte met vragen. We hebben veel verschillende manieren om de prestaties van een query te identificeren, of het nu gerelateerd is aan, specifiek om te wachten zoals we in deze weergave hier zien, of of het gerelateerd is aan het resource-verbruik van query's in het algemeen, er is een heel aantal manieren waarop we de query kunnen analyseren prestatie. Of het nu gaat om de duur, CPU, I / O en nogmaals, we kunnen ook kijken naar de workloads zelf om enig inzicht te geven. We kunnen de aanbevelingen in de analysesectie geven en we hebben ook een webversie die informatie biedt over de vragen zelf. Dus ik kan aanbevelingen krijgen over ontbrekende indexen en de mogelijkheid om het uitvoeringsplan en al dat soort dingen te bekijken; het is ook een mogelijkheid. Dus, absoluut, we kunnen zoekopdrachten op zeven manieren tot zondag diagnosticeren (lacht) en dat inzicht kunnen bieden in termen van het aantal executies, of het nu gaat om het verbruik van hulpbronnen, de wachttijden, de duur, al dat goede spul.

Rick Sherman: OK, geweldig. En wat is dan de belasting van de instanties zelf met al deze monitoring?

Bullett Manale: Het is een goede vraag. De uitdaging bij het beantwoorden van die vraag is, hangt ervan af, het is net als iets anders. Veel van wat onze tool te bieden heeft, het biedt flexibiliteit en een deel van die flexibiliteit is dat je het vertelt wat te verzamelen en wat niet te verzamelen. Dus met de vragen zelf hoef ik bijvoorbeeld geen wachtinformatie te verzamelen, of ik kan het. Ik kan informatie verzamelen met betrekking tot vragen die een tijdsduur overschrijden, van uitvoering. Als een voorbeeld hiervan, als ik naar de configureerquerymonitor zou gaan en ik zou zeggen: "Laten we deze waarde naar nul veranderen", is de realiteit dat de tool in feite elke query die wordt uitgevoerd laat verzamelen en dat is echt niet de geest van waarom dat daar is, maar over het algemeen als ik een volledige steekproef van gegevens voor alle vragen wilde verstrekken, zou ik dat kunnen doen.

Het is dus heel afhankelijk van wat je instellingen over het algemeen out of the box zijn. Het is overal van ongeveer 1-3 procent overhead, maar er zijn andere voorwaarden die van toepassing zijn. Het hangt ook af van hoeveel poortquery's op uw omgeving worden uitgevoerd, toch? Het hangt ook af van de methode voor het verzamelen van die query's en welke versie van SQL het is. Dus, bijvoorbeeld, SQL Server 2005, zou niet in staat zijn om uit uitgebreide gebeurtenissen te halen, terwijl we dus uit een trace zouden halen om dat te doen. Het zou dus een beetje anders zijn als het gaat om de manier waarop we die gegevens zouden verzamelen, maar dat zei, zoals ik al zei, al sinds ongeveer 2004 met dit product. Het bestaat al heel lang, we hebben duizenden klanten, dus het laatste wat we willen doen is een tool voor prestatiebewaking hebben die prestatieproblemen veroorzaakt (lacht). En dus proberen we daar zoveel mogelijk uit de buurt te blijven, maar over het algemeen is zo'n 1-3 procent een goede vuistregel.

Rick Sherman: OK, en dat is behoorlijk laag, dus dat is geweldig.

Eric Kavanagh: Is goed. Robin, heb je nog vragen?

Robin Bloor: Het spijt me, ik was op mute. Je hebt een mogelijkheid voor meerdere databases, en ik ben geïnteresseerd in hoe je naar meerdere databases kunt kijken en daarom kun je weten dat een grotere bronnenbasis mogelijk is verdeeld over verschillende virtuele machines, enzovoort. Ik ben geïnteresseerd in hoe mensen dat daadwerkelijk gebruiken. Ik ben geïnteresseerd in wat de klanten daarmee doen. Omdat dat naar mij lijkt, wel, zeker, toen ik aan het rommelen was met databases, iets dat ik nooit bij de hand had. En ik zou slechts één instantie op enig moment op een zinvolle manier beschouwen. Dus, hoe gebruiken mensen dit?

Bullett Manale: Over het algemeen heb je het over het algemeen alleen over de tool zelf? Hoe gebruiken ze het? Ik bedoel, over het algemeen gaat het erom een ​​centraal punt van aanwezigheid van de omgeving te hebben. Gemoedsrust en wetende dat als ze naar een scherm staren en ze groen zien, ze weten dat alles goed is. Het is wanneer er problemen optreden en natuurlijk de meeste gevallen vanuit het perspectief van een DBA, vaak komen die problemen voor wanneer ze voor de console staan, dus in staat zijn om op de hoogte te worden gesteld zodra het probleem zich voordoet. Maar daarnaast, in staat zijn om te begrijpen wanneer het probleem zich voordoet, in staat zijn om tot de kern van de informatie te komen die hen enige opheldering biedt in termen van waarom het gebeurt. En dat is volgens mij het grootste deel: proactief zijn, niet reactief zijn.

De meeste DBA's waarmee ik praat - en ik weet het niet, het is een goed percentage daarvan - bevinden zich helaas nog steeds in de reactieve omgeving; ze wachten tot een consument hen benadert om hen te vertellen dat er een probleem is. En dus zien we veel mensen proberen daar vanaf te breken en ik denk dat dat een groot deel van de reden is waarom mensen deze tool leuk vinden, is dat het hen helpt proactief te zijn, maar het geeft hen ook inzicht in wat er aan de hand is , wat is het probleem, maar in veel gevallen, wat we op zijn minst vinden - en misschien zijn het alleen de DBA's die ons dit vertellen - maar de DBA's, de perceptie is altijd hun probleem, zelfs als het de applicatie-ontwikkelaar is die de applicatie heeft geschreven die het niet goed hebben geschreven, het zijn degenen die de schuld gaan nemen, omdat ze die applicatie meenemen naar hun systemen of servers en wanneer de prestaties slecht zijn, wijst iedereen naar de DBA: "Hé, het is jouw schuld."

Dus deze tool zal heel vaak worden gebruikt om te helpen de DBA te verdedigen om te zeggen: "Hé, dit is waar het probleem ligt en ik niet." (Lacht) We moeten verbeter dit, of het nu gaat om het veranderen van de vragen of wat het ook is. In sommige gevallen zal het in hun emmer vallen in termen van hun verantwoordelijkheid, maar op zijn minst de tool hebben om hen te helpen dat te begrijpen en dat te weten, en het op tijd doen is natuurlijk de ideale aanpak.

Robin Bloor: Ja, de meeste sites waarmee ik bekend ben, maar het is al een tijdje geleden dat ik naar verschillende sites met meerdere databases keek, maar vooral wat ik altijd vond was dat er DBA's waren die zich concentreerden op een handvol databases. En dat zouden de databases zijn, dat als ze ooit zouden uitvallen, het een echt groot probleem voor het bedrijf zou zijn, enzovoort enzovoort. En de andere, ze verzamelen gewoon zo nu en dan statistieken om te zien dat de ruimte op is en ze er nooit naar zouden kijken. En terwijl je de demo aan het doen was, keek ik hiernaar en ik dacht goed, op de een of andere manier, je breidt je uit, gewoon door zoiets te bieden voor databases waar vaak niemand om gaf, omdat ze datagroei hebben , ze hebben soms ook applicatiegroei. Je breidt DBA-dekking op een behoorlijk dramatische manier uit. Dus daar gaat het eigenlijk om, is het dat je met een set van tools zo ongeveer een DBA-service kunt geven aan elke database die zich in het bedrijfsnetwerk bevindt?

Bullett Manale: Natuurlijk, ik bedoel, de uitdaging is dat, zoals je vrij welsprekend zei, er een aantal databases is waar de DBA's om geven en dan is er een aantal waar ze niet zoveel om geven. En de manier waarop dit specifieke product, de manier waarop het in licentie wordt gegeven, per geval is. Dus er is, denk ik, zou je zeggen, een drempel voor wanneer mensen beslissen: "Hé, dit is geen kritisch genoeg exemplaar dat ik het met deze tool wil beheren." Dat gezegd hebbende, er zijn andere tools die we hebben die meer zijn , Denk ik, rekening houdend met die minder belangrijke voorbeelden van SQL. Een van hen zou zijn als de Inventory Manager, waar we lichte gezondheidscontroles uitvoeren op de instanties, maar daarnaast doen we ook ontdekkingen, dus we identificeren nieuwe instanties die online zijn gebracht en vanaf dat moment, als een DBA kan ik zeggen: “Oké, hier is een nieuw exemplaar van SQL, is het nu Express? Is het de gratis versie of een enterprise-versie? ”Dat is waarschijnlijk een vraag die ik mezelf wil stellen, maar ten tweede, hoe belangrijk is die instantie voor mij? Als het niet zo belangrijk is, zou ik deze tool kunnen laten uitvoeren en uitvoeren, generiek, wat ik generieke gezondheidscontroles zou noemen in die zin dat het de elementaire soorten dingen zijn waar ik om geef als een DBA: loopt de schijf vol? Reageert de server op problemen? De belangrijkste dingen, toch?

Terwijl met Diagnostic Manager de tool die ik je net liet zien, naar het queryniveau gaat, naar de aanbeveling van indexen, kijkend naar het uitvoeringsplan en al dat goede spul, terwijl dit voornamelijk is gericht over wie wat bezit, wat is het dat ik bezit en wie er verantwoordelijk voor is? Welke servicepacks en hotfixes heb ik? En werken mijn servers met de belangrijkste ingrediënten van wat ik zou beschouwen als een gezond exemplaar van SQL? Dus om je vraag te beantwoorden, is er een beetje een mix. Wanneer we mensen naar deze tool laten kijken, kijken ze meestal naar een meer kritieke set instanties. Dat gezegd hebbende, we hebben een aantal mensen die elke instantie die ze hebben kopen en beheren, dus het hangt er gewoon vanaf. Maar ik zeg je, over het algemeen, is er zeker een drempel voor die mensen die hun omgeving belangrijk genoeg vinden om een ​​tool als deze te hebben om die instanties te beheren.

Robin Bloor: Oké, nog een vraag voordat ik het aan Eric geef. De indruk die je krijgt, alleen al door naar de industrie te kijken, is dat databases nog steeds een leven hebben, maar dat alle gegevens in al die gegevensstromen stromen, enzovoort. Dat is de hype, echt, en de hype weerspiegelt nooit de realiteit, dus ben ik geïnteresseerd in wat voor realiteit je daar waarneemt? Zijn de belangrijke databases binnen een organisatie, ervaren ze de traditionele datagroei, die ik vroeger als 10 procent per jaar beschouwde? Of groeien ze meer dan dat? Maakt big data deze databases ballon? Wat is de foto die je ziet?

Bullett Manale: Ik denk dat in veel gevallen een deel van de gegevens werd verplaatst naar die andere segmenten waar het logischer is, wanneer er andere technologieën beschikbaar komen. Sinds kort, een aantal van de grotere data-dingen. Maar deze databases, zou ik zeggen, zijn in veel gevallen moeilijk te generaliseren omdat iedereen een beetje anders is. Over het algemeen zie ik echter enige divergentie. Ik zie, zoals ik al zei, mensen in veel gevallen naar de elastische modellen gaan, omdat ze de middelen willen vergroten en niet zozeer op andere gebieden. Sommige mensen gaan naar de big data. Maar het is moeilijk om een ​​idee te krijgen van, zeg je, de perceptie, omdat in het algemeen de mensen met wie ik praat allemaal de traditionele databases hebben en dit op een SQL Server-omgeving gebruiken.

Dat gezegd hebbende, zeg ik wat betreft SQL zelf, ik denk nog steeds dat het marktaandeel wint. En ik denk dat er veel mensen zijn die nog steeds op weg zijn naar SQL vanuit andere plaatsen zoals Oracle, omdat het goedkoper is en duidelijk lijkt te zijn, naarmate SQL-versies geavanceerder worden - en je ziet dit met de meer recente dingen die gaan verder met SQL, in termen van codering en alle andere mogelijkheden die het tot een omgeving of een databaseplatform maken - dat is natuurlijk zeer missiekritisch, denk ik. Dus ik denk dat we dat ook zagen. Waar je een verschuiving ziet, gebeurt dit nog steeds. Ik bedoel, het gebeurde 10 jaar geleden, het gebeurt volgens mij nog steeds in termen van SQL Server, waar de omgevingen groeien en het marktaandeel groeit.

Robin Bloor: OK, Eric, ik neem aan dat het publiek een vraag of twee heeft?

Eric Kavanagh: Ja, laat me er een snel naar je overgooien. Het is eigenlijk een vrij goede vraag. Een van de aanwezigen vraagt, zal deze tool me vertellen of een tabel mogelijk een index nodig heeft om de zoekopdracht te versnellen? Zo ja, kunt u een voorbeeld tonen?

Bullett Manale: Ja, dus ik weet niet of ik er een heb voor een specifieke toevoeging van een index, maar je kunt hier zien dat we hier fragmentatieaanbevelingen hebben. Ik geloof ook gewoon dat we het net hadden en dit was onderdeel van de Diagnostic Manager die de webgebaseerde versie aanbiedt, waar het me vertelt dat ik een ontbrekende index heb. En we kunnen die aanbevelingen bekijken en ons vertellen wat de potentiële winst daarvan is door die informatie te indexeren. Het andere dat ik net moet vermelden, is dat wanneer we de aanbevelingen doen, voor veel van deze, het script ervoor zal worden gebouwd. Dat is geen goed voorbeeld, maar je zou wel kunnen zien in welke situaties een index - ofwel een dubbele index, of de toevoeging van een index - de prestaties zou verbeteren, en zoals ik al eerder zei, doen we veel dat door middel van hypothetische indexanalyse. Het helpt dus echt om de werkdruk te begrijpen, om dat op de aanbeveling toe te kunnen passen.

Eric Kavanagh: Dat is geweldig spul, en dit geeft me een goed overzicht van de laatste opmerkingen hier. Robin en ik en Rick hebben ook al vele jaren gehoord dat er over zelfafstemmende databases wordt gesproken. Het is een zelfafstemmende database! Het enige dat ik je kan vertellen is: geloof ze niet.

Bullett Manale: Geloof de hype niet.

Eric Kavanagh: Er kunnen enkele kleine kleine dingen zijn die dynamisch worden gedaan, maar zelfs dat, wil je het misschien eens bekijken en ervoor zorgen dat het niet iets doet wat je niet wilt. Dus hadden we al geruime tijd tools zoals deze nodig om te begrijpen wat er op databaseniveau gebeurt en zoals Robin zei, datameren zijn fascinerende concepten, maar er is waarschijnlijk ongeveer evenveel kans dat ze het overnemen als er is binnenkort een monster van Loch Ness. Dus, ik zou alleen nog maar willen zeggen, de echte wereld heeft veel databasetechnologie, we hebben mensen, DBA's, nodig om naar dit spul te kijken en het te synthetiseren. Je weet het, je moet weten wat je doet om dit spul te laten werken. Maar je hebt de tools nodig om je de informatie te geven om te weten wat je doet. Het komt er dus op neer dat DBA's het prima zullen doen.

En grote dank aan Bullett Manale en onze vrienden bij IDERA. En natuurlijk, Rick Sherman en Robin Bloor. We archiveren al deze webcasts, dus hop online op insideanalysis.com of op onze partnersite www.techopedia.com voor meer informatie daarover.

En daarmee, groet u vaarwel, mensen. Nogmaals bedankt, tot de volgende keer. Wees voorzichtig. Tot ziens.