Odvzem: Voditelj Eric Kavanagh razpravlja o napovedih z dr. Robinom Bloorjem, Rickom Shermanom in IDERA Bullettom Manaleom.
Za ogled videoposnetka se morate registrirati za ta dogodek. Za ogled videoposnetka se registrirajte.
Eric Kavanagh: Gospe in gospodje, še enkrat pozdravljeni in dobrodošli nazaj v spletni oddaji Hot Technologies! Moje ime je Eric Kavanagh, jaz bom vaš gostitelj današnjega spletnega seminarja, ki se imenuje "Prihranite čas, denar in težave z optimalnimi napovedmi." "Seveda sem tam zamudil prvi del naslova," Najboljši zastavljeni načrti. " o tem v tej oddaji. Torej, Hot Technologies je seveda naš forum za razumevanje, kakšni od najbolj kul izdelkov so danes na svetu, svet podjetniške tehnologije, kaj ljudje počnejo z njimi, kako delujejo, vse te zabavne stvari.
In tema danes, kot predlagam, se ukvarja z napovedovanjem. Resnično poskušate razumeti, kaj se bo dogajalo v vaši organizaciji. Kako boste svoje uporabnike osrečevali, ne glede na to, kaj počnejo? Če delajo analizo, če delajo resnično delo, se soočijo z resničnimi kupci s transakcijskimi sistemi, ne glede na primer, želite razumeti, kako delujejo vaši sistemi in kaj se dogaja, in o tem se danes dobro govori. Nekako smešno je, ker napovedovanje ni nekaj, kar rad počnem, zato, ker sem vraževerna, kot mislim, da če preveč napovedujem, se bodo zgodile slabe stvari, ampak to sem samo jaz. Ne sledite mojemu mnenju.
Tukaj so danes naši predstavniki, resnično tvoji v zgornjem levem kotu, Rick Sherman kliče iz Bostona, naš prijatelj Bullett Manale iz IDERA in naš doktor Robin Bloor. In s tem ga izročim Robinu in samo opomnite ljudi: Vprašajte, ne bodite sramežljivi, radi imamo dobra vprašanja, danes jih dobro postavite našim predstavnikom in drugim. In s tem, Robin, vzemi ga.
Robin Bloor: V redu, no, kot sem, kot pravijo, sem mislil, da bom danes pripovedoval zgodbo SQL, ker je to ozadje tega, za kar se bo nadaljevala diskusija in se ne bo nujno spopadel, ker se Rick ne osredotoča na to in se ne bo spopadal s tem, kar ima Rick povedati. Torej, zgodba SQL, o SQL je nekaj zanimivih stvari, ker je tako prevladujoč. Glej, da je tisk, SQL je deklarativni jezik. Ideja je bila, da lahko ustvarite jezik, v katerem boste zahtevali, kar želite. In baza podatkov bi določila, kako to pridobiti. Pravzaprav se je to dobro izšlo, vendar obstaja nekaj stvari, ki bi jih bilo vredno povedati o posledicah, ki temeljijo na celotni industriji IT na deklarativnem jeziku. Uporabnik ne ve ali ne skrbi za fizično organizacijo podatkov, in to je dobro pri deklarativnem jeziku - vas loči od vsega tega in ga celo skrbi - samo vprašajte, kar želite, in bazo podatkov bo šel in ga dobil.
Vendar uporabnik nima pojma, ali bo način strukturiranja poizvedbe SQL vplival na uspešnost poizvedbe in to je nekoliko slabo. Videla sem, da so poizvedbe dolge stotine in sto vrstic, ki so samo ena zahteva SQL, se začne z "select" in nadaljuje s podizvedbami in tako naprej. In pravzaprav se izkaže, da če želite določeno zbirko podatkov iz baze podatkov, jo lahko prosite na več različnih načinov s SQL in dobite enak odgovor, če se s kakšnimi podatki seznanite. Torej, ena poizvedba SQL ni nujno najboljši način za spraševanje podatkov, baze podatkov pa se bodo glede na SQL, ki ga v njih vstavite, odzvale čisto drugače.
In tako SQL dejansko vpliva na zmogljivost, zato ljudje, ki uporabljajo SQL, resnično o njih, tudi za SQL programerje, ki uporabljajo SQL in še manj verjetno razmišljajo o vplivu, ki ga bodo imeli, saj je večina njihovega osredotočanja je dejansko na manipulaciji s podatki in ne na pridobivanju, dajanju podatkov. Enako velja tudi za BI orodja, videl sem SQL, ki dobi, če hočete, iz BI orodij iz različnih baz podatkov iztisne in je treba reči, da veliko tega je, no, ne bi pisal poizvedb SQL kot to. Nekdo je ustvaril malo motorja, da ne glede na parametre vrže nekaj SQL-a in spet, da SQL ne bo nujno učinkovit SQL.
Potem sem si mislil, da omenjam neskladje impedance, podatki, ki jih programerji uporabljajo, so drugačni od podatkov, kot jih urejajo. Torej, naš DMS shranjuje podatke v tabele, urejena objektno usmerjena koda je večinoma koder, danes programirajo objektno usmerjeno obliko in urejajo podatke v objektnih strukturah, tako da ne preslikava enega v drugega. Torej je treba prevesti iz tega, kar programer misli, da so podatki, v tisto, v kateri baza podatkov misli, kakšni so podatki. Kar se zdi, kot da smo morali narediti nekaj narobe, da bi bilo tako. SQL ima DDL za opredelitev podatkov, ima DML - jezik za obdelavo podatkov - izberite, projektirajte in se pridružite za pridobitev teh podatkov. Zdaj je zelo malo matematike in zelo malo časovno utemeljenih stvari, zato je njen nepopolni jezik, čeprav je treba reči, da je razširjen in še naprej razširjen.
In potem dobite težavo z oviro SQL, ki je vedno naravnejša od diagrama, vendar je veliko ljudi spraševalo vprašanja iz analitičnih razlogov, ko so dobili odgovor na pogoje s podatki o vprašanju, želijo postaviti drugo vprašanje. Torej, to postane pogovorna stvar, no, SQL ni bil zgrajen za dialoge, temveč je bil zasnovan za spraševanje, kaj vse želite naenkrat. In to je vredno vedeti, saj obstajajo nekateri izdelki, ki dejansko zapuščajo SQL, da bi omogočili pogovor med uporabnikom in podatki.
Glede na zmogljivost baze podatkov - in ta vrsta se širi na vse - da, CPE, pomnilnik, terenski disk, omrežje režijskih stroškov in težava z zaklepanjem več oseb, ki želijo izključno uporabiti podatke na določenem mestu točka v času. Vendar pa imajo tudi slabe klice SQL, je ogromno, kar lahko storite, če dejansko optimizirate SQL v smislu učinkovitosti. Dejavniki uspešnosti baze podatkov: slaba zasnova, slabo načrtovanje programa, manjkajoča obremenitev, uravnoteženje obremenitev, struktura poizvedb, načrtovanje zmogljivosti. To je rast podatkov. Z nekaj besedami je SQL priročen, vendar se ne optimizira.
Po tem, mislim, da lahko prenesemo Ricka.
Eric Kavanagh: V redu, Rick, naj ti dam ključe avtomobila WebEx. Vzemi stran.
Rick Sherman: V redu, super. No, hvala Robin, kot smo začeli na začetku predstavitve, je moja grafika še vedno precej dolgočasna, vendar gre tudi z njo. Tako se strinjam z vsem, o čemer je Robin govoril na strani SQL. Toda zdaj se želim osredotočiti na povpraševanje po podatkih, ki se zelo hitro izkažejo, ponudbo kot v orodjih, ki se uporabljajo v tem prostoru, ali potrebo po orodjih v tem prostoru.
Najprej je v vsakem članku, ki ga preberete, nekaj, kar zadeva velike podatke, veliko podatkov, nestrukturirane podatke, ki prihajajo iz oblaka, velike podatke povsod, ki si jih lahko zamislite. A rast trga baz podatkov stalno raste s SQL, relacijska baza podatkov, verjetno od leta 2015, je še vedno 95 odstotkov trga baz podatkov. Najboljši trije prodajalci relacij imajo v tem prostoru približno 88 odstotkov tržnega deleža. Še vedno sta se, kot je Robin govoril, pogovarjala o SQL-u. In pravzaprav, tudi če bi gledali na platformo Hadoop, Hive in Spark SQL - ki ga moj sin, ki je podatkovni znanstvenik, ves čas uporablja -, je zagotovo prevladujoč način, da ljudje pridejo do podatkov.
Zdaj na strani baze podatkov obstajata dve široki kategoriji uporabe baz podatkov. Eno je namenjeno sistemom za upravljanje operativnih baz podatkov, zato je načrtovanje odnosov med podjetji, vzdrževanje odnosov s strankami, ERP-ji Salesforce, Oracles, EPIC, N4s itd. In obstaja veliko število in večja količina podatkov v skladiščih podatkov in drugih sistemih, ki temeljijo na poslovni inteligenci. Vzrok je, da se vse, ne glede na to, kje in kako je zajeto, shranjeno ali sklenjeno, na koncu analizira, zato je pri uporabi podatkovnih baz veliko povpraševanje in povečanje, zlasti relacijskih baz podatkov na trgu.
Zdaj smo dobili povpraševanje, prihajajo nam ogromne količine podatkov. In res ne govorim samo o velikih podatkih, govorim o uporabi podatkov v vseh vrstah podjetij. Če pa s strani ponudbe za ljudi, ki lahko upravljajo te vire, najprej imamo pomanjkanje DBA. Kot navajamo v uradu za statistiko dela, se bodo od leta 2014–2024 delovna mesta DBA povečala le za 11 odstotkov - zdaj ljudje, ki imajo delovna mesta DBA, pa o tem dobro govorijo v sekundi - v primerjavi s 40 odstotki letni prostor za rast podatkov. In imamo veliko DBA; v istem študiju je v povprečju govorilo o povprečni starosti precej visoko v primerjavi z drugimi poklici IT. In potem imamo veliko ljudi, ki odhajajo s terena, ne da bi se nujno upokojili, ampak preusmerili v druge vidike, prešli v upravljanje ali kaj drugega.
Sedaj je del razloga, da odhajajo, to, ker je delo DBA vedno težje in težje. Najprej imamo DBA, ki sami upravljajo številne različne baze podatkov, fizične baze podatkov, ki se nahajajo povsod, pa tudi različne vrste podatkovnih baz. Zdaj je to lahko relacijsko ali pa so morda tudi druge baze podatkov, vrste baz. Toda tudi če je to povezano, bi lahko imeli katerega koli enega, dva, tri, štiri različne prodajalce, ki jih dejansko poskušajo upravljati. DBA-ji se običajno vključijo po oblikovanju baze podatkov ali aplikacije. Robin je govoril o tem, kako se oblikujejo baze ali aplikacije, kako se oblikuje SQL. No, ko smo govorili o modeliranju podatkov, ER modeliranju, razširjenem modeliranju ER, dimenzijskem modeliranju, naprednem dimenzijskem modeliranju, karkoli že, običajno programerji aplikacij in razvijalci aplikacij oblikujejo s svojim končnim ciljem - ne razmišljajo o učinkovitosti same baze podatkov . Tako imamo veliko slabe zasnove.
Zdaj ne govorim o prodajalcih aplikacij za komercialna podjetja; ponavadi imajo modele ER ali razširjene modele ER. Kar govorim, je veliko več poslovnih procesov in aplikacij, ki jih razvijejo razvijalci aplikacij v vsakem podjetju - ti pa niso nujno zasnovani za učinkovitost ali uspešnost uvajanja. In DBA so prezaposleni in včasih imajo 24/7 odgovornost, nenehno dobivajo vse več baz podatkov. Mislim, da je to malo povezano s tem, da ljudje ne razumejo, kaj počnejo ali kako to počnejo. Njihova lastna majhna skupina in ljudje samo razmišljajo: "No, vsa ta orodja so tako enostavna za uporabo, kar lahko še naprej metamo na vse več baz podatkov o njihovi obremenitvi," kar ni slučaj.
Kar nas vodi do delnih in nenamernih DBA. Imamo IT ekipe, ki so majhne in si ne morejo nujno privoščiti namenskega DBA. To velja za mala in srednje velika podjetja, kjer je v zadnjem desetletju širitev aplikacij za baze podatkov in baz podatkov eksplodirala in se še naprej širi. Vendar gre tudi za velike korporacije, ki običajno že dolgo in dolgo hranijo podatke, analizirajo poslovno inteligenco. Dolgo nazaj smo za te projekte dobivali namenske akreditacijske ocene; nikoli več ne dobimo namenskega DBA. Je bil odgovoren za oblikovanje baze podatkov, kar je v redu, če je nekdo, ki ima izkušnje.Toda na splošno so pooblaščeni akterji v razvoju razvijalci aplikacij, to vlogo pogosto prevzamejo kot del svojega dela, nimajo formalnega usposabljanja v njej in še enkrat, oblikujejo ga za svoje končne cilje, ne oblikujejo ga zaradi učinkovitosti.
In obstaja veliko razlike med oblikovanjem in razvojem, v primerjavi z uvajanjem in upravljanjem. Torej, imamo "peni modre, funt neumne", z majhno puščico tam, ki preskoči na pridobivanje spretnosti in virov, potrebnih za projekte. Glede na to, da so vsi iz "Maščevanja živcev", je moja majhna slika tam. Zdaj, kar ljudje potrebujejo, zato imamo razširjeno uporabo baz podatkov in podatkov v SQL. Imamo omejeno število DBA-jev - ljudi, ki so usposobljeni in strokovni za te nastavitve, načrtovanje in upravljanje ter razmestitev. In imamo vedno več delnih ali naključnih DBA, ljudi, ki niso imeli formalnega usposabljanja.
Katere so še nekatere druge stvari, ki se prav tako postavljajo v vprašanje dejstva, da se te baze podatkov tudi ne nastavljajo ali upravljajo? Najprej mnogi domnevajo, da ima sam sistem baz podatkov dovolj orodij za upravljanje. Zdaj so orodja vse lažja in enostavnejša - načrtovanje in razvoj - vendar je to drugače, kot če naredite dober dizajn in dobro upravljanje, načrtovanje zmogljivosti, spremljanje itd. Najprej ljudje domnevajo, da imajo vsa orodja, ki jih potrebujejo. Drugič, če ste delni ali slučajni DBA, ne veste, česa ne veste.
Mislim, da sem tam pozabil nekaj stavkov, tako da velikokrat preprosto ne razumejo, kaj sploh potrebujejo, da bi pogledali v zasnovi ali ko upravljajo ali upravljajo z bazami podatkov. Če to ni vaš poklic, potem ne boste razumeli, kaj morate storiti. Tretjič, je, da je SQL orodje, s katerim gremo naprej, zato je Robin govoril o SQL-ju in o tem, kako slabo je SQL včasih sestavljen ali je pogosto sestavljen. In tudi eden od mojih hišnih ljubljenčkov pri shranjevanju BI podatkov, migracija podatkov, prostor za inženiring podatkov je, da ljudje namesto z orodji napišejo SQL kodo, shranjene postopke, tudi če uporabljajo drago orodje za integracijo podatkov ali drago BI orodje, pogosto ga resnično uporabljajo samo za izvajanje shranjenih postopkov. Tako da je pomembnost razumevanja oblikovanja baz podatkov, gradnje SQL, še bolj pomembna.
In končno je tu pristop silosa, v katerem si posamezniki ogledamo posamezne baze podatkov. Ne gledajo, kako aplikacije delujejo in medsebojno delujejo. Prav tako pogosto resnično gledajo baze podatkov v primerjavi z aplikacijami, ki jih uporabljajo. Torej je delovna obremenitev, ki jo dobite v bazi podatkov, kritična pri zasnovi, kritična pri njenem uravnavanju, kritična pri poskusu, kako načrtovati zmogljivost itd. Torej, ko gledate gozd z dreves, so ljudje v plevelu , gledanje posameznih tabel in baz podatkov in ne gledanje na celotno interakcijo teh aplikacij v delovni obremenitvi.
Nazadnje morajo ljudje pogledati ključna področja, ki jih morajo pogledati. Ko načrtujejo upravljanje z bazami podatkov, morajo najprej razmišljati o tem, razviti nekaj meritev uspešnosti, osredotočenih na aplikacijo, zato ne bi smeli gledati samo na to, kako je ta tabela strukturirana, kako je posebej modelirana, ampak kako se uporablja? Torej, če imate v upravljanju dobavne verige zadosten program za podjetja, če odstranjujete naročila prek spleta, če počnete BI - karkoli počnete - morate pogledati, kdo ga uporablja, kako ga uporablja, kakšen je obseg podatkov , ko se bo to zgodilo. Kaj si resnično želite iskati, so čakalne dobe, kajti ne glede na to, vse aplikacije presojajo, koliko časa traja, da se nekaj naredi, naj bo to oseba ali samo izmenjava podatkov med aplikacijami ali obdelovalci. In kakšna so ozka grla? Tako pogosto, ko poskušate odpravljati napake, seveda resnično poskušate pogledati, katera so resnična ozka grla - ne nujno, kako prilagoditi vse, ampak kako se znebiti in premakniti uspešnost do čakalnih dob in pretočnega učinka - karkoli morate pogledati.
In res morate ločiti zajem podatkov, transakcije, vidike preoblikovanja v bazi in analitiko. Vsak od njih ima različne vzorce oblikovanja, vsaka ima različne vzorce uporabe in vsakega od njih je treba prilagoditi drugače. Torej morate razmišljati o tem, kako se ti podatki uporabljajo, kdaj se uporabljajo, za kaj se uporabljajo in ugotoviti, kakšne so metrike uspešnosti in katere so ključne stvari, ki jih želite analizirati, povezane s to uporabo. Zdaj, ko gledate spremljanje uspešnosti, si želite ogledati same operacije baze podatkov; želite pogledati obe podatkovni strukturi, torej indeksi, razdelitve in drugi fizični vidiki baze podatkov, celo struktura baze podatkov - naj bo to ER model ali dimenzijski model, pa vendar strukturiran - vse te stvari vplivajo na uspešnost , zlasti v različnih slabostih analitike zajemanja podatkov in sprememb, ki se zgodijo.
In kot je Robin omenil na strani SQL, je gledanje na SQL, ki ga poganjajo te različne aplikacije v teh bazah podatkov, in uravnavanje tega ključnega pomena. Glede na celotno obremenitev aplikacij in infrastrukturno okolje, v katerem te baze in aplikacije tečejo. Torej, da so omrežja, strežniki in oblak - ne glede na to, kaj vse tečejo - prav tako gledali na vpliv teh aplikacij in teh baz podatkov v tem smislu, vse to se prepleta, da lahko bazo podatkov prilagodite.
In končno, ko si ogledujete orodja, si želite ogledati tri različne vrste analitike, povezane s tem. Oglejte si opisno analizo: kaj se dogaja in kje, povezano z bazo podatkov in uspešnostjo aplikacije. Želite imeti možnost diagnostične analitike, da ugotovite ne le, kaj se dogaja, ampak zakaj se dogaja, kje so ozka grla, kje so težave, kaj deluje dobro, kaj ne deluje dobro? Ampak zmožnost analiziranja in podrobnejših pregledov na problematičnih področjih, da bi se lahko lotili teh vprašanj, bodisi za načrtovanje ali kar koli morate storiti.
In končno, najbolj agresivna ali proaktivna vrsta analize je dejansko narediti neko napovedno analizo, modeliranje prediktivne analitike, karkoli že. Vemo, da baza podatkov in aplikacije delujejo v tem smislu, če smo povečali zmogljivost, če pridobimo več uporabnikov, če naredimo več prepustnosti, karkoli že počnemo, smo sposobni načrtovati, kaj, kako in kje to vpliva na bazo podatkov, aplikacije nam omogočajo, da načrtujemo in določimo proaktivno, kje so ozka grla, kje lahko pride do čakalnih dob in kaj moramo narediti, da popravimo stvari. Zato želimo imeti orodja, ki bodo sposobna izvajati meritve uspešnosti, spremljati uspešnost, kot pri teh treh vrstah analiz. In to je moj pregled.
Eric Kavanagh: V redu, dovolite, da ga izročim - mimogrede, to sta dve odlični predstavitvi - naj to predam Bullettu Manaleu, da ga odnesem od tam. In ljudje, ne pozabite postaviti dobrih vprašanj; imamo že nekaj dobrih vsebin. Vzemi ga, Bullett.
Bullett Manale: Zveni dobro. Hvala, Eric. Torej, veliko tega, kar je rekel Rick in Robin, se očitno strinjam s 100 odstotki. Rekel bi, da sem ta drsnik potegnil navzgor, ker se mi zdi njegovo prileganje, ne vem pa za tiste med vami, ki so navijači "A-Team" iz osemdesetih, John Hannibal Smith je vedno rekel: "Ljubim ko se načrt sestavi, "in mislim, da ko govorite o predvsem SQL strežniku, kamor smo se osredotočili, to je izdelek, o katerem bi danes govorili, SQL Diagnostic Manager, njegova zagotovo ena izmed tistih stvari, ki moraš imeti; moraš biti sposoben izkoristiti podatke, ki jih imaš, in biti sposoben sprejemati odločitve iz teh podatkov, v nekaterih primerih pa ne iščeš odločitve; iščete nekaj, kar bi vam povedalo, kdaj bo nekaj zmanjkalo virov, kdaj vam bo zmanjkalo virov, kdaj boste imeli ozko grlo, takšne stvari.
Ne gre samo za spremljanje določene meritve. Pri Diagnostičnem upravitelju vam bo ena izmed stvari, ki ji gre zelo dobro, pomagala pri napovedovanju in razumevanju specifičnih delovnih obremenitev, o čemer se bomo danes pogovarjali o številnih. Orodje je namenjeno upravljalcu podatkov, DBA ali delujočemu DBA, zato je veliko stvari, o katerih je Rick omenil, igralski DBA tako resničen. Če niste DBA, boste imeli veliko vprašanj, ki jih boste imeli, ko pride čas za upravljanje okolja SQL, stvari, ki jih ne poznate. In zato iščete nekaj, kar bi vam pomagalo, vas popeljalo skozi postopek in vas tudi izobraževalo. In zato je pomembno, da boste z orodjem, ki ga uporabljate za tovrstne odločitve, dobili nekaj vpogleda v razloge, zakaj se te odločitve sprejemajo, ne pa samo, da vam govorijo: "Hej, stori to."
Ker sem igralec DBA, sem na koncu morda popoln DBA z dejanskim strokovnim znanjem in znanjem, da podprem ta naslov. Torej, ko sem govoril o tem, da sem skrbnik zbirke podatkov - ta diapozitiv vedno najprej pokažem, ker ima DBA nekaj drugačnih vlog, odvisno od organizacije, ki jo imate, pa se bodo spreminjale od eno mesto do drugega - toda navadno boste vedno na nek način odgovarjali za shranjevanje, načrtovanje tega shranjevanja in razumevanje predvidevanja, bi moral reči, koliko prostora boste potrebovali, naj bo to za vaše varnostne kopije ali naj bo to za same baze podatkov. To boste morali razumeti in oceniti.
Poleg tega boste morali stvari razumeti in optimizirati po potrebi in ko boste spremljali okolje, je očitno pomembno, da spremembe spremenite tako, kot so potrebne na podlagi stvari, ki se spreminjajo v okolju sama. Tako, kot je število uporabnikov, kot so priljubljenost aplikacij, sezonskost baze podatkov, je treba upoštevati vse, ko delate napovedovanje. In potem očitno gledate na druge stvari v smislu, da lahko posredujete poročila in potrebne informacije, ki se nanašajo na sprejemanje teh odločitev. V veliko primerih to pomeni primerjalno analizo; to pomeni, da si lahko ogledate določeno metriko in razumete, kakšna je vrednost te metrike v preteklosti, tako da lahko predvidevate, kam se bo premaknila naprej.
Torej, kar veliko orodja Diagnostic Manager ima te sposobnosti, in ljudje ga uporabljajo vsak dan, da lahko počnejo stvari, kot so napovedovanje, in tu sem opredelil definicijo načrtovanja zmogljivosti. In njegova precej široka in pravzaprav precej nejasna opredelitev, ki je samo postopek določanja proizvodnih zmogljivosti, ki jih organizacija potrebuje za izpolnjevanje spreminjajočih se potreb po svojih izdelkih, in na koncu dneva je tisto, kar je resnično: njeno o tem, da lahko sprejemate informacije, ki jih imate na tak ali drugačen način, in sprejemate te informacije in sprejemate odločitve, ki vam bodo pomagale pri napredovanju skozi življenjski cikel podatkovnih baz. In zato so vrste stvari, ki so vzroki, da ljudje to potrebujejo, očitno najprej in predvsem v večini primerov prihranili denar. Podjetja so očitno njihov glavni cilj zaslužiti denar in prihraniti. Toda v tem procesu to pomeni tudi zmožnost, da se prepričate, da ni izpadov. In da lahko zagotovite, da omilite kakršno koli možnost izpada, zato preprečite, da se začne, z drugimi besedami, ne čakajte, da se zgodi, in nato reagirajte nanjo.
Ključnega pomena je tudi to, da lahko na splošno povečate produktivnost svojih uporabnikov, zato je njihova učinkovitost bolj učinkovita, da boste lahko več poslovali, to so vrste stvari, ki jih kot DBA ali kdo sodeluje pri napovedovanju ali zmogljivosti načrtovanje bo moralo biti zmožno prekrivati informacije, da bodo lahko sprejemale te odločitve. In na splošno bo to očitno pomagalo pri odstranjevanju odpadkov, ne le odpadkov v smislu denarja, ampak tudi časovno in v smislu na splošno virov, ki bi jih bilo mogoče uporabiti za druge stvari. Torej, če lahko odstranite te odpadke, tako da nimate priložnostnih stroškov, ki so vezani na same odpadke.
Torej, s tem rečeno, katere vrste vprašanj, ki jih dobimo, so značilne za osebo, ki ima DBA? Kdaj mi bo zmanjkalo prostora? To je veliko, ne le koliko prostora zaužijem zdaj, ampak kdaj mi bo zmanjkalo na podlagi trendov in pretekle zgodovine? Enako z dejanskimi primerki SQL, baz podatkov, katere strežnike lahko konsolidiram? Bom dal nekaj na VM, kaj je smiselno, v katerih bazah podatkov se bom utrdil in v katerih primerih SQL bi morali prebivati? Na vse te vrste vprašanj je treba odgovoriti. Ker v večini primerov, če ste DBA ali igrate DBA, ga boste nekje v karieri utrdili. V veliko primerih to počnete sproti. Torej morate biti sposobni sprejemati te odločitve hitro, ne pa igrati ugibanja, ko gre za to.
Pogovarjali smo se o ozkih grl in kje se bodo pojavili naslednji, da bi lahko še enkrat predvideli, da namesto da bi čakali, da se to zgodi. Torej, očitno so vse te stvari govorile, smiselno je v smislu, da se v večini primerov zanašate na zgodovinske podatke, da lahko ustvarite ta priporočila ali v nekaterih primerih sami znate oblikovati odločitve, da boste lahko izmislite te odgovore. Vendar me spominja na tisto, ko slišite radijske oglase za nekoga, ki prodaja vrednostne papirje ali kaj podobnega, njegova vedno »pretekla uspešnost ne kaže prihodnjih rezultatov« in tovrstne stvari. In enako velja tudi tukaj. Imeli boste situacije, ko te napovedi in te analize morda niso stoodstotno prave. Če pa se ukvarjate s stvarmi, ki so se že dogajale v preteklosti in so znane, in boste sposobni sprejeti in narediti "kaj, če" z veliko tovrstnimi vprašanji, ki jih boste naleteli, je zelo dragoceno in dobili boste veliko dlje od igranja ugibanja.
Očitno se bodo pojavila tovrstna vprašanja, kako bomo z Diagnostičnim upraviteljem obravnavali veliko teh vprašanj, najprej imamo zmogljivosti za napovedovanje, če lahko to storimo v bazi podatkov, v mizi in pogon ali glasnost. Da lahko rečem samo: "Hej, bili smo polni prostora", ampak šest mesecev, dve leti od tega, pet let od zdaj, če za to pripravim proračun, koliko vozniškega prostora bom potreboval za proračun za? To so vprašanja, ki si jih bom moral zastaviti, in bom moral uporabiti neko metodo tega, ne da bi ugibal in dvignil prst v zrak in čakal, kako bo pihal veter, kar je veliko na žalost, način, kako se sprejema veliko teh odločitev.
Poleg tega je to, da sem lahko - videti, kot da se je moj diapozitiv tam malo odrezal -, vendar sem lahko zagotovil pomoč v obliki priporočil. Torej, ena stvar je, če vam lahko pokažem nadzorno ploščo, polno meritev, in lahko rečete: "V redu, tukaj so vse meritve in kje so," ampak potem, da lahko nekaj ustvarite ali razumete, kaj storite, na podlagi tega je še en preskok. V nekaterih primerih so ljudje dovolj izobraženi o vlogi DBA, da lahko sprejmejo te odločitve. In zato imamo v orodju nekaj mehanizmov, ki vam bodo pri tem pomagali, kar vam dobro pokaže v samo sekundi. Ampak biti sposoben pokazati ne samo, kaj priporočilo je, ampak tudi dati nekaj vpogleda, zakaj se priporočilo pripravlja, in potem tudi povrhu tega, da je v nekaterih primerih mogoče dejansko izdelati skript, ki avtomatizira Sanacija tega vprašanja je prav tako idealna.
Prehodimo na naslednjo, ki je dobro videti, njeno splošno na splošno razumevanje, kar je normalno. Ne morem vam povedati, kaj ni normalno, če ne vem, kaj je normalno. In tako, če imamo način merjenja, ki je ključen, in morate imeti možnost upoštevati več vrst področij, na primer - ali naj rečem časovni okviri - različne skupine strežnikov, ki lahko to počnejo dinamično, od z opozorilom o perspektivi, z drugimi besedami, med oknom vzdrževanja pričakujem, da bo moj CPU deloval 80 odstotkov glede na vse vzdrževanje, ki se dogaja. Torej, morda bi želel zvišati svoje pragove višje, v tistih časovnih okvirih v primerjavi z morda sredi dneva, ko nimam toliko dejavnosti.
To so nekatere stvari, ki bodo očitno okoljske, toda stvari, ki jih lahko uporabite pri upravljanju tega, da boste lahko s tem okolju pomagali bolj učinkovito in si ga olajšali. Drugo področje je očitno sposobno le na splošno zagotoviti poročila in informacije, da bo lahko odgovoril na tiste vrste vprašanj "kaj če". Če sem pravkar spremenil svoje okolje, želim razumeti, kakšen vpliv je imel, da lahko to isto spremembo uporabim tudi za druge primerke ali druge baze podatkov v svojem okolju. Želim imeti nekaj informacij ali streliva, da bom to lahko spremenil z nekaj miru in ob zavedanju, da se bo to dobro spremenilo. Torej, če lahko naredim to primerjalno poročanje, da lahko razvrstim svoje primerke SQL, da lahko svoje baze podatkov razvrstim drug proti drugemu, da si rečem: »Kateri je moj največji porabnik CPU-ja?« Ali kateri najdlje je v pogoji čakanja in podobne stvari? Veliko teh informacij bo na voljo tudi z orodjem.
In ne nazadnje je le splošna sposobnost, da potrebujete orodje, s katerim se lahko spopadete, ne glede na situacijo, in če hočem reči, če imate veliko okolje z veliko na primer, verjetno boste naleteli na primere, ko morate izvleči metrike, ki tradicionalno niso metrike, ki bi jih DBA v nekaterih primerih želel celo nadzirati, odvisno od tega. Torej, če imate orodje, ki ga lahko razširite, da lahko dodate dodatne metrike in jih lahko uporabite v enaki obliki in na način, kot bi jih uporabljali, če bi uporabljali zunanje okence metrično, na primer. Kljub temu, da lahko to napovedujete in naredite, je ključni del, da lahko pripravite poročila, lahko opozorite, izhodiščno - vse stvari so govorili - tako boste dobili odgovore, ki jih iščete te odločitve, premik naprej.
Zdaj, ko to počne Diagnostic Manager, imamo centralizirano storitev, skupino storitev, ki se izvaja, zbira podatke glede na primere od 2000 do 2016. In potem to, kar počnemo, vzamemo te podatke in jih damo v osrednje skladišče, potem pa očitno, kaj vse dobro počnemo s temi podatki, naredimo veliko, da lahko zagotovimo nadaljnji vpogled. Zdaj, poleg tega - in ena od stvari, ki tu niso tukaj - je tudi ta, da imamo tudi storitev, ki teče sredi noči, ki je naša storitev napovedne analize, in to nekaj krči in pomaga razumeti in pomagati vam kot pooblaščeni lastnik akcijske skupine ali kot akter DBA, da lahko pripravite te vrste priporočil, da lahko tudi zagotovite nekaj vpogleda v izhodišče.
Torej, kar jaz rad počnem, in to je samo hiter primer arhitekture, tukaj ni veliko agentov ali storitev, ki dejansko sedejo na primerkih, ki jih upravljate. Ampak tisto, kar rad počnem, je, da vas dejansko dejansko prijavite tukaj in vam hitro predstavite. In naj tudi jaz odidem ven in to tudi naredim. Torej, povej mi, mislim, Eric, ali to vidiš?
Eric Kavanagh: Zdaj jih imam, ja.
Bullett Manale: V redu, zato vas bom popeljal skozi nekaj teh različnih delov, o katerih sem govoril. In v bistvu naj začnemo s takšnimi stvarmi, ki so bolj v skladu s tem, kar morate storiti, ali tukaj je nekaj pomembnega v prihodnosti in vam bodo dali nekaj vpogleda v to. In to lahko resnično predvidevamo - ali naj rečem dinamično predvidevam - stvari, kot se dogajajo. V primeru poročil je ena od stvari, ki jo imamo v orodju, tri različna poročila o napovedovanju. V primeru, na primer napovedi baze podatkov, bi najbrž storil, če bi lahko v določenem časovnem obdobju predvidel velikost baze podatkov, in navajam samo nekaj primerov tega. Torej, vzel bom svojo revizijsko zbirko podatkov, ki je precej intenzivna vhodno / izhodna - veliko podatkov je v njej. Imamo, poglejmo, tukaj to dobro naredimo in tukaj lahko samo izberemo bazo podatkov o zdravstvenem varstvu.
Toda poanta je v tem, da ne vidim samo prostora v tem, lahko rečem: "Poglejmo, naj vzamem podatke o zadnjih letih" - in tu se bom malo spoznal, res nimam let Vrednote podatkov, imam približno dva meseca podatkov, vendar, ker tukaj izbiram stopnjo vzorčenja mesecev, bom v tem primeru lahko predvidel ali napovedal naslednjih 36 enot, ker je naša stopnja vzorca nastavljena na mesece - to je enota, je mesec - in potem bi lahko pripravil poročilo, da bi mi v bistvu pokazal, kje pričakujemo našo prihodnjo rast, za te tri baze podatkov. In lahko vidimo, da se med tremi različnimi zbirkami podatkov razlikujejo razlike ali razlike, zlasti glede na količino podatkov, ki jo porabijo v preteklosti.
Tu lahko vidimo, da podatkovne točke predstavljajo zgodovinske podatke, nato pa bodo vrstice podajale napoved, skupaj s številkami, ki jih podkrepijo. Tako lahko to storimo na ravni tabele, to lahko storimo tudi na ravni pogona, kjer lahko predvidevam, kako veliki bodo moji pogoni, vključno s točkami pritrditve. To isto vrsto informacij bi lahko napovedali, vendar bom še enkrat, odvisno od stopnje vzorčenja, omogočil, da določim, koliko enot in kje jemljemo, kaj želimo napovedati. Opazite tudi, da imamo različne vrste napovedi. Tako dobite veliko možnosti in prilagodljivosti, ko pride čas za napovedovanje. To je ena stvar, saj vam določimo točno določen datum in si lahko rečete: "Hej, na ta datum bomo pričakovali rast vaših podatkov." Poleg tega vam lahko zagotovimo tudi to z drugimi vpogledi, ki so povezani z nekaterimi analizami, ki jih izvajamo v izven urnih urah in storitev, ko teče. Nekatere stvari je, da poskuša predvideti stvari, ki se bodo verjetno zgodile, na podlagi zgodovine, ko so se stvari v preteklosti dogajale.
Tako lahko tukaj vidimo, da nam pravzaprav napoved daje nekaj vpogleda v verjetnost, da bomo imeli ves večer težave na podlagi stvari, ki so se spet zgodile v preteklosti. Očitno je to super, še posebej, če nisem DBA, lahko pogledam na te stvari, a še bolje, če nisem DBA, je ta zavihek za analizo. Torej, preden bi to našli tukaj v orodju, bi šli skozi in ljudem pokazali izdelek in bili bi "To je super, vidim vse te številke, vse vidim, ampak ne vem, kaj bi storil" (smeh) "kot rezultat tega. "In tako imamo tukaj boljši način, da lahko razumete, če bom ukrepal, da bi pomagal pri uspešnosti, če bom ukrepal, da bi celo pomagal zdravju mojega okolje, če bom lahko razvrščal način podajanja teh priporočil in koristne nasvete v zvezi z informacijami, če želite izvedeti več o teh priporočilih in dejansko imeti celo zunanje povezave do nekaterih teh podatkov, ki me bodo pokazali in povedli do razlogov, zakaj ta priporočila so dana.
V mnogih primerih bi lahko zagotovili scenarij, ki bi, kot sem rekel, avtomatiziral sanacijo teh vprašanj. Zdaj je del tega, kar sem delal s to analizo - in vam pokažem, ko grem konfigurirati lastnosti tega primerka, in grem v razdelek za konfiguracijo analize - tukaj je naštetih veliko različnih kategorij, in del tega imamo optimizacijo indeksov in optimizacijo poizvedb. Torej so ocenjevali ne samo same meritve in podobne stvari, ampak tudi stvari, kot so delovne obremenitve in indeksi. V tem primeru dejansko naredite še nekaj dodatnih hipotetičnih indeksnih analiz. Torej, to je ena izmed tistih situacij, ko ne želim, v mnogih primerih nočem dodati indeksa, če tega ne želim. Toda na neki točki je nekakšna prelomna točka, kjer rečem: "No, tabela je na velikosti ali vrstah poizvedb, ki se izvajajo v okviru delovne obremenitve, je smiselno zdaj dodati indeks. Ampak to ne bi imelo smisla morda šest tednov prej. "Torej, to vam omogoča, da dinamično dobite vpogled v stvari, ki bodo verjetno, kot sem rekel, izboljšale uspešnost na podlagi tega, kar se dogaja v okolju, kaj se dogaja znotraj delovnih obremenitev in delati takšne stvari.
Tako dobite tukaj veliko dobrih informacij in tudi možnost samodejne optimizacije teh stvari. To je še eno področje, kjer bi si lahko pomagali v smislu, čemur pravimo prediktivne analize. Zdaj, poleg tega, bi moral reči, imamo tudi druga področja, za katera mislim, da so na splošno le v pomoč pri odločanju. Ko se pogovarjamo o sprejemanju odločitev, lahko znova pogledamo zgodovinske podatke, da dobimo nekaj vpogleda, da nas pripelje do tega, kje moramo biti, da izboljšamo to uspešnost.
Zdaj je ena od stvari, ki jo lahko naredimo, da imamo osnovni vizualizator, ki nam omogoča, da selektivno izbiramo tisto meritev, ki bi jo želeli - in dovolite mi, da tu najdem dostojno - grem v uporabo CPU SQL, toda poanta je, da lahko greš nazaj, vendar več tednov, da bi naslikali te slike, da bi videli, kdaj so vaši zaostali, da bi videli na splošno, kje ta vrednost pade v obdobjih, ko smo zbirali podatke. Potem pa poleg tega opazite tudi, da imamo, ko gremo na sam primerek, možnost konfiguriranja naših izhodišč. In osnovne postavke so resnično pomemben del tega, da lahko stvari avtomatiziramo in da smo o njih lahko obveščeni. In izziv, kot bi vam povedala večina DBA, je, da vaše okolje ne deluje vedno enako skozi ves dan, nasproti večeru in kaj podobno, kot smo že omenili v primeru z obdobji vzdrževanja, ko smo imajo visoko raven CPU-ja ali kar koli, kar se lahko dogaja.
V tem primeru imamo lahko pri teh dejanskih izhodiščih več osnovnih osnov, tako da bi lahko imel na primer osnovo v času ur vzdrževanja. Lahko pa bi ravno tako enostavno ustvaril izhodišče za svoje proizvodne ure. In smisel tega je, ko gremo v primerek SQL in dejansko imamo te številne izhodiščne vrednosti, potem bi lahko predvideli in lahko izvedli neko vrsto avtomatizacije, neko vrsto sanacije ali zgolj opozorila na splošno, različno specifična za tista časovna okna. Ena od stvari, ki jih boste videli tukaj, so te osnovne črte, ki jih ustvarjamo, z uporabo zgodovinskih podatkov za analizo, še pomembneje pa je, da te pragove lahko spremenim statično, lahko pa jih tudi dinamično avtomatiziram. Ko se prikaže okno za vzdrževanje ali naj rečem osnovno okno vzdrževanja, bi se ti pragovi samodejno preklopili specifično na obremenitve, s katerimi se srečujem v tem časovnem oknu, v primerjavi s morda sredi dneva, ko moje obremenitve niso tako veliko, kadar delovne obremenitve niso tako odmevne.
To je nekaj drugega, kar je treba upoštevati glede na izhodišče. Očitno bo to za vas zelo koristno, tudi če razumete, kaj je normalno in da lahko tudi razumete, se vključite, ko vam bo zmanjkalo sredstev. Kot sem že prej rekel, je druga stvar, ki jo imamo v orodju, to vam bo pomagalo pri sprejemanju odločitev, poleg tega, da se osnove in možnosti nastavitve opozoril okrog teh osnovnih ravni in pragov, ki jih ustvarite dinamično, samo da lahko pripravim ogromno poročil, ki mi pomagajo odgovoriti na vprašanja o tem, kaj se dogaja.
Kot primer, če bi imel 150 primerov, ki jih upravljam - v mojem primeru ne, zato moramo tukaj igrati igro pretvarjanja - ampak če bi imel vse svoje proizvodne primere in bi moral razumeti, kje je področje, ki ga imam Potrebna je pozornost, z drugimi besedami, če bom imel le omejen čas za izvajanje neke vrste administracije za izboljšanje učinkovitosti, se želim osredotočiti na ključna področja. In s tem bi lahko rekel: "Glede na to okolje razvrstite svoje primere drug proti drugemu in mi dodelite to razvrstitev po prepiru." Torej, ali je njegova uporaba diska, uporaba pomnilnika, ali čaka, ne glede na to, ali je odzivni čas, lahko primerjam - ali naj rečem - uvrstitev - teh primerov drug proti drugemu. Očitno je primerek tisti na vrhu vsakega seznama, če je isti primer, je to verjetno nekaj, na kar se resnično želim osredotočiti, ker je očitno spet na vrhu seznama.
Torej, v orodju imate veliko poročil, ki vam pomagajo pri razvrščanju okolja na ravni primerka; lahko to storite tudi na ravni baze podatkov, kjer lahko svoje baze podatkov uvrstim drug proti drugemu. Zlasti glede na pragove in območja, ki jih lahko nastavim, lahko tu celo postavim nadomestne znake, če se le želim, da se osredotočim samo na določene baze podatkov, toda poanta je, da lahko svoje baze podatkov primerjam na enak način. Kar se tiče drugih vrst primerjalne analize in tiste velike v tem orodju, je to osnovna analiza, ki jo imamo. Če se pomaknete navzdol do storitvenega pogleda tukaj, boste videli, da je to osnovno poročilo o statistiki. Zdaj bo to poročilo pomagalo, da bomo razumeli ne le, kaj so vrednosti metrike, ampak za določen primerek bi lahko izšel in za katero koli od teh meritev lahko dejansko pogledal izhodišča teh meritev.
Torej, ne glede na to, kakšen odstotek bi lahko izstopil in rekel: "Ogledam izhodiščno vrednost tega v zadnjih 30 dneh," v tem primeru mi bo pokazal dejanske vrednosti glede na izhodiščno in Lahko bi sprejel nekaj odločitev z uporabo teh informacij, očitno, zato je to ena tistih situacij, kjer bo odvisno od vprašanja, ki si ga takrat zastavite. Toda to vam bo očitno pomagalo pri številnih vprašanjih. Želim si, da bi lahko rekel, da imamo eno poročilo, ki to vse naredi, in takšno, kot je preprosto poročilo, kjer pritisnete in pritisnete gumb, ki samo odgovori na vsako vprašanje "kaj če", na kar bi lahko kdaj odgovorili. Toda v resnici boste imeli veliko atributov in veliko možnosti, da boste lahko v teh spustnih možnostih izbirali, da boste lahko oblikovali tista vprašanja "kaj če", ki jih iščete.
Tako je veliko teh poročil usmerjenih v odgovor na te vrste vprašanj. In zato je resnično pomembno tudi to, da so vam ta poročila in poleg tega vse stvari, ki smo jih že pokazali, v orodju, kot sem že omenil, imeli prilagodljivost za vključevanje novih meritev, ki jih je mogoče upravljati, celo lahko ustvarite števce, ali SQL poizvedbe, ki so vgrajene v vaše volilne intervale, da bi mi lahko pomagali odgovoriti na ta vprašanja, ki jih morda dodate v polje, ki ga nismo pričakovali za spremljanje. In lahko bi naredili vse iste stvari, ki sem vam jih pravkar prikazal: osnovno linijo, zagon poročil in ustvarjanje poročil iz te meritve ter lahko odgovarjate in počnete veliko teh različnih vrst stvari, ki vam jih prikažem tukaj.
Zdaj je poleg tega - in ena izmed stvari, ki smo jo očitno naleteli v zadnjem času, - najprej je bilo to, da vsi preletavajo ali prehajajo na VM-je. In zdaj imamo veliko ljudi, ki se odpravljajo v oblak. In obstaja veliko vprašanj, ki se zastavljajo glede teh vrst stvari. Ali je smiselno, da se premaknem v oblak? Ali bom prihranil denar s premikom v oblak? Če bi te stvari postavil na VM, na stroj z deljenimi viri, koliko denarja lahko privarčujem? Očitno se bodo pojavljala tudi taka vprašanja. Veliko teh stvari ne pozabite, z Diagnostic Managerjem lahko dodajamo in privlečemo iz virtualiziranih okolij tako VMware kot Hyper-V. Lahko dodamo tudi primere, ki so zunaj oblaka, zato lahko vaša okolja, kot je na primer Azure DB, ali celo RDS, tudi iz teh okolij potegnejo metrike.
Zato je veliko prožnosti in veliko možnosti, da odgovorimo na ta vprašanja, saj se nanaša na druga okolja, v katera vidimo ljudi, ki se odpravljajo. In tu je še veliko vprašanj v zvezi s temi stvarmi, in ko vidimo, da se ljudje utrjujejo v teh okoljih, bodo morali biti sposobni odgovoriti tudi na ta vprašanja. Torej, to je dober pregled, recimo, Diagnostic Managerja, saj se nanaša na to temo. Vem, da se je pojavila tema poslovne inteligence in imamo tudi orodje za poslovno inteligenco, o katerem danes nismo govorili, vendar vam bo tudi omogočilo vpogled v odgovore na tovrstna vprašanja, saj se nanaša na vaše kocke in tudi vse te različne stvari. Upajmo, da je bil to dober pregled, vsaj v smislu, kako lahko ta izdelek pomaga pri oblikovanju dobrega načrta.
Eric Kavanagh: V redu, dobre stvari. Ja, vrgel ga bom Ricku, če je še vedno tam zunaj. Rick, imaš kakšno vprašanje od tebe?
Rick Sherman: Ja, torej najprej, to je super, všeč mi je. Še posebej mi je všeč raztezanje do VM-jev in oblakov. Vidim, da veliko razvijalcev aplikacij meni, da če jih ni v oblaku, jih ni treba prilagoditi. Torej -
Bullett Manale: Kajne, za to moramo še plačati, kajne? Še vedno morate plačati za vse, kar ljudje postavljajo v oblak, tako da če slabo deluje ali če povzroči veliko ciklov CPU-ja, morate več denarja plačati, torej ne, še vedno morate izmeriti te stvari, absolutno.
Rick Sherman: Ja, v oblaku sem videl veliko slabih modelov. Želel sem vprašati, ali bi bil uporabljen tudi ta izdelek - vem, da ste omenili BI izdelek in imate številne druge izdelke, ki medsebojno delujejo - ampak ali bi začeli gledati uspešnost SQL, posamezne poizvedbe v tem orodju? Ali pa bi bila za to uporabljena druga orodja?
Bullett Manale: Ne, to bi bilo, absolutno. To je ena izmed stvari, ki je nisem pokrival in sem želel, je del poizvedb. Obstaja veliko različnih načinov za prepoznavanje uspešnosti poizvedb, bodisi povezane z njo, zlasti s čakanjem, kot ga vidimo na tem pogledu, ali je povezano s porabo virov poizvedb na splošno, obstaja veliko načinov za analizo poizvedb izvedba. Ne glede na to, ali je njegovo trajanje, CPU, V / I in še enkrat, lahko tudi sami preučimo delovne obremenitve, da bi dobili nekaj vpogleda. Priporočila lahko posredujemo v razdelku za analizo in imamo tudi spletno različico, ki vsebuje informacije o samih poizvedbah. Tako lahko dobim priporočila o manjkajočih indeksih in zmožnosti ogleda načrta izvršitve in vseh teh stvari; tudi njegova sposobnost. Torej, absolutno, lahko v nedeljo diagnosticiramo poizvedbe na sedem načinov (smeh) in smo sposobni zagotoviti vpogled v število usmrtitev, naj bo to poraba virov, čakanje, trajanje in vse te dobre stvari.
Rick Sherman: OK super. In kakšna je obremenitev samih primerkov pri vsem tem spremljanju?
Bullett Manale: Dobro vprašanje. Izziv pri odgovoru na to vprašanje je, ali je odvisno, ali je tako kot vse drugo. Veliko tega, kar ponuja naše orodje, ponuja prilagodljivost, del te prožnosti pa je, da mu poveš, kaj naj zbira in česa ne. Tako na primer s samimi poizvedbami ne rabim zbirati podatkov o čakanju ali pa lahko. Lahko zbiram informacije, povezane s poizvedbami, ki presegajo trajanje izvajanja. Kot primer, če bi šel v monitor za konfiguriranje poizvedb in bi moral reči: "Naj spremenim to vrednost v nič", je realnost ta, da v bistvu orodje zbira vsako poizvedbo, ki se zažene, in to res ni duha, zakaj je to tam, na splošno pa, če bi želel zagotoviti popoln vzorec podatkov za vsa vprašanja, bi to lahko storil.
Torej, zelo sorazmerni s tistimi, kar so vaše nastavitve, na splošno gledano, zunaj okvira. Njihova vrednost znaša od približno 1 do 3 odstotke, vendar obstajajo drugi pogoji. Odvisno je tudi od tega, koliko poizvedb v vratih se izvaja v vašem okolju, kajne? Odvisno je tudi od načina zbiranja teh poizvedb in kakšne različice SQL je. Tako na primer SQL Server 2005 ne bi mogel izvleči iz razširjenih dogodkov, medtem ko bi se za to potegnili iz sledu. Torej bi bilo nekoliko drugače glede na to, kako naj bi zbirali te podatke, toda to je, kot sem že rekel, s tem izdelkom približno od leta 2004. Dolgo je bilo, dobili smo na tisoče kupcev, zadnja stvar, ki jo želimo narediti, je orodje za spremljanje učinkovitosti, ki povzroča težave z uspešnostjo (smeh). In zato se poskušamo čim bolj izogibati temu, na splošno pa je približno 1–3 odstotkov dobro pravilo.
Rick Sherman: V redu, in to precej nizko, tako da je to grozno.
Eric Kavanagh: Dobro. Robin, imaš kakšno vprašanje od tebe?
Robin Bloor: Žal mi je, bila sem brez zvoka. Dobili ste več zmogljivosti baze podatkov in zanima me, kako lahko pogledate več baz podatkov, in zato lahko veste, da je večja baza virov morda razdeljena med različne virtualne stroje in tako naprej, in tako naprej. Zanima me, kako ljudje to dejansko uporabljajo. Zanima me, kaj počnejo kupci s tem. Ker se mi zdi, no, vsekakor, ko sem se zapletal v baze podatkov, nekaj, kar nikoli nisem imel pri roki. In kadar koli bi kdaj koli smiselno obravnaval en primer. Kako ljudje to uporabljajo?
Bullett Manale: Na splošno govorite le o orodju? Kako ga uporabljajo? Mislim, na splošno gre za to, da bi lahko imeli osrednjo točko prisotnosti okolja. Če imajo mir in vedo, da če se zazrejo v zaslon in vidijo zeleno, vedo, da je vse dobro. Kadar se težave pojavijo in je večina primerov z vidika DBA očitno velikokrat, ko se zgodijo pred konzolo, tako da jih je mogoče obvestiti takoj, ko se težava pojavi. Poleg tega pa, da lahko razumemo, kdaj se težava zgodi, da lahko priskrbimo bistvo informacij, ki jim dajejo nekaj prepričanja v smislu, zakaj se to dogaja. In tako je, mislim, največji del: biti aktiven glede tega, ne biti reaktiven.
Večina DBA-jev, s katerimi se pogovarjam - in ne vem, da jih je dober odstotek - žal še vedno deluje v reaktivnem okolju; čakajo, da se potrošnik obrne do njih in jim pokaže, da je problem. In tako vidimo veliko ljudi, ki se poskušajo odmakniti od tega, in mislim, da je to velik del razloga, zakaj je ljudem to orodje všeč, da jim pomaga, da so proaktivni, hkrati pa jim daje tudi vpogled v dogajanje , v čem je težava, toda v veliko primerih je to, kar najdemo vsaj - in morda nam to povejo samo DBA-ji - toda DBA-ji so zaznavanje vedno njihova težava, četudi je razvijalca aplikacije, ki je napisal aplikacijo ki tega niso pravilno napisali, so tisti, ki bodo krivi, povzročajo, da to aplikacijo prevzamejo v svoje sisteme ali strežnike in takrat, ko je delovanje slabo, vsi pokažejo na DBA: "Hej, tvoja je kriv."
Torej bo to orodje velikokrat uporabljeno kot pomoč pri pripravi DBA za odgovor: "Hej, tu je težava in nisem jaz jaz." (Smeh) Moramo izboljšajte to, pa naj bo to sprememba poizvedb ali karkoli že lahko. V nekaterih primerih bo to padlo v njihovo vedro glede na njihovo odgovornost, toda vsaj imeti orodje, ki jim bo pomagalo razumeti to in vedeti, in to storiti pravočasno, je očitno idealen pristop.
Robin Bloor: Ja, večina spletnih mest, ki jih poznam, vendar je minilo že nekaj časa, odkar sem bil tam, in sem si ogledal različna spletna mesta z več bazami podatkov, a večinoma sem ugotovil, da obstajajo DBA-ji, ki se osredotočajo na peščico baze podatkov. In to bi bile baze podatkov, da bi to, če bi kdaj padle, resnično velik problem za posel in tako naprej, in tako naprej. In druge, bodo samo zberele statistiko vsake toliko časa, da bi videle, da jim ni zmanjkalo prostora in jih sploh ne bi pogledale. Medtem ko ste delali predstavitev, sem gledal na to in sem dobro razmišljal, tako ali drugače, podaljšate, samo tako, da zagotovite kaj takega za baze podatkov, ki so bile pogosto, nikogar ni preveč zanimalo, ker imajo rast podatkov , imajo tudi porabo aplikacij. Pokrivanje DBA razširjate na dokaj dramatičen način. Vprašanje je torej, ali s takšnim naborom orodij lahko dobite storitev DBA za vsako bazo podatkov v podjetniškem omrežju?
Bullett Manale: Seveda, izziv je, da je tako, kot si rekel precej zgovorno, podobno kot nekaj baz podatkov, za katere skrbijo akterji DBA, in potem nekaj, za kar jih ne skrbi toliko. In način, kako ta določen izdelek, način licenciranja, temelji na posameznih stopnjah. Torej, verjetno bi rekli, je prag, ko se ljudje odločijo: "Hej, to ni dovolj kritičen primerek, da ga želim upravljati s tem orodjem." Povedano, obstajajo tudi druga orodja, ki jih imamo več , Predvidevam, da gre za tiste manj pomembne primere SQL. Eden od njih bi bil podoben upravitelju zalog, kjer izvajamo lahke zdravstvene preglede primerov, vendar poleg tega počnemo odkrivanje, torej ugotovimo nove primere, ki so bili posredovani na spletu in nato od takrat naprej kot DBA lahko rečem: "V redu, tukaj je nov primerek SQL, ali je to zdaj Express? Ali gre za brezplačno različico ali za poslovno različico? "To je verjetno vprašanje, ki si ga želim zastaviti, drugič, kako pomemben je zame ta primer? Če to ni tako pomembno, bi morda to orodje sprožilo in naredilo, splošno, kaj bi poimenoval generični zdravstveni pregledi v smislu, da gre za elementarne vrste stvari, za katere me skrbi DBA: Ali se pogon polni? Se strežnik odziva na težave? Glavne stvari, kajne?
Medtem ko sem z Diagnostic Managerjem orodje, ki sem vam ga ravno pokazal, se spustil na raven poizvedb, se bo spustil v priporočila indeksov, pogled na načrt izvedbe in vse te dobre stvari, medtem ko je to v glavnem osredotočeno o tem, kdo je lastnik, kaj sem lastnik in kdo je odgovoren za to? Katere servisne pakete in popravke imam na voljo? In ali moji strežniki delujejo z glavnimi sestavinami tega, kar bi po mojem mnenju predstavljal kot primeren primer SQL? Torej, da odgovorim na vaše vprašanje, je malo mešanice. Ko imamo ljudi, ki gledajo to orodje, običajno gledajo na bolj kritičen nabor primerkov. Kljub temu imamo nekaj ljudi, ki odkupijo vsak primer, ki ga imajo, in ga upravljajo, tako da je preprosto odvisno. Toda povem vam, da je vsekakor prag tistih, ki menijo, da je njihovo okolje dovolj pomembno, da imajo takšno orodje za upravljanje teh primerov.
Robin Bloor: V redu, še eno vprašanje, preden ga predam Ericu. Vtis, ki ga dobimo, samo če gledamo industrijo, je, da imajo baze podatkov še vedno življenje, vendar se vsi podatki prelijejo v vsa ta podatkovna jezera in tako naprej. To je hype, res, in hype nikoli ne odraža resničnosti, zato me zanima, kakšno resničnost zaznavate tam? Ali so pomembne baze podatkov v organizaciji, ali doživljajo tradicionalno rast podatkov, o kateri sem prej mislil kot 10 odstotkov na leto? Ali pa rastejo več kot to? Ali veliki podatki naredijo te baze balon? Kakšno sliko vidite?
Bullett Manale: Mislim, da je bilo veliko primerov, ko so se nekateri podatki premaknili v tiste druge segmente, kjer je bolj smiselno, ko so na voljo druge tehnologije. V zadnjem času je nekaj večjih podatkov. Toda te baze podatkov, bi rekel, je težko posplošiti v številnih primerih, ker so vsi malo drugačni. Na splošno gledano vidim nekaj razhajanj. Vidim, kot sem rekel, ljudje se v veliko primerih gibljejo k elastičnim modelom, ker želijo povečati sredstva in ne toliko na drugih področjih. Nekateri se premikajo k velikim podatkom. Ampak težko bi začutili, kot pravite, zaznavanje, ker ljudje, ki se pogovarjam z njimi, običajno imajo tradicionalne baze podatkov in to uporabljajo v okolju SQL Server.
Če rečem, če povem sam SQL, vsekakor mislim, da je njegov tržni delež vedno večji. In mislim, da obstaja veliko ljudi, ki se še vedno vozijo proti SQL-u iz drugih krajev, kot je Oracle, ker je njegova cenovno dostopnejša in očitno videti, da različice SQL postajajo naprednejše - in to opazite pri novejših stvareh, ki se dogajajo naprej s SQL-om v smislu šifriranja in vseh drugih zmogljivosti, zaradi katerih je okolje ali platforma baze podatkov - to je očitno zelo sposobno kritično poslanstvo. Torej, mislim, da smo videli tudi to. Kjer vidiš premik, se še vedno dogaja. Mislim, dogajalo se je pred 10 leti, mislim, da se to še vedno dogaja v smislu SQL Serverja, kjer okolje raste in tržni delež raste.
Robin Bloor: V redu, Eric, predvidevam, da ima občinstvo vprašanje ali dve?
Eric Kavanagh: Ja, naj vam vrnem eno hitro. Pravzaprav je precej dobro vprašanje. Eden od udeležencev se sprašuje, ali mi bo to orodje povedalo, če tabela morda potrebuje indeks za pospešitev poizvedbe? Če je tako, ali lahko pokažete primer?
Bullett Manale: Ja, tako da ne vem, če imam enega za posebej dodajanje indeksa, vendar lahko vidite tukaj, tu imamo priporočila za razdrobljenost. Prav tako samo verjamem, da smo ga ravnokar imeli, in to je bil del Diagnostičnega upravitelja, ki ponuja spletno različico, kjer mi pove, da imam manjkajoč indeks. Ta priporočila si lahko ogledamo in nam z indeksiranjem teh informacij povejo potencialni dobiček tega. Druga stvar, ki jo moram omeniti, je, da bomo, ko bomo delali priporočila, za mnoge izmed njih izdelali scenarij. To niso dober primer, vendar bi lahko videli, da, situacije, ko bi indeks - bodisi podvojen indeks bodisi dodajanje indeksa - izboljšal uspešnost, in kot sem že rekel, naredimo veliko da s hipotetično analizo indeksa. Resnično pomaga v smislu razumevanja delovne obremenitve, da lahko to uporabimo pri priporočilu.
Eric Kavanagh: To je super zadeva, in zaradi tega bom dobro spoznal končne komentarje tukaj. Tudi Robin in jaz in Rick sva se slišala že več let in tam govorita o samonačrtovanju baz podatkov. To je podatkovna baza za samonastavitev! Vse kar vam lahko povem je: Ne verjemite jim.
Bullett Manale: Ne verjemite hype.
Eric Kavanagh: Lahko se zgodi nekaj majhnih malenkosti, ki se naredijo dinamično, a kljub temu boste morda želeli, da to preverite in se prepričate, da ne počne nekaj, česar nočete. Torej bodo že nekaj časa potrebovali takšna orodja, da bi razumeli, kaj se dogaja na ravni baze podatkov in kot je dejal Robin, podatkovna jezera so fascinantni pojmi, vendar je verjetno približno toliko možnosti, da jih prevzamejo, kolikor je tam pošast iz Loch Ness-a. Torej, samo še enkrat bi rekel, resnični svet ima veliko tehnologij baz podatkov, potrebujemo ljudi, DBA, da si ogledajo te stvari in jih sintetizirajo. Lahko poveš, da moraš vedeti, kaj počneš, da te stvari delujejo. Vendar potrebujete orodja, s katerimi boste dobili informacije, da boste vedeli, kaj počnete. Torej, spodnja točka je, da DBA delajo v redu.
In velika hvala Bullettu Manaleu in našim prijateljem iz IDERA. In seveda Rick Sherman in Robin Bloor. Vse te spletne oddaje arhiviramo, zato se za več informacij o vsem tem pretaknite na spletno stran insideanalysis.com ali na naše partnersko spletno mesto www.techopedia.com.
In s tem se lepo poslovite, ljudje. Hvala še enkrat, dobro se pogovoriva naslednjič. Pazite. Adijo.