Av Techopedia Staff, 30. november 2016
Takeaway: Vert Eric Kavanagh sammen med Dr. Robin Bloor, Dez Blanchfield og IDERAs Bullett Manale diskuterer spørsmål og hvordan effektiviteten deres kan ha vidtrekkende effekter.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hallo og velkommen tilbake igjen. Klokken er østøst på fire onsdag, og i disse dager betyr det at det er tid for Hot Technologies! Ja absolutt. Vi snakker om kule greier i dag. Selvfølgelig er jeg din vert, Eric Kavanagh. Tittelen på dagens show er "Nøkkelen til effektiv analyse: raskt tilbakevendende spørsmål." Det stemmer, folkens, vi ønsker alle raskt. Hvem vil ikke fort? Det er et lysbilde om deg, og nok om meg. Hit meg på Twitter, @eric_kavanagh. Jeg vil gjerne få kontakt med deg der og ha en samtale i sosiale medier. Det kan være morsomt, bare ikke snakk om politikk.
Årets hete. Vi har snakket om forskjellige analytiske problemer i år, og det ene emnet for i dag er egentlig bare sentralt for å få jobben gjort. Jeg husker det var sannsynligvis for fem-seks år siden at jeg først hørte noen bruke uttrykket "ha en samtale med dataene dine", og selv om det kan høres litt ostete ut, er poenget at hvis du ikke kan få en iterativ opplevelse med dataene dine, hvis du ikke raskt kan endre spørsmålene dine, sende nye spørsmål, få svar raskt tilbake, så har du ikke en samtale med dataene dine, og hele analyseprosessen er avkortet. Det er ikke bra.
Når du har en samtale med dataene dine, hva det betyr er at du er i stand til å gå frem og tilbake, og etter min mening er det når du finner innsikten. For veldig sjelden skal du komme med den perfekte spørringen første gang. Med mindre du er Mozart for analytics - og jeg er sikker på at den personen er der ute - må du bruke litt tid på å endre, legge til en viss dimensjon, prøve å finjustere hva det er som du leter etter .
Fordi, igjen, dette er ikke enormt vanskelige miljøer som vi har å gjøre med i en verden av analyse; vi har å gjøre med veldig uhåndterlige miljøer og veldig komplekse og flerdimensjonale miljøer. Og hele ideen med webcasten i dag er å snakke om hvordan du kan aktivere den slags iterative interaksjoner med dataene dine.
Vi har tre presentatører. I Hot Technologies, i motsetning til Briefing Room, har vi selvfølgelig to analytikere; de gir hvert sitt først, så kommer gjesten inn, gir presentasjonen, og vi har en slags rundbord. Og du, vårt publikum, kan spille en stor rolle i det. Vær ikke sjenert; send inn spørsmålene dine når som helst. Bruk spørsmål og svar-panelet hvis du kan, ellers er chat-panelet bra; Jeg skal prøve å overvåke begge i løpet av showet. Og vi registrerer disse, så hvis du går glipp av noe eller vil dele det med kollegaene dine, kom tilbake senere. Vi legger dem ut på Techopedia.com og også på InsideAnalysis.com.
Og med det skal jeg få inn de smarte menneskene. Jeg overlater det til Dr. Robin Bloor. La meg gi ham nøklene, bytte programleder, og dit går du. Robin, ta den bort.
Robin Bloor: OK. Takk for introen. For omtrent halvannen måned siden snakket jeg med en utvikler som faktisk er en DBA. Han er egentlig ikke en DBA - han var en DBA i et bestemt selskap, og han var den eneste personen som faktisk kunne få spørsmålene til å utføre. Men han ble lei av å gjøre det, fordi han egentlig er, han er faktisk en ganske smart utvikler. Så han dro.
Og han må gjøre et par dager hver måned for dem uansett, fordi de ikke kunne finne noen til å ta sin plass og de har ikke peiling på hva databasen gjør eller hvordan de i det hele tatt kan innstille den. Og jeg tenkte litt på det, og bare, du vet, de hadde egentlig ikke en IT-avdeling, men denne fyren støttet dem. Egentlig var det DBA-arbeid han gjorde mesteparten av tiden.
For sofistikerte databaser - Oracle, SQL Server, DB2, alle de store, dyre, er tuning av databaser en tøff jobb. Det er en sikker jobb også. Og grunnen til at jeg sier det er at det er et landskap i endring. Jeg skal ganske gjennomgå dette. Du vet, relasjonsdatabaser - vanligvis er det store bildet, de relasjonsdatabasene dominerer fremdeles i popularitet. Det er sannsynlig at de vil dominere i lang tid fremover. Ja, det er andre databaser nå som får mer lufttid, men, du vet, når du faktisk ser på hva som skjer der ute, gjør Oracle det meste av det, Microsoft SQL Server er andre, og det er forskjellige ting som skjer i skyen som kan imidlertid føre til en utfordring. De er de store gigantene i spillet. Og det er databasene du kan bruke både til OLTP og faktisk arbeidslager for datavarehus. Alternativer brukes vanligvis hovedsakelig i analytiske miljøer, og deretter bestemmes det normalt av dataene om hvorfor vi vil velge det fremfor relasjonelle. Det meste gjør ikke folk.
Bedrifter har en tendens til å standardisere på en enkelt database. Jeg kom over et selskap nylig som hadde over 5000 forekomster av Oracle. Og jeg, personen jeg snakket med fra det selskapet, spurte jeg dem om DBA-er. De sa at de hadde omtrent 10 DBA-er og rundt 30 databaser ble ivaretatt. Og resten ble Oracle bare brukt som et endelig system stort sett. Det var veldig lite stress på dataene fra applikasjonene som brukte dem. Men det overrasket meg bare - 5000 tilfeller av Oracle.
Og forresten, de hadde Oracle-eiendomslisens. Du vet, bedriftens lisens, tydeligvis. Men de hadde også andre databaser, fordi noen ganger, du vet, programmer kommer med en foretrukket database. Det var ikke som om Oracle var det eneste. Og verdt å nevne at verken Hadoop eller Spark faktisk er en database, og det vil ta lang tid før de skaffer seg det jeg tenker på som en databaseregel. Bra for datalinker, selvfølgelig.
Med DBA-aktiviteter - kan Bullett sannsynligvis si mye mer om dette enn meg - men jeg vil bare løpe gjennom dem. Dette er hva jeg pleier å tenke på, vet du, hva DBA gjør. De installerer, konfigurerer, oppgraderer, gjør lisensbehandling. De gjør mye ETL- og replikasjonsarbeid på en eller annen måte. De gjør lagrings- og kapasitetsplanlegging. De gjør feilsøking, eller de er en del av feilsøkingsteamet. Ytelsesovervåking og tuning er stort sett mesteparten av aktiviteten deres, men alt dette andre ting, det er ikke lite, vet du. Sikkerhet, de er ansvarlige for sikkerhetskopiering og gjenoppretting. De burde være involvert i testsystemer for programvare, og de kan være involvert i livssyklusen for data.
Opptreden. Da jeg pleide å være en av disse karene. Da jeg kjørte og avstemte databaser, var det slik jeg forsto det, vet du? Det er CPU, og på en eller annen måte i vår tid er CPU ganske mye normalt inaktiv, fordi den ville være en av de to andre eller th– Vel, en av de andre flaskehalsene ville faktisk forårsake problemet. Minne, trashing og fragmentering, eller disk, eller disk I / O-metning, noen ganger nettverkskostnader, hvis du kjører i flere noder i et nettverk og du faktisk kan støte på noe låsing, sannsynligvis.
Men det var verden slik jeg så den. Jeg så nylig på Oracle og antall innstillingsparametere som finnes i Oracle. Det var over 300. Du vet, og hvis du faktisk tenker på det, må en DBA som virkelig vet hva han gjør, ha en ide om hvorfor du noen gang ville rote med noen av disse. Så det er en komplisert jobb, vet du, og det er mer komplisert av dette.
Du vet, akkurat nå har vi CPU-er, men du har … CPU-ene allerede eksisterte, GPU-er på CPU-en, eller med FPGA-er på CPU-en. Så det skjer en slags krysning av hva som faktisk skjer på en CPU. CPU-er ble flerkjerner for lenge siden; faktisk tunet jeg ikke lenger databaser når det skjedde. Jeg aner ikke hvilken forskjell det faktisk gjør, nå som jeg tenker på det.
Vi har, 3D Xpoint og IBMs PCM, dukket opp som et ekstra lag med minne, og vi har SSD-er, men du vet, de erstatter roterende rust. Men SSD-ene kan variere i hastigheter. Med så mange kan du ha parallell tilgang, og det gjør at de går utrolig raskt - nær RAM-hastighet. Og du har alle de parallelle maskinvarearkitekturene.
Og dette er alt, du vet, kostnadene faller, noe som er veldig fint, men dette er alt mulig å gjøre - vet du, hvis du tar neste utgave av en database og så begynner du å implementere den på maskiner, til og med noen av dette har du faktisk mistet magefølelsen du måtte ha for måten dataene oppfører seg på, fordi forsinkelsene bare er veldig, veldig forskjellige. Og her, du vet, har du fire lag i stedet for tre lagringsplass.
Databaseproblemer. Du får database entropi - spredning av forekomster er veldig vanlig. Databaser som ble brukt som skap, og det er det eksemplet jeg ga. Svært få databaser er selvinnstilt, og de som hevder å være selvinnstiller er faktisk ikke så bra, vet du. Men den andre tingen er at veldig få databaser er riktig innstilt. Det er en tøff jobb, å kunne balansere arbeidsmengden. Jeg mener, når du tenker på en database, hva en database gjør over en 24-timers periode, kan arbeidsmengdene være veldig, veldig forskjellige. Databasen må ha et spesielt sant datavarehus.
Og derfor er det ikke en triviell sak å stille inn, for det du gjør er å stille inn parametere som må passe for en hel rekke arbeidsmengder over et gitt tidspunkt. Det er en tøff jobb, i utgangspunktet. Og SQL må være innstilt spesielt for SQL JOINs. De kan være ekstremt, du vet, ressurskrevende. Og hvis databasen har materialiserte synspunkter, for å være ærlig, bør du undersøke bruken av disse, fordi de får alt til å gå utrolig raskere. Og det krever noen som forstår arbeidsmengden og forstår SQL-trafikken og så videre og så videre.
Og de fleste selskaper ansetter veldig få DBA-er - veldig dyre. Jeg har kjent ganske store selskaper med, som tre karer, du vet, enormt mange tilfeller. Egentlig koster de mye, det er en vanskelig jobb med tanke på kompleksiteten. De trenger verktøy.
Og jeg tror det er alt jeg har å si. Å, ja. La oss gi oss til Dez, se hva Dez har å si.
Dez Blanchfield: Takk, Robin. Dette er et massivt tema. Jeg kommer til å holde på de tingene som jeg tror, som er effektive daglige utfordringer vi står overfor. For la oss innse det, det er et helt bibliotek med bøker skrevet om dette emnet. Som ikke har gått til en teknisk bokhandel og funnet vegger og vegger i bøker skrevet om bare det generelle emnet databaseprestasjoner, databaseinnstilling, og overvåking. Og noen ganger er det en fin måte å drepe tid på.
Det generelle emnet: få resultatspørsmål. Det er en rekke forskjellige deler av organisasjonen som svetter dette emnet - på sluttbrukernivå, etter min erfaring, vet du, folk bare opplever ytelse, at ting går sakte. Det tar en stund å spinne hjul for å få spørsmålene tilbake. I motsatt ende av spekteret har du infrastruktur- og nettverks- og lagringsingeniører som blir banket opp av databasespesialister fordi ting ikke kjører så bra som de forventer. Og det er et veldig bredt spekter, etter min erfaring, de tingene som kan påvirke livene våre i det spekteret.
Hvis du tenker på, fra det fysiske og oppover, vet du bare datamaskinområdet. Det har minne, du vet, RAM, hvis du vil - diskplass, nettverk og alle bitene rundt det. På denne plassen har vi, vet du, det lagrer tanken om at si, at du vet, det er bedre å bruke rå disk eller en JBOD, og bare, du vet, heve så raskt som mulig disken og la database sortere ut databeskyttelseslaget. Andre mennesker er store fans av RAID, det overflødige utvalg av billige disker, og har forskjellige religiøse opplevelser med RAID 0, 1, 3, noen ganger 5 og 6 forskjellige typer striping eller replikering på disk, i tilfelle harddisken mislykkes. Selv på lagringsnivå og ingeniørnivå har vi fremdeles folk som har forskjellige synspunkter og erfaringer rundt ytelse, på typer lagring.
Enten det er direkte tilknyttede disker og serverne selv, eller om det er koblet via en fiberkanal med et lagringsområde-nettverk av en eller annen form, enten det er lagring montert fra en server et sted via iSCSI eller er det Ethernet, for eksempel. Og det er før du til og med kommer til databasesjiktet, der du vet hva slags ting vi tar for gitt - du vet, bare opprettholde det, som Eric skisserte, du vet, hva vi kaller samtalen med dataene dine . Bare det å være i stand til å identifisere mønstre og meningsfylte mønstre som vi tror vi kan begynne å dykke ned i og se etter ytelsesproblemer.
Og det er et veldig bredt emne, så jeg kommer til å dykke i to områder der erfaringen min, tid og energi og innsats som er investert får litt god avkastning. Så la meg bare raskt hoppe til den første av disse. Og jeg bare halvspøktet og lette etter et bilde av noe som hadde et skjelett på innsiden og huden på utsiden, men Lego-blokken var nok den minst grusomme. Men på mange måter er det slik jeg forestiller meg og mentalt ser utfordringen vi noen ganger står overfor med analyseplattformer og databaser som støtter dem. Og det er det, du bare, som forbruker og sluttbruker eller til og med en utvikler, ofte ser finérhudlaget, men det er faktisk skjelettet under - det er virkelig problemet du trenger å fokusere på.
I dette tilfellet vet vi når vi tenker på de tingene som kan påvirke databasens ytelse og analyser som følge av den bestemte dagen, resultatene treff, kjerneinfrastrukturen og bare overvåke den kjerneinfrastrukturen, og som jeg skisserte for et øyeblikk siden, rundt din disk og minne og CPU. Og som Dr. Robin Bloor fremhevet, utfordringer nå i virtualisering og ting som skjer i sjetongene selv, og ytelse ned til kjernenivå, og mengden minne som nå blir lagt inn i hver brikke i hver kjerne. Dette er veldig tekniske utfordringer å se på for en hverdagslig person.
Holder på toppen av spørreovervåking. Du vet, en av utfordringene rundt overvåking av spørsmål og spørringskøer er for eksempel - jeg mener, SQL som språk og databaseverktøyene som kommer rundt analyseverktøy, er veldig kraftige, og spesielt SQL som språk. Men med den kraften og enkelheten kommer også en, i mange tilfeller, og det er at hvis det ikke er et program som gjør det samme igjen og igjen, skrevet av en god utvikler og oppdaget av en god DBA, kan det være mennesker som gjør ustrukturerte spørsmål.
Og problemet med det er, det er ganske enkelt å lære seg litt SQL og begynne å lage spørsmål, men som et resultat av det, trenger du ikke nødvendigvis alle ferdighetene og erfaringene og kunnskapene til å vite om du gjør bra eller dårlig ting å gjøre databasen. Så kontinuerlig å kjøre den samme store, brede, gale kan bare ta bygningen ned. Å følge med på spørreovervåkning er en interessant utfordring.
Bare overvåking responstidene så langt plattformen gjør og hva brukerne får. Igjen, du vet, uten de riktige verktøyene, er dette ikke noe du bare intuitivt ser på tingen og tenker: "Åh, nettverket går tregt", eller "Brukerminnet presterer ikke bra", eller "Indeksene har dårlige resultater "Eller" er oppblåst. "
Og da, du vet, hvordan kommer du til et punkt der du, når du først har sett et problem med det, hvordan kan du trekke det fra hverandre og ta bort det og takle hele utfordringen med dårlig strukturerte spørsmål? Og du vet, er det et ad hoc-spørsmål som noen kjører for hånd, eller er det et analyseverktøy med et frontpanel på dashbordet som fungerer dårlig fordi de stiller spørsmålene på feil måte, eller er det bare en virkelig, virkelig dårlig skrevet kode?
Og så gjør det iterativet av, sa Eric i oppsettet innledningsvis, du vet, bare iterativt å gå om og om igjen og om igjen og finjustere arbeidsflytene. Du vet, hvilke arbeidsflyter kjører jeg, hvordan kjører de, hvor ofte kjører de, hvilken kode kjører mot dem, hvor kjører de mot den i CPU og minne og disk og nettverk? Ja, det er bare en veldig teknisk utfordring.
Og så nirvanaen som folk leter etter i denne verden, mens de skifter fra historisk analyse og ytelse innstilling og varsling mot omgivelsene dine, noe som er flott å se fordi du kanskje får en plan i fremtiden for det hvis du vet hvorfor ting gikk sakte i går morges klokka ni. Men det hjelper deg ikke akkurat nå, og det hjelper ikke planen din fremover.
Jeg tror at kapasitetsplanlegging og dimensjonering og skalering og innstilling, så du vet, jeg tror det er en trend vi ser nå, der det er et skifte i veldig store miljøer der folk har store databaseplattformer og bredt spredte databasemiljøer å gå fra historisk varsling og planlegging til prediktiv varsling og planlegging, der de vil vite hva som skjer akkurat nå og kunne planlegge for det fremover. Eller går vi tom for minne og kommer til å gå tom for minne i løpet av den neste timen, og hva kan vi gjøre med det? Hvilken kapasitetsplanlegging kan vi gjøre i sanntid?
Unnskyld meg. Det kommer til det punktet, hvor du vet, bare hele utfordringen med å oppdage disse hindringene kommer i veien for det vi omtaler som fluidanalyse, og gjør det til normen i organisasjonen din. Som du ser, er det en ikke-triviell utfordring for, du vet, bare de store hverdagslige, uvaskede massene. Og det er fremdeles en ikke-triviell utfordring for enda de mer teknisk kyndige.
Du vet, hvis det er vanskelig for bare dødelige, hvordan gjør vi dette til en ting som er mulig? Fordi du vet, det meste av dette er ting som vanlige brukere ikke kan løse, og vi kan ha noen spesielle databaseanleggere, databaseutviklere, kodeutviklere, programmerere, men de har fremdeles virkelig fått være i stand til å adskille miljøet. De må trekke fra hverandre, du vet, problemer som folk som bruker kode igjen.
Du vet, noe av det verste jeg har sett i dette rommet rundt ytelse treff i analyseplattformer i veldig store distribusjoner av databaseserverinfrastruktur, er folk som tar et stykke kode, en del av SQL eller en stjålet prosedyre som de ikke gjorde. ' t skrive, og de vet ikke om det er et godt eller dårlig stykke kode, og de bare bruker den igjen fordi det gir dem resultatet de vil ha. Men det viser seg at det kan ha vært bare noe som ble skrevet på farten for å få ett eller to utfall, som en rapport - noen hadde det travelt.
Og slik bruker folk kompleks kode de ikke skrev, og bare smeller det til et stykke applikasjonsutvikling, uten å vite at de faktisk straffer bakenden. Selv bare å overvåke den ytelsen og se på hvor spørsmålene kommer fra og bore ned, det, vet du, det er en hverdagslig utfordring jeg ser.
Grunnleggende oppførsel ting som pre-iscenesettelse data for ytelse der det er mulig. Ting som bare opplever, lærer deg bare, som å slette indekser hvis du skal importere bulk og deretter indeksere på nytt slik at indeksene ikke opprettholdes når du henter inn terabyte med data. Du vet, uten de nødvendige verktøyene, det er nesten umulig å se fordi du ikke vet at indeksen blir hamret.
Å optimalisere indekser regelmessig er en slags 101, men hva med, du vet, når du gjør bulkimport eller, vet du, oppretter en tabell med spørsmål hvis noen gjør et veldig stort spørsmål? Du vet, det kan være en massiv ytelse hit, og igjen, hvis du ikke overvåker, har du ikke verktøyene til å se det, den slags skjer bare i bakgrunnen, og du vet ikke hvordan du takler det .
Begrensning av spørsmål til bare antall kolonner du trenger - jeg mener, det høres veldig grunnleggende ut, men igjen, hvis du ikke kan se det, vet du ikke at det skjer, og så skjer det bare i bakgrunnen og det gjør deg vondt, på deg.
Å vite når og hvor du skal bruke midlertidige tabeller, batching up store slettinger og oppdateringer. Igjen, alle veldig enkle ting, men uten den synligheten, uten verktøyene for å gjøre det, sitter de bare i bakgrunnen og fortsetter å skade deg, og du kaster bare mer minne eller CPU til et databasemiljø for å få bedre ytelse på analyseplattformen, når virkelig bør du være i stand til å bore i detalj om hva som skader deg og ta opp den aktuelle tingen. Og da, du vet, ting som utenlandske nøkkelbegrensninger, og hvordan finner du det, hvordan vet du til og med at det er et problem?
Det bringer meg til konklusjonen av mitt sentrale punkt her, og det er at du vet, på en daglig basis, vi ser disse problemene overalt. Og etter hvert som databasemiljøer blir større og større og mer og mer brede, og som Dr. Robin Bloor fremhevet her, får vi flere og mer komplekse miljømodeller med databasetider.
Og da også behovet for å integrere seg i noen av de store dataplattformene som Hadoop og Spark som følger med, og mer og mer om gangen. Det trenger etter mitt syn å finne bedre måter og spesielle verktøy for å utføre denne sanntidsplattformytelsen og analyser og diagnostikk på en intelligent måte. Fordi det koster sanntid og ekte penger og frustrasjon for sluttbrukere og ekte dollar hvis vi ikke begynner å komme til verktøyene for å dykke ned i disse tingene.
Og med det skal jeg overlate til vennene våre fra IDERA, fordi jeg tror de har en god historie å fortelle om hvordan vi kan være i stand til å løse dette problemet.
Bullett Manale: Høres bra ut. Tusen takk, så vil jeg fortsette og sparke av gårde. Jeg har fått noen lysbilder her også, og lar meg gå foran og slags bringe det opp. Noen av disse skal vi hoppe gjennom ganske raskt.
Bare for å gi deg litt innsikt, er jeg direktør for salgsteknikk her på IDERA, og det vi gjør er litt snakk med DBA-er ganske regelmessig om smertene og utfordringene de har, spesifikke for, i mange tilfeller, ytelsesovervåking og den slags ting, åpenbart. Og vi hører mye fra det publikummet, og derfor tror jeg at jeg kan dele noe av informasjonen jeg mottar fra dem med jevne mellomrom som vil være fornuftig. Jeg kommer til å hoppe gjennom noen få av disse, for jeg tror ikke at de er reelle relevante for samtalen.
Du vet, jeg har min egen liste her over DBAs ansvar - det ligner mye på Robins liste, og jeg synes at det er ganske konsistent. Jeg tror at når du snakker med en databaseadministrator, er det alltid - du vet, de er klumpet inn i noen av disse områdene mer enn andre, og det er ingen rim eller grunn til det, det avhenger bare av miljøet.
Du hører et ganske bredere og bredt spekter av ting som folk vil kunne gjøre. Og mange ganger gjør ikke menneskene som vil ha disse tingene - de vil be om dem, og i noen tilfeller begynner du å bore det de virkelig ber om, og så finner du ut at de ' re virkelig ute etter mer. De vil virkelig ha mer informasjon enn hva de opprinnelig tror at de trenger, og når du begynner å bore inn verktøyet, tror jeg at det er der du kan begynne å si at de har en samtale med dataene.
Og jeg tror at det er en virkelig interessant frase, og det gir mye mening i forhold til å kunne si, ja, hvis du har en dårlig spørring, hva er egentlig et dårlig spørsmål? Er det et spørsmål som bruker mye lesing eller skriving eller CPU? Det kan være en som løper mye, den kan en, du vet, det er, som du sa, dårlig skrevet.
Når det gjelder hvordan vi identifiserer det, er det en rekke måter du ser når det gjelder produktet vårt, Diagnostic Manager-produktet, at vi viser DBA-er at de kan gjøre det. Og det er virkelig fleksibelt, og jeg tror det er en av de store tingene - du må ha et verktøy som hjelper deg med disse ytelsesproblemene, er alles miljø litt annerledes.
Og det kommer til å være mange, du vet, behov og kanskje til og med dunkle krav når det gjelder overvåking, så du må ha noe som er fleksibelt og noe som kommer til å fungere og kunne tilpasse seg miljøet som du prøver å klare deg. Du vet, og jeg har mange av disse eksemplene - jeg kommer ikke til å gå gjennom hver enkelt av dem, men du trenger noe du kan svinge frem og tilbake mellom en datamaskin og en annen, og jeg vil liksom snakk om det når vi kommer litt inn i produktet og viser deg det, og når det gjelder hvordan vi gjør det.
Men den andre tingen jeg tenker på hva som helst godt analyseverktøy er, vet du, det er noen sentrale ting du virkelig leter etter. Du ønsker tydeligvis først og fremst ikke et verktøy som vil føre til egne ytelsesproblemer i ytelsens navn. Når jeg sier å samle inn dataene uten kostnad, snakker jeg ikke om kostnadene i form av, du vet, monetære kostnader, men når det gjelder kostnadene når det gjelder overhead og kostnadene i form av mengden ressurser som vi kommer til å bruke i navnet på ytelsen. Du vil definitivt ha noe der som vil hjelpe.
Du trenger noe som vil være i stand til å få dataene du leter etter, spesifikke for problemene du møter i det daglige, og det kan være noen ting du ikke trenger og som du ikke trenger Jeg vil ikke ha det, og det er ingen mening å samle inn disse dataene hvis du ikke noen gang skal rapportere om det eller har noen behov rundt å prøve å administrere disse dataene. Når det gjelder metadataene som er knyttet til ytelse, for eksempel.
Du vet, et godt eksempel er at jeg ikke trenger å bli varslet hvis tjenesten Distribuert transaksjonskoordinator i SQL er nede hvis jeg ikke vil at den skal kjøres i utgangspunktet. Så ikke varsle meg, ikke samle inn dataene mot dem - jeg trenger ikke den informasjonen. Så å ha muligheten til å slå disse tingene av og på er virkelig viktig.
Muligheten også til, når du først har samlet inn dataene, har tilgang til dem ganske raskt - du trenger ikke, du vet, kjøre og massere dataene, manipulere dataene - å kunne gjøre det raskt og effektivt. Og så når du har dataene, er det tydeligvis veldig viktig å kunne forstå det.
Nå er det her, med vårt - med, som for eksempel Diagnostic Manager-produktet, jeg skal vise deg litt i dag - det produktet, vet du, jeg vil gjerne fortelle deg at det produktet kommer til erstatte og være en DBA i en boks. Realiteten er at den krever viss kunnskap om hva miljøet ditt er og hva du prøver å oppnå. Å ha noen, åpenbart, forståelse av rollen til selve DBA er åpenbart viktig.
Det vi prøver å gjøre er å utdanne gjennom hjelpen og gjennom andre metoder. Men du vil alltid ønske å knytte dette til, med noen form for erfaringsnivå eller noen som har kunnskap om hva de skal gjøre når de har mottatt dataene. Og å kunne ha en person som kan stille de riktige spørsmålene til et produkt, og ha den samtalen med dataene, er åpenbart sentralt. Og da åpenbart å kunne gi mening om dataene.
Når jeg har fått informasjonen, kan jeg få det ut til de rette menneskene. Utviklerne mine, operasjonsteamet mitt - uansett hva det måtte være, må jeg kanskje integrere meg med andre produkter og ha krokene for å kunne gjøre det. Dette er alle viktige ting. Og så, selvfølgelig, sist, men ikke minst, hvis jeg trenger å vite mer, å kunne gjøre det. Enten det betyr å slå på noe mer å samle på, eller om det bare betyr å gå litt dypere inn i dataene. Du håper at du, med et verktøy som kommer til å bli, hjelper til med ytelse, får alle de tingene du trenger for å kunne svare på disse spørsmålene.
Den ene tingen som jeg ikke la på her, som jeg tror det er verdt å merke seg, er at du trenger et verktøy som hjelper deg med å skille hva som er normalt og hva som ikke er normalt. Og jeg tror det er en stor en, for du vet, det er massevis av varslende produkter og ting som er der ute, men hvis du får et varsel og varselet er et falsk varsel, gjør det deg ikke ; det er mer bortkastet tid og det vil redusere effektiviteten mer enn det vil hjelpe dem. Så, du vet, det er noen ting jeg vil huske på.
Når jeg snakker om produktet som jeg slags knytter alle disse tingene til i IDERA-produktpakken, er det Diagnostic Manager-produktet som jeg tror har sannsynligvis den viktigste typen egenskaper i det vi snakker her når det gjelder database tuning og ytelse og overvåking og den slags ting.
Folk leter etter bedriftsnivåovervåking; de vil kunne ha tilgang, på en skjerm kunne vite at ting fungerer som de skal være. Eller de vil være i stand til, selvfølgelig, hvis det er et problem, å se hvor problemet er, og så kunne bore ned i det. Virkelig stor del av, tror jeg, hva folk leter etter med disse typer måter du virkelig kan finpusse på på resultatene dine.
Det andre som åpenbart følger med det, er at jeg ikke bare kan operere i dag, og jeg må kunne gå tilbake over tid, enten det betyr å se på spørsmål som kjørte dårlig eller om det betyr, du vet, ser på hvordan verten VM selv oppførte seg med tanke på ressurser. Alle de slags tingene du må være i stand til å gjøre, og du ikke kommer til å sitte der og stirre på konsollen din 24 timer i døgnet, 7 dager i uken.
Hvis du er på ferie eller er midt på natten, eller hva det måtte være, trenger du noe som vil kunne gå tilbake i tid med deg for å kunne si hva som foregikk i tilfelle på den gangen vi hadde et problem. Og å kunne gjøre det, nok en gang, effektivt og raskt og kunne bore ned i det, er definitivt en viktig brikke i forhold til denne diskusjonen. Og jeg vil si det sannsynligvis er noe av det viktigste i forhold til hva folk leter etter. De leter alltid etter det vinduet inn i fortiden, for det er virkelig et im - Du vet, du vil ikke måtte sitte der og vente på at noe skal skje igjen.
Den neste tingen på listen er egentlig bare å knytte seg til det vi snakket om tidligere, med selve spørringsytelsen. Og jeg skal vise deg et par forskjellige eksempler innen Diagnostic Manager-produktet, hvordan vi gjør det, som helt sikkert på slutten av dagen kommer til å gi deg mange alternativer rundt spørsmålene selv når det gjelder hva du vil samles.
Når det gjelder om du er interessert i spørsmål som forårsaker ressursmerter, forbruk av CPU eller forbruk av I / O. Enten det er spørsmål som tar lang tid å fullføre eller spørsmål som bare generelt ikke kan være den verste krenkende når det gjelder ytelse, men som kan løpe så ofte at den rene frekvensen av selve kjøringen kan være et problem. Og selvfølgelig er det en viktig del av det å kunne se trender over tid med disse spørsmålene.
Det er mange forskjellige måter vi kan gjøre det innenfor dette produktet, og jeg tror det åpenbart er en virkelig viktig brikke for de fleste DBA-er. Og selv om du ikke har egne internt utviklede applikasjoner, er det fremdeles hyggelig å kunne gå til programvareleverandørene dine og si: “Hei, vet du hva? Du vet, klokka to på ettermiddagen hver dag når denne jobben tar av, ”eller hva den enn er, “ Det er søknaden din som forårsaker dette, og vi trengte å fikse det. ”Så selv om du ikke har fullført kontroll over selve koden, er det fremdeles hyggelig å vite når det skjer problemer.
Og da, du vet, er den andre delen åpenbart å være mer proaktiv. Å være i stand til å være den første som vet, å kunne forstå når det oppstår et problem. Å ikke bare være i stand til å være den første som vet slik at du kan rette det, men i mange tilfeller, når du trenger, er noe som vil kunne automatisere et svar, også i mange tilfeller. Du kan si, du vet, i stedet for å få en e-post som sier: "Hei, du trenger å ordne dette, " hvis jeg er på et møte eller hvis jeg er, du vet, på veien eller hva det enn er jeg Jeg gjør det, det er tydeligvis veldig hyggelig å kunne si at jeg har noe på plass som vil kunne adressere det på en automatisert måte.
Og hvis det ikke blir adressert på en automatisert måte, i det minste å være den første til å vite, slik at du kan ta korrigerende tiltak eller kontakte noen som kan. Og det er åpenbart store viktige brikker for, du vet, disse problemene du kan støte på når det gjelder overvåking av maskinene dine, forekomstene og analysene i seg selv.
Nå snakket jeg om dette tidligere, som er tingenes fleksibilitet. Jeg kan ikke stresse dette nok, ved å kunne si, du vet, utenfor-boksen, hvis det er noe som ikke blir overvåket, å kunne ha funksjonaliteten i et produkt for å kunne legge disse tingene til overvåkes. Og i den forstand med eksempelet Diagnostic Manager, har vi åpenbart, du vet, WMI-tellere, tellere, SQL Server-tellere, kan du lage dine egne spørsmål.
Du kan til og med, hvis du vil, trekke dataene fra vCenter-miljøet ditt eller ditt Hyper-V-miljø, som et resultat av avstemningen som finner sted og du kan gjøre det på regelmessig basis og trekke disse dataene og kunne se dem. Og snu igjen fra et sted til et annet når du ser på denne informasjonen.
Så det er slike ting som hva jeg ser folk spør om når de snakker om et verktøy som vil hjelpe dem når det gjelder innstilling og ytelse - produktet jeg skal vise deg i bare et den andre er Diagnostic Manager, og den støtter alt fra 2000 helt frem til 2016. Det er spesifikt for SQL Server, og så overvåker vi å håndtere disse tingene. Det er ingen agenter på selve forekomstene som overvåker forekomst.
Det går igjen i å samle inn informasjonen til en liten pris, at vi vet at vi tydeligvis prøvde mer å samle denne informasjonen, ikke bruke mye ressurser også, ikke sant? Vi prøver å utnytte de tingene som SQL Server allerede gir oss og gjøre det bedre, enten det er dynamiske ledelsesvisninger, eller om det er utvidede hendelser, eller hva som måtte være i form av selve samlingen. Å kunne utnytte denne informasjonen og gjøre den bedre er et av våre mandater.
Hvis du nå ser gjennom dette virkelig, vil jeg ikke gå for mye i detalj gjennom arkitekturen, men ha et back-end repository med alle våre historiske data som du kan administrere og du kan oppbevare så lenge som du vil. Du kan til og med velge hvilken type informasjon du vil oppbevare, og hvor lenge. Det går litt tilbake til det, samle inn passende data og la unødvendige data være ute. Hvis du vil beholde spørsmålene i fem dager som kjører og deretter beholde varslene i to år, er det opp til deg og det er fullstendig ditt privilegium når du skal kunne gjøre det.
En rekke forskjellige konsoller med dette produktet. Du har en nettbasert versjon, du har også en tykk klientversjon. Og så det er å ha fleksibiliteten til å hoppe på en nettleser og se hva som skjer, eller hvis du har en bærbar PC hvor du har en dedikert klient installert, vil en av disse tilnærmingene fungere for deg.
Det jeg vil gjøre er å gjøre en rask demonstrasjon. Og jeg vil påpeke - jeg kommer tilbake til dette andre lysbildet her - som vi har lagt til, akkurat som en FYI for de som er kjent med produktet, vi har et nytt tilbud som er Diagnostic Manager Pro. Et profesjonelt tilbud som inkluderer noe vi kaller Workload Analyse.
Og egentlig handler det om å kunne interaktivt se på veldig store tidsperioder og gå fra det, du vet, 30-dagers visning til, du vet, fem-minutters visning i omtrent tre klikk. Og når du kan se piggen i ytelse eller problemet i flaskehalsen som du kanskje kan, kan du se på et veldig høyt nivå, og bore ned til et veldig lavt nivå. Og spesielt det også i dag, det er nytt for produktet.
Men det jeg vil gjøre er bare en første start, og jeg vil snakke litt om det svingete og gå frem og tilbake. Og jeg har tatt opp et eksempel, og jeg kommer til å dele på skjermen min her. Og la oss se … Der går vi. Skjermen min. Og la meg få vite det, folkens, at dere kan se det.
Eric Kavanagh: Der går du.
Bullett Manale: Alt går bra der borte? Ok. Så hva du ser på akkurat nå - og dette er Diagnostic Manager-produktet - og jeg ville bare gi deg en slags demonstrasjon på høyt nivå av hva som skjer her. I dette spesielle eksemplet viser vi deg spørsmålene som er knyttet til venting. Og så når jeg snakker om å kunne gå frem og tilbake, bore dypere og svinge, så er det - dette synet her er et godt eksempel på det. Jeg kan gå fra en tidslinjevisning som vi ser her, som kommer til å vises nå. I vårt tilfelle ser vi på ventene selv og kategoriene av ventene selv. Vi kan se utsagnene som er knyttet til disse ventene, vi kan se applikasjonene.
Legg merke til at den er på en tidslinjevisning her, så jeg kan identifisere den informasjonen lineært basert på når problemet skjedde, men så igjen, hvis jeg bare vil, en gang til, svinge, og jeg sier: "Du vet hva, la oss se på dette fra et annet perspektiv, ”la oss gå videre og se på dette ut fra et synspunkt:“ Jeg vil se spørsmålene eller ventene eller applikasjonene som forårsaker mest smerte for meg, og rangere dem. ”Og det er det vi ' kommer til å se etter "spørring venter etter varighet." Nå ser vi applikasjonene i seg selv som forårsaker mest smerte, eller ventene.
Og så, her er den delen som virkelig er den viktigste delen, å være i stand til å isolere disse tingene. Jeg kan se at dette NoSQL-programmet starter av her. Det gir meg en god mengde ventetid, langt inne i 25 sekunders ventetid i løpet av dette 30 minutters vinduet som vi er boret inn i. Og jeg kan deretter isolere den applikasjonen, og jeg kan se utsagnene, i dette tilfellet, som direkte påvirker denne spesielle forekomsten.
Og dette er bare ett eksempel på hvordan du vil kunne identifisere en flaskehals, kunne rangere informasjonen og kunne prioritere problemene som må løses først. Dette er alt du må tenke på. Du kan fikse problemer hele dagen, men hvis du fikser problemene som er nederst på listen som skal fikses, kaster du bort tiden din. Du har en mulighetskostnad knyttet til det.
Jeg vil gi deg et annet eksempel, og dette er litt av et annet eksempel. I stedet for å spesifikt peke på et problem eller peke på et område, trenger du også et verktøy som vil kunne hjelpe deg i bred forstand, ved å kunne si "Hei, har vi hatt noen problemer?" Eller "Er er det ting jeg kan gjøre for å forbedre ytelsen? ”og for å ha noe bak kulissene, se på hva som skjer. Og i dette tilfellet kan dette være relatert til konfigurasjonen; det kan være relatert til, du vet, måten helsen til selve instansen blir administrert på. Og også, selvfølgelig, ytelse ting også.
Hvis jeg går til denne analyseknappen her, er det jeg skal vise deg at vi i dette produktet også har en slags proaktiv liste over ting som kan utføres i et rangert format som i det vesentlige vil gi deg innsikt inn på de tingene som sannsynligvis vil gi deg en økning i ytelsen din i den forekomsten, eller en økning i helsen til den forekomsten. Og det er i et rangert format i den forstand at du har den muligheten til å se hvilke som er mer sannsynlig å forbedre ytelsen din spesifikk for en bestemt type problem som er identifisert.
Når jeg ser på disse tingene og identifiserer dem, ser jeg ikke bare at jeg har et problem, og i mange tilfeller har jeg også et skript som kan bygges automatisk for å løse dette problemet. Men i mange av disse tilfellene har vi også eksterne koblinger som refererer til typen problem vi opplever, og hvorfor vi også gir denne anbefalingen, slik at du får det pedagogiske aspektet ved ting. Det synes jeg nok en gang er veldig viktig når du snakker om å fikse problemer.
Jeg vil ikke bare følge disse anbefalingene blindt, jeg vil forstå hvorfor disse anbefalingene blir fremsatt. Og jeg er kanskje en senior DBA som har gjort dette i 30 år, og jeg trenger noe som kommer til å vite, sjekk - eller prikke i'ene og krysse t-ene, i dette tilfellet - eller kanskje jeg er en junior DBA og Jeg trenger litt hjelp med å forstå disse problemene når de skjer, og hvorfor disse anbefalingene blir fremsatt.
Som sagt skal jeg bare ta deg gjennom et par forskjellige deler av produktet. Dette verktøyet har eksistert, vet du, det har eksistert siden 2004, 2003. Og det har virkelig mye utvikling lagt inn i det, mye informasjon, så det ville ikke være fornuftig å prøve å vise deg alt her. Men jeg tror at en av tingene som er verdt å merke seg, er at når vi går inn og begynner å snakke om alle tingene du kan overvåke og alle tingene du kan varsle om, igjen, når vi går tilbake til den fleksibiliteten i tingene, her er en liste over alle varene vi overvåker.
Nå betyr det ikke nødvendigvis at jeg vil vurdere at disse tingene er i en varslingstilstand hvis de kommer ut av kløften når det gjelder terskelen, slik at du kan slå disse tingene av og på. Dette går tilbake til det, “Hei, jeg trenger bare å gjøre visse ting for bestemte beregninger. Jeg trenger bare å, du vet, varsle om visse problemer. ”Og være i stand til å sørge for at vi ikke vil, du vet, mette deg med en haug med falske positiver. Ikke bare har du muligheten til å slå disse tingene av og på, men i mange tilfeller vil du legge merke til at vi også tilbyr det normale normalitetsbåndet når det gjelder hver enkelt beregning. Så hvis jeg ser på dette, i dette tilfellet, en grunnlinje, vil jeg legge merke til at terskelen sannsynligvis er høyere der de er akkurat nå.
På den andre siden av mynten er det, hva hvis jeg har en forekomst av SQL, der jeg sporer noen beregninger og disse beregningene, uansett grunn, er tersklene jeg har satt feil? Med andre ord, tersklene er uklare midt i der baseline faktisk sitter, noe som betyr at hvis jeg har et varsel knyttet til den terskelen, vil jeg sannsynligvis få et varsel for noe som er en normal hendelse. Og i slike situasjoner kan vi gi deg den innsikten også overalt.
For alle beregningene for denne spesielle forekomsten, kan jeg se de terskler som sannsynligvis sannsynligvis vil vise et falskt positivt her når det gjelder hva som er normalt og hva som ikke er. Dette kommer til å være noe som vil bli betraktet som en mer vanlig bruk ting på minnesiden, og hvis jeg ønsket å øke den terskelen, kunne jeg det, men det er en slags ide med baselinjene.
Og den kule tingen med Diagnostic Manager-produktet når det gjelder grunnlinjene i seg selv er en mulighet til å angi flere baselinjer. Og du kan spørre: "Hvorfor vil jeg gjøre det?" Og svaret er vel, hvis du har et vedlikeholdsvindu som går fra, la oss si fra midnatt til klokka 04.00, hvor du virkelig beskatter ressursene dine, bruker du virkelig ressursene så mye som mulig, så vil du kunne skifte igjen, og du vil svinge litt og si: "Se, vi kommer til å endre terskelverdiene for det." Og vi kan faktisk justere tersklene våre dynamisk, spesielt etter hvilken grunnlinje vi tilfeldigvis befinner oss i, basert på tidspunktet på dagen eller dagen i uken og så videre, slik det er. Så det vil da dynamisk justere disse tersklene for oss.
La oss ta et skritt igjen. Når vi har identifisert disse tersklene, når vi har gått gjennom, og når det gjelder å sette opp varsler og varsling og bli kjent med disse situasjonene som kan skje, er det en gang til viktig med fleksibilitet her. Du ønsker å kunne varsle i spesifikke situasjoner. I andre situasjoner kan det være lurt å sende en e-post til noen andre, kanskje du ønsker å kjøre et PowerShell-skript, kanskje du vet at listen fortsetter.
Jeg vil kanskje integrere meg med noe via SNMP-felle eller til og med direkte med for eksempel SCOM. Poenget er at du har fleksibilitet til å gjøre det, og du kan sette opp hvilke typer forhold som kan garantere det, enten det er en veldig omfattende tilstand - du vet, min CPU og minne eller hvilke ressurser som er - i alle tilfeller, eller kanskje jeg har en veldig spesifikk type ting jeg vil overvåke for fordi når jeg opplever at vi er i strid, vil jeg kjøre et veldig spesifikt og regissert skript mot det problemet. Så det er her du kan gjøre den slags ting inne i Diagnostic Manager-produktet, bare du vet når det gjelder varsling og varsling, og være i stand til å være fleksibel fra det synspunktet.
Nå vil jeg ikke gå gjennom alt varselet og alt det gode. Jeg ville snakke om rapportene. Og igjen, å kunne ta informasjonen og utnytte disse dataene på en rekke forskjellige måter - og dette går igjen til samtalen med dataene dine. Og mange mennesker, når de først ser dette produktet, tenker de, “Vel, jeg kommer til å ha et verktøy som kommer til å varsle meg når det er problemer. Det er det jeg trenger. ”Og virkeligheten er at de trenger det verktøyet, men den andre siden av det er, hvis de virkelig - de trenger også et verktøy for å hjelpe dem å ta beslutninger, og de kan utnytte denne informasjonen som vi samle inn navnet på ytelsen og også i navnet på varsling, for å kunne hjelpe deg med å ta beslutninger på veien videre.
Du vet, et godt eksempel ville være vekstprognosene mine i databasen. Hvis jeg har en spesifikk database som vokser, kan jeg peke på den databasen eller til og med flere databaser for å kunne se hva vekstnivået er. Vi viser deg ikke basert på hva du vet hva det er i dag; det kommer til å spå det basert på tidligere vekst vi har opplevd.
Hvis jeg har noen få databaser her - som jeg tilfeldigvis har tenkt deg det - kunne jeg gå inn og si: "La oss ta det siste, du vet, årets verdier med data, la oss korrelere det etter måned og i et utvalg rate of months, la oss gå foran og se hvor mye vekst vi kommer til å se i løpet av de neste tre årene, eller 36 enheter. ”I så fall kan vi veldig raskt svare på det spørsmålet. Prøv å gjøre det på egen hånd, ikke sant? Prøv å gjøre det på så mye tid som jeg gjorde det på egen hånd. Det vil ta deg en stund.
For å til og med stresse videre, la oss ta en ny rapport, som er min toppserver-rapport. Se for meg at jeg har hundre produksjonsforekomster, som i dette tilfellet ikke gjør det. Men hvis noen kommer til meg og sier: “Jeg trenger at du forteller meg - vi kommer til å legge denne nye databasen der ute for denne fantastiske nye applikasjonen; det kommer til å endre alt slik vi kjenner det; det kommer til å gjøre livet så fantastisk. Åh, forresten, databasen i seg selv blir virkelig I / O-intensiv, eller den vil bli CPU-intensiv, eller virkelig minneintensiv …, ”uansett hvilken utfylling det er, jeg vil kunne se, av alle mine produksjonsforekomster, hvor er det fornuftig å legge den databasen? Og jeg kan rangere alle instansene mine mot hverandre når det gjelder betinget type, enten det er CPU, minne, disk eller hva tilfellet måtte være. Og poenget her er å kunne svare på det spørsmålet raskt og effektivt og ta den riktige beslutningen i stedet for å gjette når du gjør det - det er åpenbart virkelig viktig, og du trenger noe som vil hjelpe deg.
Og når vi snakker om analyser, kan det variere fra hva vi snakker om med kapasitetsplanlegging til, du vet, varsler som du kjører på hver dag som kan håndtere CPU, som samt selvfølgelig spørsmålene i seg selv, om det er blokkering og så videre og så videre.
Et annet eksempel på dette ville være, hvis jeg gikk til administrasjonsseksjonen herover - faktisk, tar jeg det tilbake, den varslende delen her borte - spørrer depotet for vår historiske informasjon om ting som har skjedd i fortiden. Har jeg blokkert det som skjedde i produksjonsmiljøet mitt? Jeg vet ikke, la oss finne ut av det.
Jeg kan gå tilbake til produksjons-taggen min, og jeg kan si, for alle produksjonsforekomstene mine, gitt uansett tidsperiode, for hvilken som helst beregning jeg vil identifisere. Hvis jeg har gått i en varslingstilstand, la oss si i tilfelle blokkering ved telling, ikke ved sekunder med blokkering, og jeg kan gå tilbake og, i dette tilfellet, noen måneder, hvis jeg trenger å - eller i dette tilfelle, en måned - og jeg kan se at det blokkeres. Jeg kan se når det startet, jeg kan se når det endte, og jeg kan bore ned i noen av disse trekkintervallene hvis jeg trenger det, for å se detaljene i den blokkerende hendelsen i seg selv. Du må kunne ha noe som er veldig raskt, kunne finne det du trenger og lete etter i stedet for å snurre mange sykluser for å gjøre det i. Og det tror jeg også er viktig.
Den siste tingen jeg vil vise deg - og viser deg dette produktet, Diagnostic Manager-produktet - er at vi, som jeg har nevnt før, har gått inn og vi har lagt til en annen komponent til SQL Diagnostic Manager Pro tilbud. Og det er arbeidsbelastningsanalysekomponenten. Og dette er en nettbasert versjon av dette, i dette tilfellet som vi viser deg her. Men poenget her er at dette lar deg se på et veldig bredt tidsrom eller et veldig spesifikt tidsvindu, og fra, du vet, et par klikk på å kunne se koden direkte relatert til problemer som kan ha skjedd .
Som et eksempel på det, hvis jeg ser på en fire ukers visning, her kan jeg se, akkurat her, alle piggene når det gjelder databasene og ytelsen til disse databasene, og hvor vi så venteaktivitet på disse databasene. Nå, og du kan se, hvis jeg ser en pigg her, er fordelen med dette verktøyet bare å kunne fremheve den lille baren der. Og når jeg gjør det, endres alle tingene her borte. Vi ville være i stand til å se databasene, vi ville være i stand til å se alle kommandoene er knyttet til det som ligger bak den linjen.
Det samme hvis jeg sa: "La oss se på de siste fire timene, " i stedet for de siste fire ukene. Det kan jeg fortsatt gjøre. Jeg kan fremdeles fremheve den perioden, og deretter derfra - her er, igjen, her er mine pivotpunkter - alle disse tingene her kan jeg koble til. De øverste SQL-setningene kan jeg se spørsmålene i dette tilfellet som forårsaket ventetid som var relatert til CPU-forbruk. Bare ved å bore inn, kan jeg se spørsmålene her - whoops - og jeg kan også se programmene og hva som ikke er forbundet med dette.
Du får mye innsikt her, og ikke bare det, men du kan se at når du kommer ned på kommandonivå, kommer det til å fortelle deg ting. Det vil fortelle deg om det ser tunge operatører, og deretter kan du se utførelsesplanene. Dette tar litt tid fordi det er ganske omfattende å laste denne. Men poenget her er at du har mange forskjellige måter å se dataene på, se hva det er du leter etter, og så åpenbart være i stand til å ta grep derfra som du trenger, så og denne tar lenger enn det pleier å gjøre, så jeg vil la det være der.
Og så med det sagt, jeg kommer til å gi det tilbake. Og forhåpentligvis var dette en god demonstrasjon av hva slags ting vi snakket om. Og som jeg sa, selve produktet som vi brukte til å gi disse eksemplene har eksistert ganske lenge, og så mange andre ting vi kunne snakke om og vise deg, men hvis dette er noe som er av interesse av deg, kan du alltid gå ut på hjemmesiden vår og laste ned den og leke med den.
Eric Kavanagh: Og jeg elsker at du viser all denne detalj. Hvis du går tilbake et par skjermer - til og med denne skjermen er ganske bra. Fordi det er så mange forskjellige måter å visualisere hva som faktisk skjer, og jeg tror dette er en av de mer undervurderte aspektene ved databehandling i disse dager. Det er absolutt et databasemiljø som jeg på mange måter har denne halve spøken jeg sier: "Vi lærer fortsatt å snakke silisium." Vi lærer fortsatt å forstå hvordan vi ser hva som skjer, og til ditt poeng, som var veldig godt tatt, må du ha den samtalen med data for bedre å forstå hva som skjer, hvorfor ting går sakte, fordi det er så mange mulige problemer. Og selvfølgelig har IDERAs en rekke forskjellige produkter, hvorav de gamle Precise-produktene som jeg tror kan være komplementære til dette.
Men kanskje Robin, jeg vil kaste det over til deg for et par spørsmål, og deretter Dez, et par spørsmål fra deg, og så kanskje noen fra publikum, ikke vær sjenert. Send dem inn nå.
Bullett Manale: Robin, er du på stum?
Robin Bloor: Ja. Det er i orden, jeg bare tar meg av demp. Jeg må si, det er utrolig - det som faktisk slo meg som mest dramatisk med dette verktøyet, fordi det virkelig - spesielt gitt det faktum at det er ganske åpenbart at en hel serie dimensjoner du bare ikke gikk inn på - det som faktisk, Jeg tror, det mest imponerende med dette er at det må være en virkelig, virkelig god måte å trene en DBA på. Du vet, det er - så når du først skal utføre databasearbeid og faktisk ikke vet mye om hva som faktisk skjer i en database, er det faktisk veldig vanskelig å få en forståelse. Så brukes dette mye, spesielt for trening? Jeg ville brukt den.
Bullett Manale: Ja. Jeg mener, når du sier trening, så mener du litt som en trening i gang som en DBA-type ting, ikke sant? I form av…
Robin Bloor: Ja, ja, ja, ja. Et læringsverktøy. Du vet, a.
Bullett Manale: Ja, jeg vil helt sikkert tro at det er tilfelle, og enda mer at vi har lagt til dette, analyser-komponenten som vi viste deg tidligere, som har alle anbefalingene som er knyttet til det. Men jeg tror helt sikkert at du vil finne, innen hjelpen og mange forskjellige områder i produktet, det gir deg, vet du, mye innsikt. Mye informasjon.
Og virkeligheten er, som jeg sa, du kan bruke dette hvis du ikke er en DBA. Du vil sannsynligvis finne deg selv gjennomføre noen Google-søk og sånne ting, bare for den generelle kunnskapen om hva de fleste DBA-er har, men du kan korrelere dette, og det vil definitivt hjelpe deg i form av: "Hei, vet du, hei hva er det denne saken som kalles fragmentering? ”eller, “ Hvorfor kjører denne spørringen 6000 ganger? ”Jeg mener, fordi disse tingene vil bli ført opp til deg og de vil boble opp, og du vil se dem. Du vil se at du vet hva som er normalt og hva som ikke er det. Du vil se de tingene som er piggende og de tingene som ikke er det.
Som regel prøver vi å sette opp denne tingen som når det gjelder beste praksis. Så når du peker på et eksempel, vil det vise deg tingene som er identifisert som utenfor beste praksis. Jeg mener, selvfølgelig, du vet, virkeligheten er at beste praksis er beste praksis, og det er ikke alltid det er virkelig praksis. Men, du vet, det vil vise deg utleggerne, selv fra det første punktet at du installerer det og peker det til en forekomst.
Og derfra kan du slags flytte sammen, slik du nødvendigvis nødvendigvis må fikse problemene og identifisere om det virkelig er et problem eller noe som vanligvis skjer på en daglig basis. Og da, fordi du har mye informasjon å hjelpe og anbefalingene, ja, absolutt.
Robin Bloor: OK. Og et annet spørsmål - men jeg er sikker på at svaret på dette er veldig raskt - er at du har granulariteten til å gå helt ned til den enkelte spørring og individuelle tidspunkt og se fra den dimensjonen.
Bullett Manale: Visst, ja. Avhengig av hva du vil gjøre, kan du se på et minutts tidsvindu, eller du kan se på et tre-dagers tidsvindu eller, du vet, et tre-ukers tidsvindu. Og du vet, som jeg sa, det kommer an på hvordan du vil se på dataene, og også hva du vil samle inn. I noen tilfeller samler vi bare spørsmålene som når en terskel som du har identifisert. I andre tilfeller kan vi samle, du vet, alle spørsmål som forårsaker ventetid.
Men du har også muligheten til å si: "Se, de terskler som jeg identifiserte, kanskje det bare er for skriver, eller kanskje det bare er for leser, eller kanskje det bare er for CPU." Så forutsatt at det har overgått den terskelen, så er det hva du vil samle på. Så uansett hvilken tidsramme du vil se på, vil du kunne se spørsmålene som er krenkende, basert på hva du anser som krenkende.
Du har mange forskjellige måter å se på dataene på. Du kan se på det i en samlet visning for å se, du vet, spørsmålene som - hvor mange spørsmål bak kulissene som startet, kontra, du vet, hver eneste hendelse av den spørringen som startet, for å se på et mønster, hvis du vil, for å se om det stadig blir verre.
Men for å svare på spørsmålet ditt, kan du definitivt vise til hvilken tid du vil. Du har denne tingen som heter History Browser - og jeg brukte litt til å bruke den - men i utgangspunktet uansett hvilket tidspunkt du velger, uansett hvilken dag i kalenderen du velger, kan du gå direkte til det tidspunktet.
Akkurat nå ser jeg i 15. november klokken 19:05, og vi kan se på spørsmål som er spesifikke for den tiden. Hvis jeg hadde noen som kjørte dårlig gitt det tidsvinduet, ville vi kunne se på øktdetaljene som var spesifikke for det tidsvinduet for å se hvilke økter som kjørte. Jeg mener, det er en hel mengde data her, og som sagt, den vanskeligste delen, egentlig, er kanskje 30 minutter å leke med konsollen og finne ut hvordan du gjør dette.
Men når du først er klar over at de fleste dataene her er i dette båndet, og at de er delt av disse fanene, og hver fane har sitt eget sett med dynamisk skiftende knapper som vises hver gang du klikker på det, så om du ser på ekte- tidsting eller sånt som skjedde forrige uke, det er den samme prosessen. Det er i grunnen, jeg ser akkurat nå 15. november, men jeg kan like gjerne se på sanntid bare ved å klikke på den knappen. Og jeg skal samhandle med dataene på samme måte.
Men for å svare på spørsmålet ditt, ja, det er mange forskjellige måter å vise historisk informasjon på, og det gjelder også selve spørsmålene.
Robin Bloor: Jeg skjønner. Det er veldig imponerende. Og jeg elsker det faktum at vinduene synkroniseres, selv om det på en måte er blitt ganske nødvendig i alt som har å gjøre med sanntidsdata i dag.
Bullett Manale: Ja. Sikker.
Robin Bloor: Her er bare et informasjonspunkt som jeg faktisk ikke vet svaret på. Som tilbudene dine - SQL Server og skyen - kan du peke på skyen under Ratio?
Bullett Manale: Du kan. Du kan peke dette under skyen. Når du faktisk legger til forekomster, vil det spørre deg om det er RDS eller Azure. Nå vil det være noen begrensninger basert på hva som blir utsatt for oss fra skyen, så det kan være en - det er litt forskjell i forhold til hva vi kan overvåke, ganske enkelt fordi instrumenteringen, i noen tilfeller, ikke er er ikke der for oss å samle, basert på hva Microsoft utsetter.
Hvis det er noe sånt som du vet infrastruktur som plattform, som du vet, eller EC2 eller noe sånt, er det ikke noe problem i det hele tatt. Vi får alt. Og mens vi jobber med Microsoft og vi jobber med Amazon; vi jobber for å avsløre denne informasjonen mer detaljert. Men absolutt ja, vi støtter de miljøene.
Robin Bloor: Ok, det er interessant. Vel, jeg vil gi Dem, som jeg er sikker på at vil kaste deg spørsmål fra en annen retning.
Bullett Manale: OK.
Dez Blanchfield: Takk. Jeg har to veldig raske til deg. Jeg tror, du vet, den første er, skalaene, du vet, jeg tror at en av tingene som slår meg er at forestillingens generelle tema har en tendens til å være noe som vi tenker på når vi blir veldig store, veldig store, veldig stor og bred, og terabyte med data. Når jeg så på demoen, slo det meg som dette er noe som faktisk gjelder til og med de veldig små miljøene, som bare å få prestasjonstreff.
Hva slags spredning ser du i bruken av dette, og tror du det er, vet du, tror du det er et verktøy som har det bra, vet du - i mitt sinn gjør det det, så jeg tror det er et ja - men jeg er bare opptatt av å se hva du ser. Mindre organisasjoner har de samme samtalene og ser etter et verktøy for å gjøre dette, eller er det virkelig noe i den større enden av byen?
Bullett Manale: Det er morsomt - det er et godt spørsmål. Det er litt av en blanding, men jeg vil si at vi har mange små kunder. Og når jeg sier små kunder, mener jeg, du vet, kjøp av ett til fem eksemplarer for å lisensiere for å administrere. I noen tilfeller har de kanskje 30 forekomster av SQL, og de bryr seg bare veldig om de fem virkelig, veldig viktig nok til å investere i et verktøy som dette, for de fem tilfellene.
Men realiteten er at selv de mindre butikkene har en håndfull SQL-servere der ute. I de fleste tilfeller, eller i mange tilfeller, er den lille butikken veldig, veldig avhengig av disse databasene, på grunn av, du vet, hva de gjør. Og slik gjør de det ikke, de kan ikke la det gå ned. De kan ikke, du vet, de må ha et verktøy.
Den andre siden av den mynten er at de i noen av de mindre butikkene ikke har dedikerte DBA-er, så fyren som er den smarteste fyren i rommet eller den mer tekniske fyren i rommet ender opp med å bli den tildelte DBA. Og i den situasjonen er de definitivt på jakt etter litt hjelp, og dette verktøyet vil åpenbart hjelpe dem i den forbindelse også.
For de større miljøene dine, som jeg tror det var Dez som nevnte det - eller Robin, jeg er ikke sikker - men du vet, de større miljøene, du vil bli overrasket over hvor mange DBA-er de har, jeg mener, vi ' snakker du enormt mange forekomster av SQL, og du har bokstavelig talt håndfull DBAer som har til oppgave å være ansvarlige for dem. Og fra det perspektivet, de fyrene, du vet, de leter etter litt hjelp fordi de ikke har ressursene virkelig nok til å virkelig hjelpe dem, og slik at et verktøy vil hjelpe til å oppveie noe av det.
Og så ser vi også det der, du vet at du har tre karer som styrer 200 forekomster. Og så kan du tenke deg logistikken til det hvis du ikke har et verktøy som dette, for å prøve å finne ut når det til og med er et problem. Det vil ikke være en proaktiv måte, jeg kan forsikre deg. Så forhåpentligvis svarer det på spørsmålet ditt. Yeah.
Dez Blanchfield: Det gjør det, ja. Det slo meg - og jeg tror Robin slags hisset på det - men du vet, den slags løfter du beskriver da du gjorde demoen, mener jeg, de er ikke eksklusive for veldig store miljøer. Du kan kjøpe en vanlig plattform som er designet for en ting og legge den inn i et delt databasemiljø for noe annet, og det vil bare straffe hele miljøet.
Den andre tingen som slo meg - det er ikke så mye spørsmål, bare en observasjon, men jeg vil føre det til et spørsmål, og det er det, du vet, når organisasjoner allerede har investert i infrastrukturen og deres plattformen og databasen deres og serverne og infrastrukturen rundt det, og de kommer til å kjøpe et produkt, uansett hva det måtte være - en HR, en ERP, et BI-verktøy - de har allerede slags gjort en ganske stor investering.
Hva slags respons ser du når du har en samtale med folk, og de er klar over at de har fått et resultatproblem, men de føler at nå må de gjøre en ny investering for å komme til det? Er det et poeng der de skjønner når du først har demonstrert det at de denne tingen som en no-brainer, og det er ikke så mye salgshøyde, men det er mer et epifanie. Det er bare, du vet, “Vi kommer øyeblikkelig til å se utbytte av dette.” I motsetning til å bare måtte selge produktet? Det virker som om det selger seg, og avkastningen bare hopper av siden.
Bullett Manale: Ja, og det er morsomt at du sier det fordi det som mange ganger vil skje er at noen vil komme, som en DBA eller til og med selgerne, og de vil si: “Hei, disse karene vil se et, liksom, et ROI-ark på dette. ”Og mer som a, noe på papir som vi ville sendt til dem. Og demoen er alltid 10 ganger bedre, spesielt fordi du kan gjøre det med DBAene selv, fordi–
Dez Blanchfield: Ja.
Bullett Manale: Som du sa, selger produktet seg selv. Det er veldig vanskelig å legge en avkastning på et stykke papir og si: "Ok, hvor mange klikk har en DBA, du vet, klikker du i løpet av en time?" Når det gjelder sikkerhetskopier, du vet, eller hva tilfellet måtte være, du vet? Og prøver å legge det på et papir, er det virkelig vanskelig å gjøre det. Men når du får noen og viser dem produktet, og de ser det, er det akkurat det du sa.
Folk innser verdien av det. For ikke bare hjelper det dem å forstå og ta bedre beslutninger, men det er også, det hjelper, vet du, dem å ikke være den dårlige fyren. De kan være de første som vet; de kan rette opp problemet før det noen gang er identifisert at det var et problem.
Den andre delen av det er at du vet, som DBA, enten det er en, du vet, ekte eller oppfatning - og jeg tror det er oppfatning - du eier prestasjonsproblemene, egentlig. Du er fyren som får fingeren rettet mot deg når forestillingen går ned, og realiteten er at det kan være utvikleren som virkelig forårsaker problemet.
Å ha et verktøy for å kunne si: "Hei, dette er ikke problemet mitt, jeg trenger å kunne ta dette til utvikleren, og de må rette opp dette, " eller, du vet, i tråd med disse linjene. Det er en fin måte å kunne ha noe i arsenal av for å kunne si: "Det er her det virkelige problemet er." Du vet?
Dez Blanchfield: Ja. Den siste for deg, og det som slår meg, og ser på dette mens vi gikk gjennom det, var at vi ofte har spesielle ferdigheter når vi tenker på ytelsesproblemer. De kommer med 20 års erfaring, de ser på den, og de slags, du vet, den klassiske vitsen til fyren som går inn i verkstedet og har en bitteliten hammer og treffer maskinen på rett sted og deretter sier, "Det er en løsning på $ 15.000, " og folk sier: "Vi betaler ikke for det, " vet du, fordi det er fem minutter av arbeidet. Og han sier: "Vel, det tok fem års erfaring å jobbe med fem minutter og det sparte deg millioner."
For meg virker det som om du vet at det er en midtprosess av at folk går gjennom denne tingen og sier: "OK, ta med de spesielle ferdighetene, fikset problemet, det vil forsvinne." Men det de har gjort da er de har nettopp lagt en Band-Aid på det, ikke sant? I motsetning til et scenario der, fra hva jeg kan se her, hvor når dette går inn, ja, de kan ha adressert noen ytelsesproblemer som de trodde de hadde opplevd, men det ser ut for meg, akkurat da, bare å ha denne 24 / 7 slags, du vet, sett med øyne som ser på miljøet i sanntid.
Du ender virkelig opp med å komme vekk fra scenariet med at DBA-er blir våknet klokka fire om morgenen fordi rapporter kjører. Er det tilfelle - og kanskje det er retorisk - men er det sånn at folk raskt går over fra å lete etter å investere i et produkt for å få det til å løse et bestemt problem, men da blir det generelt bare en del av DNA?
Bullett Manale: Ja, og det varierer fra sted til sted, men jeg mener, jeg har noen folk som opprinnelig kjøpte produktet, som for eksempel i 2006, og de har vært på tre forskjellige jobber hos forskjellige selskaper, og de har gått inn, og når de går til det neste selskapet, markedsfører de dette som noe å få fordi de har en arbeidsflyt. Og kaller det det, jeg hater å kalle det det, men, du vet, at arbeidsflyten involverer dette produktet, og de er vant til det fra dag til dag, og det hjelper dem, og slik at de ikke vil lære noe nytt.
Men absolutt. Jeg mener, mesteparten av tiden at vi får folk til å laste ned dette produktet, er det ikke fordi de har et budsjett og at de skal ut, og de sier: "Hei, vel, vi har dette ytelsesbudsjettet, vi må gjøre et bevis på konsept, og vi må gå inn og finne ut, gjøre en evaluering og alt det der. ”Det som vanligvis skjer har at de har et problem på en forekomst av SQL, og de leter etter hjelp til fikse problemet. De går og laster ned verktøyet vårt, de får problemet løst, og så innser de at dette, selve verktøyet kommer til å gjøre mer enn bare å fikse problemet de hadde den gangen, at det faktisk ville hjelpe dem å forbedre den generelle ytelsen og forhindre at andre problemer skjer og går fremover. Og det er helt sikkert. Og du kan definitivt fortsette å bruke dette verktøyet til å stille inn miljøet kontinuerlig, fordi du alltid vil kunne se ikke bare hva som skjedde akkurat nå, men hva som skjedde forrige uke, forrige måned, i fjor, og sammenligne det med hva som skal skje i morgen. Du vet? Den typen ting.
Dez Blanchfield: Ja.
Bullett Manale: Så, helt sikkert.
Dez Blanchfield: Perfekt. Så du har nevnt, du nevnte noe om - jeg skal bare pakke sammen før jeg gir tilbake til Eric for å lukke. En av tingene jeg alltid er interessert i er, vet du, hvordan får folk tak i det? Du nevnte last ned den. Hva er 30 sekunders sammendrag av hvordan de får tak i det, få en kopi, snurre den opp og leke med den, og hva de kanskje trenger infrastrukturmessig, bare for å få et eksempel.
Bullett Manale: Så det kommer til å bli, du går til IDERA (idera). Com. IDERA.com er selskapet, og hvis du treffer det nettstedet - og jeg faktisk kan vise deg det her - vet jeg ikke om jeg fortsatt deler skjermen min, men hvis du går til Produkter-siden, går du til Diagnostic Manager-kobling, det vil være en liten nedlastingsknapp, og du kan bare laste ned byggingen etter at du har fylt ut informasjonen din. De ber deg om 32- eller 64-bits byggingen, og du er på tur til løpene, som de sier.
Dez Blanchfield: Og vil den kjøre på en bærbar PC for noen å leke med den, eller trenger de å laste den inn på en server et sted?
Bullett Manale: Nei, nei. Det jeg viste deg i dag, kjørte faktisk fra den bærbare datamaskinen. Nå har den bærbare datamaskinen min 32 spillejobber og 8-kjerners prosessor, men det er fremdeles en bærbar PC. Men det trenger ikke nødvendigvis å ha så mye ressurser, for å svare på spørsmålet ditt. Evalueringen i seg selv er god i 14 dager, men du er mer enn velkommen til å gi den en lengre prøveperiode. Hvis du bare ringer oss, kan vi utvide det for deg hvis du vil.
Dez Blanchfield: Jeg tror det burde være noe å ta bort, fordi jeg absolutt kommer til å gjøre det. Jeg tror, ut fra tingenes utseende, ser det ut til at jeg er en no-brainer å laste ned den og leke med den. Gå sannsynligvis til et av miljøene dine, og se bare hva du kan se, for jeg mistenker at - som alt jeg har sett i en databasebakgrunn de siste 20 + årene, som aldrer meg - når du først har sett hva som er under hette, det er utrolig hva du innser at du kan fikse raskt og bare få lite gevinst i ytelsen.
Kjempebra, takk for demoen. Det var virkelig flott. Takk for hele tiden for å diskutere spørsmålene.
Bullett Manale: Du er velkommen. Takk for-
Dez Blanchfied: Eric, jeg kommer til å gi deg tilbake.
Eric Kavanagh: Ja, vi har et veldig godt spørsmål fra publikummet. Du snakket litt om dette i presentasjonen din, og jeg tweetet faktisk om dette fordi det var et så flott sitat. Du sa at du ikke vil bruke et verktøy for å overvåke ytelse som påvirker ytelsen din negativt.
Bullett Manale: Rett. Det er riktig. Det er slags en viktig del av et ytelsesovervåkningsverktøy, fordi det ikke forårsaker ytelsesproblemer. Helt riktig.
Eric Kavanagh: Akkurat. Vel, det er som de darned - det er som antivirusprogrammer som bare kan ødelegge systemer. Jeg mener, jeg har brukt en rekke forskjellige teknologier for kringkasting der antivirusprogrammet starter og vil avkutte strømmen din. Så det er ting som skjer som du ikke forventer, men spørsmålet, det gjelder den spesifikke kommentaren du kom med. Og hva slags fremføringstreff ser du? Er det to prosent, er det fem prosent, er det en prosent? Har du noen tall du kan kaste på oss?
Bullett Manale: Vel, jeg mener, utfordringen med dette spørsmålet er at du vet en del av diskusjonen vi snakket om tidligere. Jeg kan gi deg det - det er vanligvis rundt en til tre prosent, for å svare på spørsmålet ditt. Men det er mer forklaring som jeg tror vil være nødvendig, det er, vi gir deg mange måter å kunne fortelle verktøyet hva du vil overvåke, ikke sant? Og så går det tilbake til det. Vel, det kan være lurt å få et utvalg av hvert spørsmål som kjører. Så jeg vil ha et verktøy som er fleksibelt nok til å kunne slå det på slik at jeg kan se det.
Og så, en del av fleksibiliteten inkluderer, vet du, det koster det. Hvis jeg trenger å samle inn mer data fordi jeg vil ha et utvalg av alle spørsmål som kjøres i løpet av det siste, vet du, 20 minutter, kan jeg slå på det, og det kan gjøre det. Og så, men generelt sett, ja, en til tre prosent er det vi ser, når det gjelder overhead. Men det kommer til å variere, og det meste av dette vil være avhengig av tingene du slår på og slår av, i forhold til tersklene dine, hvor mye data du vil samle inn, pollingintervaller, alle den slags ting som binder seg til at.
Faktisk, hvis du går ut i selve forekomsten du administrerer, er en av tingene du ser, at vi har flere valgperioder som du kan spesifisere. Og det er rett og slett fordi vi vil, du vet, jeg trenger ikke å sjekke hver - Hvis jeg vil foreta en hjerteslagssjekk på et eksempel, trenger jeg ikke undersøke CPU og alt annet sammen med det hvis jeg ' m gjør det hvert 20. sekund. Så du har flere pollingintervaller som du kan spesifisere.
Du har også, som sagt, spørringsovervåkningen din som du kan spesifisere. Og dette kan gjøres for hver forekomst uavhengig, slik at du virkelig kan imøtekomme den bestemte forekomsten når det gjelder hva du vil overvåke. For min ventestatistikk og overvåking av ventetiden, kan jeg slå den av eller på. Og jeg kan fortelle det å fange alt, jeg kan fortelle det, vet du hva jeg vil fange og når jeg vil fange det. Så mye av det vil også - Du må ta hensyn til hva du gjør, med tanke på hva du forteller verktøyet du skal overvåke.
Men generelt sett, hva jeg vil si, er, som sagt, rundt en til tre prosent det vi ser. Vi har solgt dette verktøyet lenge - siden, som sagt, cirka 2003 eller 2004 - og vi har tusenvis av kunder, så jeg kan forsikre deg om at vi ikke har det, vi vet det best å ikke forårsake ytelsesproblemer i navnet på ytelsen.
Eric Kavanagh: Ja, det er virkelig god informasjon. Jeg trodde bare det var et strålende sitat fordi, du vet, igjen, du ikke vil beseire formålet med det du prøver å oppnå, ikke sant?
Bullett Manale: Nøyaktig.
Eric Kavanagh: Og jeg setter pris på Robins spørsmål; dette er virkelig en utmerket plattform for å hjelpe DBA-er med å forstå de mange forskjellige aspektene og dimensjonene og lagene i det vi snakker om. Og jeg tror konseptet med samtale med dataene dine er veldig passende her, fordi du, til ditt poeng tidligere, ikke vil finne ut av det på første forsøk, vanligvis. Du må bruke litt tid på å se på dataene, se på historiske data, gjøre den syntesen i tankene dine. Og det er menneskets jobb, ikke sant? Jobben til yrket som sitter der bak og tar varme fra virksomheten på ganske regelmessig basis, for å få den jobben gjort og å holde togene i gang, ikke sant?
Bullett Manale: Absolutt.
Eric Kavanagh: Vel, folkens, dette har vært en annen fantastisk begivenhet. Hvis noen spørsmål du stilte ikke ble besvart, gi meg beskjed. Send en e-post til. Vi arkiverer alle disse hendelsene, så du kan alltid gå til InsideAnalysis.com for å finne arkivet, eller gå til vår partner, Techopedia.com. Hvis du ser på høyre side av siden deres, vil du se Hendelser og webcastene som er oppført der. Hvis du klikker på Flere arrangementer, kan du se alle webcastene som vi gjør oppført der, fortid, nåtid og fremtid.
Og med det skal vi ta farvel med deg. Vi har fem nettkaster til resten av året, folkens. Vi kan planlegge en til. Men ellers kommer den til 2017. Utgaven er ute. Gi oss beskjed, og hvis du har noen som vil vise frem teknologien deres, kan du sende en e-post til.
Med det skal vi ta farvel, folkens. Takk igjen for din tid og oppmerksomhet, vi snakker med deg neste gang. Ha det fint. Ha det.
