Af Techopedia Staff, 30. november 2016
Takeaway: Værten Eric Kavanagh sammen med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bullett Manale diskuterer forespørgsler og hvordan deres effektivitet kan have vidtrækkende virkninger.
Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej og velkommen igen. Det er klokken fire østlig tid på en onsdag, og i disse dage betyder det, at det er tid for Hot Technologies! Ja bestemt. Vi taler om seje ting i dag. Selvfølgelig er jeg din vært, Eric Kavanagh. Titlen på dagens show er "Nøglen til effektiv analyse: hurtigt tilbagevendende forespørgsler." Det er rigtigt folkens, vi vil alle sammen hurtigt. Hvem vil ikke hurtigt? Der er et lysbillede om din virkelig, og nok om mig. Slå mig op på Twitter, @eric_kavanagh. Jeg er glad for at få forbindelse med dig der og have en samtale i sociale medier. Det kan være sjovt, bare ikke snak politik.
Årets varme. Vi har talt om forskellige analytiske problemer i år, og det ene emne for i dag er virkelig bare centralt for at få jobbet gjort. Jeg kan huske, det var sandsynligvis for fem eller seks år siden, at jeg først hørte nogen bruge udtrykket "have en samtale med dine data", og selvom det kan lyde en smule osteagtig, er pointen, at hvis du ikke kan få en iterativ oplevelse med dine data, hvis du ikke hurtigt kan ændre dine forespørgsler, sende nye forespørgsler, få svar hurtigt tilbage, så har du ikke en samtale med dine data, og hele analyseprocessen er afkortet. Det er ikke godt.
Når du har en samtale med dine data, hvad det betyder, er du i stand til at gå frem og tilbage, og efter min mening er det, når du finder indsigten. Fordi meget sjældent vil du komme med den perfekte forespørgsel første gang. Medmindre du er Mozart for analytics - og jeg er sikker på, at denne person er derude - bliver du nødt til at bruge lidt tid på at ændre, tilføje en eller anden dimension og prøve at finjustere, hvad det er, du leder efter .
Fordi igen, disse er ikke enormt svage omgivelser, som vi beskæftiger os med i analyseverdenen; vi har at gøre med meget uhåndterlige miljøer og meget komplekse og multidimensionelle miljøer. Og derfor er hele ideen med webcast i dag at tale om, hvordan du aktiverer den slags iterative interaktion med dine data.
Vi har tre præsentanter. Naturligvis har vi i Hot Technologies, i modsætning til Briefing Room, to analytikere; de giver hver deres take først, så kommer gæsten ind, giver deres præsentation, og vi har en slags rundbord. Og du, vores publikum, kan spille en stor rolle i det. Vær ikke venlig; send dine spørgsmål til enhver tid. Brug Q & A-panelet, hvis du kan, ellers er chatpanelet fint; Jeg vil prøve at overvåge begge under showet. Og vi registrerer disse, så hvis du går glip af noget eller vil dele det med dine kolleger, kom tilbage senere. Vi sender dem på Techopedia.com og også på InsideAnalysis.com.
Og med det vil jeg bringe de smarte mennesker ind. Jeg overleverer det til Dr. Robin Bloor. Lad mig give ham nøglerne, skifte præsentant, og der går du. Robin, tag det væk.
Robin Bloor: Okay. Tak for den intro. For cirka halvanden måned siden havde jeg en chat med en udvikler, der faktisk er en DBA. Han er ikke rigtig en DBA - han var en DBA hos et bestemt firma, og han var den eneste person, der faktisk kunne få forespørgslerne til at fungere. Men han blev syg af at gøre det, fordi han virkelig er, han er faktisk en ret smart udvikler. Så han forlod.
Og han skal alligevel gøre et par dage hver måned for dem, fordi de ikke kunne finde nogen til at indtage hans sted, og de har ikke en anelse om, hvad databasen gør, eller hvordan de overhovedet kan indstilles. Og jeg tænkte lidt på det, og bare, ved du, de havde ikke rigtig en IT-afdeling, men denne fyr støttede dem. Faktisk var det DBA-arbejde, som han gjorde det meste af tiden.
Til sofistikerede databaser - Oracle, SQL Server, DB2, alle disse store, dyre - er tuning af databaser et hårdt job. Det er også et sikkert job. Og grunden til at sige dette er, at det er et landskab i forandring. Jeg skal nok gennemgå dette. Du ved, relationelle databaser - normalt er det store billede, de relationelle databaser dominerer stadig i popularitet. De vil sandsynligvis dominere i lang tid fremover. Ja, der er andre databaser nu, der får mere lufttid, men du ved, når du faktisk ser på, hvad der foregår derude, gør Oracle det meste af det, Microsoft SQL Server er det andet, og der er forskellige ting, der sker i skyen, kan dog medføre en udfordring. De er de store giganter i spillet. Og det er de databaser, du kan bruge både til OLTP og faktisk datalagerarbejdsbelastning. Alternativer bruges normalt hovedsageligt i analytiske miljøer, og derefter bestemmes det normalt af dataene om, hvorfor vi vælger det snarere end relationelt. Oftest gør folk ikke det.
Virksomheder har en tendens til at standardisere på en enkelt database. Jeg stødte for nylig på et firma, der havde over 5.000 tilfælde af Oracle. Og jeg slags, den person, jeg talte med fra det firma, jeg spurgte dem slags om DBA'erne. De sagde, at de havde ca. 10 DBA'er, og at der var omkring 30 databaser, der blev passet. Og resten blev Oracle lige brugt som et endeligt system stort set. Der var meget lidt stress på dataene fra de applikationer, der brugte dem. Men det forbløffede bare mig - 5.000 tilfælde af Oracle.
Og forresten, de havde en Oracle-ejendomslicens. Du ved, virksomhedslicens, selvfølgelig. Men de havde også andre databaser, fordi nogle gange, ved du, applikationer leveres med en foretrukken database. Det var ikke som om Oracle var den eneste ting. Og det er værd at nævne, at hverken Hadoop eller Spark faktisk er en database, og det vil vare lang tid, før de får det, jeg synes om som en databaseregel. God til datalinks, selvfølgelig.
Med DBA-aktiviteter kan Bullett sandsynligvis sige meget mere om dette end mig - men jeg vil bare løbe igennem dem. Dette er hvad jeg har tendens til at tænke på, ved du, hvad DBA gør. De installerer, konfigurerer, opgraderer, udfører licensstyring. De udfører en masse ETL- og replikationsarbejde på en eller anden måde. De laver opbevaring og kapacitetsplanlægning. De laver fejlfinding, eller de er en del af fejlfindingsteamet. Ydelsesovervågning og tuning er stort set det meste af deres aktivitet, men alt dette andet, det er ikke lille, ved du. Sikkerhed, de er ansvarlige for sikkerhedskopiering og gendannelse. De burde være involveret i softwaretestsystemer, og de kunne være involveret i datalivets cyklus.
Ydeevne. Da jeg plejede at være en af disse fyre. Da jeg kørte og indstillede databaser, var det sådan jeg forstod det, ved du? Der er CPU'en, og på en eller anden måde i vores tid er CPU'en stort set normalt inaktiv, fordi den ville være en af de andre to eller th– Nå, en af de andre flaskehalse ville faktisk forårsage problemet. Hukommelse, thrashing og fragmentering, eller disk, eller disk I / O-mætning, undertiden netværksomkostning, hvis du kører i flere noder i et netværk, og du rent faktisk kan løbe ind i en vis låsning.
Men det var verden, som jeg så den. For nylig kiggede jeg på Oracle og antallet af indstillingsparametre, der findes i Oracle. Det var over 300. Du ved, og hvis du faktisk tænker over det, skal en DBA, der virkelig ved, hvad han laver, have en idé om, hvorfor du nogensinde ville rod med nogen af dem. Så det er et kompliceret job, ved du, og det er mere kompliceret af dette.
Du ved, lige nu har vi CPU'er, men du har … CPU'erne eksisterede allerede, GPU'er på CPU'en eller med FPGA'er på CPU'en. Så der foregår en slags krydsning af hvad der faktisk sker på en CPU. CPU'er blev multicore for længe siden; faktisk tunede jeg ikke længere databaser, da det skete. Jeg aner ikke, hvilken forskel det faktisk gør, nu når jeg tænker over det.
Vi har 3D Xpoint og IBM's PCM vist som et ekstra lag med hukommelse, og vi har SSD'er, men du ved, de erstatter roterende rust. Men SSD'erne kan variere i hastigheder. Med så mange kan du have parallel adgang, og det får dem til at gå utroligt hurtigt - tæt på RAM-hastighed. Og du har alle de parallelle hardwarearkitekturer.
Og alt dette, ved du, omkostningerne falder, hvilket er en rigtig dejlig ting, men det hele gør det - du ved, hvis du tager den næste udgivelse af en database, og så begynder du at implementere den på maskiner, endda nogle af dette har du faktisk mistet en magefølelse, du måtte have for den måde, dataene opfører sig på, fordi forsinkelserne bare er meget, meget forskellige. Og her, du ved, har du fire lag snarere end tre lagringslager.
Databaseproblemer. Du får database entropi - spredning af forekomster er meget almindeligt. Databaser, der blev brugt som skabe, hvilket faktisk var det eksempel, jeg gav. Meget få databaser er selvindstilling, og dem, der hævder at være selvindstilling, er faktisk ikke så gode, ved du. Men den anden ting er, at meget få databaser er korrekt afstemt. Det er et hårdt job, at være i stand til at afbalancere arbejdsmængder. Jeg mener, når du tænker på en database, hvad en database muligvis laver over en 24-timers periode, kan arbejdsmængderne være meget, meget forskellige. Databasen skal have et særligt sandt datalager.
Og derfor ved du, at du ikke er en triviel sag, for hvad du laver er at indstille parametre, der er nødt til at tage højde for en hel række arbejdsbelastninger over et givet tidspunkt. Det er et hårdt job, dybest set. Og SQL skal være afstemt især for SQL JOINs. De kan være ekstremt, du ved, ressourceforbrugende. Og hvis databasen har materialiseret synspunkter, for at være ærlig, bør du undersøge brugen af dem, fordi de får alt til at gå utroligt hurtigere. Og det kræver nogen, der forstår arbejdsmængderne og forstår SQL-trafikken og så videre og så videre.
Og de fleste virksomheder har meget få DBA'er - meget dyre. Jeg har kendt temmelig store virksomheder med, ligesom, tre fyre, du ved, massivt antal tilfælde. Virkelig, de koster meget, det er et hårdt job med hensyn til kompleksiteten. De har brug for værktøjer.
Og jeg tror, det er alt, hvad jeg har at sige. Oh yeah. Lad os give Dem over, se hvad Dez har at sige.
Dez Blanchfield: Tak, Robin. Dette er et massivt emne. Jeg vil holde mig til de ting, som jeg synes, som er effektive daglige udfordringer, som vi står over for. Fordi lad os indse det, der er et helt bibliotek med bøger skrevet om dette emne. Hvem har ikke været i en teknisk boghandel og fundet vægge og vægge i bøger skrevet om det generelle emne databasepræstation og tuning af databaser og overvågning. Og nogle gange er det en fantastisk måde at dræbe tid på.
Det generelle emne: at få præstationsforespørgsler. Der er en række forskellige dele af organisationen, der sveder dette emne - på dit slutbrugerniveau, efter min erfaring, ved du, folk bare oplever ydeevne, at tingene er langsomme. Spindehjul tager et stykke tid for at få spørgsmålene tilbage. I den modsatte ende af spektret har du infrastruktur- og netværks- og lagerteknikere, der bliver banket op af databasespecialister, fordi tingene ikke kører så godt, som de forventer. Og efter min oplevelse er det et meget bredt spektrum de ting, der kan påvirke vores liv i det spektrum.
Hvis du tænker på, fra det fysiske og opefter, ved du det bare computerpladsen. Det har hukommelse, du ved, RAM, hvis du vil - diskplads, netværk og alle bitene deromkring. I dette rum har vi, ved du, det gemmer tanken om, at sige, at, du ved, det er bedre at bruge rå disk eller en JBOD, og bare, du ved, hæve så hurtigt som muligt disken og lade database sortere databeskyttelseslaget. Andre mennesker er store fans af RAID, det overflødige udvalg af billige diske og har forskellige religiøse oplevelser med RAID 0, 1, 3, undertiden 5 og 6 forskellige typer striping eller replikation på disk, i tilfælde af at harddisken mislykkes. Selv på lager- og teknikniveau har vi stadig mennesker, der har forskellige synspunkter og oplevelser omkring ydeevne, om typer lagring.
Uanset om det er direkte tilknyttede diske og selve serverne, eller om det er tilsluttet via en fiberkanal med et lagerområde-netværk af en eller anden form, hvad enten det er lager, der er monteret fra en server et sted via iSCSI eller er det f.eks. Ethernet. Og det er, før du endda virkelig kommer til databaselaget, hvor, du ved, den slags ting, som vi tager for givet det - du ved, bare vedligeholde det, som Eric skitserede, du ved, hvad vi kalder samtalen med dine data . Bare det at være i stand til at identificere mønstre og meningsfulde mønstre, som vi tror, vi kan begynde at dykke ned i og kigge efter præstationsproblemer.
Og det er et meget bredt emne, så jeg vil dykke ned i to områder, hvor min erfaring, tid og energi og investeret indsats får et godt afkast. Så lad mig bare hurtigt hoppe til den første af disse. Og jeg gik kun halvt spøgtigt ud og kiggede efter et billede af noget, der havde et skelet på indersiden og hud på ydersiden, men Lego-blokken var nok den mindst grusomme. Men på mange måder er det sådan, jeg forestiller mig og mentalt forestiller mig den udfordring, vi undertiden står overfor med analytiske platforme og databaser, der understøtter dem. Og det er det, du virkelig kun som forbruger og slutbruger eller endda en udvikler ofte ser finérhudlaget, men det er faktisk skelettet nedenunder - det er virkelig det problem, du skal fokusere på.
I ved i dette tilfælde, når vi tænker på de ting, der kan påvirke databasens ydeevne og analyser, der er resultatet af den bestemte dag, præstationshits, kerneinfrastrukturen og bare overvågning af den centrale infrastruktur, og som jeg skitserede for et øjeblik siden din disk og hukommelse og CPU. Og som Dr. Robin Bloor fremhævede, udfordringer nu inden for virtualisering og ting, der sker i selve chips, og ydeevne ned til kerneniveau, og mængden af hukommelse, der nu placeres i hver chip i hver kerne. Dette er meget tekniske udfordringer at se efter for en hverdag.
Hold på toppen af forespørgselsovervågning. Du ved, en af udfordringerne omkring overvågning af forespørgsler og forespørgselskøer er for eksempel - jeg mener, SQL som sprog og databaseværktøjerne, der kommer rundt om analyseværktøjer, er meget magtfulde og især SQL som sprog. Men med den kraft og enkelhed kommer også en, i mange tilfælde, og det er, at hvis det ikke er et program, der gør det samme igen og igen og igen, skrevet af en god udvikler og opdaget af en god DBA, kan det måske være mennesker, der laver ustrukturerede forespørgsler.
Og problemet med det er, det er ganske nemt at lære lidt SQL og begynde at stille spørgsmål, men som et resultat heraf har du ikke nødvendigvis alle de færdigheder og erfaringer og viden til at vide, om du laver en god eller dårlig ting at gøre databasen. Så kontinuerligt at køre den samme store, brede og forkerte kan bare tage bygningen ned. Det er en interessant udfordring at holde øje med overvågningen af spørgsmål.
Bare overvågning af responstider så vidt platformens gør, og hvad brugerne får. Igen, ved du, uden de rigtige værktøjer, er dette ikke noget, du bare intuitivt ser på tinget og tænker, "Åh, de netværk kører langsomt, " eller "Brugerhukommelsen fungerer ikke godt, " eller "Indeksene fungerer dårligt ”Eller“ er oppustet. ”
Og så, ved du, hvordan kommer du til det punkt, hvor du, når du først har set et problem med det, hvordan kan du trække det fra hinanden og adskille det og tackle hele udfordringen ved dårligt strukturerede forespørgsler? Og ved du, er det en ad hoc-forespørgsel, som nogen kører i hånden, eller er det et analyse-værktøj med et frontpanel, der fungerer dårligt, fordi de stiller spørgsmålene på den forkerte måde, eller er det bare virkelig, virkelig dårligt skrevet stykke kode?
Og derefter gøre det iterativ af, sagde Eric i opsætningen oprindeligt, ved du, bare iterativt går igen og igen og igen og finjusterer disse arbejdsgange. Ved du, hvilke arbejdsgange kører jeg, hvordan kører de, hvor ofte kører de, hvilken kode kører mod dem, hvor kører de imod det i CPU og hukommelse og disk og netværk? Ja, det er bare en virkelig, virkelig teknisk udfordring.
Og så den nirvana, som folk leder efter i denne verden, mens de skifter fra historisk analyse og præstationsindstilling og alarmerer mod dit miljø, hvilket er dejligt at se, fordi du muligvis får en plan i fremtiden, hvis du ved, hvorfor ting gik langsomt i går morgen klokka ni. Men det hjælper ikke dig lige nu, og det hjælper ikke din plan fremad.
Jeg tror, at kapacitetsplanlægning og størrelse og skalering og indstilling, så du ved, jeg tror, at der er en tendens, vi ser nu, hvor der er et skift i meget store miljøer, hvor folk har store databaseplatforme og bredt spredte databasemiljøer til at gå fra historisk alarmering og planlægning til forudsigelig alarmering og planlægning, hvor de vil vide, hvad der sker lige nu og være i stand til at planlægge for det fremover. Eller løber tør for hukommelse, og vil vi løbe tør for hukommelse i den næste time, og hvad kan vi gøre ved det? Hvilken kapacitetsplanlægning kan vi gøre i realtid?
Undskyld mig. Det kommer til det punkt, hvor, du ved, bare hele udfordringen med at opdage disse forhindringer kommer i vejen for det, vi i det væsentlige refererer til som fluidanalyse, og gør det til normen i din organisation. Som du kan se, er det en ikke-triviel udfordring for, du ved, bare de hverdagens store, uvaskede masser. Og det er stadig en ikke-triviel udfordring for endnu de mere teknisk kyndige.
Du ved, hvis det er svært for bare dødelige, hvordan gør vi dette til en ting, der er mulig? Fordi, du ved, de fleste af disse er ting, som almindelige brugere ikke kan løse, og vi kan have nogle specielle databasingeniører, databaseudviklere, kodeudviklere, programmerere, men de har stadig virkelig været i stand til at adskille miljøet. De er nødt til at trække fra hinanden, du ved, problemer som folk, der genbruger kode.
Du ved, en af de værste ting, jeg har set i dette rum omkring ydeevne hits i analytiske platforme i meget store implementeringer af databaseserverinfrastruktur, er folk, der tager et stykke kode, et stykke SQL eller en stjålet procedure, som de ikke gjorde. ' t skriver, og de ved ikke, om det er et godt eller dårligt stykke kode, og de genbruger det bare, fordi det giver dem det resultat, de ønsker. Men det viser sig, at det måske kun har været noget, der blev skrevet på farten for at få et eller to resultater, som en rapport - nogen havde travlt.
Og så bruger folk kompleks kode, de ikke skrev, og bare smider det til et stykke applikationsudvikling, uden at vide, at de faktisk straffer bagenden. Selv bare at overvåge den præstation, der rammer og se på, hvor forespørgslene kommer fra og bore ned, det, ved du, det er en hverdagsudfordring, jeg ser.
Grundlæggende adfærdsmæssige ting som pre-iscenesættelse af data til ydeevne, hvor det er muligt. Ting, der bare oplever, lærer kun dig, som at slette indekser, hvis du vil foretage bulkimport og derefter indeksere igen, så indekserne ikke opretholdes, når du henter terabytes med data. Du ved, uden de relevante værktøjer er det næsten umuligt at se, fordi du ikke ved, at indekset bliver hamret.
Optimering af indekser regelmæssigt er en slags 101, men hvad med, ved du, når du laver bulkimport eller, ved du, opretter en tabel med forespørgsler, hvis nogen laver en rigtig stor forespørgsel? Du ved, det kan være et massivt præstationshit, og igen, hvis du ikke overvåger, har du ikke værktøjer til at se det, den slags sker lige i baggrunden, og du ved ikke, hvordan man adresserer det .
Begrænsning af forespørgsler til kun det antal kolonner, du har brug for - jeg mener, det lyder virkelig grundlæggende, men igen, hvis du ikke kan se det, ved du ikke, at det sker, og så sker det bare i baggrunden, og det gør dig ondt, på dig.
At vide, hvornår og hvor man skal bruge midlertidige tabeller, opsamle store sletninger og opdateringer. Igen, alle meget enkle ting, men uden denne synlighed, uden værktøjer til at gøre det, sidder de bare i baggrunden og fortsætter med at skade dig, og du kaster bare mere hukommelse eller CPU til et databasemiljø for at få en bedre analyseplatformydelse, når virkelig skal du være i stand til at bore ind i detaljerne om, hvad der skader dig og adressere den bestemte ting. Og så ved du ting som udenlandske nøglebegrænsninger, og hvordan finder du det, hvordan ved du endda, at det er et problem?
Det bringer mig til konklusionen af mit nøglepunkt her, og det er, at du ved, dagligt, vi ser disse problemer overalt. Og når databasemiljøer bliver større og større og mere og mere brede, og som Dr. Robin Bloor fremhævede her, får vi flere og mere komplekse miljømodeller med databasetider.
Og så også behovet for at integrere i nogle af de store dataplatformer som Hadoop og Spark, der følger med, og mere og mere ad gangen. Det behøver os efter min mening at finde bedre måder og særlige værktøjer til at udføre denne realtidsplatformpræstation og analyse og diagnostik intelligent. Fordi det koster realtid og rigtige penge og frustration for slutbrugere og rigtige dollars, hvis vi ikke begynder at komme til værktøjerne til at dykke ned i disse ting.
Og med det vil jeg udlevere til vores venner fra IDERA, fordi jeg tror, de har en god historie at fortælle, hvordan vi muligvis kan tackle dette meget problem.
Bullett Manale: lyder godt. Mange tak, og jeg vil gå videre og sparke tingene væk. Jeg har også et par lysbilleder her, og lad mig gå foran og slags bringe det op. Nogle af disse vil vi springe igennem temmelig hurtigt.
Bare for at give dig en vis indsigt er jeg direktør for salgsteknologi her på IDERA, og så hvad vi gør er en slags snak med DBA'er temmelig regelmæssigt om de smerter og de udfordringer, de har, specifikke for i mange tilfælde, præstationsovervågning og den slags ting, selvfølgelig. Og vi hører meget fra det publikum, og derfor tror jeg, jeg kan dele nogle af de oplysninger, jeg modtager fra dem regelmæssigt, der giver mening. Jeg vil springe gennem et par af disse, for jeg tror ikke, at de er reelle relevante for samtalen.
Du ved, jeg har min egen liste her over DBA's ansvarsområder - det ligner meget på Robins liste, og jeg synes, det er temmelig konsistent. Jeg tror, at når du taler med en databaseadministrator, er det dog altid - du ved, at de er klumpet ind i nogle af disse områder mere end andre, og der er ingen rim eller grund til det, det afhænger bare af miljøet.
Du hører en temmelig bredere, bred vifte af ting, som folk vil kunne gøre. Og mange gange gør de mennesker, der vil have disse ting, ikke - de vil bede om dem, og i nogle tilfælde begynder du slags at bore i det, de virkelig beder om, og så finder du ud af, at de ' re virkelig leder efter mere. De vil virkelig have mere information end hvad de oprindeligt synes, at de har brug for, og når du begynder at bore i værktøjet, tror jeg, at det er her, du kan begynde at sige, at de har en samtale med dataene.
Og jeg synes, det er en rigtig interessant sætning, og det giver en masse mening med hensyn til at kunne sige, ja, ja, hvis du har en dårlig forespørgsel, hvad er egentlig en dårlig forespørgsel? Er det en forespørgsel, der bruger en masse læser eller skriver eller CPU? Det kan være en, der kører meget, den kan en, du ved, det er, som du sagde, dårligt skrevet.
Med hensyn til hvordan vi identificerer det, er der en række måder, du vil se med hensyn til vores produkt, Diagnostic Manager-produktet, at vi viser DBA'erne, at de kan gøre det. Og det er virkelig fleksibelt, og jeg synes, det er en af de store ting - du skal have et værktøj, der hjælper dig med disse ydelsesproblemer, er alles miljø lidt anderledes.
Og der vil være mange, du ved, behov og måske endda uklare krav med hensyn til overvågning, så du bliver nødt til at have noget, der er fleksibelt og noget, der vil arbejde og være i stand til at tilpasse sig det miljø, du prøver at styre. Du ved, og jeg har mange af disse eksempler - Jeg vil ikke gennemgå hver enkelt af dem, men du har brug for noget, som du kan dreje frem og tilbage mellem et stykke data og et andet, og jeg vil slags tale om det, når vi kommer ind i produktet lidt og viser dig det, og med hensyn til hvordan vi gør det.
Men den anden ting, som jeg synes med hensyn til ethvert godt analyseværktøj er, ved du, der er nogle centrale ting, du virkelig leder efter. Du ønsker selvfølgelig først og fremmest ikke et værktøj, der vil forårsage sine egne ydelsesproblemer i navnet på ydeevnen. Når jeg siger, indsamle dataene uden omkostninger, taler jeg ikke om omkostningerne i form af, du ved, monetære omkostninger, men med hensyn til omkostningerne i form af omkostninger og omkostningerne i form af mængden af ressourcer, som vi vil bruges i navnet på performance. Du vil bestemt have noget der, der vil hjælpe.
Du har brug for noget, der vil være i stand til at få de data, du leder efter, specifikke for de problemer, du står overfor i din daglige dag, og der kan være nogle ting, du ikke har brug for, og som du ikke har Jeg vil ikke, og der er ingen mening i at indsamle disse data, hvis du ikke nogensinde vil rapportere om det eller vil have nogen behov omkring at prøve at administrere disse data. Med hensyn til metadata, der er knyttet til ydeevne, f.eks.
Du ved, et godt eksempel er, at jeg ikke behøver at blive advaret, hvis tjenesten Distribueret transaktionskoordinator i SQL er nede, hvis jeg ikke ønsker, at den skal køre i første omgang. Så ikke advar mig, ikke indsamle dataene mod dem - jeg har ikke brug for disse oplysninger. Så det er virkelig vigtigt at have evnen til at tænde og slukke for disse ting.
Muligheden for, når du først har indsamlet dataene, har adgang til dem temmelig hurtigt - du behøver ikke, du ved, køre og massere dataene, manipulere dataene - være i stand til at gøre det hurtigt og effektivt. Og så når du først har dataene, er det tydeligvis virkelig vigtigt at være i stand til at forstå dem.
Nu er det her, med vores - med, som for eksempel Diagnostic Manager-produktet, jeg vil vise dig lidt i dag - det produkt, ved du, jeg vil meget gerne fortælle dig, at det produkt vil erstatte og være en DBA i en boks. Virkeligheden er, at det kræver en vis viden om, hvad dit miljø er, og hvad du prøver at opnå. At have nogle, selvfølgelig, forståelse af selve rollen som DBA er naturligvis vigtig.
Det, vi prøver at gøre, er at uddanne gennem hjælp og gennem andre metoder. Men du vil altid ønske at binde dette, selvfølgelig, med en eller anden type oplevelsesniveauer eller nogen, der har noget kendskab til, hvad de skal gøre, når de har modtaget dataene. Og at være i stand til at have en person, der kan stille de rigtige spørgsmål til et produkt og have den samtale med dataene, er åbenlyst nøglen. Og så åbenlyst at kunne give mening om dataene.
Når jeg først har fået oplysningerne, kan jeg få dem ud til de rigtige mennesker. Mine udviklere, mit driftsteam - uanset hvad det måtte være, er jeg muligvis nødt til at integrere med andre produkter og have kroge for at kunne gøre det. Dette er alle rigtige vigtige ting. Og så, selvfølgelig, sidst men ikke mindst, hvis jeg har brug for at vide mere, være i stand til at gøre det. Om det betyder, at du tænder på noget mere, der skal indsamles, eller om det betyder bare at gå lidt dybere ind i dataene. Du håber, at du med et værktøj, der bliver, ved at hjælpe med ydeevne, får alle de ting, du har brug for for at kunne svare på disse spørgsmål.
Den ene ting, som jeg ikke har lagt på her, som jeg synes, det er værd at bemærke, er, at du har brug for et værktøj, der hjælper dig med at skelne mellem hvad der er normalt og hvad der ikke er normalt. Og jeg tror, det er en stor en, for, du ved, der er masser af alarmerende produkter og ting derude, men hvis du får en advarsel, og alarmen er en falsk alarm, gør det dig ikke godt ; det er mere spild af tid, og det vil reducere din effektivitet mere, end det vil hjælpe dem. Så du ved, det er nogle ting, jeg vil huske.
Når jeg taler om det produkt, som jeg slags binder alle disse ting til i IDERA-produktpakken, er det Diagnostic Manager-produktet, som jeg tror, der sandsynligvis har den vigtigste slags egenskaber i det, vi taler her i form af database tuning og ydeevne og overvågning og den slags ting.
Folk søger overvågning på virksomhedsniveau; de ønsker at være i stand til at have adgang, på en skærm kunne vide, at tingene fungerer som de skal være. Eller de vil være i stand til, selvfølgelig, hvis der er et problem, at se, hvor problemet er, og derefter være i stand til at bore ned i det. Rigtig stor del af, tror jeg, hvad folk leder efter med disse typer måder, som du virkelig kan finpudse på din præstation.
Den anden ting, der naturligvis følger med det, er, at jeg ikke bare kan operere i nuet, og jeg har brug for at kunne gå tilbage over perioder, hvad enten det betyder at se på forespørgsler, der løb dårligt, eller om det betyder, du ved, ser på den måde, som værten VM selv opførte med hensyn til ressourcer. Alle de slags ting, du skal være i stand til, og du vil ikke sidde der og stirre på din konsol 24 timer i døgnet, 7 dage om ugen.
Hvis du er på ferie, eller hvis det er midt på natten, eller hvad det måtte være, har du brug for noget, der vil være i stand til at gå tilbage i tiden med dig for at kunne sige, hvad der foregik i eksemplet på den gang vi havde et problem. Og at være i stand til at gøre det igen, effektivt og hurtigt og være i stand til at bore ned i det er bestemt et vigtigt stykke med hensyn til denne diskussion. Og jeg vil sige, at det sandsynligvis er en af de mere vigtige ting med hensyn til, hvad folk leder efter. De leder altid efter det vindue ind i fortiden, for det er virkelig en im. Du ved, du ønsker ikke at skulle sidde der og vente på, at der skal ske noget igen.
Den næste ting på listen er egentlig bare at binde tilbage til det, vi talte om tidligere, med selve forespørgslens ydeevne. Og jeg vil vise dig et par forskellige eksempler inden for Diagnostic Manager-produktet, hvordan vi gør det, hvilket helt sikkert i slutningen af dagen, det vil give dig en masse muligheder omkring selve forespørgslerne med hensyn til hvad du vil samles.
Hvad angår, om du er interesseret i forespørgsler, der forårsager smerter i ressourcer, forbrug af CPU eller forbrug af I / O. Uanset om det er forespørgsler, der tager lang tid at gennemføre, eller forespørgsler, der bare generelt ikke kan være den værste fornærmende med hensyn til ydeevne, men kan køre så ofte, at den rene frekvens af selve kørsel kan være et problem. Og åbenlyst at kunne se tendenser over tid med disse spørgsmål er også en vigtig del af det.
Der er mange forskellige måder, hvorpå vi kan gøre det inden for dette produkt, og jeg synes, det er åbenlyst et virkelig vigtigt stykke for de fleste DBA'er. Og selvom du ikke har dine egne internt udviklede applikationer, er det stadig rart at være i stand til at gå til dine softwareleverandører og sige, “Hej, ved du hvad? Du ved, klokken to om eftermiddagen hver dag, når dette job starter, ”eller hvad det end er, ” Det er din ansøgning, der forårsager dette, og vi var nødt til at ordne det. ”Så selvom du ikke har komplet kontrol over selve koden, er det stadig rart at vide, hvornår der opstår problemer.
Og så ved du, den anden del er bare åbenlyst at være mere proaktiv. At være i stand til at være den første til at vide, være i stand til at forstå, når der opstår et problem. At ikke kun være den første, der ved det, så du kan rette det, men i mange tilfælde, når du har brug for, er noget, der vil være i stand til at automatisere et svar, også i mange tilfælde. Du kan sige, du ved, snarere end at få en e-mail, der siger: ”Hej, du er nødt til at løse dette, ” hvis jeg er på et møde, eller hvis jeg er, du ved, på vejen eller hvad det end er jeg Jeg laver det, det er tydeligvis meget rart at kunne sige, at jeg har noget på plads, der vil være i stand til at tackle det på en automatiseret måde.
Og hvis det ikke adresseres på en automatiseret måde, i det mindste at være i stand til at være den første, der ved, så du kan tage korrigerende handling eller kontakte en person, der kan. Og så dette er åbenlyst store vigtige stykker til, du ved, disse typer problemer, du muligvis støder på med hensyn til overvågning af dine maskiner og dine forekomster og selve analysen.
Nu talte jeg om dette tidligere, hvilket er tingens fleksibilitet. Jeg kan ikke understrege dette nok, ved at være i stand til at sige, du ved, out-of-the-box, hvis der er noget, der ikke overvåges, at være i stand til at have funktionaliteten i et produkt for at kunne tilføje disse ting til overvåges. Og i den forstand med eksemplet med Diagnostic Manager har vi selvfølgelig, du ved, WMI-tællere, tællere, SQL Server-tællere, du kan oprette dine egne forespørgsler.
Du kan endda, du ved, hvis du vil, trække dataene fra dit vCenter-miljø eller dit Hyper-V-miljø, som et resultat af den afstemning, der finder sted og i stand til, du ved, gør det regelmæssigt og træk disse data og være i stand til at se dem. Og drej igen, fra et sted til et andet, når du ser på disse oplysninger.
Så det er de slags ting, hvad angår det, jeg ser folk beder om, når de taler om et værktøj, der vil hjælpe dem med hensyn til tuning og ydeevne - det produkt, jeg vil vise dig i bare et det andet er Diagnostic Manager, og det understøtter alt fra 2000 helt op til 2016. Det er specifikt for SQL Server, og så overvåger vi at administrere disse ting. Der er ingen agenter på selve forekomsterne, der overvåger forekomst.
Det går tilbage til at indsamle informationen til en lille pris, at vi ved, vi forsøgte åbenlyst mere at indsamle disse oplysninger, ikke bruge en masse ressourcer også, gør vi? Vi forsøger at udnytte de ting, som SQL Server allerede leverer til os og gøre det bedre, uanset om det er dynamiske ledelsesvisninger, eller om det er udvidede begivenheder, eller hvad der måtte være tilfældet i selve samlingen. At være i stand til at udnytte disse oplysninger og gøre dem bedre er et af vores mandater.
Hvis du nu ser igennem dette rigtige hurtigt, vil jeg ikke gå igennem arkitekturen i for mange detaljer, men have et bagvedliggende arkiv med alle vores historiske data, som du kan administrere, og du kan opbevare så længe du vil have. Du kan endda vælge den type information, du vil opbevare, og i hvor længe. Det går lidt tilbage til det, indsamle de relevante data og lader de unødvendige data være ude. Hvis du vil beholde forespørgslerne i fem dage, der kører effektivt og derefter beholde dine alarmer i to år, er det op til dig, og det er fuldstændigt din beføjelse til at kunne gøre det.
Et antal forskellige konsoller med dette produkt. Du har en webbaseret version, du har også en tyk klientversion. Og så det er at have fleksibiliteten ved at springe i en browser og se, hvad der foregår, eller hvis du har en bærbar computer, hvor du har en dedikeret klient installeret, ville en af disse tilgange fungere for dig.
Hvad jeg gerne vil gøre er at gøre en hurtig demonstration. Og jeg vil påpege - jeg går tilbage til dette andet lysbillede her - som vi har, vi lige har tilføjet, ligesom en FYI for de mennesker, der er bekendt med produktet, vi har et nyt tilbud, som er Diagnostic Manager Pro. Et professionelt tilbud, der inkluderer det, vi kalder Workload Analyse.
Og det handler virkelig om at være i stand til interaktivt at se på meget store tidsperioder og gå fra det, du ved, 30-dages udsigt til, du ved, fem minutters udsigt i cirka tre klik. Og ved at kunne se spidsen i ydeevne eller problemet i den flaskehals, som du måske kunne, ved du, vil du være i stand til at se på et meget højt niveau og bore ned til et meget lavt niveau. Og især det også i dag, det er nyt for produktet.
Men hvad jeg gerne vil gøre, er bare en slags første start, og jeg vil tale lidt om den drejning og gå frem og tilbage. Og jeg har taget et eksempel op, og jeg vil dele på min skærm her. Og lad os se … Der går vi. Min skærm. Og lad mig vide, fyre, at I kan se det.
Eric Kavanagh: Der går du.
Bullett Manale: Alt er okay derovre? I orden. Så hvad du ser på lige nu - og dette er Diagnostic Manager-produktet - og jeg ville bare give dig en slags demonstration på højt niveau af hvad der foregår her. I dette særlige eksempel, hvad vi laver, er at vi viser dig de forespørgsler, der er knyttet til ventetider. Og så når jeg taler om at være i stand til at gå frem og tilbage, bore dybere ned og dreje, er det - dette synspunkt her er et godt eksempel på det. Jeg kan gå fra en tidslinjevisning, som vi ser her, som vises nu. I vores tilfælde ser vi på selve ventetiden og kategorierne af venterne selv. Vi kan se de udsagn, der er knyttet til disse ventetider, vi kan se applikationerne.
Bemærk, at det er på en tidslinjevisning her, så jeg kan identificere disse oplysninger lineært baseret på, hvornår problemet skete, men så igen, hvis jeg vil bare, endnu en gang, dreje, og jeg siger: ”Ved du hvad, lad os se på dette fra et andet perspektiv, ”lad os gå videre og se på dette ud fra et synspunkt:” Jeg vil se forespørgslerne eller ventetiden eller de applikationer, der forårsager mig mest smerte, og rang dem. ”Og det er hvad vi ' kommer til at se ved "forespørgsel venter efter varighed." Nu ser vi selve applikationerne, der forårsager min mest mængde smerte eller venter.
Og så er her den del, der virkelig er den vigtigste del, at være i stand til at isolere disse ting. Jeg kan se, at denne NoSQL-applikation starter med her. Det giver mig en god mængde ventetid, langt inde i de 25 sekunders mængder ventetid inden for dette 30-minutters vindue, som vi bores i. Og så kan jeg isolere den applikation, og jeg kan se de erklæringer, i dette tilfælde, der direkte påvirker netop dette tilfælde.
Og dette er bare et eksempel på, hvordan du ville være i stand til at identificere en flaskehals, være i stand til at rangordne informationen og være i stand til at prioritere de problemer, der skal løses først. Dette er alle ting, du skal overveje. Du ved, du kan løse problemer hele dagen lang, men hvis du løser de problemer, der er nederst på listen, der skal rettes, spilder du din tid. Du har en mulighedsomkostning forbundet hermed.
Jeg giver dig et andet eksempel, og dette er lidt af et andet eksempel. I stedet for specifikt at pege på et problem eller pege på et område, har du også brug for et værktøj, der vil være i stand til at hjælpe dig i bred forstand, ved at kunne sige, "Hej, har vi haft problemer?" Eller "Er der ting, som jeg kan gøre for at forbedre ydelsen? ”og for at have noget slags bag kulisserne og se, hvad der foregår. Og i dette tilfælde kan dette relateres til konfigurationen; det kan relateres til den, du ved, måde, hvorpå selve sundhedsforekomsten styres. Og også, selvfølgelig, ydeevne ting også.
Hvis jeg går til denne Analyse-knap herover, er det, jeg vil vise dig, at vi inden for dette produkt også har en slags proaktiv liste over ting, der kan udføres i et rangeret format, der i det væsentlige giver dig indsigt i de ting, der sandsynligvis vil give dig en forøgelse af din præstation i det tilfælde, eller en forøgelse af sundheden i det tilfælde. Og det er i et klassificeret format i den forstand, at du har denne evne til at se, hvilke der er mere tilbøjelige til at forbedre din ydelse, der er specifik for en bestemt type problem, der er identificeret.
Og så når jeg ser på disse ting, og jeg identificerer dem, ser jeg ikke kun, at jeg har et problem, og jeg har også i mange tilfælde et script, der kan bygges automatisk for at løse dette problem. Men i mange af disse tilfælde har vi også eksterne links, der refererer til den type problem, vi oplever, og hvorfor vi også giver denne anbefaling, så du får det uddannelsesmæssige aspekt af tingene. Hvilket, igen, synes jeg er meget vigtigt, når du taler om, du ved, at løse problemer.
Jeg vil ikke bare følge disse anbefalinger blindt, jeg vil forstå, hvorfor disse henstillinger bliver fremsat. Og jeg er muligvis en senior DBA, der har gjort dette i 30 år, og jeg har brug for noget, der skal, ved du, tjekke - eller prik i'erne og krydse t'erne, i dette tilfælde - eller måske er jeg en junior DBA og Jeg har brug for lidt hjælp til at forstå disse problemer, mens de sker, og hvorfor disse henstillinger bliver fremsat.
Som jeg sagde, vil jeg bare føre dig gennem et par forskellige dele af produktet. Dette værktøj har eksisteret, ved du, det har eksisteret siden 2004, 2003. Og det har virkelig lagt en masse udvikling i det, en masse information, så det ville ikke være fornuftigt at prøve at vise dig alt her. Men jeg tror, en af de ting, det er værd at bemærke, er, at når vi går ind og vi begynder at tale om alle de ting, du kan overvåge, og alle de ting, du kan advare om, igen, når vi går tilbage til den fleksibilitet af ting, her er en liste over alle de poster, som vi overvåger.
Nu betyder det ikke nødvendigvis, at jeg vil overveje disse ting til at være i en alarmtilstand, hvis de slipper ud for at være i tærskelværdi, så du kan tænde og slukke disse ting. Dette går tilbage til det, ”Hej, jeg har kun brug for at gøre visse ting til bestemte målinger. Jeg behøver kun at, du ved, gøre opmærksom på visse problemer. ”Og være i stand til at sikre os, at vi ikke ved, du ved, mæt dig med en masse falske positiver. Ikke kun har du evnen til at tænde og slukke for disse ting, men i mange tilfælde vil du bemærke, at vi også leverer dette bånd af normalitet, når det gælder hver enkelt metrisk. Så hvis jeg ser på netop dette, i dette tilfælde en basislinje, vil jeg bemærke, at tærsklen sandsynligvis er højere, hvor de er lige nu.
På den anden side af mønten er, hvad nu hvis jeg har en forekomst af SQL, hvor jeg sporer nogle målinger og disse beregninger, uanset hvad årsagerne er, at tærsklerne, jeg har angivet, er forkerte? Med andre ord er tærsklerne smækkende midt i det sted, hvor basislinjen faktisk sidder, hvilket betyder, at hvis jeg har en alarm bundet til denne tærskel, får jeg sandsynligvis en advarsel om noget, der er en normal begivenhed. Og i sådanne situationer kan vi give dig den indsigt også overalt.
For alle målingerne i dette særlige tilfælde kan jeg se de tærskler, der sandsynligvis vil vise en falsk positiv her med hensyn til hvad der er normalt og hvad der ikke er. Dette vil være noget, der ville blive betragtet som en mere normal brug ting på hukommelsessiden, og hvis jeg ville øge denne tærskel, kunne jeg det, men det er slags ideen med basislinjerne.
Og den seje ting ved Diagnostic Manager-produktet med hensyn til selve basislinjerne er en mulighed for at indstille flere baselinjer. Og du kan spørge: "Hvorfor vil jeg gerne gøre det?" Og svaret er, ja, hvis du har et vedligeholdelsesvindue, der løber fra, lad os sige, midnat til kl. 04, hvor du virkelig beskatter dine ressourcer, du bruger jeg virkelig ressourcerne så meget som muligt, så vil du være i stand til endnu en gang at skifte, og du vil dreje en lille smule og sige: ”Se, vi vil ændre vores tærskler for det.” Og vi kan faktisk dynamisk tilpasse vores tærskler, specielt til hvilken basislinje vi tilfældigvis er i, baseret på tidspunktet for dagen eller dagen i ugen og så videre, at det er. Så det justeres derefter dynamisk disse tærskler for os.
Lad os tage et skridt igen. Når vi først har identificeret disse tærskler, når vi først er gået igennem, og med hensyn til opsætning af advarsler og anmeldelse og at vi er opmærksomme på disse situationer, der kan ske, er det endnu en gang vigtig for fleksibilitet her. Du vil være i stand til at advare i specifikke situationer. I andre situationer ønsker du måske at sende en e-mail til en anden, muligvis vil du køre et PowerShell-script, måske, ved du, listen fortsætter.
Jeg vil måske integrere med noget via SNMP-fælde eller endda direkte med for eksempel SCOM. Pointen er, at du har fleksibiliteten til at gøre det, og du kan indstille uanset hvilke typer betingelser, der kan berettige det, uanset om det er en meget vidtgående tilstand - du ved, min CPU og hukommelse eller hvilke ressourcer der er - på tværs af alle mine tilfælde, eller måske har jeg en meget specifik type ting, jeg vil overvåge, fordi når jeg finder ud af, at vi er i krænkelse, vil jeg køre et meget specifikt og instrueret script til det problem. Så det er her, du ville være i stand til at gøre den slags ting inde i Diagnostic Manager-produktet, bare du ved hvad angår advarsel og anmeldelse og være i stand til at være fleksibel fra det synspunkt.
Nu vil jeg ikke gennemgå al alarmeringen og alt det gode. Jeg ville gerne tale om rapporterne. Og endnu en gang at være i stand til at tage informationen og udnytte disse data på en række forskellige måder - og dette går igen tilbage til samtalen med dine data. Og mange mennesker, når de først ser dette produkt, tror de, ”Åh, jeg har et værktøj, der vil advare mig, når der er problemer. Det er hvad jeg har brug for. ”Og virkeligheden er, er de har brug for det værktøj, men den anden side af det er, hvis de virkelig - de har også brug for et værktøj til at hjælpe dem med at tage beslutninger, og de kan udnytte disse oplysninger, som vi indsamling i præstationens navn og også i advarselsnavnet for at være i stand til at hjælpe dig med at tage beslutninger på vejen fremad.
Du ved, et godt eksempel ville være mine vækstprognoser i min database. Hvis jeg har en bestemt database, der vokser, kan jeg pege på den database eller endda flere databaser for at kunne se, hvad vækstraterne er. Vi viser dig ikke ud fra hvad, du ved, hvad det er i dag; det vil forudsige det baseret på den tidligere vækst, vi har oplevet.
Hvis jeg har et par databaser her - som jeg tilfældigvis har forestillet mig det - kunne jeg gå ind og sige, ”Lad os tage det sidste, du ved, årets værdi af data, lad os korrelere det efter måned og i en prøve for måneder, lad os gå videre og se, hvor meget vækst vi vil se i de næste tre år, eller 36 enheder. ”I hvilket tilfælde kan vi meget hurtigt besvare det spørgsmål. Prøv nu at gøre det på egen hånd, ikke? Prøv at gøre det på så meget tid, som jeg gjorde det på egen hånd. Det tager dig et stykke tid.
Nu, til endda slags yderligere stress, lad os tage en anden rapport, som er min topserver-rapport. Forestil dig, at jeg har hundrede produktionsforekomster, hvilket i dette tilfælde ikke gør det. Men hvis nogen kommer til mig og siger: ”Jeg har brug for, at du fortæller mig - vi vil lægge denne nye database derude til denne fantastiske nye applikation; det vil ændre alt, som vi kender det; det vil gøre livet så vidunderligt. Åh, forresten, selve databasen bliver virkelig I / O-intensiv, eller den bliver CPU-intensiv, eller virkelig hukommelseskrævende … ”Uanset hvilken udfyldning det er, jeg vil kunne se af alle mine produktionsforekomster, hvor er det fornuftigt at placere denne database? Og jeg kan rangere alle mine tilfælde mod hinanden med hensyn til den betingede type, hvad enten det drejer sig om CPU, hukommelse, disk eller hvad end det er tilfældet. Og så er pointen her at kunne besvare dette spørgsmål hurtigt og effektivt og tage den rigtige beslutning snarere end at gætte, når du gør det - det er alle åbenlyst virkelig vigtigt, og du har brug for noget, der vil hjælpe dig.
Og når vi taler om analytics, kan det spænde fra alt, hvad vi taler om med kapacitetsplanlægning til, du ved, alarmer, som du løber ind i fra dag til dag, der muligvis kan håndtere CPU, som såvel som selvfølgelig spørgsmålene i sig selv, om der er blokering og så videre og så videre.
Et andet eksempel på det ville være, hvis jeg gik til administrationssektionen herover - faktisk tager jeg den tilbage, den advarselssektion herover - spørger deponeringsstedet for vores historiske oplysninger om ting, der er sket i fortiden. Har jeg blokeret, der er sket i mit produktionsmiljø? Jeg ved ikke, lad os finde ud af det.
Jeg kan vende tilbage til mit produktionsmærke, og jeg kan sige, for alle mine produktionsforekomster, givet uanset tidsperiode, for alle målinger, som jeg vil identificere. Hvis jeg er gået i en alarmtilstand på, i vores tilfælde, så lad os sige blokering ved tælling, ikke ved sekunders blokering, og jeg kan gå tilbage og i dette tilfælde et par måneder, hvis jeg har brug for - eller i dette sag, en måned - og jeg kan se, at det blokerer. Jeg kan se, hvornår det startede, jeg kan se, hvornår det sluttede, og jeg kan bore ned i et hvilket som helst af disse trækintervaller, hvis jeg har brug for det, for at se detaljerne i blokeringshændelsen i sig selv. Du skal være i stand til at have noget, der er meget hurtigt, være i stand til at finde det, du har brug for og leder efter, snarere end at dreje en masse cykler for at gøre det i. Og det synes jeg også er vigtigt.
Den sidste ting, jeg gerne vil vise dig - og viser dig dette produkt, Diagnostic Manager-produktet - er, at vi, som jeg har nævnt før, er gået ind, og vi har tilføjet en anden komponent til vores SQL Diagnostic Manager Pro-tilbud. Og det er komponenten Workload Analysis. Og dette er en webbaseret version af dette, i dette tilfælde, som vi viser dig her. Men pointen her er, at dette giver dig mulighed for at se på et rigtig bredt tidsrum eller et meget specifikt tidsvindue, og fra, du ved, et par klik, der er i stand til at se koden direkte relateret til problemer, der måske er sket .
Som et eksempel på dette, hvis jeg ser på en fire-ugers visning, her kan jeg lige her se alle piggene med hensyn til databaserne og ydelsen af disse databaser, og hvor vi så ventaktivitet på disse databaser. Nu, og du kan se, hvis jeg ser en pigge her, er fordelen ved dette værktøj bare at kunne fremhæve den lille bar lige der. Og når jeg gør det, ændres alt det her. Vi ville være i stand til at se databaserne, vi ville være i stand til at se, at alle kommandoer er bundet til hvad der ligger bag denne bjælke.
Samme ting, hvis jeg sagde: ”Lad os se på de sidste fire timer” snarere end de sidste fire uger. Det kan jeg stadig gøre. Jeg kan stadig fremhæve den periode, og derefter derfra - her er, igen, her er mine omdrejningspunkter - alle disse ting her kan jeg linke til. De øverste SQL-udsagn, jeg kan se de forespørgsler, i dette tilfælde, der forårsager ventetider, der var relateret til CPU-forbrug. Bare ved at bore ind kan jeg se de spørgsmål, der er relateret her - whoops - og jeg kan også se programmerne og hvad der ikke er forbundet med dette også.
Du får en masse indsigt her, og ikke kun det, men du kan se, når du kommer ned på kommandoniveau, det vil fortælle dig ting. Det vil fortælle dig, om det ser tunge operatører, du kan derefter se udførelsesplanerne. Dette tager lidt tid, fordi det er temmelig omfattende at indlæse denne. Men pointen her er, at du har en masse forskellige måder at se dataene på, se hvad det er, du leder efter, og så åbenlyst være i stand til at gribe ind derfra, som du har brug for, så og denne tager længere end det normalt gør, så jeg lader det være ved det.
Og så med det sagt, vil jeg give det tilbage. Og forhåbentlig var dette en god demonstration af slags ting, vi talte om. Og som jeg sagde, selve produktet, som vi brugte til at give disse eksempler, har været meget lang, og så mange andre ting, vi kunne tale om og vise dig, men hvis dette er noget, der er af interesse af dig, kan du altid gå ud på vores hjemmeside og downloade den og lege med det.
Eric Kavanagh: Og jeg elsker at du viser alle disse detaljer. Hvis du går tilbage et par skærme - selv denne skærm er temmelig god. Fordi der er så mange forskellige måder at visualisere, hvad der faktisk sker, og jeg tror, dette er en af de mere under-værdsatte aspekter af computing i disse dage. Det er bestemt et databasemiljø, som jeg på mange måder har denne halve vittighed, som jeg siger: ”Vi lærer stadig at tale silicium.” Vi lærer stadig at forstå, hvordan man kan se, hvad der sker, og til dit punkt, som var meget godt taget, skal du have den samtale med data for bedre at forstå, hvad der foregår, hvorfor ting går langsomt, fordi der er så mange mulige problemer. Og selvfølgelig har IDERAs en række forskellige produkter, hvoraf det ene er de gamle præcise produkter, som jeg tror kunne være komplementære til dette.
Men måske Robin, jeg kaster det over til dig for et par spørgsmål, og så er Dez, et par spørgsmål fra dig, og så måske nogen fra publikum, ikke vær genert. Send dem ind nu.
Bullett Manale: Robin, er du på stum?
Robin Bloor: Ja. Det er okay, jeg tager bare mig af. Jeg må sige, det er utroligt - den ting, der faktisk slog mig som mest dramatisk ved dette værktøj, fordi det virkelig - især i betragtning af det faktum, at det er ganske åbenlyst, at en hel række dimensioner, du bare ikke har gået ind i - det, der faktisk, Jeg tror, det mest imponerende ved dette er, det skal være en virkelig, rigtig god måde at træne en DBA på. Du ved, det er - så når du først går i gang med databasearbejde, og du faktisk ikke ved meget om, hvad der faktisk sker i en database, er det faktisk virkelig, virkelig svært at få en forståelse. Så bruges dette meget, specifikt til træning? Jeg ville bruge det.
Bullett Manale: Ja. Jeg mener, når du siger træning, mener du slags som en træning i gang som en DBA slags, ikke? Med hensyn til…
Robin Bloor: Ja, ja, ja, ja. Et læringsværktøj. Du ved, a.
Bullett Manale: Ja, jeg ville helt sikkert tro, at det er tilfældet, og endnu mere, at vi har tilføjet dette, analysekomponenten, som vi viste dig tidligere, der har alle de anbefalinger, der er knyttet til det. Men jeg tror helt sikkert, at du inden for hjælp og en masse forskellige områder inden for produktet finder det, at du ved, du ved, en masse indsigt. En masse information.
Og virkeligheden er, som jeg sagde, du kan bruge dette, hvis du ikke er en DBA. Du kan sandsynligvis finde dig selv ud af nogle Google-søgninger og lignende ting, bare for den generelle viden om, hvad de fleste DBA'er har, men du kan sammenhænge dette, og det vil bestemt hjælpe dig i form af, "Hej, ved du, hej hvad er der denne ting, der kaldes fragmentering? ”eller, ” Hvorfor kører denne forespørgsel 6.000 gange? ”Jeg mener, fordi disse ting vil blive bragt op til dig, og de vil boble op, og du vil se dem. Du kan se, du ved, hvad der er normalt og hvad der ikke er. Du kan se de ting, der er piggende, og de ting, der ikke er.
Som regel forsøger vi at konfigurere denne ting som med hensyn til bedste praksis. Så når du peger på et eksempel, viser det dig de ting, der identificeres som uden for bedste praksis. Jeg mener, selvfølgelig, ved du, virkeligheden er, at bedste praksis er bedste praksis, og det er ikke altid reel praksis. Men, du ved, det vil vise dig outliers, selv fra det oprindelige punkt, at du installerer det og peger det på et eksempel.
Og derfra kan du en slags bevæge dig, da du nødvendigvis nødvendigvis skal løse problemerne og identificere, om det virkelig er et problem eller noget, der normalt sker dagligt. Og derefter, fordi du har en masse information at hjælpe og anbefalingerne, ja, absolut.
Robin Bloor: Okay. Og et andet spørgsmål - men jeg er sikker på, at svaret på dette er meget hurtigt - er, at du har granulariteten til at gå helt ned til den individuelle forespørgsel og det individuelle tidspunkt og se fra den dimension.
Bullett Manale: Sikker, ja. Afhængigt af hvad du vil gøre, kan du se på et tidsvindue på et minut, eller du kan se på et tre-dages tidsvindue eller, du ved, et tidsvindue på tre uger. Og du ved, som jeg sagde, det afhænger af, hvordan du vil se på dataene, og også, hvad du vil indsamle. I nogle tilfælde indsamler vi kun de forespørgsler, der når en tærskel, som du har identificeret. I andre tilfælde kan vi muligvis indsamle, du ved, enhver forespørgsel, der forårsager en ventetid.
Men du har også evnen til at sige, ”Se, de tærskler, som jeg identificerede, måske er det bare til skrivninger, eller måske er det bare til læsninger, eller måske er det bare for CPU.” Så hvis man antager, at det er overgået denne tærskel, så er det hvad du vil samle på. Så uanset hvilken tidsramme, du vil se på, ville du være i stand til at se de forespørgsler, der er krænkende, baseret på det, du anser for at fornærme.
Du har mange forskellige måder at se på dataene på. Du kan se på det i en samlet visning for at se, du ved, de forespørgsler, der - hvor mange bag kulisserne forespørgsler, der startede, mod, du ved, hver eneste hændelse i den forespørgsel, der starter, for at se et mønster, hvis du vil, for at se, om det konstant bliver værre.
Men for at besvare dit spørgsmål kan du bestemt pege på det tidspunkt, du ønsker. Du har denne ting, der kaldes Historiebrowser - og jeg brugte den slags lidt - men dybest set uanset hvilket tidspunkt du vælger, uanset dag i den kalender, du vælger, kan du gå direkte til det tidspunkt.
Lige nu ser jeg den 15. november kl. 19:05, og vi kan se på specifikke forespørgsler til det tidspunkt. Hvis jeg havde nogen, der kørte dårligt i betragtning af det tidsvindue, ville vi være i stand til at se på sessionens detaljer, der er specifikke for det tidsvindue for at se, hvilke sessioner der kørte. Jeg mener, der er en hel række data her, og som sagt, den sværeste del, virkelig, er måske 30 minutter at lege med konsollen og finde ud af, hvordan man gør det.
Men når du først er klar over, at de fleste af dataene her er i dette bånd, og de er divideret med disse faner, og hver fane har sit eget sæt dynamisk skiftende knapper, der vises, hver gang du klikker på det, så hvad enten du ser på reelle- tidsforhold eller ting der skete i sidste uge, det er den samme proces. Det er dybest set, jeg ser lige nu den 15. november, men jeg kan lige så let se på det virkelige tidspunkt bare ved at klikke på den knap. Og jeg vil interagere med dataene på samme måde.
Men for at besvare dit spørgsmål, ja, der er mange forskellige måder at se historiske oplysninger på, og det gælder også forespørgsler selv.
Robin Bloor: Jeg kan se. Det er meget imponerende. Og jeg elsker det faktum, at vinduerne synkroniseres, selvom det slags er blevet temmelig nødvendigt i noget, der beskæftiger sig med data i realtid i dag.
Bullett Manale: Ja. Jo da.
Robin Bloor: Her er bare et informationspunkt, som jeg faktisk ikke ved svaret på. Som dine tilbud - SQL Server og skyen - kan du pege på skyen under Ratio?
Bullett Manale: Det kan du. Du kan pege dette under skyen. Når du faktisk tilføjer tilfælde, vil det spørge dig, om det er RDS eller Azure. Nu vil der være nogle begrænsninger baseret på hvad der udsættes for os fra skyen, så der kan være en - der er en lille smule forskel med hensyn til hvad vi kan overvåge, simpelthen fordi instrumenteringen, i nogle tilfælde, ikke er 't der for os at samles, baseret på hvad Microsoft afslører.
Nu, hvis det er noget i, ved du, infrastruktur som platform, som, du ved, eller EC2 eller noget lignende, er det overhovedet ikke et problem. Vi får alt. Og mens vi arbejder med Microsoft, og vi arbejder med Amazon; vi arbejder for at afsløre disse oplysninger mere detaljeret. Men absolut ja, vi støtter disse miljøer.
Robin Bloor: Okay, det er interessant. Nå, jeg overleverer Dez, som jeg er sikker på, vil kaste dig spørgsmål fra en anden retning.
Bullett Manale: Okay.
Dez Blanchfield: Tak. Jeg har to meget hurtige dem til dig. Jeg tror, du ved, den første er, skalaerne, du ved, jeg tror, en af de ting, der slår mig, er, at det generelle tema for forestillingen har en tendens til at være noget, som vi tænker på, når vi bliver meget store, meget store, meget stor og bred og terabyte af data. Når jeg så demoen, slog det mig som dette er noget, der faktisk gælder selv de meget små miljøer, som bare at få performance hits.
Hvilken form for spredning ser du i brugen af dette, og tror du, det er, ved du, tror du, det er et værktøj, der har et godt, ved du det - efter min mening gør det det, så jeg synes det er et ja - men jeg er bare ivrig efter at se, hvad du ser. Mindre organisationer har de samme samtaler og leder efter et værktøj til at gøre dette, eller er det virkelig noget i den større ende af byen?
Bullett Manale: Det er sjovt - det er et godt spørgsmål. Det er lidt af en blanding, men jeg vil sige, at vi har et væld af små kunder. Og når jeg siger små kunder, mener jeg, du ved, køb af et til fem eksemplarer til licens til at administrere. I nogle tilfælde har de måske 30 forekomster, SQL, fortrinsvis, og de er kun virkelig interesserede i de fem virkelig, virkelig vigtigt nok til at investere i et værktøj som dette, for disse fem tilfælde.
Men virkeligheden er, at selv de mindre butikker, har du en håndfuld SQL-servere derude. I de fleste tilfælde eller i mange tilfælde er den lille butik meget, meget afhængig af disse databaser, på grund af, du ved, hvad de gør. Og det gør de ikke, de kan ikke lade det gå ned. De kan ikke, du ved, de skal have et værktøj.
Den anden side af denne mønt er, at de i nogle af de mindre butikker ikke har dedikerede DBA'er, så den fyr, der er den smarteste fyr i rummet, eller den mere tekniske fyr i rummet ender med at blive den tildelte DBA. Og i den situation er de bestemt på udkig efter nogen hjælp, og dette værktøj vil naturligvis også hjælpe dem i den forbindelse.
For dine større miljøer, som jeg tror, det var Dez, der nævnte det - eller Robin, jeg er ikke sikker - men, du ved, de større miljøer, ville du blive overrasket over, hvor mange DBA'er de har, jeg mener, vi ' snakker enorme antal tilfælde af SQL, og du har bogstaveligt talt håndfulde DBA'er, der har til opgave at være ansvarlige for dem. Og så ud fra det perspektiv, de fyre, du ved, de leder efter noget hjælp, fordi de ikke har ressourcerne virkelig tilstrækkeligt nok til virkelig at hjælpe dem, og så et værktøj vil hjælpe med at udligne noget af det.
Og så ser vi også det ganske lidt, hvor, du ved, du har tre fyre, der administrerer 200 tilfælde. Og så kan du forestille dig logistikken for det, hvis du ikke har et værktøj som dette, for at prøve at finde ud af, når der endda er et problem. Det vil ikke være en proaktiv måde, jeg kan forsikre dig. Så forhåbentlig svarer det på dit spørgsmål. Ja.
Dez Blanchfield: Det gør det, ja. Det strejkede mig - og jeg tror, at Robin slags henvist til det - men, du ved, den slags løfte, som du beskriver, da du gjorde demoen, mener jeg, de er ikke eksklusive til meget store miljøer. Du ved, du kan købe en fælles platform, der er designet til én ting og placere den i et delt databasemiljø for noget andet, og det vil bare straffe hele miljøet.
Den anden ting, der ramte mig - det er ikke så meget et spørgsmål, bare en observation, men jeg vil dog føre det til et spørgsmål - og det er det, ved du, når organisationer allerede har investeret i deres infrastruktur og deres platform og deres database og serverne og infrastrukturen omkring det, og de vil købe et produkt, uanset hvad det måtte være - en HR, en ERP, et BI-værktøj - de har allerede slags gjort en ret stor investering.
Hvilken slags respons ser du, når du har en samtale med mennesker, og de er klar over, at de har et præstationsproblem, men de føler, at de nu er nødt til at foretage endnu en investering for at komme til det? Er der et punkt, hvor de er klar over, når du først har demonstreret det, at de denne ting er en no-brainer, og det er ikke så meget en salgsgrad, men det er mere en epiphany. Det er bare, du ved, ”Vi vil straks se fordelene ved dette.” I modsætning til, at vi bare skal sælge produktet? Det ser ud til, at det sælger sig selv, og ROI springer bare ud af siden.
Bullett Manale: Ja, og det er sjovt, at du siger, at fordi hvad der ofte vil ske, er, at nogen, som en DBA eller endda salgsrepræsentanterne, kommer, og de siger: ”Hej, disse fyre vil gerne se et lignende ROI-ark på dette. ”Og mere som a, noget på papir, som vi ville sende til dem. Og demoen er altid 10 gange bedre, især fordi du kan gøre det med DBA'erne selv, fordi–
Dez Blanchfield: Ja.
Bullett Manale: Som du sagde, sælger produktet sig selv. Det er virkelig svært at lægge en ROI på et stykke papir og sige, ”Okay, hvor mange klik har en DBA typisk, ved du, klikker du inden for en time?” Som det vedrører sikkerhedskopier, du ved, eller hvad sagen måtte være, du ved? Og når du prøver at lægge det på et stykke papir, er det virkelig svært at gøre det. Men når du får nogen, og du viser dem produktet, og de ser det, er det præcis, hvad du sagde.
Folk indser værdien af det. Fordi det ikke kun hjælper dem med at forstå og tage bedre beslutninger, men det er også, det hjælper, du ved, dem til ikke at være den onde fyr. De kan være de første, der ved; de kan rette problemet, før det nogensinde endda identificeres, at der var et problem.
Den anden del af det er, at du, som DBA, hvad enten det er en, du ved, reel eller opfattelse - og jeg tror, det er opfattelse - du ejer præstationsproblemerne, virkelig. Du er den fyr, der får fingeren rettet mod dig, når forestillingen går ned, og virkeligheden er, at det kan være udvikleren, der virkelig forårsager problemet.
At have et værktøj til at kunne sige, “Hej, dette er ikke mit problem, jeg er nødt til at være i stand til at tage dette til udvikleren, og de er nødt til at rette dette, ” eller, du ved, i disse linjer. Det er en dejlig måde at være i stand til at have noget i dit arsenal for at være i stand til at sige, "Det er her, det virkelige problem er." Ved du?
Dez Blanchfield: Ja. Den sidste for dig, og den ting, der slår mig, når vi kiggede på dette, da vi gik igennem det, var, at vi ofte når vi tænker på præstationsspørgsmål, har en særlig færdighed. De kommer med 20 års erfaring, de ser på det, og de slags, du ved, den klassiske vittighed fra den fyr, der går ind i ingeniørbutikken og har en lille lille hammer og rammer maskinen på det rigtige sted og derefter siger, "Det er en $ 15.000-løsning", og folk går, "Vi betaler ikke for det, " ved du, fordi det er fem minutter af arbejdet. Og han siger, "Nå, det fem minutters arbejde tog 15 års erfaring at løse, og det sparte dig millioner."
For mig ser det ud som om, du ved, der er en midtproces med, at folk går igennem denne ting og siger: ”Okay, bring de specielle færdigheder ind, rett problemet, det vil forsvinde.” Men hvad de har gjort så er de har lige lagt en band-aid på det, ikke? I modsætning til et scenarie, hvor, fra hvad jeg kan se her, hvor når dette går ind, ja, de muligvis har adresseret nogle præstationsproblemer, som de troede, de havde oplevet, men det ser ud til, lige for mig, bare at have denne 24 / 7 slags, du ved, sæt øjne, der ser miljøet i realtid.
Du ender med at slippe væk fra scenariet med DBA'er, der bliver vågnet klokka fire om morgenen, fordi rapporter kører. Er det tilfældet - og måske er det retorisk - men er det således, at folk hurtigt skifter fra at kigge efter at investere i et produkt for at få det til at løse et bestemt problem, men så bliver det generelt bare en del af DNA'et?
Bullett Manale: Ja, og det varierer fra sted til sted, men jeg mener, jeg har nogle folk, der oprindeligt købte produktet, ligesom allerede i 2006, og de har været i tre forskellige job hos forskellige virksomheder, og de er gået ind, og når de går til det næste firma, reklamerer de for dette som noget at få, fordi de har en arbejdsgang. Og kalde det det, jeg hader at kalde det det, men, du ved, at arbejdsgang involverer dette produkt, og de er vant til det dagligt, og det hjælper dem, og så de ikke vil lære noget nyt.
Men absolut. Jeg mener, det meste af tiden får vi folk til at downloade dette produkt, det er ikke fordi de har et budget, og at de går ud, og de siger: ”Hej, vi har dette ydelsesbudget, vi er nødt til at gøre et bevis på koncept, og vi er nødt til at træde ind og finde ud af, foretage en evaluering og alt det der er. ”Normalt hvad der sker er, at de har et problem på et eksempel på SQL, og de leder efter hjælp til ordne problemet. De går og henter vores værktøj, de får problemet løst, og så er de klar over, at dette, selve værktøjet vil gøre mere end bare at løse det problem, de havde på det tidspunkt, at det faktisk ville hjælpe dem med at forbedre den samlede ydelse og forhindre, at andre problemer sker, når de går videre. Og det er helt sikkert. Og du kan bestemt fortsætte med at bruge dette værktøj til kontinuerligt at indstille miljøet, fordi du altid vil være i stand til at se ikke kun hvad der skete lige nu, men hvad der skete i sidste uge, sidste måned, sidste år, og sammenligne det med hvad der sker i morgen. Du ved? Den slags ting.
Dez Blanchfield: Ja.
Bullett Manale: Så sikker.
Dez Blanchfield: Perfekt. Så du har nævnt, du har nævnt noget om - jeg vil bare slå op, inden jeg giver mig tilbage til Eric for at lukke. En af de ting, jeg altid er interesseret i, er, ved du, hvordan får folk fat i det? Du nævnte at downloade den. Hvad er 30-sekunders resuméet af, hvordan de får fat i det, få en kopi, drej den op og leg med den, og hvad de muligvis har brug for infrastrukturmæssigt, bare for at få et eksempel.
Bullett Manale: Så det bliver, du går til IDERA (idera). Com. IDERA.com er firmaet, og hvis du rammer det websted - og jeg faktisk kan vise dig her - ved jeg ikke, om jeg stadig deler min skærm, men hvis du går til siden Produkter, så gå til Diagnostic Manager-link, der vil være en lille download-knap, og du kan bare downloade build, når du har udfyldt dine oplysninger. De beder dig om 32- eller 64-bit-opbygningen, og du er klar til løbene, som de siger.
Dez Blanchfield: Og vil det køre på en bærbar computer, så nogen kan lege med det, eller har de brug for at indlæse den på en server et sted?
Bullett Manale: Nej, nej. Det, jeg viste dig i dag, kørte faktisk alt fra min bærbare computer. Nu har min bærbare computer 32 optræden og 8-core processor, men det er stadig en bærbar computer. Men det behøver ikke nødvendigvis at have så mange ressourcer for at besvare dit spørgsmål. Selve evalueringen er god i 14 dage, men du er mere end velkommen til at give den en længere prøve. Hvis du bare ringer til os, kan vi udvide det til dig, hvis du ønsker det.
Dez Blanchfield: Jeg synes, det burde være noget at fjerne, fordi jeg bestemt vil gøre det. Jeg synes, du ved, ud fra tingene ser det ud til, at jeg er en no-brainer at downloade den og lege med den. Gå sandsynligvis til et af dine miljøer og se bare, hvad du kan se, for jeg formoder, at - ligesom alt, hvad jeg har set i en databasebaggrund i de sidste 20+ år, som ældes mig - når du først ser hvad der er under hætte, det er forbløffende, hvad du er klar over, at du kan rette hurtigt og bare få små gevinster i ydelsen.
Fantastisk, tak for demoen. Det var virkelig godt. Tak for hele tiden for at diskutere spørgsmålene.
Bullett Manale: Du er velkommen. Tak for-
Dez Blanchfied: Eric, jeg vil give Dem tilbage.
Eric Kavanagh: Ja, vi har et rigtig godt spørgsmål fra publikummedlemmet. Du talte slags om dette i din præsentation, og jeg tweetede faktisk om dette, fordi det var et godt tilbud. Du sagde, at du ikke ønsker at bruge et værktøj til at overvåge ydeevne, der påvirker din præstations negativt.
Bullett Manale: Right. Det er rigtigt. Det er slags en vigtig del af et værktøj til overvågning af ydelser, er det ikke forårsager ydelsesproblemer. Lige præcis.
Eric Kavanagh: Præcis. Det er ligesom de darned - det er som de antivirale programmer, der bare kan ødelægge systemer. Jeg mener, jeg har brugt en række forskellige teknologier til radio- og tv-spredning, hvor antivirusprogrammet går ind og vil beskære din strøm. Så der er ting, der sker, som du ikke forventer, men spørgsmålet, det vedrører den specifikke kommentar, du kom med. Og hvilken slags performance hits ser du? Er det to procent, er det fem procent, er det en procent? Har du nogle numre, du kan smide på os?
Bullett Manale: Nå, jeg mener, udfordringen med dette spørgsmål er, at du ved, en del af den diskussion, vi talte om tidligere. Jeg kan give dig det - det er normalt omkring en til tre procent for at besvare dit spørgsmål. Men der er flere forklaringer, som jeg tror ville være påkrævet, hvilket er, vi giver dig en masse måder at være i stand til at fortælle værktøjet, hvad du vil overvåge, ikke? Og så går det tilbage til det. Nå, måske vil jeg gerne have en prøve på alle de forespørgsler, der kører. Så jeg vil have et værktøj, der er fleksibelt nok til at være i stand til at tænde det, så jeg kan se det.
Og så inkluderer en del af denne fleksibilitet, du ved, at der er en omkostning for det. Hvis jeg har brug for at indsamle flere data, fordi jeg vil have en prøve på alle forespørgsler, der kører i det sidste, ved du, 20 minutter, kan jeg tænde for det, og det kan gøre det. Og så, men generelt set, ja, en til tre procent er det, vi ser med hensyn til omkostninger. Men det vil variere, og det meste af det vil være afhængigt af dine ting, som du tænder og slukker for, hvad angår dine tærskler, hvor meget data du vil indsamle, dine pollingintervaller, alle den slags ting, der binder sig til at.
Faktisk, hvis du går ud til selve det instans, du administrerer, er en af de ting, du ser, at vi har flere pollingintervaller, som du kan specificere. Og det er simpelthen fordi vi vil, du ved, jeg behøver ikke at tjekke hver - Hvis jeg vil foretage en hjerteslagskontrol på en instans, behøver jeg ikke at afstemme CPU'en og alt det andet, hvis jeg ' m gør det hvert 20. sekund. Så du har flere pollingintervaller, som du kan specificere.
Du har også, som jeg sagde, din forespørgselsovervågning, som du kan specificere. And this can be done for each instance independently, so you can really cater to that specific instance in terms of what you want to monitor. For my wait statistics and wait monitoring, I can turn that on or off. And I can tell it to capture everything, I can tell it, you know, what I want to capture and when I want to capture it. So a lot of that will also– You have to take into consideration what you're doing, in terms of what you're telling the tool to monitor.
But generally speaking, what I would say, is, like I said, around one to three percent is what we see. We've been selling this tool a long time – since, like I said, about 2003 or 2004 – and we've got thousands of customers, so I can assure you that, you know, we don't have– we try our best not to cause performance problems in the name of performance.
Eric Kavanagh: Yeah, that's really good information. I just thought that was a brilliant quote because, you know, again, you don't want to defeat the purpose of what you're trying to accomplish, right?
Bullett Manale: Exactly.
Eric Kavanagh: And I appreciate Robin's question, too; this really is an excellent platform for helping DBAs understand the many different aspects and dimensions and layers of what we're talking about. And I think the concept of conversation with your data is highly appropriate here, because, to your point earlier, you're not gonna figure it out on the first try, usually. You need to spend some time looking at the data, looking at historical data, doing that synthesis in your mind. And that's the job of the human, right? The job of the profession that sits back there and takes heat from the business on a fairly regular basis, to get that job done and to keep the trains running on time, right?
Bullett Manale: Absolutely.
Eric Kavanagh: Well, folks, this has been another fantastic event. If any question you asked was not answered, by all means, let me know. Send an email to . We do archive all these events, so you can always go to InsideAnalysis.com to find the archive, or go to our partner, Techopedia.com. If you look on the right-hand side of their page, you will see Events, and the webcasts listed there. If you click on More Events, you can see all of the webcasts that we do listed there, past, present and future.
And with that, we're going to bid you farewell. We've got five more webcasts for the rest of this year, folks. We may schedule one more. But otherwise, it's going to be on to 2017. The ed cal is out. Let us know, and if you have someone that wants to showcase their technology, send an email to .
With that, we're gonna bid you farewell, folks. Thanks again for your time and attention, we'll talk to you next time. Pas på. Bye-bye.