Door Techopedia Staff, 19 april 2017
Afhaalmaaltijd: gastheer Eric Kavanagh bespreekt voorspellingen met Dr. Robin Bloor, Rick Sherman en Bullett Manale van IDERA.
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 problemen besparen met optimale voorspellingen." Natuurlijk heb ik het eerste deel van de titel daar gemist: "De beste plannen". praat daar altijd over 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 in jouw organisatie gaat gebeuren. Hoe gaat u uw gebruikers tevreden houden, wat ze ook doen? Als ze analyses doen, als ze echt werk doen, worden ze geconfronteerd met echte klanten met transactionele systemen, wat het geval ook is, je wilt begrijpen hoe je systemen werken en wat er aan de hand is, en dat is wat we ' Ik zal het vandaag hebben. Het is een beetje grappig omdat voorspellen niet iets is dat ik graag doe, omdat ik bijgelovig ben, 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 overhandig ik het aan Robin en herinner ik mensen eraan: stel vragen, wees niet verlegen, we houden van goede vragen, we stellen ze vandaag aan onze presentatoren en anderen. En daarmee, Robin, haal het weg.
Robin Bloor: OK, nou, ik sta in de pole-position zoals ze zeggen, ik dacht dat ik vandaag een SQL-verhaal zou vertellen, omdat dit de achtergrond is voor wat de discussie aan de gang is en het onvermijdelijk niet zal botsen met omdat Rick zich hier niet op concentreert en niet zal botsen met wat Rick te zeggen heeft. Dus, het SQL-verhaal, er zijn een aantal interessante dingen aan SQL omdat het zo dominant is. Kijk, dat is een typfout, SQL is een verklarende 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 hiervan af, en maakt zich zelfs zorgen over - vraag gewoon om wat u maar 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 u, 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. Eén SQL-query is dus niet noodzakelijkerwijs de beste manier om gegevens te vragen, en databases zullen heel anders reageren volgens de SQL die u erin opgeeft.
En dus beïnvloedt SQL de prestaties, dus mensen die SQL gebruiken, dat geldt ook voor hen, het geldt ook voor de SQL-programmeurs die SQL gebruiken en ze denken zelfs nog minder na over de impact die ze zullen hebben, omdat het grootste deel van hun focus ligt eigenlijk op het manipuleren van gegevens en niet op het verkrijgen, plaatsen van gegevens. En hetzelfde geldt ook voor BI-tools, ik heb de SQL gezien die, als je wilt, BI-tools uit verschillende databases haalt en het moet gezegd worden, dat veel daarvan is, nou, ik zou t schrijf dergelijke SQL-vragen. Het is iemand die, als je wilt, een kleine motor heeft gemaakt die, ongeacht de parameters, SQL weggooit en nogmaals, dat SQL niet noodzakelijkerwijs efficiënte SQL is.
Toen dacht ik dat ik de impedantie-mismatch zou noemen, de gegevens die programmeurs gebruiken zijn anders dan de gegevens zoals ze sorteren. 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 is er 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 te vragen wat je allemaal in één keer wilt. En het is een beetje de moeite waard om dat te weten, want er zijn een aantal 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 netwerkoverheadkosten 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 we gaan ermee 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 we heel snel zullen doornemen, 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 praten nog steeds, zoals Robin sprak, over SQL. En in feite, zelfs als we op het Hadoop-platform kijken, is Hive en Spark SQL - die mijn zoon, die 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 data 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 er is dus een enorme vraag en toename in het gebruik van databases, met name relationele databases op de markt.
Nu hebben we de vraag, er komen enorme hoeveelheden gegevens aan. 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 zijn dat mensen die DBA-functies hebben, maar daar zullen we het zo over hebben - 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, als we het hebben 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 database structuur zelf. We hebben dus veel slecht ontwerp.
Nu heb ik het niet over de leveranciers van commerciële bedrijfstoepassingen; ze hebben meestal ER-modellen of uitgebreide ER-modellen. Waar ik het over heb, is dat er in elk bedrijf veel meer bedrijfsprocessen en applicaties worden gebouwd door applicatie-ontwikkelaars - 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 er 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 noodzakelijkerwijs 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. We zijn verantwoordelijk voor het ontwerpen van de database, wat prima is, als het iemand is die ervaring heeft. Maar over het algemeen zijn de DBA's applicatie-ontwikkelaars, ze nemen die rol vaak aan als een part-time deel van hun werk, ze hebben er geen formele training in en opnieuw, ze ontwerpen het voor hun einddoelen, ze zijn niet ontwerpen 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 accidentele DBA's, mensen die de formele training niet 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 onopzettelijke DBA bent, weet je niet wat je niet weet.
Ik denk dat ik een deel van de zin daar ben vergeten, zodat ze vaak gewoon niet 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 huisdierliefhebbers 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 data-integratie gebruiken of een dure BI-tool, die ze vaak echt alleen gebruiken 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, zodat ze niet alleen moeten kijken naar hoe deze tabel is gestructureerd, hoe het in het bijzonder is gemodelleerd, maar hoe het 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 ze 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 voor elkaar 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 je problemen probeert te debuggen, probeer je natuurlijk echt te kijken naar wat de echte knelpunten zijn - niet noodzakelijkerwijs hoe je alles kunt afstemmen, maar hoe kom je af van en verplaats je de prestaties naar de wachttijden en doorvoer - waar u ook naar 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 kijken naar de databasebewerkingen zelf; 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 nu ER-model of dimensionaal model is, maar het is gestructureerd - al die dingen hebben een impact op de prestaties, vooral in de verschillende contexten 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 - waar ze ook op draaien - ook kijken naar de impact die deze applicaties en deze databases hebben in die context, al deze hebben 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 te achterhalen 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 context 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 zal impact op de database, 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 op te lossen. 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 omhoog 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 dat hij altijd zeg: "Ik vind het geweldig als een plan samenkomt", en ik denk dat als je het hebt over met name de SQL Server, dat is waar we ons op richten, dat is het product waar we het vandaag over hebben, SQL Diagnostic Manager, het is absoluut een van die dingen die u 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 er iets opraakt met middelen, wanneer je opraakt met middelen, 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 daar gaan we het vandaag over hebben. 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, zullen er veel vraagtekens zijn 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, kan ik uiteindelijk de volwaardige DBA zijn met de feitelijke expertise en kennis om die titel te ondersteunen. Dus, dat gezegd hebbende, als we het hebben over het zijn van een databasebeheerder, laat ik deze dia altijd eerst zien, omdat de DBA een aantal verschillende rollen heeft en afhankelijk van de organisatie waarmee je samenwerkt, die zullen van de ene plaats naar de andere variëren - maar meestal ben je altijd op een of andere manier verantwoordelijk voor je opslag, je planning van die opslag en het begrip van anticiperen, zou ik moeten zeggen, hoeveel ruimte je gaat nodig hebben, of het nu voor uw back-ups is of voor de databases zelf. Je zult dat moeten begrijpen en beoordelen.
Bovendien moet je dingen kunnen begrijpen en optimaliseren wanneer dat nodig is, en terwijl je de monitoring van de omgeving doorloopt, is het natuurlijk belangrijk dat je wijzigingen aanbrengt omdat ze nodig zijn op basis van dingen die verandering 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 bij het maken van uw prognoses. 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 dat je specifiek naar een bepaalde statistiek kunt kijken en kunt begrijpen wat de waarde van die statistiek in de loop van de tijd is geweest, zodat je kunt anticiperen waar het naartoe gaat.
Dus veel van de tool Diagnostic Manager heeft die mogelijkheden en mensen gebruiken het elke dag om dingen als forecasting te kunnen doen, en ik heb hier de definitie van capaciteitsplanning geplaatst. En het is een vrij brede en eigenlijk vrij vage definitie, wat gewoon 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 is 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 u geen opportuniteitskosten heeft die aan de verspilling zelf zijn gebonden.
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 verbruik, maar wanneer ga 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 welke databases ik ga consolideren en op welke exemplaren van SQL moeten ze zich bevinden? Al die soorten vragen moeten beantwoord kunnen worden. Want in de meeste gevallen, als je een DBA bent of een DBA handelt, ga je het ergens in je carrière 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 zullen voordoen. We kunnen daarop opnieuw anticiperen in plaats van te wachten tot ze zich voordoen. Dus het is duidelijk dat al deze dingen waar we het over hebben logisch zijn, in de 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 deze antwoorden te kunnen bedenken. Maar het doet me denken aan, of wanneer je de radioadvertenties hoort voor iemand die effecten verkoopt of iets dergelijks, het is altijd "prestaties uit het verleden 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 kunnen nemen en doen van het "wat als" met veel van dit soort vragen, waar je tegenaan loopt, is zeer waardevol en het gaat je veel verder brengen dan het spelen van het raadspel.
Dus dit soort vragen zullen uiteraard aan de orde komen, dus hoe we veel van deze vragen behandelen met Diagnostic Manager, in de eerste plaats hebben we voorspellingsmogelijkheden, dit kunnen doen in de database, aan de tafel ook als de schijf of het volume. Om niet alleen te kunnen zeggen: "Hé, we zijn vol met ruimte", maar over zes maanden, over twee jaar, over vijf jaar, als ik dat budgetter, hoeveel schijfruimte ga ik dan moeten budgetteren? Dat zijn vragen die ik moet stellen, en ik moet een methode 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 welke kant de wind waait, wat vaak gebeurt, 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 statistieken en waar ze zich bevinden", maar dan om wat te kunnen maken of enig begrip te hebben van wat te doen, op basis daarvan is een nieuwe 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 u daarbij zullen helpen, die we u in een seconde zullen 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 hier verder naar de volgende, die we zullen zien, het is in het algemeen gewoon begrijpen tot op metrische niveau wat normaal is. Ik kan je niet vertellen wat niet normaal is als ik niet weet wat normaal is. En dus is een manier om dat te meten cruciaal en moet je rekening kunnen houden met meerdere soorten gebieden, bijvoorbeeld - of ik zou moeten zeggen tijdframes - verschillende groepen servers, in staat om dit dynamisch te doen, vanuit 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 zojuist 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 hebben om die verandering met een gerust hart 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 vaardigheid dat je een tool nodig hebt die in staat zal zijn om met elke situatie op je weg te komen, en dus wat ik daarmee bedoel is, als je een grote omgeving hebt met een In veel gevallen zul je waarschijnlijk situaties tegenkomen 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, rapporten kunnen uitvoeren, kunnen waarschuwen, baseline - alle dingen waar we het over hebben - is ook een belangrijk onderdeel van het kunnen doen van deze voorspelling en het maken van het zodat u de antwoorden krijgt waar u naar op zoek bent in staat zijn om die beslissingen te nemen, 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 dan met die gegevens doen, is natuurlijk dat we veel doen om meer inzicht te kunnen bieden. Nu, naast 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 ik graag zou willen doen, en dit is slechts een snel voorbeeld van de architectuur, de grote meeneem hier is dat er geen agenten of services zijn die daadwerkelijk aanwezig zijn op de instanties die u beheert. Maar wat ik graag zou willen doen, is je hier gewoon meenemen naar de applicatie 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, hier is iets dat u moet doen, of hier is iets dat een tijdstip in de toekomst is en we gaan u er wat inzicht in 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 in de situatie om gedurende een bepaalde periode te kunnen anticiperen op de grootte van een database, en ik geef u slechts een paar voorbeelden daarvan . Dus ik ga mijn auditdatabase gebruiken, die behoorlijk I / O-intensief is - er komen veel gegevens bij. We hebben, laten we eens kijken, we zullen dit hier doen, en laten we gewoon de gezondheidszorgdatabase hier ophalen.
Maar het punt is, ik zie niet alleen wat hier de ruimte voor is, ik kan zeggen: "Kijk, laten we de gegevens van het afgelopen jaar meenemen" - en ik ga hier een beetje zoeken, Ik heb niet echt een jaar aan gegevens, ik heb ongeveer twee maanden aan gegevens - maar omdat ik hier een steekproefpercentage van maanden kies, kan ik hierop anticiperen of voorspellen in het geval van de volgende 36 eenheden 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 verschillende 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 dan zal de lijn ons de voorspelling 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 nemen 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. Nu, dat is een ding dat we zullen doen, door je een specifieke datum te geven en te kunnen zeggen: "Hé op deze datum, dit is waar we de groei van je gegevens zouden verwachten." Maar daarnaast kunnen we u voorzien van 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, ik kan 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 gevolg daarvan." En dus wat we hier hebben, is een betere manier voor u om te begrijpen, als ik actie ga ondernemen om te helpen met de prestaties, als ik actie ga ondernemen om zelfs helpen bij 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 neem me mee naar de redenen 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 doen - en ik zal je laten 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 zijn hier vermeld, en een deel daarvan, hebben we indexoptimalisatie en query-optimalisatie. We evalueren dus niet alleen de statistieken zelf en dergelijke, maar ook dingen zoals de workloads en de indexen. In het geval hier zullen we een aantal aanvullende hypothetische indexanalyses uitvoeren. Het is dus 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 kantelpunt, waar ik zeg: "Wel, de tabel is zo groot of het soort zoekopdrachten dat binnen de werklast wordt, 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 baseline visualizer 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 jij kan teruggaan in zoveel weken om deze foto's voor u te schilderen om te zien wanneer uw uitbijters zijn, om in het algemeen te zien waar die waarde valt binnen de tijdsperioden dat we gegevens verzamelen. En dan, naast dat, zult u ook merken dat wanneer we naar de eigenlijke instantie 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 zou bijvoorbeeld een basislijn kunnen 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 tegenkom gedurende dat tijdvenster, versus misschien in het midden van de dag wanneer mijn belastingen niet zoveel, als de werklast niet zo impactvol is.
Dus dat is iets anders om in gedachten te houden, in termen van de basislijn. Het is duidelijk dat dit echt nuttig voor je zal zijn, in termen van ook begrijpen wat normaal is en in staat zijn om ook te begrijpen, betrokken te raken wanneer je ook te weinig middelen hebt. Nu, het andere soort ding dat we in de tool hebben, dat je gaat helpen beslissingen te nemen, naast de baselining en het kunnen instellen van waarschuwingen rond die basislijnen en de drempels die je dynamisch creëert, 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 waar ik aandacht voor nodig heb, met andere woorden, als ik maar een beperkte hoeveelheid tijd heb om een bepaald soort 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 is, of het wacht, of het nu responstijd is, ik kan deze instanties tegen elkaar correleren - of ik zou rang moeten zeggen. 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, want het staat duidelijk weer bovenaan de lijst.
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 u hier naar de serviceweergave scrolt, ziet u dat er een basisstatistiekenrapport is. Nu gaat dit rapport ons uiteraard helpen 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 sommige beslissingen kunnen nemen met behulp van die informatie, dus dit is een van die situaties, waar het afhangt van welke vraag het is, die 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 eenvoudige 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 waar je naar 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 te zijn om te creëren tellers, 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 die we niet hadden verwacht te controleren. 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 laat zien hier.
Nu, in aanvulling op dat - en een van de dingen die we de laatste tijd natuurlijk nogal wat zijn tegengekomen - was het eerst, iedereen flippen of overschakelen naar VM's. En nu hebben veel mensen op weg naar de cloud. En er zijn veel vragen die rond dit soort dingen komen. 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 steeds veel vragen rond dit soort dingen, en als we zien dat mensen die omgevingen consolideren, zullen ze die vragen ook moeten kunnen beantwoorden. Dat is dus een redelijk goed overzicht van Diagnostic Manager, wat dit onderwerp betreft. Ik weet dat het onderwerp business intelligence aan de orde is gekomen en we hebben ook een tool voor business intelligence waar we het vandaag niet over hadden, maar het geeft je ook inzicht 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 is, 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 dat is het niet, jij moet dit nog steeds absoluut meten.
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 gebeuren . Dat is een van de dingen die ik niet heb behandeld en die ik ook bedoelde, is 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 zijn een aantal manieren waarop we de query kunnen analyseren prestatie. Of het nu gaat om de duur, CPU, I / O, en nogmaals, we kunnen ook naar de workloads zelf kijken 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 zou ingaan op de configureerquerymonitor en ik zou zeggen: "Laten we deze waarde in nul veranderen", is de realiteit dat het hulpprogramma 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 uw 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, zullen we niet kunnen halen uit uitgebreide evenementen, terwijl we dus uit een trace zouden trekken om dat te doen. Dus het zou een beetje anders zijn in termen van de manier waarop we die gegevens zouden verzamelen, maar dat gezegd hebbende, zoals ik al zei, we zijn er 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 prestatiecontrole 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: Goed. Robin, heb je nog vragen?
Robin Bloor: Het spijt me, ik was op mute. U beschikt over meerdere databasemogelijkheden en ik ben geïnteresseerd in hoe u naar meerdere databases kunt kijken en daarom kunt u 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 om het kunnen hebben van een centraal aanwezigheidspunt van de omgeving. 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 uiteraard de meeste gevallen vanuit het perspectief van een DBA, vaak komen die problemen voor wanneer ze voor de console liggen, 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 context 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 tenminste vinden - en misschien zijn het alleen de DBA's die ons dit vertellen - maar de DBA's, de perceptie is dat het altijd hun probleem is, zelfs als het de applicatie-ontwikkelaar is die de applicatie heeft geschreven die het niet goed hebben geschreven, zij zijn degene die de schuld gaan krijgen, omdat ze die applicatie naar hun systemen of servers nemen 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 ben het 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 die ik ken, maar het is alweer een tijdje geleden dat ik naar verschillende sites met meerdere databases keek, maar ik ontdekte vooral dat er DBA's 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 ze geen ruimte tekort komen en dat 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 de DBA-dekking op een behoorlijk dramatische manier uit. Dus dat is de vraag waar het echt om gaat, is het met zo'n set van tools dat je uiteindelijk 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 behoorlijk welsprekend zei, het is alsof er een aantal databases zijn waar de DBA's om geven en dan is er een aantal waar ze minder om geven. En de manier waarop dit specifieke product, de manier waarop het een licentie heeft, is per geval. Dus er is, denk ik, zou je zeggen, een drempel voor wanneer mensen beslissen: "Hé, dit is geen kritisch genoeg exemplaar dat ik met deze tool wil beheren." Dat gezegd hebbende, er zijn andere tools die we doen heb dat zijn meer, denk ik, catering aan die minder belangrijke instanties 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 rit vol ? Reageert de server op problemen? De belangrijkste dingen, toch?
Terwijl met Diagnostic Manager, de tool die ik je net liet zien, het op het queryniveau komt, gaat het in op de aanbeveling van indexen, kijkend naar het uitvoeringsplan en al die goede dingen, terwijl dit voornamelijk is gericht over wie wat bezit, wat bezit ik en wie is er verantwoordelijk voor? 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. Als mensen naar dit hulpprogramma 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 van 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 doorgeef. 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 echt de hype en de hype weerspiegelt nooit de realiteit, dus ik ben 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 sommige gegevens worden 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, is 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, u zegt, de perceptie, omdat in het algemeen de mensen met wie ik het heb allemaal de traditionele databases hebben en deze op een SQL Server-omgeving gebruiken.
Dat gezegd hebbende, zou ik zeggen in termen van SQL zelf, ik denk zeker 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 encryptie en alle andere mogelijkheden die het tot een omgeving of een databaseplatform maken - dat is duidelijk zeer kritisch geschikt voor de missie, denk ik. Dus ik denk dat we dat ook zien. 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 omgeving groeit 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 net hadden en dit was onderdeel van de Diagnostic Manager die de web-gebaseerde versie aanbiedt, waar het me vertelt dat ik een ontbrekende index heb. En we kunnen die aanbevelingen bekijken en het zal ons de potentiële winst daarvan vertellen 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 - of 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, en dit geeft me een goed overzicht van de laatste opmerkingen hier. Robin en ik en Rick, hebben nu al vele jaren gehoord dat er sprake is van zelfafstemmende databases. Het is een zelfafstemmende database! Het enige dat ik je kan vertellen is: geloof ze niet.
Bullett Manale: Geloof niet in de hype.
Eric Kavanagh: Er zijn misschien wat kleine kleine dingen 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 hebben 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 er is binnenkort een monster van Loch Ness. Dus, ik zou gewoon nogmaals 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 zullen we u vaarwel zeggen, mensen. Nogmaals bedankt, we zullen de volgende keer met je praten. Wees voorzichtig. Tot ziens.
