Predstava igra: poslovimo od zamude

Avtor osebja Techopedia, 9. maja 2016

Odvzem: Voditelj Eric Kavanagh intervjuva z Markom Madsenom, Dezom Blanchfieldom in Bullettom Manaleom o zaostajanju in uspešnosti.

Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.

Partner za vsebino Techopedia

Osebje podjetja Techopedia je povezano z Bloor Group in z njimi je možno vzpostaviti stik z možnostmi na desni. Za informacije o tem, kako sodelujemo s panožnimi partnerji, kliknite tukaj.

• Profil
• Spletna stran

Eric Kavanagh: Dame in gospodje, pozdravljeni in dobrodošli še enkrat k Hot Technologies! Da, resnično! Moje ime je Eric Kavanagh, to je naša oddaja Hot Tech, partnerstvo z našimi dobrimi prijatelji iz Techopedije. Skočite na spletno mesto na Techopedia.com za vse najnovejše na širokem področju podjetniške tehnologije; seveda zajemajo tudi potrošniške stvari. Tu se osredotočamo na podjetje v našem programu, tako da bomo to počeli danes.

Obstaja spot o tvojem resnično in dovolj o meni, počakaj me na Twitterju @eric_kavanagh, obožujem Twitter, obožujem, da preverim te stvari, to je odličen način za ohranjanje stika z ljudmi in dober pogovor, in ena na ena -en pogovori.

Torej o čem govorimo? Letos je vroče, to je celotno priložnost, ki ga danes gledamo v svet upravljanja informacij, in o čemer danes govorimo, bodo poizvedbe, pospeševanje poizvedb.

Mislim, da sem pozabil omeniti naslov, "Predstava igra: Pozdravi od zamude." Kdo hoče zamudo? Nihče ne želi latencije, latenca je, ko sedite tam, kliknete gumb in počakate, da se kaj zgodi, in tega nihče ne želi. Otroci ga ne marajo, ne mislijo, da je to kul, odrasli tudi ne marajo. Vse nas je razvajala hitrost spleta in stvari si želimo hitro, stvari si želimo zdaj in o tem bomo danes govorili v naši oddaji.

Analitik Mark Madsen je danes z nami iz Tretje narave, enega izmed naših rednih članov. Naš novi znanstvenik, Dez Blanchfield, ki prihaja iz Sydneya v Avstraliji. In potem Bullett Manale, ja, res, to je njegovo ime, pravzaprav naj bi šlo za dva T-a. Bullett Manale sodeluje kot naš gost iz Idere, zelo, zelo zanimivega podjetja, počne veliko stvari. Za njih že vem, eno od njih je, da so pred časom kupili podjetje z imenom Precision. Vedela sem, da je njihov izvršni direktor Zohar Gilad, kako je to ime? Pameten človek je bil hec.

Toda ljudje, igrate pomembno vlogo v tej spletni oddaji pri vprašanjih, ki jih postavljate, zato prosim, ne bodite sramežljivi, vprašanja pošljite kadar koli - to lahko storite s pomočjo Q&A komponente konzole webcast. v spodnjem desnem kotu. Lahko tudi poklepetate, jaz pa bom poklepetal pred govorci. Že imamo nekoga, ki kliče iz Italije, zato: "Ciao, ciao. Pridite stai? "V redu, s tem, da bom potisnil Markovo prvo vrstico, bom predal krovu Marku. Mark, zdaj imate WebEx. Vzemi stran, tla so tvoja.

Mark Madsen: Hvala, Eric. Ne bom pa začel na sredini, začel bom na začetku. Torej le nekaj pripomb, da se začne Dez in Idera razpravljati o nekakšnem stanju države z razvojem ter bazami podatkov in operacijami. In veste, če na to nekako pogledate, imamo na svetovnih bazah podatkov in na aplikacijah tovrstne težave na svetu, saj razvijalci vidijo DBA kot ljudi, ki jih preganjajo. Moraš sestaviti podatkovne modele, do tega ne moreš imeti dostopa, ne moreš ustvariti te stvari, ne moreš postaviti indeksa v vsak stolpec vsake tabele v bazi podatkov, da bi bil hitrejši. In seveda, zakaj potrebujemo modele? To so samo podatkovne strukture, če jih spremenimo, ali jih ne morete preprosto zapisati v serializirani obliki?

Težava je v tem, da razvijalci poznajo kodo in aplikacije, vendar dve stvari, ki ju pogosto ne poznata, sta sočasnost, sočasno programiranje in baze podatkov ter operacijski sistemi pod njimi. Ker sem bil razvijalec jedra in operacijskih sistemov in baz podatkov, lahko rečem, da sta sočasnost in paralelizem res težka, zato se veliko stvari, ki se jih naučite, da iz kode dosežete dobre rezultate, resnično začne razpadati, ko ste delo z bazo podatkov. Učinkovitost je videti super, testno okolje je videti super in okolje Q&A, nato pa zadene pravi sistem, potem pa kar naenkrat ni tako veliko. Ker je večplastna, kako koda deluje z bazo podatkov, kako deluje z okoljem in resnično majhne prakse lahko imajo drastične učinke, odvisno od obsega lestvice.

In ko začnete govoriti o zunanjih aplikacijah, so seveda zunanje aplikacije, spletne aplikacije, res lahko težke, saj so stvari odlične, dokler nenadoma ne poravnajo, in niso. Našli se boste na teh zanimivih planotah, ki zahtevajo veliko nianse za razumevanje.

Pogledi stvari so pogled DBA. Stališče DBA je, da obstajajo operacije, glavnino svojega časa, 80 do 90 odstotkov, porabijo v operacijah in morda 10 do 20 odstotkov, ki se ukvarjajo z razvojnimi stvarmi, ki se dogajajo vnaprej. S tega vidika bodisi plačate zdaj bodisi plačate kasneje in če ves čas porabite vnaprej, boste imeli pozneje veliko boljše možnosti, v nasprotju z razvojem, ki ponavadi raziskuje funkcijo prostora in poskušam ugotoviti, kako najbolje narediti stvari. In tako imamo težave, zdaj pa imamo nezdružljive metodologije - neprestano uvajanje, zvijanje aplikacij, kadar koli so pripravljene, periodično potiskanje kode, delo v trgovini, ki izvaja programe za razvoj. Takšna stvar pospešuje razvoj, vendar vse prakse v bazi podatkov in kaj DBA počnejo ter kaj so sistemski upravljavci usposobljeni za to, prakse IT operacij niso nadaljevale.

Če pomislite na to, večina DBA deluje v okolju nadzora sprememb v primerjavi z neprekinjenim okoljem uvajanja. Gre za stabilnost in nadzor ter hitrost sprememb in povratnost. Neprekinjena uporaba, če se ne morete vrniti iz sprememb, imate težave, zato je treba vse zgraditi tako, da je mogoče enostavno reverzibilno in preklopiti s kodo, kar pa ni tako, kako delujejo relacijske baze podatkov, razvojne prakse in prakse upravljanja .

Naletite tudi na te težave, da boste morali biti bolj aktiven, če lahko kot DBA, ker do trenutka, ko slišite za težavo, na vašem spletnem mestu sto tisoč ljudi izpolni pritožbene obrazce. Tako boste potrebovali nekaj novih stvari, ki jih ne boste dobili iz starega okolja. Veste, stvari, kot so boljše spremljanje in opozarjanje. Hkrati se baze podatkov množijo, dobili smo več aplikacij kot kdaj koli prej, da podpremo več stvari kot kdaj koli prej, notri so, zunaj so, povsod so. In bolj neodvisni nabori podatkov za analize ljudje na novo ustanavljajo baze podatkov, ker je seveda enostavno zdaj, lahko nastavite virtualni stroj. Če imate ponudnika oblakov ali notranjega oblaka, lahko takoj izpišete stvari in to spremeni celotno pot nabave.

Stara pot nabave je bila: "Imam čas, da dobim strežnik, ga potisnem v stojalo, dodelim prostor, shranim skladišče, namestim bazo podatkov in naredim stvari", nasproti pa je nekdo potegnil kreditno kartico in šel čez pet minut. Če to storite, moderno razvojno okolje deluje z zelo različnim tempom, zato je enostavno ustvariti baze podatkov in to samo ustvarja ta problem širjenja, kot nič, kar še nismo videli. In to traja že deset let, to nikomur ni nobena vest, pomeni pa tudi, da so se operativna okolja razvila v zapletenost.

Celotno okolje strežnika odjemalcev se je res spremenilo, ker ni več svet strežnikov odjemalcev. Takrat ste imeli strežnik, imeli ste bazo podatkov, če je bilo kaj narobe, ste vedeli, na kateri strežnik iti, ste vedeli, kako upravljati z viri na njem, ker je najboljša praksa ena baza podatkov, en strežnik. Virtualizacija se je začela ločiti, oblak jo še bolj razbije, kajti tisto, kar mislite, da je strežnik baz podatkov, je samo programska oprema. Torej okolje ni resnično. V njem je okolje, ki je resničnost, in to je lahko rezilo ali velik strežnik, razrezan na koščke, v resnici ne veste.

Vse v zvezi z upravljanjem baz podatkov in upravljanjem uspešnosti ter s tem, kaj so baze zgrajene okoli strogega nadzora z enim strežnikom ali peščico strežnikov in nekaj baz podatkov, ne morete nadzirati vsega. Sedite tam na stroju, vendar pasovne širine virtualni upravljavci ne morejo preprosto razdeliti, zato je s pomnilnikom in CPE-jem vse v redu, vendar ste v ozkem okolju vira, ki ga ni mogoče obravnavati, in nato kdaj poskusite to popraviti, stari model bi bil težko delati, dobil večji strežnik in naredil kaj takega, zdaj bi lahko bilo res preprosto, samo dodajte virtualni tečaj, samo dodajte pomnilnik v VM in to je rešeno. Toda kaj se zgodi, če je vaš VM na prenatrpanem strežniku in se mora seliti? Ali kaj se zgodi, če ste v velikosti AWS sistema in dosežete največjo velikost, kam zdaj greste?

Torej imate vse te težave, kadar je okolje zdaj del baze podatkov, pakirate okolje z bazo podatkov, vse posebne vire, vse v aplikaciji, ki je del konfiguracije, konfiguracija se tam izvleče. To je iz okolja baze podatkov, veliko težje ga je upravljati in nadzirati.

Če pogledate, kaj počnejo baze podatkov, so sedeli na njihovih rokah, kajne? Oddaljili smo se od te ideje, da bi baze podatkov in strežnike obravnavali kot hišne ljubljenčke. Strežniki imajo imena, z njimi ravnate, kot da so posamezno edinstvene stvari, z njimi ravnate kot z živino, upravlja s čredo. In težava pri upravljanju s čredami je v tem, da če jih ne nadzorujete, lahko sčasoma žigosajo in žigosanje ni dobra stvar. Potrebujemo boljša orodja za spremljanje, potrebujemo boljše načine za spopadanje s temi stvarmi in vemo, na kaj je to vplivalo. V starem modelu je bilo lažje, ker so vam povedali operacijski sistemi in vsi vaši nadzorni sistemi, ko pa je ime vašega strežnika UPC koda, je stvari težko razbrati.

Ne morete si privoščiti lažnih opozoril, ne morete si privoščiti stvari, ki pravijo: "S tem strojem je težava in ta stroj gosti 30 baz podatkov." Ne morete si privoščiti, da vam stvari ne dajejo zgodovine. Nadzorne konzole so odlične, ko se prižgejo, če pa rdeča lučka spet postane zelena in ne veste, zakaj in nimate zgodovine, da bi se vrnili nazaj, da bi pogledali, kaj je vodilo do tega in kaj kontekst je bil, da si v težavah. Potrebujemo sisteme, ki bodo nadzirali nas, potrebujemo boljše spremljanje, reševanje prekarnih težav s prekinitvami, ki ohranjajo to zgodovino podatkov.

Boljše stvari in preprosti pragi meritev, ki nam omogočajo ključne meritve, vendar nas ne usmerjajo neposredno v to, kaj je normalno, kaj je nenormalno in kako pogosto se pojavijo te težave. V resnici govorimo o kombinaciji nadzorovanja okolja in ukvarjanja z uspešnostjo, prodajalci pa so že sedeli na rokah. Boljšega orodja nam niso dali. Imamo sisteme z več CPU-ja in pomnilnika, kot vemo, kaj z vsem tem storiti, in kljub temu se še vedno zanašamo na modele ročnih intervencij, stroj še nismo postavili na delo, da bi nas vodili, da bi nas pripeljali do težav, še nismo prišli do tega novega sloga, ki je: "Tukaj je težava, lahko to odpravite" ali "Tu je težava z zmogljivostjo, dejansko s to specifično izjavo SQL. Tu so tri stvari, ki bi jih lahko uporabite za popravljanje te izjave SQL. "Uporaba hevristike, uporaba modelov strojnega učenja, ki lahko pogledajo vzorce uporabe sistema, da odkrijejo težave in se izognejo napačnim opozorilom. Uporaba stroja za tisto, kar stroj najbolje počne, za povečanje DBA ali za povečanje osebe, ki se mora spoprijeti s težavami z zmogljivostmi.

To je nov način, v nasprotju s starim slogom. Težave so s to bazo podatkov, stvari so počasne, zato imamo nove tehnike, nove načine, kako to storiti, in uporabljali bi jih morali. In tu gre trg. Vidite, da se začne pojavljati ne pri velikih prodajalcih, ampak pri drugih podjetjih, in to se zrcali, kar se je zgodilo pred 20 leti, ko prodajalci baz podatkov niso zagotovili niti ene stvari, s katero bi lahko upravljali sisteme. To je nekako smer tržišča in s tem bi ga rad vrnil Eriku.

Eric Kavanagh: V redu, predal ga bom Dezu. In Dez, vzemi ga, tla so tvoja.

Dez Blanchfield: Hvala, Mark. Naredili ste fantastično delo, ko ste pokrivali njegovo tehnično komponento. Na to bom prišel iz nekoliko drugačnega zornega kota, da bom izpostavil dogajanje v tujini, kar zadeva vpliv na podjetja in baze podatkov okoli njih. Naj samo skočim na svoj prvi tobogan.

Na zadnji strani tega, kar ste pravkar zajemali s tehnične strani stvari in s strani razvijalcev, vidim, da se morajo podjetja spoprijeti zlasti z izzivom podatkov in baz podatkov, in očitno smo doživeli ta pomemben premik v smeri ta koncept velikih podatkov, vendar učinkovito podatkovne baze so še vedno srce in duša, kjer organizacije hranijo svoje poslovne informacije, in to od vhodnih vrat vse do zadnje pisarne. Vsak del organizacije se dotakne neke vrste baze podatkov, ki jo poganja baza podatkov, zelo redko pa grem bodisi v razprave o projektih, bodisi v kakšno obliko inovativnega strateškega pogovora v organizaciji, kjer je tema baze podatkov ali sistem baz podatkov se ne pojavijo, in vedno se zastavljajo vprašanja o vrstah stvari, o katerih smo pravkar slišali, o uspešnosti in varnosti ter kako se razvoj loteva tega izziva in kam se baze podatkov prilegajo, ter o našem okolju in uporabi s katerimi se pogovarjamo, kaj pa naprave in mobilnost?

To je še vedno zelo, zelo vroča tema in je že dolgo, dolgo v veliki shemi stvari, kolikor gre za sodobno tehnologijo. V tem smislu verjamem, da je dejstvo, da skoraj vse, kar počnemo v vsakdanjem življenju, to je naše vsakdanje življenje, to je zdaj, ki ga podpira kakšna oblika baze podatkov. Ko pomislimo na vse stvari okoli nas, pa naj gre za račun, ki vsak dan pride po pošti za neko storitev, ki jo kupimo, jo neizogibno natisne sistem, ki govori z bazo podatkov, in tam smo. Naši telefoni imajo na njih baze podatkov s seznami stikov in dnevniki klicev ter druge stvari.

Kamor koli gremo, za pogovorom in sistemi, ki jih uporabljamo, obstaja neka oblika baze podatkov, ki so pogosteje pregledne za nas, toda dejstvo je, da so tam. Zato sem mislil, da bom hitro opisal, zakaj je to postalo težava v zelo kratkem času. Na začetku je koncept baze podatkov prišel od tega ljubkega gospoda Edgarja Codda. Medtem ko je delal v IBM-u, je spremenil svet, kar zadeva upravljanje podatkov, tako da je ustvaril koncept, ki ga danes imenujemo kot relacijska baza podatkov.

Na začetku je bila baza podatkov in življenje je bilo dobro, dokaj enostavna je bila tako v stolpcih, referencah, in tako naprej, in tabelah, in razvijanje programske opreme je bilo precej enostavno, uspešnost pa v resnici ni bila tako velika težava - šlo je za novo razburljivo tehnologijo. Do podatkovnih baz smo dostopali prek neke oblike terminala in resnično lahko resnično ustvarite toliko opustošenja na koncu terminala 3270 na mainframe in neizogibno drugih tipov terminalov, ki so prišli skupaj s temi drugimi sistemi. V večini primerov so bili terminali v starem slogu zelo podobni trenutnim spletnim okoljem, in to je, da bi na samem terminalu izpolnili obrazec na zaslonu in pritisnili Enter in off it go, ustrelil kot en paket, kot zahtevo, in back-end sistem bi se tega lotil. To se v bistvu dogaja v spletnem brskalniku danes, ko v spletnem brskalniku vtipkate povezavo in v takšni obliki običajno ne gre v realnem času nazaj v sistem, čeprav danes AJAX to ni povsem Ovitek.

Toda potem se je nekaj zgodilo, prihodnost je prišla, pred kratkim pa internet in skoraj včeraj v sek web 2.0 in tik za vogalom imamo internet stvari. In v prihodnosti se je svet baz podatkov samo razbulil, interakcije z bazami podatkov pa so postale stvar, ki smo jo vsi privzeto počeli, ni šlo, da bi šli nekam, da bi kaj storili, kot na primer kupili vozovnico za letalo in želeti potovati na drugo stran planeta, je moral nekdo vtipkati v terminal vse vaše podatke in iti v bazo podatkov in izpisati vozovnico.

Skoraj vse, kar počnemo zdaj, ne glede na to, ali gre za taksi na Googlu z aplikacijo, ali je skok na internetno bančništvo, vse, kar počnemo vsakodnevno, z nekakšnim sistemom, ki ga poganja baza podatkov. In ko se je pojavil internet, je bilo to malo lažje prinesti k nam, naše vsakdanje življenje prek spletnega brskalnika, nato pa je prišel web 2.0 in stvari so postale mobilne, lestvica stvari pa je samo eksplodirala. Pravzaprav je moja najljubša vrstica v tej temi ta: "Internet je povezal vse, splet 2.0 je naredil mobilno in družabno, in stvari so postale zelo, zelo velike in zdaj imamo internet in stvari, in IoT … Yikes !!" Sploh si nismo začeli predstavljati vpliva interneta stvari, ko gre za svet na sisteme baz podatkov.

Torej, v sodobnem pogledu je to, kar smo včasih mislili kot terminal, dejansko postale te stvari, to so mobilni telefoni, različne vrste tabličnih računalnikov, bodisi osebni potrošniški ali podjetniški tablični računalniki z velikim zaslonom, prenosniki in tradicionalno namizje v neki obliki. Na tej sliki lahko vidite skoraj vsako obliko vmesnika, ki jo zdaj uporabljamo za pogovor s sistemi baz podatkov in aplikacijami, ki jih poganjajo ti, od majhnih pripomočkov v naših rokah, ki hodijo naokoli in na katere se zdi, da smo prilepljeni, vsi vse do nekoliko večjih različic, iPadov, drugih tabličnih računalnikov in Microsoftovih površin, do vsakodnevnih prenosnih računalnikov, kar je v profesionalnih okoljih vedno tako. Ljudje ponavadi dobijo prenosni računalnik in ne fiksno namizje, vendar so po mojem mnenju sodobni terminal in del razloga, da se v zbirkah podatkov pojavljajo vse vrste izzivov pri uspešnosti upravljanja dela našega življenja in ne le pri razvoju.

Predvidevam, da je to eden največjih izzivov, s katerimi se podjetja še vedno srečujejo vsakodnevno. Vsi so mislili, da so baze podatkov naša edina težava, ne. Torej, kaj vse se muči? Ko gremo z enega konca na drugega z vsemi stvarmi, povezanimi z bazami podatkov, iz komercialnega vidika, Mark pa je tehnične sestavine zajel zelo, zelo dobro, toda v komercialnem smislu kot organizacija razmišljamo o zbirkah podatkov. S stvarmi se ukvarjamo vse od osnovnega dizajna in razvoja. Ko se podjetje začne, bodo razmišljali o razvoju aplikacij, razvoju zmogljivosti ali celo uvedbi obstoječe aplikacije v kakšni obliki. Nekatere oblike oblikovanja in razvoja se morajo odvijati in veliko razmišljanja je treba vnesti v to, kako bodo ti sistemi baz podatkov implementirani, podprti in upravljani ter spremljajo izvedbe in podobno.

Vključevanje okolja baz podatkov in aplikacij ter vrste API-ja, vrste dostopa, ki se zdaj zagotavljajo, postajajo vse bolj zahtevni in bolj zapleteni. Vsakodnevna administracija, podpora in varnostno kopiranje, spet so to stvari, za katere smo mislili, da so bile rešene, toda naenkrat je lestvica postala veliko večja in stvari so se hitreje premikale, obseg pa toliko večji; velikosti okolij so morali sistemi baz podatkov podpirati hitrost premikanja transakcij.

Pomislite na bazo podatkov v zelo, zelo visokofrekvenčnem trgovalnem okolju, tako da ljudje preprosto ne morejo slediti temu, to je samo skupina strojev, ki se borijo z drugo množico strojev, ki opravljajo visokofrekvenčno trgovanje, nakup in prodajo in količino katere transakcije se zgodijo. Razmislite o sodobnem scenariju, kot je predčasna izdaja filma Netflix, v katerem ne govorite samo o stotinah ali tisočih ali celo stotih tisočih, kar bi lahko na milijone ljudi pogledalo film že od samega drugega, ko je izšel. Vse te informacije se zajemajo, spremljajo in beležijo in analizirajo na platformi baze podatkov.

In tu je vedno ves čas v svetu, v katerem živimo, 24/7, ne le slediti Soncu, ampak vedno je nekdo ob polnoči, ki želi nekaj narediti, in delovne ure sledijo Soncu po vsem svetu. Torej sta čas in čas razpoložljivosti privzeto privzeta, zdaj sta klima, saj izpad resnično ni sprejemljiva stvar. In odveč, če obstaja težava z zmogljivostjo ali če potrebujemo okno za vzdrževanje, da opravimo nadgradnjo ali popravek ali varnost, resnično moramo biti sposobni prerezati iz enega okolja v drugo bazo podatkov in to storiti brezhibno in samodejno.

Varnost in standardi ter skladnost, v poznem svetu se je zgodilo nekaj zelo velikih stvari, zlasti GFC, in tako imamo celo vrsto novih izzivov, s katerimi se moramo spoprijeti glede skladnosti, varnosti in ustreznosti standardov, in potrebujemo da lahko o teh poročate v realnem času in v idealnem primeru v obliki nadzorne plošče. Nočemo pošiljati skupin opic v podatkovni center, ki poskuša najti stvari, potrebujemo sistem, da nam to sporoči takoj, v realnem času.

In dve veliki zabavi, o katerih skoraj nihče nikoli ne govori, ju na splošno potisnemo pod preprogo in upamo, da ne bosta nikoli dvignili svoje grde glave, ampak obnovo po nesrečah in nepretrganost poslovanja - to so stvari, ki bi morale biti večinoma se zgodijo samodejno, če bi se pojavile potrebe.

Lahko preživimo dneve v pogovorih o vrstah stvari, ki lahko gredo narobe v okolju baz podatkov, in na to, da so se ljudje na splošno odzvali, zdaj pa za to potrebujemo sisteme in orodja. En primer je kršitev podatkov in tako, ko razmišljamo o bazah podatkov, in to vprašanje odkrito postavljam v različnih oblikah: kaj se zgodi z bazami podatkov, ko si odvzamemo pogled z žogice in kaj kritičnega gre narobe? Še posebej, če ni sistema, ki bi spremljal zmogljivost in varnost ter druge pomembne vidike delovanja baz podatkov.

No, kaj bi se lahko zgodilo je to, to je posnetek zaslona nekaterih zadnjih kršitev v zadnjih dveh do treh letih. Vse to izvira iz sistema podatkovnih baz, in vedno se je pojavila težava z varnostjo ali nadzorom ali dostopom, in v zgornjem levem kotu si ogledujemo 152 milijonov Adobe računov, kjer je vsaka podrobnost teh strank je bilo kršeno. In če bi morda obstajala ustrezna orodja za sledenje in zajem dogodka ter za nadzor varnosti, smo se morda izognili nekaterim od teh, prvih par sto ukradenih zapisov bi nas lahko opozorilo, mi pa bi ustavilo naslednjih sto petdeset milijonov.

Nato pridemo do ključne točke tega celotnega potovanja, ki nas je popeljala, to je: zakaj potrebujemo boljše sisteme? Zakaj ne moremo preprosto metati več trupel na to, da smo po mojem mnenju dobro in resnično prestopili prelomno točko, in zagotovo verjamem, da obstaja primer, ki se je pozno dokazoval, da bi nanj vrgli več DBA, skrbnikov in več ljudi ta stvar ne odpravi težave. Potrebujemo boljši nabor orodij in boljši nabor sistemov.

Tu je mojih pet glavnih razlogov, za katere menim, da to podpirajo, in razvrščeni so po pomembnosti, glede na to, kar vidim v teh zasebnih podjetjih in državah, ki jih urejajo okolja, izzive, s katerimi se srečujejo z okoljem baz podatkov, in njihovo upravljanje.

Varnost in skladnost - številka ena. Veste, nadzor nad tem, kdo ima dostop, kje imajo dostop, kdaj imajo dostop, kako pogosto imajo dostop, od kod so dostopali. Potencialno naprave, ki so se jih dejansko dotaknili, in vrste stvari, ki so si jih ogledali, ter skladnost, ki je okrog tega. Če ljudje 30 dni kasneje pripravljajo poročila, da nam sporočijo, ali so stvari v redu, ni več primerno, to se mora zgoditi v realnem času.

Učinkovitost in spremljanje - zdi se, da ni možgan, vendar vedno ni. Ne glede na to, ali uporabljamo odprtokodna orodja ali katera koli komercialna orodja drugih proizvajalcev, čoln vedno nismo zamudili z vrstami potrebnega spremljanja zmogljivosti in podrobnostmi, ki in možnostjo odzivanja v času .

Zaznavanje in odzivanje na nesreče - to mora biti takojšnja stvar v realnem času in vedno potrebujemo sistem, da to stori za nas ali pa nas vsaj hitro opozori, da se lahko spopademo z njim, tako da se reši nekaj težav, ki se pojavijo s hitro in ne prekrivajte nadzora.

Upravljanje in uprava - spet mislimo, da so te težave rešene, niso. Cilj vprašanj, s katerimi se srečujejo ekipe baz podatkov, zlasti DBA, kjer bi moral sistem skrbeti za nas, tega problema še nismo rešili, še vedno je resnična stvar.

In že od spredaj naprej z načrtovanjem in razvojem, ko začnemo graditi ta orodja, gradimo okolja baz podatkov, bomo lahko metali ustrezna orodja pri razvoju in testiranju ter integraciji platform. To še vedno ni lahka stvar, in celotno potovanje nas nekako pripelje do istega sporočila, da v mojih mislih potrebujemo boljše sisteme in boljša orodja, ki nam bodo pomagala pri doseganju rezultatov, ki jih potrebujemo naše okolje baze podatkov, torej podjetja, ki prinašajo korist od naših strank. Ne moremo kar naprej metati več teles in več DBA, lestvica je prevelika, hitrost prehitra in glasnost prevelika. S tem bi se lahko vrnil Eric.

Eric Kavanagh: Všeč mi je, tam imamo veliko ljudi pokritih, veliko potencialnih voditeljev, mi pa gremo naprej in predamo Bulletta v samo eni sekundi.

Bullett Manale: V redu.

Eric Kavanagh: Oh, odvzemimo ga in Bullett, zdaj ti ga izročam in tla so tvoja.

Bullett Manale: V redu, hvala. Mislim, da je bilo veliko dobrih točk. Želel sem samo na kratko govoriti o Ideri, kdo smo, in potem bomo skočili. Govoril bom o orodju, o katerem mislim, da veliko o tem, o čemer govorimo, lahko vrsta in vrsta razpravljanja o nekaterih področjih, s katerimi se ta poravnajo, s tem orodjem, izdelkom Diagnostic Manager.

Zdaj, kar želim najprej storiti, je le, da vam malo predstavim, kdo je Idera; obstajamo že od približno leta 2003, zato smo začeli s samo orodji SQL Server in na to se bomo danes osredotočili, bi bil izdelek Diagnostic Manager. Lahko pa vidite vsa vedra stvari, ki jih imamo tukaj, in v zadnjem času, kot smo že omenili, smo pridobili Natančno in s pridobitvijo imamo tudi Embarcadero in tako imamo precej dober portfelj izdelkov.

V zvezi s spremljanjem uspešnosti, kar zadeva SQL Server, je izdelek, o katerem želim govoriti, ki poravnava te teme, o katerih razpravljamo, Diagnostic Manager. Zdaj je to izdelek, ki se pojavlja že od začetka idej, in sem imel srečo, da sem bil del tega od približno leta 2005. In videl sem veliko sprememb v smislu SQL Server, premik od fizičnega k virtualnemu, vse te stvari, ki se dogajajo, pa tudi potrebe DBA-jev, ki rastejo v okolju, in te vrste stvari.

Začela sem s tem, da je tipični uporabnik našega izdelka DBA, in ko se prvič pogovarjamo z ljudmi, bodočimi strankami, gre večinoma za DBA. Ne pogovarjamo se z vodji IT ali direktorji, morda bo v nekem trenutku dosegel to raven, toda prvotni začetek je, da ima DBA težave, DBA poskuša odpraviti težavo in velikokrat Kot del tega bom izdelek prenesla in prenesla ter preizkusila izdelek. Dobili boste upravljavca podatkov ali DBA ali delujočega DBA, moža, ki ima srečo, da je v nekaterih primerih najbolj tehničen v sobi. Ko boste očitno prišli do večjih podjetniških okolij, boste potem dobili polno razširjene DBA-je, običajno bodo ti uporabili orodje. In šel sem naprej in sem tu dodal malo zamegljenosti iz Wikipedije. Nekako gre za odgovornost DBA, kot pravi Wikipedia, to počnejo.

Če greš skozi seznam tukaj, veliko teh stvari, tega ne bom prebral, vendar dobiš veliko značilnih stvari, ki bi si jih omislili, in potem na enem od njih imaš nadzor in optimizacijo uspešnosti baze podatkov, in to precej. In kar je zanimivo, je, da, ko se pogovarjate z DBA, so vedno krivi tisti, ki se pojavijo, ko gre za težave, in morda res niso krivi, toda ko je težava z zmogljivostjo, običajno z aplikacijo, ki je vezan na bazo podatkov DBA, oni so tisti, ki so krivi, zato vedno iščejo razloge, zakaj niso krivi. V mnogih primerih je to tisto, kar jim lahko pomaga to orodje, Diagnostic Manager.

Toda na koncu dneva tudi, če baza podatkov ne deluje, veliko teh drugih stvari v resnici ni pomembno, vaše aplikacije ne delujejo, potem pa za veliko teh ni pomembno. stvari. Najprej in predvsem želimo zagotoviti, da uporabnik doživi tako, kot ga poznamo, da ne bo zmanjšan, to je nekaj, čemur si prizadevajo DBA. In mislim, da če pogledate razloge, zakaj ljudje običajno kupujejo in uporabljajo izdelek SQL Diagnostic Manager, eden prvih razlogov, verjetno ne najbolj, ne nazadnje, vendar je nekako enakovreden vsem, in odvisno od tega, s kom se pogovarjaš, teh razlogov je skoraj eden ali dva vedno, okoli tega obstaja kakšna potreba.

Toda prvi je le, da ima centraliziran pogled na primerke kot SQL, ki ga upravljajo. In smešno je, da v veliko primerih, če vprašate DBA, "Koliko primerov upravljate?" Številka se spreminja tako pogosto, da v nekaterih primerih res niso prepričani. Torej potrebujete nekaj več kot samo to, da lahko vse vržete na zaslon. Te informacije želite prevzeti, jih želite smiselno preučiti, zato je to ena izmed stvari, s katero vam Diagnostični upravitelj zagotovo lahko pomaga, to, da vam lahko zagotovi takšen pogled v okolje.

In to ni samo pogled na okolje, ampak je pogled, s katerim je DBA, skrbnik baze podatkov, udoben in je konzola, ki je usmerjena v DBA, če hočete. Narejena je za skrbnika baze podatkov. Zunaj je veliko orodij za spremljanje, veliko orodij za delovanje, ampak kot sem rekel, na koncu dneva DBA želi orodje, zasnovano za DBA, ker je veliko stvari, ki so značilne za to, kar počnejo v njihov dan v dan.

In s tem rečeno, imaš SCOM, imaš HPF, imaš vse te druge tehnologije, vendar želijo nekaj, kar je značilno za to, kar počnejo. Mislim, da si lahko na tem področju pomagamo s tem izdelkom, boste videli, ko bomo vstopili vanj čez sekundo. Druga stvar, ki jo vidimo pri agenciji DBA, je zagotovo ena izmed stvari, ki smo se je dotaknili tudi prej, je, da morajo očitno videti, kaj se dogaja, in jih je treba znati pogledati skozi celotno podjetje in imejte nekaj miru, da veste, kaj se dogaja. Toda hkrati ne sedijo tam in gledajo v konzole.

Se spomnite vseh tistih točk, ki ste jih videli na seznamu, ki sem jih pravkar potegnil? Tudi druge stvari morajo storiti, zato ne gre samo za čakanje na gašenje požarov. V veliko primerih bodo srečanja ali pa se veliko vzdrževalnih oken, povezanih z skrbnikom zbirke podatkov, izvaja sredi noči, ko spi, zato morajo imeti možnost, da se vrnejo nazaj in vidijo, kaj se je zgodilo . Če težave ne ujamete v mnogih primerih, ko težava izgine, ali vsaj s SQL strežnikom, postane nekakšna težava, ko se spopadate s situacijo, ko ne da že obstajajo ostanki te težave. In te težave odidejo, tako tudi ostanki, kar pomeni, da imate manj težav, s katerimi imate manj informacij.

Glede na to je zagotovo ena od stvari, s katero si lahko Diagnostic Manager pomaga, da vam da pogled v preteklost, da poizvedujete podatke iz preteklosti: "Ali sem imel opozorilo z blokiranjem, ali sem imel težave z zastojem, smo se kaj dogajali glede na naše vire? "Lahko se vrnem in poizvem te podatke. Lahko se podrobno seznanim s časom. Vse te stvari bi lahko naredil neposredno iz orodja.

Vse te stvari, ne glede na to, ali gre za notranjo ali zunanjo aplikacijo, želi DBA vedeti, ker želijo videti, kaj povzroča težavo. V resnici ni pomembno, ali je nekdo v organizaciji ali nekdo zunaj organizacije napisal kodo; še vedno ga želijo izolirati, tako da vedo, da se težava dogaja, in vedo, od kod prihaja.

Tako sta uspešnost in odgovornost ključni del našega izdelka. Vse te podrobnosti vam lahko zagotovimo, in kar je lepo, ali imate možnost vrtanja. Če obstaja ozko grlo, lahko to povežete z aplikacijo, uporabnikom, bazo podatkov in poizvedbo. In še enkrat, to je nekakšna puška za kajenje. Dobiš direktno povezavo med tem, ko te poizvedbe tečejo, kaj počne? In ne gre samo za samo poizvedbo v smislu, da se izvaja samo po sebi, ampak tudi, da se poizvedba sčasoma poslabša? In na te stvari je mogoče odgovoriti tudi z izdelkom, kar je vsekakor nekaj, kar je, če se trudiš biti proaktiven, lepo reči, "Hej, tukaj je poizvedba, ki je šla slabo, a fant poglejte ko teče naprej, vidimo, da teče še slabše in slabše, lahko naredim nekaj o tem. "

Če gremo tukaj na naslednje območje; in to je verjetno - rekel bi, da je to ena velikih. Eno od vprašanj, ki jih zastavljam, ko bom pokazal naš izdelek, bom vedno vprašal skrbnika baze podatkov: "Kako slišite za težavo, povezano z vašimi zbirkami podatkov SQL Server?" In je zelo smešno, saj večino časa - zdaj že odobreno, večino časa gledajo naš izdelek, saj v veliko primerih poskušajo rešiti določeno potrebo. Zanimivo je slišati začetne stvari - vsaj pri SQL Serverju je, da je bilo to nekako - veste, v zgodnjih dneh SQL Serverja ste imeli SQL Server in potem ste imeli Oracle. In vsi so imeli Oracle in SQL Server je bil nekako takšen, ker ni bilo boljšega izraza rdečelaska pastorka baz podatkov, ko se je prvič zagnala.

In ko je Microsoft temu dodal še več funkcij, je postal malce bolj poslovno orodje. In očitno je od takrat že daleč. Toda poanta je v tem, da bi nekoč lahko trdili, da se v teh dneh baze podatkov ne štejejo za kritične. In to se sčasoma spremeni. Zaradi tega se v mnogih primerih ljudje trudijo, da bi si jih omislili in govorili: »Veste kaj? Imam vse te zbirke podatkov SQL Server, poskušam se rešiti. "In namesto da bi slišal za težave iz službe za pomoč ali slišal za težave določenih ljudi, ki - tako kot uporabniki sami" iščejo načine, kako to premagati. Iščejo načine, kako se lahko zavedajo teh situacij, preden se kdaj zgodijo.

In tako je pri Diagnostic Managerju to ena izmed stvari, ki jih poskušamo storiti, vsaj to, da lahko DBA prvič izve za te situacije ali te težave, tako da lahko počnejo nekaj o tem, bodisi prav, ko se zgodijo, ali pa naredimo še korak dlje, da analiziramo te sisteme, ki jih spremlja. In da bi vam lahko dal proaktiven nasvet, ki bo izboljšal delovanje tega primerka, in to lahko redno. Na primer, dodati moramo indeks na podlagi delovne obremenitve; tiste vrste stvari, orodja, ki jih tudi lahko počnemo. Tako bomo v orodju videli veliko tega.

Druga stvar in zadnja stvar, ki je na tem seznamu, je nekako bolj splošen opis, vendar je vsekakor vredno opozoriti. In še posebej, ko se znajdete v večjih tipih situacij na podjetniškem nivoju, kjer imate veliko primerov, bo vedno prišlo do neke nejasne stvari, ki jo bom želel nadzorovati, če bom skrbnik baze podatkov, za primer. In to, kar poskušamo narediti, je predvideti v smislu, kaj bo tipični DBA želel nadzorovati.

Ob tem bi rekli, da bi lahko tudi v smislu - vedno bo kaj novega. Tako smo za vas dodali način, kako dodate vse meritve, ki jih potrebujete za spremljanje in upravljanje po dodajanju točke namestitve. Torej kateri koli števci PerfMon, števci WMI, števci predmetov SQL Server; vse, ki jih lahko vključimo v orodje. Lahko dodate dodatne poizvedbe, ki jih lahko vključite v svoje volilne intervale.

In še zadnja stvar, ki jo je prav tako treba opozoriti, je, da lahko dodamo in dejansko komuniciramo tako z vCenter kot s Hyper-V, da lahko iz teh okolij potegnemo meritve. Ker je ena od stvari, ki smo jih identificirali z DBA, ta, da običajno niso posebej del operacij. In ti običajno nimajo, veste, okolja vCenter, ki jim je na voljo, ali takšnih stvari, ki so jim na voljo.

In zato je težava v tem, da če imajo opravka z primerom SQL Server in so jim dodeljeni viri, vendar je ta primerek virtualiziran, je videti, da imajo vsi viri na svetu, ko samo spremljajo, kaj na gostujočem operacijskem sistemu. Resničnost je, da je na gostitelju lahko 30, 40, ali 50 ali 100 drugih VM-ov, do katerih poskušajo dostopati, in imajo iste iste vire. In edini način, da to dejansko vidimo, je sporočanje tistim drugim okoljem in tistim vmesnikom v tem primeru, kar počnemo mi.

V orodje lahko dodate še druge vrste števcev. Zdaj ne gre samo za to, da bi lahko spremljali te števce, ampak da bi lahko naredili te nove števce, ki jih boste predstavili izdelku in jih naredili kot del orodja, kot da bi bili zunanja škatla . Običajna stvar, ki bi jo radi spremljali; tako da to pomeni, da jih lahko vključite v svoje nadzorne plošče. To pomeni, da jih boste lahko dodali v svoja poročila po meri, lahko očitno postavili pragove in opozorili nanje, hkrati pa jih lahko tudi izpostavili in bili sposobni določiti pragove z nekim znanjem, kje jih lahko nastavite na podlagi stvari, kot so vaše izhodiščne vrednosti in kaj je normalno. Torej, imate veliko takšnih stvari, ki so tudi v izdelku.

Nekaj, kar sem vam priskrbel, je tisto, čemur pravim "temeljni rezultati za Diagnostic Manager", in lahko nadaljujem z vami in samo malo poizkusim s tem, ko bom vstopil v izdelek. delite z mojega zaslona, ​​v redu, in to povlecite čez. Torej, kar boste videli, je to konzola za diagnostiko upravitelja. In kot sem že omenil, grem do tega prvega jedra, ki ga bo mogoče pogledati. stvari iz vrste pogleda na ravni podjetja. Obstaja veliko različnih primerov tega v orodju. Imamo neke vrste sličic; imamo več kot mrežni pogled. Tudi glede fleksibilnosti imamo imejte tudi spletno konzolo. Spletna konzola ima na voljo tudi druge poglede, kot so ključni zemljevidi in podobne stvari. Bistvo pa je, da imate to možnost, da si ogledate in vidite stvari na visoki ravni. Toda, ko se pojavijo težave, se kopate malo naprej v orodje in dejansko vidite točno določeno težavo lems, in imeti nek način, da razumejo in vedo, kaj se dogaja. In očitno je to zelo pomembno.

Zdaj, da bi lahko dejansko videli, kaj se je zgodilo v preteklosti; če gledam na težavo, ki se je zgodila včeraj ali pred tednom dni, potem boste v tej situaciji morali vedeti, da boste lahko šli na določen primerek SQL. Dobra novica pa je, da če veste, kdaj se je težava zgodila znotraj izdelka, lahko greste neposredno v brskalnik zgodovine. In lahko opozorim na točno določen čas dneva; lahko je od pred nekaj tedni, lahko bi bilo tudi od včeraj. Ne glede na dan, ki ga v koledarju izberem, bom nato predstavljen z različnimi volilnimi intervali. V tem primeru zdaj dejansko vidim, kaj bi videl, če bi konzolo ogledal 20. aprila ob 13:37

Torej se lahko vrnem nazaj v čas in potem, ko to storim, bodo vsi različni zavihki, ki jih vidimo tukaj, odražali to točno določen čas, vključno s poizvedbami, ki bi se lahko slabo izvajale, tudi morda, če Sem imel seje z blokado. Vse tovrstne stvari bi se pokazale v orodju in omogočilo mi bo, da očitno izkoristim te zgodovinske podatke, da bom lahko, če veste, odpravil težavo. Zdaj pri tem zapisku, ko govorimo o zgodovini, je treba opozoriti še na to, da zgodovine ne uporabljamo le za odpravljanje težav. Ta zgodovina je očitno zelo pomembna iz drugih razlogov. In eno od pomembnejših je, da lahko učinkovito sprejemate odločitve in hitro sprejemate odločitve s pravimi informacijami. Torej lahko vso to zgodovino, vse podatke, ki jih zbiramo, lahko poročamo proti.

Če nekdo pride k meni in reče: "Dobil sem to resnično novo aplikacijo. Spremenil bo svet, kot ga poznamo. Oh, mimogrede, potrebuje bazo podatkov, in oh, tako, da bo resnično prikoval V / I na računalniku, kjer je ta baza podatkov. " Če vem, da grem v to, potem lahko uporabim te podatke, da bom lahko zagotovil razvrstitev vseh svojih proizvodnih strežnikov, morda na podlagi zadnjih sedmih dni zbiranja. In zelo hitro bi lahko ugotovil, katere primere je najbolj smiselno uporabiti v tej bazi podatkov. Torej je ta vrsta zgodovinskih informacij, ki je tudi očitno zelo dragocena.

V smislu samih poizvedb; Glede na poizvedbe imamo v orodju veliko različnih načinov za to. Tisti, ki ga rad pogledam, je Pogled poizvedbe čaka, saj je Pogled poizvedb čaka zelo koristen v smislu ocene. Če se pojavlja ozko grlo, da bom lahko v bistvu določil vsa različna področja, ki vplivajo na to posebno poizvedbo; ne samo sama poizvedba in kakšen je vpliv te poizvedbe, ampak tudi, veste, iz katere aplikacije je prišla, iz katere seje je prišla, kateri uporabnik jo je poklical in vse te stvari, lahko vidim, da so očitno informacije v realnem času, imam pa tudi možnost, da pogledam te podatke iz preteklosti. In tako je tukaj ena stvar, in začel sem scenarij, vendar moram počakati, da se nekako pojavi.

Medtem ko čakamo na to, želim - in vem, da imamo čas, zato sem se želel malo pogovoriti tudi o tem, da bi opozorilo lahko proaktivno. In ko govorite o takšnih stvareh, kot sem rekel, kot proaktivni del, obstaja veliko orodij, ki opozorijo. Težki del ni pošiljanje e-pošte. Težki del ni pisanje v dnevnik dogodkov ali ustvarjanje pasti SNMP. Težki del je vedeti, kdaj poslati opozorilo ob ustreznih trenutkih. In tako je s tem veliko opraviti nekaj izračunov in razumeti: "Kaj je s tem določenim primerom in kaj je normalno, če se nanaša na ta primer?"

In tako za vse meritve, ki jih je smiselno storiti z njimi, temeljimo te meritve. Pravzaprav vam pokažemo osnovno linijo, pokazali vam bomo prag, ki je trenutno nastavljen. In potem je še ena lepa stvar v tem, da recimo, postavim svoje pragove v tem primeru šest in deset samo za ta primer. Če se vrnem na ta primer, se čez šest tednov ta osnovna črta lahko popolnoma spremeni, saj je ena od stvari, ki jih počnemo, ko izračunamo osnovno črto, privzeto tekoči sedemdnevni izračun. Tako mi vedno daje najsodobnejšo različico osnovne linije. In kaj se zgodi, če se ta osnovna vrednost premakne na moje pragove? V tem primeru lahko vidim in opozorim na priporočila, ki v bistvu pravijo: "Hej, verjetno imate napačno nastavljen prag, specifičen za to, kje vidimo prag, in tam, kjer je osnovna črta, verjetno boste biti opozorjen na nekaj, kar je običajni pojav. "

In zato namesto da zdravim simptom nekaj normalnega, lahko prepoznam tisto vrsto situacije, kjer je dejanski prag postavljen napačno. In kar mi očitno omogoča, je, da postavim pragove v skladu s tem, kje bom opozorjen. To je nekaj, za kar vem, da je bolj poziv k ukrepanju in preiskavi, da bi ugotovili, ali gre res za težave. Mislim, da je del orodja resnično koristen glede na izhodiščno vrednost in da je mogoče izračunati.

Zdaj lahko s tem izdelkom dejansko ustvarite več osnovnih osnov; lahko jih nastavite za različna časovna obdobja in lahko dinamično prilagajate pragove glede na svoje osnovne črte, kar je tudi zelo pomemben del prilagajanja spremembam, ki se vsakodnevno dogajajo vašim primerkom SQL Server . Zdaj v tem primeru nekako pokrivamo veliko nastavitev pragov in vam prikazujemo osnovne vrednosti. Kar zadeva dejanska opozorila, pa je samo obveščanje, kar je najbolj všeč pri Diagnostic Managerju, ali vam ponuja več profilov opozorila. Če imate na primer profil za dežurstvo med 2. in 5. uro, potem imam lahko profil, ki ustreza točno temu časovnemu obdobju, in tukaj lahko nastavim vse pogoje in ustrezne nastavitve za moj odgovor.

Zdaj je stvar odgovora v tem, da v nekaterih primerih da, lahko pošljem e-poštno sporočilo ali odstrelim in ustvarim pasti SNMP ali napišem v dnevnik dogodkov. Obstajamo lahko veliko drugih stvari, toda ko se pogovarjam z DBA, je resnično všeč dejstvo, da je v večini primerov veliko dela, ki ga opravljamo, ponavljajoče se stvari. To je stvar, ki točno vedo, kdaj se težava zgodi, kaj storiti, da jo odpravijo. Preprosto morajo iti in posredovati. In ko rastete svoje okolje, ko imate več primerov, to postane veliko težje storiti. Torej je ena izmed stvari, ki jo lahko naredite v orodju, za katero menim, da je vredno opozoriti, ali imate možnost, da postavite pogoj, toda na podlagi tega pogoja lahko nastavite odgovor za zagon skripta in zaženete delo, za vodenje izvedljivega. In poanta je, če se odločite za zagon skripta, lahko uporabim parametre znotraj tega skripta, ki bo v času izvajanja, napolnjen z dejanskimi informacijami.

Torej, če obstajajo težave z določeno bazo podatkov, bo skript zasnovan tako, da deluje samo proti bazi podatkov, kjer se težava dogaja. Torej, lahko težave samodejno rešujete samodejno, nato pa lahko še vedno prejmem e-poštno sporočilo, da se vrnem in mi reče, "Hej, prišlo je do težave, a mimogrede, odpravljena je bila." Skript je bil izveden in kot DBA veste za to, vendar vam dejansko ni bilo treba vstopati in posredovati. Zdaj, ob isti opombi o proaktivnosti, očitno imamo tukaj še eno funkcijo, to je funkcija »Analiziraj«. In to bo to, da bo redno preverjal primernost SQL-a. In v nekaterih primerih bo naredil globlji potop v smislu, kaj išče. Izvedene bodo stvari, kot je hipotetična analiza indeksa. Ali dodam indeks? Ali odstranim kazalo? In vse te stvari bodo očitno pomagale pri mojem nastopu, ampak še enkrat, da gre za proaktivnost. Gre za to, da lahko sprejemate odločitve, preden se stvari razidejo, in za boljše delovanje. In v mnogih primerih to resnično poskušamo narediti tukaj.

Vrnitev k poizvedbi čaka, o kateri smo že govorili; kot vidite, je tukaj velik špic. Prej sem vodil scenarij, ki je povzročil nekaj čakalnih aktivnosti, in kot sem že omenil, imamo resnično edinstven način, kako lahko podrobneje preučite te podatke. Če želim videti, kakšna vloga je bila; Vidim, da prihaja iz aplikacije NoSQL. Lahko bi videli bazo podatkov, na katere je bila vezana, sejo, uporabnika, potem pa, če hočem, lahko to razvrstim tudi glede na čakanje. Lahko rečem, od vseh čakanj, ki so se dogajala v tistem časovnem oknu, katera so se dogajala najbolj? In če vidim, da ko se je to najbolj zgodilo, je res lepa stvar, da lahko vrnem v to vrsto čakanja in vidim vse ukaze. Če pogledate tukaj, so čakali, da se zgodi. V glavnem tudi vidim, katera aplikacija je bila, da se je to čakalo.

Tako štrli kot boleč palec. Takoj lahko rečem: "To je aplikacija, ki povzroča moje ozko grlo. Kaj je bila izvedena poizvedba? Kateri uporabnik jo je vodil? Katero bazo podatkov je izvajal?" In tako naprej. Torej, upam, da je to smiselno, in pomaga tudi pri zagotavljanju, da nimate zamud v svojem okolju, saj se nanaša na vaše podatkovne baze. Upajmo, da je to koristno. Na tej točki bom šel naprej in ga vrnil nazaj, in mislim od tam lahko nadaljujemo.

Eric Kavanagh: Seveda. Predvidevam, da bom to ravnokar vrgel našim današnjim strokovnjakom. Mark, morda najprej želite komentirati in postaviti nekaj vprašanj. Potem pa Dez, lahko zvoniš.

Mark Madsen: Ja, hvala, res sem užival ob gledanju tega. To je veliko bolj inteligentno spremljanje, kot sem ga vajen. Radoveden sem z upravljanjem podatkov za tem; upravljanje meritev, ki jih lahko spremljate, in veste, poiščite stvari, kot je premik izhodišč, zlasti to, da je to ena od mojih bolečinskih točk, z nadzornimi ploščami. Kako ravnate s temi podatki in drugi del tega podatka je z, veste, osnovnimi metrikami, kot nekakšen premik - ali imate možnost samodejnega premikanja pragov, tako da mi ni treba se vrniti nazaj in ponastaviti pragove z roko, ko se osnovna premica premakne?

Bullett Manale: Saj veš, in zato je lepa stvar v tem, da se lahko odločiš. Lahko naredite karkoli. Lahko postavim prag in ga postavim v statično nastavitev ali potrdim polje, da rečem: "Naj bo to dinamični prag, ki se bo spremenil, ko se bodo spremenile moje izhodiščne vrednosti." In imam možnost in orodje, da nastavim privzeto okno časa za mojo osnovno linijo. Potem pa bom morda moral imeti ločeno osnovno okno, na primer od vzdrževalnega okna od 2:00 zjutraj, recimo do 5:00, ker bom obdavčil svoje CPU, moji pogoni in vse ostalo, ker takrat opravimo vse svoje vzdrževanje. Potem bi samodejno, če bi to izbral, naredil samodejno, samodejno prilagodil svoje pragove, da bi bili zunaj tega, kar je normalno za tiste meritve, ki Odločim se za to. To bi mi omogočilo. V bistvu imate možnost znotraj orodja nastaviti časovna okna, to so vaša osnovna okna, in vsako okno se lahko obravnava kot ločena entiteta v smislu dinamična prilagoditev izhodišč, ki jo je mogoče narediti. In lahko dodate toliko oken osnovne linije kot yo u, če je to smiselno. Lahko bi imeli okno za vikend, teden v delovnem času, okno za vzdrževanje, ki se zgodi sredi noči in tako naprej, in tako naprej.

Mark Madsen: Hvala.

Bullett Manale: Predvidevam, da se vračamo na prvi del vprašanja, ki ga imamo, in zbiramo vse te podatke. Nisem res govoril o arhitekturi, vendar imamo skladišče za nazaj, da imate popoln nadzor nad hrambo teh podatkov, imamo pa tudi storitev, ki deluje sredi noči, ki gre in počne vsi naši izhodiščni izračuni in podatke zajemajo, zbirajo in imajo smisel. In očitno imate poleg tega tudi številna poročila, ki jih lahko uporabimo za poročanje proti vašim osnovnim točkam, za posebne meritve. Imate celo možnost, da primerjate svoje izhodiščne točke istega strežnika za isto metriko za različna časovna obdobja. Lahko vidite, ali so se pojavile razlike ali kakšna je delta. Veliko je tudi takšnih možnosti.

Eric Kavanagh: Dez.

Dez Blanchfield: Hitro vprašanje, ki ga imam za vas - obstaja širok spekter tega, kar lahko to orodje naredi. Ali zdaj opažate privzem uporabe le-te v zgodnji fazi razvoja ali je to predvsem orodje proizvodnega okolja? Z drugimi besedami, ali razvijalci dobijo dostop in ga uporabljajo z zgodnjim razvojem in nato preizkušajo fazo integracije? Ali se še vedno pretežno uporablja v proizvodnih okoljih?

Bullett Manale: To bi rekel, večinoma ga vidimo v proizvodnih okoljih. Odvisno je od situacij, večinoma pa bi rekel predvsem proizvodnja in mi - in tudi, veste, pošteno je omeniti, da imamo različne cene za razvojna in testna okolja, zato je to nekoliko bolj privlačno. Vidimo ljudi, ki ga uporabljajo za ta okolja, vendar bi rekel, če bi vam moral odgovoriti tako ali drugače, bi rekel, da gre predvsem za proizvodna okolja, kjer vidimo, da ljudje vlagajo v ta izdelek .

Dez Blanchfield: Seveda, da in zanimivo je bilo slišati, da imate različne točke cen, ker očitno obstajajo različne obremenitve in težja delovna mesta so tam, kjer se opravljajo vsa prava dela. Vendar vidim veliko organizacij, zlasti v vladi in zagotovo v obrambni dejavnosti, kjer razvoj zdaj dobiva enako raven vlaganj v orodja in sisteme kot proizvodna okolja, saj delajo veliko več predhodnih testiranj. Na primer, v obrambo obstajajo ekipe, ki izvajajo milijarde testov, na stotine milijard testov za aplikacije in sisteme in orodja ter jih spremljajo, preden sploh začnejo testirati integracijo, saj želijo zagotoviti, da je vgrajena koda in baza podatkov sedi pod njim. Doseže sto in milijon iteracij ali kaj podobnega, medtem ko si zunaj na terenu, ko streljaš na nekoga, pač ne gre.

Bullett Manale: Seveda.

Dez Blanchfield: V mojih izkušnjah je baza baz podatkov stare šole, da je razmišljanje, da je okolje baze podatkov nekaj, kar smo pustili v podatkih in nekateri veste, zelo redko vidno in o njem zelo redko govorimo, tako da, ko bomo zdaj ugotovili, kje orodja in razvijajo se aplikacije, zlasti na analitičnih platformah, ki so zdaj na voljo v naših napravah in naših napravah. Ali opažate, da stranke v vsakodnevne razprave vodijo pogovor o uspešnosti baze podatkov in upravljanju baz podatkov, v nasprotju s samo izključno tehnično? In vem, da ste že omenili, da se pretežno pogovarjate z DBA, toda ali je zdaj trend, kjer je to v splošnem besedišču, ali opazite ljudi, kjer razpravljajo o teh temah, v nasprotju s samo gojki?

Bullett Manale: No, težko je reči. Mislim, kot sem rekel večinoma, ljudje, s katerimi se kljub temu ukvarjamo s prodajnim postopkom, so praktiki, ki so DBA. Torej, kar zadeva vaše vprašanje, pravite samo: "Na splošno se ljudje, ki se nahajajo v organizaciji IT, bolj zavedajo baze podatkov?" Mislim, da je to vprašanje in verjetno bi rekel, da je odgovor "da". Verjetno je ne vidim toliko, glede na to, kje sem, vsakodnevno, toda mislim, da bi bil odgovor, če razumem vaše vprašanje.

Dez Blanchfield: Da, v redu je. Verjetno je naloženo vprašanje, oprostite, ker so očitno vaša prevladujoča zanimanja v vašem svetu tehnična plat stvari. Radoveden sem, da v vsakodnevnih dejavnostih organizacije že zelo zgodaj začnejo to vnašati v pogovor. Ko govorijo o novih pobudah, novih projektih, novih programih dela, je ena od stvari, ki prihajajo takoj: "Kako jo spremljamo, kako jo spremljamo, kako se ukvarjamo z vprašanji, ko se pojavljajo, v nasprotju z lansiranjem, gredo v živo? "

Bullett Manale: To bi rekel -

Dez Blanchfield: Oprosti, pojdi naprej.

Bullett Manale: Hotel bi reči, da vidim trend, za katerega bi verjetno moral povedati - veste, velikokrat v preteklosti bi se vam zgodilo, "Imeli smo težavo, zato zdaj potrebujemo orodje. " In mislim, da se nekoliko bolj strinjamo, da imamo orodje, preden se težava zgodi, če je to smiselno. Torej bi rekel, da to vsekakor postane bolj normalno, če veste: "Hej, potrebujemo orodje za spremljanje, nekaj potrebujemo." In ljudje vsekakor vidijo vrednost tega izdelka, saj tako kot ste že povedali, samo dodajte DBA in Če dodate nove primerke, potrebujete nekaj, kar s tem upravlja. Potrebujete nekaj, kar pomaga pri upravljanju tega, zato se tudi pri tem izdelku veliko sprejmemo ali pa ga imamo.

Dez Blanchfield: Hitro vprašanje. Kje je to treba živeti? Ali mora sedeti desno na zadnjem zapisu v omrežju LAN, znotraj podatkovnega centra, čim bližje okolju baz podatkov, ali je udobno nameščen nekje, potencialno zunaj oblaka, zunanjega oblaka z nekakšnim bodisi tunel VPN ali oddaljeni dostop do različnih okolij? Kje mora to sedeti, kar zadeva okolje in spremljanje?

Bullett Manale: Kar zadeva arhitekturo, obstaja rezervno skladišče in to je baza podatkov SQL Server. Imamo konzolo, ki je lahko debela stranka ali tanka stranka; ponujamo vam možnost obeh. Imamo pa tudi tankega odjemalca, ki je namenjen prav tako mobilnim napravam. Toda glede tega, kje to dejansko lahko sedi; lahko sedi v okolju, res zahtevnejši del tega je, od mnogih informacij, ki jih moramo zbrati, so potrebne upravne pravice, ponekod ali v veliko primerih. Zdaj vas ne prisilimo, da to storite; če želite, lahko zbirate podatke in samo za stvari, ki jih ne moremo zbrati, ker nimamo skrbniških pravic, bomo samo pustili, da teh podatkov ne vidite, če je to vaša izbira.

Glede na okus, na primer, če govorite o AWS, nekaterih okoljih, deluje bolje kot druga, toda kar se tiče samega okolja, običajno za preverjanje pristnosti SA za zbiranje podatkov uporabimo samo preverjanje pristnosti. Ali če gre za nepreverjeno domeno, je to običajno takrat, ko to želite storiti, vendar več domen; dokler obstaja zaupanje med njimi, lahko zbiramo proti njim. Ni pomembno, ali je v omrežju LAN ali je na omrežju WAN, sama zbirka podatkov je glede na količino podatkov, ki jo zbiramo, precej zanemarljiva. Če imamo WAN povezavo dovolj velike velikosti, to ni problem. Videla sem, kje imajo podružnice, kjer imajo SQL strežnike po vsem ZDA. Na enem od teh različnih lokacij je en strežnik in ga nadzorujejo centralno. Zapleteni del je samo zagotavljanje, da imate za to dostojno povezanost. Upajmo, da bo odgovorilo na vaše vprašanje, bilo je nekako po vsem zemljevidu.

Dez Blanchfield: Vsekakor. Hvala vam. Torej, dve hitri vprašanji, ki sta se danes zjutraj pojavila skozi udeležence; eno je: kakšen je vpliv - pogosto vidimo, da orodja za nadzor sistema ustvarjajo obremenitve s samo nadziranjem stvari, zato je bilo vprašanje, oprosti, da se je zdaj pomaknil z mojega zaslona, ​​ampak da to parafraziram; s spremljanjem ustvarjamo obremenitve sami? Ali je mogoče meriti vpliv orodja, samo opazovati okolje ali gre za zanemarljiv vpliv?

Bullett Manale: Učinek bo vedno majhen, ker mora poizvedovati primerek SQL Server, da bi potegnil podatke. Vprašanje, kot ste rekli, je: "Ali je to zanemarljivo ali je pomembno?" Če ne kažete na primer, je zanemarljiv. To počnemo že, kot sem rekel, že kar nekaj časa. Imamo več kot 20.000 strank in lahko vam zagotovim, da če to povzroči pomemben vpliv na uspešnost, ne bomo poslovali. S tem rečeno uporabniku omogočamo tudi, da sam odloči, kaj želi, da ga spremlja. Zato mislim, da je to pomembno omeniti, da je vsako okolje nekoliko drugačno.

Primer bi lahko bila s komponento za spremljanje poizvedb ena od stvari, ki jo lahko počnemo, ali lahko določimo prag, za kar menite, da je vaša meja normalnosti. Torej bi lahko temeljila na času izvedbe poizvedbe. Lahko bi temeljil na CPU, I / O, toda kot primer, recimo, da sem čas izvedbe nastavil na nič milisekund. Učinkovito je tisto, za kar pravim orodje, da zberem vsa poizvedbe, ki so se izvajale od zadnjega vlečnega intervala, in to tudi del moje zgodovinske zbirke.

Zdaj, ko bomo to storili, bomo zbirali ne glede na število poizvedb, ki smo jih izvajali v polju od zadnjega volišča. Zdaj je to izbirno in uporabnik ima to možnost. Ali si rečemo: "To bi morali storiti?" Ne. Ampak tudi vam dajemo možnost, da to storite v primeru, da želite vzorec podatkov, ki vam omogoča, da te podatke zbirate. Torej na splošno imate sredstva v orodje, da ga nastavite in prilagodite točno tako, kot želite, glede na to, kar vam je všeč. Vendar ga lahko resnično odprete, če želite, in zberete veliko dodatnih informacij, ki jih morda ne bi morali redno redno zbrati, če je to smiselno.

Dez Blanchfield: Da, absolutno. Vem, da tečemo še malo, toda obstajata dve resnično dobri vprašanji, ki bi ju rad vrgel, preden se zavem. Oba prideta direktno do mene, vendar mislim, da je najbolje, če jim odgovorite. Vprašanje je bilo na splošno: "Kakšen je obseg orodja, kar zadeva znanje o obstoječih sistemih?" Torej lahko to samo priključimo in samodejno zazna platformo, ki je tam, in vemo, kaj je normalno za to platformo, in takoj Nekaj ​​osnovnega znanja o platformah, tako da je vnesel, vem, ne vem, to bi lahko bil Microsoft Dynamics. Kakšen je obseg znanja platforme s tem, kaj je normalno in v nekaterih sedanjih orodjih, ki niso na razpolago, ki se uporabljajo pri poslu?

Bullett Manale: Rekel bi, da na splošno, ko začnemo zbirati podatke na primerku SQL, delamo z najboljšimi praksami za začetek, glede na naše pragove in tam, kjer so nastavljeni. Kljub temu priznavamo tudi, da je s kdorkoli se pogovarjaš glede na najboljše prakse vsako okolje drugačno. Kar bomo sprva storili, bomo le zbrali podatke, in kaj priporočamo ljudem, lahko izdelek preizkusite 14 dni dlje, če boste morali. Toda po približno dveh dneh boste začeli opazovati osnovne podatke. Ko bo imel dovolj vzorčnih informacij, s katerimi bo lahko deloval, vam bo začel ponujati kontekst glede na izhodiščno točko, kje je obseg in vse take stvari. Potem lahko od tam, če želite, samodejno nastavite svoje pragove na podlagi zbranih informacij. Začeti je treba malo začetnega zbiranja in anketiranja, da lahko določite, kaj je normalno, tako da lahko začnete premikati svoje pragove.

Vendar menim, da je vredno omeniti tudi to, da ko spremenite te pragove, lahko to storite po skupinah po skupinah vaših primerkov. Lahko je specifičen za en primerek ali pa ga lahko storite proti vsem vašim primerkom, pa tudi možnost ustvarjanja stvari, kot so predloge, tako da lahko rečete: "To je proizvodni primerek, vendar je to predloga, ki jo želim da ga dodelite. " Ko torej prihaja nov proizvodni primerek na spletu, samodejno uporabimo te pragove, ker ima isto vrsto strojne opreme in ima običajno enake delovne obremenitve, tako da bi to lahko naredili tudi mi. Upajmo, da to pomaga pri vprašanju.

Dez Blanchfield: Vsekakor. Pravzaprav ste odgovorili na drugo vprašanje, ki se mi je pravkar oglasilo, in to je bilo: "Ali obstaja poskusni prenos?" Na to lahko odgovorim, vem. Prepričan sem, da boste potrdili, da obstaja brezplačen prenos, in mislim, da ste rekli, da je bilo 14 dni s spletne strani. Lahko ga prenesete in se z njim igrate. Mislim, da hitro s tem. "Kakšno okolje potrebujem, da lahko zaženem preizkus? Ali ga lahko zaženim na prenosnem računalniku in se igram z njim ali res potrebujem strežnik?"

Bullett Manale: Glavna stvar, ki jo potrebuje, je shramba, baza podatkov SQL Server, ki je leta 2005 ali višje. Poleg tega obstajajo nekatere minimalne zahteve po virih, zahteva .NET in to je to. Torej, samo vprašanje namestitve izdelka in ustvarjanja baze podatkov.

Dez Blanchfield: Popolno. Še zadnje vprašanje, ki vam ga bom vrgel, ker nam zdaj že zmanjkuje časa, a hitro sta me približno dva ali trije vprašali: "Ali moram biti DBA, da lahko dejansko vstanem in tečem z to in se igrate z njo? "

Bullett Manale: Ne. Rekel bi, da boste, če ste DBA, uporabljali orodje drugače. Mislim, da bo verjetno nekoliko večja vrednost, če si sezonski DBA. Ogledali si boste veliko več globine orodja, ki bi ga lahko izkoristili. Toda tudi kot novi DBA ali celo oseba, ki to ni DBA, imamo veliko priporočil in trenutno sem na tej strani. Ta priporočila se bodo pojavljala redno in resnično lepo pri priporočilih je, da vam zagotavljajo razloge, zakaj priporočila pripravljate. Poleg tega pa bodo imele tudi povezave do zunanjih vsebin, ki podrobneje opisujejo razloge, zakaj se ta priporočila tudi oblikujejo. To bo povezava do zunanjih Microsoftovih spletnih mest, blogov in vseh podobnih stvari, to je zunanje.

Da pa odgovorim na vaše vprašanje, je nekako, če veste, če ste starejši DBA, bo tukaj nekaj stvari, verjetno boste to izkoristili, da verjetno ne bi kot začetnik DBA. Toda hkrati je to tudi nekakšno učno orodje, saj boste s pomočjo priporočil začeli sami nabirati nekaj teh stvari.

Dez Blanchfield: Fantastično. Hvala vam. Zelo sem užival v demo delu. Predstavitev je bila odlična. Demo je bil fantastičen. Hitro iz pomnilnika je na vašem spletnem mestu cel center virov, ki ga priporočam, da si ga ogledajo tudi ljudje. Spomnim se, da sem šel skozi tisto sinoč, da sem dobil nekaj podrobnosti. Na voljo imate celo vrsto stvari, od vaših blogov, podatkov in pogovorov do pomnilnika, tudi večino svoje dokumentacije o izdelku imate na spletu, ja?

Bullett Manale: Da, to je pravilno, in obrazec, na katerega mislim, da ga omenjate, je spletno mesto community.idera.com. In potem bi omenil še eno stvar, prej ste vprašali: "Ali bomo prepoznali okolje?" Kar zadeva nove primerke ali dodajanje primerkov, obstaja še eno orodje, ki omogoča odkrivanje primerkov. In vse gre za popis in upravljanje zalog. Pravkar bi vas usmeril v to smer v smislu odkrivanja primerov. Kar pa se tiče uspešnosti in spremljanja, vseh takšnih stvari, o katerih smo govorili, je tu začel igrati Diagnostic Manager.

Dez Blanchfield: Fantastično. Poglejte, odlična pokritost. Resnično uživala v vaši predstavitvi. Oboževal sem demo prikaz v živo in to je vse od mene zjutraj, saj vem, da smo čez čas šli verjetno 10 minut. Eric, vrnil se bom k tebi.

Eric Kavanagh: V redu. Samo demo sem ljubil. Vesel sem, da si naredil demo. Veseli me, da smo to lepo pregledali, ko smo preiskovali vprašanja in vprašanja.

Bullett Manale: Super.

Eric Kavanagh: Ker to ljudem daje predstavo o tem, kaj gledate, in res me nekako preseneti, ko pomislim, da se še vedno učimo, kako govoriti s temi računalniki, ko se spustite takoj. Mislim, ta raven diagnostike je precej izpopolnjena in vsak dan je izpopolnjena. Dobivamo veliko več vpogleda v dogajanje. Ampak resnično potrebujete človeka, ki te stvari spregleda, prebere, da kognitivno sposobnost postavi za tisto, kar počnete, kajne?

Bullett Manale: Da, mislim, v veliko primerih - rad bi vam rekel, da je v tem polju DBA, vendar se dogaja le preveč stvari. Mislim, dajemo smernice in pomagamo, vendar na koncu tega zahteva, da se ljudje odločajo o podatkih, ki jih predstavljamo. Mislim, da se to ne bo kmalu spremenilo.

Eric Kavanagh: No, to je dobra novica za prave ljudi, ljudje.

Bullett Manale: Tako je.

Eric Kavanagh: Želeli boste imeti nekoga, ki to gleda, ekipo, ki to opazuje, in izvedeli boste, kot ste slišali od Bulletta tukaj, in gledali boste ta priporočila, da boste izbrali, kaj se dogaja. In ugibam iz te zgodovine, in mislim, da ste se tega dotaknili, Bullett, toda zelo hitro vam zgodovina omogoča, da prepoznate pomembne vzorce in jih potem lahko prepoznate, ko se zgodijo v prihodnosti, kajne?

Bullett Manale: To je pravilno. Ena izmed stvari, ki jo lahko naredimo, je, da skozi čas spremljamo uspešnost poizvedbe. Očitno lahko pogledamo tudi druge stvari, kot so osnovne črte in vidimo, kako se premikajo, in očitno prejmemo opozorila in take stvari, ko se to zgodi, zato zagotovo imate to sposobnost.

Eric Kavanagh: Zveni dobro, ljudje. Tukaj ne bi bilo dolgo, vendar sem želel priti do teh vprašanj. Najlepša hvala za vaš čas in pozornost. Vse te spletne oddaje arhiviramo. Skočite v spletu na Techopedia.com ali na InsideAnalysis.com, videli boste povezave z obeh strani.

In s tem se poslovimo. Hvala še enkrat, ljudje, naslednji teden, torek, sreda, četrtek, vas bomo dojeli še tri. Torej, se bomo pogovorili naslednji teden, ljudje. Pazite. Adijo.

Partner za vsebino Techopedia

Osebje podjetja Techopedia je povezano z Bloor Group in z njimi je možno vzpostaviti stik z možnostmi na desni. Za informacije o tem, kako sodelujemo s panožnimi partnerji, kliknite tukaj.

• Profil
• Spletna stran