Oduzeti: Domaćin Eric Kavanagh razgovara o prognoziranju s dr. Robin Bloor, Rickom Shermanom i IDERAs Bullett Manaleom.
Da biste pogledali videozapis, morate se registrirati za ovaj događaj. Registrirajte se da biste pogledali video.
Eric Kavanagh: Dame i gospodo, pozdravimo još jednom i dobrodošli natrag u webcast serije Hot Technologies! Zovem se Eric Kavanagh, bit ću vaš domaćin današnjeg web seminara koji se zove „Ušteda vremena, novca i problema s optimalnim prognozama.“ „Naravno da sam propustio prvi dio naslova,„ Najbolji plaćeni planovi “. Uvijek razgovaramo o tome u ovoj emisiji. Dakle, Hot Technologies je naravno naš forum za razumijevanje koji su neki kul proizvodi danas u svijetu, svijet poslovne tehnologije, što ljudi rade s njima, kako rade, sve te zabavne stvari.
A tema se danas, kao što predlažem, bavi prognoziranjem. Stvarno pokušavate shvatiti što će se događati u vašoj organizaciji. Kako ćete usrećiti svoje korisnike, bez obzira na to što oni rade? Ako rade analize, ako rade pravi posao, suočavaju se sa stvarnim kupcima s transakcijskim sustavima, bez obzira na slučaj, želite shvatiti kako vaši sustavi rade i što se događa, i o tome se danas dobro govori. Vrlo je smiješno jer predviđanje nije nešto što volim raditi, zato što sam praznovjeran, kao što mislim da ako previše predvidim, dogodit će se loše stvari, ali to sam samo ja. Ne slijedi moje vodstvo.
Dakle, evo naših prezentatora danas, vaš doista u gornjem lijevom kutu, Rick Sherman zove iz Bostona, naš prijatelj Bullett Manale iz IDERA-e i naš vlastiti dr. Robin Bloor. I s tim, bolesno ga predajte Robinu i samo podsjetite ljude: Pitajte pitanja, ne stidite se, volimo dobra pitanja, dobro ih postavite danas našim prezentatorima i drugima. I s tim, Robin, odvedi to.
Robin Bloor: OK, dobro, kako sam Im u položaju s polo, kako kažu, mislio sam da danas pričam SQL priču, jer je njegova pozadina za ono što će rasprava nastaviti i neizbježno se neće sukobiti s tim jer se Rick nije usredotočio na to , i neće se sukobljavati s onim što Rick ima za reći. Dakle, priča o SQL-u, ima nekoliko zanimljivih stvari o SQL-u jer je on toliko dominantan. Vidite, to je pogreška, SQL je deklarativni jezik. Ideja je bila da možete stvoriti jezik na kojem ćete tražiti ono što želite. I baza podataka mogla bi razraditi kako to dobiti. I zapravo je to dobro ispalo, ali postoje brojne stvari koje su vrijedne toga reći, posljedice temeljene na čitavoj IT industriji na deklarativnom jeziku. Korisnik ne zna ili ne brine o fizičkoj organizaciji podataka, a ono dobro je u deklarativnom jeziku - ono vas razdvaja od svega toga, pa čak i brine o njemu - samo tražite sve što želite i bazu podataka otići će i dobiti.
No, korisnik nema pojma hoće li način strukturiranja SQL upita utjecati na izvedbu upita i to je pomalo negativno. Vidio sam upite dugi stotine i stotine redaka, koji su samo jedan SQL zahtjev, znate, započinje s "select" i nastavlja se i dalje s podupitima i tako dalje, i tako dalje. I zapravo ispada da ako želite određenu kolekciju podataka iz baze podataka, možete je zatražiti na mnogo različitih načina sa SQL-om i dobiti isti odgovor ako znate neke podatke. Dakle, jedan SQL upit nije nužno najbolji način traženja podataka, a baze podataka odgovorit će sasvim drugačije prema SQL-u koji u njih unesete.
I tako, SQL zapravo utječe na performanse, tako da ljudi koji koriste SQL, njegova istina o njima, isto vrijedi i za SQL programere koji koriste SQL i još manje vjerojatno razmišljaju o utjecaju koji će imati, jer je većina njihova fokusa je zapravo na manipulaciji podacima, a ne na dobivanju, stavljanju podataka. A isto vrijedi i za BI alate, vidio sam SQL koji, ako želite, istiskuje iz BI alata iz različitih baza podataka i moram reći da je puno toga, dobro, ne bih pisao SQL upite onako. Netko je stvorio, ako želite, mali motor koji će bez obzira na parametre izbaciti neki SQL, i opet, taj SQL neće nužno biti učinkovit SQL.
Tada sam pomislio da spominjem neusklađenost impedancije, podaci koje programeri koriste se razlikuju od podataka kao što ih sortiraju. Dakle, naš DMS pohranjuje podatke u tablice, organizirani objektno orijentirani kod većinom su koderi, danas programiraju objektno orijentirani oblik i naručuju podatke u objektnim strukturama, tako da ne preslikava jedan u drugi. Dakle, postoji potreba za prevođenje s onoga što programer misli da su podaci na ono što baza podataka misli što su podaci. Čini se kao da smo sigurno učinili nešto pogrešno da bi to bio slučaj. SQL ima DDL za definiranje podataka, ima DML - jezik za upravljanje podacima - odaberite, projektirajte i pridružite se za dobivanje tih podataka. Sada ima vrlo malo matematike i vrlo malo vremena temeljenih na stvarima, tako da je njihov nesavršeni jezik, iako treba reći da je njegov produžen i nastavlja se produžavati.
I tada, imate problem s SQL barijerom, koji je uvijek ravna od dijagrama, s tim da je mnogo ljudi postavljalo pitanja iz analitičkih razloga, nakon što su dobili odgovor na uvjete s podacima o pitanju i žele postaviti još jedno pitanje. To postaje dijaloška stvar, pa, SQL nije bio izgrađen za dijaloge, bio je izgrađen za postavljanje pitanja što želite sve odjednom. I vrsta je toga vrijedno znati, jer postoje neki proizvodi koji zapravo forsiraju SQL kako bi omogućili razgovor između korisnika i podataka.
U pogledu performansi baze podataka - a ova vrsta se širi na sve - da, theres CPU, theres memorija, theres disk, mrežni režijski troškovi i theres problem zaključavanja više osoba koje žele ekskluzivno koristiti podatke u određenom trenutku točka u vremenu. Ali tu su i loši SQL pozivi, postoji jako puno što se može učiniti ako stvarno optimizirate SQL, u smislu performansi. Dakle, čimbenici performansi baze podataka: loš dizajn, loš dizajn programa, istovremena količina radnog opterećenja, balansiranje opterećenja, struktura upita, planiranje kapaciteta. To je rast podataka. U nekoliko riječi, SQL je zgodan, ali ne optimizira se.
Rekavši to, mislim da možemo prenijeti Ricka.
Eric Kavanagh: U redu, Rick, daj da ti dam ključeve automobila WebEx. Odnesi to.
Rick Sherman: U redu, super. Hvala Robin, kao što smo krenuli na početku prezentacije, moja je grafika i dalje prilično dosadna, ali dobro ide s tim. Dakle, slažem se sa svime o čemu je Robin razgovarao na strani SQL-a. Ali ono na što se sada želim malo usredotočiti jest potražnja za podacima, koja vrlo brzo prolaze, ponuda kao u alatima koji se koriste u tom prostoru ili potreba za alatima u tom prostoru.
Prvo, u svakom pročitanom članku ima neke veze s velikim podacima, puno podataka, nestrukturiranim podacima koji dolaze iz oblaka, velikim podacima svugdje koji možete zamisliti. No, rast tržišta baza podataka kontinuirano se povećava kod SQL-a, relativna baza podataka vjerojatno od 2015. godine, još uvijek je 95 posto tržišta baza podataka. Tri najbolja dobavljača relacija imaju oko 88 posto tržišnog udjela u tom prostoru. Dakle, još uvijek su, kao Robin je govorio, o SQL-u. U stvari, čak i ako gledaju platformu Hadoop, Hive i Spark SQL - koji moj sin, koji je istraživač podataka, sada koristi cijelo vrijeme - je zasigurno dominantan način na koji ljudi mogu doći do podataka.
Sada, na strani baze podataka, postoje dvije široke kategorije korištenja baza podataka. Jedan je za sustave upravljanja operativnim bazama, pa planiranje odnosa s poduzećima, upravljanje odnosima s kupcima, ERP-ove Salesforce-a, Oracles, EPIC-ove, N4-ove itd. A, tu je velika količina i sve veća količina podataka koja se nalazi u skladištima podataka i drugim sustavima koji se temelje na poslovnoj inteligenciji. Uzrok tome sve, bez obzira na to gdje i na koji način je zarobljeno, pohranjeno ili izvršeno, na kraju se analizira, pa je stoga potrebna velika potražnja i povećanje uporabe baza podataka, posebno relacijskih baza podataka na tržištu.
Sad, imamo zahtjev, imamo ogromne količine podataka. A zapravo ne govorim samo o velikim podacima, govorim o upotrebi podataka u svim vrstama poduzeća. Ali prateći to, s one strane, mi ljudi koji mogu upravljati tim resursima prvo imamo svojevrsni nedostatak DBA. Prema podacima Zavoda za statistiku rada, od 2014–2024. Posao DBA porast će samo za 11 posto - sada je to ljudi koji imaju nazive DBA poslova, ali o tome razgovaraju u sekundi - nasuprot 40-postotnom posto godišnji prostor za rast podataka. I imamo puno DBA-a; u prosjeku je ta ista studija govorila o prosječnoj dobi prilično visoka u usporedbi s drugim IT profesijama. I onda imamo puno ljudi koji odlaze s terena, ne nužno u penziju, već prelaze u druge aspekte, prelaze u upravljanje ili što već.
Jedan od razloga zašto odlaze je taj što DBA posao postaje sve teži i teži. Kao prvo, imamo DBA-e koji sami upravljaju različitim različitim bazama podataka, fizičkim bazama podataka, lociranim po cijelom mjestu kao i različitim vrstama baza podataka. To bi moglo biti relacijsko, ili može biti i druga baza podataka, tipovi baze podataka. Ali čak i ako je relativan, oni bi mogli imati bilo kojeg jednog, dva, tri, četiri različita dobavljača kojima se zapravo trude upravljati. DBA-ovi se obično uključuju u dizajn nakon izrade baze podataka ili aplikacije. Robin je govorio o tome kako se dizajniraju baze podataka ili aplikacije, kako se dizajnira SQL. Pa, kada smo govorili o modeliranju podataka, ER modeliranju, proširenom ER modeliranju, dimenzionalnom modeliranju, naprednom dimenzionalnom modeliranju, što god, obično programirani programi i programeri aplikacija dizajniraju sa svojim krajnjim ciljem na umu - oni ne dizajniraju za učinkovitost same strukture baze podataka , Dakle, imamo jako loš dizajn.
E sad, ne govorim o dobavljačima aplikacija za komercijalna poduzeća; obično imaju ER modele ili proširene ER modele. Ono o čemu govorim je da postoji puno više poslovnih procesa i aplikacija koje razvijaju programi u svakoj tvrtki - oni su ti koji nisu nužno dizajnirani zbog učinkovitosti ili učinkovitosti primjene. A sami DBA-ovi su prezaposleni i ponekad imaju 24/7 odgovornosti, neprestano dobivaju sve više i više baza podataka. Mislim da je to pomalo povezano s tim što ljudi ne razumiju što rade ili kako to rade. Njihova mala skupina i ljudi samo razmišljaju: "Pa, svi su ovi alati jednostavno tako jednostavni za upotrebu, mi možemo nastaviti bacati na sve više i više baza podataka o njihovom radnom opterećenju", što nije slučaj.
Što nas vodi prema skraćenom i slučajnom DBA-u. Imamo IT timove koji su mali i ne mogu si nužno priuštiti namjenski DBA. To se sada odnosi na mala i srednja poduzeća, gdje je širenje aplikacija i baza podataka u posljednjem desetljeću eksplodiralo i dalje se širi. Ali to je slučaj i s velikim korporacijama, koje već duže vrijeme rade skladištenje podataka i analitiku poslovnog obavještavanja. Davno smo koristili namjenske DBA za te projekte; nikad više ne dobivamo namjenski DBA. Bili su odgovorni za dizajn baze podataka, što je u redu, ako je to netko tko ima iskustva.Ali općenito, DBA-i su programeri aplikacija, oni često tu ulogu uzimaju kao dio posla sa skraćenim radnim vremenom, nemaju formalnu obuku u njemu i opet, dizajniraju ga za svoje krajnje ciljeve, ne dizajniraju ga za učinkovitost.
I postoji velika razlika između dizajna i razvoja, nasuprot uvođenju i upravljanju. Dakle, mi imamo "sitnu sitnicu, budalu od funte", s tamošnjom maloj svinjici, preskačemo stjecanje vještina i resursa potrebnih za projekte. Mislim da su svi ljudi iz „Osvete živaca“, moja mala slika ondje. Sada, što se tiče onoga što ljudima treba, tako imamo sve veću upotrebu baza podataka i podataka u SQL-u. Imamo ograničen broj DBA - ljudi koji su vješti i stručni u ovim situacijama u prilagođavanju, dizajniranju, upravljanju i uvođenju. A imamo sve više i više izvanrednih DBA-ova, ljudi koji nisu imali formalnu obuku.
Dakle, koje su još neke stvari koje se također bave pitanjem činjenice da se te baze podataka također ne podešavaju ili se njima upravlja? Prvo, mnogi pretpostavljaju da sami sustavi baza podataka imaju dovoljno alata kako bi se upravljali. Sada su alati sve jednostavniji i lakši za dizajn - dizajn i razvoj - ali to je drugačije od dobrog dizajna i dobrog upravljanja, planiranja kapaciteta, nadzora itd. Za uporabu. Dakle, prvo ljudi pretpostavljaju da imaju sve potrebne alate. Drugo, ako ste skraćeni ili slučajni DBA, ne znate što ne znate.
Valjda sam tamo zaboravio neke fraze, tako da puno puta jednostavno ne razumiju ono što uopće trebaju pogledati u dizajnu ili kad upravljaju ili upravljaju bazama podataka. Ako to nije vaša profesija, onda nećete razumjeti što trebate učiniti. Treće, jest da je SQL alat koji ide dalje, tako da je Robin govorio o SQL-u i o tome kako je loše SQL ponekad izgrađen ili često konstruiran. A također jedan od mojih ljubimaca koji se bave skladištenjem BI podataka, migracijom podataka, prostorom za inženjering podataka jest taj što umjesto korištenja alata ljudi imaju tendenciju pisanja SQL koda, pohranjenih procedura, čak i ako koriste skupi alat za integraciju podataka ili skupi BI alat, često ga stvarno koriste samo za pokretanje pohranjenih procedura. Tako da je važnost razumijevanja dizajna baze podataka, izgradnje SQL-a, sve veća i važnija.
I konačno, tu je silosni pristup, u kojem pojedini ljudi promatraju pojedinačne baze podataka. Oni ne gledaju kako aplikacije funkcioniraju i međusobno djeluju. A oni stvarno često gledaju baze podataka u odnosu na aplikacije za koje ih koriste. Dakle, opterećenje koje dobivate u bazi podataka presudno je u dizajnu, kritično za njegovo prilagođavanje, kritično je za pokušaj smisliti kako planirati kapacitet itd. Dakle, gledajući šumu s drveća, ljudi su u korovu , gledajući pojedinačne tablice i baze podataka i ne gledajući cjelokupnu interakciju ovih aplikacija u radnom opterećenju.
I na kraju, ljudi trebaju pogledati ključna područja koja trebaju pogledati. Kada planiraju upravljati bazama podataka, prvo trebaju razmisliti o, razviti neke metričke performanse usmjerene na aplikaciju, pa ne moraju gledati ne samo kako je ta tablica strukturirana, kako je njezino posebno modelirano, već kako se koristi? Dakle, ako imate za korporativnu primjenu u upravljanju lancima opskrbe, ako skidate narudžbe s interneta, ako radite BI - što god radili - morate pogledati tko ga koristi, kako ih koristi, koliki su podaci , kada će se to dogoditi. Ono što stvarno želite tražiti su vrijeme čekanja, jer bez obzira na sve, sve se aplikacije procjenjuju koliko dugo je potrebno da se nešto učini, bilo da je riječ o osobi ili samo razmjeni podataka između aplikacija ili procesora. A koja su to uska grla? Pa često kada pokušavate ispraviti probleme, naravno da stvarno pokušavate pogledati koja su prava uska grla - ne nužno kako prilagoditi sve, već kako se riješiti i premjestiti izvedbu prema vremenima čekanja i protoku - što god trebate pogledati.
I stvarno morate izdvojiti podatke o snimanju, transakcijama, aspektima transformacije u bazi podataka, zajedno s analitikom. Svaki od njih ima različite obrasce dizajna, a svaki od njih ima različite obrasce uporabe i svaki od njih treba prilagoditi drugačije. Dakle, trebate razmisliti o tome kako se ti podaci koriste, kada se koriste, za što se koriste i shvatite koje su metrike performansi i koje su ključne stvari koje želite analizirati u vezi s tom upotrebom. Sada, kad gledate praćenje performansi, želite pogledati same operacije baze podataka; želite pogledati obje podatkovne strukture, pa indeksi, particije i drugi fizički aspekti baze podataka, čak i struktura baze podataka - bilo da se radi o ER modelu ili dimenzionalnom modelu, koliko god on bio strukturiran - sve te stvari utječu na performanse , posebno u različitim nedostacima analitike prikupljanja podataka i transformacija koje se događaju.
I kao što je Robin spomenuo na SQL-u, presudno je promatranje SQL-a koji pokreću te različite aplikacije u tim bazama podataka i njegovo prilagođavanje. Gledajući ukupna opterećenja aplikacija i infrastrukturno okruženje na kojem te baze podataka i aplikacije rade. Dakle, da mreže, poslužitelji, oblak - bez obzira na to što rade - također gledaju utjecaj koji te aplikacije i te baze podataka imaju u tom kontrastu, sve to ima međusobnu međusobnu sposobnost prilagođavanja baze podataka.
I na kraju, kad gledate alate, želite pogledati tri različite vrste analitičkih podataka povezanih s tim. Želite pogledati opisnu analizu: što se događa i gdje, povezano s bazom podataka i radom aplikacije. Želite imati mogućnost dijagnostičke analize kako biste shvatili ne samo što se događa, već i zašto se događa, gdje su uska grla, gdje su problemi, što ide dobro, a što ne radi dobro? Ali kad budete mogli analizirati i detaljno proučiti problematična područja, kako biste se obratili onima, bilo za dizajn ili ono što trebate učiniti.
I na kraju, najagresivnija ili najaktivnija vrsta analize zapravo je napraviti neku prediktivnu analizu, modeliranje prediktivne analitike, bilo što. Znamo da baza podataka i aplikacije djeluju u tom smislu, ako smo povećali kapacitet, ako dobijemo više korisnika, ako radimo više propusnosti, što god radili, kad možemo projicirati što, kako i gdje to utječe na bazu podataka, aplikacija nam omogućava planiranje i promišljanje gdje su uska grla, gdje mogu čekati vremena čekanja i što trebamo učiniti da popravimo stvari. Stoga želimo imati alate koji mogu implementirati metrike uspješnosti, nadzirati izvedbu, kao i ove tri vrste analize. I to je moj pregled.
Eric Kavanagh: U redu, dopustite da ga predajem - usput, to su dvije sjajne prezentacije - dopustite da ga predajem Bullettu Manaleu da ga odnesem odatle. I ljudi, ne zaboravite postaviti dobra pitanja; već imamo dobar sadržaj. Odnesi to, Bullett.
Bullett Manale: Zvuči dobro. Hvala, Eric. Dakle, puno toga što je Rick rekao i Robin je rekao, očito se slažem sa 100 posto. Rekao bih da sam povukao ovaj tobogan, jer mislim da je dolikuje, ne znam za one od vas koji su navijači "A-tima" u 80-ima, John Hannibal Smith je uvijek govorio: "Volim kad se plan sastavi ", a mislim da kada govorite o posebno SQL Serveru, na koji smo se fokusirali, a to je proizvod o kojem ćemo danas razgovarati, SQL Diagnostic Manager, definitivno jedna od onih stvari koje moraš imati; morate biti u mogućnosti iskoristiti podatke koje imate i biti u stanju donositi odluke iz tih podataka, a u nekim slučajevima ne tražite odluku; tražite nešto što će vam reći kada će vam ponestati resursa, kada će vam ponestati resursa, kada će vam imati usko grlo i takve stvari.
Nije riječ samo o nadziranju određenog mjernog podatka. S Diagnostic Managerom jedna od najboljih stvari će vam pomoći u predviđanju i razumijevanju specifičnih radnih opterećenja te ćemo danas razgovarati o mnogim stvarima. Alat je namijenjen upravitelju podataka, DBA ili glumačkom DBA, tako da je puno toga što je Rick spominjao, glumački DBA toliko istinito. U puno slučajeva, ako niste DBA, bit će puno upitnika koje ćete imati kad dođe vrijeme za upravljanje SQL okruženjem, stvari koje ne znate. I tako tražite nešto što će vam pomoći, voditi vas kroz taj proces i također vas educirati u tom procesu. Dakle, važno je da će vam alat koji koristite za takve vrste odluka dati uvid u razloge zbog kojih se te odluke donose, a ne samo da vam govori: "Hej, učini to."
Budući da igram DBA, na kraju bih mogao biti punopravni DBA s stvarnom stručnošću i znanjem da poduprijem tu titulu. Dakle, kad je riječ o administratoru baze podataka, to sam uvijek prvi prikazao, jer DBA ima neke različite uloge, a ovisno o organizaciji s kojom ćete učestvovati, oni će varirati od jedno mjesto na drugo - ali obično ćete uvijek na neki način biti odgovorni za vašu pohranu, vaše planiranje skladišta i razumijevanje predviđanja, trebao bih reći, koliko prostora će vam trebati, bilo za rezervne kopije ili bilo da je to za same baze podataka. Trebat ćete to razumjeti i procijeniti.
Osim toga, trebat ćete biti u stanju razumjeti i optimizirati stvari prema potrebi, a kako prolazite kroz praćenje okoliša, očito je važno da napravite promjene onako kako su potrebne na temelju stvari koje se mijenjaju u okolini sebe. Dakle, stvari poput broja korisnika, poput popularnosti aplikacija, sezonalnosti baze podataka, sve bi trebalo razmotriti kada obavljate svoje prognoze. I onda, očito gledajući druge stvari u smislu davanja mogućih izvještaja i informacija koje su potrebne, što se tiče donošenja tih odluka. U puno slučajeva to znači i usporednu analizu; to znači biti u stanju pogledati određenu metriku i shvatiti koja je vrijednost tog mjerila s vremenom, tako da možete predvidjeti kuda će se kretati naprijed.
Dakle, ono što puno alata Diagnostic Manager ima ima te mogućnosti i ljudi ga svakodnevno koriste kako bi mogli raditi stvari poput predviđanja, a ovdje sam definiciju stavio u planiranje kapaciteta. I njegova prilično široka i zapravo prilično nejasna definicija, što je samo postupak utvrđivanja proizvodnog kapaciteta koji je potrebna organizaciji da udovolji promjenjivim zahtjevima svojih proizvoda, a na kraju dana, u tome je zapravo ono što je njeno: o tome da možete preuzeti informacije koje imate na neki ili drugi način i da te informacije donosite i donosite odluke koje će vam pomoći da napredujete dok napredujete kroz životni ciklus svojih baza podataka. I tako, vrste stvari koje su razlozi zbog kojih ljudi to trebaju očito su prije svega u prvom redu radi uštede novca. Poduzeća su, očito, njihov glavni cilj zaraditi novac i uštedjeti novac. Ali u tom procesu, to također znači da možete biti sigurni da nećete zastajati. I biti u stanju osigurati da ublažite bilo kakvu šansu za prekid, tako da to ne dopušta da započne s, drugim riječima, ne čekajući da se to dogodi, a zatim reagirajte na njega.
Ono što je očigledno ključno je u tome što ste u cjelini mogli povećati produktivnost svojih korisnika, što ih čini efikasnijima kako biste mogli još više poslovati, to su vrste stvari koje kao DBA ili netko tko je uključen u predviđanje ili kapacitet planiranje će morati biti u mogućnosti proširivati se informacijama kako bi mogli donijeti te odluke. I sve u svemu, ovo će vam očito pomoći da eliminirate otpad, ne samo u novcu, već iu vremenu i u smislu općenito resursa koji bi se mogli koristiti za druge stvari. Dakle, mogućnost uklanjanja tog otpada tako da nemate oportunitetne troškove koji su vezani za sam otpad.
Dakle, s tim rečenim, koje su vrste pitanja koja dobivamo, specifična za osobu koja ima DBA? Kad će mi ponestati prostora? To je veliko, ne samo koliko prostora sada trošim, već i kada ću ga potrošiti na temelju trendova i povijesti prošlosti? Ista stvar s stvarnim primjercima SQL-a, baze podataka koje servere mogu objediniti? Ja ću staviti neke na VM-ove, što ima smisla u smislu koje baze podataka moram konsolidirati i na kojim instancama SQL-a trebaju prebivati? Na sve te vrste pitanja trebate moći dobiti odgovore. Jer u većini slučajeva, ako ste DBA ili igrate DBA, to ćete konsolidirati negdje u svojoj karijeri. U većini slučajeva to ćete raditi stalno. Dakle, morate biti u mogućnosti donositi te odluke brzo, a ne igrati igre nagađanja kada je u pitanju.
Razgovarali smo o uskim grlima i gdje će se oni sljedeći dogoditi, sposobni predvidjeti da je, opet, umjesto da čekamo da im se to dogodi. Dakle, očito su sve te stvari govorile, ima smisla u smislu da se oslanjate na povijesne podatke, u većini slučajeva da biste mogli generirati ove preporuke ili, u nekim slučajevima, moći sami formulirati odluke, kako biste bili u mogućnosti smislite ove odgovore. Ali podsjeća me na ono kad čujete radijske oglase za nekoga tko prodaje vrijednosne papire ili nešto slično, njegov uvijek "dosadašnji učinak nije pokazatelj budućih rezultata" i takve stvari. I ista stvar vrijedi i ovdje. Imat ćete situacije u kojima ove prognoze i ove analize možda nisu 100% ispravne. Ali ako se bavite stvarima koje su se događale u prošlosti i poznatim i kad ste u stanju da preuzmete i napravite "što ako" s puno ovih vrsta pitanja, u koje ćete se naići, vrlo je vrijedno i ono što ide u doći će vam puno dalje od igranja igre nagađanja.
Dakle, ove vrste pitanja očito će se pojaviti, pa kako s tim dijagnozama upravljamo s mnogim tim pitanjima, prije svega imamo mogućnosti predviđanja, to možemo učiniti u bazi podataka, za stolom kao i pogon ili glasnoća. Da bih mogao reći ne samo: "Hej, bili su puni prostora", nego šest mjeseci od sada, dvije godine od sada, pet godina od sada, ako budem za to proračunavao, koliko će mi prostora za vožnju trebati da proračunu za? To su pitanja koja ću morati postaviti, a ja ću morati koristiti neku metodu da to radim, umjesto da nagađam i dignem prst u zrak i čekam da vidim na koji način duva vjetar, što je puno nažalost, način na koji se puno tih odluka donosi.
Uz to, biti u mogućnosti - izgleda kao da se moj slajd tamo malo odsjekao - ali biti u mogućnosti pružiti neku pomoć u obliku preporuka. Dakle, jedna je stvar biti u mogućnosti pokazati vam nadzornu ploču punu mjernih podataka i moći reći: "U redu, evo sve metrike i gdje se nalaze", ali onda biti u mogućnosti napraviti neke ili imati razumijevanja za što učiniti, na osnovu toga je još jedan skok. U nekim su slučajevima ljudi dovoljno obrazovani u ulozi DBA-e da bi mogli donositi te odluke. Tako da u alatu imamo neke mehanizme koji će vam pomoći u tome, koji će vam dobro pokazati u samo sekundi. Ali biti u stanju pokazati ne samo što je preporuka, nego i pružiti uvid u to zašto se ta preporuka daje, a zatim i povrh toga, u nekim slučajevima, zapravo moći smisliti skriptu koja automatizira Sanacija tog pitanja je također idealna.
Prelazak na sljedeći, koji je dobro, njegovo općenito gledano, shvaćanje normalno na normalnu razinu. Ne mogu vam reći što nije normalno ako ne znam što je to normalno. I tako, ako postoji način da se mjeri to je ključno, a vi morate biti u mogućnosti uzeti u obzir više vrsta područja, na primjer - ili bih trebao reći vremenske okvire - različite grupe poslužitelja, kad to možete učiniti dinamički, s upozoravajući na perspektivu, drugim riječima, tijekom noći, tijekom prozora održavanja, očekujem da će se moj CPU pokrenuti na 80 posto na temelju cjelokupnog održavanja. Dakle, možda bih želio povećati svoje pragove više, u tim vremenskim okvirima nasuprot možda tijekom sredine dana, kada nemam toliko aktivnosti.
To su neke stvari koje će očito biti ekološke, ali stvari koje možete primijeniti u onome što se upravlja, kako bi vam mogli pomoći učinkovitije upravljati tim okolišem i olakšati vam to. Drugo područje očito je u mogućnosti upravo u cjelini pružiti izvješća i informacije kako bi se moglo odgovoriti na te vrste pitanja "što ako". Ako sam tek promijenio svoje okruženje, želim shvatiti kakav je to utjecaj, tako da tu istu promjenu mogu primijeniti i na druge instance ili druge baze podataka u mom okruženju. Želim biti u stanju imati neke informacije ili streljivo kako bih to promijenio s malo mira i znajući da će to biti dobra promjena. Dakle, kad bih mogao raditi to uporedno izvještavanje, moći rangirati svoje instance SQL-a, biti sposoban rangirati baze podataka jedni prema drugima i reći: „Koji je moj najveći potrošač CPU-a?“ Ili koji se najduže zadržava u uvjete čekanja i takve stvari? Tako da će puno tih podataka biti dostupno i sa alatom.
I posljednje, ali ne najmanje bitno, samo je sveobuhvatna sposobnost da vam treba alat koji će se moći nositi u bilo kojoj situaciji koja vam se dogodi, i što mislim pod tim, ako imate veliko okruženje s puno na primjer, vjerojatno ćete naići na situacije u kojima morate povući metrike koje tradicionalno nisu metrike koje bi DBA u nekim slučajevima čak želio nadzirati, ovisno o određenoj situaciji. Dakle, imati alat koji možete, taj proširivi, biti u mogućnosti dodati dodatne metrike i moći ih koristiti u istom obliku i na način na koji biste ih koristili ako biste koristili out-of-the-box. metrički, na primjer. Dakle, biti u stanju pokrenuti izvješća, biti u stanju upozoriti, osnovna vrijednost - sve o čemu se pričalo - također je ključni dio mogućnosti prognoziranja i izrade tako da dobijete odgovore koje tražite da biste mogli napraviti te odluke, krećući se naprijed.
Sada, kako to radi Diagnostic Manager, imamo centralizirani servis, grupu usluga koja se pokreće, prikuplja podatke u slučajevima od 2000 do 2016. I što onda radimo je da uzmemo te podatke i stavimo ih u središnje spremište i onda, očito, što dobro činimo s tim podacima je da radimo puno da bismo mogli dati daljnji uvid. Sada, uz to - i jedna od stvari koja nije ovdje - je li i nama usluga koja se pokreće usred noći, a to je naša služba za prediktivnu analizu, a to je i neki krcat broja i to nam pomaže da shvatimo i pomoći vam kao DBA ili djelujući DBA da biste mogli davati te vrste preporuka, da biste mogli pružiti i neki uvid u polaznu vrijednost.
Dakle, ono što ja volim raditi, a ovo je samo brzi primjer arhitekture, ovdje je veliki korak što nisu agenti ili usluge koji zapravo sjede na primjerima kojima upravljate. Ali ono što volim raditi je da vas zapravo zapravo prijavim za prijavu ovdje i brzo vam demo. I pusti me da i ja izađem i učinim to. Dakle, javite mi, mislim da Eric, možete li to vidjeti?
Eric Kavanagh: Shvatio sam to sada, da.
Bullett Manale: Dobro, pa ću vas provesti kroz neke od tih različitih dijelova o kojima sam govorio. I u suštini, dopustimo da započnemo s onim što je više u skladu s onim što je ovdje nešto što trebate učiniti, ili je ovdje nešto što je u vremenu u budućnosti i trebalo bi vam dati uvid u to. I to je u stanju stvarno predvidjeti - ili bih trebao reći dinamički anticipirati - stvari kako se događaju. U slučaju izvještaja jedna od stvari koju imamo u alatu su tri različita izvještaja prognoziranja. A u slučaju, na primjer, prognoze baze podataka, što bih vjerojatno mogao učiniti u slučaju da mogu predvidjeti veličinu baze podataka kroz određeno vrijeme, a ja ću vam samo ponuditi nekoliko primjera toga. Dakle, uzet ću moju revizorsku bazu podataka, koja je prilično intezivno I / O - ima puno podataka. Imamo, idemo vidjeti, dobro ovo napravimo ovdje, i samo odabiremo bazu podataka o zdravstvu ovdje.
Ali poanta je u tome što ne vidim samo koliki je prostor na ovome, ja sam u mogućnosti reći: "Gledaj, uzmimo podatke vrijedne zadnjih godina" - i ja ću se ovdje malo predati, zapravo nemam godina vrijedi podataka, imam podatke oko dva mjeseca - ali, zato što odabirem mjesečnu stopu uzorka, ja ću u ovom slučaju moći predvidjeti ili predvidjeti sljedećih 36 jedinica jer je stopa uzorkovanja postavljena na mjesece - to je jedinica, mjesec je dana - i tada bih mogao pokrenuti izvještaj da mi u osnovi pokaže gdje možemo predvidjeti naš budući rast za ove tri baze podataka. I možemo vidjeti da imamo različit stupanj razlike ili razlike između tri različite baze podataka, posebno u količini podataka koje oni povijesno konzumiraju.
Vidimo da podatkovne točke ovdje predstavljaju povijesne podatke, a zatim će nam linije pružiti prognozu, zajedno s brojevima koji to podupiru. Dakle, to možemo učiniti na razini tablice, to možemo i na razini pogona, gdje mogu predvidjeti koliko će se moji pogoni postići, uključujući točke montiranja. Mogli bismo predvidjeti istu vrstu informacija, ali još jednom, ovisno o brzini uzorka, omogućit ću mi da odredim koliko jedinica i gdje smo uzimali ono što želimo prognozirati. Primjetite i da imamo različite vrste predviđanja. Tako dobivate puno mogućnosti i fleksibilnosti kada dođe vrijeme za obavljanje predviđanja. Eto, to je jedna stvar, jer vam zapravo dajemo određeni datum i možemo reći „Hej, ovaj datum, ovo je mjesto na kojem bismo mogli predvidjeti rast vaših podataka.“ Uz to, ipak možemo vam pružiti s drugim uvidima koji su povezani s nekim analizama koje radimo u izvan radnog vremena i uslugom kada se provodi. Neke stvari čini pokušaj predviđanja stvari koje će se vjerojatno dogoditi na temelju povijesti vremena kada su se stvari događale u prošlosti.
Dakle, možemo vidjeti ovdje, zapravo, prognoza nam pruža neki uvid u vjerojatnost da ćemo imati problema tijekom večeri na temelju stvari koje su se još jednom dogodile u prošlosti. Dakle, očito je to sjajno, pogotovo ako nisam DBA, mogu vidjeti ove stvari, ali što je još bolje ako ja nisam DBA, ovo je kartica za analizu. Dakle, prije nego što je ovo ovdje u alatu, mi bismo prošli i ljudima pokazali proizvod, a oni bi bili "To je super, vidim sve ove brojeve, vidim sve, ali ne znam što da radim" (smijeh) "kao rezultat toga. "Dakle, ono što ovdje imamo je bolji način da shvatite, hoću li poduzeti akciju da bih joj pomogao u performansama, ako ću poduzeti akciju da pomognem zdravlju mog okruženje, mogućnost da pružam rangiran način pružanja tih preporuka, kao i korisne savjete u informacijama kako biste saznali više o tim preporukama i zapravo imali čak i vanjske poveznice na neke od tih podataka, koji će me pokazati i odvesti do razloga zašto navedene su preporuke.
I u mnogim slučajevima mogućnost pružanja skripte koja bi, kao što rekoh, automatizirala sanaciju ovih problema. Sada, dio onoga što se ovdje radilo s ovom analizom - i pokazat ću vam kada uđem u konfiguraciju svojstava ove instance i idem u odjeljak konfiguracije analize - imamo puno različitih kategorija koje su ovdje navedene, i dio toga, imamo optimizaciju indeksa i optimizaciju upita. Dakle, ocjenjivali smo ne samo same metrike i slične stvari, već i stvari poput opterećenja rada i indeksa. U ovom slučaju, zapravo napravite dodatnu analizu hipotetičkih indeksa. Dakle, to je jedna od onih situacija u kojoj ne želim, u mnogim slučajevima, ne želim dodavati indeks ako ne moram. Ali u nekom trenutku postoji neka tipka, gdje kažem: „Pa, tablica dobiva na veličini ili vrstama upita koji se izvode unutar radnog opterećenja sada ima smisla dodati indeks. Ali to ne bi imalo smisla možda prije šest tjedana. "Dakle, ovo vam omogućava dinamički stjecanje tog uvida u stvari koje će vjerojatno, kao što sam rekao, poboljšati performanse na temelju onoga što se događa u okolini, onoga što se događa unutar opterećenja i radeći takve stvari.
I tako ovdje dobivate puno dobrih informacija, kao i mogućnost automatske optimizacije tih stvari. Dakle, to je još jedno područje u kojem bismo mogli pomoći, u smislu onoga što nazivamo prediktivnom analizom. Sada, uz to, trebao bih reći, imamo i druga područja za koja mislim da uglavnom uglavnom pomažu u donošenju odluka. A kad govorimo o donošenju odluka, još jednom, kad možemo pogledati povijesne podatke, pružite nam neki uvid da nas dovede do mjesta gdje trebamo biti kako bismo poboljšali taj učinak.
Sada, jedna od stvari koje možemo učiniti jest da imamo osnovni vizualizator koji nam omogućava selektivni odabir onoga što bismo željeli - i dopustite mi da ovdje nađem pristojno - Idem na upotrebu SQL CPU-a, ali poanta je da možete ići unatrag, bez obzira na nekoliko tjedana da biste slikali te slike kako biste vidjeli kad su vam odmetnici, da biste vidjeli općenito govoreći, gdje ta vrijednost pada unutar razdoblja u kojima smo prikupljali podatke. A onda, uz to, primijetit ćete i da kada izađemo na samu instancu, možemo konfigurirati naše osnovne točke. A osnovne su vrijednosti vrlo važan dio mogućnosti automatizacije stvari i mogućnosti da ih se obavijesti. A izazov je, kako bi vam rekla većina DBA-a, taj što vaše okruženje ne radi uvijek isto, tijekom dana, nasuprot večernjim satima i onome što smo već spomenuli u primjeru s vremenskim periodima održavanja, imati visoku razinu CPU-a ili onoga što se možda događa.
Dakle, u slučaju ovdje, s tim stvarnim osnovnim linijama, možemo imati više polaznih linija, tako da bih mogao imati osnovnu vrijednost, na primjer, to tijekom mojih sati održavanja. Ali mogao bih jednako lako stvoriti osnovu za svoje sate proizvodnje. I poanta toga je kad uđemo u instancu SQL-a i zapravo imamo ove više osnovnih baza, tada bismo mogli predvidjeti i moći izvršiti neku vrstu automatizacije, neku vrstu sanacije ili općenito samo upozoriti, drugačije specifične za one vremenske prozore. Dakle, jedna od stvari koju ćete ovdje vidjeti jesu ove osnovne linije koje generiramo koriste povijesne podatke za pružanje te analize, ali što je još važnije, te pragove mogu statički promijeniti, ali ih također mogu dinamički automatizirati. Dakle, kako se pojavljuje prozor za održavanje, ili bih trebao reći osnovni prozor za održavanje, ovi se pragovi automatski prebacuju specifično na opterećenja s kojima se susrećem tijekom tog vremenskog prozora, nasuprot možda sredinom dana kada moja opterećenja nisu kao mnogo, kad opterećenja nisu toliko utjecajna.
Dakle, to je nešto drugo na umu, u smislu osnovne linije. Očito će vam ovo biti od velike pomoći, u smislu razumijevanja normalnog i razumijevanja, angažirajte se kad vam ponestane resursa. Kao što sam ranije rekao, druga vrsta stvari koju imamo u alatu, to će vam pomoći u donošenju odluka, osim polaganja i mogućnosti postavljanja upozorenja oko tih polaznih linija i pragova koje dinamički kreirate, samo što mogu pokrenuti čitav niz izvještaja koji mi pomažu da odgovorim na pitanja o tome što se događa.
Dakle, na primjer, ako imam 150 primjeraka kojima upravljam - u mom slučaju to ne radim, ovdje se moramo igrati pretvarajući se - ali ako bih imao sve svoje proizvodne instance i morao sam shvatiti gdje je područje koje sam treba mi pažnja, drugim riječima, ako ću imati samo ograničeno vrijeme da izvršim neku vrstu administracije za poboljšanje performansi, želim se usredotočiti na ključna područja. I tako, s tim rečenim, mogao bih reći: „Na temelju tog okruženja rangirajte svoje slučajeve jedni protiv drugih i dodijelite mi to mjesto po izbornoj cijevi.“ Dakle, da li je upotreba diska, upotreba memorije, da li čeka bilo da je vrijeme odgovora, u mogućnosti sam korelirati - ili treba reći da rangiraju one slučajeve jedni protiv drugih. Očito je da je instanca na vrhu svakog popisa, ako je to ista instanca, to je vjerojatno ono na što se zapravo želim usredotočiti, jer je očito opet na vrhu popisa.
Dakle, u alatu imate puno izvještaja koja vam pomažu u rangiranju okruženja na razini instance; ovo možete učiniti i na razini baze podataka, gdje svoje baze podataka mogu međusobno poredati. Osobito pragovima i područjima koja mogu postaviti, ovdje mogu postaviti i zamjenske znakove samo da se usredotočim na određene baze podataka, ali poanta je u tome da svoje baze podataka mogu usporediti na isti način. Što se tiče ostalih vrsta komparativne analize i one velike u ovom alatu, to je osnovna analiza koju imamo. Ako se ovdje pomaknete prema prikazu usluge, vidjet ćete da postoji osnovno izvješće o statistici. Sada će nam ovo izvješće pomoći da shvatimo ne samo što su vrijednosti metrike, već bih za određenu instancu mogao izaći i za bilo koju od tih metrika moći biti u mogućnosti pogledati osnovne crte tih metrika.
Dakle, što god to moglo biti, u postotku ili o tome što bih mogao izići i reći: "Pogledajmo da je osnovna vrijednost ovog prekinuta u zadnjih 30 dana", u tom slučaju će mi pokazati stvarne vrijednosti u odnosu na osnovnu i Mogao bih donijeti neke odluke koristeći se tim podacima, očito, tako da je ovo jedna od onih situacija, u kojoj će to ovisiti o onom pitanju koje postavljate u to vrijeme. Ali ovo će vam očito pomoći za mnoga pitanja. Volio bih da mogu reći da imamo jedno izvješće koje to sve radi, i to poput jednostavnog izvještaja, u kojem pritisnete i pritisnete tipku i ono samo daje odgovor na svako "što ako" pitanje na koje biste ikad mogli odgovoriti. Ali stvarnost je da ćete imati puno atributa i puno mogućnosti da budete mogli birati između ovih padajućih tipki da biste mogli formulirati ona pitanja "što ako" koja tražite.
Tako je mnogo tih izvještaja usmjereno na odgovor na te vrste pitanja. Dakle, važno je i to da su vam ta izvješća i, osim toga, sve stvari koje smo već pokazali u alatu, kao što sam već spomenuo, koji imaju fleksibilnost za uključivanje novih mjernih podataka, kojima se može upravljati, čak i kad možete kreirati brojila, ili SQL upite koji su ugrađeni u vaše anketne intervale da biste mi pomogli da odgovorim na ta pitanja, možda možda izvan okvira koji nismo predvidjeli da nadgledam. I mogli biste tada raditi sve iste stvari koje sam vam upravo pokazao: osnovnu liniju, pokretanje izvještaja i izradu izvještaja iz te metrike, te moći odgovarati i raditi puno različitih stvari koje vam ovdje prikazujem.
Uz to - i jedna je stvar s kojom se očito susrećemo u posljednje vrijeme - najprije je to bilo, svi prelaze ili prelaze na VM-ove. I sada imamo puno ljudi koji kreću u oblak. A postoji puno pitanja koja se postavljaju oko tih vrsta stvari. Ima li smisla prijeći u oblak? Hoću li uštedjeti novac prelaskom u oblak? Ako bih te stvari stavio na VM, na stroj s zajedničkim resursima, koliko novca mogu uštedjeti? Očito će se pojaviti i takve vrste pitanja. Dakle, na sve ove stvari imajte na umu, a pomoću Diagnostic Managera možemo dodavati i povlačiti iz virtualiziranih okruženja VMware-a i Hyper-V-a. Također možemo dodati instance koji su na oblaku, tako da okruženja poput Azure DB, na primjer, ili čak RDS, možemo izvući i metrike iz tih okruženja.
Dakle, postoji puno fleksibilnosti i puno mogućnosti odgovora na ta pitanja kako se odnosi na one druge vrste okruženja u koje vidimo ljudi kojima se kreću. I još uvijek postoji puno pitanja u vezi s ovim stvarima, a kako vidimo kako ljudi konsolidiraju ta okruženja, trebat će im i oni moći odgovoriti na ta pitanja. Dakle, to je prilično dobar pregled, recimo, Diagnostic Manager-a u odnosu na ovu temu. Znam da se pojavila tema poslovne inteligencije, a imamo i alat za poslovnu inteligenciju o kojem danas nismo razgovarali, ali također će vam pružiti uvid u odgovore na ove vrste pitanja jer se odnosi na vaše kocke i sve te različite vrste stvari. No nadamo se da je ovo dobar pregled, barem u smislu kako ovaj proizvod može pomoći u formuliranju dobrog plana.
Eric Kavanagh: U redu, dobre stvari. Da, baciću ga Ricku, ako je još uvijek napolju. Rick, imaš li kakvih pitanja od tebe?
Rick Sherman: Da, pa prvo, ovo je super, sviđa mi se. Posebno mi se sviđa širenje na VM-ove i oblake. Vidim da mnogi programeri aplikacija misle da ako ih ima u oblaku, ne trebaju ga podesiti. Tako-
Bullett Manale: Da, moramo to još platiti, zar ne? Još uvijek morate platiti za sve što ljudi stavljaju u oblak, pa ako njegov loš rad ili ako uzrokuje mnogo CPU ciklusa, više novca morate platiti, pa ne, još uvijek morate mjeriti ove stvari, apsolutno.
Rick Sherman: Da, vidio sam u oblaku puno loših dizajna. Htio sam pitati hoće li se koristiti i ovaj proizvod - znam da ste spomenuli BI proizvod i imate mnoštvo drugih proizvoda koji međusobno djeluju - ali biste li pogledali SQL izvedbu, pojedinačne upite u ovom alatu? Ili bi to bili drugi alati koji bi se koristili za to?
Bullett Manale: Ne, to bi, apsolutno. To je jedna od stvari koju nisam pokrivao, a to sam želio reći, dio upita. Imamo puno različitih načina za prepoznavanje izvedbe upita, bilo da je povezano sa, konkretno sa čekanjem kao što vidimo ovdje na ovom prikazu, ili je li povezano sa potrošnjom resursa upita u cjelini, postoji čitav niz načina na koje možemo analizirati upit izvođenje. Bilo da je riječ o njegovom trajanju, CPU-u, I / O-u, i još jednom, možemo i sami pogledati radna opterećenja kako bismo dobili određeni uvid. Preporuke možemo pružiti u odjeljku za analizu, a imamo i web-verziju koja pruža informacije o samim upitima. Tako mogu dobiti preporuke o nedostajućim indeksima i mogućnost pregleda plana izvršenja i sve takve stvari; također njegova sposobnost. Dakle, apsolutno, možemo dijagnosticirati upite na sedam načina do nedjelje (smijeh) i biti u stanju pružiti taj uvid u pogledu broja pogubljenja, bilo da se radi o potrošnji resursa, čekanju, trajanju i svim tim dobrim stvarima.
Rick Sherman: Ok super. I što je onda opterećenje samih instanci sa svim tim nadzorom?
Bullett Manale: To je dobro pitanje. Izazov s odgovorom na to pitanje je: ovisi li, isto kao i sve drugo. Mnogo toga što naš alat može ponuditi, nudi fleksibilnost, a dio te fleksibilnosti je da mu kažete što treba sakupljati, a što ne sakupljati. Na primjer, sa samim upitima ne moram sakupljati podatke o čekanju, ili mogu. Mogu prikupiti podatke vezane za upite koji premašuju trajanje izvršenja. Kao primjer za to, ako bih trebao ići u monitor upita za konfiguriranje i rekao bih: "Promijenimo ovu vrijednost u nulu", stvarnost je da alat u osnovi čini prikupljanje svih upita koji se pokreću, a to stvarno nije duha zašto je to tu, ali općenito govoreći, ako bih želio pružiti potpuni uzorak podataka za sve upite, mogao bih to učiniti.
Dakle, vrlo je relativno s onim što su vaše postavke, uglavnom gledano, izvan okvira. Ima negdje oko 1-3 posto režijskih troškova, ali postoje i drugi uvjeti koji će se primjenjivati. To također ovisi o tome koliko upita portova se pokreće u vašem okruženju, zar ne? Također ovisi o načinu prikupljanja tih upita i verziji SQL-a. Tako, na primjer, SQL Server 2005, neće se moći povući iz proširenih događaja, dok bismo mi to trag povukli iz traga. Dakle, to bi bilo malo drugačije u pogledu načina na koji ćemo prikupiti te podatke, ali to je reklo, kao što rekoh, valjda otprilike 2004. godine s ovim proizvodom. Prošlo je dugo vremena, dobili smo tisuće kupaca, tako da posljednje što želimo je imati alat za praćenje performansi koji uzrokuje probleme s izvedbom (smijeh). I tako se trudimo da se što više riješimo toga, ali općenito govoreći, oko 1-3 posto je dobro pravilo.
Rick Sherman: U redu, i to prilično nisko, tako da je to sjajno.
Eric Kavanagh: Dobro. Robin, imaš li kakvih pitanja od tebe?
Robin Bloor: Žao mi je, bio sam u zanemarivanju. Imali ste mogućnost za višestruku bazu podataka, a mene je zanimalo zašto možete gledati više baza podataka i samim tim možete znati da je veća baza resursa možda podijeljena između različitih virtualnih računala i tako dalje, i tako dalje. Zanima me kako ljudi to zapravo koriste. Zanima me što kupci rade s tim. Jer to me gleda, pa, sigurno, kad sam se zezao s bazama podataka, nešto što nikad nisam imao pri ruci. A ikada bih ikad u bilo kojem trenutku razmatrao jedan slučaj na bilo koji smislen način. Pa, kako ljudi to koriste?
Bullett Manale: Općenito govoreći, govorite li općenito samo o samom alatu? Kako ga koriste? Mislim, općenito, to o tome koliko je moguće imati središnju točku prisutnosti okoliša. Ako imaju mir i znaju da ako zure u ekran i vide zeleno, znaju da je sve dobro. Kada se problemi dogode i očigledno je većina slučajeva iz perspektive DBA-a, puno puta se ti problemi događaju kada su ispred konzole, tako da možete biti obaviješteni čim se problem dogodi. Ali uz to, biti u stanju razumjeti kada se problem dogodi, biti u stanju doći do srži informacija koje im pružaju određeni zaključak u smislu zašto se događa. I tako je, mislim, najveći dio: biti proaktivan u tome, ne biti reaktivan.
Većina DBA-ova s kojima razgovaram - a ne znam, to je dobar postotak njih - nažalost su još uvijek u reaktivnom okruženju; čekaju da im se obraća potrošač i kažu im da postoji problem. I tako, vidimo puno ljudi koji se pokušavaju odvojiti od toga i mislim da je to veliki dio razloga zašto se ljudima sviđa ovaj alat taj što im pomaže da budu proaktivni, ali također im omogućuje uvid u ono što se događa , u čemu je problem, ali u mnogim slučajevima ono što mi najmanje nalazimo - a možda nam upravo to govore DBA-ovi - ali DBA-i su, njihov percepcija, uvijek njihov problem, čak i ako je njegov programer koji je napisao aplikaciju to nije dobro napisao, oni su oni koji će biti krivi što uzrokuje da oni preuzmu tu aplikaciju u svoje sustave ili poslužitelje, a onda kada je izvedba loša, svi upućuju na DBA kaže: "Hej, tvoja je krivica."
Dakle, ovaj će se alat mnogo puta koristiti kako bi pomogao DBA-i da kaže da je "Hej, tu leži problem, a ja nisam ja." (Smijeh) Moramo poboljšajte ovo, bilo da se radi o promjeni upita ili što god moglo biti. U nekim će slučajevima pasti u njihove kante s obzirom na njihovu odgovornost, ali barem imati alat kako bi im mogli pomoći da to shvate i to znaju, a to rade pravovremeno, očito je idealan pristup.
Robin Bloor: Da, većina web mjesta koja poznajem, ali prošlo je dosta vremena od kada sam bio vani i gledao razne web stranice s više baza podataka, ali uglavnom ono što sam koristio da utvrdim je da će postojati DBA koji su usredotočeni na nekolicinu baza podataka. A to bi bile baze podataka da će, ako ikad padnu, to biti veliki problem za posao, i tako dalje, i tako dalje. A ostale, s vremena na vrijeme, samo će prikupljati statističke podatke da vide da im ponestaje prostora i da ih nikad ne pogledaju. I dok ste radili demonstraciju, ja sam gledao ovo i razmišljao sam dobro, na ovaj ili onaj način, proširite, samo pružajući tako nešto za baze podataka koje su često, nikoga nije previše zanimalo, jer oni imaju rast podataka , imaju porast primjene i s vremena na vrijeme. Proširite pokrivenost DBA na prilično dramatičan način. Dakle, o tome se zapravo radi u pitanju, da li s ovakvim alatom na kraju možete u velikoj mjeri pružiti DBA uslugu svakoj bazi podataka koja se nalazi u korporativnoj mreži?
Bullett Manale: Mislim, izazov je što je, kao što ste rekli prilično elokventno, poput nekih baza podataka do kojih su stariji DBA-i, a potom i do kojih nije toliko stalo. I način na koji se ovaj proizvod određuje, na način na koji je licenciran, na pojedinačnoj osnovi. Pa, pretpostavljam, možete reći, prag kad ljudi odluče "Hej, ovo nije dovoljno kritična instanca da želim upravljati ovim alatom". To kaže, postoje i drugi alati koji su više , Valjda, usluživši one manje važne instance SQL-a. Jedan od njih bi bio poput upravitelja zaliha, gdje vršimo lagane zdravstvene provjere u odnosu na slučajeve, ali uz to otkrivamo ono što radimo, pa identificiramo nove slučajeve koji su preneseni putem interneta i od tada kao DBA mogu reći: "OK, evo nove instance SQL-a, je li to Express? Je li to besplatna verzija ili je to poslovna verzija? "To je vjerojatno pitanje koje bih si želio postaviti, ali drugo, koliko mi je ta instanca važna? Ako to nije toliko važno, možda bih ovaj alat izbacio i učinio to, generičkim, ono što bih nazvao generičkim zdravstvenim pregledima u smislu da su one elementarne vrste stvari do kojih mi je stalo kao DBA: Da li se pogon puni? Da li poslužitelj odgovara na probleme? Glavne stvari, zar ne?
Dok je s Diagnostic Manager-om, alat koji sam vam upravo pokazao, spuštat će se na razinu upita, preći će na preporuku indeksa, pogledati plan izvršenja i sve te dobre stvari, dok je ovo uglavnom usredotočeno o tome tko je vlasnik, što sam ja vlasnik i tko je za to odgovoran? Koje pakete servisa i hitne popravke imam? A posluju li moji poslužitelji s glavnim sastojcima onoga što bih smatrao zdravom instancom SQL-a? Dakle, da odgovorim na vaše pitanje, malo je miksa. Kad imamo ljude koji gledaju na ovaj alat, oni obično gledaju kritičniji niz slučajeva. To je rečeno, mi imamo nekoliko ljudi koji kupuju svaku instancu koju imaju i upravljaju njom, pa to samo ovisi. Ali kažem vam, sveukupno, tu je definitivno prag onih koji smatraju da je njihovo okruženje dovoljno važno da bi imali takav alat za upravljanje tim slučajevima.
Robin Bloor: U redu, još jedno pitanje prije nego što ga predam Ericu. Dojam koji se stječe samo gledanjem industrije jest da baze podataka još uvijek imaju život, ali svi se podaci prelijevaju u sva ta jezera podataka i tako dalje. To je stvarno, a hype nikad ne odražava stvarnost, pa me zanima kakva stvarnost opažate vani? Jesu li važne baze podataka u organizaciji doživljavaju li tradicionalni rast podataka, za koji sam nekada razmišljao kao 10 posto? Ili rastu više od toga? Da li veliki podaci čine ove baze balonima? Kakvu sliku vidite?
Bullett Manale: Mislim da je u mnogim slučajevima došlo do premještanja nekih podataka u one druge segmente gdje ima više smisla, kada postanu dostupne i druge tehnologije. Od nedavno, neki veći podaci. Ali, rekao bih, te su baze podataka u puno slučajeva teško generalizirati i uzrokovati da su svi malo drugačiji. Općenito govoreći, vidim neke razlike. Vidim, kao što rekoh, ljudi prelaze na elastične modele u mnogim slučajevima, jer žele povećati resurse, a ne toliko u drugim područjima. Neki se ljudi kreću prema velikim podacima. Ali teško je osjetiti percepciju, jer kažete, ljudi koji razgovaraju sa svima imaju tradicionalne baze podataka i to koriste u okruženju SQL Server.
U tom smislu, recimo u smislu samog SQL-a, definitivno još uvijek mislim da je njegov tržišni udio sve veći. I mislim da postoji puno ljudi koji još uvijek kreću prema SQL-u s drugih mjesta poput Oraclea, jer je njegova pristupačnija i čini se očigledno, kako SQL verzije postaju naprednije - i vi to vidite sa najnovijim stvarima koje se događaju u vezi sa SQL-om, u smislu enkripcije i svih ostalih mogućnosti zbog kojih je okruženje ili platforma baze podataka - pretpostavljam da je to očigledno vrlo kritično sposobno za misiju. Dakle, mislim da sam i to vidio. Tamo gdje vidite promjenu, to se i dalje događa. Mislim, događalo se prije 10 godina, mislim da se to i dalje događalo u smislu SQL Servera, gdje raste okolina i raste tržišni udio.
Robin Bloor: U redu, Eric, pretpostavljam da publika ima pitanje ili dva?
Eric Kavanagh: Da, daj da ti jedan brzo prebacim. Zapravo je prilično dobro pitanje. Jedan od sudionika se pita hoće li ovaj alat reći hoće li tablici trebati indeks za ubrzavanje upita? Ako je tako, možete li pokazati primjer?
Bullett Manale: Da, pa ne znam imam li ga za posebno dodavanje indeksa, ali možete vidjeti ovdje, ovdje imamo preporuke za fragmentaciju. Također vjerujem da smo upravo imali, a ovo je bilo dio Dijagnostičkog upravitelja koji nudi web-verziju, gdje mi kaže da imam nedostajući indeks. A mi možemo vidjeti te preporuke i to će nam reći potencijalni dobitak od toga indeksiranjem tih podataka. Drugo što bih trebao napomenuti jest da kada napravimo preporuke, za mnoge od njih će se za to stvoriti skripta. To nisu dobar primjer, ali vi biste mogli vidjeti, da, situacije u kojima bi indeks - ili duplikat indeksa ili dodavanje indeksa - poboljšao performanse, i kao što sam već rekao, radimo puno da kroz hipotetičku analizu indeksa. Dakle, to stvarno pomaže u smislu razumijevanja posla, da biste to mogli primijeniti na preporuku.
Eric Kavanagh: To je sjajno, a ovo će me uputiti u konačne komentare ovdje. I Robin, ja i Rick, čuli smo se već mnogo godina, govore o samonamjenjivanju baza podataka. To je baza podataka za samoindustriranje! Sve što vam mogu reći je: Ne vjerujte im.
Bullett Manale: Ne vjerujte u hipe.
Eric Kavanagh: Možda postoje neke sitnice koje se dinamički završavaju, ali čak i to, možda biste željeli da to provjerite i uvjerite se da ne radi nešto što ne želite. Dakle, već dugo vremena trebat će mi takvi alati da bi shvatili što se događa na razini baze podataka i kao što je Robin rekao, podatkovna jezera su fascinantni pojmovi, ali postoji vjerovatno o onolikoj šansi da ih preuzmu koliko postoji čudovište iz Loch Ness-a u bilo kojem trenutku. Dakle, samo bih još jednom rekao, u stvarnom svijetu postoji puno tehnologije baza podataka, trebamo ljude, DBA-e, da bismo ovo pregledali i sintetizirali. Možete reći, trebate znati što radite kako bi ove stvari funkcionirale. Ali trebaju vam alati koji će vam dati informacije da biste znali što radite. Dakle, dno crte je DBA će biti u redu.
I velika hvala Bullett Manaleu i našim prijateljima iz IDERA-e. I naravno Rick Sherman i Robin Bloor. Sve te internetske emisije arhiviramo, pa se uskočite na internet insideanalysis.com ili na našu partnersku web stranicu www.techopedia.com za više informacija o svemu tome.
I s tim se, oprosti, narode. Hvala još jednom, dobro ćemo razgovarati sljedeći put. Čuvaj se. Doviđenja.