Tag væk: Værten Eric Kavanagh diskuterer prognoser med Dr. Robin Bloor, Rick Sherman og IDERAs Bullett Manale.
Du skal tilmelde dig denne begivenhed for at se videoen. Registrer dig for at se videoen.
Eric Kavanagh: Mine damer og herrer, hej endnu en gang og velkommen tilbage til Hot Technologies webcast-serien! Mit navn er Eric Kavanagh, jeg vil være vært for dagens webseminar, kaldet ”Sparer tid, penge og problemer med optimale prognoser.” ”Kursus Jeg savnede den første del af titlen der,” De bedste planlagte planer. ”Vi taler altid om det på dette show. Så Hot Technologies er selvfølgelig vores forum til at forstå, hvad nogle af de seje produkter er derude i verden i dag, verden af virksomhedsteknologi, hvad folk gør med dem, hvordan de fungerer, alt det slags sjove ting.
Og emnet i dag handler, som jeg antyder, om prognoser. Virkelig at du prøver at forstå, hvad der vil ske i din organisation. Hvordan skal du holde dine brugere glade, uanset hvad de laver? Hvis de laver analyse, hvis de laver rigtigt arbejde, står de over for rigtige kunder med transaktionssystemer, uanset hvad tilfældet måtte være, vil du gerne forstå, hvordan dine systemer kører, og hvad der foregår, og det er det, der godt tales om i dag. Dens slags sjovt, fordi prognoser ikke er noget, jeg kan lide at gøre, forårsager jeg er overtroisk, som jeg tror, hvis jeg forudsiger for meget, vil dårlige ting ske, men det er bare mig. Følg ikke min leder.
Så her er vores præsentanter i dag, dine virkelig i øverste venstre hjørne, Rick Sherman ringer ind fra Boston, vores ven Bullett Manale fra IDERA og vores helt egen Dr. Robin Bloor. Og med det overleverer jeg det til Robin og minder bare folk: Stil spørgsmål, vær ikke genert, vi elsker gode spørgsmål, send dem godt ud til vores præsentanter og andre i dag. Og med det, Robin, tag det væk.
Robin Bloor: OK, ja, da jeg er i polspositionen som de siger, troede jeg, at Id fortæller en SQL-historie i dag, fordi det er baggrunden for, hvad diskussionen, der skal foregå, og det vil uundgåeligt ikke komme i konflikt med, fordi Rick ikke fokuserer på dette , og vil ikke kæmpe med det, Rick har at sige. Så SQL-historien, der er nogle interessante ting ved SQL, fordi den er så dominerende. Se, det er en skrivefejl, SQL er et deklarativt sprog. Ideen var, at du kunne oprette et sprog, hvor du ville anmode om, hvad du ville have. Og databasen ville finde ud af, hvordan man får den. Og det har faktisk fungeret temmelig godt, men der er en række ting, der er slags værd at sige om det, konsekvenserne af at basere hele IT-branchen på et deklarativt sprog. Brugeren kender ikke eller bekymrer sig om den fysiske organisering af dataene, og det er det gode ved det deklarative sprog - det adskiller dig ud fra alt det her, og endda bekymre dig om det - bare spørg om hvad du vil og databasen vil gå og få det.
Men brugeren har ingen idé om, hvordan den måde, de strukturerer SQL-forespørgslen på, vil påvirke effektiviteten af forespørgslen, og det er lidt af en nedside. Jeg har set forespørgsler, der er hundreder og hundreder af linjer lange, det er bare en SQL-anmodning, du ved, begynder med "vælg" og fortsætter bare med underforespørgsler og så videre og så videre. Og det viser sig faktisk, at hvis du ønsker en bestemt indsamling af data ud af en database, kan du bede om det på mange forskellige måder med SQL, og få det samme svar, hvis du slags har en vis fortrolighed med dataene. Så en SQL-forespørgsel er ikke nødvendigvis den bedste måde at bede om data, og databaser vil svare ganske forskelligt i henhold til den SQL, du lægger i dem.
Og så påvirker SQL faktisk ydelsen, så folk, der bruger SQL, det er sandt for dem, det er også sandt for SQL-programmører, der bruger SQL, og de er endnu mindre tilbøjelige til at tænke på den indflydelse, de vil have, fordi de fleste af deres fokus handler faktisk om manipulation af data og ikke om at få, indsætte data. Og det samme er også tilfældet med BI-værktøjer, jeg har set den SQL, der, hvis du vil, skubber ud af BI-værktøjer i forskellige databaser, og det må siges, at meget af det er, ja, jeg ville ikke skrive SQL-forespørgsler sådan. Dets nogen har skabt, hvis du vil, en lille motor, at uanset hvilke parametre der er, vil det smide nogle SQL ud, og igen, at SQL ikke nødvendigvis vil være effektiv SQL.
Derefter tænkte jeg, at Id nævner impedansmatchet, de data, som programmører bruger, er forskellige end dataene, som de sorteres. Så vores DMS gemmer data i tabeller, organiseret den objektorienterede kode er for det meste kodere, programmerer objektorienteret form i dag, og de bestiller data i objektstrukturer, så det kortlægger ikke det ene til det andet. Så der er en nødvendighed for at oversætte fra, hvad programmøren mener, at dataene er til, hvad databasen mener, hvad dataene er. Det ser ud til, at vi må have gjort noget forkert for, at det var tilfældet. SQL har DDL til datadefinition, det har DML - datamanipulationssprog - vælg, projekt og deltag, for at få disse data. Nu er der meget lidt matematik og meget lidt tidsbaseret ting, så det er det ufuldkomne sprog, selvom det må siges, at det er blevet udvidet og fortsat udvides.
Og så får du SQL-barriereproblemet, som altid er lysere end diagrammet, i det, men mange mennesker stillede spørgsmål af analytiske grunde, når de først har fået svaret på spørgsmålene, vil du stille et andet spørgsmål. Så det bliver en dialog ting, ja, SQL var ikke bygget til dialoger, det blev bygget til at spørge, hvad du vil have alt på én gang. Og det er det værd at vide, fordi der er nogle produkter derude, der faktisk forlader SQL for at muliggøre samtale mellem brugeren og dataene.
Med hensyn til databasepræstation - og denne form for spredning til alt - ja, der er CPU, theres hukommelse, theres disk, theres netværksomkostninger og der er låsningsproblemet for mere end en person, der ønsker at have eksklusiv brug af dataene på en given tidspunkt. Men der er også dårlige SQL-opkald, der er meget, der kan gøres, hvis du faktisk optimerer SQL, hvad angår ydeevne. Så, databasepræstationsfaktorer: dårligt design, dårlig programdesign, samtidig manglende arbejdsbelastning, belastningsbalancering, forespørgselsstruktur, kapacitetsplanlægning. Det er datavækst. Og med få ord er SQL praktisk, men det optimerer ikke selv.
Når det er sagt, tror jeg, vi kan videregive til Rick.
Eric Kavanagh: Okay, Rick, lad mig give dig nøglerne til WebEx-bilen. Tage det væk.
Rick Sherman: Okay, fantastisk. Nå tak Robin, da vi startede i begyndelsen af præsentationen, er min grafik stadig temmelig kedelig, men gå godt med det. Så jeg er enig i alt, hvad Robin talte om på SQL-siden. Men det, jeg vil koncentrere mig lidt om nu, er efterspørgslen efter data, der godt gennemgår meget hurtigt, udbuddet som i værktøjer, der bruges i det rum, eller behovet for værktøjer i det rum.
For det første er der nogle i hver artikel, som du læser, har at gøre med big data, masser af data, ustrukturerede data, der kommer fra skyen, big data overalt, som du kan forestille dig. Men væksten i databasemarkedet har konstant været med SQL, relationel database sandsynligvis fra 2015, er stadig 95 procent af databasemarkedet. De øverste tre relationelle sælgere har cirka 88 procent af markedsandelen i dette rum. Så talte stadig, som Robin talte, om SQL. Og faktisk, selv hvis vi så på Hadoop-platformen, er Hive og Spark SQL - som min søn, som en datavidenskabsmand bruger hele tiden nu - bestemt den dominerende måde for folk at komme til data på.
På databasesiden er der nu to brede kategorier af brug af databaser. Den ene er til operationelle databasestyringssystemer, så forretningsforholdsplanlægning, kundeforhold bemanding, Salesforce ERP'er, Oracle, EPICs, N4s osv., I verden. Og der er et bredt beløb og en udvidet mængde data, der findes i datavarehuse og andre business intelligence-baserede systemer. Årsag alt, uanset hvor og hvordan det indfanges, opbevares eller transaktioner, bliver til sidst analyseret, og der er således en enorm efterspørgsel og stigning i brugen af databaser, især relationelle databaser ude på markedet.
Nu har vi fået efterspørgslen, vi har enorme mængder data, der kommer. Og jeg taler egentlig ikke bare om big data, jeg taler om brugen af data på tværs af alle slags virksomheder. Men ledsaget af det fra en forsyningsside, for mennesker, der kan administrere disse ressourcer, har vi først ud, vi har en slags mangel på DBA. Vi har ifølge Bureau of Labor Statistics, fra 2014-2020 vil DBA-job kun vokse med 11 procent - nu er der folk, der har DBA-jobtitler, men taler godt om det i et sekund - kontra 40-plus-procenten årlig datavækstplads. Og vi har en masse DBA'er; i gennemsnit er den samme undersøgelse, der talte om gennemsnitsalderen, temmelig høj sammenlignet med andre it-erhverv. Og så har vi en masse mennesker, der forlader banen, ikke nødvendigvis går på pension, men skifter til andre aspekter, går i ledelse eller hvad som helst.
En del af grunden til, at de forlader, skyldes, at DBA-job stadig bliver sværere og sværere. For det første har vi DBA'er, der selv administrerer mange forskellige databaser, fysiske databaser, der er placeret overalt, såvel som forskellige typer databaser. Nu kan det være relationelt, eller de kan også være en anden database, databasetyper også. Men selv hvis det er relationelt, kunne de have en af en, to, tre, fire forskellige leverandører, som de faktisk prøver at styre. DBA'er involveres typisk efter design af databasen eller applikationen. Robin talte om, hvordan databaser eller applikationer bliver designet, hvordan SQL bliver designet. Nå, når talte om datamodellering, ER-modellering, udvidet ER-modellering, dimensioneringsmodellering, avanceret dimensionel modellering, hvad som helst, typisk applikationsprogrammører og applikationsudviklere design med deres slutmål i tankerne - de designer ikke til effektiviteten af selve databasestrukturen . Så vi har meget dårligt design.
Nu taler jeg ikke om de kommercielle virksomhedsapplikationsleverandører; de har normalt ER-modeller eller udvidede ER-modeller. Det, jeg taler om, er meget flere forretningsprocesser og applikationer, der bygges af applikationsudviklere i enhver virksomhed - det er dem, der ikke nødvendigvis er designet til effektivitet eller effektivitet i implementeringen. Og DBA'erne selv er overanstrengte, og de har undertiden ansvar 24/7, de får stadig flere databaser. Jeg tror, det har gjort lidt med, at folk ikke helt forstår, hvad de gør, eller hvordan de gør det. Deres egen lille gruppe og folk tænker bare fortsat: ”Nå, alle disse værktøjer er bare så lette at bruge, vi kan bare fortsætte med at kaste flere og flere databaser på deres arbejdsmængde,” hvilket ikke er tilfældet.
Hvilket fører os til DBA på deltid og utilsigtet. Vi har IT-teams, der er små, og de har ikke nødvendigvis råd til en dedikeret DBA. Det gælder nu små til mellemstore virksomheder, hvor udvidelsen af database- og databaseapplikationer har eksploderet i det sidste årti og fortsætter med at udvide. Men det er også tilfældet med store virksomheder, der typisk har udført datalagring, business intelligence-analyse i lang, lang tid. For længe siden brugte vi dedikerede DBA'er til disse projekter; vi får aldrig en dedikeret DBA længere. Var ansvarlig for at designe databasen, hvilket er fint, hvis det er nogen, der har erfaring.Men generelt er DBA'erne applikationsudviklere, de tager ofte denne rolle som en deltidsdel af deres job, de har ikke formel uddannelse i det og igen, de designer det til deres slutmål, de designer ikke det til effektivitet.
Og der er meget forskel mellem design og udvikling versus implementering og styring. Så vi har det "penny kloge, pund tåbeligt" med en lille sparegris der, der springer over for at få de færdigheder og ressourcer, der er nødvendige i projekterne. Når jeg tænker på, at alle kommer fra "Nørdenes hævn", er mit lille billede der. Nu, hvad folk har brug for, så har vi en udvidet brug af databaser og data i SQL. Vi har begrænset antal DBA'er - mennesker, der er dygtige og eksperter til disse tuning og design og styring og implementering situationer. Og vi har flere og flere deltids- eller utilsigtede DBA'er, folk der ikke har haft den formelle træning.
Så hvad er nogle af de andre ting, der også kommer ind i spørgsmålet om, at disse databaser ikke også er afstemt eller styret? For det første antager mange mennesker, at databasesystemet selv har tilstrækkelige værktøjer til at styre sig selv. Nu bliver værktøjerne nemmere og lettere at gøre - design og udvikling - men det er anderledes end at lave et godt design og god styring, kapacitetsplanlægning, overvågning osv. Til implementering. Så for det første antager folk, at de har alle de værktøjer, de har brug for. For det andet, hvis du er en deltids- eller utilsigtet DBA, ved du ikke, hvad du ikke ved.
Jeg har nok glemt noget af udtrykket der, så mange gange forstår de ikke, hvad de endda har brug for at se på i designet eller når de administrerer eller betjener databaserne. Hvis det ikke er dit erhverv, skal du ikke forstå, hvad du skal gøre. Det tredje er, at SQL er et go-to-værktøj, så Robin talte om SQL, og hvor dårligt SQL sommetider konstrueres eller ofte konstrueres. Og også en af mine kæledyrspæle i BI-datalagring, datamigrering, datateknikplads er, at folk i stedet for at bruge værktøjer har en tendens til at skrive SQL-kode, lagrede procedurer, selvom de bruger et dyre dataintegrationsværktøj eller et dyrt BI-værktøj, de bruger ofte det virkelig bare for at køre lagrede procedurer. Så vigtigheden af at forstå databasedesign og konstruktion af SQL bliver endnu mere og mere vigtig.
Og endelig er der denne silo-tilgang, hvor vi har individuelle mennesker, der ser på individuelle databaser. De ser ikke på, hvordan applikationerne fungerer og interagerer med hinanden. Og de ser også ofte på databaserne i forhold til de applikationer, de bruger dem til. Så den arbejdsbyrde, du får i databasen, er kritisk i designet, kritisk for at indstille den, kritisk i forsøget på at finde ud af, hvordan man planlægger kapacitet osv. Så når man ser på skoven fra træerne, er folk i ukrudt , ser på de individuelle tabeller og databaser og ikke ser på den samlede interaktion mellem disse applikationer i arbejdsbyrden.
Endelig skal folk se på de vigtigste områder, de har brug for at se på. Når de planlægger at administrere databaser, er de nødt til først at tænke over, udvikle nogle applikationscentriske ydelsesmetrikker, så de er nødt til at se på ikke kun, hvordan denne tabel er struktureret, hvordan den er særlig modelleret, men hvordan bruges den? Så hvis du har virksomhedsapplikationer, der skal leveres i supply chain management, hvis du tager ordrer fra nettet, hvis du laver BI - uanset hvad du laver - skal du se på hvem der bruger det, hvordan de bruger det, hvad datamængderne er , når det kommer til at ske. Hvad du virkelig prøver at se efter er ventetiderne, for uanset hvad, alle applikationer bedømmes efter hvor lang tid det tager at få noget gjort, hvad enten det er en person eller bare udveksling af data mellem applikationer eller processorer. Og hvad er flaskehalse? Så ofte, når du prøver at fejlsøge spørgsmål, er du selvfølgelig virkelig forsøger at se på, hvad der er de virkelige flaskehalse - ikke nødvendigvis hvordan man indstiller alt, men hvordan slipper man af og flytter ydelsen op på ventetiderne og gennemløbet - uanset hvad du har brug for at se på.
Og du skal virkelig adskille datafangst, transaktioner, transformationsaspekter i databasen sammen med analysen. Hver af dem har forskellige designmønstre, hver af dem har forskellige brugsmønstre, og hver af dem skal indstilles forskelligt. Så du er nødt til at tænke over, hvordan disse data bruges, hvornår de bruges, hvad de bruges til, og finde ud af, hvad præstationsmetrikerne er, og hvad er de vigtigste ting, du vil analysere, der er relateret til denne brug. Når du nu ser på at overvåge ydeevnen, vil du se på selve databasefunktionerne; du vil se på både datastrukturer, så indekserne, opdelingen og andre fysiske aspekter af databasen, endda strukturen i databasen - hvad enten det er ER-model eller dimensionel model, dog dens strukturerede - alle disse ting har indflydelse på ydelsen , især i de forskellige ulemper ved datafangstanalyse og de transformationer, der sker.
Og som Robin nævnte på SQL-siden, at se på den SQL, der køres af disse forskellige applikationer på tværs af disse databaser, og at indstille den er afgørende. Og ser på de overordnede applikationsarbejdsbelastninger og det infrastrukturmiljø, som disse databaser og applikationer kører på. Så at netværkene, serverne, skyen - uanset hvad de kører på - også ser på virkningen, som disse applikationer og disse databaser har inden for dette con, har alle disse samspil mellem at være i stand til at indstille databasen.
Og til sidst, når du ser på værktøjer, vil du være i stand til at se på de tre forskellige slags analyser relateret til det. Du vil se på beskrivende analyse: hvad der sker og hvor, relateret til databasen og applikationsydelsen. Du vil have evnen til at foretage diagnostiske analyser for ikke at finde ud af, hvad der sker, men hvorfor sker det, hvor er flaskehalse, hvor er problemerne, hvad der kører godt, hvad der ikke kører godt? Men at være i stand til at analysere og bore ned i problemområderne for at adressere disse, enten til design eller hvad du end skal gøre.
Og endelig er den mest aggressive eller proaktive type analyse faktisk at foretage en eller anden forudsigelsesanalyse, forudsigelig analysemodellering, uanset hvad. Vi ved, at databasen og applikationerne fungerer i denne situation, hvis vi øgede kapaciteten, hvis vi får flere brugere, hvis vi gør mere gennemstrømning, uanset hvad der gjorde, at kunne projicere hvad, hvordan og hvor det vil påvirke databasen, applikationerne, giver os mulighed for at planlægge og finde ud af proaktivt, hvor flaskehalserne er, hvor ventetiderne kan lide, og hvad vi skal gøre for at løse tingene. Så vi ønsker at have værktøjer, der er i stand til at implementere performance-metrics, overvåge ydeevnen, ligesom i disse tre typer analyser. Og det er min oversigt.
Eric Kavanagh: Okay, lad mig aflevere det til - det er to gode præsentationer, forresten - lad mig give dette til Bullett Manale for at tage det derfra. Og folk, glem ikke at stille gode spørgsmål; vi har allerede noget godt indhold. Tag den væk, Bullett.
Bullett Manale: Lyder godt. Tak, Eric. Så meget af hvad Rick sagde og Robin sagde, jeg er selvfølgelig 100% enig. Jeg vil sige, at jeg trak dette lysbillede op, fordi jeg tror, det er passende, jeg ved ikke for dem af jer, der er "A-Team" fans tilbage i 80'erne, John Hannibal Smith havde et ordsprog hed altid sige, "Jeg elsker det, når en plan samles, ”og jeg tror, at når du snakker om især SQL Server, som det var, hvor vi fokuserede, hvilket er det produkt, der skulle tale om i dag, SQL Diagnostic Manager, det er bestemt en af de ting, som du skal have; du skal være i stand til at udnytte de data, du har, og være i stand til at tage beslutninger ud fra disse data, og i nogle tilfælde er du ikke på udkig efter en beslutning; du leder efter noget, der kan fortælle dig, når noget vil løbe tør med ressourcerne, når du vil løbe tør for ressourcerne, når du kommer til at have en flaskehals, den slags ting.
Det handler ikke kun om at overvåge en bestemt metrisk. Så med Diagnostic Manager er en af de ting, det gør meget godt, dig til at hjælpe dig med hensyn til prognoser og forståelse specifikt for arbejdsmængderne og ville tale om en masse af det i dag. Værktøjet er beregnet til databehandleren, DBA eller den fungerende DBA, så mange af de ting, som Rick nævnte om, den fungerende DBA er så sandt. I mange tilfælde, hvis du ikke er en DBA, vil der være mange spørgsmålstegn, som du vil have, når det er tid til at styre et SQL-miljø, ting du ikke ved. Og så er du på udkig efter noget, der kan hjælpe dig, tage dig igennem denne proces og også uddanne dig i processen. Og så er det vigtigt, at det værktøj, du bruger til den slags beslutninger, vil give dig en vis indsigt i grundene til, at disse beslutninger træffes, og det er ikke bare at fortælle dig, "Hej, gør dette."
Fordi jeg er den fungerende DBA, kan jeg til sidst være den fulde blå DBA med den faktiske ekspertise og viden til at bakke op om den titel. Så når det er sagt, når vi talte om at være en databaseadministrator - viser jeg altid slags dette dias først, fordi DBA har nogle forskellige roller, og afhængigt af den organisation, som du er med, du vil have, vil de variere fra et sted til et andet - men typisk er du altid på en eller anden måde ansvarlig for din opbevaring, din planlægning af denne opbevaring og forståelse af at foregribe, jeg skal sige, hvor meget plads du har brug for, hvad enten det er til dine sikkerhedskopier, eller om det er for databaserne selv. Du bliver nødt til at forstå og vurdere det.
Derudover har du brug for at være i stand til at forstå og optimere tingene efter behov, og når du gennemgår overvågningen af miljøet, er det åbenlyst vigtigt, at du foretager ændringer efter behov, baseret på ting, der ændrer sig i miljøet. sig selv. Så ting som antallet af brugere, ting som populariteten af applikationer, sæsonbestemtheden af en database, skal alle overvejes, når du laver din prognose. Og så, selvfølgelig, ser på andre ting i form af at være i stand til at give rapporterne og de oplysninger, der er nødvendige, når det drejer sig om at tage disse beslutninger. I mange tilfælde betyder det at foretage en sammenlignende analyse; det betyder at være i stand til at se specifikt på en bestemt metrisk og forstå, hvad værdien af denne metrisk har været over tid, så du kan forudse, hvor det vil komme videre.
Så hvad en masse af værktøjet Diagnostic Manager gør, har disse muligheder, og folk bruger det hver dag til at være i stand til at gøre ting som forudsigelse, og jeg har lagt definitionen her på kapacitetsplanlægning. Og det er en temmelig bred og faktisk temmelig vag definition, som bare er processen med at bestemme den produktionskapacitet, som en organisation har brug for til at imødekomme de skiftende krav til sine produkter, og i slutningen af dagen er det virkelig det, det hele handler om: Dets om at være i stand til at tage oplysninger, du har på en eller anden måde, og tage disse oplysninger og tage beslutninger, der hjælper dig med at komme videre, når du skrider frem gennem dine databases livscyklus. Og så, de typer ting, der er grundene til, at folk har brug for dette, er åbenlyst først og fremmest i de fleste tilfælde at spare penge. Virksomheder, selvfølgelig, det er deres vigtigste mål er at tjene penge og spare penge. Men i processen sammen med det betyder det også at være i stand til at sikre dig, at din nedetid, der ikke er nogen nedetid. Og at være i stand til at sikre dig, at du mindsker enhver chance for, at nedetid forekommer, så forhindre det i at ske til at begynde med, med andre ord, ikke vente på, at det skal ske, og derefter reagere på det.
Ud over at være i stand til generelt at øge produktiviteten for dine brugere, at gøre dem mere effektive, så du kan få gjort flere forretninger, er det åbenlyst nøglen her, så dette er de typer ting, som DBA eller nogen involveret i prognoser eller kapacitet planlægning bliver nødt til at være i stand til at vade igennem informationen for at være i stand til at træffe disse beslutninger. Og så vil dette helt klart hjælpe dig med at eliminere affald, ikke kun spild i form af penge, men også med hensyn til tid og med hensyn til generelt generelt ressourcer, der muligvis kan bruges til andre ting. Så at være i stand til at eliminere dette affald, så du ikke har mulighed for omkostninger, der er bundet til selve affaldet.
Så med det sagt, hvad er de typer spørgsmål, vi får, specifikke for den person, der er en DBA? Hvornår skal jeg løbe tør for rummet? Det er en stor, ikke kun hvor meget plads jeg bruger nu, men hvornår skal jeg løbe tør, baseret på tendenser og fortidens historie? Samme ting med de faktiske forekomster af SQL, databaserne, hvilke servere kan jeg konsolidere? Jeg vil sætte nogle på VM'erne, hvad giver mening med hensyn til hvilke databaser jeg vil konsolidere og hvilke forekomster af SQL skal de opholde sig på? Alle disse typer spørgsmål skal kunne besvares. Fordi i de fleste tilfælde, hvis du er en DBA eller handler DBA, vil du konsolidere det engang i din karriere. I mange tilfælde vil du gøre det løbende. Så du skal være i stand til at tage disse beslutninger hurtigt, ikke spille gætte-spil, når det kommer til det.
Vi talte om flaskehalse, og hvor de næste gang skulle forekomme, at vi kunne forudse det igen, i stedet for at vente på, at de skulle ske. Så åbenlyst alle disse ting talte om, giver mening i den forstand, at du er afhængig af historiske data, i de fleste tilfælde, for at være i stand til at generere disse henstillinger, eller i nogle tilfælde være i stand til at formulere beslutninger selv, for at være i stand til komme med disse svar. Men det minder mig om, at når du hører radioannoncer for nogen, der sælger værdipapirer eller noget lignende, er det altid "fortidens ydeevne ikke tegn på fremtidige resultater" og den slags ting. Og det samme gælder her. Du vil have situationer, hvor disse prognoser og disse analyser muligvis ikke er 100 procent rigtige. Men hvis du har at gøre med ting, der er sket i fortiden og det kendte, og være i stand til at tage og gøre "hvad hvis" med en masse af disse typer spørgsmål, vil du løbe ind i, det er meget værdifuldt og det vil får dig meget længere end at spille gætte-spillet.
Så disse typer spørgsmål er åbenlyst, at de vil komme op, så hvordan vi håndterer en masse af disse spørgsmål med Diagnostic Manager. Først og fremmest har vi prognosefunktioner, der er i stand til at gøre dette i databasen, ved bordet såvel som drev eller lydstyrken. For ikke kun at kunne sige, “Hej, var fulde af plads”, men seks måneder fra nu, to år fra nu, fem år fra nu, hvis jeg budgetterer til det, hvor meget drevplads skal jeg have til budget til? Det er spørgsmål, jeg bliver nødt til at stille, og jeg bliver nødt til at være i stand til at bruge en metode til at gøre det snarere end at gætte og sætte min finger op i luften og vente på at se, hvilken vej vinden blæser, hvilket er meget af og til, desværre, hvordan mange af disse beslutninger tages.
Derudover var det at være i stand til - ser ud som om min lysbillede blev afskåret der lidt - men at være i stand til at yde hjælp i form af henstillinger. Så det er en ting at være i stand til at vise dig et instrumentbræt fyldt med målinger og være i stand til at sige, "OK, her er alle målinger, og hvor de er ved," men derefter for at være i stand til at gøre nogle eller have en vis forståelse af, hvad de skal gør, baseret på det er endnu et spring. Og i nogle tilfælde uddannes folk nok i rollen som DBA til at være i stand til at træffe disse beslutninger. Og så har vi nogle mekanismer i værktøjet, der hjælper med det, som godt viser dig på bare et sekund. Men at være i stand til ikke kun at vise, hvad anbefalingen er, men også give en vis indsigt i, hvorfor den anbefaling bliver fremsat, og derefter også på toppen af det, i nogle tilfælde faktisk kunne komme med et script, der automatiserer afhjælpning af dette spørgsmål er også ideel.
Gå videre til den næste her, som godt kan se, dets bare generelt set forståelse ned til det metriske niveau, hvad der er normalt. Jeg kan ikke fortælle dig, hvad der ikke er normalt, hvis jeg ikke ved, hvad normalt er. Og så ved at have en eller anden måde at måle det, der er nøglen, og du har været i stand til at tage højde for flere typer områder, for eksempel - eller jeg skal sige tidsrammer - forskellige grupperinger af servere, der er i stand til at gøre dette dynamisk, fra en med alarmerende perspektiv, med andre ord midt på natten, under mit vedligeholdelsesvindue, forventer jeg, at min CPU kører på 80 procent baseret på alt det vedligeholdelsesarbejde, der foregår. Så måske vil jeg øge mine tærskler højere i disse tidsrammer kontra måske midt på dagen, når jeg ikke har så meget aktivitet.
Det er nogle ting, der naturligvis vil være miljømæssigt, men ting, som du kan anvende til hvad der styres, for at være i stand til at hjælpe dig med at styre dette miljø mere effektivt og gøre det lettere at gøre det. Det andet område er selvfølgelig i stand til bare samlet at give rapporterne og informationen for at kunne besvare disse typer af "hvad hvis" -spørgsmål. Hvis jeg lige har foretaget en ændring af mit miljø, vil jeg forstå, hvad den påvirkning har været, så jeg kan anvende den samme ændring på andre tilfælde eller andre databaser i mit miljø. Jeg vil være i stand til at have nogle oplysninger eller noget ammunition for at være i stand til at foretage denne ændring med en vis ro i sindet og vide, at det vil være en god forandring. Så at være i stand til at gøre den sammenlignende rapportering, være i stand til at rangere mine forekomster af SQL, være i stand til at rangere mine databaser mod hinanden og sige, ”Hvilken er min højeste forbruger af CPU?” Eller hvilken der tager længst i vilkår for ventetid og lignende ting? Så mange af disse oplysninger kommer også til rådighed med værktøjet.
Og så, sidst men ikke mindst, er det bare en samlet evne, at du har brug for et værktøj, der er i stand til at håndtere uanset situation, der kommer din vej, og så hvad jeg mener med det er, hvis du har et stort miljø med en masse tilfælde, vil du sandsynligvis løbe ind i situationer, hvor du har brug for at trække målinger, der traditionelt ikke er målinger, som en DBA ønsker at overvåge i nogle tilfælde, afhængigt af den særlige situation. Så at have et værktøj, som du kan, det er udvideligt, for at være i stand til at tilføje yderligere målinger og for at være i stand til at bruge disse metrics i samme form og på den måde, som du ville bruge dem, hvis du bruger en out-of-the-box metrisk, for eksempel. Så at være i stand til at køre rapporter, være i stand til at advare, baseline - alle tingene talte om - er også en vigtig del af at være i stand til at udføre denne prognose og gøre det, så du får de svar, du leder efter for at være i stand til at gøre disse beslutninger, gå videre.
Nu, som Diagnostic Manager gør dette, har vi en centraliseret service, en gruppe af tjenester, der kører, indsamler data mod 2000 til 2016-tilfælde. Og hvad vi gør, er at vi tager disse data, og vi lægger dem ind i et centralt arkiv, og hvad gør vi med disse data, selvfølgelig, er vi meget for at være i stand til at give yderligere indsigt. Udover det - og en af de ting, der ikke sker her - har vi også en service, der kører midt på natten, som er vores forudsigelige analysetjeneste, og der gør nogle numre knasende, og det hjælper med at forstå og hjælpe dig som DBA eller fungerende DBA, for at være i stand til at fremsætte disse typer af anbefalinger, for at være i stand til også at give en vis indsigt med hensyn til baseline.
Så hvad jeg kan lide at gøre, og dette er bare et hurtigt eksempel på arkitekturen, den store afhentning her er ikke nogen agenter eller tjenester, der faktisk sidder i de tilfælde, du administrerer. Men hvad jeg kan lide at gøre, er bare faktisk at tage dig ind i applikationen her og give dig en hurtig demo. Og lad mig bare gå ud og få det til. Så lad mig vide, jeg tror Eric, kan du se det OK?
Eric Kavanagh: Jeg har det nu, ja.
Bullett Manale: OK, så jeg tager dig gennem nogle af disse forskellige dele, som jeg talte om. Og lad os i det væsentlige starte med den slags ting, der er mere i træk med heres, noget, du skal gøre, eller her er noget, der er et tidspunkt i fremtiden og vil give dig en vis indsigt omkring det. Og dette er i stand til virkelig at foregribe - eller jeg burde sige dynamisk forudse - ting, som de sker. I tilfælde af rapporter er en af de ting, vi har i værktøjet, tre forskellige prognoserapporter. Og i tilfælde af f.eks. En databaseprognose, hvad jeg sandsynligvis ville gøre i situationen med at kunne forudse størrelsen på en database over en periode, og jeg vil bare give dig et par eksempler på det. Så jeg tager min revisionsdatabase, som er temmelig I / O-intensiv - det har en masse data, der går til den. Weve har, lad os se, og gør det her her, og lad os bare vælge sundhedsdatabasen her oppe.
Men pointen er, at jeg ikke bare kan se, hvad pladsen er på dette, jeg er i stand til at sige, ”Se, lad os tage de sidste års værdi af data” - og jeg kommer til at fibre her lidt, jeg har virkelig ikke et år data værd, jeg har cirka to måneders værdi af data - men fordi jeg vælger en prøvehastighed på måneder her, vil jeg være i stand til at forudse eller forudsige i dette tilfælde de næste 36 enheder, fordi vores prøvehastighed er indstillet til måneder - det er en enhed, er en måned - og så ville jeg være i stand til derefter at køre en rapport for dybest set at vise mig, hvor vi ville forudse vores fremtidige vækst, for disse tre databaser. Og vi kan se, at vi har en forskellig grad af forskel eller variation mellem de tre forskellige databaser, især med hensyn til den mængde data, de historisk spiser.
Vi kan se datapunkterne her repræsentere de historiske data, og derefter linjerne, der vil give os prognosen, sammen med de tal, der skal sikkerhedskopieres. Så vi kan gøre det på bordniveau, vi kan gøre det selv på drevniveauet, hvor jeg kan forudse, hvor store mine drev vil blive, inklusive monteringspunkter. Vi ville være i stand til at forudsige den samme type information ud, men igen, afhængigt af eksempelprocenten, vil jeg give mulighed for at bestemme, hvor mange enheder og hvor skal vi tage det, vi vil forudsige. Bemærk også, at vi har forskellige typer prognosetype. Så du får en masse muligheder og fleksibilitet, når det er tid til at udføre prognoser. Nu gør det en ting godt, ved faktisk at give dig en bestemt dato og være i stand til at sige "Hej på denne dato, det er her, vi ville forvente, at væksten af dine data bliver." Derudover kan vi dog give dig med andre indsigter, der er relateret til noget af den analyse, vi udfører i løbet af slukket timer og tjenesten, når den kører. Nogle af de ting, det gør, er det at forsøge at foregribe de ting, der sandsynligvis vil ske, baseret på historien om, hvornår ting skete i fortiden.
Så vi kan se her, faktisk giver en prognose os en vis indsigt i sandsynligheden for, at vi får problemer i løbet af aftenen ud fra ting, der igen er sket i fortiden. Så åbenlyst er dette godt, især hvis jeg ikke er en DBA, kan jeg se på disse ting, men hvad der er endnu bedre, hvis jeg ikke er en DBA, er denne analyse-fane. Så før dette var her i værktøjet, ville vi gå igennem og vise produktet til folk, og de ville være “Det er fantastisk, jeg ser alle disse numre, jeg ser alt, men jeg ved ikke, hvad jeg skal gøre” (griner) “som et resultat af det. ”Og så, hvad vi har her, er en bedre måde for dig at være i stand til at forstå, hvis jeg vil tage skridt til at hjælpe med ydeevne, hvis jeg vil tage skridt for endda at hjælpe med sundheden for min miljø, være i stand til at have en rangeret måde at levere disse henstillinger på, samt nyttige tip til information for at lære mere om disse henstillinger og faktisk have endda eksterne links til nogle af disse data, der vil vise mig og tage mig til grundene til disse henstillinger udarbejdes.
Og i mange tilfælde er det at være i stand til at levere et script, der, som jeg sagde, automatiserer afhjælpningen af disse problemer. Nu er en del af det, der lavede her med denne analyse - og jeg viser dig, når jeg går ind for at konfigurere egenskaberne for denne instans, og jeg går til afsnittet med analysekonfiguration - vi har en masse forskellige kategorier, der er anført her, og del af det har vi indeksoptimering og forespørgseloptimering. Så vi vurderede ikke kun selve målingerne og lignende ting, men også ting som arbejdsmængder og indekser. I dette tilfælde skal du faktisk gøre nogle yderligere hypotetiske indeksanalyser. Så det er en af de situationer, hvor jeg ikke vil, i mange tilfælde vil jeg ikke tilføje et indeks, hvis jeg ikke har brug for det. Men på et tidspunkt er der en slags vippepunkt, hvor jeg siger: ”Nå, tabellen kommer til størrelsen eller de typer forespørgsler, der kører inden for arbejdsbyrden, giver mening nu at tilføje et indeks. Men det ville have været fornuftigt måske seks uger før. ”Så dette giver dig mulighed for dynamisk at få den indsigt i ting, som sandsynligvis, som sagt, vil forbedre ydelsen baseret på hvad der sker i miljøet, hvad der sker inden for arbejdsmængderne, og gør den slags ting.
Og så får du en masse god information her såvel som muligheden for automatisk at optimere disse ting. Så det er et andet område, hvor vi ville være i stand til at hjælpe med, hvad vi kalder forudsigelig analyse. Nu skal jeg udover det også sige, at vi også har andre områder, som jeg synes generelt kun egner sig til at hjælpe dig med at tage beslutninger. Og når vi snakker om at tage beslutninger, endnu engang at være i stand til at se på historiske data, give en vis indsigt for at få os til, hvor vi skal være for at forbedre denne præstation.
En af de ting, vi kan gøre, er nu, at vi har en baseline-visualisator, som giver os mulighed for selektivt at vælge hvilken metrisk vi ønsker - og lad mig finde en anstændig her - Jeg går til SQL CPU-brug, men pointen er, at du kan gå tilbage over uanset mange uger for at male disse billeder, så du kan se, hvornår dine outliers er, for at se generelt hvor den værdi falder inden for de tidsperioder, som vi har indsamlet data. Og så vil du udover det også bemærke, at når vi går ud til selve det faktiske tilfælde, har vi muligheden for at konfigurere vores baseline. Og basislinjerne er en virkelig vigtig del om at være i stand til at automatisere tingene samt at kunne få besked om tingene. Og udfordringen, som de fleste DBA'er ville fortælle dig, er, at dit miljø ikke altid kører det samme i løbet af dagen, kontra aftenen og hvad ikke, som vi nævnte tidligere i eksemplet med de vedligeholdelsesperioder, hvor vi har høje niveauer af CPU eller hvad der måtte ske.
Så i tilfældet her, med disse faktiske baselinjer, kan vi have flere baselinjer, så jeg har muligvis en baseline for eksempel, det er i løbet af mine vedligeholdelsestimer. Men jeg kunne lige så let oprette en baseline til mine produktionstimer. Og poenget med at gøre det er, når vi går ind i en forekomst af SQL, og vi faktisk har disse flere baselinjer, så ville vi være i stand til at forudse og være i stand til at udføre en form for automatisering, en eller anden form for afhjælpning eller bare advarsel generelt, forskelligt specifikt for tidens vinduer. Så en af de ting, du ser her, er disse baselinjer, som vi genererer, bruger de historiske data til at levere den analyse, men endnu vigtigere er, at jeg kan ændre disse tærskler statisk, men jeg kan også automatisere disse dynamisk også. Så som vedligeholdelsesvinduet, eller jeg må sige, at vedligeholdelsesgrundvinduet kommer op, skifter disse tærskler automatisk specifikke til de belastninger, som jeg møder i det tidsvindue, mod måske midt på dagen, når mine belastninger ikke er som meget, når arbejdsmængderne ikke er så effektive.
Så det er noget andet at huske på med hensyn til baseline. Det er klart, at dette vil være meget nyttigt for dig med hensyn til også at forstå, hvad der er normalt, og at du også kan forstå, engagere dig, når du også er ved at løbe tør for ressourcer. Nu er den anden slags ting, vi har i værktøjet, det vil hjælpe dig med at tage beslutninger, ud over at baselinen og være i stand til at oprette alarmer omkring disse baselinjer og de tærskler, du opretter dynamisk, er som jeg sagde tidligere, bare at være i stand til at køre en hel række rapporter, der hjælper mig med at besvare spørgsmål om, hvad der sker.
Så som et eksempel, hvis jeg havde 150 tilfælde, jeg administrerer - i mit tilfælde gør jeg ikke det, så vi er nødt til at spille det foregående spil her - men hvis jeg havde alle mine produktionsinstanser, og jeg var nødt til at forstå, hvor er det område, jeg har brug for opmærksomheden med andre ord, hvis jeg kun vil have en begrænset tid til at udføre en form for administration for at forbedre ydeevnen, vil jeg fokusere på de centrale områder. Og så med det sagt, ville jeg være i stand til at sige, "Baseret på dette miljø, rangér mine tilfælde mod hinanden og giv mig den placering ved hjælp af stridsrør." Så hvad enten det er diskbrug, hukommelsesforbrug, om det venter, Uanset om det er svartid, er jeg i stand til at korrelere - eller jeg skal sige rang - disse tilfælde mod hinanden. Det er klart, at forekomsten er øverst på hver liste, hvis det er den samme instans, det er sandsynligvis noget, jeg virkelig ønsker at fokusere på, fordi det åbenbart igen er øverst på listen.
Så du har mange rapporter i værktøjet, der hjælper dig med at rangere miljøet på forekomstniveau; du kan også gøre dette på databaseniveau, hvor jeg kan rangere mine databaser mod hinanden. Især med tærskler og områder, som jeg kan indstille, kan jeg endda oprette jokertegn her, hvis jeg vil, for kun at fokusere på bestemte databaser, men pointen er, at jeg kan sammenligne mine databaser på samme måde. For så vidt angår andre typer komparativ analyse og det store i dette værktøj, er den baseline-analyse, som vi har. Så hvis du ruller ned til servicevisningen her, ser du, at der er en grundlæggende statistikrapport. Nu vil denne rapport naturligvis hjælpe os med at forstå ikke kun, hvad de metriske værdier er, men for en bestemt instans kunne jeg gå ud, og for en hvilken som helst af disse beregninger, faktisk være i stand til at se på basislinjerne for disse målinger.
Så hvad end det måtte være, som en procent eller hvad jeg end kunne gå ud og sige, "Lad os se baseline for dette, der er brudt ud i de sidste 30 dage," i hvilket tilfælde det viser mig de faktiske værdier i forhold til baseline og Jeg ville selvfølgelig være i stand til at tage nogle beslutninger ved hjælp af disse oplysninger, så dette er en af disse situationer, hvor det vil afhænge af hvilket spørgsmål det er, som du stiller på det tidspunkt. Men dette vil naturligvis hjælpe dig med mange af disse spørgsmål. Jeg ville ønske, jeg kunne sige, at vi havde en rapport, der gør det hele, og dets slags som den lette rapport, hvor du trykker og holder på, og den svarer bare på ethvert "hvad hvis" -spørgsmål, du nogensinde kunne svare på. Men virkeligheden er, at du vil have en masse attributter og en masse muligheder for at være i stand til at vælge imellem i disse pull-downs for at være i stand til at formulere disse "hvad hvis" -typespørgsmål, som du leder efter.
Så mange af disse rapporter er rettet mod at kunne besvare disse typer spørgsmål. Og så er det virkelig vigtigt også, at disse rapporter og derudover alle de ting, vi allerede har vist dig i værktøjet, som jeg nævnte før, har fleksibiliteten til at indarbejde nye målinger, der skal styres, endda at være i stand til at skabe tællere, eller SQL-forespørgsler, der er indarbejdet i dine pollingintervaller, for at være i stand til at hjælpe mig med at besvare disse spørgsmål, at du måske kan tilføje de ting ud af det felt, vi ikke forventede at overvåge. Og du vil være i stand til derefter at gøre alle de samme ting, som jeg lige har vist dig: basislinje, køre rapporter og oprette rapporter fra den metrik, og være i stand til at besvare og gøre en masse af disse forskellige typer ting, som jeg viser dig her.
Nu, udover det - og en af de ting, vi naturligvis løber ind i ganske lidt i det seneste, er - først var det, alle, der flippede eller skiftede til VM'er. Og nu har vi fået mange mennesker, der er på vej mod skyen. Og der er en masse spørgsmål, der dukker op omkring disse typer ting. Er det fornuftigt for mig at flytte til skyen? Skal jeg spare penge ved at flytte til skyen? Hvis jeg skulle placere disse ting på en VM på en maskine med delt ressource, hvor mange penge kan jeg spare? Disse typer spørgsmål kommer tydeligvis også frem. Så mange af disse ting skal huske, med Diagnostic Manager kan vi tilføje og trække fra de virtualiserede miljøer i både VMware og Hyper-V. Vi kan også tilføje forekomster, der er ude på skyen, så dine miljøer som f.eks. Azure DB, eller endda RDS, kan vi også trække målinger fra disse miljøer.
Så der er en masse fleksibilitet og meget at være i stand til at besvare disse spørgsmål, da det vedrører de andre typer miljøer, som vi ser folk på vej hen til. Og der er stadig mange spørgsmål omkring dette, og når vi ser folk konsolidere disse miljøer, er de nødt til at være i stand til at besvare disse spørgsmål også. Så det er en temmelig god oversigt, id siger, af Diagnostic Manager, da det vedrører dette emne. Jeg ved, at emnet business intelligence kom op, og vi har også et værktøj til business intelligence, som vi ikke talte om i dag, men det vil også give dig indsigt i at besvare disse typer spørgsmål, da det vedrører dine terninger og alle disse forskellige typer ting også. Men forhåbentlig har dette været et godt overblik, i det mindste med hensyn til, hvordan dette produkt kan hjælpe med at kunne formulere en god plan.
Eric Kavanagh: Okay, gode ting. Ja, jeg kaster det ud til Rick, hvis han stadig er derude. Rick, spørgsmål fra dig?
Rick Sherman: Ja, så først op, dette er fantastisk, jeg kan godt lide det. Jeg kan især godt lide at udvide til VM'er og skyer. Jeg ser, at en masse appudviklere mener, at hvis det er i skyen, behøver de ikke at indstille det. Så-
Bullett Manale: Okay, vi er stadig nødt til at betale for det, ikke? Du er stadig nødt til at betale for hvad det end er, at folk lægger på skyen, så hvis det er dårligt at køre, eller hvis det forårsager en masse CPU-cyklusser, det er flere penge, du har måttet betale, så det er ikke, du har stadig brug for at måle det her, absolut.
Rick Sherman: Ja, jeg har set en masse dårlige motiver i skyen. Jeg ville gerne spørge, ville dette produkt også blive brugt - Jeg ved, at du nævnte BI-produktet, og du har masser af andre produkter, der interagerer med hinanden - men ville du begynde at se på SQL-ydeevne, individuelle forespørgsler i dette værktøj? Eller ville det være andre værktøjer, der ville blive brugt til det?
Bullett Manale: Nej, det ville det absolut. Det er en af de ting, som jeg ikke dækkede, og som jeg mente, er forespørgselsdelen af det. Vi har mange forskellige måder at identificere forespørgslens ydeevne, hvad enten det er relateret til, specifikt til ventetider, som vi ser på dette synspunkt her, eller om det er relateret til ressourceforbruget af forespørgsler generelt, der er et helt antal måder, vi kan analysere forespørgsel ydeevne. Uanset om dets varighed, CPU, I / O, og endnu en gang, kan vi også se på selve arbejdsmængderne for at give en vis indsigt. Vi kan give anbefalingerne i analysesektionen, og vi har også en webbaseret version, der indeholder information omkring forespørgsler selv. Så jeg kan få anbefalinger om manglende indekser og evnen til at se udførelsesplanen og alt det slags; det er også en evne. Så absolut kan vi diagnosticere forespørgsler syv veje til søndag (griner) og være i stand til at give den indsigt med hensyn til antallet af henrettelser, det være sig ressourceforbrug, ventetiden, varigheden, alt det gode.
Rick Sherman: Ok godt. Og hvad er belastningen af selve forekomsterne med al denne overvågning?
Bullett Manale: Det er et godt spørgsmål. Udfordringen med at besvare dette spørgsmål er, afhænger det, det er ligesom noget andet. Meget af hvad vores værktøj har at tilbyde, det giver fleksibilitet, og en del af denne fleksibilitet er, at du får at fortælle det, hvad det skal samles, og hvad der ikke skal indsamles. Så for eksempel med selve forespørgslerne, behøver jeg ikke at samle oplysninger om ventetiden, eller det kan jeg også. Jeg kan indsamle oplysninger relateret til forespørgsler, der overstiger en varighed af tiden, for udførelsen. Som et eksempel på dette, hvis jeg skulle gå ind på konfigurationsforespørgselskærmen, og jeg skulle sige, "Lad os ændre denne værdi til nul," er virkeligheden, at det bare dybest set gør, at værktøjet samler alle forespørgsler, der kører, og det er virkelig ikke ånd af hvorfor der er der, men generelt set hvis jeg ville give et komplet udvalg af data til alle spørgsmålene, kunne jeg gøre det.
Så det er meget relativt til, hvad dine indstillinger generelt er ude af boksen. Det er overalt fra ca. 1-3 procent overhead, men der er andre betingelser, der vil gælde. Det afhænger også af, hvor meget portforespørgsler der kører på dit miljø, ikke? Det afhænger også af metoden til indsamling af disse spørgsmål og hvilken version af SQL det er. Så for eksempel SQL Server 2005 var ikke i stand til at trække fra udvidede begivenheder, hvorimod vi ville trække fra et spor for at gøre det. Så det ville være lidt anderledes med hensyn til den måde, vi ville gå på med at indsamle disse data, men som sagt, som jeg sagde, har vi været der, for jeg gætte siden omkring 2004 med dette produkt. Det har været i lang tid, vi har fået tusinder af kunder, så den sidste ting, vi ønsker at gøre, er at have et værktøj til overvågning af ydeevne, der forårsager ydelsesproblemer (griner). Og så prøver vi at undgå det så meget som muligt, men generelt set er ca. 1-3 procent en god tommelfingerregel.
Rick Sherman: OK, og det er ret lavt, så det er fantastisk.
Eric Kavanagh: Godt. Robin, nogen spørgsmål fra dig?
Robin Bloor: Jeg beklager, jeg var på stum. Du har en flere databasefunktioner, og jeg er interesseret i, hvordan du kan se på flere databaser, og derfor kan du vide, at en større ressourcebase muligvis er opdelt mellem forskellige virtuelle maskiner og så videre og så videre. Jeg er interesseret i, hvordan folk rent faktisk bruger det. Jeg er interesseret i, hvad kunderne laver med det. Fordi det ser for mig godt ud, det bestemt, da jeg rodede sammen med databaser, noget jeg aldrig havde på hånden. Og jeg ville kun nogensinde overveje et eksempel på nogen meningsfuld måde på et givet tidspunkt. Så hvordan bruger folk dette?
Bullett Manale: Generelt taler du om generelt kun selve værktøjet? Hvordan bruger de det? Jeg mener generelt, det handler om at være i stand til at have et centralt punkt i miljøets tilstedeværelse. At have ro i sindet og vide, at hvis de stirrer på en skærm og ser grønt, ved de, at alt er godt. Det er, når der opstår problemer, og åbenlyst de fleste af sagerne fra et DBA-perspektiv, mange gange forekommer disse problemer, når de er foran konsollen, så det er muligt at blive underrettet, så snart problemet sker. Men derudover at være i stand til at forstå, når problemet sker, at være i stand til at komme til hjertet af de oplysninger, der giver dem nogle begrænsninger med hensyn til, hvorfor det sker. Og det er, synes jeg, den største del: At være proaktiv overfor det, ikke være reaktiv.
De fleste af de DBA'er, jeg snakker med - og det ved jeg ikke, det er en god procentdel af dem - er desværre stadig i den reaktive type miljø; de venter på, at en forbruger nærmer sig dem for at fortælle dem, at der er et problem. Og så ser vi en masse mennesker, der prøver at bryde væk fra det, og jeg tror, det er en stor del af grunden til, at folk kan lide dette værktøj, er at det hjælper dem med at være proaktive, men det giver dem også indsigt i, hvad der foregår , hvad er problemet, men i mange tilfælde, hvad vi i det mindste finder - og måske er det bare DBA’erne der fortæller os dette - men DBA’erne, opfattelsen er det altid deres problem, selvom det er applikationsudvikleren, der skrev applikationen der skrev det ikke ordentligt, de er dem, der vil tage skylden, forårsage, at de tager denne applikation i deres systemer eller servere, og så når ydeevnen er dårlig, peger alle på DBA: "Hey, det er din skyld."
Så dette værktøj er mange gange brugt til at hjælpe med at gøre det muligt for DBA at sige, “Hej, det er her problemet ligger, og det er ikke mig.” (Ler) Vi er nødt til at forbedre dette, uanset om det ændrer forespørgsler eller hvad det måtte være. I nogle tilfælde falder det i deres spand med hensyn til deres ansvar, men i det mindste at have værktøjet til at være i stand til at hjælpe dem med at forstå det og vide det, og at gøre det på en rettidig måde er naturligvis den ideelle tilgang.
Robin Bloor: Ja, de fleste af de websteder, jeg er bekendt med, men det har været et stykke tid siden jeg har været derude og kigget på forskellige multidatabase-websteder, men mest hvad jeg plejede at finde var at der ville være DBA'er, der fokuserede på en håndfuld databaser. Og det ville være databaserne, at hvis de nogensinde gik ned, ville det være et rigtig stort problem for virksomheden, og så videre og så videre. Og de andre, de skal bare indsamle statistik nu og da for at se, at de ikke løber tør for plads, og de ville aldrig se på dem overhovedet. Og mens du udførte demoen, så jeg på dette, og jeg tænkte godt, på en eller anden måde udvider du bare ved at give noget som dette til databaser, der ofte var, brydde ingen sig for meget om, fordi de har datavækst , de har også applikationsvækst til tider. Du udvider DBA-dækning på en ganske dramatisk måde. Så det er det, spørgsmålet egentlig handler om, er det, at du med et sæt værktøjer som dette ender med at være i stand til stort set at give en DBA-service til enhver database, der findes i virksomhedsnetværket?
Bullett Manale: Sikker på, jeg mener, udfordringen er, er, at ligesom du sagde temmelig veltalende, er som der er nogle databaser, som DBA'erne er interesserede i, og så er der nogle, de ikke bryder sig om så meget. Og den måde, netop dette produkt, dets licens, er på en per-instans basis. Så der er, antager du, du vil sige, en tærskel for, når folk beslutter ”Hej, dette er ikke et kritisk nok eksempel, at jeg vil administrere det med dette værktøj.” Når det er sagt, er der andre værktøjer, som vi har, der er mere , Antager jeg, at der er catering til de mindre vigtige tilfælde af SQL. En af dem ville være som Inventory Manager, hvor vi foretager lette sundhedskontroller mod forekomsterne, men ud over det, vi gør, er vi at finde, så vi identificerer nye tilfælde, der er bragt online og derefter fra det tidspunkt, som en DBA kan jeg sige, ”OK, her er en ny forekomst af SQL, er det nu Express? Er det gratisversionen, eller er det en virksomhedsversion? ”Det er sandsynligvis et spørgsmål, jeg vil stille mig selv, men for det andet, hvor vigtig er den instans for mig? Hvis det ikke er så vigtigt, har jeg måske dette værktøj til at gå ud og gøre det, generisk, hvad jeg ville kalde generisk sundhedskontrol i den forstand, at de er de elementære typer af ting, jeg er interesseret i som en DBA: Er drevet påfyldt? Besvarer serveren problemer? De vigtigste ting, ikke?
Mens Diagnostic Manager viste det værktøj, jeg lige viste dig, det vil komme ned på forespørgselsniveauet, det vil komme ned i indstillingen fra indekser, se på udførelsesplanen og alt det gode, mens dette hovedsageligt er fokuseret på hvem ejer hvad, hvad er det, jeg ejer, og hvem der er ansvarlig for det? Hvilke servicepakker og hot fixes har jeg? Og kører mine servere med de vigtigste ingredienser i det, jeg ville betragte som et sundt eksempel på SQL? Så for at besvare dit spørgsmål er der lidt af en blanding. Når vi har folk, der ser på dette værktøj, ser de typisk på et mere kritisk sæt tilfælde. Når det er sagt, har vi nogle mennesker, der køber alle eksempler, de har, og administrerer det, så det afhænger bare. Men jeg siger, generelt er der bestemt en tærskel for de mennesker, der betragter deres miljø er vigtigt nok til at have et værktøj som dette til at styre disse tilfælde.
Robin Bloor: Okay, et andet spørgsmål, før jeg overleverer det til Eric. Det indtryk man får, bare ved at se branchen er, at databaser stadig har et liv, men alle data hældes ud i alle disse datasøer og så videre og så videre. Thats hype, virkelig, og hype afspejler aldrig virkeligheden, så jeg er interesseret i, hvilken slags virkelighed, du opfatter derude? Er de vigtige databaser inden for en organisation, oplever de den traditionelle datavækst, som jeg plejede at tænke på som 10 procent om året? Eller vokser de mere end det? Er det store data, der fremstiller disse databaser til ballon? Hvad er det billede, du ser?
Bullett Manale: Jeg tror, at der i mange tilfælde blev set nogle af dataene, der blev flyttet til de andre segmenter, hvor det giver større mening, når der er andre teknologier, der er tilgængelige. Som for nylig nogle af de større data ting. Men disse databaser, vil jeg sige, det er svært at generalisere i mange tilfælde, fordi alle er lidt anderledes. Generelt set er jeg dog en vis afvigelse. Som jeg sagde, er folk ved at flytte til de elastiske modeller i mange tilfælde, fordi de ønsker at vokse ressourcerne og ikke så meget på andre områder. Nogle mennesker flytter til big data. Men det er svært at få en fornemmelse af, siger du, opfattelsen, fordi folk generelt taler, at jeg taler med alle, har de traditionelle databaser og bruger dette i et SQL Server-miljø.
Når det er sagt, id siger med hensyn til selve SQL, jeg synes bestemt stadig, at det vinder sin markedsandel. Og jeg tror, at der er mange mennesker, der stadig er på vej mod SQL fra andre steder som Oracle, fordi det er mere overkommeligt og synes åbenbart, da SQL-versioner bliver mere avancerede - og du ser dette med de nyere ting, der foregår på med SQL, hvad angår kryptering og alle de andre muligheder, der gør det til et miljø eller en databaseplatform - det er åbenbart meget missionskritisk, antager jeg. Så det tror jeg også. Hvor du ser et skift, sker det stadig. Jeg mener, det skete for 10 år siden, det er stadig, synes jeg, at det sker i form af SQL Server, hvor miljøerne vokser og markedsandelen vokser.
Robin Bloor: OK, Eric, jeg formoder, at publikum har et spørgsmål eller to?
Eric Kavanagh: Ja, lad mig kaste en hurtig en hen til dig. Det er faktisk et ret godt spørgsmål. En af de deltagende spørger, vil dette værktøj fortælle mig, om en tabel muligvis har brug for et indeks for at fremskynde forespørgslen? I bekræftende fald, kan du vise et eksempel?
Bullett Manale: Ja, så jeg ved ikke, om jeg har et til specifikt at tilføje et indeks, men du kan se her, vi har fragmenteringsanbefalinger her. Jeg tror også bare, vi lige havde haft, og dette var en del af Diagnostic Manager, der tilbyder den webbaserede version, hvor det fortæller mig, at jeg har et manglende indeks. Og vi kan se disse henstillinger, og det fortæller os den potentielle gevinst ved at indeksere disse oplysninger. Den anden ting, jeg bare skal nævne, er, at når vi udfører anbefalingerne, vil scriptet blive bygget til det for mange af disse. Det er ikke et godt eksempel, men du vil være i stand til at se, ja, de situationer, hvor et indeks - enten et duplikatindeks eller tilføjelse af et indeks - ville forbedre ydeevnen, og som jeg sagde tidligere, gør vi meget af det gennem hypotetisk indeksanalyse. Så det hjælper virkelig med hensyn til forståelse af arbejdsbyrden at være i stand til at anvende det på anbefalingen.
Eric Kavanagh: Det er store ting, og dette vil give mig et godt segment til de endelige kommentarer her. Robin og jeg og Rick har også hørt i mange år nu, der er tale om selvindstillende databaser. Det er en selvindstillende database! Alt hvad jeg kan fortælle dig er: Tro ikke dem.
Bullett Manale: Tro ikke på hypen.
Eric Kavanagh: Der kan være nogle små små ting, der bliver gjort dynamisk, men selv det kan du tjekke det ud og sørge for, at det ikke gør noget, du ikke ønsker, at det skal gøre. Så i lang tid har vi brug for værktøjer som dette for at forstå, hvad der sker på databaseniveau, og som Robin sagde, datasøer er fascinerende koncepter, men der er sandsynligvis lige så stor chance for, at de overtager, som der er der en Loch Ness-monster når som helst snart. Så jeg vil bare sige igen, den virkelige verden har en masse databaseteknologi, vi har brug for mennesker, DBA'er, til at se på dette og syntetisere det. Du kan fortælle, at du er nødt til at vide, hvad du laver for at få disse ting til at fungere. Men du har brug for værktøjerne til at give dig informationen for at vide, hvad du laver. Så bundlinjen er, at DBA'er klarer sig fint.
Og en stor tak til Bullett Manale og vores venner på IDERA. Og selvfølgelig Rick Sherman og Robin Bloor. Vi arkiverer alle disse webcasts, så hopp online insideanalysis.com eller til vores partnerwebsted www.techopedia.com for at få flere oplysninger om alt det.
Og med det, så tak farvel, folkens. Tak igen, snak med dig næste gang. Pas på. Hej hej.