Performance-spil: sige farvel til forsinkelse

Af Techopedia Staff, 9. maj 2016

Takeaway: Værten Eric Kavanagh interviewer Mark Madsen, Dez Blanchfield og Bullett Manale om latenstid og præstation.

Du er ikke logget ind. Log ind eller tilmeld dig for at se videoen.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved hjælp af indstillingerne til højre. For info om, hvordan vi samarbejder med branchepartnere, klik her.

• Profil
• Internet side

Eric Kavanagh: Mine damer og herrer, hej og velkommen igen til Hot Technologies! Ja bestemt! Jeg hedder Eric Kavanagh, dette er vores Hot Tech-show, et partnerskab med vores gode venner fra Techopedia. Hop online til Techopedia.com for alt det nyeste inden for det brede felt af virksomhedsteknologi; de dækker selvfølgelig også forbrugerudstyr. Vi fokuserer på virksomheden her på vores program, så det er hvad vi gør i dag.

Der er et sted om dit virkelig og nok om mig, slå mig op på Twitter @eric_kavanagh, jeg elsker Twitter, jeg elsker at tjekke det, det er en fantastisk måde at holde kontakten med mennesker og have gode samtaler og one-on -en samtaler.

Så hvad taler vi om? Dette år er varmt, dette er et helt univers af muligheder, som vi ser på i dag i en verden af ​​informationsstyring, og det, vi taler om i dag, bliver spørgsmål, det vil fremskynde forespørgsler.

Jeg tror, ​​jeg har glemt at nævne titlen, "Performance Play: Say farvel til Latency." Nå, hvem vil have forsinkelse? Ingen vil have forsinkelse, forsinkelse er, når du sidder der, klikker på knappen og venter på, at der skal ske noget, og ingen vil have det. Børnene kan ikke lide det, de synes ikke det er cool, de voksne kan heller ikke lide det. Vi er alle blevet forkælet af internetets hastighed, og vi vil have ting hurtigt, vi vil have ting nu, og vi skal tale alt om det i dag på vores show.

Analytiker Mark Madsen er med os i dag fra Third Nature, en af ​​vores stamgæster. Vores nye dataforsker, Dez Blanchfield, kalder ind fra Sydney, Australien. Og så er Bullett Manale, ja, det er hans navn, det skal faktisk være to T'er. Bullett Manale er på som vores gæst fra Idera, et meget, meget interessant firma, gør en masse ting. Jeg ved allerede om dem, hvoraf de ene købte et firma, der hedder Precise for et stykke tid tilbage. Jeg kendte deres administrerende direktør ved navn Zohar Gilad, hvordan er det med et navn? Han var et dumt af en smart fyr.

Men folkens, du spiller en betydelig rolle i denne webcast i de spørgsmål, du stiller, så vær venlig ikke at være genert, send dine spørgsmål til enhver tid - du kan gøre det ved hjælp af Q & A-komponenten i webcast-konsollen, det er dernede i nederste højre hjørne. Du kan også chatte med mig, så chatter jeg den over til højttalerne. Vi har allerede nogen, der ringer fra Italien, så ”Ciao, ciao. Kom i gang? ”Okay, med det at jeg skubber Marks første linje, vil jeg overdrage dækket til Mark. Mark, du har nu WebEx. Tag det væk, gulvet er dit.

Mark Madsen: Tak, Eric. Jeg vil dog ikke starte i midten, men jeg begynder i begyndelsen. Så bare et par kommentarer til at starte diskussionen med Dez og Idera, en slags tilstand af staten med udvikling, og databaser og operationer. Og du ved, hvis du ser på dette, har vi denne slags to verdensproblemer stadig på database- og applikationsmarkedet, fordi udviklere betragter DBA'erne som de mennesker, der besidder dem. Du er nødt til at bygge datamodeller, du kan ikke have adgang til det, du kan ikke oprette den ting, du kan ikke placere et indeks i hver kolonne i hver tabel i databasen for at gøre det hurtigere. Og selvfølgelig, hvorfor har vi brug for modellerne? Det er bare datastrukturer, hvis vi ændrer dem, kan du ikke bare skrive dem ud i en serieformet form?

Problemet er, at udviklere kender kode og applikationer, men to ting, som de ofte ikke ved, er samtidighed, samtidig programmering og databaser og operativsystemerne under dem. Efter at have været en kerneludvikler og operativsystemer og databaser, kan jeg sige, at samtidighed og parallelisme er virkelig hårdt, og så mange af de ting, du lærer at få en god ydelse ud af din kode, virkelig begynder at falde fra hinanden, når du er arbejder med en database. Og ydelsen ser godt ud, testmiljøet ser godt ud, og spørgsmål og svar-miljøet, og så rammer det det virkelige system, og så er det pludselig ikke så godt. Fordi den er mangefacetteret, hvordan koden fungerer med databasen, hvordan den fungerer med miljøet og virkelig enkle små praksis kan have drastiske effekter afhængigt af hvilken skala du kører.

Og når du begynder at tale om eksterne applikationer, kan naturligvis eksterne applikationer, webapplikationer, være rigtig vanskelige, fordi tingene er store, indtil de pludselig sidder fast, og det er de ikke. Du rammer disse interessante plateauer, der kræver en masse nuance at forstå.

Tingenes bagside er DBA-synet. DBA's opfattelse er, at der er operationer, de bruger størstedelen af ​​deres tid, 80 til 90 procent, i ops, og måske 10 til 20 procent, der beskæftiger sig med de udviklingsmuligheder, der foregår på forhånd. Fra dette perspektiv betaler du enten nu eller betaler du senere, og hvis du bruger al din tid på forhånd, vil du have en meget bedre chance senere, i modsætning til udvikling, der har tendens til at udforske en funktion plads og forsøge at finde ud af, hvordan man bedst gør tingene. Og så har vi problemer, og nu har vi metoder, der er uforenelige - kontinuerlig implementering, rullning af dine apps, når de er klar, udfører kodepresser med jævne mellemrum, arbejder i en butik, der praktiserer dev ops. Denne slags ting fremskynder udviklingen, men al praksis omkring databasen og hvad DBA'er gør, og hvad systemledere er blevet uddannet til at gøre, IT-ops praksis har ikke holdt trit.

Hvis du tænker over det, fungerer de fleste DBA'er under et miljø med ændringskontrol kontra et kontinuerligt implementeringsmiljø. Det handler om stabilitet og kontrol kontra hastighed på ændring og reversibilitet. Kontinuerlig implementering, hvis du ikke kan komme ud af forandring, er du i problemer, så alt skal bygges for at være let reversibelt og kodeudskifteligt, hvilket ikke er den måde, relationel database, udviklingspraksis og ledelsespraksis har fungeret .

Du løber også ind i disse problemer med at skulle være mere proaktiv, hvis du kan som DBA, for når du hører om et problem, udfylder hundrede tusinde mennesker klageformularer på dit websted. Det giver dig brug for nogle nye ting, som du ikke kommer ud af dit gamle miljø. Du ved, ting som bedre overvågning og alarmering. På samme tid er databaserne blevet flere, vi har flere applikationer end nogensinde til at støtte flere ting end nogensinde, de er inde, de er udenfor, de er overalt. Og mere uafhængige datasæt til analyser, folk starter databaser overalt, fordi det selvfølgelig er let nu, du kan konfigurere en virtuel maskine. Hvis du har en skyudbyder eller en intern sky, kan du øjeblikkeligt poppe op, og dette ændrer hele din indkøbssti.

Den gamle anskaffelsessti var: ”Jeg har tid til at få en server, skubbe den i et rack, tildele plads, få lager, få databasen installeret og gøre ting, ” mod nogen, der stryger et kreditkort og går på fem minutter. Hvis du gør det, fungerer det moderne udviklingsmiljø i et tempo, der er meget anderledes, og det er derfor let at oprette databaser, og det skaber bare dette spredningsproblem, som intet, vi har set før. Og dette har foregået i ti år nu, dette er ikke nyheder for nogen, men det betyder også, at driftsmiljøer er vokset i kompleksitet.

Hele klientservermiljøet har virkelig ændret sig, fordi det ikke længere er en klientserververden. Dengang havde du en server, du havde en database, hvis der var noget galt, du vidste, hvilken server du skulle gå til, vidste du hvordan man administrerer ressourcerne på den, fordi bedste praksis var en database, en server. Virtualisering begyndte at bryde det fra hinanden, skyder det endnu mere, fordi det, du synes er en databaseserver, bare software. Så miljøet er ikke rigtigt. Det er det, der indeholder miljøet, der er virkeligheden, og det kan være et rack med klinger eller en stor server, der er skåret op i stykker, du ved ikke rigtig.

Alt omkring databaseadministration og performance management, og hvilke databaser der er bygget op omkring stram kontrol med en server, eller en håndfuld servere og et par databaser, kan du ikke kontrollere alt. Du sidder der på en maskine, men båndbredde kan ikke nemt deles op af de virtuelle ledere, og alt kan derfor være fint med hukommelse og CPU, men du er flaskehalset på en ressource, der ikke kan håndteres, og derefter når du prøver at ordne det, den gamle model ville have været i hårdt arbejde, fået en større server og gøre sådan noget, nu kunne det være rigtig enkelt, bare tilføje virtuelt kursus, bare tilføje hukommelse til VM og det er løst. Men hvad sker der, hvis din VM er på en overfyldt server og skal migrere? Eller hvad sker der, hvis du er på størrelse med et AWS-system, og den maksimale størrelse er nået, hvor skal du hen nu?

Så du har alle disse problemer, hvor miljøet er en del af databasen nu, du pakker et miljø med en database, alle de specielle ressourcer, alt i applikationen, det er en del af konfigurationen, konfigurationen bliver skubbet derude. Dette er fra databasemiljøet, det er meget sværere at administrere og kontrollere.

Hvis du ser på, hvad databasesentrene har gjort, har de siddet på deres hænder, ikke? Vi er gået væk fra denne idé om at behandle databaser og servere som kæledyr. Servere har navne, du behandler dem som om de er individuelt unikke ting, du behandler dem som kvæg, det er at styre en besætning. Og problemet med at styre besætninger er, at hvis du ikke kontrollerer dem, kan de til sidst stemme, og et stampede er ikke en god ting. Vi har brug for bedre overvågningsværktøjer, vi har brug for bedre måder at tackle disse ting på og vide, hvad der er blevet påvirket. I den gamle model var det lettere, fordi dine ops og alle dine kontrolsystemer fortalte dig det, men når dit servernavn er en UPC-kode, er det lidt svært at finde ud af.

Du har ikke råd til falske advarsler, du har ikke råd til ting, der siger: ”Der er et problem med denne maskine, og den maskine er vært for 30 databaser.” Du har ikke råd til at have ting, der ikke giver dig nogen historie. Overvågningskonsoller er gode, når de lyser, men hvis det røde lys bliver grønt igen, og du ikke ved hvorfor, og du ikke har nogen historie at gå tilbage til for at se, hvad der førte til det, og hvad sammenhæng var, du er i problemer. Vi har brug for systemer, der overvåger for os, vi har brug for bedre overvågning, der håndterer de kursive intermitterende problemer, der opretholder datahistorikken.

Bedre ting og enkle metrics-tærskler, der får os nøglemetrik, men led ikke os direkte i, hvad der er normalt, hvad der er unormalt, og hvor ofte disse problemer opstår. Det, vi virkelig taler om, er en kombination af overvågningsmiljø og håndtering af ydeevne, og leverandørerne har siddet på deres hænder. De har ikke givet os bedre værktøjer. Vi har systemer med mere CPU og hukommelse, end vi ved, hvad vi skal gøre med det hele, og alligevel er vi stadig afhængige af manuelle indgrebsmodeller, vi har ikke bragt maskinen til at fungere, til at guide os, for at få os til et punkt med problemer, vi er ikke kommet til denne nye stil, som er, "Der er et problem her, du kan gøre dette for at løse det, " eller, "Der er et ydelsesproblem, det er faktisk med denne specifikke SQL-sætning, her er tre ting, du kunne bruges til at løse den SQL-sætning. ”Anvendelse af heuristik, anvendelse af maskinlæringsmodeller, der kan se på dit systems brugsmønstre for at få øje på problemer og undgå falske advarsler. Brug af maskinen til at gøre, hvad maskinen gør bedst, for at udvide DBA eller til at udvide den person, der har at gøre med ydelsesproblemer.

Det er den nye måde, i modsætning til den gamle stil. Der er et problem med denne database, tingene er langsomme, og derfor har vi nye teknikker, nye måder at gøre det på, og vi bør anvende dem, og det er der, hvor markedet er på vej. Du ser, at det begynder at vokse op, ikke med de store leverandører, men med tredjepartsfirmaer, og dette spejler noget, der skete for 20 år siden, da databaseleverandørerne ikke leverede en enkelt ting til at hjælpe med at styre systemerne. Så det er slags, hvad markedsretningen er, og med det vil jeg gerne vende det tilbage til Eric.

Eric Kavanagh: Okay, jeg overleverer det til Dez. Og Dez, tag det væk, gulvet er dit.

Dez Blanchfield: Tak, Mark. Du har gjort et fantastisk stykke arbejde med at dække den tekniske komponent af det. Jeg vil komme til det fra en lidt anden vinkel for at fremhæve, hvad der er sket i resten af ​​verden, så vidt det påvirker virksomhederne og databaserne omkring dem. Lad mig bare springe til mit første lysbillede.

På bagsiden af ​​det, du lige har dækket fra den tekniske side af tingene og udviklerens side af tingene, ser jeg virksomhederne nødt til at konfrontere udfordringen med data og databaser især, og vi har tydeligvis haft dette betydelige skift mod dette koncept med big data, men databaser er faktisk stadig hjertet og sjælen i, hvor organisationer bevarer deres forretningsoplysninger, og det er fra hoveddøren hele vejen igennem til back office. Hver del af organisationen er berørt af en database af en eller anden form og drevet af en database, og meget sjældent går jeg enten i projektdiskussioner eller en form for innovativ strategisk samtale i en organisation, hvor emnet for databasen eller databasesystemet dukker ikke op, og der er altid spørgsmål omkring de typer ting, vi netop har hørt om, hvad angår ydeevne og sikkerhed, og hvordan kommer udvikling nærmer sig denne udfordring, og hvor passer databaserne, og vores opmærksom på miljøer og anvendelse miljøer snak med, hvad med enheder og mobilitet?

Det er stadig et meget, meget varmt emne, og det har været et i lang, lang tid inden for det store skema med ting, så vidt moderne teknologi går. På det tidspunkt tror jeg, det er en kendsgerning, at næsten alt, hvad vi gør i vores daglige liv, vores daglige liv, det vil sige, nu understøttes af en form for database. Når vi tænker på alle tingene omkring os, uanset om det er en regning, der hver dag kommer i posten for en eller anden service, vi køber, udskrives det uundgåeligt af et system, der taler til en database, og vi er derinde. Vores telefoner har databaser med dem med kontakter og opkaldslogger og andre ting.

Uanset hvor vi går, er der en form for database bag samtalen og de systemer, vi bruger, og oftere er de temmelig gennemsigtige for os, men faktum er, at de er der. Så jeg tænkte, at jeg bare hurtigt ville dække, hvorfor dette er blevet lidt af et problem i en meget kort periode. I begyndelsen kom databasekonceptet fra denne dejlige herre, Edgar Codd. Mens han arbejdede hos IBM, ændrede han verdenen så vidt datastyring går ved at skabe et koncept, som vi nu omtaler som en relationel database.

I begyndelsen var databasen en database, og livet var godt, det var temmelig ligetil både i kolonner og referencer osv. Og tabeller, og udvikling af software var ret ligetil, og ydelsen var virkelig ikke så stort problem - det var en ny spændende teknologi. Vi fik adgang til databaserne gennem en form for terminal, og du kan kun virkelig skabe så meget ødelæggelse i slutningen af ​​en 3270 terminal på en mainframe, og altid andre typer terminaler, disse andre systemer fulgte med. Og i de fleste tilfælde lignede de gamle stilterminaler meget, hvad webmiljøer er nu, og det er, at du udfylder en formular på skærmen på selve terminalen og rammer Enter og slukker for at den ville gå, det ville skyde af som en pakke, som en anmodning, og back-end-systemet vil håndtere det. Det er i det væsentlige, hvad der sker i en webbrowser i disse dage, når du indtaster et link i en webbrowser og den form, det normalt ikke går i realtid tilbage til systemet, selvom det med AJAX i disse dage ikke er helt sag.

Men så skete der noget, fremtiden ankom, og for nylig internettet, og næsten i går, i et sekund web 2.0, og lige rundt om hjørnet har vi tingenes internet. Og i processen med fremtiden, er databasens verden netop eksploderet, og interaktionen med databaser blev bare en ting, som vi alle gjorde som standard, det var ikke et tilfælde, at du ville gå et sted for at gøre noget, som at købe en billet til et fly og vil rejse til den anden side af planeten, var nogen nødt til at indtaste terminalen alle dine detaljer og gå ind i en database og udskrive en billet.

Næsten alt, hvad vi gør nu, hvad enten det er at hylde en førerhus på Google med en applikation, uanset om det er at hoppe på internetbank, alt hvad vi gør på en daglig basis, med et slags system, det drives af en database. Og da Internettet kom med, var det lidt lettere at bringe os, vores hverdag gennem en webbrowser, og derefter kom Web 2.0 med, og tingene blev mobile, og omfanget af ting bare eksploderede. Faktisk er min yndlingslinje i dette emne, at "Internettet tilsluttede alt, web 2.0 gjorde det mobil og socialt, og tingene blev meget, meget store, og nu har vi internettet og tingene og, og IoT … Yikes !!" Vi er ikke engang begyndt at forestille os virkningen af ​​Internet of Things, når det kommer til verden på databasesystemer.

Så i moderne termer er det, vi plejede at tænke på som en terminal, blevet disse ting, det er mobiltelefoner, det er forskellige slags tabletter, enten personlige forbruger- eller enterprise-grade storskærms-tabletter, det er bærbare computere og det er det traditionelle skrivebord i en eller anden form. I det ene billede kan du se næsten enhver form for interface, som vi nu bruger til at tale med databasesystemer og apps, der er drevet af dem, fra de små gadgets i vores hænder, der går rundt og vi ser ud til at være limet til, alle vejen igennem til de lidt større versioner og iPads og andre tablets og Microsoft Surfaces til hverdagslige bærbare computere, som altid er tilfældet i professionelle miljøer og så videre. Folk har en tendens til at få en bærbar computer og ikke et fast skrivebord, men de er den moderne terminal efter min mening og en del af grunden til, at databaser oplever alle slags udfordringer i ledelsesprestationsdelen af ​​vores liv, og ikke kun udvikling.

Så jeg antager, at det er en af ​​de største udfordringer, som virksomhederne stadig står over for på den daglige basis. Alle troede, databaser var vores eneste problemer, de er det ikke. Så hvad handler alt om? Nå, når vi går fra den ene ende til den anden med alle ting relateret til databaser, fra kommerciel forstand, og Mark's dækkede de tekniske komponenter meget, meget godt, men i kommerciel forstand, som en organisation, tænker vi på databaser. Vi beskæftiger os med tingene helt fra det grundlæggende design og udviklingsfronten. Når en virksomhed starter, vil de overveje at udvikle applikationer, udvikle en kapacitet eller endda implementere en eksisterende applikation i en eller anden form. En eller anden form for design og udvikling skal finde sted, og der skal tænkes meget på, hvordan disse databasesystemer skal implementeres, understøttes og styres, og forestillinger spores og så videre.

Integrationen af ​​databasemiljøet og applikationerne, og typerne af API, de typer af adgang, der leveres nu, bliver mere og mere udfordrende, mere komplekse. Daglig administration, support og sikkerhedskopiering, igen, dette er ting, som vi troede var løst, men så pludselig blev skalaen meget større, og tingene flyttes hurtigere, og lydstyrken er så meget større; Størrelsen af ​​miljøerne måtte databasesystemerne understøtte den hastighed, hvorpå transaktioner bevæger sig.

Tænk på en database i et meget, meget højfrekvent handelsmiljø, der er bare ingen måde mennesker kan holde styr på, det er bare en klynge af maskiner, der kæmper mod en anden klynge af maskiner for at udføre højfrekvent handel, køb og salg, og volumenet ved som disse transaktioner sker. Tænk på et moderne scenarie, som en tidlig udgivelse af en Netflix-film, hvor du ikke taler om bare hundreder eller tusinder, eller endda hundreder af tusinder, potentielt millioner af mennesker, der ønsker at se den film lige fra det andet, den er frigivet. Alle disse oplysninger indfanges, spores og logges og analyseres i en databaseplatform.

Og så er der den altid-på-verden, som vi lever i nu, 24/7, ikke bare følger solen, men der er altid nogen op ved midnat, der ønsker at gøre noget, og arbejdstider følger solen overalt i verden. Så oppetid og tilgængelighed er som standard, er et klima nu, at have et afbrydelse er virkelig ikke en acceptabel ting. Og redundans, hvis der er et præstationsproblem, eller hvis vi har brug for et vedligeholdelsesvindue for at udføre en opgradering eller en patch eller en sikkerhed, virkelig, er vi nødt til at være i stand til at skære fra et databasemiljø til et andet og gøre det problemfrit og automatisk.

Sikkerhed og standarder og overholdelse, vi har haft nogle temmelig store ting, der sker i den sene verden, især GFC, og derfor har vi en række nye udfordringer til at mødes omkring compliance og sikkerhed og matchende standarder, og vi har brug for at kunne rapportere om dem i realtid og ideelt set i en dashboardform. Vi ønsker ikke at sende et team med aber ud til et datacenter, der prøver på at finde ting, vi har brug for systemet til at fortælle os det straks, i realtid.

Og de to store sjove, som næsten ingen nogensinde snakker om, vi skubber dem generelt under tæppet og håber, at de ikke nogensinde hæver deres grimme hoved, men katastrofegendannelse og forretningskontinuitet - det er også disse ting, der skal det meste sker automatisk, hvis behovet opstår.

Vi kunne bruge dage på at tale om de typer ting, der kan gå galt i databasemiljøer, og at mennesker generelt har reageret, men nu har vi brug for systemer og værktøjer til at gøre det for os. Et eksempel er en dataovertrædelse, og når vi tænker på databaser, og jeg stiller dette spørgsmål ganske åbent i forskellige former: hvad sker der med databaser, når vi tager øjnene væk fra bolden, og noget kritisk går galt? Især hvis der ikke er et system, der ser ydeevne og sikkerhed og andre vigtige aspekter ved kørsel af databaser.

Det, der kunne ske, er dette, dette er et skærmbillede af nogle af de nylige overtrædelser i de sidste to til tre år. Uundgåeligt er disse alle kommet fra et databasesystem, og altid har der været noget problem inden for sikkerhed eller kontrol, eller adgang der er sket, og i øverste venstre hjørne ser vi på 152 millioner Adobe-konti, hvor alle detaljer af disse kunder blev overtrådt. Og hvis det var tilfældet med de passende værktøjer, der måske var på plads til at spore og fange hændelsen og kontrollere sikkerhed, har vi måske undgået nogle af dem, det første par hundrede poster, der blev stjålet, kunne have advaret os, og vi ville have stoppede de næste hundrede og halvtreds millioner.

Derefter kommer vi til det centrale punkt på hele denne rejse, taget os igennem, det vil sige: hvorfor har vi brug for bedre systemer? Hvorfor kan vi ikke bare kaste flere organer på denne ting, at vi godt og virkelig har krydset vippepunktet efter min mening, og bestemt tror jeg, at der er en sag, der har været bevis for sent, at kaste flere DBA'er, administratorer og flere mennesker på denne ting løser ikke problemet. Vi har brug for et bedre sæt værktøjer og et bedre sæt systemer.

Her er mine fem bedste grunde, som jeg mener understøtter dette, og de rangeres i rækkefølge af betydning, baseret på hvad jeg ser på tværs af disse private virksomheder og stater, der er styrede miljøer, de udfordringer, de står overfor med databasemiljøer, og styre dem.

Sikkerhed og overholdelse - nummer et. Du ved, at kontrollere, hvem der har adgang, hvor har de adgang, når de har adgang, hvor ofte de har adgang, hvor de har adgang til det fra. Potentielt de enheder, de faktisk har rørt ved, og de typer ting, de har set på, og den overholdelse, der går omkring det. At få mennesker til at køre rapporter 30 dage senere for at fortælle os, om tingene er okay, er ikke passende mere, det skal ske i realtid.

Ydeevne og overvågning - det ser ud som en ingen hjerne, men altid er det ikke. Uanset om vi bruger open source-værktøjer eller nogle tredjeparts kommercielle værktøjer, har vi altid ikke gået glip af båden på mange måder med de krævede typer overvågning af ydeevne og detaljerne der, og evnen til at reagere i tide .

Hændelsesregistrering og respons - det skal være en øjeblikkelig ting i realtid, og vi har altid brug for et system til at gøre det for os, eller i det mindste advare os hurtigt, så vi kan håndtere det, så de få problemer, der opstår bliver behandlet med hurtigt og ikke kaskade ud af kontrol.

Ledelse og administration - igen, vi tror, ​​at disse problemer er løst, de er det ikke. Målet med spørgsmål, som databaseteam står overfor, især DBA'erne, hvor et system skal tage sig af tingene for os, vi har ikke løst det problem endnu, det er stadig en rigtig ting.

Og lige fra frontend med design og udvikling, når vi begynder at bygge disse værktøjer, bygger vi databasemiljøer, er i stand til at kaste de relevante værktøjer til udvikling og test og integration, platforme. Dette er stadig ikke en let ting for os at gøre, og hele denne rejse, det driver os slags til den samme meddelelse, at i mine sind har vi brug for bedre systemer og bedre værktøjer til at hjælpe os med at levere de resultater, vi har brug for fra vores databasemiljø, så de virksomheder, der skaber værdi for vores kunder. Vi kan ikke bare fortsætte med at kaste flere kroppe og flere DBA'er, skalaen er for stor, hastigheden er for hurtig og lydstyrken er for høj. Med det Eric vil jeg måske vende tilbage til dig.

Eric Kavanagh: Jeg elsker det, vi har mange grunde dækket der folk, en masse potentielle kundeemner, og vi går videre og overleverer de nøgler til Bullett på kun et sekund.

Bullett Manale: Okay.

Eric Kavanagh: Åh, lad os tage det væk og Bullett, nu overleverer jeg det til dig, og ordet er dit.

Bullett Manale: Okay, tak. Jeg tror, ​​at der er blevet skabt mange gode point. Jeg ville bare hurtigt snakke et øjeblik om Idera, hvem vi er, og så hopper vi ind. Jeg skal tale om det værktøj, som jeg synes, en masse af det her vi snakker om, vi kan slags sæt og slags diskuterer nogle af de områder, hvor disse justeres med dette værktøj Diagnostic Manager-produktet.

Hvad jeg først vil gøre først, er bare at give dig lidt af en baggrund om, hvem Idera er; vi har eksisteret siden omkring 2003, og derfor er vi startet med bare SQL Server-værktøjer, og det er det, vi vil fokusere på i dag, er Diagnostic Manager-produktet. Men du kan se alle spande med ting, som vi har her, og vi har for nylig som nævnt købt Precise og gennem erhvervelse har vi også Embarcadero, og derfor har vi en ret god portefølje af produkter.

Med hensyn til præstationsovervågning, hvad angår SQL Server, er det produkt, som jeg vil tale om, som justerer disse emner, vi diskuterer, Diagnostic Manager. Nu er dette et produkt, der har eksisteret siden temmelig tæt på begyndelsen af ​​Ideras dage, og jeg har været heldig nok til at være en del af det siden omkring 2005. Og jeg har set en masse af ændringerne med hensyn til SQL Server, skifterne fra fysisk til virtuel, alt det, der er sket, og også DBA'ernes behov, når miljøerne vokser, og de slags ting.

Det, jeg startede med, var den typiske bruger af vores produkt, er DBA, og så når vi snakker med folk for første gang, potentielle kunder, er det mest DBA’erne, vi taler med. Vi taler ikke med IT-cheferne eller direktørerne, det kan på et tidspunkt komme til det niveau, men den første begyndelse er, at DBA har et problem, DBA forsøger at løse problemet, og mange gange vi Jeg skal downloade og prøve produktet som en del af det. Du får enten datahåndtereren eller DBA eller den fungerende DBA, den fyr, der er heldig nok til at være den mest tekniske i rummet, i nogle tilfælde. Nu, når du kommer til de større virksomhedsmiljøer, åbenbart, så får du fuldt udblæst DBA'er, typisk vil de være dem, der bruger værktøjet. Og jeg gik videre og tilføjede bare en lille blurb her fra Wikipedia. Den går typisk over DBA's ansvar, som Wikipedia siger, det er hvad de gør.

Hvis du gennemgår listen her, en masse af disse ting, vil jeg ikke læse den af, men du får en masse af de typiske ting, du ville tænke på, og så på en af ​​dem, har du overvågning og optimering af databasens ydelse, og det er en temmelig stor. Og hvad der er interessant, er, når du taler med DBA, det er altid dem, der får skylden først, når det kommer til problemer, og det er måske ikke rigtig deres skyld, men når der er et præstationsproblem, typisk med et program, der er bundet til en DBA-database, det er dem, der får skylden, så de leder altid efter grundene til, at det ikke er deres skyld. I mange tilfælde er det, hvad de kan bruge dette værktøj, Diagnostic Manager, til at hjælpe dem.

Men i slutningen af ​​dagen, hvis databasen ikke fungerer, betyder ikke meget af dette andet noget rigtigt, dine applikationer fungerer ikke, så betyder det ikke meget for mange af disse ting. Først og fremmest ønsker vi at være i stand til at sikre, at brugeren oplever den måde, vi kender det på, ikke mindskes, det er noget, som DBA'er altid stræber mod. Og jeg tror, ​​at hvis du slags ser på grundene til, at folk typisk køber og bruger SQL Diagnostic Manager-produktet, er en af ​​de første grunde, sandsynligvis ikke den forreste, ikke sidst eller mindst, men det er slags lige overalt, og afhængigt af hvem du snakker med, disse grunde, næsten en eller to af dem altid er, er der et slags behov omkring.

Men den første er bare at kunne have det centraliserede syn på forekomsterne som en SQL, som de administrerer. Og det sjove er, at i mange tilfælde, hvis du spørger en DBA, "Hvor mange tilfælde administrerer du?" Antallet ændres så ofte, at de ikke er rigtig sikre i nogle tilfælde. Så du har brug for noget mere end bare at være i stand til at smide alt op på skærmen. Du vil gribe fat i disse oplysninger, du vil give mening om dem, og så det er en af ​​de ting, som Diagnostic Manager helt sikkert kan hjælpe med, er at være i stand til at give dig den slags syn på miljøet.

Og det er ikke kun et syn på miljøet, men det er en opfattelse, som DBA, databaseadministratoren, er komfortabel med, og det er en konsol, der er DBA-centreret, hvis du vil. Det er lavet til en databaseadministrator. Der er masser af overvågningsværktøjer derude, der er masser af ydelsesværktøjer derude, men som jeg sagde, i slutningen af ​​dagen, ønsker DBA et værktøj, der er designet til en DBA, fordi der er en masse ting, der er specifikke for, hvad de gør i deres dag til dag.

Og med det sagt, du har SCOM, du har HPF, du har alle disse andre teknologier, men de vil have noget, der er specielt til det, de laver. Jeg tror, ​​at vi kan hjælpe på dette område med dette produkt, du vil se, når vi kommer ind i det om et sekund. Den anden ting, som vi ser med DBA, som bestemt også er en af ​​de ting, vi berørte tidligere, er, at de selvfølgelig skal være i stand til at se, hvad der foregår, og de er nødt til at kunne se på tværs af hele virksomheden og have lidt ro i sindet ved at vide, hvad der sker. Men på samme tid sidder de ikke der og stirrer på konsoller.

Kan du huske alle de kuglepunkter, som du så på listen, at jeg lige trak op? De er nødt til at gøre disse andre ting også, så det handler ikke kun om at vente på, at brande skal slukke. I mange tilfælde er der møder, eller mange vedligeholdelsesvinduer, der er relateret til databaseadministratoren, kører midt på natten, når de sover, så de skal have mulighed for at gå tilbage og se, hvad der skete . I mange tilfælde, hvis du ikke fanger noget, når det sker, når problemet først er forsvundet, eller i det mindste med SQL Server, bliver det slags et problem, hvor du håndterer situationen, hvor du ikke har længere rester af dette problem. Og disse problemer forsvinder, og det samme gør resterne, hvilket betyder, at du har mindre at fejlfinde med, du har mindre information at arbejde med.

Når det er sagt, er det bestemt en af ​​de ting, som Diagnostic Manager kan hjælpe med, er at give dig det syn på fortiden for at forespørge oplysningerne fra fortiden, “Har jeg en advarsel om at blokere, havde jeg problemer med deadlocking, havde vi ting, der skete med hensyn til vores ressourcer? ”Jeg kan gå tilbage og spørge om oplysningerne. Jeg kan bore ind i bestemte tidspunkter. Jeg ville være i stand til at gøre alle disse ting direkte inde i værktøjet.

Alle disse ting, til trods for om det er internt eller eksternt, vil DBA vide det, fordi de vil være i stand til at se, hvad der forårsager problemet. Det betyder ikke noget, om det var nogen inde i organisationen, eller nogen uden for organisationen, der skrev koden; de vil stadig være i stand til at isolere det, så de ved, at problemet sker, og de ved, hvor det kommer fra.

Så ydelse og ansvarlighed er en vigtig del af, hvad vores produkt gør. Vi kan give alle disse detaljer, og hvad der er sødt, er du har evnen til at bore ned. Hvis der er en flaskehals, kan du korrelere det med applikationen, til brugeren, til databasen, til forespørgslen. Og endnu en gang er det slags en rygerpistol. Du får en direkte sammenhæng mellem, når denne forespørgsel kører, hvad laver den? Og det handler ikke kun om selve forespørgslen, hvad angår udførelsen i sig selv, men også forespørgslen med tiden bliver værre? Og disse ting kan også besvares med produktet, som bestemt er noget, som hvis du prøver at være proaktiv, er det dejligt at kunne sige, "Hej, her er en forespørgsel, der løb dårligt, men dreng kig på det når det løber længere, kan vi se, at det løber endnu værre og værre, det kan jeg gøre noget ved. "

Hvis vi går ind i det næste område her; og det er sandsynligvis - jeg vil sige, at dette er en af ​​de store. Et af de spørgsmål, jeg stiller, når jeg viser vores produkt er, vil jeg altid spørge databaseadministratoren, "Hvordan hører du om et problem, der er relateret til dine SQL Server-databaser?" Og det er meget sjovt, fordi det meste af tiden - nu tildelt, oftest ser de på vores produkt, fordi de i mange tilfælde prøver at løse et bestemt behov. Men det er interessant at høre den oprindelige slags ting - i det mindste med SQL Server, er at det var slags - du ved, i de tidlige dage af SQL Server havde du SQL Server og så havde du Oracle. Og alle havde Oracle, og SQL Server var ligesom den, på grund af manglende et bedre udtryk, det rødhårede stebarn af databaser, da det først startede.

Og da Microsoft føjede flere funktioner til det, blev det lidt mere af et virksomhedsværktøj. Og tydeligvis er det kommet langt siden da. Men pointen er, at man engang kunne hævde, at databaserne ikke blev betragtet som kritiske tilbage i dag. Og det er ændret over tid. På grund af dette prøver folk i mange tilfælde at få fat i det og siger: ”Ved du hvad? Jeg har alle disse SQL Server-databaser, jeg prøver at få et greb om det. "Og snarere end at høre om problemer fra helpdesk eller høre om problemer fra de specifikke mennesker, som - som brugerne selv, de ' du leder efter nogle måder at gå omkring på. De leder efter måder, der kan gøres opmærksomme på disse situationer, før de nogensinde sker.

Og så med Diagnostic Manager er det en af ​​tingene, vi prøver også at gøre, i det mindste være i stand til at gøre, at DBA er den første, der ved om disse situationer eller disse problemer, så de kan gøre noget ved det, enten rigtigt, når de sker, eller for at tage det endnu et skridt videre for at analysere disse systemer, som det overvåges. Og for at være i stand til at give dig proaktiv rådgivning, der forbedrer ydeevnen i det tilfælde, og at være i stand til det regelmæssigt. For eksempel er vi nødt til at tilføje et indeks baseret på arbejdsbyrden; disse typer ting, værktøjerne, der også er i stand til at gøre. Så vi får set meget af det i værktøjet.

Den anden ting og den sidste ting, der er på denne liste, som er en slags mere generel beskrivelse, men det er bestemt værd at bemærke. Og især når du kommer ind i de større situationer på virksomhedsniveau, hvor du har masser af tilfælde, er der altid noget uklart, som jeg vil overvåge, hvis jeg er databaseadministrator, for eksempel. Og hvad vi forsøger at gøre er at forudse med hensyn til hvad den typiske DBA vil overvåge.

Når det er sagt, ville du også være i stand til - der vil altid være noget nyt. Så vi leverede en måde for dig at tilføje de målinger, du har brug for for at overvåge og administrere, efter installationen er tilføjet. Så alle PerfMon-tællere, WMI-tællere, SQL Server-tællerobjekter; alle disse kan integreres i værktøjet. Du har muligheden for at tilføje yderligere forespørgsler, der kan integreres i dine pollingintervaller.

Og den sidste ting, der også er værd at bemærke, er, at vi kan tilføje og faktisk kommunikere med både vCenter og Hyper-V for at kunne trække målingerne fra disse miljøer. Fordi en af ​​de ting, vi har identificeret med DBA, er, at de typisk ikke er en del af operationerne specifikt. Og de har ikke nødvendigvis typisk vCenter-miljøet til rådighed for dem eller den slags ting, de har til rådighed.

Og så er problemet, at hvis de beskæftiger sig med en SQL Server-instans, og de er blevet tildelt ressourcer, men denne instans er virtualiseret, kan det se ud som om de har alle ressourcerne i verden, når de bare overvåger, hvad der er på gæstens styresystem. Virkeligheden er, at på værten kan der være 30, 40, eller 50 eller 100 andre VM'er, de forsøger at få adgang til, og har strid med de samme ressourcer. Og den eneste måde at faktisk se det på er at kommunikere med de andre miljøer og til disse grænseflader i dette tilfælde, som vi gør.

Du har muligheden for at tilføje disse andre typer tællere i værktøjet. Nu handler det ikke kun om at være i stand til at overvåge disse tællere, men det handler om at være i stand til at gøre disse nye tællere, at du introducerer til produktet, gør dem til en del af værktøjet, som om de var en out-of-the-box metrisk . En out-of-the-box ting, som du gerne vil overvåge; så det betyder at være i stand til at integrere dem i deres betjeningspaneler. Det betyder at være i stand til at føje dem til dine egne brugerdefinerede rapporter, være i stand til åbenbart at indstille tærskler og advare dem, men også baseline dem og være i stand til at indstille tærsklerne med en vis viden, hvor de skal indstilles til at baseres på ting som din basislinjer og hvad der er normalt. Så du har mange af de slags ting, der også findes i produktet.

Hvad jeg slags har forsynet dig med, er, hvad jeg kalder "de vigtigste leverancer til Diagnostic Manager", og jeg kan gå videre og bare give dig en lille smag af det ved at gå ind i produktet. Hvad jeg skal gøre, er dele ud af min skærm, okay, og bare gå til at trække dette over. Så hvad du vil se, dette er konsollen til Diagnostic Manager. Og som jeg nævnte før, at gå til den første leverede kerne, være i stand til at se på ting fra slags virksomhedsniveau. Der er masser af forskellige eksempler på det inden for værktøjet. Vi har en slags miniaturevisning; vi har mere af et gitterlignende synspunkt. Vi har også, hvad angår fleksibilitet, vi har en webbaseret konsol også. Den webbaserede konsol har andre synspunkter, der er tilgængelige for dig, som nøglekort og lignende ting. Men pointen er, at du har den evne til at se på og se ting på et højt niveau. Men når der opstår problemer, skal du grave lidt længere ned i værktøjet og faktisk se det specifikke prob lems, og har en måde at forstå og vide, hvad der foregår. Og det er naturligvis meget vigtigt.

Nu med hensyn til at kunne faktisk se, hvad der skete i fortiden; hvis jeg ser på et problem, der skete i går, eller for en uge siden, så i denne situation, ved du, vil du have behovet for at være i stand til at gå ud til et bestemt tilfælde af SQL. Og den gode nyhed er, hvis du ved, hvad tid det problem skete inden for produktet, kan du gå direkte til historikbrowser. Og jeg kan pege på et bestemt tidspunkt på dagen; det kunne være fra et par uger siden, det kunne være fra i går. Men uanset hvilken dag jeg vælger i kalenderen, får jeg derefter præsenteret de forskellige valgintervaller. I hvilket tilfælde nu ser jeg effektivt, hvad jeg ville have set, hvis jeg havde set konsollen den 20. april kl. 13:37

Så jeg er i stand til at gå tilbage i tiden, og så når jeg først har gjort det, vil alle de forskellige faner, som vi ser her, afspejle det specifikke tidspunkt, herunder de forespørgsler, der måske har kørt dårligt, inklusive måske hvis Jeg havde sessioner med blokering. Alle de slags ting ville dukke op i værktøjet, og det vil give mig mulighed for åbenbart at udnytte den historiske information for at være i stand til, du ved, at løse problemet. På den note, når vi taler om historien, er den anden ting, der er værd at bemærke her, ikke bare at bruge historikken til at løse problemer. Denne historie er naturligvis meget værdifuld af andre grunde. Og en af ​​de store er at være i stand til at træffe beslutninger effektivt og være i stand til hurtigt at tage beslutninger med de rigtige oplysninger. Så hele denne historie, alle de oplysninger, vi indsamler, kan vi rapportere imod.

Hvis nogen kommer til mig og siger, "Jeg har denne rigtig gode nye applikation. Det kommer til at ændre verden, som vi kender den. Åh, forresten kræver det en database, og åh, forresten vil den virkelig pinde I / O på maskinen, hvor databasen er. " Hvis jeg ved, at det går ind på det, så kan jeg udnytte disse oplysninger til at kunne give en placering af alle mine produktionsservere, måske baseret på de sidste syv dage af indsamlingen. Og jeg kunne meget hurtigt komme til den konklusion, hvilke tilfælde der er mest fornuftigt at anvende denne database på. Så det er den type historiske oplysninger, som også åbenlyst er meget værdifulde.

Med hensyn til selve forespørgslerne; med hensyn til at se på forespørgsler, har vi en masse forskellige måder at gøre det i værktøjet. Og den, jeg gerne vil se på, er Query Waits View, fordi Query Waits View er meget nyttig med hensyn til at kunne vurdere. Hvis jeg har en flaskehals, der forekommer, for at være i stand til i det væsentlige at identificere alle de forskellige områder, der påvirker den specifikke specifikke forespørgsel; ikke kun selve forespørgslen, og hvad virkningen af ​​denne forespørgsel er, men også, du ved, hvilken applikation den kom fra, hvilken session den kom fra, hvilken bruger der kaldte den og alle disse ting, jeg kan se, det, åbenbart, information i realtid, men jeg har også evnen til at se på disse data fra fortiden. Og det er en af ​​tingene her, og jeg startede et script, men jeg må vente på, at det bliver en slags pop-up.

Mens vi venter på det, vil jeg - og jeg ved, at vi er kort til tiden, så jeg ville slags tale lidt også om, at alarmeringsmeddelelse er proaktiv. Og når du taler om den slags ting, som jeg sagde, der er den proaktive del, er der en masse værktøjer, der gør alarmerende. Den hårde del er ikke at sende en e-mail. Den hårde del er ikke at skrive til hændelsesloggen eller generere en SNMP-fælde. Den hårde del er at vide, hvornår man skal sende denne advarsel på de passende tidspunkter. Og med det kommer en masse at skulle foretage nogle beregninger og skulle forstå, "Hvad er det med det bestemte tilfælde, og hvad er normalt, da det vedrører det tilfælde?"

Og så for alle de beregninger, der giver mening at gøre det, baserer vi disse beregninger. Vi viser dig faktisk basislinjen, vi viser dig den tærskelværdi, den i øjeblikket er indstillet til. Og så er den anden dejlige ting ved det, at lad os sige, jeg indstiller mine tærskler til i dette tilfælde seks og ti bare for dette eksempel. Seks uger fra nu, hvis jeg vender tilbage til dette tilfælde, kan denne baseline helt ændre sig, fordi en af ​​de ting, vi laver, når vi beregner baseline, som standard, er en rullende syv-dages beregning. Så det giver mig altid en ajourført version af baseline. Og hvad sker der, hvis denne baseline skifter op i mine tærskler? I dette tilfælde kan jeg se og advare anbefalinger, der dybest set siger: "Hej, du har en tærskel, der sandsynligvis er indstillet forkert, specifik for det sted, hvor vi ser tærsklen være, og selvfølgelig, hvor basislinjen er, vil du sandsynligvis til få en advarsel om noget, der er en normal forekomst. "

Og så snarere end at behandle et symptom på noget, der er normalt, er jeg i stand til at identificere den type situation, hvor den faktiske tærskel er indstillet forkert. Og hvad det tillader mig selvfølgelig at gøre, er at indstille tærsklerne i overensstemmelse med, hvor jeg vil få en advarsel. Det er noget, jeg ved, for mere at være en opfordring til handling mod en undersøgelse for at se, om det virkelig er et problem. Og jeg tror, ​​at en del af værktøjet er virkelig nyttigt med hensyn til selve baseline og ved at være i stand til at beregne.

Nu med dette produkt har du muligheden for faktisk at have flere baselinjer; du kan indstille dem til forskellige tidsperioder, og du kan dynamisk justere tærsklerne baseret på dine baselinjer, hvilket også er meget vigtig del af formen for tilpasning til de ændringer, der sker dagligt til dine SQL Server-instanser . Nu, i dette tilfælde her, dækker vi slags en masse af indstillingerne for tærsklerne og viser dig basislinjerne. Men hvad angår de faktiske alarmer, er meddelelsen i sig selv, den seje ting ved Diagnostic Manager, at den giver dig flere alarmprofiler. Så hvis du f.eks. Har en on-call-profil, der er fra 02.00 til 05.00, kan jeg have en profil, der er specifik for netop dette tidsinterval, og jeg kan indstille alle betingelser og de relevante indstillinger her for mit svar.

Sagen ved svaret er, at jeg i nogle tilfælde ja kan sende en e-mail, eller jeg kan skyde af og generere en SNMP-fælde eller skrive til hændelsesloggen. Der er en masse andre ting, vi kan gøre, men når jeg taler med DBA'er, er det faktum, at i de fleste tilfælde meget af det arbejde, der udføres, er gentagne ting. Det er ting, de ved nøjagtigt, når problemet sker, hvad de skal gøre for at løse det. De er bare nødt til at gå og gribe ind. Og så når du vokser dit miljø, når du har flere tilfælde, bliver det meget vanskeligere at gøre. Så en af ​​de ting, du kan gøre inden for det værktøj, som jeg synes er værd at bemærke, er at du har evnen til at oprette en betingelse, men baseret på denne betingelse for at være i stand til at indstille et svar til at køre et script, til at køre en job, til at køre en eksekverbar. Og poenget er, at hvis du beslutter at køre et script, kan jeg bruge parametre inde i det script, der vil være på kørselstidspunktet, besat med de faktiske oplysninger.

Så hvis der er problemer med en bestemt database, vil scriptet være designet til at køre lige mod den database, hvor problemet sker. Så du kan dynamisk løse problemer på en automatiseret måde, og så kan jeg stadig modtage en e-mail for at vende tilbage og fortælle mig, at "Hej der var et problem, men forresten var det løst." Manuskriptet blev kørt, og som DBA kender du til det, men du var faktisk ikke nødt til at gå ind og gribe ind. Nu, på den samme note om at være proaktiv, har vi selvfølgelig også en anden funktion her, som er funktionen "Analyser". Og hvad dette vil gøre, er at det foretager en regelmæssig kontrol mod forekomsten af ​​SQL. Og i nogle tilfælde vil det gøre et dybere dykk i forhold til hvad det leder efter. Ting som hypotetisk indeksanalyse vil blive udført. Tilføjer jeg et indeks? Fjerner jeg et indeks? Og alle de slags ting hjælper naturligvis med min præstation, men endnu en gang handler det om at være proaktiv. Det handler om at være i stand til at tage beslutninger, før ting går i stykker, og få det til at løbe bedre. Og så i mange tilfælde er det virkelig, hvad vi forsøger at gøre her.

At vende tilbage til forespørgsel venter på, at vi talte om tidligere; som du kan se, der er en stor pigge her. Jeg kørte et script tidligere, der netop forårsagede en vis venteaktivitet, og som jeg nævnte før, har vi en virkelig unik måde, du kan uddybe i denne information. Hvis jeg vil se, hvilken applikation det var; Jeg kan se, at det kom fra NoSQL-applikationen. Vi ville være i stand til at se databasen, den var bundet til, sessionen, brugeren, og hvis jeg vil, kan jeg også rangere denne, hvad angår mine ventetider. Så jeg kan sige, af alle de ventninger, der skete i det tidsvindue, hvilke der skete mest? Og hvis jeg ser, at når det er sket mest, er det virkelig rart, at jeg kan bore ind i den ventetype, og jeg kan se alle kommandoerne. Hvis du ser her, fik de denne vent til at ske. Og jeg kan også først og fremmest se, hvilken anvendelse det var, der fik denne ventetid til at ske.

Så det stikker ud som en øm tommel. Jeg kan straks gå og sige, "Dette er det program, der forårsager min flaskehals. Hvad var den forespørgsel, der blev kørt? Hvilken bruger kørte den? Hvilken database kørte den mod?" Og så videre. Så forhåbentlig er det fornuftigt, og det hjælper også med hensyn til at sikre dig, at du ikke har latensen i dit miljø, da det vedrører dine databaser. Forhåbentlig er dette nyttigt. Jeg vil gå videre på dette tidspunkt og videregive det, og jeg gætter vi kan fortsætte derfra.

Eric Kavanagh: Sikker ting. Så jeg antager, at jeg bare vil kaste det til vores eksperter på dagen. Mark, måske først vil du kommentere og stille et par spørgsmål. Så Dez, kan du chime ind.

Mark Madsen: Ja, tak, jeg nød virkelig at se noget af dette. Det er en meget mere intelligent overvågning, end jeg er vant til at se. Jeg er nysgerrig efter håndteringen af ​​dataene bag dette; styring af de metrics, som du kan spore, og du ved, kigge efter ting som skiftende basislinjer især, at det er et af mine smerter med kæledyr, med instrumentbræt. Hvordan håndterer du disse data, og den anden del af det er med, du ved, baseline-metrics, som en slags skift - har du evnen til automatisk at skifte tærsklerne også, så jeg ikke behøver at gå tilbage og nulstille tærskler for hånd, når en basislinie skifter?

Bullett Manale: Det gør du, og det dejlige ved det er, at du kan beslutte det. Du kan gøre det enten. Jeg kan indstille en tærskel og gøre det til en statisk indstilling, eller jeg kan markere afkrydsningsfeltet for at sige: "Gør dette til en dynamisk tærskel, der vil ændres, når mine baselinjer ændres." Og jeg har evnen og værktøjet til at indstille et standardvindue tid til min basislinje. Men så hvis jeg har brug for det, har jeg måske et separat basislinievindue, for eksempel fra mit vedligeholdelsesvindue fra 02:00, lad os sige indtil 05:00; fordi jeg vil beskatte min CPU, mine drev og alt andet, fordi det er, når vi udfører alt vores vedligeholdelse. Det ville så automatisk, hvis jeg havde valgt det at gøre det, justere det automatisk mine tærskler til at være uden for det, uanset hvad der er normalt for disse målinger, Jeg vælger at gøre det med. Det vil tillade mig at gøre det. Grundlæggende har du en mulighed inden for værktøjet til at indstille tidsvinduer, det er dine basisvinduer, og hvert vindue kan behandles som en separat enhed i form af dynamisk baselinjustering, der kan gøres, og du kan tilføje så mange vinduer på din baseline som yo du har brug for det, hvis det giver mening. Du kan have et weekendvindue, en ugedag i arbejdstiden, et vedligeholdelsesvindue, der sker midt på natten og så videre og så videre.

Mark Madsen: Tak.

Bullett Manale: Jeg gætte tilbage til den første del af spørgsmålet, vi har, og indsamler alle disse oplysninger. Jeg talte ikke rigtig om arkitekturen, men vi har et back-end arkiv, at du har fuld kontrol over opbevaring af disse data, men vi har også en service, der kører midt om natten, der går og gør alle vores baselineberegninger, og det tager disse data, indsamler og giver mening af dem. Og selvfølgelig har du også adskillige rapporter, som vi kan bruge til at rapportere mod dine baselinjer til specifikke beregninger. Og du har endda muligheden for at sammenligne dine baselinjer på den samme server for den samme metrisk i forskellige tidsperioder. Du kan se, om der er forskelle, der er sket, eller hvad deltaet er. Der er også mange af disse typer muligheder.

Eric Kavanagh: Dez.

Dez Blanchfield: Et hurtigt spørgsmål, jeg har til dig - der er et bredt spektrum af, hvad dette værktøj kan gøre. Ser du et optag i brugen af ​​det i den tidlige fase af udviklingen nu, eller er det stadig primært et produktionsmiljøværktøj? Med andre ord, får udviklere adgang og bruger det gennem deres tidlige udvikling og tester derefter integrationsfasen? Eller bruges det stadig overvejende i produktionsmiljøer?

Bullett Manale: Jeg vil sige det, i de fleste af de gange, vi ser det i produktionsmiljøer. Det afhænger af situationerne, men for det meste vil jeg først og fremmest sige produktion og det gør vi - og det er også, du ved, fair at nævne, at vi har forskellige priser for dev- og testmiljøer, så det er lidt mere attraktivt. Vi ser mennesker, der bruger det til disse miljøer, men hvis jeg skulle give dig et svar på den ene eller den anden måde, ville jeg sige, at det primært stadig er produktionsmiljøer, hvor vi ser, at folk foretager en investering for dette produkt .

Dez Blanchfield: Ja, ja, og det var interessant at høre, at du har forskellige prisfastsættelsespunkter, for der er åbenbart forskellige arbejdsmængder, og jo tyngre arbejdspladserne vil være, hvor alt det rigtige arbejde udføres. Men jeg ser en masse organisationer, især i regeringen og helt sikkert i forsvaret, hvor udviklingen nu får det samme niveau af investering i værktøjer og systemer som produktionsmiljøer, fordi de laver meget mere up-front test. Til forsvar er der for eksempel hold, der kører milliarder af test, hundreder af milliarder af test på applikationer og systemer og værktøjer, og overvåger dem, før de endda går i integrationstest, fordi de vil sikre sig, at der er en kode, der er bygget, og databasen det sidder under det. Det kommer til en hundrede og en million iteration eller noget, mens du er ude i marken og skyder mod nogen, går det ikke "bang".

Bullett Manale: Sure.

Dez Blanchfield: I databasesamlingen i oldskolen efter min oplevelse er det meget sjældent at se, og meget sjældent talt om, at databasemiljøet er noget, der lige er tilbage i data, og nogle af jer ved, så når vi får det punkt, hvor værktøjer og apps udvikles, især med analytiske platforme, de er nu i vores håndsæt og vores enheder. Ser du klienter bringe samtalen om databasepræstation og databasestyring slags i en mere dagligdags diskussion i modsætning til kun rent teknik? Og jeg ved, at du nævnte før, at overvejende du taler med DBA'er, men er der en tendens nu, hvor det er i det generelle ordforråd, ser du folk, hvor de diskuterer disse emner, i modsætning til bare nørderne?

Bullett Manale: Det er godt at sige. Jeg mener, som jeg for det meste sagde, at de mennesker, vi beskæftiger os med med hensyn til salgsprocessen alligevel, er med de udøvere, som er DBA’erne. Så hvad angår dit spørgsmål siger du bare "Med hensyn til generelt folk i it-organisationen bliver de mere databasekendte?" Jeg gætter på, at det er spørgsmålet, og jeg vil sandsynligvis sige, at svaret er "ja." Jeg ser det sandsynligvis ikke så meget, baseret på hvor jeg er, fra den daglige basis, men jeg tror, ​​hvis jeg forstår dit spørgsmål, ville det være mit svar, antager jeg.

Dez Blanchfield: Ja, det er okay. Det er sandsynligvis et indlæst spørgsmål, desværre, for selvfølgelig er dine overvejende interesser, i din verden, den tekniske side af tingene. Jeg er nysgerrig over, at jeg i mine daglige aktiviteter ser organisationer begynde at bringe dette ind i samtalen meget tidligt. Så når de taler om nye initiativer, nye projekter, nye arbejdsprogrammer, er en af ​​de ting, der kommer med det samme, "Hvordan overvåger vi det, hvordan sporer vi det, hvordan håndteres der problemer, når de opstår, i stedet for at lancere, gå live? "

Bullett Manale: Jeg vil sige det -

Dez Blanchfield: Undskyld, gå videre.

Bullett Manale: Jeg ville sige, at jeg ser en tendens, som jeg skulle sige i - du ved, mange gange tidligere ville du få, ”Vi havde et problem, og nu har vi brug for et værktøj. " Og jeg tror, ​​at vi ser lidt mere af accept omkring at have værktøjet på plads, før problemet sker, hvis det giver mening. Så jeg vil sige, at det bestemt bliver mere normalt at være, du ved, ”Hej, vi har brug for et overvågningsværktøj, vi har brug for noget.” Og folk ser bestemt værdien af ​​dette produkt, for som du sagde tidligere, bare tilføj DBA'er og tilføjelse af nye tilfælde, har du brug for noget, der styrer det. Du har brug for noget, der hjælper med styringen af ​​det, og det er derfor, vi ser en masse accept også omkring dette produkt, eller vi har.

Dez Blanchfield: Hurtigt spørgsmål. Hvor skal dette bo? Skal det sidde lige bagpå og brænde på LAN, inden for datacenteret, så tæt som muligt på databasemiljøerne, eller er det behageligt placeret et sted, potentielt ude i skyen, en tredjepartssky med en slags enten VPN-tunnel eller fjernadgang til forskellige miljøer? Hvor skal dette sidde, hvad angår miljøer og overvågning?

Bullett Manale: Med hensyn til arkitekturen er der et back-end-arkiv, og det er en SQL Server-database. Vi har konsollen, der enten kan være en fed klient eller en tynd klient; vi giver dig muligheden for begge. Og vi har også en tynd klient, der også virkelig er specielt tilpasset mobile enheder. Men med hensyn til hvor dette faktisk kan sidde; det kan sidde i et miljø, virkelig den vanskeligere del ved det, fra en masse af de oplysninger, vi har brug for at indsamle, kræver administrative rettigheder, i nogle tilfælde eller i mange tilfælde. Nu får vi dig ikke til at gøre det; Hvis du vil, kan du samle data og bare for de ting, vi ikke kan samle, fordi vi ikke har administratorrettigheder, vi vil bare lade dig ikke se disse oplysninger, hvis det er det valg, du vælger.

Afhængig af smagen, som hvis du taler om AWS, fungerer nogle miljøer bedre end andre, men for så vidt angår selve miljøet, typisk enten ved hjælp af SA-godkendelse til at indsamle data mod forekomsterne, er alt hvad der er nødvendigt. Eller hvis det er et ikke-betroet domæne, er det normalt, når du vil gøre det, men flere domæner; så længe der er tillid mellem dem, kan vi samle imod dem. Det betyder ikke noget, om det er på et LAN eller om det er i WAN, selve indsamlingen er temmelig ubetydelig med hensyn til mængden af ​​data, vi indsamler. Hvis vi har en tilstrækkelig WAN-forbindelse, er det ikke et problem. Jeg har set miljøer, hvor de har filialer, hvor de har SQL-servere over hele USA. Og det er en server på hver af disse forskellige placeringer, og de overvåger den centralt. Den vanskelige del er bare at sikre dig, at du har en anstændig mængde forbindelse til at gøre det. Forhåbentlig, som svarer på dit spørgsmål, var det slags overalt på kortet.

Dez Blanchfield: Det gør det absolut. Tak skal du have. Så to hurtige spørgsmål, der er kommet gennem deltagere i morges; det ene er: hvad er virkningen af ​​- ofte ser vi systemovervågningsværktøjer generere belastning i sig selv ved blot at overvåge ting, så spørgsmålet var, desværre det rullede ud fra min skærm nu, men bare at omskrive det; ved at overvåge genererer vi belastning selv? Er der en målbar påvirkning af værktøjet, bare se på miljøet, eller er det en ubetydelig påvirkning?

Bullett Manale: Der vil altid være en smule indflydelse, fordi det skal spørges til SQL Server-forekomsten for at trække dataene tilbage. Spørgsmålet, som du sagde, er: "Er det ubetydelig eller er det vigtigt?" Ud af boksen, du peger på et eksempel, er det ubetydelig. Vi har gjort dette i, som sagt, et stykke tid nu. Vi har over 20.000 kunder, og jeg kan forsikre dig om, at hvis det medfører betydelig ydeevne, ville vi ikke have forretning. Med det sagt tillader vi også brugeren at bestemme, hvad de vil have, de vil overvåge. Så jeg synes, det er en vigtig ting at nævne, er, at ethvert miljø er lidt anderledes.

Et eksempel ville være, at med forespørgselsovervågningskomponenten, en af ​​de ting, vi har evnen til at gøre, er, at vi kan indstille tærsklen for, hvad du betragter som din grænse for normalitet. Så det kunne være baseret på tidspunktet for udførelsen af ​​forespørgslen. Det kan være baseret på CPU'en, I / O, men som et eksempel, lad os bare sige, at jeg har indstillet min udførelsestid til nul millisekunder. Det, jeg fortæller værktøjet til at gøre, er faktisk at samle alle de forespørgsler, der løb siden det sidste trækinterval, og også gøre denne del af min historiske samling.

Når vi gør det, skal vi indsamle det antal mængder af forespørgsler, vi kørte på kassen siden den sidste afstemning. Nu er det valgfri, og brugeren har evnen til at gøre det. Siger vi "Det er hvad du skal gøre"? Nej. Men vi giver dig også muligheden for at gøre det, hvis du vil have en stikprøve af data, der giver dig mulighed for at indsamle disse oplysninger. Så generelt har du midlerne inden for værktøj til at konfigurere det og indstille det nøjagtigt, hvordan du vil, baseret på hvad du er tilpas med. Men du har evnen til virkelig at åbne den op, hvis du vil, og samle en masse yderligere oplysninger, som du måske ikke nødvendigvis regelmæssigt indsamle, hvis det giver mening.

Dez Blanchfield: Ja, absolut. Jeg ved, at vi løber lidt længe, ​​men der er to rigtig gode spørgsmål, jeg vil smide på dig, inden jeg går sammen. De kommer begge direkte til mig, men jeg synes, det er bedst, hvis du svarer dem. Spørgsmålet var generelt, "Hvad er omfanget af værktøjets rækkevidde så vidt kendskab til eksisterende systemer?" Så kan vi bare tilslutte dette og få det automatisk til at registrere den platform, der er der, og vide, hvad der er normalt for den platform, og med det samme samle op, som Mark talte om tidligere? Nogle af baseline-viden om platforme ved at sætte i, ved du, jeg ved ikke, det kunne være Microsoft Dynamics. Hvad er omfanget af viden om platformen med hvad der er normalt og i nogle af de nuværende værktøj, der bruges rundt om forretning?

Bullett Manale: Jeg vil sige, at når vi begynder at indsamle data om SQL-forekomsten, arbejder vi med bedste praksis til at begynde med, hvad angår vores tærskler, og hvor de er indstillet til. Når det er sagt, anerkender vi også, at uanset hvad du snakker med, hvad angår bedste praksis, er ethvert miljø anderledes. Hvad vi begynder med, indsamler vi bare dataene, og hvad vi anbefaler folk at gøre, du kan prøve produktet i 14 dage længere, hvis du har brug for det. Men efter cirka to dage vil du begynde at se basisliniedataene. Når den har tilstrækkelig prøveoplysninger til at arbejde med, vil den begynde at give dig konteksten med hensyn til baseline, hvor området er, og alt det slags. Derefter derfra, hvis du vil, kan du automatisk indstille dine tærskler ud fra de oplysninger, der er indsamlet. Det kræver lidt indsamling og polling for at kunne begynde at bestemme, hvad der er normalt, så du kan begynde at skifte dine tærskler.

Men det, som jeg synes er værd at bemærke, er, at når du ændrer disse tærskler, kan det gøres gruppevis for dine forekomster. Det kan være specifikt for en forekomst, eller du kan gøre det mod alle dine forekomster samt muligheden for at oprette ting som skabeloner, så du kan sige, "Dette er en produktionsforekomst, men dette er den skabelon, som jeg ønsker at tildele det. " Og så når en ny produktionsinstans kommer online, anvender vi automatisk disse tærskler til det, fordi det har den samme type hardware, og det har normalt de samme arbejdsbelastninger, så vi ville være i stand til det også. Forhåbentlig hjælper det med hensyn til spørgsmålet.

Dez Blanchfield: Det gør det absolut. Faktisk besvarede du faktisk et andet spørgsmål, der lige kom ind til mig, og det var: "Er der en prøveversion?" Der kan jeg svare på det, jeg ved. Jeg er sikker på, at du vil bekræfte, at der er en gratis download, og jeg tror, ​​du sagde, at det var 14 dage fra webstedet. Du kan downloade det og lege med det. Jeg gætter dog ganske hurtigt med det: "Hvilket miljø har jeg brug for for at kunne køre prøveversionen? Kan jeg køre den på min bærbare computer og lege med den, eller har jeg virkelig brug for en server?"

Bullett Manale: Det vigtigste er, at det er et lager, en SQL Server-database, der er 2005 eller derover. Bortset fra det er der nogle minimale ressourcebehov, et .NET-krav, og det er det. Så det er bare et spørgsmål om at installere produktet og oprette en database.

Dez Blanchfield: Perfekt. Et sidste spørgsmål, som jeg vil kaste dig, for vi er lige ude af tid nu, men hurtigt spurgte omkring to eller tre personer mig: ”Har jeg brug for at være en DBA for faktisk at være i stand til at køre med dette, og leg et med det? ”

Bullett Manale: Nej. Jeg vil sige, at hvis du er en DBA, vil du have forskellige anvendelser af værktøjet. Jeg mener, der vil sandsynligvis være lidt mere værdi, hvis du er en erfaren DBA. Du vil se meget mere dybde til det værktøj, som du vil være i stand til at drage fordel af. Men også som en ny DBA, eller endda en person, der, det er ikke en DBA, vi har en masse anbefalinger, og jeg er på den side lige nu. Disse henstillinger kommer regelmæssigt frem, og det virkelig dejlige ved anbefalingerne er, at de giver dig grundene til, at henstillingerne bliver fremsat. Men derudover vil de også have links til eksternt indhold, der beskriver mere detaljeret om grundene til, at disse anbefalinger også bliver fremsat. Så det vil linke til eksterne Microsoft-websteder, blogs og alle slags ting som det, det er eksternt.

Men for at besvare dit spørgsmål er det slags, ved du, hvis du er en senior DBA, vil der være ting herinde, vil du sandsynligvis drage fordel af, som du sandsynligvis ikke ville være som en nybegynder DBA. Men så på samme tid er det også et slags læringsværktøj, for når du gennemgår disse anbefalinger, vil du begynde at afhente nogle af disse ting på egen hånd ved hjælp af anbefalingerne.

Dez Blanchfield: Fantastisk. Tak skal du have. Jeg nød virkelig demodelen. Præsentationen var stor. Demoen var fantastisk. Fra hukommelsen findes der et helt ressourcecenter på dit websted, som jeg anbefaler, at folk også kigger på. Jeg kan huske, at jeg gik igennem i går aftes for at få nogle detaljer. Du har en lang række ting lige fra dine blogs og data og samtaler til, fra hukommelsen, du har også det meste af din produktdokumentation online, ja?

Bullett Manale: Ja, det er korrekt, og den form, som jeg tror, ​​at du refererer til, er community.idera.com-webstedet. Og så vil en ting jeg også nævne, tidligere har du spurgt om, "Vil det genkende miljøet?" Med hensyn til nye forekomster eller tilføjelse af forekomster er der et andet værktøj, som vi har, som gør opdagelse af forekomster. Og det handler om inventar og styring af din beholdning. Jeg vil bare pege dig i den retning med hensyn til faktisk at opdage tilfælde. Men hvad angår faktisk ydeevne og overvågning, alt det, vi talte om, det var her Diagnostic Manager kom i spil.

Dez Blanchfield: Fantastisk. Se, god dækning. Virkelig nød din præsentation. Elskede live demo, og det er alt fra mig her til morgen, da jeg ved, at vi sandsynligvis er gået 10 minutter over tid. Eric, jeg vil vende tilbage til dig.

Eric Kavanagh: Okay. Jeg elskede bare demoen. Jeg er glad for, at du gjorde demoen. Jeg er glad for, at vi blev nødt til at se et rart hårdt kig på det, da vi gik gennem spørgsmål og svar.

Bullett Manale: Fantastisk.

Eric Kavanagh: Fordi dette giver folk en idé om, hvad du ser på, og det forbliver mig virkelig forbløffende at tro, at vi stadig lærer om, hvordan man taler med disse computere, når du kommer helt ned til det. Jeg mener, dette niveau af diagnostik er temmelig sofistikeret, og det bliver bedre hver dag. Vi får meget mere indsigt i, hvad der faktisk sker. Men du har virkelig brug for en person, der overser dette, læser det, lægger den kognitive evne bag det, du laver, ikke?

Bullett Manale: Ja, jeg mener i mange tilfælde - jeg ville ønske, jeg kunne fortælle dig, at dette er en DBA i boksen, men der er bare for mange ting, der foregår. Jeg mener, vi giver vejledning, og vi hjælper, men i slutningen af ​​dagen kræver det, at folk træffer beslutninger om de data, vi præsenterer. Jeg tror ikke, det snart vil ændre sig.

Eric Kavanagh: Det er godt nyt for de rigtige mennesker derude, folkens.

Bullett Manale: Det er rigtigt.

Eric Kavanagh: Du vil have nogen til at se dette, et hold der ser på dette, og du lærer, som du har hørt fra Bullett her, at se på disse anbefalinger, du vil hente, hvad der foregår. Og jeg gætter fra den historie, og jeg tror, ​​du har rørt ved dette, Bullett, men meget hurtigt, at historien giver dig mulighed for at genkende betydelige mønstre og derefter være i stand til at identificere dem, når de sker i fremtiden, ikke?

Bullett Manale: Det er korrekt. En af de ting, vi kan gøre, er at spore en forespørgsels ydeevne over tid. Vi kan selvfølgelig også se på andre ting, som basislinjer og se dem skifte, og åbenbart få advarsler og lignende ting, når det sker, så du har bestemt denne evne.

Eric Kavanagh: Det lyder godt, folkens. Vi ville ikke have været længe her, men jeg ville komme til de spørgsmål. Tak så meget for din tid og opmærksomhed. Vi arkiverer alle disse webcasts. Hop online til Techopedia.com eller til InsideAnalysis.com, du vil se links fra begge steder.

Og med det beder vi dig farvel. Tak igen folkens, vi henter dig næste uge, tre webcasts mere i næste uge, tirsdag, onsdag, torsdag. Så vi taler med dig i næste uge, folkens. Pas på. Hej hej.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved hjælp af indstillingerne til højre. For info om, hvordan vi samarbejder med branchepartnere, klik her.

• Profil
• Internet side