Turinys:
Autorius „Techopedia“ darbuotojai, 2016 m. Gegužės 9 d
„Takeaway“: Šeimininkas Ericas Kavanaghas apklausa Marką Madseną, Dezą Blanchfieldą ir Bullettą Manale'ą apie delsą ir atlikimą.
Šiuo metu nesate prisijungęs. Jei norite pamatyti vaizdo įrašą, prisijunkite arba prisiregistruokite.
„Techopedia“ turinio partneris
„Techopedia“ personalas yra susijęs su „Bloor Group“ ir su juo galima susisiekti naudojant dešinėje pateiktas parinktis. Norėdami sužinoti daugiau informacijos apie tai, kaip mes dirbame su pramonės partneriais, spustelėkite čia.- Profilis
- Interneto svetainė
Ericas Kavanaghas: Ponios ir ponai, sveiki ir dar kartą pasveikinkite „Hot Technologies“! Taip išties! Mano vardas Ericas Kavanaghas, tai mūsų „Hot Tech“ šou, partnerystė su mūsų gerais draugais iš „Techopedia“. Internetinėje svetainėje Techopedia.com gaukite naujausių žinių apie plačią įmonių technologiją; jie, be abejo, taip pat apima vartotojui reikalingus dalykus. Mes savo programoje sutelkiame dėmesį į verslą, todėl tą ir veiksime šiandien.
Čia yra tavęs, apie kurį tikrai ir pakankamai, apie mane, paspausk mane į „Twitter“ @eric_kavanagh, man patinka „Twitter“, man patinka tikrinti tuos dalykus, tai puikus būdas palaikyti ryšį su žmonėmis, gerai bendrauti ir vienas su kitu. -vieni pokalbiai.
Taigi apie ką mes kalbame? Šie metai yra karšti, tai yra visa galimybių visuma, į kurią šiandien žvelgiame informacijos valdymo pasaulyje, ir tai, apie ką mes šiandien kalbėsime, bus klausimų, tai paspartins užklausas.
Manau, kad pamiršau paminėti pavadinimą „Spektaklio spektaklis: atsisveikink su latencija“. Na, kas nori latencijos? Niekas nenori delsti, latencija yra tada, kai tu sėdi ten, paspaudi mygtuką ir lauki, kol kažkas nutiks, ir niekas to nenori. Vaikams tai nepatinka, jie nemano, kad tai šaunu, ir suaugusiems tai nepatinka. Mes visi buvome sugadinti dėl interneto greičio ir norime dalykų greitai, norime dalykų dabar ir kalbėsime visa tai šiandien savo laidoje.
Analitikas Markas Madsenas yra su mumis šiandien iš trečiosios prigimties, vienas iš mūsų nuolatinių atstovų. Mūsų naujasis duomenų mokslininkas Dezas Blanchfieldas paskambino iš Sidnėjaus, Australijos. Ir tada Bullett Manale, taip, iš tikrųjų, tai jo vardas, iš tikrųjų tai turėtų būti du T. „Bullett Manale“ yra mūsų svečias iš „Idera“, labai, labai įdomios įmonės, kuri gamina daug ką. Aš jau žinau apie juos, iš kurių vienas yra dar kurį laiką nusipirkę įmonę pavadinimu „Precise“. Aš žinojau, kad jų generalinis direktorius vardu Zohar Gilad. Kaip tai yra vardas? Jis buvo vienas gudrus vaikinas.
Bet žmonės, jūs vaidinate reikšmingą vaidmenį šioje internetinėje transliacijoje užduodami klausimus, todėl nedvejokite, siųskite savo klausimus bet kuriuo metu - tai galite padaryti naudodamiesi internetinių transliavimo pulto klausimų ir atsakymų komponentu. apatiniame dešiniajame kampe. Taip pat galite kalbėtis su manimi ir aš tai kalbėsiu per pranešėjus. Jau turime, kas skambina iš Italijos, „Ciao, ciao. Ateikite staiga? “Gerai, kai aš stosiu pirmąją Marko eilutę, atiduosiu denį Markui. Pažymėk, jūs dabar turite „WebEx“. Nuimkite, grindys yra jūsų.
Markas Madsenas: Ačiū, Ericai. Nors aš nepradėsiu vidurio, pradėsiu pradžioje. Taigi tik keli komentarai, skirti diskusijai su „Dez“ ir „Idera“ užmegzti - tam tikra valstybės padėtis su plėtra, duomenų bazėmis ir operacijomis. Ir jūs žinote, jei šitaip pažvelgsite, duomenų bazių ir programų rinkoje vis dar turime šias dvi pasaulių problemas, nes kūrėjai DBA vertina kaip žmones, kuriems jie rūpi. Jūs turite sukurti duomenų modelius, neturite prieigos prie to, negalite sukurti to, negalite dėti rodyklės kiekviename kiekvienos duomenų bazės lentelės stulpelyje, kad būtų greičiau. Ir, žinoma, kodėl mums reikia modelių? Tai tik duomenų struktūros, jei mes jas pakeisime, ar negalite jų tiesiog nurašyti nuosekliai?
Problema ta, kad kūrėjai žino kodą ir programas, tačiau du dalykai, kurių jie dažnai nežino, yra lygiagrečiai, tuo pačiu metu vykstantis programavimas ir duomenų bazės bei po jais esančios operacinės sistemos. Buvęs branduolio kūrėju, operacinėmis sistemomis ir duomenų bazėmis, galiu pasakyti, kad suderinamumas ir lygiagretumas yra tikrai sunkus, todėl daugelis dalykų, kuriuos išmoksite išgauti iš savo kodo, tikrai pradeda subyrėti, kai esate darbas su duomenų baze. Ir našumas atrodo puikus, bandymo aplinka atrodo puiki, taip pat - klausimų ir atsakymų aplinka, tada ji patenka į tikrąją sistemą, o tada staiga nėra tokia puiki. Kadangi tai yra daugialypė, kaip kodas veikia su duomenų baze, kaip jis veikia su aplinka, o tikrai paprasta praktika gali turėti drastiškų padarinių, atsižvelgiant į tai, kokią skalę naudojate.
Ir kai jūs pradedate kalbėti apie išorines programas, be abejo, išoriškai veikiančias programas, žiniatinklio programas, gali būti tikrai sunku, nes viskas yra puiku, kol staiga jie išsilygina, o ne. Pataikysite į šias įdomias plokšteles, kurioms suprasti reikia daug niuansų.
Daiktų vaizdas yra DBA vaizdas. DBA mano, kad yra operacijų, kurios didžiąją dalį laiko, nuo 80 iki 90 procentų, praleidžia operacijomis, o gal 10–20 procentų - su išankstiniu vystymo darbu. Žvelgiant iš šios perspektyvos, jūs arba mokate dabar, arba mokate vėliau, o jei visą savo laiką praleidžiate iš anksto, vėliau turėsite daug geresnių galimybių, palyginti su plėtra, kuri linkusi tyrinėti savybes. erdvėje, ir bandoma išsiaiškinti, kaip geriausia elgtis. Taigi, mes turime problemų, o dabar turime nesuderinamų metodikų - nuolatinį diegimą, programų kaupimą, kai jos yra pasirengusios, periodiškai atliekant kodą, dirbant parduotuvėje, kurioje praktikuojami tobulinimai. Toks dalykas pagreitina vystymąsi, tačiau visa praktika, susijusi su duomenų baze, ir tai, ką daro DBA, ir tai, ką išmokė sistemos valdytojai, IT operacijų praktika nesustojo.
Jei pagalvojate, dauguma DBA veikia pokyčių kontrolės aplinkoje, palyginti su nuolatinio diegimo aplinka. Viskas priklauso nuo stabilumo ir kontrolės, palyginti su pokyčių greičiu ir grįžtamumu. Nuolatinis diegimas, jei nepavyksta atsisakyti pokyčių, kyla problemų, todėl viskas turi būti sukurta taip, kad būtų lengvai grįžtamoji ir keičiama kodais, o tai ne visai tinka taip, kaip veikė reliacinė duomenų bazė, kūrimo praktika ir valdymo praktika. .
Jūs taip pat susiduriate su šiomis problemomis, kad, būdami DBA, turite būti iniciatyvesni, nes iki to laiko, kai išgirdote apie šią problemą, šimtas tūkstančių žmonių užpildo skundų formas jūsų svetainėje. Tai palieka jums naujų dalykų, kurių neišmesite iš senos aplinkos. Žinote, tokie dalykai kaip geresnis stebėjimas ir perspėjimas. Tuo pačiu metu duomenų bazės daugėjo, mes turime daugiau programų nei bet kada anksčiau, kad palaikytume daugiau dalykų nei bet kada anksčiau. Jie yra viduje, jie yra lauke, jie yra visur. Ir daugiau nepriklausomų duomenų rinkinių, skirtų analizei, žmonės pradeda kurti duomenų bazes, nes, be abejo, dabar lengva, galite nustatyti virtualią mašiną. Jei turite debesies tiekėją arba vidinį debesį, galite nedelsdami juos parodyti, ir tai keičia visą jūsų viešųjų pirkimų kelią.
Senas viešųjų pirkimų kelias buvo: „Aš turiu laiko gauti serverį, įsikrauti jį į lentyną, paskirstyti vietą, gauti saugyklą, sutvarkyti duomenų bazę ir atlikti reikalus“, palyginti su tuo, kas nors perbraukia kreditinę kortelę ir eina per penkias minutes. Jei tai padarysite, ta moderni kūrimo aplinka veikia labai skirtingais tempais, todėl nesunku kurti duomenų bazes, o tai tik sukuria šią platinimo problemą, kaip niekur anksčiau matėme. Ir tai vyksta jau dešimt metų, tai niekam nėra naujiena, bet tai taip pat reiškia, kad veiklos aplinka tapo sudėtingesnė.
Visa kliento serverio aplinka tikrai pasikeitė, nes tai jau nėra kliento serverio pasaulis. Tuomet turėjote serverį, duomenų bazę. Jei kažkas ne taip, žinojote, į kurį serverį eiti, žinojote, kaip valdyti jame esančius išteklius, nes geriausia praktika buvo viena duomenų bazė, vienas serveris. Virtualizacija pradėjo tai skaidyti, debesis dar labiau ją sulaužo, nes tai, kas, jūsų manymu, yra duomenų bazės serveris, yra tik programinė įranga. Taigi aplinka nėra tikra. Tai, kas yra aplinka, yra tikrovė, ir tai gali būti ašmenų stovas arba didelis serveris, išpjaustytas į dalis, jūs tikrai nežinote.
Viskas, kas susiję su duomenų bazių administravimu ir našumo valdymu, ir tai, kokios duomenų bazės buvo sukurtos atsižvelgiant į griežtą vieno serverio valdymą ar saują serverių ir porą duomenų bazių, visko kontroliuoti negalite. Jūs sėdite ten, mašinoje, tačiau pralaidumo virtualūs valdytojai negali lengvai skaidyti, todėl atmintyje ir procesoriuje viskas gali būti gerai, tačiau jums trūksta resursų, kurių negalima sutvarkyti, ir tada, kai bandai tai ištaisyti, senasis modelis būtų sunkiai dirbęs, gavęs didesnį serverį ir ką nors panašaus nuveikęs, dabar jis gali būti tikrai paprastas, tiesiog pridėk virtualų kursą, tiesiog pridėk atmintį prie VM ir viskas išspręsta. Bet kas atsitiks, jei jūsų VM yra perpildytame serveryje ir reikia jį perkelti? Arba kas nutinka, jei esate AWS sistemos dydžio ir pasiekėte maksimalų dydį, dabar kur jūs einate?
Taigi jūs turite visas šias problemas, kai aplinka dabar yra duomenų bazės dalis, jūs pakuojate aplinką su duomenų baze, visais specialiaisiais ištekliais, viskas, kas programoje yra konfigūracijos dalis, konfigūracija ten bus išstumta. Tai iš duomenų bazės aplinkos, daug sunkiau valdyti ir valdyti.
Jei pažvelgtumėte į tai, ką veikė duomenų bazių centrai, jie sėdėjo ant rankų, tiesa? Mes nutolome nuo šios idėjos laikyti duomenų bazes ir serverius kaip naminius gyvūnus. Tarnai turi vardus, jūs elgiatės su jais lyg su unikaliais dalykais, elgiatės su jais kaip su galvijais, tvarkote bandą. O bandų tvarkymo problema yra ta, kad jei jų nekontroliuojate, jie galų gale gali sustingti, o sustingimas nėra geras dalykas. Mums reikia geresnių stebėjimo priemonių, reikia geresnių būdų, kaip tvarkyti šią medžiagą, ir žinoti, kas tai paveikė. Sename modelyje buvo lengviau, nes jūsų darbuotojai ir visos jūsų valdymo sistemos jums pasakė, bet kai jūsų serverio vardas yra UPC kodas, tai sunku suprasti.
Jūs negalite sau leisti melagingų perspėjimų, negalite sau leisti dalykų, kurie sako: „Yra problema dėl šio kompiuterio ir kad mašinoje yra 30 duomenų bazių.“ Jūs negalite sau leisti, kad daiktai neturėtumėte jokios istorijos. Stebėjimo pultai yra puikūs, kai jie užsidega, tačiau jei raudona lemputė vėl šviečia žalia spalva ir jūs nežinote kodėl, o jūs neturite jokios istorijos, kur grįžti, kad pažvelgtumėte į tai, kas lėmė tai, o kas kontekste buvo, jūs esate bėdų. Mums reikia sistemų, kurios mus stebės, mums reikia geresnio stebėjimo, sprendžiant kreivas periodiškas problemas, kurios palaiko tą duomenų istoriją.
Geresni dalykai ir nesudėtingos metrikos slenksčiai, kurie suteikia mums pagrindinę metriką, tačiau tiesiogiai nenukreipia į tai, kas įprasta, kas nenormalu ir kaip dažnai šios problemos atsiranda. Tai, apie ką mes iš tikrųjų kalbame, yra stebėjimo aplinkos ir veiklos efektyvumo derinys, o pardavėjai sėdėjo ant rankų. Jie nedavė mums geresnių įrankių. Turime sistemų, turinčių daugiau procesoriaus ir atminties, nei žinome, ką su tuo visu daryti, ir vis dėlto mes vis dar pasikliaujame neautomatinėmis intervencijos modeliais, mes neleidome mašinos dirbti, kad ji mus nukreiptų, kad mus nukreiptų į problemų vietą., mes dar neįsigilinome į šį naują stilių, kuris yra: „Čia yra problema, galite tai padaryti, kad ją išspręstumėte“ arba „Kyla našumo problema, kuri iš tikrųjų yra susijusi su šiuo konkrečiu SQL sakiniu. Čia yra trys dalykai naudokite pataisydami tą SQL teiginį. “Taikydami euristiką, taikydami mašininio mokymosi modelius, kurie gali pažvelgti į jūsų sistemos naudojimo modelius, kad būtų galima pastebėti problemas ir išvengti klaidingų perspėjimų. Naudodamiesi mašina darykite tai, ką mašina daro geriausiai, kad padidintumėte DBA arba padidintumėte asmenį, kuris turi spręsti našumo problemas.
Tai naujas būdas, priešingai nei senasis stilius. Kyla šios duomenų bazės problema, viskas vyksta lėtai, todėl turime naujų metodų, naujų būdų tai padaryti ir turėtume juos pritaikyti, ir štai rinka eina. Matote, kad tai pradeda keistis ne su dideliais pardavėjais, bet su trečiųjų šalių įmonėmis. Tai atspindi tai, kas nutiko prieš 20 metų, kai duomenų bazių pardavėjai nepateikė nei vieno dalyko, padedančio valdyti sistemas. Taigi tokia yra rinkos kryptis, ir aš norėčiau tai pakeisti Erikui.
Erikas Kavanaghas: Gerai, aš perduosiu tai Dezui. Ir Dezai, atimk, grindys tavo.
Dezas Blanchfildas: Ačiū, Markai. Jūs atlikote fantastišką darbą, aprėpdami jo techninį komponentą. Pažvelgsiu į tai šiek tiek kitu kampu, norėdamas pabrėžti, kas nutiko likusiame pasaulyje, kiek tai daro poveikį verslui ir aplink esančioms duomenų bazėms. Leisk man tiesiog peršokti į savo pirmąją skaidrę.
Remdamasis tuo, ką ką tik apėmėte iš techninės ir kūrėjų pusės, matau, kad įmonės susiduria su duomenų ir duomenų bazių iššūkiu, ir akivaizdu, kad mes pastebėjome šį reikšmingą poslinkį link Ši didelių duomenų samprata, tačiau duomenų bazės vis dar tebėra širdis ir siela ten, kur organizacijos saugo savo verslo informaciją, ir tai vyksta nuo durų iki galutinio biuro. Kiekvieną organizacijos dalį paliečia tam tikros rūšies duomenų bazė ir ją palaiko duomenų bazė. Labai retai aš einu į projekto diskusijas ar į naujoviškų strateginių pokalbių formą organizacijoje, kurioje yra duomenų bazės ar duomenų bazės sistemos tema. nekyla ir visada kyla klausimų apie tai, apie ką ką tik girdėjome, apie našumą ir saugumą, kaip vystymasis atliepia šį iššūkį, kur tinka duomenų bazės ir ar mūsų aplinka ir taikymas yra žinomi? aplinkoje kalbėtis, o kaip su įrenginiais ir mobilumu?
Tai vis dar labai, labai karšta tema ir ilgą laiką buvo įtraukta į didžiąją dalykų schemą, kiek tai susiję su šiuolaikinėmis technologijomis. Šiuo klausimu manau, kad beveik viskas, ką mes darome kasdieniniame gyvenime, kasdieniame gyvenime, tai yra, dabar palaikoma tam tikros formos duomenų bazėse. Kai mes galvojame apie visus mus supančius dalykus, nesvarbu, ar tai sąskaita, kuri kiekvieną dieną siunčiama į paštą už kokią nors mūsų perkamą paslaugą, ją neišvengiamai atspausdina sistema, kuri bendrauja su duomenų baze, ir mes ten esame. Mūsų telefonuose yra duomenų bazės su kontaktais, skambučių žurnalais ir kita.
Kad ir kur eitume, pokalbių ir sistemų, kurias naudojame, yra tam tikros duomenų bazės ir dažniausiai yra gana skaidrios mums, tačiau faktas yra tas, kad jos ten yra. Taigi maniau, kad greitai išsiaiškinsiu, kodėl tai per trumpą laiką tapo šiek tiek problema. Iš pradžių duomenų bazės idėją sugalvojo šis puikus ponas Edgaras Coddas. Dirbdamas IBM jis pakeitė pasaulį tiek, kiek reikia duomenų valdymui, sukurdamas koncepciją, kurią dabar vadiname reliacine duomenų baze.
Iš pradžių duomenų bazė buvo duomenų bazė ir gyvenimas buvo geras, ji buvo gana nesudėtinga ir stulpeliuose, ir nuorodose, ir taip toliau, lentelėse ir programinės įrangos kūrime buvo gana nesudėtinga, o našumas iš tikrųjų nebuvo tokia didelė problema - tai buvo nauja įdomi technologija. Duomenų bazes mes pasiekėme per tam tikros formos terminalus, ir jūs tikrai galite sugadinti tik 3270 terminalo, esančio pagrindiniame korpuse, pabaigą, ir visada kitų tipų terminalus, tas kitas sistemas. Daugeliu atvejų senojo stiliaus terminalai buvo labai panašūs į dabartinius internetinius įrenginius. Tai yra, kad užpildydami formą ekrane pačiame terminale paspausite klavišą Enter ir išeisite, tai būtų šaudyti kaip vienas paketas, kaip prašymas, ir foninė sistema su tuo susidoros. Iš esmės tai, kas šiomis dienomis atsitinka žiniatinklio naršyklėje, kai įvedate nuorodą į interneto naršyklę, ir ta forma paprastai negrįžta realiuoju laiku į sistemą, nors šiomis dienomis AJAX tai nėra visiškai atvejis.
Bet tada kažkas atsitiko, atsirado ateitis, o visai neseniai - internetas ir beveik vakar - sek internete 2.0 ir visai šalia mūsų - daiktų internetas. Ateityje įvykusiame duomenų bazių pasaulyje tiesiog sprogo ir sąveika su duomenų bazėmis tapo dalyku, kurį mes visi padarėme pagal numatytuosius nustatymus. Nebuvo taip, kad važiuotumėte kur nors ką nors padaryti, pavyzdžiui, nusipirktumėte. lėktuvo bilietą ir norėdami nukeliauti į kitą planetos pusę, kažkas terminale turėjo įvesti visą jūsų informaciją ir patekti į duomenų bazę bei atsispausdinti bilietą.
Beveik viskas, ką mes darome dabar, nesvarbu, ar tai „Google“ kabinos užkabinimas su programa, ar šokinėjimas internetinėje bankininkystėje, viskas, ką mes darome kasdien, turėdami kažkokią sistemą, ją maitina duomenų bazė. O kai atsirado internetas, tai buvo šiek tiek lengviau mums atrasti per internetinę naršyklę, tada atsirado internetas 2.0 ir viskas tapo mobili, o dalykų mastelis tiesiog sprogo. Tiesą sakant, mano mėgstamiausia linija šioje temoje yra ta, kad „Internetas sujungė viską, internetas 2.0 pavertė jį mobiliu ir socialiniu, ir viskas pasidarė labai, labai didelis, o dabar mes turime internetą ir daiktus, ir IoT… Yikes !!“ Mes net nepradėjome įsivaizduoti, koks daiktų interneto poveikis pasauliui yra duomenų bazių sistemose.
Taigi šiuolaikiškai kalbant, tai, ką mes galvojome kaip terminalą, iš tikrųjų tapo šiais dalykais: tai mobilieji telefonai, tai įvairių rūšių planšetiniai kompiuteriai, asmeniniai vartotojui ar įmonei skirti didelio ekrano planšetiniai kompiuteriai, nešiojamieji kompiuteriai ir tradicinis darbalaukis. tam tikra forma. Tame viename paveikslėlyje galite pamatyti beveik visas sąsajos formas, kurias dabar naudojame kalbėdami su duomenų bazių sistemomis ir programomis, kurias palaiko tie, iš mažų mūsų rankose esančių dalykėlių, kurie vaikšto aplink ir, atrodo, esame priklijuoti. kelias į šiek tiek didesnes versijas, „iPad“ ir kitas planšetines kompiuterius bei „Microsoft“ paviršius “, į kasdienius nešiojamuosius kompiuterius, kurie visada yra profesinėje aplinkoje ir pan. Žmonės linkę įsigyti nešiojamąjį kompiuterį, o ne fiksuotą darbalaukį, tačiau, mano manymu, jie yra modernus terminalas ir yra priežastis, dėl kurios duomenų bazės patiria įvairius iššūkius, susijusius su valdymo veikimu, o ne tik plėtra.
Taigi aš manau, kad tai yra vienas didžiausių iššūkių, su kuriais verslai vis dar susiduria kiekvieną dieną. Visi manė, kad duomenų bazės yra vienintelė mūsų problema, jos nėra. Taigi, koks visas nerimas? Na, kai einame nuo vieno galo prie kito su komercinėmis prasmėmis, susijusiomis su duomenų bazėmis, ir Markas labai gerai apėmė techninius komponentus, tačiau komercine prasme, kaip organizacija, mes galvojame apie duomenų bazes. Mes susiduriame su visais dalykais, pradedant nuo pagrindinio projektavimo ir tobulinimo. Pradėjus verslą, jie galvos apie programų plėtojimą, galimybių plėtojimą ar net tam tikros formos esamų programų įgyvendinimą. Turi būti vykdoma tam tikra projektavimo ir tobulinimo forma, todėl reikia daug galvoti apie tai, kaip šios duomenų bazių sistemos bus diegiamos, palaikomos ir valdomos, kaip stebimi spektakliai ir pan.
Duomenų bazės aplinkos ir programų integracija bei API tipai, dabar teikiamos prieigos rūšys tampa vis sudėtingesnės ir sudėtingesnės. Kasdienis administravimas, palaikymas ir atsarginės kopijos vėlgi buvo tai, kas, mūsų manymu, buvo išspręsta, bet tada staiga mastelis tapo daug didesnis, ir viskas judėjo greičiau, o apimtis - daug didesnė; Aplinkos dydis, duomenų bazių sistemos turėjo palaikyti operacijų judėjimo greitį.
Pagalvokite apie duomenų bazę labai, labai dažnoje prekybos aplinkoje, tiesiog nėra taip, kad žmonės galėtų to sekti, tai tik mašinų spiečius, kovojantis su kita mašinų grupe, norint atlikti aukšto dažnio prekybą, pirkimą ir pardavimą, o apimtis - kurie tie sandoriai įvyksta. Pagalvokite apie šiuolaikinį scenarijų, pavyzdžiui, apie ankstyvą „Netflix“ filmo išleidimą, kai jūs nekalbate tik apie šimtus ar tūkstančius ar net šimtus tūkstančių, potencialiai milijonams žmonių, norinčių pamatyti tą filmą nuo pat jo išleidimo. Visa ta informacija yra užfiksuota, stebima ir registruojama bei analizuojama duomenų bazės platformoje.
Ir tada visada yra pasaulis, kuriame mes gyvename dabar, 24 valandas per parą, ne tik sekdami saule, bet ir kas nors vidurnaktį norėdamas ką nors padaryti, o darbo valandos seka saulę visame pasaulyje. Taigi veiksnumas ir prieinamumas pagal numatytuosius nustatymus yra klimatas dabar, jei prastova tikrai nėra priimtinas dalykas. Ir atleidimas iš darbo, jei kyla našumo problemų arba mums reikia priežiūros lango, kad galėtume atlikti atnaujinimą ar pataisą, arba apsaugą, tikrai turime sugebėti pereiti iš vienos duomenų bazės aplinkos į kitą ir tai padaryti sklandžiai ir automatiškai.
Saugumas ir standartai bei atitiktis, vėlyvajame pasaulyje, ypač GFC, nutiko keletas gana didelių dalykų, todėl turime daugybę naujų iššūkių, su kuriais susiduriame laikydamiesi saugos, saugumo ir atitikimo standartų, ir mums reikia mokėti pranešti apie juos realiu laiku, o geriausia - prietaisų skydelio forma. Mes nenorime siųsti beždžionių komandos į duomenų centrą, bandydami surasti daiktus, mums reikia sistemos, kad ji mums tai praneštų realiu laiku.
Ir du didelius linksmus dalykus, apie kuriuos beveik niekas niekada nekalba, paprastai mes juos stumiame po kilimėliu ir tikimės, kad jie niekada nekels sau bjaurios galvos, o atkūrus nelaimes ir tęsiant verslą - štai ir dalykai, kurie turėtų dažniausiai tai įvyksta automatiškai, jei iškiltų poreikis.
Galėjome praleisti dienas kalbėdami apie dalykus, kurie duomenų bazių aplinkoje gali suklysti ir apie kuriuos žmonės paprastai reagavo, tačiau dabar mums reikia sistemų ir priemonių, kad tai padarytume už mus. Vienas iš pavyzdžių yra duomenų pažeidimas, taigi, kai galvojame apie duomenų bazes, aš gana atvirai užduodu šį klausimą įvairiomis formomis: kas nutinka su duomenų bazėmis, kai mes užmerkiame akis, o kažkas kritinio nutinka? Ypač jei nėra sistemos, stebinčios našumą ir saugumą bei kitus pagrindinius duomenų bazių veikimo aspektus.
Na, kas gali atsitikti, tai yra kai kurių paskutinių pažeidimų per pastaruosius dvejus trejus metus ekrano kopija. Visada visa tai kilo iš duomenų bazės sistemos ir visada iškilo tam tikra saugumo ar valdymo ar prieigos problema, o viršutiniame kairiajame kampe mes žiūrime į 152 milijonus „Adobe“ paskyrų, kuriose yra kiekviena detalė. iš tų klientų buvo pažeisti. Jei būtų buvę tinkamų priemonių, skirtų įvykiui sekti ir užfiksuoti, ir saugumui kontroliuoti, galbūt kai kurių iš jų išvengėme, galbūt pavogę pirmieji keli šimtai įrašų mus įspėjo, ir mes turėtume sustabdė kitus šimtus penkiasdešimt milijonų.
Tada mes pasiekiame pagrindinį visos šios kelionės tašką, kurį nuvedėme, tai yra: kodėl mums reikia geresnių sistemų? Kodėl mes negalime tiesiog mesti daugiau kūnų į šį reikalą, kad, mano manymu, gerai ir tikrai peržengėme tašką, ir tikrai tikiu, kad yra atvejis, kuris buvo pavėluotas, kad mesti daugiau DBA, administratorių ir daugiau žmonių šis dalykas neišsprendžia problemos. Mums reikia geresnio priemonių rinkinio ir geresnio sistemų rinkinio.
Čia pateikiamos penkios pagrindinės priežastys, kurios, manau, palaiko tai, ir jos yra surūšiuotos pagal svarbą, atsižvelgiant į tai, ką matau šiose privačiose įmonėse ir valstijose, kurios yra valdomos aplinkos, iššūkius, su kuriais susiduria duomenų bazių aplinka, ir juos valdyti.
Saugumas ir atitiktis. Jūs žinote, kontroliuodami, kas turi prieigą, iš kur jie turi prieigą, kada turi prieigą, kaip dažnai turi prieigą, iš kur jie ją pasiekia. Potencialiai prietaisai, kuriuos jie iš tikrųjų palietė, ir dalykai, kuriuos jie apžiūrėjo, ir atitiktis, kuri yra šalia to. Jei žmonės po 30 dienų rengia ataskaitas, kad mums praneštų, ar viskas gerai, tai jau netinka, tai turi įvykti realiuoju laiku.
Našumas ir stebėjimas - atrodo, kad nėra jokių protų, bet visada tai nėra. Nesvarbu, ar mes naudojame atvirojo kodo įrankius, ar kai kuriuos trečiųjų šalių komercinius įrankius, visada įvairiais būdais nepraleidome laivo, turėdami reikalingų našumo stebėjimo tipų ir reikalaujamų detalių bei galimybę laiku reaguoti. .
Incidento aptikimas ir reagavimas - tai turi būti momentinis realaus laiko dalykas, ir visada mums reikia sistemos, kuri tai padarytų už mus arba bent jau perspėtų mus greitai, kad galėtume su tuo susitvarkyti, kad būtų išspręstos kelios iškilusios problemos. greitai ir nekontroliuodami kaskados.
Valdymas ir administravimas - vėlgi, mes manome, kad šios problemos yra išspręstos, jų nėra. Tikslas, su kuriuo susiduria duomenų bazių komandos, ypač DBA, kai sistema turėtų rūpintis mumis, mes dar neišsprendėme šios problemos, ji vis dar yra tikras dalykas.
Ir jau nuo pat projekto kūrimo ir tobulinimo pradžios, kai pradedame kurti šias priemones, mes sukuriame duomenų bazių aplinką, gebame naudoti tinkamus įrankius kūrimo ir testavimo bei integravimo platformose. Tai vis dar nėra lengvas dalykas, ir visa ši kelionė mus tarsi varo į tą pačią žinią, kad, mano manymu, mums reikia geresnių sistemų ir geresnių įrankių, kurie padėtų mums pasiekti rezultatus, kurių mums reikia iš mūsų duomenų bazės aplinka, taigi verslai, didinantys vertę iš mūsų klientų. Negalime tiesiog mesti daugiau kūnų ir daugiau DBA, mastelis yra per didelis, greitis yra per didelis ir apimtis yra per didelė. Turėdamas tai Ericas, galėčiau tau grąžinti.
Erikas Kavanaghas: Man tai patinka, mes turime daug žemės, padengtą ten esančiais žmonėmis, daug numatomų laidų, ir mes einame į priekį ir perduodame jiems raktus „Bullett“ vos per vieną sekundę.
Bullett Manale: Gerai.
Erikas Kavanaghas: O, atimkime jį ir „Bullett“, dabar aš jums tai perduodu, o jūsų grindys yra jūsų.
Bullett Manale: Gerai, ačiū. Manau, kad buvo pareikšta labai daug gerų dalykų. Norėjau tik akimirką greitai pakalbėti apie „Idera“, kas mes esame, tada mes įsijungsime. Aš kalbėsiu apie įrankį, kuris, manau, yra daug tų dalykų, apie kuriuos mes kalbame, savotiškas rinkinys ir būdas aptarti kai kurias sritis, kuriose jos suderinamos, naudojant šį įrankį, „Diagnostic Manager“ produktą.
Tai, ką pirmiausia noriu padaryti, yra tik tam, kad suteiktų jums šiek tiek informacijos apie tai, kas yra „Idera“; mes buvome maždaug nuo 2003 m., taigi mes pradėjome nuo vien tik „SQL Server“ įrankių, ir štai ką šiandien daugiausia dėmesio skirsime, bus „Diagnostic Manager“ produktas. Bet jūs galite pamatyti visus daiktus, kuriuos turime čia, ir neseniai, kaip jau buvo minėta anksčiau, įsigijome tikslių prekių. Įsigiję taip pat turime „Embarcadero“, taigi turime gana gerą produktų portfelį.
Kalbant apie našumo stebėjimą, kalbant apie „SQL Server“, produktas, apie kurį noriu kalbėti, kuris suderina šias mūsų aptariamas temas, yra „Diagnostic Manager“. Dabar tai yra produktas, kuris gyvuoja jau beveik nuo „Idera“ dienų pradžios, ir man pasisekė, kad esu to dalis, maždaug nuo 2005 m. Ir mačiau daug pokyčių kalbant apie „Idera“. „SQL Server“, perėjimas nuo fizinio prie virtualiojo, visa tai, kas nutiko, taip pat DBA poreikiai, augant aplinkai, ir tų rūšių dalykai.
Aš pradėjau nuo to, kad tipiškas mūsų produkto vartotojas yra DBA, taigi, kai pirmą kartą kalbame su žmonėmis, potencialiais klientais, dažniausiai tai yra DBA, su kuriais mes kalbamės. Mes nekalbame su IT valdytojais ar direktoriais, tam tikru momentu jis gali patekti į tą lygį, bet pradžia yra ta, kad DBA turi problemą, DBA bando išspręsti problemą, ir daugybę kartų mes Aš eisiu ir atsisiųsiu bei išbandysiu produktą kaip dalį to. Tai galite padaryti duomenų tvarkytuve arba DBA, arba veikiančiu DBA - vaikinu, kuriam pasisekė, kad tam tikrais atvejais kambaryje yra techniškiausia. Dabar, žinoma, kai pateksite į didesnių įmonių aplinką, gausite pilnavertes DBA, kurios dažniausiai bus tos, kurios naudoja šį įrankį. Aš nuėjau į priekį ir čia tik pridėjau nedidelį įrašą iš Vikipedijos. Tai, kaip sakoma Vikipedijoje, peržengia DBA atsakomybę, tai jie ir daro.
Jei jūs einate per sąrašą čia, daug šių dalykų, aš nesiruošiu jo skaityti, bet jūs gaunate daug tipiškų dalykų, apie kuriuos galėtumėte pagalvoti, o tada vieną iš jų turite stebėti duomenų bazės našumo optimizavimas, ir tai yra gana didelė. Įdomu tai, kad kalbėdamiesi su DBA, jie visada kaltinami pirmiausia, kai kyla problemų, ir tai gali būti ne tikrai jų kaltė, bet kai kyla našumo problema, paprastai su programa, yra susietas su DBA duomenų baze, jie kalti, todėl jie visada ieško priežasčių, kodėl tai nėra jų kaltė. Daugeliu atvejų jie gali naudoti šį įrankį „Diagnostic Manager“, kad padėtų.
Bet dienos pabaigoje, taip pat, jei duomenų bazė neveikia, daugumai kitų dalykų nėra labai svarbu, jūsų programos neveikia, tada daugeliui iš tikrųjų tai nėra svarbu daiktai. Visų pirma, mes norime sugebėti įsitikinti, kad nesumažėja vartotojo patirtis, kaip mes jį žinome, tai yra kažkas, ko DBA siekia. Ir aš manau, kad jei jūs pažvelgtumėte į priežastis, kodėl žmonės paprastai perka ir naudojasi „SQL Diagnostic Manager“ produktu, tai viena iš pirmųjų priežasčių, tikriausiai ne pati svarbiausia, ne paskutinė ar mažiausia, tačiau ji yra tokia pati lygi visur, ir atsižvelgiant į tai, su kuo tu kalbi, šios priežastys yra beveik visada viena ar dvi, aplinkybės yra tam tikros.
Tačiau pirmasis yra tiesiog galimybė turėti centralizuotą egzempliorių vaizdą kaip jų valdomą SQL. Ir juokinga tai, kad daugeliu atvejų, jei paklaustumėte DBA „Kiek pavyzdžių jūs tvarkote?“, Skaičius keičiasi taip dažnai, kad kai kuriais atvejais jie nėra tikri. Taigi jums reikia kažko daugiau, nei tik sugebėjimo viską mesti į ekraną. Norite sugriebti tą informaciją, norite ją įsisąmoninti, ir tai yra vienas iš dalykų, kuriam „Diagnostic Manager“ tikrai gali padėti, - sugebėti pateikti jums tokį vaizdą į aplinką.
Tai nėra tik vaizdas į aplinką, bet ir tai, kad DBA, duomenų bazės administratoriui, yra patogu ir tai yra konsolė, kuri, jei norite, orientuota į DBA. Jis skirtas duomenų bazės administratoriui. Stebėjimo įrankių yra daugybė, o spektaklio priemonių - gausu, bet, kaip sakiau, dienos pabaigoje DBA nori įrankio, kuris būtų sukurtas DBA, nes ten yra daugybė dalykų, būdingų tam, ką jie daro jų kasdien.
Tai pasakius, jūs turite SCOM, turite HPF, turite visas šias kitas technologijas, tačiau jie nori kažko, kas būdinga tam, ką jie daro. Manau, kad galime padėti šioje srityje naudodami šį produktą, pamatysite, kai pateksime į jį per sekundę. Kitas dalykas, kurį mes matome su DBA, kuris neabejotinai yra vienas iš dalykų, į kurį mes taip pat kalbėjome anksčiau, yra tas, kad jie, aišku, turi mokėti matyti, kas vyksta, ir turėti galimybę apžvelgti visą įmonę ir ramiai žinokite, kas vyksta. Bet tuo pačiu metu jie nesėdi stebėdami pultus.
Prisimeni visus tuos taškus, kuriuos matai tame sąraše, kuriuos ką tik išsitraukiau? Jie turi atlikti ir tuos kitus dalykus, todėl ne tik reikia laukti gaisrų. Daugeliu atvejų įvyks susitikimai arba daugybė priežiūros duomenų langų, susijusių su duomenų bazės administratoriumi, veikia viduryje nakties, kai jie miega, todėl jie turi turėti galimybę grįžti atgal ir pamatyti, kas nutiko. . Daugeliu atvejų, jei kažko nesugaunate, kai tai įvyksta, kai problema išnyksta ar bent jau naudojant SQL Server, tai tampa savotiška problema, kai susiduriate su situacija, kai ne nebeturite tos problemos likučių. Tos problemos praeina, kaip ir liekanos, o tai reiškia, kad turite mažiau šalinti trikčių, turite mažiau informacijos, su kuria turite dirbti.
Tai pasakius, tai tikrai yra vienas iš dalykų, kuriam gali padėti „Diagnostic Manager“, - suteikti jums tą žvilgsnį į praeitį pasiteirauti iš praeities gautos informacijos: „Ar aš turėjau įspėjimą dėl blokavimo, ar turėjau problemų dėl blokavimo, ar turėjome dalykų, kurie vyko atsižvelgiant į mūsų išteklius? “Aš galiu grįžti ir paklausti tos informacijos. Galiu įsigilinti į konkrečius laiko momentus. Aš galėčiau daryti visus tuos dalykus tiesiogiai iš įrankio.
Visus šiuos dalykus, nepaisant to, ar tai vidinė, ar išorinė programa, DBA nori žinoti, nes nori pamatyti, kas sukelia problemą. Visiškai nesvarbu, ar kodą parašė kažkas organizacijos viduje, ar kažkas už organizacijos ribų; jie vis tiek nori sugebėti ją atskirti, kad jie žinotų, kad problema kyla, ir žino, iš kur ji kyla.
Taigi našumas ir atskaitomybė yra pagrindinė mūsų gaminio dalis. Mes galime pateikti visas šias detales, ir kas yra puiku, ar jūs turite galimybę įsigilinti. Jei yra trūkumų, galite tai susieti su programa, vartotoju, duomenų baze ir užklausa. Ir vėl tai yra rūkymo pistoletas. Jūs gaunate tiesioginę koreliaciją tarp to, kada ši užklausa vykdoma, ką ji daro? Ir tai ne tik apie pačią užklausą, atsižvelgiant į jos vykdymą savaime, bet ir ar laikui bėgant užklausa blogėja? Į tuos dalykus taip pat galima atsakyti ir su produktu, kuris tikrai yra kažkas tokio, kad jei bandai būti iniciatyvus, malonu, kai gali pasakyti: „Ei, štai, užklausa pasirodė bloga, bet berniukas pažvelk į tai važiuodamas toliau, matome, kad jis bėga dar blogiau ir blogiau, aš galiu ką nors padaryti “.
Jei mes eisime į kitą sritį čia; ir taip yra tikriausiai - sakyčiau, kad tai vienas didžiausių. Vienas iš mano užduodamų klausimų, kai rodysiu mūsų produktą, aš visada paklausiu duomenų bazės administratoriaus: „Kaip jūs girdite apie problemą, susijusią su jūsų SQL Server duomenų bazėmis?“ Ir tai labai juokinga, nes dažniausiai jie yra suteikiami ir dažniausiai žiūri į mūsų produktą, nes daugeliu atvejų jie bando išspręsti tam tikrą poreikį. Bet įdomu išgirsti pradinį dalyką - bent jau su SQL Server, kad tai buvo tokio tipo - žinote, pirmosiomis „SQL Server“ dienomis jūs turėjote SQL serverį, o vėliau - „Oracle“. Visi turėjo „Oracle“, o „SQL Server“ buvo panašūs į tai, kad, pradėjus pirmą kartą, trūko geresnės išraiškos duomenų bazių raudonplaukio patėvio.
Ir tada, kai „Microsoft“ pridėjo prie jo daugiau funkcijų, ji tapo šiek tiek įmonės įrankiu. Ir akivaizdu, kad nuo to laiko nuėjo ilgą kelią. Bet esmė ta, kad vieną kartą jūs galite teigti, kad duomenų bazės dieną nebuvo laikomos kritinėmis. Ir tai laikui bėgant pasikeitė. Dėl šios priežasties daugeliu atvejų žmonės bando sugriebti rankas ir sako: „Žinai ką? Turiu visas šias „SQL Server“ duomenų bazes, bandau su tuo susitvarkyti. “Ir užuot girdėjęs apie problemas iš pagalbos tarnybos ar konkrečių žmonių problemas, kurios, kaip ir patys vartotojai, jie ieško būdų, kaip būtų galima supažindinti su tokiomis situacijomis, kol jos kada nors neįvyks.
Taigi, su Diagnostikos vadovu, tai yra vienas iš dalykų, kuriuos mes taip pat bandome padaryti, kad bent jau sugebėtume įsitikinti, jog DBA yra pirmasis, kuris sužino apie tas situacijas ar tas problemas, kad galėtų ką nors apie tai, iškart, kai jie įvyksta, arba žengti dar daugiau, išanalizuoti šias sistemas, kurias jis stebi. O sugebėti jums duoti iniciatyvius patarimus, kurie pagerins tos instancijos darbą, ir sugebėti tai daryti reguliariai. Pavyzdžiui, turime pridėti rodyklę, pagrįstą darbo krūviu; tų rūšių daiktai, įrankiai, kuriuos taip pat galima atlikti. Taigi įrankyje pamatysime daug to.
Kitas ir paskutinis dalykas, esantis šiame sąraše, kuris yra labiau bendras apibūdinimas, tačiau tai tikrai kažkas, ką verta paminėti. Ir ypač kai jūs patenkate į didesnių tipų įmones, kuriose yra daugybė egzempliorių, visada bus neaiškių dalykų, kuriuos norėsiu stebėti, jei esu duomenų bazės administratorius. pavyzdys. Taigi tai, ką mes stengiamės padaryti, yra numatyti tai, ką norės stebėti tipinis DBA.
Tai pasakius, jūs taip pat sugebėsite: visada bus kažkas naujo. Taigi mes pateikėme būdą, kuriuo galite pridėti bet kokią metriką, kurią jums reikia stebėti ir valdyti, kai bus pridėtas diegimo taškas. Taigi bet kokie „PerfMon“ skaitikliai, WMI skaitikliai, „SQL Server“ skaitiklių objektai; visas šias priemones galima įtraukti į įrankį. Jūs galite pridėti papildomų užklausų, kurias galite įtraukti į jūsų apklausų intervalus.
Ir paskutinis dalykas, kurį taip pat verta paminėti, yra tai, kad galime pridėti ir realiai bendrauti tiek su „vCenter“, tiek su „Hyper-V“, kad galėtume ištraukti metriką iš tų aplinkų. Vienas iš dalykų, kuriuos mes tapatinome su DBA, yra tai, kad jie paprastai nėra konkrečiai vykdomų operacijų dalis. Ir jie, nebūtinai, paprastai turi „vCenter“ aplinką, kuri jiems yra prieinama, arba tokius dalykus, kurie jiems yra prieinami.
Taigi problema yra ta, kad jei jie susiduria su SQL serverio egzemplioriumi ir jiems buvo paskirta išteklių, tačiau tas egzempliorius yra virtualizuotas, gali atrodyti, kad jie turi visus pasaulio išteklius, kai tik stebi, kas yra svečio operacinėje sistemoje. Realybė yra tokia, kad pagrindiniame kompiuteryje gali būti 30, 40, arba 50 ar 100 kitų VM, kuriuos jie bando pasiekti, ir turi tuos pačius išteklius. Ir vienintelis būdas tai pamatyti yra komunikacija su kitomis aplinkomis ir sąsajomis, šiuo atveju, ką mes darome.
Jūs turite galimybę pridėti tų kitų tipų skaitiklius į įrankį. Dabar svarbu ne tik tai, kad galėtumėte stebėti tuos skaitiklius, bet ir tai, kad galėtumėte padaryti tuos naujus skaitiklius, kad jūs supažindintumėte su produktu, kad jie taptų įrankio dalimi, tarsi jie būtų „už langelio“ metrika. . Neįprastas dalykas, kurį norėtumėte stebėti; taigi tai reiškia, kad galėsite juos įtraukti į savo prietaisų skydelius. Tai reiškia, kad galėsite įtraukti juos į savo pasirinktines ataskaitas, sugebėti akivaizdžiai nustatyti slenksčius ir įspėti apie juos, bet kartu ir nubrėžti juos bei sugebėti su tam tikromis žiniomis nustatyti slenksčius, kur juos nustatyti atsižvelgiant į tokius dalykus kaip jūsų bazinės linijos ir kas normalu. Taigi, jūs turite daug tokių dalykų, kurie taip pat yra gaminyje.
Tai, ką aš jums suteikiau, yra tai, ką aš vadinu „pagrindiniais diagnostikos vadybininko produktais“, ir aš galiu žengti į priekį ir tiesiog suteikti jums šiek tiek skonio tai įsigijęs į produktą. Ką aš padarysiu, tai pasidalykite mano ekranu, gerai, ir tiesiog ketinu tai pervilkti. Taigi, ką jūs pamatysite, tai yra „Diagnostic Manager“ pultas. Ir kaip jau minėjau anksčiau, eikite į tą pirmąjį pagrindinį failą, galėsite pažvelgti į dalykų iš įmonės lygmens požiūrio. Įrankyje yra daugybė skirtingų pavyzdžių. Turime savotišką miniatiūrų vaizdą; daugiau turime į tinklelį panašų vaizdą. Taip pat, kalbant apie lankstumą, turime taip pat turite internetinę konsolę. Internetinėje konsolėje yra ir kitų turimų rodinių, tokių kaip pagrindiniai žemėlapiai ir panašūs dalykai. Bet esmė ta, kad jūs turite tokią galimybę apžiūrėti ir pamatyti dalykus. bet iškilus problemoms, jūs šiek tiek įsigilinsite į įrankį ir pamatysite konkrečią problemą Lems, ir turi tam tikrą būdą suprasti ir žinoti, kas vyksta. Ir akivaizdu, kad tai labai svarbu.
Kalbant apie galimybę iš tikrųjų pamatyti tai, kas nutiko praeityje; Jei aš žvelgiu į problemą, kuri įvyko vakar ar prieš savaitę, tada, tokioje situacijoje, jūs žinote, turėsite turėti galimybę kreiptis į tam tikrą SQL egzempliorių. Geros žinios yra tai, kad jei žinote, kokiu metu ta problema kilo gaminyje, galite kreiptis tiesiai į istorijos naršyklę. Aš galiu nurodyti konkretų dienos laiką; tai gali būti nuo poros savaičių, tai gali būti nuo vakar. Bet kokią dieną pasirinksiu kalendoriuje, tada man bus pateikiami skirtingi rinkimų intervalai. Šiuo atveju aš iš tikrųjų matau tai, ką būčiau matęs, jei būčiau žiūrėjęs konsolę balandžio 20 d., 13:37.
Taigi aš galiu grįžti į laiką ir tada, kai tai padarysiu, visi skirtingi čia matomi skirtukai atspindės tą konkretų laiko momentą, įskaitant užklausas, kurios galėjo būti vykdomos prastai, įskaitant galbūt, jei Turėjau sesijas su blokavimu. Įrankyje bus rodomi visi tokie dalykai, ir tai leis man akivaizdžiai panaudoti tą istorinę informaciją, kad galėčiau, žinote, išspręsti problemą. Šiuo klausimu, kai mes kalbame apie istoriją, verta atkreipti dėmesį į tai, kad ne tik naudoti istoriją problemoms spręsti. Akivaizdu, kad istorija yra labai vertinga dėl kitų priežasčių. Ir vienas iš didžiausių yra sugebėjimas efektyviai priimti sprendimus ir greitai priimti sprendimus, turint reikiamą informaciją. Taigi visą tą istoriją, visą informaciją, kurią renkame, galime pranešti prieš.
Jei kas nors prieis prie manęs ir pasakys: "Aš gavau šią tikrai puikią programą. Tai pakeis pasaulį, nes mes jį žinome. O, beje, tam reikės duomenų bazės, o, beje, tai tikrai reikės susieti. I / O kompiuteryje, kuriame yra ta duomenų bazė. “ Jei žinau, kad gilinuosi į ją, tada galiu panaudoti šią informaciją, kad galėčiau pateikti visų mano gamybos serverių reitingą, remiantis galbūt per pastarąsias septynias kolekcijos dienas. Ir aš labai greitai galėčiau padaryti išvadą, kurioms instancijoms yra prasmingiausia naudoti tą duomenų bazę. Taigi akivaizdu, kad labai vertinga yra tokia istorinės informacijos rūšis.
Kalbant apie pačius klausimus; kalbant apie užklausas, įrankyje mes turime daug įvairių būdų, kaip tai padaryti. Man patinka žiūrėti „Query Waits“ vaizdą, nes „Query Waits View“ yra labai naudingas vertinant. Jei turiu kliūčių, kurios kyla, sugebėti iš esmės identifikuoti visas skirtingas sritis, turinčias įtakos tam tikrai, konkrečiai užklausai; ne tik pačią užklausą ir jos įtaką, bet taip pat žinote, iš kurios programos ji atsirado, iš kurios sesijos ji atėjo, kuris vartotojas ją pavadino ir visa tai, aš galiu peržiūrėti tą informaciją realiu laiku, bet aš taip pat gebu pažvelgti į tuos duomenis iš praeities. Taigi tai yra vienas iš dalykų ir aš paleido scenarijų, bet turiu laukti, kol jis pasirodys.
Kol to laukiame, noriu - ir žinau, kad mums trūksta laiko, todėl norėjau šiek tiek pasikalbėti ir apie tai, kad perspėjimo pranešimas yra aktyvus. Ir kai jūs kalbate apie tokius dalykus, kaip sakiau, būdamas iniciatyvia dalimi, yra daugybė įspėjamųjų priemonių. Sunkiausia yra ne siųsti el. Laišką. Sunkioji dalis nerašoma į įvykių žurnalą ar SNMP gaudyklė. Sunku žinoti, kada reikia nusiųsti tą įspėjimą tinkamu laiku. Taigi kartu su tuo reikia nemažai skaičiuoti, suprasti: „Kas tai yra apie tą egzempliorių ir kas yra normalu, kai jis susijęs su ta instancija?“
Taigi, naudodamiesi visomis metrikomis, su kuriomis tai daryti yra prasminga, mes parengiame pradinę metriką. Mes iš tikrųjų parodome jums pradinę padėtį, parodysime jums ribą, kurią ji šiuo metu nustato. Ir tada dar vienas gražus dalykas yra tai, kad tarkime, kad šiuo pavyzdžiu aš nustatiau savo slenksčius šešioms ir dešimtims. Po šešių savaičių, jei grįšiu prie šios bylos, ši pradinė padėtis gali visiškai pasikeisti, nes vienas iš dalykų, kuriuos mes darome apskaičiuodami bazinę situaciją, pagal nutylėjimą yra einamasis septynių dienų skaičiavimas. Taigi visada pateikiu naujausią pradinio varianto variantą. O kas atsitiks, jei tas atskaitos taškas pakils iki mano slenksčių? Šiuo atveju galiu pamatyti ir perspėti rekomendacijas, kuriose iš esmės sakoma: „Ei, jūs turite slenkstį, kuris tikriausiai neteisingai nustatytas, konkretus ten, kur mes matome slenkstį, ir, aišku, kur yra atskaitos taškas, tikriausiai jūs eisite gauti įspėjimą apie tai, kas yra normalu “.
Taigi aš, užuot gydęs kažkokį normalų simptomą, galiu nustatyti tokio tipo situaciją, kai tikroji riba yra nustatyta neteisingai. Ir tai, kas man akivaizdžiai leidžia tai padaryti, yra ribų nustatymas atsižvelgiant į tai, kur aš gausiu perspėjimą. Aš žinau, kad tai labiau raginimas veikti, palyginti su tyrimu, norint išsiaiškinti, ar tai tikrai yra problema. Ir aš manau, kad tam tikra priemonės dalis yra labai naudinga, kalbant apie patį pradinį scenarijų ir galimybę apskaičiuoti.
Dabar su šiuo produktu jūs turite galimybę iš tikrųjų turėti kelias bazines linijas; galite juos nustatyti skirtingiems laikotarpiams ir galite dinamiškai pakoreguoti slenksčius, remdamiesi bazinėmis linijomis, o tai taip pat yra labai svarbi prisitaikymo prie pokyčių, kurie kiekvieną dieną vyksta jūsų SQL serverio egzemplioriuose, dalis. . Dabar, šiuo atveju, mes padengiame daugybę slenksčių nustatymų ir parodome jums bazines linijas. Kalbant apie tikruosius įspėjimus, patys pranešimai, o tai yra puikus dalykas apie „Diagnostic Manager“, yra tai, kad jie suteikia jums kelis įspėjimo profilius. Taigi, jei turite, pavyzdžiui, budėjimo profilį, kuris yra nuo 2:00 iki 5:00 ryto, tada aš galiu turėti profilį, būdingą būtent tam laiko diapazonui, ir čia galiu nustatyti visas sąlygas ir atitinkamus parametrus. už mano atsakymą.
Dabar atsakymas yra tas, kad kai kuriais atvejais taip, aš galiu išsiųsti el. Laišką arba nusifilmuoti ir sugeneruoti SNMP spąstus, arba parašyti įvykių žurnale. Yra daugybė kitų dalykų, kuriuos galime nuveikti, tačiau, kai aš kalbu su DBA, kas jiems iš tikrųjų patinka, yra tai, kad daugeliu atvejų didelė dalis atliktų darbų yra pasikartojantys dalykai. Tai dalykas, kurį jie tiksliai žino, kada kyla problema, ką daryti, norint ją išspręsti. Jie tiesiog turi eiti ir įsikišti. Augant savo aplinkai, turint daugiau pavyzdžių, tai padaryti tampa daug sunkiau. Taigi, vienas iš dalykų, kuriuos, jūsų manymu, verta atkreipti į įrankį, yra tai, ar jūs turite galimybę nustatyti sąlygą, tačiau remdamiesi ta sąlyga galėtumėte nustatyti atsakymą scenarijui paleisti, paleisti darbas, paleisti vykdomąjį. Esmė ta, kad jei nuspręsite paleisti scenarijų, aš galiu naudoti parametrus to scenarijaus viduje, kuris bus vykdomas, pateikiant faktinę informaciją.
Taigi, jei kyla problemų dėl konkrečios duomenų bazės, scenarijus bus sukurtas paleisti tik prieš duomenų bazę, kurioje yra problema. Taigi, jūs galite dinamiškai spręsti problemas automatizuotu būdu, tada aš vis tiek galiu gauti el. Laišką, kad grįžtumėte ir pasakytumėte man: „Ei, buvo problema, bet, beje, ji buvo ištaisyta“. Scenarijus buvo paleistas, ir jūs, kaip DBA, žinote apie jį, bet jums iš tikrųjų nereikėjo įsitraukti ir įsikišti. Dabar, kalbant apie tą pačią pastabą apie iniciatyvumą, akivaizdu, kad čia turime ir kitą funkciją, kuri yra „Analizuoti“. O ką tai padarys, tai reguliariai tikrins, ar nėra SQL pavyzdžių. Ir tam tikrais atvejais tai leis giliau pasinerti į tai, ko ieško. Bus atlikta hipotetinė indekso analizė. Ar galiu pridėti rodyklę? Ar galiu pašalinti rodyklę? Akivaizdu, kad visi tie dalykai padės mano pasirodymui, bet vėlgi viskas bus iniciatyvi. Tai susiję su galimybe priimti sprendimus prieš pertrauką ir priversti ją veikti geriau. Ir todėl daugeliu atvejų iš tikrųjų mes čia bandome tai padaryti.
Grįžtant prie „Query Waits“, apie kuriuos kalbėjome anksčiau; kaip matai, čia didelis smaigas. Anksčiau vykdžiau scenarijų, kuris tiesiog sukėlė tam tikrą laukimo veiklą, ir, kaip jau minėjau anksčiau, turime tikrai unikalų būdą, kuriuo galite išsiaiškinti šią informaciją. Jei noriu pamatyti, kokia tai buvo programa; Matau, kad jis atsirado iš „NoSQL“ programos. Mes galėtume pamatyti duomenų bazę, į kurią ji buvo susieta, sesiją, vartotoją, o tada, jei noriu, galėčiau tai suskirstyti pagal savo laukimus. Taigi, galiu pasakyti, kad visų tų laikų langų laukimų, kurie vyko dažniausiai? Ir jei aš matau, kad kai tai nutiko daugiausiai, tikrai gražus dalykas yra tai, kad galiu įsigilinti į tą laukimo tipą ir galiu pamatyti visas komandas. Jei pažiūrėtumėte čia, jie privertė laukti. Taip pat pirmiausia galiu pamatyti, kokia programa tai buvo, dėl ko buvo laukiama.
Taigi jis atrodo kaip skaudus nykštys. Aš iš karto galiu nueiti ir pasakyti: „Tai yra programa, dėl kurios kilo mano kliūtis. Dabar kokia užklausa buvo vykdoma? Kuris vartotojas ją paleido? Kuriai duomenų bazei ji veikė?“ Ir pan. Taigi, tikiuosi, kad ji turi prasmę, ir tai taip pat padeda įsitikinti, kad jūsų aplinkoje nėra latentiškumo, nes tai susiję su jūsų duomenų bazėmis. Tikiuosi, kad tai bus naudinga. Šiuo metu eisiu į priekį ir perduosiu atgal, ir spėju galime tęsti iš ten.
Ericas Kavanaghas: tikras dalykas. Taigi, manau, tiesiog įmesiu į mūsų dienos ekspertus. Pažymėk, gal pirmiausia nori pakomentuoti ir užduoti porą klausimų. Tuomet Dez, tu gali paskambinti.
Markas Madsenas: Taip, ačiū, man labai patiko kai ką tai žiūrėti. Tai daug intelektualesnis stebėjimas, nei aš įpratęs matyti. Man įdomu tvarkyti duomenis; tvarkyti metriką, kurią galite sekti, ir, žinote, ieškokite tokių dalykų, kaip, visų pirma, pamatinių linijų perkėlimas, tai yra vienas iš mano augintinių skausmo taškų, naudojant prietaisų skydelius. Kaip jūs elgiatės su tais duomenimis, o antroji jų dalis, kaip jūs žinote, yra su pradine metrika, pavyzdžiui, su tam tikru pamainu - ar jūs taip pat turite galimybę automatiškai perkelti slenksčius, kad man nereikėtų grįžti atgal ir rankiniu būdu iš naujo nustatyti slenksčius, kai keičiasi bazinė padėtis?
Bullett Manale: Jūs darote, ir todėl, kad malonu, jog jūs galite nuspręsti. Galite padaryti bet kurį iš jų. Aš galiu nustatyti slenkstį ir padaryti jį statiniu nustatymu arba galiu pažymėti langelį, sakydamas: „Padarykite tai dinaminiu slenksčiu, kuris pasikeis keičiantis mano bazinėms linijoms“. Turiu galimybę ir įrankį nustatyti numatytąjį langą. laiko, bet, jei man reikės, aš galiu turėti atskirą pradinio lygio langą, pavyzdžiui, nuo techninės priežiūros lango nuo 2:00 ryto, sakykime iki 5:00 ryto, nes aš apmokestinu savo Centrinis procesorius, mano diskai ir visa kita, nes būtent tada ir atliekame visą priežiūrą. Tada automatiškai, jei būčiau pasirinkęs tai daryti, jis automatiškai pakoreguotų mano slenksčius taip, kad būtų už jos ribų, kad ir kas būtų normalu tiems metrikoms, kurie yra normalūs. Aš pasirenku tai padaryti. Tai leistų man tai padaryti. Iš esmės įrankyje jūs turite galimybę nustatyti laiko langus, kurie yra jūsų pradiniai langai, ir kiekvienas langas gali būti traktuojamas kaip atskiras subjektas, kalbant apie dinamišką bazinių linijų koregavimą, kurį galima atlikti, ir jūs galite pridėti tiek pradinio lygio langų, kiek norite jums reikia, jei tai prasminga. Jūs galite turėti savaitgalio langą, savaitės dieną darbo valandomis, priežiūros langą, kuris vyksta nakties viduryje ir pan. Ir pan.
Markas Madsenas: Ačiū.
Bullett Manale: Manau, grįžkime prie pirmosios klausimo dalies, kurią mes turime, ir renkame visą šią informaciją. Aš tikrai nekalbėjau apie architektūrą, bet mes turime atsarginę saugyklą, kurią jūs visiškai kontroliuojate, kaip saugoti tuos duomenis, tačiau mes taip pat turime paslaugą, kuri veikia viduryje nakties, kuri eina ir veikia visus mūsų pradinius skaičiavimus ir tuos duomenis renka, renka ir įprasmina. Be abejo, be to, jūs taip pat turite daugybę ataskaitų, kurias galime naudoti teikdami ataskaitas pagal jūsų bazines linijas, naudodami konkrečią metriką. Jūs netgi turite galimybę palyginti to paties serverio bazines linijas, naudodami tą patį metriką skirtingais laikotarpiais. Galite pamatyti, ar atsirado skirtumų, ar tai yra delta. Tų variantų rūšių taip pat yra daug.
Erikas Kavanaghas: Dez.
Dezas Blanchfildas: Vienas greitas klausimas, kurį turiu jums - yra platus pasirinkimas, ką ši priemonė gali padaryti. Ar pastebite, kad jo naudojimas buvo pradėtas ankstyvajame vystymosi etape, ar vis dėlto tai vis dar yra gamybos aplinkos įrankis? Kitaip tariant, ar kūrėjai gauna prieigą ir naudojasi ja ankstyvo vystymosi metu, o tada išbando integracijos etapą? O gal ji vis dar naudojama gamybos aplinkose?
Bullett Manale: Aš sakyčiau, kad daugumą kartų mes tai matome gamybos aplinkoje. Tai priklauso nuo situacijų, tačiau didžiąja dalimi sakyčiau, kad pirmiausia gaminame ir mes - ir taip pat, žinote, teisinga paminėti, kad turime skirtingas dev ir bandymų aplinkos kainas, taigi ji yra šiek tiek patrauklesnė. Mes matome, kaip žmonės tai naudoja tokioms aplinkoms, bet, sakyčiau, jei turėčiau atsakyti vienaip ar kitaip, aš sakyčiau, kad tai daugiausia vis dar gamybos aplinka, kurioje matome, kaip žmonės investuoja į šį produktą .
Dezas Blanchfieldas: Žinoma, taip ir buvo įdomu išgirsti, kad gavai skirtingus kainų taškus, nes akivaizdu, kad yra skirtingi darbo krūviai, ir kuo sunkesni bus darbai, kur atliekamas tikrasis darbas. Bet aš matau daug organizacijų, ypač vyriausybėje ir, be abejo, gynybos srityje, kur plėtojant dabar investuojama į tokio paties lygio įrankius ir sistemas kaip į gamybos aplinką, nes jos atlieka daug daugiau išankstinių bandymų. Pavyzdžiui, gynyboje yra komandų, kurios vykdo milijardus testų, šimtus milijardų testų, susijusių su programomis ir sistemomis bei įrankiais, ir stebi juos, prieš pradėdami net integruoti, nes nori įsitikinti, ar yra sukurtas kodas ir duomenų bazė. tai sėdi po juo. Patenka į šimto milijono iteraciją ar panašiai, o kai lauke šauksi į ką nors, jis nesibaigia.
Bullett Manale: Žinoma.
Dezas Blanchfieldas: Remdamasis savo patirtimi senosios mokyklos duomenų bazių pasaulyje, manydamas, kad duomenų bazės aplinka yra kažkas, kas liko tik duomenyse, o kai kurie iš jūsų žinote, yra labai retai matomi ir apie juos kalbama labai retai, taigi, kai mes susipažinome, kai įrankiai ir Programos yra kuriamos, ypač su analitinėmis platformomis, dabar jos yra mūsų telefonuose ir mūsų įrenginiuose. Ar matote, kad klientai įtraukia duomenų bazės veikimo ir duomenų tvarkymo pokalbį į kasdienes diskusijas, o ne vien tik į technikas? Ir aš žinau, kad jūs anksčiau minėjote, kad daugiausia kalbatės su DBA, bet ar dabar yra tendencija, kai kalbama apie bendrą žodyną, ar matote žmones, kur jie aptaria šias temas, o ne tiesiog genius?
Bullett Manale: Na, sunku pasakyti. Aš turiu omenyje, kaip aš daugiausiai sakiau, žmonės, su kuriais mes vis tiek susiduriame dėl pardavimo proceso, yra praktikai, kurie yra DBA. Taigi, kalbant apie jūsų klausimą, jūs tiesiog sakote: „Kalbant apskritai apie IT organizacijos žmones, ar jie geriau žino duomenų bazę?“ Manau, kad yra klausimas, ir turbūt atsakyčiau, kad atsakymas yra „taip“. Turbūt nematau tiek daug, atsižvelgiant į tai, kur esu kasdien, tačiau manau, kad jei suprantu jūsų klausimą, manau, kad tai būtų mano atsakymas.
Dezas Blanchfildas: Taip, tai gerai. Tikriausiai tai labai apkrautas klausimas, atsiprašau, nes akivaizdu, kad dominuojantys jūsų interesai jūsų pasaulyje yra techninė dalykų pusė. Man įdomu, kad vykdydamas savo kasdienę veiklą matau, kad organizacijos labai anksti pradeda tai įtraukti į pokalbį. Taigi, kai jie kalba apie naujas iniciatyvas, naujus projektus, naujas darbo programas, vienas iš karto ateinančių dalykų yra: „Kaip mes jį stebime, kaip mes jį stebime, kaip sprendžiame iškilusias problemas, priešingai nei paleidimas, tiesioginis transliavimas? "
Bullett Manale: Aš sakyčiau, kad -
Dezas Blanchfildas: Atsiprašau, eik į priekį.
Bullett Manale: Aš ketinau pasakyti, kad matau tendenciją, kurią, kaip manau, turėčiau pasakyti, - žinote, daug kartų praeityje gaudavote: „Turėjome problemą, todėl dabar mums reikia įrankio. " Ir aš manau, kad mes matome šiek tiek daugiau pritarimo tam, kad turėtume įrankį vietoje, kol iškyla problema, jei tai yra prasminga. Taigi, sakyčiau, kad tikrai tampa normaliau, žinai: „Ei, mums reikia stebėjimo įrankio, kažko mums reikia.“ Ir žmonės tikrai mato šio produkto vertę, nes, kaip jūs sakėte anksčiau, tiesiog pridedate DBA ir pridedant naujų egzempliorių, jums reikia kažko, kas tai suvaldo. Jums reikia kažko, kas padėtų valdyti tai, todėl mes pastebime, kad ir šis produktas daug ką priima, arba mes jį turime.
Dez Blanchfield: Greitas klausimas. Kur tai reikia gyventi? Ar jis turi sėdėti tiesiai ant nudegimo LAN tinkle, duomenų centre, kiek įmanoma arčiau duomenų bazės aplinkos, ar jis yra patogiai patalpintas kažkur, potencialiai debesyje, trečiosios šalies debesis su kažkokiu arba VPN tunelis, arba nuotolinė prieiga prie įvairių aplinkų? Kur tai sėdėti, atsižvelgiant į aplinką ir stebėjimą?
„Bullett Manale“: Kalbant apie architektūrą, yra atsarginis saugykla ir tai yra „SQL Server“ duomenų bazė. Mes turime konsolę, kuri gali būti nei riebi, nei plona; mes suteikiame jums abi galimybes. Mes taip pat turime nedidelį klientą, kuris taip pat yra specialiai pritaikytas mobiliesiems įrenginiams. Bet kalbant apie tai, kur tai gali sėdėti; jis gali sėdėti aplinkoje, iš tiesų sudėtingesnė dalis informacijos, kurią mums reikia surinkti, iš tikrųjų reikalauja administracinių teisių, kai kuriais atvejais arba daugeliu atvejų. Dabar mes neverčiame tavęs to daryti; jei norite, galite rinkti duomenis ir tik dėl dalykų, kurių negalime rinkti, nes neturime administratoriaus teisių, mes tiesiog leisime jums nematyti tos informacijos, jei tai jūsų pasirinkimas.
Atsižvelgiant į skonį, pavyzdžiui, jei jūs kalbate apie AWS, kai kurios aplinkos, jis veikia geriau nei kitos, tačiau tiek, kiek yra tikroji aplinka, paprastai viskas, kas naudojama SA autentifikavimui rinkti duomenis iš egzempliorių, yra būtina. Arba, jei tai nepatikimas domenas, paprastai tada reikia tai padaryti, bet keli domenai; tol, kol tarp jų yra pasitikėjimas, mes galime rinkti prieš tuos. Nesvarbu, ar tai LAN, ar WAN, pats rinkimas yra nereikšmingas atsižvelgiant į tai, kiek duomenų renkame. Jei turime pakankamo dydžio WAN ryšį, tai nėra problema. Aš mačiau aplinką, kurioje jie turi filialus, kur jie turi SQL serverius visoje JAV. Ir tai yra vienas serveris kiekvienoje iš šių skirtingų vietų, ir jie stebi jį centralizuotai. Sudėtinga dalis yra tik įsitikinimas, kad turite pakankamai ryšio, kad galėtumėte tai padaryti. Tikiuosi, kad tai atsakys į jūsų klausimą, jis buvo toks, koks buvo visame žemėlapyje.
Dezas Blanchfieldas: Tai tikrai. Ačiū. Taigi, du greiti klausimai, kurie šį rytą kilo klausytojams; viena: koks yra poveikis - dažnai matome, kad sistemos stebėjimo įrankiai sukuria apkrovą patys, tik stebėdami dalykus, todėl kilo klausimas, gaila, kad jis dabar nuslinko nuo mano ekrano, o tik perfrazavo; stebėdami ar mes patys generuojame apkrovą? Ar yra išmatuojamas įrankio poveikis, tiesiog stebint aplinką, ar jis yra nereikšmingas?
„Bullett Manale“: Visada bus šiek tiek įtakos, nes ji turi pateikti užklausą „SQL Server“ egzemplioriui, kad galėtų sugrąžinti duomenis. Klausimas, kaip jūs sakėte, yra „Ar jis nereikšmingas ar reikšmingas?“ Iš dėžutės, kuriai nurodote pavyzdį, ji yra nereikšminga. Kaip jau sakiau, mes tai darėme gana ilgai. Mes turime daugiau nei 20 000 klientų ir galiu jus patikinti, kad jei tai nepadarys reikšmingos įtakos veiklos rezultatams, mes neveiksime verslo. Tai pasakę, mes taip pat leidžiame vartotojui nuspręsti, ką jie nori stebėti. Taigi, manau, svarbu paminėti, kad kiekviena aplinka yra šiek tiek kitokia.
Pavyzdys galėtų būti tas, kad užklausos stebėjimo komponentas yra vienas iš dalykų, kuriuos galime atlikti, jei galime nustatyti jūsų normos ribą, kurią laikote savo normos riba. Taigi tai galėtų būti pagrįsta užklausos atlikimo laiku. Tai galėtų būti pagrįsta centriniu procesoriumi, įvestimi / išvestimi, bet, tarkime, tarkime, kad savo vykdymo laiką nustatiau iki nulio milisekundžių. Iš tikrųjų, ką aš sakau įrankiui, reikia surinkti visus klausimus, kurie vyko po paskutinio traukimo intervalo, ir sudaryti tą mano istorinės kolekcijos dalį.
Dabar, kai tai padarysime, mes surenkame bet kokį kiekį užklausų, kurių mes buvome atlikę dėžėje nuo paskutinės apklausos. Dabar tai pasirenkama, ir vartotojas turi galimybę tai padaryti. Ar mes sakome: „Štai ką turėtum daryti?“. Ne. Tačiau mes taip pat suteikiame jums galimybę tai padaryti, jei norite duomenų pavyzdžio, kuris leistų jums rinkti tą informaciją. Taigi paprastai jūs turite priemonių įrankis jį nustatyti ir sureguliuoti tiksliai taip, kaip norite, atsižvelgiant į tai, kas jums patogu. Tačiau jūs turite galimybę iš tikrųjų atidaryti, jei norite, ir surinkti daug papildomos informacijos, kurios galbūt nebūtinai reguliariai turėtumėte. rinkti, jei tai prasminga.
Dezas Blanchfildas: Taip, absoliučiai. Aš žinau, kad bėgame šiek tiek ilgai, tačiau yra du tikrai dideli klausimai, kuriuos noriu išmesti prieš tave apvyniodamas. Jie abu ateina tiesiai pas mane, bet aš manau, kad geriausia, jei į juos atsakysite. Klausimas paprastai buvo toks: „Kokia įrankio pasiekiamumo sritis, kiek reikia žinoti apie esamas sistemas?“ Taigi, ar galime tiesiog prijungti šį įrankį ir leisti automatiškai aptikti ten esančią platformą, ir žinoti, kas yra normalu tai platformai, nedelsiant? paimk, kaip Markas anksčiau kalbėjo? Kai kurias bazines žinias apie platformas įvesdamas, tu žinai, aš nežinau, tai gali būti „Microsoft Dynamics“. Kas yra platformos žinių apimtis su tuo, kas normalu ir normalu kai kuriuose dabartiniuose nepriekaištinguose įrankiuose, kurie naudojami visame versle?
Bullett Manale: Aš sakyčiau, kad paprastai pradedant rinkti duomenis apie SQL egzempliorių, pirmiausia dirbame su geriausia praktika, atsižvelgiant į mūsų slenksčius ir kur jie yra nustatyti. Be to, mes taip pat suprantame, kad su kuo kalbatės, kalbant apie geriausią praktiką, kiekviena aplinka yra skirtinga. Ką iš pradžių darysime, mes tiesiog renkame duomenis, o tai, ką žmonėms daryti rekomenduojame, galite išbandyti produktą 14 dienų ilgiau, jei to reikia. Bet maždaug po dviejų dienų pradėsite matyti pradinius duomenis. Kai ji turės pakankamai pavyzdžių informacijos, su kuria bus galima dirbti, tada ji pradės pateikti pagrindinę situaciją, ten, kur yra diapazonas, ir visą tokią medžiagą. Tada, jei norite, galite automatiškai nustatyti slenksčius pagal tą informaciją, kuri buvo surinkta. Pradėjus rinkti, kas yra normalu, reikia šiek tiek pradinio rinkimo ir apklausos, kad galėtumėte pradėti keisti savo slenksčius.
Tačiau, mano manymu, verta atkreipti dėmesį ir į tai, kad pakeitus šias ribas, tai gali būti daroma kiekvienai jūsų grupei. Tai gali būti būdinga vienam egzemplioriui arba galite tai padaryti prieš visus savo egzempliorius, taip pat galimybę kurti tokius dalykus kaip šablonai, kad galėtumėte pasakyti: „Tai yra gamybos egzempliorius, bet tai yra šablonas, kurio noriu priskirti tam “. Taigi, kai naujas gamybos egzempliorius pasirodo internete, mes automatiškai pritaikome tas slenksčius, nes jis turi to paties tipo aparatinę įrangą ir paprastai turi tą patį darbo krūvį, todėl mes taip pat galėtume tai padaryti. Tikiuosi, kad tai padės klausimo atžvilgiu.
Dezas Blanchfieldas: Tai tikrai. Tiesą sakant, jūs iš tikrųjų atsakėte į kitą klausimą, kuris ką tik man kilo, ir tai buvo: „Ar galima atsisiųsti bandomąją versiją?“ Aš galiu į tai atsakyti, aš žinau. Aš tikiu, kad patvirtinsite, kad čia yra nemokamas atsisiuntimas, ir aš manau, kad jūs sakėte, kad tai buvo 14 dienų nuo svetainės. Galite atsisiųsti ir žaisti. Vis dėlto greitai pagalvoju: "Kokia aplinka man reikalinga, kad galėčiau vykdyti bandomąją versiją? Ar galiu ją paleisti savo nešiojamajame kompiuteryje ir žaisti su juo, ar man tikrai reikia serverio?"
„Bullett Manale“: Pagrindinis dalykas, kurio reikia, yra saugykla, „SQL Server“ duomenų bazė, kuri yra 2005 m. Ar naujesnė. Išskyrus tai, yra keli minimalūs išteklių reikalavimai, .NET reikalavimas, ir viskas. Taigi, tereikia įdiegti produktą ir sukurti duomenų bazę.
Dezas Blanchfildas: Puikiai. Paskutinis klausimas, kurį įmesiu į tave, nes mes tiesiog pasenome, bet greitai maždaug du ar trys žmonės manęs paklausė: „Ar aš turiu būti DBA, kad iš tikrųjų galėčiau atsikelti ir bėgti su tai ir pažaisk su tuo? “
„Bullett Manale“: Ne. Aš sakyčiau, kad jei esate DBA, jūs naudositės skirtingais įrankio naudojimo būdais. Aš turiu galvoje, kad turbūt bus šiek tiek daugiau vertės, jei esi patyręs DBA. Pamatysite daug daugiau informacijos apie įrankį, kuriuo galėtumėte pasinaudoti. Bet taip pat kaip naujas DBA ar net žmogus, kuris tai nėra DBA, mes turime daug rekomendacijų, ir aš šiuo metu esu tame puslapyje. Šios rekomendacijos bus pateikiamos reguliariai, ir tikrai puiku dėl rekomendacijų, ar jos pateikia priežastis, kodėl teikiamos rekomendacijos. Be to, jie taip pat turės nuorodas į išorinį turinį, kuriame išsamiau aprašomos priežastys, kodėl taip pat teikiamos šios rekomendacijos. Taigi, tai bus nuoroda į išorines „Microsoft“ svetaines, tinklaraščius ir bet kokius panašius dalykus.
Bet jei norite atsakyti į jūsų klausimą, žinote, jei esate DBA vyresnysis, čia bus daug dalykų, ko gero, pasinaudosite tuo, ko tikriausiai nepajustumėte kaip naujokas DBA. Bet tuo pat metu tai taip pat yra mokymosi priemonė, nes, atlikdami šias rekomendacijas, naudodamiesi rekomendacijomis, jūs pradėsite pasirinkti kai kuriuos iš šių dalykų savarankiškai.
Dez Blanchfield: Fantastiška. Ačiū. Man labai patiko demonstracinė dalis. Pristatymas buvo puikus. Demonstracija buvo fantastiška. Greitai iš atminties jūsų svetainėje yra visas išteklių centras, kurį žmonėms rekomenduoju taip pat pasižiūrėti. Prisimenu, kad praeitą vakarą išgyvenau tam tikras detales. Jūs turite daugybę dalykų, tik nuo savo tinklaraščių, duomenų ir pokalbių iki atminties, taip pat ir didžiąją dalį savo gaminio dokumentacijos galite rasti internete, taip?
„Bullett Manale“: Taip, tai teisinga, ir aš manau, kad jūs remiatės svetaine „community.idera.com“. Ir tada paminėčiau vieną dalyką, kurio anksčiau paklausėte: „Ar tai atpažins aplinką?“ Kalbant apie naujus egzempliorius ar egzempliorių pridėjimą, yra dar vienas įrankis, kurį turime, kuris aptinka egzempliorius. Viskas priklauso nuo atsargų ir jų tvarkymo. Norėčiau jus tiesiog nukreipti ta linkme, kalbant apie faktų atradimą. Bet kiek tai susiję su našumu ir stebėjimu, tiek su visais dalykais, apie kuriuos mes kalbėjome, būtent čia pradės veikti diagnostikos vadybininkas.
Dez Blanchfield: Fantastiška. Žiūrėk, puiki aprėptis. Labai patiko jūsų pristatymas. Patiko tiesioginis demonstracinis demonstracinis filmas, ir tai viskas, kas man šį rytą, nes aš žinau, kad per tam tikrą laiką praleidome 10 minučių. Erike, aš jums perduosiu.
Erikas Kavanaghas: Gerai. Man tiesiog patiko demo. Džiaugiuosi, kad atlikote demonstracinę versiją. Džiaugiuosi, kad mums teko gražiai į tai atsižvelgti, kai ėjome į klausimus ir atsakymus.
Bullett Manale: Puiku.
Erikas Kavanaghas: Kadangi tai žmonėms suteikia supratimą apie tai, ką jūs žiūrite, ir tai mane tikrai nustebina pagalvojus, kad mes vis dar mokomės kalbėtis su šiais kompiuteriais, kai jūs suprantate. Aš turiu omenyje, kad šis diagnostikos lygis yra gana sudėtingas ir kasdien tobulėja. Mes gauname daug daugiau įžvalgos apie tai, kas iš tikrųjų vyksta. Bet jums tikrai reikia žmogaus, kuris pamiršta šią medžiagą, ją perskaito, užleisdamas tą pažintinį sugebėjimą už to, ką darote, tiesa?
„Bullett Manale“: Taip, aš turiu omenyje daugeliu atvejų - norėčiau, kad galėčiau pasakyti, kad tai DBA dėžutėje, tačiau čia yra tiesiog per daug dalykų. Aš turiu galvoje, kad mes teikiame gaires ir padedame, tačiau dienos pabaigoje žmonėms reikia priimti sprendimus dėl mūsų pateiktų duomenų. Nemanau, kad tai greitai pasikeis.
Ericas Kavanaghas: Tai gera žinia realiems žmonėms, žmonėms.
Bullett Manale: Teisingai.
Erikas Kavanaghas: Norėsite, kad kas nors tai stebėtų, komanda, kuri tai stebėtų, ir jūs sužinosite, kaip girdėjote iš „Bullett“ čia, žiūrėdami į šias rekomendacijas, rinkitės tai, kas vyksta. Aš spėju iš tos istorijos ir manau, kad jūs palietėte tai, „Bullett“, bet labai greitai, kad istorija leidžia atpažinti reikšmingus modelius ir todėl sugebėti juos atpažinti, kai jie įvyks ateityje, tiesa?
Bullett Manale: Tai teisinga. Vienas iš dalykų, kuriuos galime padaryti, yra sekti užklausos našumą bėgant laikui. Taip pat akivaizdžiai galime pažvelgti į kitus dalykus, pavyzdžiui, bazines linijas, ir pamatyti, kaip jie keičiasi, ir, aišku, sulaukti įspėjimų bei panašių dalykų, kai tai atsitiks, taigi jūs tikrai turite šį sugebėjimą.
Ericas Kavanaghas: Tai gerai skamba, žmonės. Ilgai čia nebūtume buvę, bet norėjau patekti į tuos klausimus. Labai ačiū už jūsų laiką ir dėmesį. Mes archyvuojame visas šias internetines transliacijas. Peršokite į internetą į Techopedia.com arba InsideAnalysis.com, pamatysite nuorodas iš abiejų vietų.
Su tuo mes atsisveikiname. Dar kartą ačiū, žmonės, mes su jumis susisieksime kitą savaitę, dar tris internetines transliacijas kitą savaitę, antradienį, trečiadienį, ketvirtadienį. Taigi, mes kalbėsimės su jumis kitą savaitę, žmonės. Pasirūpink. Iki.
„Techopedia“ turinio partneris
„Techopedia“ personalas yra susijęs su „Bloor Group“ ir su juo galima susisiekti naudojant dešinėje pateiktas parinktis. Norėdami sužinoti daugiau informacijos apie tai, kaip mes dirbame su pramonės partneriais, spustelėkite čia.- Profilis
- Interneto svetainė
