Prestasjonsspill: ta farvel med latenstid

Av Techopedia Staff, 9. mai 2016

Takeaway: Vert Eric Kavanagh intervjuer Mark Madsen, Dez Blanchfield og Bullett Manale om latens og ytelse.

Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved å bruke alternativene til høyre. For informasjon om hvordan vi samarbeider med bransjepartnere, klikk her.

• Profil
• nettsted

Eric Kavanagh: Mine damer og herrer, hei og velkommen igjen til Hot Technologies! Ja absolutt! Jeg heter Eric Kavanagh, dette er vårt Hot Tech-show, et samarbeid med våre gode venner fra Techopedia. Hop online til Techopedia.com for alt det siste innen det brede feltet av bedrifts-teknologi; de dekker selvfølgelig også forbruker ting. Vi fokuserer på bedriften her på programmet vårt, så det er det vi gjør i dag.

Det er et sted om deg virkelig og nok om meg, slå meg opp på Twitter @eric_kavanagh, jeg elsker Twitter, jeg elsker å sjekke ut de tingene, det er en fin måte å holde kontakten med mennesker og ha gode samtaler og en-til-en -en samtaler.

Så hva snakker vi om? Dette året er varmt, dette er et helt univers av muligheter som vi ser på i dag i verden av informasjonshåndtering, og det vi snakker om i dag kommer til å være spørsmål, det kommer til å sette fart på spørsmålene.

Jeg tror jeg glemte å nevne tittelen, "Performance Play: Say Goodbye to Latency." Vel, hvem vil ha forsinkelse? Ingen vil ha latens, latenstid er når du sitter der, klikker på knappen og venter på at noe skal skje, og ingen vil ha det. Barna liker ikke det, de synes ikke det er kult, de voksne liker det heller ikke. Vi har alle blitt bortskjemt med hastigheten på nettet, og vi vil ha ting raskt, vi vil ha ting nå, og vi kommer til å snakke alt om det i dag på showet vårt.

Analytiker Mark Madsen er med oss ​​i dag fra Third Nature, en av våre faste. Vår nye dataforsker, Dez Blanchfield, ringer inn fra Sydney, Australia. Og så er Bullett Manale, ja, det er navnet hans, det er egentlig ment å være to T-er. Bullett Manale fortsetter som vår gjest fra Idera, et veldig, veldig interessant selskap, som gjør mye. Jeg vet om dem allerede, hvorav de ene kjøpte et selskap som heter Precise for en stund tilbake. Jeg kjente deres administrerende direktør ved navn Zohar Gilad, hvordan er det for et navn? Han var en pokker for en smart fyr.

Men folkens, du spiller en viktig rolle i denne webcasten i spørsmålene du stiller, så vær ikke sjenert, send inn spørsmålene dine når som helst - du kan gjøre det ved å bruke spørsmål og svar-komponenten på webcast-konsollen, det er der nede i nedre høyre hjørne. Du kan også chatte med meg, så snakker jeg det til høyttalerne. Vi har allerede noen som ringer inn fra Italia, så “Ciao, ciao. Kom igjen? ”OK, med det at jeg skal skyve Marks første linje, skal jeg overrekke dekket til Mark. Mark, du har nå WebEx. Ta den bort, gulvet er ditt.

Mark Madsen: Takk, Eric. Jeg har ikke tenkt å begynne i midten, jeg begynner i begynnelsen. Så bare noen få kommentarer for å sette opp diskusjonen med Dez og Idera, en slags tilstand av staten med utvikling, og databaser og operasjoner. Og du vet, hvis du ser på dette, har vi den slags to verdensproblemer fremdeles i database- og applikasjonsmarkedet, fordi utviklere ser på DBA-ene som menneskene som plager dem. Du må bygge datamodeller, du kan ikke ha tilgang til det, du kan ikke lage den tingen, du kan ikke sette en indeks i hver kolonne i hver tabell i databasen for å gjøre det raskere. Og selvfølgelig, hvorfor trenger vi modellene? Det er bare datastrukturer, hvis vi endrer dem, kan du ikke bare skrive dem ut i en seriell form?

Problemet er at utviklere kjenner kode og applikasjoner, men to ting de ofte ikke vet, er samtidighet, samtidig programmering og databaser og operativsystemene under dem. Etter å ha vært en kjerneutvikler og operativsystemer og databaser, kan jeg si at samtidighet og parallellitet er veldig vanskelig, og så mange ting du lærer å få god ytelse fra koden din, virkelig begynner å falle fra hverandre når du er arbeider med en database. Og ytelsen ser bra ut, testmiljøet ser bra ut, og spørsmål og svar-miljøet, og så treffer det det virkelige systemet, og så er det plutselig ikke så bra. Fordi den er mangefasettert, hvordan koden fungerer med databasen, hvordan den fungerer med miljøet, og virkelig enkle små fremgangsmåter kan ha drastiske effekter avhengig av hvilken skala du kjører.

Og når du begynner å snakke om eksterne applikasjoner, selvfølgelig, eksterntvendte applikasjoner, webapplikasjoner, kan være veldig vanskelig fordi ting er bra før de plutselig plater, og det er de ikke. Du vil treffe disse interessante platåene som krever mye nyanse for å forstå.

Tingenes bakside er DBA-visningen. DBA-synet er at det er operasjoner, de bruker mesteparten av tiden sin, 80 til 90 prosent, i ops, og kanskje 10 til 20 prosent som håndterer utviklingsstoffene som foregår på forhånd. Fra dette perspektivet betaler du enten nå eller betaler senere, og hvis du bruker all tiden på forhånd, vil du ha en mye bedre sjanse senere, i motsetning til utvikling som har en tendens til å utforske en funksjon plass, og prøve å finne ut hvordan du best kan gjøre ting. Så vi har problemer, og nå har vi metodologier som er inkompatible - kontinuerlig distribusjon, rullering av appene dine når de er klare, gjør koder skyver med jevne mellomrom, jobber i en butikk som praktiserer dev ops. Denne typen ting fremskynder utviklingen, men all praksis rundt databasen og hva DBAer gjør og hva systemansvarlige har blitt opplært til å gjøre, IT ops praksis har ikke holdt tritt.

Hvis du tenker på det, opererer de fleste DBA-er under et endringskontrollmiljø kontra et kontinuerlig distribusjonsmiljø. Det handler om stabilitet og kontroll, versus hastighet på endring og reversibilitet. Kontinuerlig distribusjon, hvis du ikke kan komme ut av endring, er du i trøbbel, så alt må bygges for å være lett reversibel og byttbar, som ikke er slik relasjonsdatabase, utviklingspraksis og administrasjonspraksis har fungert .

Du får også opp problemene med å være mer proaktive hvis du kan som DBA, for når du hører om et problem, fyller hundre tusen mennesker klageskjemaer på nettstedet ditt. Det gjør at du trenger noen nye ting du ikke får ut av det gamle miljøet. Du vet ting som bedre overvåking og varsling. Samtidig har databaser blitt flere, vi har flere applikasjoner enn noen gang for å støtte flere ting enn noen gang, de er inne, de er utenfor, de er over alt. Og mer uavhengige datasett for analyser, folk starter opp databaser over alt, fordi det selvfølgelig er enkelt nå, du kan sette opp en virtuell maskin. Hvis du har en skyleverandør eller en intern sky, kan du øyeblikkelig dukke opp ting, og dette endrer hele anskaffelsesstien.

Den gamle anskaffelsesstien var, "Jeg har tid til å skaffe meg en server, skyve den i et stativ, tildele plass, få lagring, få installert databasen og gjøre ting, " kontra noen som sveiper et kredittkort og går om fem minutter. Hvis du gjør det, fungerer det moderne utviklingsmiljøet i et tempo som er veldig annerledes, og det er derfor enkelt å lage databaser, og det skaper bare dette problemet med en spredning, som ingenting vi har sett før. Og dette har pågått i ti år nå, dette er ikke nyheter for noen, men det betyr også at driftsmiljøene har vokst i kompleksitet.

Hele klientservermiljøet har virkelig endret seg, fordi det ikke er en klientserververden lenger. Da hadde du en server, du hadde en database, hvis noe var galt du visste hvilken server du skulle gå til, visste du hvordan du skulle administrere ressursene på den fordi beste praksis var en database, en server. Virtualisering begynte å bryte det fra hverandre, sky bryter det enda mer, fordi det du tror er en databaseserver, bare er programvare. Så miljøet er ikke ekte. Det er det som inneholder miljøet som er virkeligheten, og som kan være et knivstativ eller en stor server som er skåret opp i biter, du vet ikke helt.

Alt rundt databaseadministrasjon og ytelsesstyring, og hvilke databaser som er bygget rundt tett kontroll med en server, eller en håndfull servere og et par databaser, kan du ikke kontrollere alt. Du sitter der på en maskin, men båndbredde kan ikke deles enkelt av de virtuelle lederne, og alt kan derfor være bra med minne og CPU, men du har flaskehalset på en ressurs som ikke kan håndteres, og når prøver du å fikse det, ville den gamle modellen vært hardt i arbeid, fått en større server og gjøre noe sånt, nå kan det være veldig enkelt, bare legg til virtuell kurs, bare legg til minne i VM og det er løst. Men hva skjer hvis din VM er på en overfylt server og trenger å migrere? Eller hva skjer hvis du er på størrelse med et AWS-system, og maksimalstørrelsen er nådd, hvor skal du nå?

Så du har alle disse problemene der miljøet er en del av databasen nå, du pakker et miljø med en database, alle spesialressursene, alt i applikasjonen det er en del av konfigurasjonen, konfigurasjonen blir skjøvet der ute. Dette er fra databasemiljøet, det er mye vanskeligere å administrere og kontrollere.

Hvis du ser på hva databasesentrene har gjort, har de sittet på hendene, ikke sant? Vi har beveget oss bort fra denne ideen om å behandle databaser og servere som kjæledyr. Servere har navn, du behandler dem som om de er unike ting, du behandler dem som storfe, det er å forvalte en flokk. Og problemet med å forvalte besetninger er at hvis du ikke kontrollerer dem, kan de til slutt stemple, og et stampede er ikke noe bra. Vi trenger bedre overvåkingsverktøy, vi trenger bedre måter å takle dette og vite hva som er blitt påvirket. I den gamle modellen var det lettere fordi ops og alle kontrollsystemene dine fortalte deg, men når servernavnet ditt er en UPC-kode, er det litt vanskelig å finne ut av det.

Du har ikke råd til falske varsler, du har ikke råd til ting som sier "Det er et problem med denne maskinen, og den maskinen er vert for 30 databaser." Du har ikke råd til å ha ting som ikke gir deg historie. Overvåkningskonsoller er flotte når de lyser, men hvis det røde lyset blir grønt igjen og du ikke vet hvorfor, og du ikke har noen historie å gå tilbake til for å se på hva som ledet fram til det, og hva konteksten var, du har problemer. Vi trenger systemer som vil overvåke for oss, vi trenger bedre overvåking og håndtere de kursive periodiske problemene som opprettholder datahistorikken.

Bedre ting og enkle beregningsterskler som gir oss viktige beregninger, men ikke leder oss direkte inn i hva som er normalt, hva som er unormalt og hvor ofte disse problemene oppstår. Det vi egentlig snakker om er en kombinasjon av overvåkingsmiljø og å takle ytelse, og leverandørene har sittet på hendene. De har ikke gitt oss bedre verktøy. Vi har systemer med mer CPU og minne enn vi vet hva vi skal gjøre med det hele, og likevel er vi fortsatt avhengige av manuelle intervensjonsmodeller, vi har ikke satt maskinen i gang, for å veilede oss, for å komme oss til poenget med problemer, vi har ikke fått til denne nye stilen, som er: "Det er et problem her, du kan gjøre dette for å fikse det, " eller "Det er et ytelsesproblem, det er faktisk med denne spesifikke SQL-setningen, her er tre ting du kan bruk for å fikse den SQL-setningen. ”Bruk heuristikker, bruk maskinlæringsmodeller som kan se på bruksmønstrene til systemet ditt for å oppdage problemer og unngå falske varsler. Bruke maskinen til å gjøre det maskinen gjør best, for å forsterke DBA, eller for å forsterke personen som må takle ytelsesproblemer.

Det er den nye måten, i motsetning til den gamle stilen. Det er et problem med denne databasen, ting går sakte, og derfor har vi nye teknikker, nye måter å gjøre det på, og vi bør bruke dem, og det er der markedet er på vei. Du ser at det begynner å gro opp, ikke med de store leverandørene, men med tredjepartsselskaper, og dette speiler noe som skjedde for 20 år siden da databaseleverandørene ikke ga en eneste ting for å administrere systemene. Så det er sånn retningen på markedet er, og med det vil jeg gjerne gi den tilbake til Eric.

Eric Kavanagh: OK, jeg overlater det til Dez. Og Dez, ta det bort, gulvet er ditt.

Dez Blanchfield: Takk, Mark. Du har gjort en fantastisk jobb med å dekke den tekniske delen av det. Jeg kommer til å komme fra det fra en litt annen vinkel for å synliggjøre hva som skjedde i resten av verden, så langt det påvirker bedrifter og databasene rundt dem. La meg bare hoppe til mitt første lysbilde.

På baksiden av det du nettopp har dekket fra den tekniske siden av tingene og utviklerens side av tingene, ser jeg at bedrifter må møte utfordringene med data og databaser spesielt, og tydeligvis har vi hatt dette betydelige skiftet mot dette konseptet med big data, men databaser er fremdeles hjertet og sjelen der organisasjoner beholder sin forretningsinformasjon, og det er fra inngangsdøren helt til back office. Hver del av organisasjonen blir berørt av en database av en eller annen art og drevet av en database, og veldig sjelden går jeg verken i prosjektdiskusjoner, eller noen form for nyskapende strategisk samtale i en organisasjon der temaet til databasen eller databasesystemet dukker ikke opp, og det er alltid spørsmål rundt hva slags ting vi nettopp har hørt om, når det gjelder ytelse og sikkerhet, og hvordan kommer utvikling tilnærming til denne utfordringen, og hvor passer databasene, og vi er klar over miljøer og applikasjoner miljøer snakke med, hva med enheter og mobilitet?

Det er fremdeles et veldig, veldig varmt tema, og det har vært et i lang, lang tid i den store tingenes ordning så langt som moderne teknologi går. Til det punktet tror jeg det er et faktum at nesten alt vi gjør i våre daglige liv, hverdagen vår, det vil si, nå støttes av en form for database. Når vi tenker på alle tingene rundt oss, enten det er en regning som kommer i posten hver dag for noen tjenester vi kjøper, blir den uunngåelig skrevet ut av et system som snakker med en database, og vi er der inne. Telefonene våre har databaser med kontakter og anropslogger og andre ting.

Uansett hvor vi går, er det en form for database bak samtalen og systemene vi bruker, og oftere er de ganske gjennomsiktige for oss, men faktum er at de er der. Så jeg tenkte at jeg bare raskt skulle dekke hvorfor dette har blitt litt av et problem på veldig kort tid. I begynnelsen kom databasekonseptet fra denne herlige mannen, Edgar Codd. Mens han jobbet hos IBM, forandret han verden så langt som datahåndtering går ved å lage et konsept som vi nå omtaler som en relasjonsdatabase.

I begynnelsen var databasen en database, og livet var bra, det var ganske greit både i kolonner, og referanser, og så videre, og tabeller, og utvikling av programvare var ganske grei, og ytelsen var egentlig ikke så stort problem - det var en ny spennende teknologi. Vi fikk tilgang til databasene gjennom en form for terminal, og du kan bare virkelig skape så mye ødeleggelse på slutten av en 3270 terminal på en hovedramme, og alltid andre typer terminaler, de andre systemene fulgte med. Og i de fleste tilfeller var de gamle stilterminalene veldig like hva nettmiljøene er nå, og det er at du ville fylt ut et skjema på skjermen på selve terminalen og trykket på Enter og av det ville gå, det ville skyte av som en pakke, som en forespørsel, og back-end-systemet ville takle det. Det er egentlig det som skjer i en nettleser i disse dager, når du skriver inn en kobling i en nettleser, og den formen går den vanligvis ikke i sanntid tilbake til systemet, selv om det med AJAX i disse dager ikke er det sak.

Men så skjedde det noe, fremtiden ankom, og mer nylig internett, og nesten i går, i et sekund web 2.0, og rett rundt hjørnet har vi fått tingenes internett. Og i prosessen med at fremtiden skal skje, har databasens verden nettopp eksplodert, og interaksjonen med databaser ble bare en ting som vi alle gjorde som standard, det var ikke et tilfelle at du ville dra et sted for å gjøre noe, som å kjøpe en billett til et fly, og vil reise til den andre siden av planeten, måtte noen skrive inn terminalen alle detaljer og gå inn i en database og skrive ut en billett.

Nesten alt vi gjør nå, enten det er å hyle en drosje på Google med en applikasjon, om det er å hoppe på nettbank, alt vi gjør på en daglig basis, med et slags system, det drives av en database. Og da internett fulgte, var det litt lettere å ta med oss, hverdagen vår gjennom en nettleser, og så kom web 2.0 sammen og ting ble mobile, og omfanget av ting bare eksploderte. Faktisk er favorittlinjen min i dette emnet at "Internett koblet alt sammen, web 2.0 gjorde det mobil og sosialt, og ting ble veldig, veldig stort, og nå har vi internett og ting og, og IoT … Yikes !!" Vi har ikke engang begynt å forestille oss virkningen av tingenes internett når det gjelder verden på databasesystemer.

Så i moderne termer, det vi pleide å tenke på som en terminal, har blitt disse tingene, det er mobiltelefoner, det er forskjellige typer nettbrett, enten personlige forbruker- eller enterprise-klasse store skjermtabletter, det er bærbare datamaskiner og det er det tradisjonelle skrivebordet i en eller annen form. I det ene bildet kan du se nesten alle former for grensesnitt som vi nå bruker for å snakke med databasesystemer og apper som er drevet av disse, fra de små dingsene i hendene våre som går rundt og vi ser ut til å være limt til, alle veien videre til de litt større versjonene, og iPads, og andre nettbrett og Microsoft Surfaces, til hverdags bærbare datamaskiner, som alltid er tilfelle i profesjonelle miljøer og så videre. Folk har en tendens til å skaffe seg en bærbar datamaskin og ikke et fast skrivebord, men de er den moderne terminalen etter mitt syn, og er en del av grunnen til at databaser opplever alle slags utfordringer i ledelsesresultatens del av livene våre, og ikke bare utvikling.

Så jeg antar at det er en av de største utfordringene som bedrifter fremdeles står overfor på en daglig basis. Alle trodde databaser var våre eneste problemer, det er de ikke. Så hva handler alt om? Vel, når vi går fra den ene enden til den andre med alle ting knyttet til databaser, fra kommersiell forstand, og Mark's dekket de tekniske komponentene veldig, veldig bra, men i kommersiell forstand, som organisasjon, tenker vi på databaser. Vi arbeider med ting helt fra grunnleggende design og utvikling frontend. Når en bedrift starter, vil de tenke på å utvikle applikasjoner, utvikle en evne eller til og med implementere en eksisterende applikasjon i en eller annen form. Noe form for design og utvikling må skje, og det må settes en god del tanker på hvordan disse databasesystemene skal implementeres, støttes og administreres, og forestillinger spores og så videre.

Integrasjonen av databasemiljøet og applikasjonene, og typene API, tilgangstypene som blir gitt nå blir mer og mer utfordrende, mer komplekse. Daglig administrasjon, support og sikkerhetskopiering, igjen, dette er ting som vi trodde ble løst, men så plutselig ble skalaen mye større, og ting beveget seg raskere, og volumet er så mye større; Størrelsen på miljøene, databasesystemene måtte støtte hastigheten som transaksjoner beveger seg.

Tenk på en database i et veldig, veldig høyfrekvent handelsmiljø, det er bare ingen måte mennesker kan følge med på, det er bare en klynge av maskiner som kjemper mot en annen klynge av maskiner for å utføre høyfrekvent handel, kjøp og salg, og volumet på som disse transaksjonene skjer. Tenk på et moderne scenario, som en tidlig utgivelse av en Netflix-film der du ikke snakker om bare hundre eller tusenvis, eller til og med hundretusener, potensielt millioner av mennesker som ønsker å se den filmen helt fra den ble utgitt. All denne informasjonen blir fanget, sporet og logget og analysert i en databaseplattform.

Og så er det den verden som vi alltid lever i nå, 24/7, ikke bare følger solen, men det er alltid noen opp ved midnatt som ønsker å gjøre noe, og arbeidstiden følger sola over hele verden. Så oppetid og tilgjengelighet er som standard, er et klima nå, å ha et strømbrudd er egentlig ikke en akseptabel ting. Og overflødighet, hvis det er et ytelsesproblem, eller hvis vi trenger et vedlikeholdsvindu for å gjøre en oppgradering eller en oppdatering, eller en sikkerhet, virkelig, må vi være i stand til å kutte fra et databasemiljø til et annet og gjøre det sømløst og automatisk.

Sikkerhet og standarder og overholdelse. Vi har hatt noen ganske store ting i sen verden, spesielt GFC, og derfor har vi en rekke nye utfordringer å møte rundt samsvar, sikkerhet og matchende standarder, og vi trenger å kunne rapportere om de i sanntid, og ideelt sett i en dashbordform. Vi ønsker ikke å sende et team med aper ut til et datasenter som prøver å finne ting, vi trenger at systemet skal fortelle oss det umiddelbart, i sanntid.

Og de to store morsomme som nesten ingen noen gang snakker om, vi skyver dem generelt under teppet og håper at de ikke noen gang hever sitt stygge hode, men katastrofegjenoppretting og kontinuitet i kontoret - dette er også ting som bør det meste skjer automatisk hvis behovet skulle oppstå.

Vi kunne tilbringe dager på å snakke om hva slags ting som kan gå galt i databasemiljøer, og at mennesker generelt har svart, men nå trenger vi systemer og verktøy for å gjøre det for oss. Et eksempel er et datainnbrudd, og når vi tenker på databaser, og jeg stiller dette spørsmålet ganske åpent i forskjellige former: hva skjer med databaser når vi tar blikket fra ballen, og noe kritisk går galt? Spesielt hvis det ikke er et system som ser på ytelse og sikkerhet og andre viktige aspekter ved å kjøre databaser.

Det som kan skje, er dette, dette er et skjermbilde av noen av de siste bruddene de siste to til tre årene. Unødvendigvis har disse alle kommet fra et databasesystem, og alltid har det vært noe problem med sikkerhet eller kontroll, eller tilgang som har oppstått, og i øverste venstre hjørne ser vi på 152 millioner Adobe-kontoer, der alle detaljer av disse kundene ble brutt. Og hvis det var aktuelle verktøy som kan ha vært på plass for å spore og fange hendelsen, og kontrollere sikkerheten, kan vi ha unngått noen av disse, de første par hundre postene som ble stjålet kunne ha varslet oss, og vi ville ha stoppet de neste hundre og femti millionene.

Så kommer vi til nøkkelpunktet for hele denne reisen, ført oss gjennom, det vil si: hvorfor trenger vi bedre systemer? Hvorfor kan vi ikke bare kaste flere kropper på denne tingen, at vi vel og virkelig har krysset vippepunktet etter mitt syn, og absolutt tror jeg det er en sak som har vært bevis på at det er sent, som kaster flere DBA-er, administratorer og flere mennesker på denne tingen løser ikke problemet. Vi trenger et bedre sett med verktøy og et bedre sett med systemer.

Her er de fem beste grunnene til at jeg tror støtter dette, og de er rangert i rekkefølge av betydning, basert på hva jeg ser på tvers av disse private virksomhetene og statene som er styrte miljøer, utfordringene de står overfor med databasemiljøer, og administrere dem.

Sikkerhet og etterlevelse - nummer én. Du vet, kontrollere hvem som har tilgang, hvor har de tilgang, når de har tilgang, hvor ofte de har tilgang, hvor de har tilgang til den fra. Potensielt de enhetene de faktisk har rørt og hvilke ting de har sett på, og samsvaret som følger det. Å ha mennesker som kjører rapporter 30 dager senere for å fortelle oss om ting er greit, er ikke passende lenger, det må skje i sanntid.

Ytelse og overvåking - det virker som om det ikke er noen brainer, men alltid er det ikke det. Enten vi bruker åpen kildekodeverktøy eller noen tredjeparts kommersielle verktøy, har vi alltid ikke savnet båten på mange måter med de typer ytelsesovervåkning som kreves, og detaljene som og muligheten til å svare i tide .

Oppdagelse og respons av hendelser - det må være en øyeblikkelig ting i sanntid, og alltid trenger vi et system for å gjøre det for oss, eller i det minste varsle oss raskt slik at vi kan takle det, slik at de få problemene som oppstår blir behandlet med raskt, og ikke kaskader ut av kontroll.

Ledelse og administrasjon - igjen, vi tror at disse problemene er løst, de er det ikke. Målet med problemer som databaseteam blir møtt, spesielt DBA-ene der et system skal ta seg av ting for oss, vi har ikke løst det problemet ennå, det er fremdeles en ekte ting.

Og helt fra frontend med design og utvikling, når vi begynner å bygge disse verktøyene, bygger vi databasemiljøene, er i stand til å kaste de aktuelle verktøyene på utvikling og testing, og integrasjon, plattformer. Dette er fremdeles ikke en enkel ting for oss å gjøre, og hele reisen, den driver oss på en måte til den samme beskjeden, at i mitt sinn trenger vi bedre systemer og bedre verktøy for å hjelpe oss med å levere resultatene vi trenger fra databasemiljøet vårt, slik at virksomhetene som gir verdi fra kundene våre. Vi kan ikke bare fortsette å kaste flere kropper og flere DBA-er, skalaen er for stor, hastigheten er for rask og volumet er for høyt. Med det, Eric, vil jeg kanskje komme tilbake til deg.

Eric Kavanagh: Jeg elsker det, vi har mange grunner tildekket der folk, mange potensielle kunder, og vi fortsetter og overlater de nøklene til Bullett på bare ett sekund.

Bullett Manale: OK.

Eric Kavanagh: Å, la oss ta det bort og Bullett, nå overlater jeg det til deg, og gulvet er ditt.

Bullett Manale: OK, takk. Jeg tror det er kommet mange gode poeng. Jeg ønsket å snakke raskt et øyeblikk om Idera, hvem vi er, og så hopper vi inn. Jeg skal snakke om verktøyet som jeg tror mye av det vi snakker om, vi kan slags sett og slags diskuter noen av områdene der disse justeres, med dette verktøyet, Diagnostic Manager-produktet.

Det jeg vil gjøre først, er bare å gi deg litt bakgrunn om hvem Idera er; Vi har eksistert siden omtrent 2003, og derfor har vi startet med bare SQL Server-verktøy, og det er det vi kommer til å fokusere på i dag, er, ville være Diagnostic Manager-produktet. Men du kan se alle bøttene med tingene vi har her, og vi har nylig, som nevnt tidligere, skaffet oss presise og gjennom anskaffelse har vi også Embarcadero, og derfor har vi en ganske god portefølje av produkter.

Når det gjelder ytelsesovervåking, i form av SQL Server, er produktet som jeg vil snakke om, som justerer disse emnene vi diskuterer, Diagnostic Manager. Nå, dette er et produkt som har eksistert siden ganske nær begynnelsen av dagene av Idera, og jeg har vært heldig nok til å være en del av det siden rundt 2005. Og jeg har sett mye av endringene mht. SQL Server, skiftene fra fysisk til virtuell, alt det slags som har skjedd, og også behovene til DBA-ene når miljøene vokser, og de slags ting.

Det jeg startet med, var den typiske brukeren av produktet vårt, DBA, og når vi snakker med folk for første gang, potensielle kunder, er det mest DBA-ene vi snakker med. Vi snakker ikke med IT-sjefene eller direktørene, det kan på et tidspunkt komme til det nivået, men det første utbruddet er at DBA har et problem, DBA prøver å løse problemet, og mange ganger har vi Du kan laste ned og prøve ut produktet som en del av det. Du får enten databehandler eller DBA eller fungerende DBA, fyren som er heldig nok til å være den mest tekniske i rommet, i noen tilfeller. Nå, når du kommer til de større bedriftsmiljøene, selvfølgelig, så kommer du til å få fullverdige DBA-er, vanligvis vil de være de som bruker verktøyet. Og jeg gikk foran og bare la til en liten blurb her fra Wikipedia. Det går på en måte over DBAs ansvar som Wikipedia sier, det er det de gjør.

Hvis du går gjennom oppføringen her, mange av disse tingene, skal jeg ikke lese den av, men du får mye av de typiske tingene du vil tenke på, og så på en av dem, har du overvåking og optimalisere ytelsen til databasen, og det er ganske stort. Og det som er interessant, er at når du snakker med DBA, er de alltid de som får skylden først, når det kommer til problemer, og det er kanskje ikke egentlig deres skyld, men når det er et ytelsesproblem, vanligvis med et program som er knyttet til en DBA-database, det er de som får skylden, så de leter alltid etter grunnene til at det ikke er deres skyld. I mange tilfeller er det det de kan bruke dette verktøyet, Diagnostic Manager, for å hjelpe dem.

Men på slutten av dagen, hvis databasen ikke presterer, betyr det at mange av disse andre tingene ikke spiller noen rolle, applikasjonene dine fungerer ikke, og det betyr ikke noe for mange av disse tingene. Først og fremst ønsker vi å være i stand til å sikre at brukeren opplever slik vi kjenner den, ikke blir redusert, det er noe som DBAs alltid streber mot. Og jeg tror at hvis du ser på årsakene til at folk vanligvis kjøper og bruker SQL Diagnostic Manager-produktet, er en av de første grunnene, sannsynligvis ikke de fremste, ikke sist eller minst, men det er lik over hele linjen, og avhengig av hvem du snakker med, disse grunnene, nesten en eller to av dem alltid er, er det et slags behov rundt.

Men den første er bare å kunne ha det sentraliserte synet på forekomstene som en SQL som de administrerer. Og det morsomme er at i mange tilfeller, hvis du spør en DBA, "Hvor mange tilfeller klarer du det?" Antallet endres så ofte at de ikke er helt sikre i noen tilfeller. Så du trenger noe mer enn bare å kunne kaste alt opp på skjermen. Du vil ta tak i den informasjonen, du vil forstå det, og det er noe av det Diagnostic Manager absolutt kan hjelpe med, er å kunne gi deg den slags syn på miljøet.

Og det er ikke bare et syn på miljøet, men det er et synspunkt som DBA, databaseadministratoren, er komfortabel med, og det er en konsoll som er DBA-sentrisk, hvis du vil. Den er laget for en databaseadministrator. Det er mange overvåkningsverktøy der ute, det er mange ytelsesverktøy der ute, men som sagt, på slutten av dagen, ønsker DBA et verktøy som er designet for en DBA, fordi det er mange ting som er spesifikke for hva de gjør i dag til dag.

Og med det sagt, har du SCOM, har du HPF, har du alle disse andre teknologiene, men de vil ha noe som er spesielt det de gjør. Jeg tror at vi kan hjelpe på det området med dette produktet, du får se når vi kommer inn på det om et sekund. Den andre tingen vi ser med DBA, som absolutt er en av tingene vi rørte ved tidligere også, er at de selvfølgelig må kunne se hva som skjer, og at de må kunne se på hele bedriften og ha litt ro i å vite hva som skjer. Men samtidig sitter de ikke og stirrer på konsoller.

Husker du alle de kulepunktene du så på listen, at jeg nettopp dro opp? De må gjøre de andre tingene også, så det handler ikke bare om å vente på at branner skal slukke. I mange tilfeller vil det være møter, eller mange vedlikeholdsvinduer relatert til databaseadministratoren kjører midt på natten når de sover, så de må ha muligheten til å gå tilbake og se hva som skjedde . I mange tilfeller, hvis du ikke fanger noe når det skjer, når problemet først er borte, eller i det minste med SQL Server, blir det slags problem der du håndterer situasjonen der du ikke har noen rester av det problemet lenger. Og problemene forsvinner, og det samme gjør restene, noe som betyr at du har mindre å feilsøke, du har mindre informasjon å jobbe med.

Når det er sagt, er det definitivt en av tingene som Diagnostic Manager kan hjelpe med, er å gi deg det synet på fortiden for å spørre informasjonen fra fortiden, "Hadde jeg et varsel om blokkering, hadde jeg problemer med dødeliggjøring, hadde vi ting som skjedde med tanke på ressursene våre? ”Jeg kan gå tilbake og spørre om den informasjonen. Jeg kan bore inn i bestemte punkter i tide. Jeg vil kunne gjøre alle disse tingene direkte fra verktøyet.

Alle disse tingene, til tross for om det er internt eller eksternt program, vil DBA vite det, fordi de vil være i stand til å se hva som forårsaker problemet. Det spiller ingen rolle om det var noen i organisasjonen, eller noen utenfor organisasjonen som skrev koden; de ønsker fortsatt å være i stand til å isolere det, slik at de vet at problemet skjer, og de vet hvor det kommer fra.

Så ytelse og ansvarlighet er en sentral del av det produktet vårt gjør. Vi kan tilby alle disse detaljene, og hva som er hyggelig, er at du har muligheten til å bore ned. Hvis det er en flaskehals, kan du korrelere det med applikasjonen, til brukeren, til databasen, til spørringen. Og nok en gang, det er en slags røykepistol. Du får en direkte sammenheng mellom når denne spørringen kjører, hva gjør den? Og det handler ikke bare om selve spørringen, med tanke på at den kjøres i seg selv, men også blir spørringen over tid verre? Og de tingene kan også besvares, med produktet, som absolutt er noe som hvis du prøver å være proaktiv, er det fint å kunne si: "Hei, her er et spørsmål som gikk dårlig, men gutten se på det når det går lenger, kan vi se at det kjører enda verre og verre, det kan jeg gjøre noe med. "

Hvis vi går inn i det neste området her; og dette er sannsynligvis - jeg vil si at dette er en av de store. Ett av spørsmålene jeg stiller, når jeg viser produktet vårt, vil jeg alltid spørre databaseadministratoren: "Hvordan hører du om et problem relatert til SQL Server-databasene dine?" Og det er veldig morsomt, fordi det meste av tiden - nå innvilget, mesteparten av tiden de ser på produktet vårt, fordi de i mange tilfeller prøver å løse et spesielt behov. Men det er interessant å høre den første typen ting - i det minste med SQL Server, er at det var slags - du vet, i de første dagene av SQL Server hadde du SQL Server og så hadde du Oracle. Og alle hadde Oracle, og SQL Server var lik den, på grunn av mangel på et bedre uttrykk, det rødhodede stebarn til databaser, da den startet.

Og da Microsoft la til flere funksjoner til det, ble det litt mer av et bedriftsverktøy. Og tydeligvis er det kommet langt siden den gang. Men poenget er at en gang kan du hevde at databasene ikke ble ansett som kritiske på dagen. Og det har endret seg over tid. På grunn av dette prøver folk i mange tilfeller å få hendene rundt det, og sier: “Vet du hva? Jeg har alle disse SQL Server-databasene, jeg prøver å få tak i det. "Og heller enn å høre om problemer fra hjelpeapparatet, eller høre om problemer fra de spesifikke personene som - som brukerne selv, de ' De leter etter måter å kunne bli gjort oppmerksom på disse situasjonene før de noen gang skjer.

Og så med Diagnostic Manager er det en av tingene, vi prøver å gjøre også, i det minste være i stand til å gjøre at DBA er den første til å vite om disse situasjonene, eller de problemene, slik at de kan gjøre det noe med det, enten riktig når de skjer, eller for å ta det enda et skritt videre, for å analysere disse systemene som den overvåker. Og for å kunne gi deg proaktive råd som vil forbedre ytelsen til den forekomsten, og å kunne gjøre det med jevne mellomrom. For eksempel må vi legge til en indeks, basert på arbeidsmengden; de typer ting, verktøyene som også kan gjøre. Så vi får se mye av det i verktøyet.

Den andre tingen og den siste tingen som er på denne listen, som er litt mer av en generell beskrivelse, men det er noe absolutt verdt å merke seg. Og spesielt når du kommer inn i større situasjonstyper av situasjoner, hvor du har mange tilfeller, vil det alltid være en uklar ting som jeg vil ønske å overvåke, hvis jeg er databaseadministrator, for eksempel. Og det vi prøver å gjøre er å forutse med tanke på hva den typiske DBA vil ønske å overvåke.

Når det er sagt, vil du også være i stand til - det vil alltid være noe nytt. Så vi ga en måte for deg å legge til de beregningene du trenger for å overvåke og administrere etter at installasjonspunktet kan legges til. Så alle PerfMon-tellere, WMI-tellere, SQL Server-telleobjekter; alle disse kan integreres i verktøyet. Du har muligheten til å legge til flere spørsmål som kan integreres i pollingintervallene dine.

Og det siste som også er verdt å merke seg, er at vi kan legge til, og faktisk kommunisere med både vCenter og Hyper-V for å kunne trekke beregningene fra disse miljøene. Fordi en av tingene vi har identifisert med DBA, er at de vanligvis ikke er en del av operasjonene spesielt. Og de har ikke nødvendigvis vCenter-miljøet, tilgjengelig for dem, eller slike ting tilgjengelig for deg.

Og problemet er at hvis de har å gjøre med en SQL Server-forekomst, og de har fått tildelt ressurser, men den forekomsten er virtualisert, kan det se ut som om de har alle ressursene i verden, når de bare overvåker hva som er på gjestesystemet. Realiteten er at hos verten kan det være 30, 40, eller 50 eller 100 andre VM-er som de prøver å få tilgang til, og som har strid med de samme ressursene. Og den eneste måten å faktisk se det på er å kommunisere med de andre miljøene og til de grensesnittene, i dette tilfellet, som vi gjør.

Du har muligheten til å legge til de andre typer tellere i verktøyet. Nå handler det ikke bare om å kunne overvåke disse tellere, men det handler om å kunne gjøre de nye tellere, at du introduserer produktet, gjør dem til en del av verktøyet, som om de var en out-of-the-box metrisk . En ut-av-boksen ting du ønsker å overvåke; så det betyr å kunne integrere dem i dashbordene. Det betyr å kunne legge dem til i dine egne tilpassede rapporter, å selvsagt kunne angi terskler og varsle om dem, men også legge dem til grunn og kunne stille tersklene med viss kunnskap om hvor du kan stille dem inn basert på ting som din baselinjer og hva som er normalt. Så, du har mye av den slags ting som også er i produkt.

Det jeg har gitt deg, er det jeg kaller “kjerneproduktene for Diagnostic Manager”, og jeg kan fortsette og bare gi deg en liten smakebit av det ved å gå inn på produktet. Det jeg skal gjøre er del ut skjermen min, ok, og bare skal dra dette over. Så hva du kommer til å se, dette er konsollen for Diagnostic Manager. Og som jeg nevnte før, å gå til den første kjernen som kan leveres, å kunne se på ting fra en slags visning på et bedriftsnivå. Det er mange forskjellige eksempler på det i verktøyet. Vi har et slags miniatyrbilde; vi har mer et rutenettlignende synspunkt. Vi har også, når det gjelder fleksibilitet, vi har en nettbasert konsoll også. Den nettbaserte konsollen har andre synspunkter som er tilgjengelige for deg, som nøkkelkart og sånt. Men poenget er at du har den evnen til å se på og se ting på et høyt nivå. Men når det oppstår problemer, kommer du til å grave litt lenger ned i verktøyet, og faktisk se den spesifikke prob lems, og har en måte å forstå og vite hva som skjer. Og det er tydeligvis veldig viktig.

Nå, i forhold til å kunne se hva som skjedde tidligere; Hvis jeg ser på et problem som skjedde i går, eller for en uke siden, så vil du i den situasjonen ha behov for å kunne gå ut til en bestemt forekomst av SQL. Og den gode nyheten er at hvis du vet hvilken tid det problemet skjedde i produktet, kan du gå direkte til historikkleseren. Og jeg kan peke på et bestemt tidspunkt på dagen; det kan være fra et par uker siden, det kunne være fra i går. Men uansett hvilken dag jeg velger fra i kalenderen, vil jeg bli presentert for de forskjellige valglokalene. I så fall ser jeg effektivt hva jeg ville ha sett hvis jeg hadde sett konsollen 20. april kl. 13:37

Så jeg kan gå tilbake i tid, og når jeg først har gjort det, vil alle de forskjellige fanene som vi ser her gjenspeile det bestemte tidspunktet, inkludert spørsmålene som kan ha kjørt dårlig, inkludert kanskje hvis Jeg hadde økter med blokkering. Alt det slags dukker opp i verktøyet, og det vil gjøre det mulig for meg å åpenbart utnytte den historiske informasjonen for å kunne løse problemet. Når vi snakker om historien, er det det andre som er verdt å merke seg her, ikke bare å bruke historikken til å fikse problemer. At historien er åpenbart veldig verdifull, av andre grunner. Og en av de store er å kunne ta beslutninger effektivt, og å kunne ta beslutninger raskt, med riktig informasjon. Så all den historien, all informasjonen vi samler inn, kan vi rapportere mot.

Hvis noen kommer til meg og sier, "Jeg har fått denne virkelig nye applikasjonen. Den kommer til å forandre verden slik vi kjenner den. Åh, forresten det krever en database, og åh forresten virkelig vil knytte den I / O på maskinen der databasen er. " Hvis jeg vet at det går ut på det, kan jeg utnytte den informasjonen for å kunne gi en rangering av alle produksjonsserverne mine, kanskje basert på de siste sju dagene av samlingen. Og jeg vil raskt kunne komme til konklusjonen om hvilke tilfeller som er mest fornuftig å bruke databasen på. Så det er den typen historisk informasjon som også åpenbart er veldig verdifull.

Når det gjelder selve spørsmålene; når det gjelder å se på spørsmålene, har vi mange forskjellige måter å gjøre det på i verktøyet. Og den jeg liker å se på er Query Waits View, fordi Query Waits View er veldig nyttig når det gjelder å kunne vurdere. Hvis jeg har en flaskehals som oppstår, for å kunne identifisere alle de forskjellige områdene som påvirker den spesifikke spesifikke spørringen; ikke bare selve spørringen og hvilken innvirkning det har, men også, du vet, hvilken applikasjon den kom fra, hvilken økt den kom fra, hvilken bruker som kalte den og alle disse tingene. Jeg kan se den informasjonen åpenbart i sanntid, men jeg har også muligheten til å se på data fra fortiden. Og det er en av tingene her, og jeg sparket i gang et manus, men jeg må vente på at det dukker opp.

Mens vi venter på det, vil jeg - og jeg vet at vi har kort tid, så jeg ønsket å snakke litt også om at varsling av varsel er proaktiv. Og når du snakker om den typen ting, som jeg sa, å være den proaktive delen, er det mange verktøy som gjør varsler. Den vanskelige delen er ikke å sende en e-post. Den vanskelige delen er ikke å skrive til hendelsesloggen eller generere en SNMP-felle. Den vanskelige delen er å vite når jeg skal sende varselet til riktig tid. Og med det kommer mye av å måtte gjøre noen beregninger, å måtte forstå, "Hva er det med den spesielle forekomsten og hva er normalt når det gjelder den forekomsten?"

Og så for alle beregningene som er fornuftige å gjøre det med, baserer vi disse beregningene. Vi viser deg faktisk grunnlinjen, vi viser deg terskelen som den for øyeblikket er satt til. Og så er den andre fine tingen ved det, la oss si, jeg setter tersklene mine til i dette tilfellet seks og ti bare for dette eksempelet. Seks uker fra nå, hvis jeg kommer tilbake til dette tilfellet, kan denne grunnlinjen endre seg fullstendig, fordi en av tingene vi gjør når vi beregner grunnlinjen, som standard, er en rullerende syv-dagers beregning. Så det gir meg alltid en oppdatert versjon av grunnlinjen. Og hva skjer hvis den grunnlinjen skifter opp i tersklene mine? I dette tilfellet kan jeg se og varsle anbefalinger som i utgangspunktet sier: "Hei, du har en terskel som antagelig er satt feil, spesifikk for hvor vi ser at terskelen er, og tydeligvis hvor grunnlinjen er, kommer du sannsynligvis til bli varsling om noe som er en normal forekomst. "

Og i stedet for å behandle et symptom på noe som er normalt, er jeg i stand til å identifisere den typen situasjoner der den faktiske terskelen er satt feil. Og det som gjør at jeg selvsagt kan gjøre, er å stille terskler i samsvar med hvor jeg skal varsle. Det er noe jeg vet er mer en oppfordring til handling versus en etterforskning for å se om det virkelig er et problem. Og jeg tror at en del av verktøyet virkelig er nyttig med tanke på selve grunnlinjen, og å kunne beregne.

Nå, med dette produktet, har du muligheten til å faktisk ha flere baselinjer; Du kan angi dem for forskjellige tidsperioder, og du kan dynamisk justere tersklene basert på basislinjene dine, noe som også er veldig viktig del av typen tilpasning til endringene som skjer i det daglige til dine SQL Server-forekomster . Nå, i dette tilfellet her, dekker vi ganske mye av innstillingene for terskelverdiene, og viser deg grunnlinjene. Men når det gjelder de faktiske varslene, er varslingen i seg selv, den kule tingen med Diagnostic Manager, at den gir deg flere varslingsprofiler. Så hvis du for eksempel har en telefonprofil som er fra 02.00 til 17.00, kan jeg ha en profil som er spesifikk for akkurat det tidsområdet, og jeg kan stille alle betingelser, og de riktige innstillingene her for mitt svar.

Nå, tinget med svaret er at i noen tilfeller, ja, jeg kan sende en e-post, eller jeg kan skyte av og generere en SNMP-felle, eller skrive til hendelsesloggen. Det er mange andre ting vi kan gjøre, men når jeg snakker med DBA-er, er det det de virkelig liker, at i de fleste tilfeller er mye av arbeidet som utføres repeterende ting. Det er ting som de vet nøyaktig når problemet skjer, hva de skal gjøre for å fikse det. De må bare gå og gripe inn. Når du vokser miljøet ditt, etter hvert som du har flere tilfeller, blir det mye vanskeligere å gjøre. Så en av tingene du kan gjøre i verktøyet som jeg synes er verdt å merke seg, er at du har muligheten til å sette opp en betingelse, men basert på den betingelsen for å kunne stille svar til å kjøre et skript, til å kjøre en jobb, for å drive en kjørbar. Og poenget er at hvis du bestemmer deg for å kjøre et skript, kan jeg bruke parametere, inne i det skriptet som vil være på kjøretid, fylt med den faktiske informasjonen.

Så hvis det er problemer med en spesifikk database, vil skriptet være designet for å kjøre bare mot databasen der problemet skjer. Så du kan adressere problemer dynamisk på en automatisert måte, og da kan jeg fortsatt motta en e-post for å komme tilbake og fortelle meg at "Hei, det var et problem, men forresten, det var løst." Manuset ble kjørt, og som DBA vet du om det, men du trengte faktisk ikke å gå inn og gripe inn. Nå, på den samme notatet om å være proaktiv, har vi tydeligvis også en annen funksjon her, som er "Analyser" -funksjonen. Og hva dette vil gjøre er at det vil gjøre en jevnlig sjekk, mot forekomsten av SQL. Og i noen tilfeller vil den gjøre et dypere dykk når det gjelder hva det leter etter. Ting som hypotetisk indeksanalyse vil bli utført. Legger jeg en indeks? Fjern jeg en indeks? Og alle de slags ting kommer tydeligvis til å hjelpe med prestasjonene mine, men nok en gang handler det om å være proaktiv. Det handler om å kunne ta beslutninger før ting går i stykker, og få det til å løpe bedre. Og i mange tilfeller er det virkelig det vi prøver å gjøre her.

Gå tilbake til spørring Venter på at vi snakket om tidligere; som du kan se, det er en stor pigg her. Jeg kjørte et skript tidligere som bare forårsaket litt venteaktivitet, og som jeg nevnte før, har vi en veldig unik måte å se nærmere på denne informasjonen. Hvis jeg vil se hvilken applikasjon det var; Jeg kan se at det kom fra NoSQL-applikasjonen. Vi vil kunne se databasen den var bundet til, økten, brukeren, og hvis jeg vil, kan jeg rangere dette også når det gjelder ventetid. Så, jeg kan si, av alle ventene som skjedde i det tidsvinduet, hvilke som skjedde mest? Og hvis jeg ser at når det har skjedd mest, er det virkelig hyggelig at jeg kan bore inn i den ventetypen, og jeg kan se alle kommandoene. Hvis du ser her, fikk de ventetiden til å skje. Og jeg kan også først og fremst se hvilken applikasjon det var, som fikk den ventetiden til å skje.

Så den stikker ut som en sår tommel. Jeg kan umiddelbart gå og si: "Dette er applikasjonen som forårsaker flaskehalsen min. Hva var spørringen som ble kjørt? Hvilken bruker kjørte den? Hvilken database kjørte den mot?" Og så videre. Så forhåpentligvis er det fornuftig, og det hjelper også når det gjelder å sørge for at du ikke har latensen i omgivelsene dine, for det gjelder din databaser. Forhåpentligvis er dette nyttig. Jeg kommer til å gå videre på dette tidspunktet og gi det tilbake, og jeg antar vi kan fortsette derfra.

Eric Kavanagh: Visst. Så jeg antar at jeg bare vil kaste det til ekspertene våre om dagen. Merk, kanskje først vil du kommentere og stille et par spørsmål. Så Dez, kan du chime inn.

Mark Madsen: Ja, takk, jeg likte å se på noe av dette. Det er en mye mer intelligent overvåking enn jeg er vant til å se. Jeg er nysgjerrig på å håndtere dataene bak dette; håndtering av beregningene du kan spore, og du vet, se etter ting som å skifte baselinjer spesielt, som å være et av mine smertepunkter for kjæledyr, med dashbord. Hvordan takler du disse dataene, og den andre delen av det, er med, du vet, grunnleggende beregninger, som en slags skift - har du muligheten til automatisk å skifte terskelene også, slik at jeg ikke trenger gå tilbake og tilbakestille terskler for hånd når en grunnlinje skifter?

Bullett Manale: Det gjør du, og det fine med det er at du kan bestemme det. Du kan gjøre det heller. Jeg kan stille en terskel og gjøre det til en statisk innstilling, eller jeg kan merke av i boksen for å si: "Gjør dette til en dynamisk terskel, som vil endre seg etter hvert som grunnlinjene mine endres." Og jeg har muligheten og verktøyet til å sette et standardvindu tid for grunnlinjen. Men hvis jeg trenger det, kan jeg ha et eget grunnleggende vindu, for eksempel fra vedlikeholdsvinduet fra kl. 02.00, la oss si til kl. 05.00; fordi jeg kommer til å skattlegge CPU, mine stasjoner og alt annet fordi det er når vi utfører alt vedlikeholdet. Det ville da automatisk, hvis jeg hadde valgt å gjøre det, det automatisk justert tersklene mine til å være utenfor der det som er normalt for de beregningene som Jeg velger å gjøre det med. Det vil tillate meg å gjøre det. I utgangspunktet har du en mulighet innen verktøyet til å stille inn tidsvinduer, det er baselinevinduene dine, og hvert vindu kan behandles som en egen enhet, i form av dynamisk baslinjustering som kan gjøres, og du kan legge til så mange vinduer i baseline som deg du trenger det, hvis det er fornuftig. Du kan ha et helgens vindu, en ukedag i arbeidstiden, et vedlikeholdsvindu som skjer midt på natten og så videre og så videre.

Mark Madsen: Takk.

Bullett Manale: Jeg antar at vi kommer tilbake til den første delen av spørsmålet, og vi samler all denne informasjonen. Jeg snakket egentlig ikke om arkitekturen, men vi har et back-end repository, at du har fullstendig kontroll over oppbevaring av disse dataene, men vi har også en tjeneste som kjører midt på natten som går og gjør alle grunnleggende beregninger, og den tar dataene, samler inn og gir mening om dem. Og selvfølgelig, sammen med det, har du også mange rapporter som vi kan bruke til å rapportere mot grunnlinjene dine, for spesifikke beregninger. Og du har til og med muligheten til å sammenligne basislinjene for den samme serveren, for den samme beregningen i forskjellige tidsperioder. Du kan se om det er forskjeller som har skjedd, eller hva deltaet er. Det er mange av disse alternativene også.

Eric Kavanagh: Dez.

Dez Blanchfield: Et raskt spørsmål jeg har til deg - det er et bredt spekter av hva dette verktøyet kan gjøre. Ser du et opptak i bruken av det i det tidlige stadiet av utviklingen nå, eller er det fremdeles først og fremst et produksjonsmiljøverktøy? Får utviklere med andre ord tilgang og bruker den gjennom sin tidlige utvikling, og deretter tester integreringsfasen? Eller brukes det fremdeles overveiende i produksjonsmiljøer?

Bullett Manale: Jeg vil si det, for de fleste gangene vi ser det i produksjonsmiljøer. Det avhenger av situasjonene, men for det meste vil jeg si først og fremst produksjon og det gjør vi - og det er også, du vet, rimelig å nevne at vi har forskjellige priser for dev- og testmiljøer, så det er litt mer attraktivt. Vi ser folk som bruker det for de miljøene, men hvis jeg måtte gi deg svar på den ene eller den andre måten, vil jeg si at det først og fremst fremdeles er produksjonsmiljøer der vi ser at folk investerer i dette produktet. .

Dez Blanchfield: Visst, ja, og det var interessant å høre at du har forskjellige prissettingspunkter, fordi det tydeligvis er forskjellige arbeidsmengder, og jo tyngre jobber det blir der alt det virkelige arbeidet blir gjort. Men jeg ser mange organisasjoner, spesielt i myndighetene, og absolutt i forsvaret, der utviklingen nå får det samme nivået av investeringer i verktøy og systemer som produksjonsmiljøer, fordi de gjør mye mer foran tester. Til forsvar er det for eksempel lag som kjører milliarder av tester, hundrevis av milliarder tester på applikasjoner og systemer og verktøy, og overvåker dem før de til og med går ut på integrasjonstesting, fordi de vil forsikre seg om at det er en kode som er bygget og databasen det sitter under den. Det kommer til hundre og en million iterasjon eller noe, mens du er ute i felten og skyter på noen, går det ikke "smell."

Bullett Manale: Sikker.

Dez Blanchfield: I databasesamlingen på gamle skoler, etter min erfaring, blir det sjelden sett, og veldig sjelden om jeg tenker at databasemiljøet er noe som bare har igjen i data og noen av dere vet, så når vi får poenget der verktøy og apper utvikles, spesielt med analytiske plattformer, de er nå i håndsettene og enhetene våre. Ser du klienter bringe samtalen om databaseprestasjoner og databestyring som en mer daglig diskusjon i motsetning til bare rent teknologier? Og jeg vet at du nevnte før, hovedsakelig at du snakker med DBA, men er det en trend nå hvor det er i det generelle ordforrådet, ser du folk der de diskuterer disse temaene, i motsetning til bare nørdene?

Bullett Manale: Det er vel vanskelig å si. Jeg mener, som jeg sa for det meste, at de menneskene vi har å gjøre med salgsprosessen uansett er med utøverne, som er DBA-er. Så når det gjelder spørsmålet ditt, sier du bare: "Når det gjelder personene innen IT-organisasjonen, blir de mer informasjonsbevisste?" Jeg antar at dette er spørsmålet, og jeg vil nok si at svaret er "ja." Jeg ser det sannsynligvis ikke så mye, basert på hvor jeg er, på en daglig basis, men jeg tror at hvis jeg forstår spørsmålet ditt, vil det være mitt svar, antar jeg.

Dez Blanchfield: Ja, det er greit. Det er sannsynligvis et lastet spørsmål, beklager, fordi åpenbart dine overveiende interesser, i din verden, er den tekniske siden av ting. Jeg er nysgjerrig på at jeg i daglige aktiviteter ser organisasjoner begynne å bringe dette inn i samtalen veldig tidlig. Så når de snakker om nye initiativer, nye prosjekter, nye arbeidsprogrammer, er en av tingene som kommer umiddelbart, "Hvordan overvåker vi det, hvordan sporer vi det, hvordan håndterer vi problemer når de oppstår, i motsetning til å lansere, gå live? "

Bullett Manale: Jeg vil si det -

Dez Blanchfield: Beklager, fortsett.

Bullett Manale: Jeg hadde til hensikt å si at jeg ser en trend jeg antar at jeg skulle si i - du vet, mange ganger tidligere ville du fått, "Vi hadde et problem, og nå trenger vi et verktøy. " Og jeg tror at vi ser litt mer på aksept rundt å ha verktøyet på plass før problemet skjer, hvis det er fornuftig. Så jeg vil si at det definitivt blir mer normalt å være, du vet, "Hei, vi trenger et overvåkingsverktøy, vi trenger noe." Og folk ser definitivt verdien av dette produktet, for som du sa tidligere, bare legger DBAer og Hvis du legger til nye tilfeller, trenger du noe som klarer det. Du trenger noe som hjelper deg med å håndtere det, og det er derfor vi ser mye aksept rundt dette produktet også, eller vi har det.

Dez Blanchfield: Rask spørsmål. Hvor trenger dette å bo? Må det sitte rett bakpå forbrenningen på LAN, i datasenteret, så nær databasemiljøene som mulig, eller er det komfortabelt plassert et sted, potensielt ute i skyen, en tredjeparts sky med en slags enten VPN-tunnel eller fjerntilgang til forskjellige miljøer? Hvor trenger det å sitte, når det gjelder miljøer og overvåking?

Bullett Manale: Når det gjelder arkitekturen, er det en bakre del, og det er en SQL Server-database. Vi har konsollen som enten kan være en feit klient, eller en tynn klient; vi gir deg muligheten til begge deler. Og vi har også en tynn klient som også virkelig er rettet mot mobile enheter. Men når det gjelder hvor dette faktisk kan sitte; det kan sitte i et miljø, egentlig er den vanskeligste delen om det, fra mye av informasjonen vi trenger å samle inn, krever administrative rettigheter, i noen tilfeller eller i mange tilfeller. Nå får vi ikke til å gjøre det; Hvis du vil, kan du samle inn data og bare for de tingene vi ikke kan samle inn, fordi vi ikke har administratorrettigheter, vil vi bare la deg ikke se den informasjonen, hvis det er valget du tar.

Avhengig av smaken, som om du snakker om AWS, fungerer noen miljøer bedre enn andre, men så langt som det faktiske miljøet, typisk enten å bruke SA-godkjenning for å samle inn dataene mot forekomstene, er alt det som er nødvendig. Eller hvis det er et ikke-betrodd domene, er det vanligvis når du vil gjøre det, men flere domener; så lenge det er tillit mellom dem, kan vi samle inn mot dem. Det spiller ingen rolle om det er på et LAN eller om det er i WAN, selve samlingen er ganske ubetydelig med tanke på datamengden vi samler inn. Hvis vi har tilstrekkelig WAN-tilkobling, er det ikke et problem. Jeg har sett miljøer der de har filialer der de har SQL-servere over hele USA. Og det er en server på hvert av disse forskjellige stedene, og de overvåker det sentralt. Den vanskelige delen er bare å sørge for at du har en anstendig mengde tilkobling for å gjøre det. Forhåpentligvis, som svarer på spørsmålet ditt, var det liksom hele kartet.

Dez Blanchfield: Det gjør det absolutt. Takk skal du ha. Så, to kjappe spørsmål som har kommet gjennom deltakere i morges; det ene er: hva er virkningen av - ofte ser vi systemovervåkingsverktøy generere belastning selv ved bare å overvåke ting, så spørsmålet var, beklager at det rullet av skjermen min nå, men bare omskriver det; ved å overvåke genererer vi belastning selv? Er det en målbar påvirkning av verktøyet, bare å se på miljøet, eller er det en ubetydelig innvirkning?

Bullett Manale: Det kommer alltid til å være en liten innvirkning fordi det må spørres om SQL Server-forekomsten for å trekke tilbake dataene. Spørsmålet som du sa er: "Er det ubetydelig eller er det viktig?" Når du peker på et eksempel, er det ubetydelig. Vi har gjort dette i, som sagt, en god stund nå. Vi har over 20 000 kunder, og jeg kan forsikre deg om at hvis det fører til betydelig ytelseseffekt, ikke ville vi være i virksomhet. Når det er sagt, lar vi også brukeren bestemme hva de vil at de vil overvåke. Så jeg tror det er en viktig ting å nevne, er at alle omgivelser er litt forskjellige.

Et eksempel er at med spørringsovervåkningskomponenten, en av tingene vi har muligheten til å gjøre, er at vi kan stille terskelen for det du anser som din normalitetsgrense. Så det kan være basert på tidspunktet for utførelsen av spørringen. Det kan være basert på CPU, I / O, men som et eksempel, la oss bare si at jeg har satt utførelsestiden min til null millisekunder. Effektivt det jeg forteller verktøyet å gjøre er å samle alle spørsmålene som kjørte siden forrige trekningsintervall, og gjøre den delen av min historiske samling også.

Når vi gjør det, skal vi samle inn hvor mange spørsmål vi kjørte på boksen siden forrige valgdag. Nå er det valgfri, og brukeren har muligheten til å gjøre det. Sier vi: "Det er det du bør gjøre?" Nei. Men vi gir deg også muligheten til å gjøre det i tilfelle du vil ha et utvalg av data som lar deg samle den informasjonen. Så generelt sett har du midler innen verktøy for å konfigurere det og stille det nøyaktig slik du vil, basert på hva du er komfortabel med. Men du har muligheten til å virkelig åpne den hvis du vil, og samle inn masse tilleggsinformasjon du kanskje ikke nødvendigvis regelmessig samle, hvis det er fornuftig.

Dez Blanchfield: Ja, absolutt. Jeg vet at vi kjører litt lenge, men det er to virkelig gode spørsmål jeg vil kaste til deg før jeg slutter. De kommer begge direkte til meg, men jeg synes det er best hvis du svarer dem. Spørsmålet var generelt, "Hva er omfanget av verktøyets rekkevidde så langt som kunnskap om eksisterende systemer?" Så kan vi bare plugge dette inn og få det automatisk til å oppdage plattformen som er der, og vite hva som er normalt for den plattformen, og umiddelbart plukke opp som Mark snakket om tidligere? Noen av grunnleggende kunnskapene om plattformene ved å sette inn, du vet, jeg vet ikke, det kan være Microsoft Dynamics. Hva er omfanget av kunnskapen om plattformen med det som er normalt og i noen av de nåværende verktøy som brukes rundt virksomheten?

Bullett Manale: Jeg vil si at når vi begynner å samle inn data på SQL-forekomsten, generelt sett, jobber vi med beste praksis til å begynne med, når det gjelder terskelverdiene våre og hvor de er innstilt på. Når det er sagt, anerkjenner vi også at alle miljøene er forskjellige, uansett hva du snakker med. Hva vi skal gjøre i utgangspunktet, samler vi bare inn dataene, og hva vi anbefaler at folk gjør, kan du prøve produktet i 14 dager lenger hvis du trenger det. Men etter omtrent to dager, vil du begynne å se basisdataene som fylles. Når den har nok prøveinformasjon å jobbe med, vil den begynne å gi deg konteksten når det gjelder grunnlinjen, hvor rekkevidden er, og alt det slags. Deretter, hvis du vil, kan du automatisk angi terskler fra den informasjonen som er samlet inn. Det krever litt innsamling og polling for å kunne begynne å bestemme hva som er normalt, slik at du kan begynne å skifte tersklene.

Men det jeg synes er verdt å merke seg også, er at når du endrer disse terskler, kan det gjøres gruppevis av forekomster. Det kan være spesifikt for en forekomst, eller du kan gjøre det mot alle forekomstene dine, så vel som muligheten til å lage ting som maler, slik at du kan si: "Dette er en produksjonsinstans, men dette er malen jeg vil ha å tildele den. " Og så når en ny produksjonsinstans kommer på nettet, bruker vi automatisk disse tersklene for den, fordi den har samme type maskinvare, og den har vanligvis de samme arbeidsmengdene, så vi kan også gjøre det på den måten. Forhåpentligvis hjelper det når det gjelder spørsmålet.

Dez Blanchfield: Det gjør det absolutt. Du har faktisk svart på et annet spørsmål som nettopp kom inn til meg, og det var: "Er det prøveversjon?" Det er, jeg kan svare på det, jeg vet. Jeg er sikker på at du vil bekrefte at det er en gratis nedlasting, og jeg tror du sa at det var 14 dager fra nettstedet. Du kan laste ned den og leke med den. Jeg antar bare raskt med det: "Hva slags miljø trenger jeg for å kunne kjøre prøveversjonen? Kan jeg kjøre den på den bærbare datamaskinen min og leke med den, eller trenger jeg virkelig en server?"

Bullett Manale: Det viktigste det er et depot, en SQL Server-database som er 2005 eller over. Annet enn det er det noen minimale ressurskrav, et .NET-krav, og det er det. Så det gjelder bare å installere produktet og opprette en database.

Dez Blanchfield: Perfekt. Et siste spørsmål som jeg vil kaste deg, fordi vi bare er ute av tid nå, men raskt, omtrent to eller tre personer spurte meg: "Må jeg være en DBA for å faktisk kunne komme i gang med dette, og ha en lek med det? ”

Bullett Manale: Nei. Jeg vil si at hvis du er en DBA, vil du ha forskjellige bruksområder av verktøyet. Jeg mener, det kommer nok til å være litt mer verdi hvis du er en erfaren DBA. Du kommer til å se mye mer dybde i verktøyet som du vil kunne dra nytte av. Men også som en ny DBA, eller til og med en person som, det er ikke en DBA, vi har mange anbefalinger, og jeg er på den siden akkurat nå. Disse anbefalingene vil komme opp med jevne mellomrom, og det som er veldig hyggelig med anbefalingene, er at de gir deg grunnene til at anbefalingene blir fremsatt. Men i tillegg til det, vil de også ha lenker til eksternt innhold som beskriver mer detaljert om årsakene til at disse anbefalingene også blir gjort. Så det vil koble til eksterne Microsoft-nettsteder, blogger og alle slags ting som det, det er eksternt.

Men for å svare på spørsmålet ditt, er det på en måte, hvis du er en senior DBA, vil det være ting her, vil du sannsynligvis dra nytte av det, som du sannsynligvis ikke ville ha som en nybegynner DBA. Men så er det på samme tid et slags læringsverktøy, for når du går gjennom disse anbefalingene, vil du begynne å plukke opp noen av disse tingene på egen hånd gjennom bruk av anbefalingene.

Dez Blanchfield: Fantastisk. Takk skal du ha. Jeg likte demodelen. Presentasjonen var flott. Demoen var fantastisk. Raskt fra minnet er det et helt ressurssenter på nettstedet ditt som jeg anbefaler at folk også ser på. Jeg husker at jeg gikk gjennom det i går for å få noen detaljer. Du har en rekke ting, bare fra blogger og data og samtaler til, fra hukommelse, og har det meste av produktdokumentasjonen din på nettet, ja?

Bullett Manale: Ja, det er riktig, og skjemaet som jeg tror at du refererer til er nettstedet community.idera.com. Og så vil jeg også nevne en ting, tidligere har du spurt om: "Vil det gjenkjenne miljøet?" Når det gjelder nye forekomster eller legge til forekomster, er det et annet verktøy som vi har som gjør oppdagelse av forekomster. Og det handler om inventar og administrering av varelageret ditt. Jeg vil bare peke deg i den retningen, med tanke på å oppdage forekomstene. Men så langt som faktisk ytelse og overvåking, alt det slags vi snakket om, det var der Diagnostic Manager kom inn i bildet.

Dez Blanchfield: Fantastisk. Se, flott dekning. Likte presentasjonen. Elsket live-demoen, og det er alt fra meg i morges, ettersom jeg vet at vi sannsynligvis har gått 10 minutter over tid. Eric, jeg kommer til å gi meg tilbake til deg.

Eric Kavanagh: OK. Jeg bare elsket demoen. Jeg er glad du gjorde demoen. Jeg er glad for at vi måtte se det hardt når vi gikk gjennom spørsmål og svar.

Bullett Manale: Flott.

Eric Kavanagh: Fordi dette gir folk en ide om hva du ser på, og det virkelig forbløffer meg for å tro at vi fremdeles lærer om hvordan du kan snakke med disse datamaskinene, når du kommer til det. Jeg mener, dette nivået av diagnostikk er ganske sofistikert, og det blir bedre for hver dag. Vi får mye mer innsikt i hva som faktisk skjer. Men du trenger virkelig en person som overser disse tingene, leser den, legger den kognitive evnen bak det du gjør, ikke sant?

Bullett Manale: Ja, jeg mener i mange tilfeller - jeg skulle ønske jeg kunne fortelle deg at dette er en DBA i boksen, men det er bare for mange ting som skjer. Jeg mener, vi gir veiledning, og vi hjelper oss, men på slutten av dagen krever det at folk tar beslutninger om dataene vi presenterer. Jeg tror ikke det kommer til å endre seg snart.

Eric Kavanagh: Det er gode nyheter for de virkelige menneskene der ute, folkens.

Bullett Manale: Det stemmer.

Eric Kavanagh: Du vil ønske at noen skal se på dette, et team som ser på dette, og du lærer, som du har hørt fra Bullett her, å se på disse anbefalingene du kommer til å hente hva som skjer. Og jeg gjetter fra den historien, og jeg tror du har berørt dette, Bullett, men veldig raskt, at historien lar deg gjenkjenne betydelige mønstre og deretter kunne identifisere dem når de skjer i fremtiden, ikke sant?

Bullett Manale: Det er riktig. En av tingene vi kan gjøre er å spore en spørres ytelse over tid. Vi kan selvsagt også se på andre ting, som baselinjer og se dem skifte, og tydeligvis få varsler og sånt når det skjer, så du har definitivt den evnen.

Eric Kavanagh: Det høres bra ut, folkens. Vi hadde ikke vært lenge her, men jeg ville komme til de spørsmålene. Tusen takk for din tid og oppmerksomhet. Vi arkiverer alle disse webcastene. Hop online til Techopedia.com eller til InsideAnalysis.com, så ser du lenker fra begge steder.

Og med det tar vi farvel. Takk igjen, folkens, vi får tak i deg neste uke, tre nettkaster til neste uke, tirsdag, onsdag, torsdag. Så vi snakker med deg neste uke, folkens. Ha det fint. Ha det.

Techopedia Content Partner

Techopedia Staff er tilknyttet Bloor Group og kan kontaktes ved å bruke alternativene til høyre. For informasjon om hvordan vi samarbeider med bransjepartnere, klikk her.

• Profil
• nettsted