Av Techopedia Staff, 19. april 2017
Takeaway: Vert Eric Kavanagh diskuterer prognoser med Dr. Robin Bloor, Rick Sherman og IDERAs Bullett Manale.
Du må registrere deg for dette arrangementet for å se videoen. Registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, Hei igjen og velkommen tilbake til Hot Technologies webcast-serie! Jeg heter Eric Kavanagh, jeg vil være vertskap for dagens webseminar, kalt “Spare tid, penger og problemer med optimale prognoser.” Kurs jeg savnet den første delen av tittelen der, “De beste planene.” Vi snakk alltid om det på dette showet. Så, Hot Technologies er selvfølgelig vårt forum for å forstå hva noen av de kule produktene er der ute i verden i dag, verden av bedrifts-teknologi, hva folk gjør med dem, hvordan de jobber, alt det slags morsomme ting.
Og emnet i dag, som jeg antyder, omhandler prognoser. Du prøver virkelig å forstå hva som skal skje i organisasjonen din. Hvordan skal du holde brukerne glade, uansett hva de gjør? Hvis de gjør analyse, hvis de gjør virkelig arbeid, står de overfor ekte kunder med transaksjonssystemer, uansett hva tilfellet måtte være, vil du forstå hvordan systemene dine kjører og hva som skjer, og det er hva vi ' Jeg snakker om i dag. Det er litt morsomt fordi prognoser ikke er noe jeg liker å gjøre, fordi jeg er overtroisk, som om jeg tror at hvis jeg spår for mye, vil dårlige ting skje, men det er bare meg. Ikke følg ledelsen min.
Så her er våre presentatører i dag, du er virkelig i øverste venstre hjørne. Rick Sherman ringer inn fra Boston, kompisen Bullett Manale fra IDERA og vår helt egen Dr. Robin Bloor. Og med det skal jeg overlevere det til Robin og bare minne folk: Still spørsmål, ikke vær sjener, vi elsker gode spørsmål, vi sender dem ut til presentatørene våre og andre i dag. Og med det, Robin, ta det bort.
Robin Bloor: OK, da jeg er i pol-posisjon som de sier, tenkte jeg at jeg skulle fortelle en SQL-historie i dag, fordi det er bakgrunnen for hva diskusjonen som kommer til å fortsette, og den vil uunngåelig ikke kollidere med fordi Rick ikke fokuserer på dette, og ikke vil kollidere med det Rick har å si. Så SQL-historien, det er noen interessante ting ved SQL fordi den er så dominerende. Se, det er en skrivefeil, SQL er et deklarativt språk. Tanken var at du kunne lage et språk der du ville be om det du ønsket. Og databasen ville finne ut hvordan du får tak i den. Og det har fungert ganske bra, faktisk, men det er en rekke ting som er slags verdt å si om det, konsekvensene av å basere hele IT-bransjen på et deklarativt språk. Brukeren kjenner ikke til eller bryr seg om den fysiske organisasjonen av dataene, og det er det som er bra med det deklarative språket - det skiller deg ut fra alt dette, og til og med bekymrer deg for det - bare spør om hva du vil, og databasen vil gå og få det.
Men brukeren har ingen anelse om måten de strukturerer SQL-spørringen på vil påvirke resultatene til spørringen, og det er litt av en ulempe. Jeg har sett spørsmål som er hundrevis og hundrevis av linjer lange, som bare er en SQL-forespørsel, du vet, begynner med "select" og bare fortsetter og fortsetter med sub-queries og så videre og så videre. Og det viser seg faktisk at hvis du vil ha en bestemt innsamling av data ut av en database, kan du be om det på mange forskjellige måter med SQL, og få det samme svaret hvis du slags har litt fortrolighet med dataene. Så ett SQL-spørsmål er ikke nødvendigvis den beste måten å be om data, og databaser vil svare ganske annerledes i henhold til SQL som du legger i dem.
Og slik påvirker SQL faktisk ytelsen, så folk som bruker SQL, det er sant for dem, det er også sant for SQL-programmerere som bruker SQL, og det er enda mindre sannsynlig at de tenker på virkningen de vil ha, fordi mesteparten av deres fokus er faktisk på manipulering av data og ikke på innhenting, innhenting av data. Og det samme gjelder også BI-verktøy. Jeg har sett SQL som, hvis du vil, klemmer ut av BI-verktøy i forskjellige databaser, og det må sies at mye av det er, vel, jeg ville ikke t skrive SQL-spørsmål sånn. Det er noen som har skapt, hvis du vil, en liten motor som uansett parametrene vil kaste ut litt SQL, og igjen, at SQL ikke nødvendigvis vil være effektiv SQL.
Da tenkte jeg at jeg skulle nevne impedansmatchet, dataene som programmerere bruker er annerledes enn dataene slik de sorteres. Så, våre DMS lagrer data i tabeller, organisert den objektorienterte koden er for det meste kodere, programmerer objektorientert form nå for tiden, og de bestiller data i objektstrukturer, så den kartlegger ikke den ene til den andre. Så det er en nødvendighet å oversette fra hva programmereren mener at dataene er til det databasen mener hva dataene er. Det virker som om vi må ha gjort noe galt for at det skulle være tilfelle. SQL har DDL for definisjon av data, den har DML - datamanipuleringsspråk - velg, prosjekt og bli med, for å få disse dataene. Nå er det veldig lite matematikk og veldig lite tidsbaserte ting, så det er det ufullkomne språket, selv om det må sies at det har blitt utvidet og fortsetter å bli utvidet.
Og så får du SQL-barriereproblemet, som alltid er rettere enn diagrammet, ved at mange mennesker spurte spørsmål av analytiske grunner, når de først har fått svaret på spørsmålene om vilkårene, vil du stille et annet spørsmål. Så det blir en dialog ting, vel, SQL var ikke bygget for dialoger, den ble bygget for å spørre hva du vil ha på en gang. Og det er liksom verdt å vite det, fordi det er noen produkter der ute som faktisk forlater SQL for å gjøre samtalen mulig mellom brukeren og dataene.
Når det gjelder databaseytelse - og denne typen sprer seg til alt - ja, det er CPU, det er minne, det er disk, det er nettverkskostnader, og det er låseproblemet til mer enn én person som ønsker å ha eksklusiv bruk av dataene på en gitt tidspunkt. Men det er også dårlige SQL-samtaler, det er utrolig som kan gjøres hvis du faktisk optimaliserer SQL, med tanke på ytelse. Altså, databaseprestasjonsfaktorer: dårlig design, dårlig programdesign, samtidig manglende arbeidsmengde, belastningsbalansering, spørringsstruktur, kapasitetsplanlegging. Det er datavekst. Og med noen få ord er SQL praktisk, men den optimaliserer ikke selv.
Når det er sagt, tror jeg at vi kan gi videre til Rick.
Eric Kavanagh: OK, Rick, la meg gi deg nøklene til WebEx-bilen. Ta den bort.
Rick Sherman: OK, flott. Vel takk Robin, da vi startet i begynnelsen av presentasjonen, er grafikken min fremdeles ganske kjedelig, men vi får fortsette med det. Så jeg er enig i alt Robin snakket om på SQL-siden. Men det jeg vil konsentrere meg litt om nå er etterspørselen etter data, som vi vil gjennomgå veldig raskt, tilbudet som i verktøy som brukes på det rommet eller behovet for verktøyene i det rommet.
For det første er det noen i hver artikkel som du leser å gjøre med big data, mye data, ustrukturerte data fra skyen, big data overalt som du kan forestille deg. Men veksten i databasemarkedet har kontinuerlig vært med SQL, relasjonsdatabase sannsynligvis fra 2015, er fremdeles 95 prosent av databasemarkedet. De tre beste relasjonsleverandørene har omtrent 88 prosent av markedsandelen på den plassen. Så vi snakker fremdeles, som Robin snakket, om SQL. Og faktisk, selv om vi ser på Hadoop-plattformen, er Hive og Spark SQL - som min sønn, som er en dataforsker, bruker hele tiden nå - absolutt den dominerende måten for folk å komme til data på.
Nå, på databasesiden, er det to brede kategorier av bruk av databaser. Den ene er for operative databasestyringssystemer, så forretningsforholdsplanlegging, kundeforhold bemanning, Salesforce ERPs, Oracle, EPICs, N4s, etc., i verden. Og det er et bredt og utvidende mengde data som er i datavarehus og andre forretningsintelligensbaserte systemer. Forårsaker alt, uavhengig av hvor og hvordan det blir fanget, lagret eller gjennomført, blir det til slutt analysert, og det er derfor en stor etterspørsel og økning i bruken av databaser, spesielt relasjonsdatabaser ute på markedet.
Nå har vi etterspørsel, vi har enorme mengder data som kommer. Og jeg snakker egentlig ikke bare om big data, jeg snakker om bruk av data på tvers av alle slags selskaper. Men med det fra tilbudssiden, for folk som kan administrere disse ressursene, har vi først av, vi har en slags mangel på DBA. Vi har ifølge Bureau of Labor Statistics, fra 2014–2024 vil DBA-jobbene bare vokse med 11 prosent - nå er det folk som har DBA-jobbtitler, men vi skal snakke om det om et sekund - kontra 40- pluss prosent årlig datavekstplass. Og vi har mange DBA-er; i gjennomsnitt at den samme studien snakket om gjennomsnittsalderen er ganske høy sammenlignet med andre IT-yrker. Og så har vi mange mennesker som forlater feltet, ikke nødvendigvis går av med pensjon, men skifter til andre aspekter, går i ledelse, eller hva som helst.
Nå, en del av grunnen til at de forlater, er fordi DBA-jobben blir stadig hardere. For det første har vi DBA-er som administrerer mange forskjellige databaser selv, fysiske databaser, som er plassert over alt, så vel som forskjellige typer databaser. Nå kan det være relasjonelt, eller de kan være en annen database, databasetyper også. Men selv om det er relasjonelt, kan de ha noen av en, to, tre, fire forskjellige leverandører som de faktisk prøver å administrere. DBA-er blir vanligvis involvert etter utformingen av databasen eller applikasjonen. Robin snakket om hvordan databaser eller applikasjoner blir designet, og hvordan SQL blir designet. Vel, når vi snakker om datamodellering, ER-modellering, utvidet ER-modellering, dimensjonsmodellering, avansert dimensjonell modellering, hva som helst, typisk applikasjonsprogrammerere og applikasjonsutviklere som design med det endelige målet for øye - de designer ikke for effektiviteten til selve databasestrukturen. Så vi har mye dårlig design.
Nå snakker jeg ikke om leverandører av kommersielle applikasjoner; de har vanligvis ER-modeller eller utvidede ER-modeller. Det jeg snakker om er at det er mye mer forretningsprosesser og applikasjoner som bygges av applikasjonsutviklere i hvert selskap - det er de som ikke nødvendigvis er designet for effektivitet eller effektivitet for distribusjon. Og DBAene selv er overarbeidet, og de har 24/7 ansvar noen ganger, de får stadig flere databaser. Jeg tror det har gjort litt med at folk ikke helt forstår hva de gjør, eller hvordan de gjør det. Deres egen lille gruppe og folk tenker bare på, “Vel, alle disse verktøyene er bare så enkle å bruke, vi kan bare fortsette å kaste på flere og flere databaser på arbeidsmengden deres, ” som ikke er tilfelle.
Noe som fører oss til DBA på deltid og tilfeldigvis. Vi har IT-team som er små, og de har ikke nødvendigvis råd til en dedikert DBA. Det stemmer nå for små til mellomstore bedrifter, der utvidelsen av database- og databaseapplikasjoner har eksplodert det siste tiåret og fortsetter å utvide. Men det er også tilfelle for store selskaper, som typisk har holdt på med datavarehus, analyser av forretningsintelligens i lang, lang tid. For lenge siden brukte vi å få dedikerte DBA-er for disse prosjektene; vi får aldri en dedikert DBA lenger. Vi er ansvarlige for å designe databasen, noe som er bra, hvis det er noen som har erfaring. Men generelt er DBA-er applikasjonsutviklere, de tar ofte den rollen som en deltid i jobben sin, de har ikke formell opplæring i det og igjen, de designer det for sluttmålene deres, de er ikke utforme den for effektivitet.
Og det er mye forskjell mellom design og utvikling, kontra distribusjon og styring. Så vi har det "penny kloke, pund tåpelige", med en liten sparegris der, og hopper over å få ferdighetene og ressursene som trengs i prosjektene. Tenker at alle er fra "Revenge of the Nerds", mitt lille bilde der. Nå, så langt som hva folk trenger, så har vi en utvidet bruk av databaser og data i SQL. Vi har begrensende antall DBA-er - personer som er dyktige og eksperter på disse tuning og design og styring og distribusjonssituasjoner. Og vi har mer og mer deltids- eller tilfeldige DBA-er, folk som ikke har hatt den formelle treningen.
Så, hva er noen av de andre tingene som også kommer inn i problemet med at disse databasene ikke blir innstilt så bra, eller administrert også? For det første antar mange at databasesystemet selv har tilstrekkelige verktøy for å kunne administrere seg selv. Nå blir verktøyene enklere og enklere å gjøre - design og utvikling - men det er annerledes enn å gjøre en god design, og god styring, kapasitetsplanlegging, overvåking, etc. for distribusjon. Så for det første antar folk at de har alle verktøyene de trenger. For det andre: Hvis du er en DBA på deltid eller utilsiktet, vet du ikke hva du ikke vet.
Jeg har nok glemt noe av uttrykket der, slik at de mange ganger ikke forstår hva de selv trenger å se på i designen eller når de administrerer eller drifter databasene. Hvis det ikke er ditt yrke, vil du ikke forstå hva du trenger å gjøre. Tredje, er at SQL er et go-to-verktøy, så Robin snakket om SQL, og hvor dårlig SQL noen ganger er konstruert, eller ofte er konstruert. Og også en av kjæledyrene mine i BI-datavarehus, dataoverføring, datateknisk plass er at folk i stedet for å bruke verktøy har en tendens til å skrive SQL-kode, lagrede prosedyrer, selv om de bruker et dyrt dataintegrasjonsverktøy eller et dyrt BI-verktøy, bruker de det virkelig bare for å kjøre lagrede prosedyrer. Slik at viktigheten av å forstå databasedesign, for bygging av SQL, blir enda mer og mer viktig.
Og til slutt er det denne silotilnærmingen, der vi har enkeltpersoner som ser på individuelle databaser. De ser ikke på hvordan applikasjonene fungerer og samhandler med hverandre. Og de ser også ofte på databasene kontra applikasjonene de bruker dem til. Så arbeidsmengden du får i databasen er kritisk i utformingen, kritisk for å stille den inn, kritisk for å prøve å finne ut hvordan du skal planlegge for kapasitet, osv. Så når man ser på skogen fra trærne, er folk i ugresset, ser på de individuelle tabellene og databasene og ikke ser på det samlede samspillet mellom disse applikasjonene i arbeidsmengden.
Endelig må folk se på de sentrale områdene de trenger å se på. Når de planlegger å administrere databaser, må de først tenke på, utvikle noen applikasjonssentriske ytelsesmålinger, så de må se på ikke bare hvordan denne tabellen er strukturert, hvordan den er spesielt modellert, men hvordan brukes den? Så hvis du har bedriftsapplikasjoner som skyldes ledelse av forsyningskjeder, hvis du tar bestillinger fra nettet, hvis du gjør BI - hva du enn gjør - må du se på hvem som bruker det, hvordan de er bruker den, hva datamengdene er, når det kommer til å skje. Det du virkelig prøver å se etter er ventetidene, for uansett hva, alle applikasjoner blir bedømt etter hvor lang tid det tar å få gjort noe, enten det er en person eller bare utveksling av data mellom applikasjoner eller prosessorer. Og hva er flaskehalsene? Så ofte når du prøver å feilsøke problemer, prøver du selvfølgelig virkelig å se på hva som er de virkelige flaskehalsene - ikke nødvendigvis hvordan du kan stille inn alt, men hvordan blir du kvitt og flytter ytelsen opp i ventetidene og gjennomstrømning - hva du trenger å se på.
Og du må virkelig skille ut datafangst, transaksjoner, transformasjonsaspekter i databasen sammen med analysene. Hver av dem har forskjellige designmønstre, hver av dem har forskjellige bruksmønstre, og hver av dem må være innstilt på en annen måte. Så du må tenke på hvordan disse dataene brukes, når de brukes, hva de brukes til, og finne ut hva resultatmålingene er og hva er de viktigste tingene du ønsker å analysere relatert til den bruken. Når du nå ser på å overvåke ytelsen, vil du se på selve databasens operasjoner; du vil se på både datastrukturer, så indeksene, partisjoneringen og andre fysiske aspekter av databasen, til og med strukturen i databasen - enten det er ER-modell eller dimensjonsmodell, men det er strukturert - alle disse tingene har innvirkning på ytelsen, spesielt i de forskjellige sammenhengene med datafangstanalyse og transformasjonene som skjer.
Og som Robin nevnte på SQL-siden, og ser på SQL som blir kjørt av disse forskjellige applikasjonene på tvers av disse databasene, og innstiller den er avgjørende. Og ser på de samlede applikasjonsmengdene og infrastrukturmiljøet som disse databasene og applikasjonene kjører på. Så at nettverkene, serverne, skyen - uansett hva de kjører på - også ser på virkningen disse applikasjonene og disse databasene har i den sammenhengen, har alle disse samspillene om å kunne stille inn databasen.
Og til slutt, når du ser på verktøy, vil du kunne se på de tre forskjellige typer analyser relatert til det. Du vil se på beskrivende analyse: hva som skjer og hvor, relatert til databasen og applikasjonsytelsen. Du vil ha muligheten til å gjøre diagnostiske analyser for å finne ut ikke bare hva som skjer, men hvorfor skjer det, hvor er flaskehalsene, hvor er problemene, hva kjører bra, hva kjører ikke bra? Men å kunne analysere og bore ned i problemområdene for å adressere disse, enten for design eller hva du måtte gjøre.
Og til slutt, den mest aggressive eller proaktive typen analyser er å faktisk gjøre noen prediktive analyser, prediktive analysemodellering, uansett. Vi vet at databasen og applikasjonene fungerer i denne sammenhengen, hvis vi økte kapasiteten, hvis vi får flere brukere, hvis vi gjør mer gjennomstrømming, hva vi enn gjør, å kunne projisere ut hva, hvordan og hvor det skal påvirke databasen, applikasjonene, gjør at vi kan planlegge og finne ut proaktivt, hvor flaskehalsene er, hvor ventetidene kan lide og hva vi trenger å gjøre for å fikse ting. Så vi ønsker å ha verktøy som er i stand til å implementere resultatmålingene, overvåke ytelsen, som i disse tre analysene. Og det er oversikten min.
Eric Kavanagh: OK, la meg overlate det til - det er for øvrig to gode presentasjoner - la meg overlevere dette til Bullett Manale for å ta det derfra. Og folkens, ikke glem å stille gode spørsmål; vi har noe godt innhold allerede. Ta den bort, Bullett.
Bullett Manale: Høres bra ut. Takk, Eric. Så mye av det Rick sa og Robin sa, jeg er tydeligvis enig med 100 prosent. Jeg vil si at jeg trakk dette lysbildet, fordi jeg synes det passer, jeg vet ikke for dere som er "A-Team" fans på 80-tallet, John Hannibal Smith sa at han alltid ville si: "Jeg elsker det når en plan kommer sammen, " og jeg tror at når du snakker om spesielt SQL Server, som det er der vi fokuserer, som er produktet vi skal snakke om i dag, SQL Diagnostic Manager, det er definitivt en av de tingene du må ha; du må kunne utnytte dataene du har, og kunne ta avgjørelser ut fra disse dataene, og i noen tilfeller er du ikke ute etter en beslutning; du leter etter noe som kan fortelle deg når noe skal gå tom for ressurser, når du skal gå tom for ressurser, når du skal ha en flaskehals, slike ting.
Det handler ikke bare om å overvåke en spesifikk beregning. Så med Diagnostic Manager er en av tingene det gjør veldig bra å hjelpe deg med tanke på prognoser og forståelse spesifikk for arbeidsmengdene, og vi kommer til å snakke om mye av det i dag. Verktøyet er laget for datasjefen, DBA eller den fungerende DBA, så mange av tingene som Rick nevnte om, den fungerende DBA er så sant. I mange tilfeller, hvis du ikke er en DBA, vil det være mange spørsmålstegn som du kommer til å ha når det er på tide å styre et SQL-miljø, ting du ikke vet. Og så leter du etter noe som kan hjelpe deg, ta deg gjennom den prosessen og også utdanne deg i prosessen. Og så er det viktig at verktøyet du bruker til den slags beslutninger skal gi deg innsikt i årsakene til at disse beslutningene blir tatt, det er ikke bare å si deg: "Hei, gjør dette."
Fordi jeg er den fungerende DBA, kan jeg til slutt være den fullverdige DBA med den faktiske ekspertisen og kunnskapen for å støtte den tittelen. Når det er sagt, når vi snakker om å være databaseadministrator - viser jeg alltid denne lysbilden først, fordi DBA har noen forskjellige roller, og avhengig av hvilken organisasjon du er hos, vil du ha, disse kommer til å variere fra sted til sted - men typisk vil du alltid være ansvarlig for lagring, planlegging av lagring og forståelse av å forutse, jeg må si, hvor mye plass du skal å trenge, enten det er for sikkerhetskopiene dine, eller om det er for databasene selv. Du trenger å forstå og vurdere det.
I tillegg trenger du å kunne forstå og optimalisere ting etter behov, og når du går gjennom overvåking av miljøet, er det åpenbart viktig at du gjør endringer når de trengs, basert på ting som endring i selve miljøet. Så ting som antall brukere, ting som populariteten til applikasjoner, sesongmessigheten til en database, bør alt tas i betraktning når du gjør prognoser. Og så, selvfølgelig å se på andre ting når det gjelder å kunne gi rapportene og informasjonen som er nødvendig når det gjelder å ta disse beslutningene. I mange tilfeller betyr det å gjøre sammenlignende analyser; det betyr å kunne se spesifikt på en bestemt beregning og forstå hva verdien av denne beregningen har vært over tid, slik at du kan forutse hvor den vil komme videre.
Så mye av verktøyet Diagnostic Manager gjør, har disse mulighetene, og folk bruker det hver dag for å kunne gjøre ting som prognoser, og jeg har lagt definisjonen her på kapasitetsplanlegging. Og det er en ganske bred og faktisk ganske vag definisjon, som bare er prosessen med å bestemme produksjonskapasiteten som en organisasjon trenger for å møte de endrede kravene til produktene sine, og på slutten av dagen er det virkelig det det handler om: om å kunne ta informasjon som du har på en eller annen måte, og ta den informasjonen og ta beslutninger for å hjelpe deg med å komme deg videre når du går gjennom livssyklusen til databasene dine. Og så, de typene ting som er årsakene til at folk trenger å gjøre dette, er åpenbart først og fremst, i de fleste tilfeller, for å spare penger. Foretak, det er tydeligvis deres viktigste mål er å tjene penger og spare penger. Men i prosessen sammen med det, betyr det også å være i stand til å sørge for at driftsstansen din ikke er noen driftsstans. Og å være i stand til å sørge for at du avbøter enhver sjanse for at nedetid oppstår, så forhindrer det fra å begynne med, med andre ord, ikke vente på at det skal skje og deretter reagere på det.
I tillegg til å kunne øke produktiviteten til brukerne dine totalt sett, og gjøre dem mer effektive slik at du kan få mer virksomhet, er det åpenbart nøkkelen her, så dette er de typene ting som DBA eller noen som er involvert i prognoser eller kapasitet planlegging vil måtte være i stand til å vade gjennom informasjonen for å kunne ta disse beslutningene. Og samlet sett vil dette tydeligvis hjelpe deg med å eliminere avfall, ikke bare avfall i form av penger, men også når det gjelder tid og når det gjelder generelt ressurser som kan brukes til andre ting, muligens. Så å kunne eliminere avfallet slik at du ikke har mulighetskostnader som er bundet til selve avfallet.
Så, med det sagt, hva er de spørsmålene vi får, spesifikke for personen som er en DBA? Når skal jeg gå tom for plass? Det er stort, ikke bare hvor mye plass jeg bruker nå, men når skal jeg gå tom, basert på trender og fortidens historie? Det samme med de faktiske forekomstene av SQL, databasene, hvilke servere kan jeg konsolidere? Jeg skal legge noen på VMene, hva er fornuftig med tanke på hvilke databaser jeg skal konsolidere og hvilke forekomster av SQL skal de ligge på? Alle disse spørsmålene må være i stand til å bli besvart. For i de fleste tilfeller, hvis du er en DBA eller handler DBA, kommer du til å befeste det en gang i karrieren. I mange tilfeller skal du gjøre det fortløpende. Så du må være i stand til å ta disse beslutningene raskt, ikke spille gjettespill når det kommer til det.
Vi snakket om flaskehalser og hvor de skal oppstå neste gang, og kunne forutse det, nok en gang, i stedet for å vente på at de skulle skje. Så selvfølgelig, alle disse tingene vi snakker om, er fornuftige i den forstand at du er avhengig av historiske data, i de fleste tilfeller, for å kunne generere disse anbefalingene, eller i noen tilfeller være i stand til å formulere beslutninger selv, for å kunne komme med disse svarene. Men det minner meg om at når du hører radioannonsene for noen som selger verdipapirer eller noe sånt, så er det alltid “tidligere resultater er ikke et tegn på fremtidige resultater” og den slags ting. Og det samme gjelder her. Du kommer til å ha situasjoner der disse prognosene og disse analysene kanskje ikke stemmer 100 prosent. Men hvis du har å gjøre med ting som har skjedd i det siste og det kjente, og å kunne ta og gjøre "hva om" med mange av disse spørsmålene, du kommer til å løpe på, er veldig verdifullt og det kommer til å komme deg mye lenger enn å spille gjette-spillet.
Så disse spørsmålene kommer tydeligvis til å komme opp, så hvordan vi håndterer mange av disse spørsmålene med Diagnostic Manager, først har vi prognosefunksjoner, og kan gjøre dette i databasen, ved bordet også som stasjon eller volum. For ikke bare å kunne si “Hei, vi er full av plass”, men seks måneder fra nå, to år fra nå, fem år fra nå, hvis jeg budsjetterer for det, hvor mye stasjonsplass skal jeg å trenge å budsjettere med? Dette er spørsmål jeg blir nødt til å stille, og jeg vil trenge å kunne bruke en eller annen metode for å gjøre det i stedet for å gjette og sette fingeren opp i luften og vente på å se hvilken vei vinden blåser, Dette er mange ganger, dessverre, slik mange av disse beslutningene tas.
I tillegg til det å kunne - ser ut som om lysbildet mitt ble avskåret der litt - men å kunne gi litt hjelp i form av anbefalinger. Så det er en ting å kunne vise deg et instrumentpanel fullt av beregninger og kunne si: "OK, her er alle beregningene og hvor de er på, " men så for å kunne gjøre noen eller ha forståelse for hva du skal gjøre, basert på det er nok et sprang. Og i noen tilfeller er folk utdannet nok i rollen som DBA til å kunne ta disse beslutningene. Og så har vi noen mekanismer i verktøyet som vil hjelpe med det, som vi viser deg på bare et sekund. Men å kunne vise ikke bare hva anbefalingen er, men også gi en viss innsikt i hvorfor den anbefalingen blir gjort, og deretter også på toppen av det, i noen tilfeller, å faktisk kunne komme med et skript som automatiserer utbedring av det problemet er også ideelt.
Fortsetter vi til den neste her, som vi vil se, det er bare generelt sett å forstå ned til metrisk nivå hva som er normalt. Jeg kan ikke fortelle deg hva som ikke er normalt hvis jeg ikke vet hva normalt er. Og slik at du har en måte å måle det som er sentralt, og du må kunne ta hensyn til flere typer områder, for eksempel - eller jeg må si tidsrammer - forskjellige grupperinger av servere, kunne gjøre dette dynamisk, fra et varslende perspektiv, med andre ord, midt på natten, i løpet av vedlikeholdsvinduet, forventer jeg at prosessoren min kjører på 80 prosent basert på alt vedlikeholdet som foregår. Så kanskje jeg ønsker å øke terskelverdiene mine høyere, i løpet av disse tidsrammer kontra kanskje på midten av dagen, når jeg ikke har så mye aktivitet.
Det er noen ting som åpenbart vil være miljømessige, men ting du kan bruke på det som blir administrert, for å kunne hjelpe deg med å administrere dette miljøet mer effektivt og gjøre det lettere å gjøre det. Det andre området er selvsagt i stand til å gi rapporter og informasjon samlet for å kunne svare på disse spørsmålene "hva om". Hvis jeg nettopp har gjort en endring i miljøet mitt, vil jeg forstå hva den innvirkningen har vært, slik at jeg kan bruke den samme endringen på andre forekomster eller andre databaser i miljøet mitt. Jeg vil kunne ha noe informasjon eller ammunisjon for å kunne gjøre den endringen med litt trygghet og vite at det kommer til å bli en god forandring. Så å kunne gjøre den sammenlignende rapporteringen, kunne rangere forekomstene mine av SQL, kunne rangere databasene mine mot hverandre, for å si, "Hvilken er den høyeste forbrukeren av CPU?" Eller hvilken som tar den lengste i vilkår for venting og sånt? Så mye av den informasjonen kommer til å være tilgjengelig med verktøyet også.
Og så, sist, men ikke minst, er bare en generell evne til at du trenger et verktøy som vil kunne håndtere uansett situasjon som kommer din vei, og så det jeg mener med det er, hvis du har et stort miljø med I mange tilfeller vil du sannsynligvis komme i situasjoner der du trenger å trekke beregninger som tradisjonelt ikke er beregninger som en DBA selv ønsker å overvåke i noen tilfeller, avhengig av den aktuelle situasjonen. Så å ha et verktøy som du kan, det er utvidbart, for å kunne legge til flere beregninger og for å kunne bruke disse beregningene på samme måte og på samme måte som du ville brukt dem hvis du bruker en out-of-the-box beregning, for eksempel. Så å kunne kjøre rapporter, kunne varsle, baseline - alle tingene vi snakker om - er også en sentral del av å kunne gjøre denne prognosen og lage den slik at du får svarene du leter etter kunne ta disse beslutningene og komme videre.
Nå slik Diagnostic Manager gjør dette, har vi en sentralisert tjeneste, en gruppe tjenester som kjører, samler inn data fra 2000 til 2016-forekomster. Og det vi gjør er at vi tar dataene og legger dem inn i et sentralt lager, og det vi gjør med disse dataene, selvfølgelig, er at vi gjør mye for å kunne gi ytterligere innsikt. Nå, i tillegg til det - og en av tingene som ikke er her - har vi også en tjeneste som kjører midt på natten, som er vår prediktive analysetjeneste, og som gjør noe tallknusing og det hjelper å forstå og hjelpe deg som DBA eller fungerende DBA, for å kunne komme med disse typene anbefalinger, også kunne gi deg innsikt i forhold til baselinjer.
Så hva jeg vil gjøre, og dette er bare et raskt eksempel på arkitekturen. Det store takeaway her er at det ikke er noen agenter eller tjenester som faktisk sitter i de tilfeller du administrerer. Men det jeg ønsker å gjøre er å bare ta deg inn i applikasjonen her og gi deg en rask demo. Og la meg bare gå ut og få det til. Så la meg få vite det, tror jeg Eric, kan du se det OK?
Eric Kavanagh: Jeg har det nå, ja.
Bullett Manale: OK, så jeg kommer til å ta deg gjennom noen av disse forskjellige delene som jeg snakket om. Og la oss i utgangspunktet begynne med den type ting som er mer på linje med her, er noe du trenger å gjøre, eller her er noe som er et tidspunkt i fremtiden, og vi kommer til å gi deg litt innsikt rundt det. Og dette er i stand til å virkelig forutse - eller jeg burde si dynamisk forutse - ting mens de skjer. Når det gjelder rapporter, er en av tingene vi har i verktøyet tre forskjellige prognoserapporter. Og i tilfelle av en databaseprognose, hva jeg sannsynligvis ville gjort i situasjonen med å kunne forutse størrelsen på en database over en periode, og jeg vil bare gi deg et par eksempler på det . Så jeg skal ta revisjonsdatabasen min, som er ganske I / O-intensiv - det er mye data som kommer til den. Vi har, la oss se, vi gjør dette her, og la oss bare velge helsedatabasen her oppe.
Men poenget er at jeg ikke bare ser hva plassen er på dette, jeg kan si: "Se, la oss ta data fra fjoråret" - og jeg kommer til å fibre litt her, Jeg har ikke egentlig ett års data, jeg har omtrent to måneders data - men fordi jeg velger en utvalgshastighet på måneder her, vil jeg kunne forutse eller spå ut i dette tilfelle de neste 36 enhetene fordi utvalgsraten vår er satt til måneder - det vil si en enhet, er en måned - og da ville jeg være i stand til, for deretter å kjøre en rapport for i utgangspunktet å vise meg hvor vi ville forutse vår fremtidige vekst, for disse tre databaser. Og vi kan se at vi har en ulik grad av forskjell, eller varians, mellom de tre forskjellige databasene, spesielt i forhold til datamengden de konsumerer historisk.
Vi kan se datapunktene her representere de historiske dataene, og deretter vil linjen gi oss prognosen, sammen med tallene som skal sikkerhetskopieres. Så vi kan gjøre det på bordnivå, vi kan gjøre det selv på stasjonsnivået, hvor jeg kan forutse hvor store stasjonene mine kommer til å bli, inkludert monteringspunkter. Vi vil være i stand til å forutsi den samme typen informasjon ut, men igjen, avhengig av utvalgsfrekvensen, vil jeg tillate å bestemme hvor mange enheter og hvor vi tar det vi vil spå. Legg merke til at vi har forskjellige typer prognosetype. Så du får mange alternativer og fleksibilitet når det er tid for å gjøre prognoser. Nå, det er en ting vi skal gjøre, ved å faktisk gi deg en spesifikk dato og kunne si "Hei på denne datoen, det er her vi forventer at veksten av dataene dine skal bli." I tillegg til det kan vi imidlertid gi deg annen innsikt som er relatert til noe av analysen som vi utfører i løpet av fritiden og tjenesten når den kjøres. Noen av tingene det gjør, er det å prøve å forutse de tingene som sannsynligvis vil skje, basert på historien til når ting skjedde i fortiden.
Så vi kan se her, faktisk, en prognose gir oss litt innsikt i sannsynligheten for at vi får problemer utover kvelden basert på ting som nok en gang har skjedd i fortiden. Så tydeligvis er dette flott, spesielt hvis jeg ikke er en DBA, kan jeg se på disse tingene, men hva som er enda bedre hvis jeg ikke er en DBA, er denne analysefanen. Så før dette var her i verktøyet, ville vi gå gjennom og vise produktet til folk, og de ville være “Det er flott, jeg ser alle disse tallene, jeg ser alt, men jeg vet ikke hva jeg skal gjøre” (ler) “Som et resultat av det.” Og det vi har her, er en bedre måte for deg å være i stand til å forstå, hvis jeg skal iverksette tiltak for å hjelpe til med ytelse, hvis jeg skal iverksette tiltak til hjelpe med helsen til miljøet mitt, å kunne ha en rangert måte å gi disse anbefalingene, så vel som nyttige tips i informasjon for å lære mer om disse anbefalingene og faktisk ha til og med eksterne lenker til noen av disse dataene, som vil vise meg og ta meg til grunnene til at disse anbefalingene blir gitt.
Og i mange tilfeller å kunne tilby et skript som automatiserer, som sagt, utbedringen av disse problemene. Nå, en del av det vi gjør her med denne analysen - og jeg vil vise deg når jeg går inn for å konfigurere egenskapene til denne forekomsten, og jeg går til analysekonfigurasjonsdelen - vi har mange forskjellige kategorier som er listet her, og en del av det har vi indeksoptimalisering og spørreoptimalisering. Så vi evaluerer ikke bare beregningene i seg selv og slike ting, men også ting som arbeidsmengden og indeksene. I tilfelle her, vil vi faktisk gjøre noen ytterligere hypotetiske indeksanalyser. Så det er en av de situasjonene der jeg ikke vil, i mange tilfeller vil jeg ikke legge til en indeks hvis jeg ikke trenger det. Men på et eller annet tidspunkt er det et slags tippepunkt, der jeg sier: “Vel, tabellen begynner å bli størrelsen eller hvilke typer spørsmål som kjøres i arbeidsmengden, er det fornuftig å legge til en indeks. Men det hadde ikke vært fornuftig kanskje seks uker før. ”Så dette lar deg dynamisk få den innsikten om ting som, som sagt, vil forbedre ytelsen basert på hva som skjer i miljøet, hva som skjer i arbeidsmengdene., og gjør den slags ting.
Og slik at du får mye god informasjon her, samt muligheten til å optimalisere disse tingene automatisk. Så det er et annet område der vi ville være i stand til å hjelpe, med tanke på det vi kaller prediktiv analyse. Nå, i tillegg til det, vil jeg si, har vi også andre områder som jeg tror generelt bare gir deg råd til å hjelpe deg med å ta beslutninger. Og når vi snakker om å ta beslutninger, igjen, å kunne se på historiske data, gi litt innsikt for å få oss dit vi trenger å være for å forbedre den ytelsen.
Noe av det vi kan gjøre er at vi har en basislinjevisualisator som lar oss selektivt velge hvilken metrisk vi ønsker - og la meg finne en anstendig her - jeg skal bruke SQL CPU-bruk, men poenget er at du kan gå tilbake over mange uker for å male disse bildene slik at du kan se når utmerkerne er, for å se generelt hvor verdien faller innenfor de tidsperioder vi har samlet inn data. Og i tillegg til at du også vil merke at når vi går ut til selve forekomsten, har vi muligheten til å konfigurere grunnlinjene våre. Og baselinjene er en veldig viktig del om å kunne automatisere ting, samt å kunne varsles om ting. Og utfordringen, som de fleste DBA-er vil si deg, er at miljøet ditt ikke alltid kjører det samme, i løpet av dagen, kontra kvelden og hva som vi nevnte tidligere i eksemplet med vedlikeholdsperioder, når vi ha høye nivåer av CPU eller hva som måtte hende.
Så i tilfelle her, med disse faktiske baselinjene, kan vi ha flere baselinjer, så jeg kan ha en grunnlinje for eksempel, det er i løpet av vedlikeholdstiden min. Men jeg kunne like enkelt lage en baseline for produksjonstimene mine. Og poenget med å gjøre det er når vi går inn i en forekomst av SQL og vi faktisk har disse flere baselinjene, da ville vi være i stand til å forutse og være i stand til å utføre en type automatisering, en slags sanering eller bare varsle generelt, annerledes spesifikke for tidens vinduer. Så, en av tingene du ser her, er at disse grunnlinjene som vi genererer bruker de historiske dataene for å gi den analysen, men enda viktigere er at jeg kan endre disse tersklene statisk, men jeg kan også automatisere disse dynamisk også. Så når vedlikeholdsvinduet, eller jeg må si at vedlikeholdsgrunnlagsvinduet kommer opp, vil disse terskelverdiene automatisk skifte spesifikke til belastningene jeg opplever i løpet av det tidsvinduet, kontra kanskje midt på dagen når belastningene mine er ikke så mye når arbeidsmengdene ikke er så utslagsgivende.
Så det er noe annet å huske på, med tanke på baseline. Det er klart at dette kommer til å være veldig nyttig for deg, når det gjelder å forstå det som er normalt og også kunne forstå, engasjere seg når du også vil gå tom for ressurser. Nå, den andre typen ting som vi har i verktøyet, som vil hjelpe deg å ta beslutninger, i tillegg er baselinjen og det å kunne sette opp varsler rundt de grunnleggende linjene og tersklene du oppretter dynamisk, som jeg sa tidligere, bare å kunne kjøre et stort antall rapporter som hjelper meg med å svare på spørsmål om hva som skjer.
Så som et eksempel, hvis jeg hadde 150 forekomster jeg klarer - i mitt tilfelle gjør jeg det ikke, så vi må spille det foregående spillet her - men hvis jeg hadde alle mine produksjonsforekomster og jeg trengte å forstå hvor er det området jeg trenger oppmerksomhet på, med andre ord, hvis jeg bare vil ha en begrenset periode til å utføre en slags administrasjon for å forbedre ytelsen, vil jeg fokusere på nøkkelområdene. Og så, med det sagt, vil jeg kunne si: "Basert på det miljøet, rangere tilfellene mine mot hverandre og gi meg den rangeringen etter kontroversjonsrør." Så om det er diskbruk, minnebruk, om det venter, Enten det er responstid, klarer jeg å korrelere - eller jeg skal si rang - de tilfellene mot hverandre. Det er klart at forekomsten som er øverst på hver liste, hvis det er den samme forekomsten, er det sannsynligvis noe jeg virkelig vil fokusere på, fordi det åpenbart igjen er øverst på listen.
Så du har mange rapporter i verktøyet som hjelper deg med å rangere miljøet på forekomstnivå; du kan gjøre dette også på databasenivå, der jeg kan rangere databasene mine mot hverandre. Spesielt med terskler og områder som jeg kan sette, kan jeg til og med sette opp jokertegn her hvis jeg vil, bare for å fokusere på bestemte databaser, men poenget er at jeg kan sammenligne databasene mine på samme måte. Så langt som andre typer komparativ analyse og det store i dette verktøyet, er den grunnleggende analysen vi har. Så hvis du blar ned til tjenestevisningen her, vil du se at det er en grunnleggende statistikkrapport. Nå kommer denne rapporten tydeligvis til å hjelpe oss med å forstå ikke bare hva metriske verdier er, men for en spesifikk instans kunne jeg gå ut, og for noen av disse beregningene, faktisk kunne se på grunnlinjene for disse beregningene.
Så hva enn det måtte være, i prosent eller hva jeg enn kan gå ut og si, "La oss se grunnlinjen for dette utbrutt i løpet av de siste 30 dagene, " i så fall vil det vise meg de faktiske verdiene i forhold til grunnlinjen og Jeg vil være i stand til å ta noen beslutninger ved å bruke den informasjonen, selvfølgelig, så dette er en av de situasjonene, hvor det kommer til å avhenge av hvilket spørsmål det er, som du stiller på den tiden. Men dette kommer tydeligvis til å hjelpe deg for mange av disse spørsmålene. Jeg skulle ønske jeg kunne si at vi hadde en rapport som gjør alt, og det er litt som den enkle rapporten, der du trykker og holder på, og den svarer bare på alle spørsmål om hva du kan svare på. Men virkeligheten er at du kommer til å ha mange attributter og mange alternativer for å kunne velge mellom i disse nedtrekkene for å kunne formulere disse spørsmålene "hva om" -typene du leter etter .
Så mange av disse rapportene er rettet mot å kunne svare på disse spørsmålene. Og så er det veldig viktig også at disse rapportene og i tillegg alle tingene vi allerede har vist deg i verktøyet, som jeg nevnte før, har fleksibilitet til å inkorporere nye beregninger, som skal administreres, til og med kunne opprette tellere eller SQL-spørsmål som er integrert i avstemningsintervallene dine, for å kunne hjelpe meg med å svare på disse spørsmålene, at du kanskje kan legge til ting ut av boksen vi ikke forventet å overvåke. Og du vil kunne gjøre alle de samme tingene som jeg nettopp viste deg: utgangspunktet, kjøre rapporter og lage rapporter fra den metrikken, og kunne svare på og gjøre mange av disse forskjellige typene ting som jeg viser deg her.
Nå, i tillegg til det - og en av tingene vi tydeligvis har opplevd ganske mye i det siste er - først var det den, alle bla eller byttet til VM-er. Og nå har vi mange mennesker som er på vei til skyen. Og det er mange spørsmål som dukker opp rundt den typen ting. Er det fornuftig av meg å flytte til skyen? Skal jeg spare penger ved å flytte til skyen? Hvis jeg skulle plassere disse tingene på en VM, på en maskin med delt ressurs, hvor mye penger kan jeg spare? Disse spørsmålene kommer tydeligvis også til å komme opp. Så mange av de tingene må huske på, med Diagnostic Manager kan vi legge til og trekke fra de virtualiserte miljøene til både VMware og Hyper-V. Vi kan også legge til forekomster som er ute på skyen, så miljøene dine som Azure DB, for eksempel, eller til og med RDS, kan vi trekke beregninger fra disse miljøene også.
Så det er mye fleksibilitet og mye å kunne svare på disse spørsmålene når det gjelder de andre typer miljøer som vi ser folk drar til. Og det er fortsatt mange spørsmål rundt dette, og når vi ser folk konsolidere de miljøene, trenger de å kunne svare på disse spørsmålene. Så det er en ganske god oversikt over Diagnostic Manager, for det gjelder dette emnet. Jeg vet at emnet business intelligence kom opp, og vi har også et verktøy for business intelligence som vi ikke snakket om i dag, men det kommer også til å gi deg innsikt i forhold til å svare på disse spørsmålene når det gjelder din terninger og alle de forskjellige typene ting også. Men forhåpentligvis har dette vært en god oversikt, i hvert fall med tanke på hvordan dette produktet kan hjelpe med å kunne formulere en god plan.
Eric Kavanagh: Ok, gode ting. Ja, jeg vil kaste det ut til Rick, hvis han fortsatt er der ute. Rick, noen spørsmål fra deg?
Rick Sherman: Ja, så først, dette er flott, jeg liker det. Jeg liker spesielt godt å utvide til VM og skyer. Jeg ser at mange apputviklere tror at hvis det er i skyen, så trenger de ikke å innstille det. Så-
Bullett Manale: Ikke sant, vi må fortsatt betale for det, ikke sant? Du må fremdeles betale for hva det er som folk legger på skyen, så hvis det kjører dårlig, eller hvis det forårsaker mange CPU-sykluser, er det mer penger du må betale, så det er det ikke, du trenger fortsatt å måle disse tingene, absolutt.
Rick Sherman: Ja, jeg har sett mange dårlige design i skyen. Jeg ønsket å spørre, ville dette produktet også bli brukt - jeg vet at du nevnte BI-produktet, og at du har mange andre produkter som samhandler med hverandre - men vil du begynne å se på SQL-ytelse, individuelle spørsmål i dette verktøyet? Eller ville det være andre verktøy som vil bli brukt til det?
Bullett Manale: Nei, dette vil absolutt. Det er noe av det jeg ikke dekket og jeg mente, er spørsmålets del. Vi har mange forskjellige måter å identifisere spørringsytelse på, enten det er relatert til, spesifikt til venting som vi ser på dette synspunktet her, eller om det er relatert til ressursforbruket til spørsmål generelt, det er et helt antall måter vi kan analysere spørring på opptreden. Det er om det er varighet, CPU, I / O, og nok en gang, vi kan også se på arbeidsmengdene selv for å gi litt innsikt. Vi kan gi anbefalingene i analysedelen, og vi har også en nettbasert versjon som gir informasjon rundt spørsmålene i seg selv. Så jeg kan få anbefalinger om manglende indekser og muligheten til å se utførelsesplanen og alt det slags; det er også en evne. Så absolutt, vi kan diagnostisere spørsmål syv måter til søndag (ler) og være i stand til å gi den innsikten når det gjelder antall henrettelser, det være seg ressursforbruk, ventetiden, varigheten, alt det gode.
Rick Sherman: OK, flott. Og hva er belastningen på forekomstene selv med all denne overvåkningen?
Bullett Manale: Det er et godt spørsmål. Utfordringen med å svare på det spørsmålet er, er det avhenger, det er akkurat som noe annet. Mye av det verktøyet vårt har å tilby, det gir fleksibilitet, og en del av den fleksibiliteten er at du får fortelle det hva du skal samle og hva du ikke skal samle på. Så for eksempel med spørsmålene i seg selv, trenger jeg ikke å samle på ventinformasjonen, eller det kan jeg også. Jeg kan samle informasjon relatert til spørsmål som overgår en varighet av tid, utførelse. Som et eksempel på dette, hvis jeg skulle gå inn på konfigurasjonsforespørselsmonitoren og si "La oss endre denne verdien til null", er virkeligheten at verktøyet i utgangspunktet gjør at verktøyet samler alle spørsmålene som kjøres, og det er virkelig ikke ånd av hvorfor det er der, men generelt sett hvis jeg ønsket å gi et komplett utvalg av data for alle spørsmålene, kunne jeg gjøre det.
Så det er veldig relativt til hva innstillingene dine generelt sett er utenfor boksen. Det er alt fra ca. 1-3 prosent, men det er andre forhold som vil gjelde. Det avhenger også av hvor mye portforespørsler som kjøres på miljøet ditt, ikke sant? Det avhenger også av metoden for samling av disse spørsmålene og hvilken versjon av SQL det er. Så for eksempel SQL Server 2005, vi kommer ikke til å være i stand til å trekke oss fra utvidede hendelser, mens vi vil trekke fra et spor for å gjøre det. Så det ville være litt annerledes når det gjelder hvordan vi skulle samle inn disse dataene, men når det er sagt, har vi som jeg har trodd siden 2004 med dette produktet. Det har eksistert i lang tid, vi har tusenvis av kunder, så det siste vi ønsker å gjøre er å ha et verktøy for ytelsesovervåkning som forårsaker ytelsesproblemer (ler). Og så prøver vi å unngå det, så mye som mulig, men generelt sett er omtrent 1-3 prosent en god tommelfingerregel.
Rick Sherman: OK, og det er ganske lavt, så det er kjempefint.
Eric Kavanagh: Bra. Robin, noen spørsmål fra deg?
Robin Bloor: Jeg beklager, jeg var på stum. Du har en flere databasefunksjoner, og jeg er interessert i hvordan du kan se på flere databaser, og derfor kan du vite at en større ressursbase muligens er delt opp mellom forskjellige virtuelle maskiner og så videre og så videre. Jeg er interessert i hvordan folk faktisk bruker det. Jeg er interessert i hva kundene gjør med det. Fordi det ser ut for meg, vel, det absolutt, da jeg rotet med databaser, noe jeg aldri hadde på hånden. Og jeg ville bare noen gang vurdert en forekomst på noen meningsfull måte på et gitt tidspunkt. Så, hvordan bruker folk dette?
Bullett Manale: Generelt sett snakker du om bare selve verktøyet? Hvordan bruker de det? Jeg mener, generelt handler det om å kunne ha et sentralt poeng av tilstedeværelse av miljøet. Å ha trygghet og vite at hvis de stirrer på en skjerm og ser grønt, vet de at alt er bra. Det er når problemer skjer, og tydeligvis de fleste tilfeller fra en DBAs perspektiv, mange ganger disse problemene skjer når de er foran konsollen, så det å kunne varsles så snart problemet skjer. Men i tillegg til det, å kunne forstå når problemet skjer, å kunne komme til kjernen i informasjonen som gir dem en viss kontekst når det gjelder hvorfor det skjer. Og det er, tror jeg, den største delen: å være proaktiv overfor det, ikke være reaktiv.
De fleste av DBAene jeg snakker med - og jeg vet ikke, det er en god prosentandel av dem - er dessverre fortsatt i den reaktive typen miljø; de venter på at en forbruker skal henvende seg til dem for å fortelle dem at det er et problem. Og så ser vi mange mennesker prøve å bryte seg bort fra det, og jeg tror det er en stor del av grunnen til at folk liker dette verktøyet er at det hjelper dem å være proaktive, men det gir dem også innsikten i hva som skjer, hva er problemet, men i mange tilfeller, det vi finner minst - og kanskje er det bare DBAene som forteller oss dette - men DBAene, oppfatningen er at det alltid er problemet deres, selv om det er applikasjonsutvikleren som skrev applikasjonen som ikke skrev det ordentlig, det er de som kommer til å ta skylden, for de tar den applikasjonen inn i systemene eller serverne sine, og når ytelsen er dårlig, peker alle på DBA, "Hei, det er din skyld."
Så dette verktøyet blir mange ganger brukt til å hjelpe i forhold til å gjøre saken til at DBA sier: "Hei, det er her problemet ligger og det er ikke meg." (Ler) Vi må forbedre dette, enten det er om å endre spørsmålene eller hva det måtte være. I noen tilfeller vil den falle i bøtta deres med tanke på deres ansvar, men i det minste å ha verktøyet for å kunne hjelpe dem å forstå det og vite det, og å gjøre det på en betimelig måte, er åpenbart den ideelle tilnærmingen.
Robin Bloor: Ja, de fleste nettstedene jeg er kjent med, men det har gått en stund siden jeg har vært der ute og sett på forskjellige multidatabasesider, men det jeg pleide å finne var at det ville være DBA-er som fokuserte på en håndfull databaser. Og det ville være databasene, at hvis de noen gang gikk ned, ville det være et virkelig stort problem for virksomheten, og så videre og så videre. Og de andre, de vil bare samle statistikk nå og da for å se at de ikke gikk tom for plass og at de aldri ville se på dem i det hele tatt. Og mens du gjorde demoen, så jeg på dette, og jeg tenkte godt, på en eller annen måte utvider du bare ved å tilby noe slikt for databaser som ofte var det ingen som brydde seg for mye om, fordi de har datavekst, de har applikasjonsvekst til tider også. Du utvider DBA-dekningen på en ganske dramatisk måte. Så det er det spørsmålet egentlig handler om, er det at med et sett verktøy som dette, ender du opp med å kunne gi en DBA-tjeneste til hver database som er i bedriftsnettverket?
Bullett Manale: Visst, jeg mener, utfordringen er at det er som du sa ganske veltalende, er at det er noen databaser som DBAene bryr seg om, og så er det noen de ikke bryr seg om så mye. Og måten dette bestemte produktet, måten det er lisensiert på, er på en per forekomst basis. Så det er, antar jeg, du vil si, en terskel for når folk bestemmer seg "Hei, dette er ikke et kritisk nok tilfelle til at jeg vil administrere det med dette verktøyet." Når det er sagt, det er andre verktøy som vi gjør har det mer, antar jeg, å ta imot de mindre viktige forekomstene av SQL. En av dem vil være som Inventory Manager, der vi foretar lette helsekontroller mot forekomstene, men i tillegg til det vi gjør er vi å oppdage, så vi identifiserer nye forekomster som har blitt brakt på nettet, og fra det tidspunktet som en DBA kan jeg si: “OK, her er en ny forekomst av SQL, nå er det ekspress? Er det gratisversjonen, eller er det en bedriftsversjon? ”Det er nok et spørsmål jeg vil stille meg, men for det andre, hvor viktig er den forekomsten for meg? Hvis det ikke er så viktig, kan det hende at jeg har dette verktøyet som skal ut og gjøre det, generisk, det jeg vil kalle generiske helsekontroller i den forstand at de er elementære typer ting jeg bryr meg om som DBA: Er stasjonen å fylle ? Svarer serveren på problemer? De viktigste tingene, ikke sant?
Mens Diagnostic Manager, verktøyet jeg bare viste deg, kommer til å komme ned på spørringsnivået, det kommer til å komme inn på anbefalingen fra indekser, se på utførelsesplanen og alt det gode, mens dette hovedsakelig er fokusert på hvem som eier hva, hva er det jeg eier og hvem som er ansvarlig for det? Hvilke servicepakker og hot fixes har jeg? Og kjører serverne mine med hovedingrediensene i det jeg anser for å være en sunn forekomst av SQL? Så for å svare på spørsmålet ditt, er det litt av en blanding. Når vi har folk som ser på dette verktøyet, ser de vanligvis på et mer kritisk sett av forekomster. Når det er sagt, har vi noen mennesker som kjøper alle forekomster de har og administrerer det, så det avhenger bare. Men jeg sier deg, generelt sett er det definitivt en terskel for de menneskene som anser at miljøet deres er viktig nok til å ha et verktøy som dette for å administrere disse tilfellene.
Robin Bloor: Ok, et nytt spørsmål før jeg overlater det til Eric. Inntrykket man får, bare fra å se på bransjen, er at databaser fremdeles lever, men all data strømmer inn i alle disse datasjøene og så videre og så videre. Det er egentlig hype, og hypen gjenspeiler aldri virkeligheten, så jeg er interessert i hva slags virkelighet du oppfatter der ute? Er de viktige databasene i en organisasjon, opplever de den tradisjonelle dataveksten, som jeg pleide å tenke på som 10 prosent i året? Eller vokser de mer enn det? Er stor data gjør disse databasene ballong? Hva er bildet du ser?
Bullett Manale: Jeg tror mange tilfeller vi ser at noen av dataene blir flyttet inn i de andre segmentene der det er mer fornuftig når det er andre teknologier som blir tilgjengelige. Som nylig, noen av de større dataene ting. Men disse databasene, vil jeg si, er det vanskelig å generalisere i mange tilfeller fordi alle er litt forskjellige. Generelt sett ser jeg imidlertid noe avvik. Som jeg sa, folk flytter til mange elastiske modeller i mange tilfeller, fordi de vil dyrke ressursene og ikke så mye på andre områder. Noen mennesker flytter til big data. Men det er vanskelig å få en følelse av, sier du, oppfatningen, fordi folkene jeg snakker med generelt har de tradisjonelle databasene og bruker dette i et SQL Server-miljø.
Når det er sagt, vil jeg si når det gjelder SQL selv, jeg tror fremdeles fremdeles at den vinner markedsandeler. Og jeg tror at det er mange mennesker som fremdeles er på vei mot SQL fra andre steder som Oracle, fordi det er mer overkommelig og ser ut til å være tydelig, ettersom SQL-versjoner blir mer avanserte - og du ser dette med de nyere tingene som fortsetter med SQL, når det gjelder kryptering og alle de andre funksjonene som gjør det til et miljø eller en databaseplattform - det er åpenbart veldig misjonskritisk kapabel, antar jeg. Så jeg tror vi ser det også. Der du ser et skifte, skjer det fortsatt. Jeg mener, det skjedde for 10 år siden, det er fremdeles, tror jeg, det skjer i form av SQL Server, der miljøet vokser og markedsandelen vokser.
Robin Bloor: OK, Eric, jeg antar at publikum har et spørsmål eller to?
Eric Kavanagh: Ja, la meg kaste en rask en over til deg. Det er et ganske godt spørsmål, faktisk. En av de fremmøtte spør, vil dette verktøyet fortelle meg om en tabell kan trenge en indeks for å få fart på spørsmålet? Kan du i så fall vise et eksempel?
Bullett Manale: Yeah, so I don't know if I have one for a specifically adding an index, but you can see here, we have fragmentation recommendations here. I also just believe we just had and this was part of the Diagnostic Manager offering the web-based version, where it's telling me I have a missing index. And we can view those recommendations and it'll tell us the potential gain of that by indexing that information. The other thing I should just mention is that when we do the recommendations, for many of these, the script will be built for it. That one's not a good example, but you would be able to see, yes, the situations where an index – either a duplicate index, or the addition of an index – would improve performance, and like I said earlier, we do a lot of that through hypothetical index analysis. So, it really helps in terms of understanding the workload, to be able to apply that to the recommendation.
Eric Kavanagh: That's great stuff, and this will give me a good segue to the final comments here. Robin and I and Rick as well, have heard over many years now, there's talk about self-tuning databases. It's a self-tuning database! All I can tell you is: Don't believe them.
Bullett Manale: Don't believe the hype.
Eric Kavanagh: There may be some small little things that get done dynamically, but even that, you might want to check it out and make sure it's not doing something you don't want it to do. So, for quite some time, we're going to need tools like this to understand what's happening at the database level and like Robin said, data lakes are fascinating concepts, but there's probably about as much chance of them taking over as there is of there being a Loch Ness Monster anytime soon. So, I would just say again, the real world has a lot of database technology, we need people, DBAs, to look at this stuff and synthesize it. You can tell, you need to know what you're doing to make this stuff work. But you need the tools to give you the information to know what you're doing. So, bottom line is DBAs are going to be doing just fine.
And big thanks to Bullett Manale and our friends at IDERA. And of course, Rick Sherman and Robin Bloor. We do archive all of these webcasts, so hop online insideanalysis.com or to our partner site www.techopedia.com for more information on all that.
And with that, we'll bid you farewell, folks. Thanks again, we'll talk to you next time. Ha det fint. Ha det.
