Avtor osebja Techopedia, 26. maja 2016
Odvzem: V zadnji epizodi Hot Technologies gostitelj Eric Kavanagh razpravlja o upravljanju baz podatkov in odkrivanju primerkov z Robin Bloor, Dez Blanchfield in Bullett Manale.
Trenutno niste prijavljeni. Če si želite ogledati video, se prijavite ali prijavite.
Eric Kavanagh: V redu, dame in gospodje. Še enkrat dobrodošli. Ime mi je Eric Kavanagh. Stvari so vroče. Tu se stvari segrejejo. Ne vem, kaj se dogaja. Oh, tako je, čas je za Hot Technologies. Ja, res, moje ime je spet Eric Kavanagh. Najdete me na Twitterju @eric_kavanagh. To je šov, ki je zasnovan tako, da govori o tem, kar je vroče na trgu. Današnji naslov, "Ključi kraljevine: Upravljanje SQL strežnika z dinamičnim odkritjem." Dobre stvari. Resnično je tvoje. Ok, ta slika je bila izpred nekaj let. Ne bom lagal, zdaj sem videti nekoliko starejši, ampak to je v redu.
Torej, govorimo o tem, kako so tehnologije in SQL Server resnično zelo zares zelo vroči. Danes imamo cel kup vsebine, zato jo bom takoj izročil. Stojte, tukaj. Tam so naši govorci. In Robin Bloor gre prvi.
Robin Bloor: Da, res. Predstavitev se bo poglabljala v upravljanje baz podatkov, zato sem samo pomislil, da bom naletel na upravljanje baz podatkov ali, veste, labirint baz, da bi ljudi spravil v duh tega. Včasih sem bil DBA, lahko bi rekli, da sem bil pred 20 leti kot svetovalec za baze podatkov in stvar, ki me dejansko preseneča v bazah podatkov, je, da se ni veliko spremenilo. Veliko stvari se je spremenilo v smislu hitrosti, glede na količino podatkov in podobne stvari, vendar je velik del tega dejansko zelo podoben tistemu, kar se je včasih dogajalo.
Baza podatkov je po mojem mnenju organizirana razširljiva zbirka podatkov, ki jo je mogoče optimizirati za specifične delovne obremenitve in zagotoviti zmogljivosti za upravljanje podatkov. Nastala je predvsem zato, ker če bi želeli upravljati podatke v datotekah, je bilo to zelo težko delo. In ideja, da bi sestavili del programske opreme, ki bi naredila skoraj vse, kar boste potrebovali, se je skoraj takoj sprožila, takoj ko smo imeli v sedemdesetih letih prejšnjega stoletja naključni dostop do IBM-ovih glavnih računalnikov.
Relacijska podatkovna baza je bila izumljena v 70. letih in je za prototipe nastala v 80. letih in se na trgu začela vleči od začetka 90. let naprej. In relacijske baze podatkov še vedno izjemno prevladujejo v priljubljenosti. Če boste brali tisk, boste slišali ogromno stvari o teh - SQL bazah podatkov, v zadnjem času pa je ogromno hrupa glede podatkovnih baz grafov. In te so zanimive, če želite, vendar dejansko še vedno v najnovejših prodajnih številkah, relacijske baze podatkov predstavljajo 95% trga. Microsoft SQL Server, o katerem bomo danes podrobneje razpravljali, je drugi najbolj priljubljen za Oracle.
Kar zadeva relacijske baze podatkov, zaradi česar so motorji nenavadni, lahko delujejo tako pri OLTP kot poizvedovalnih delovnih obremenitvah. Če boste to počeli, jih morate prilagoditi drugače, vendar dejansko lahko delajo obe vrsti delovne obremenitve. Eden od njih so kratke naključne transakcije, drugi pa dolge poizvedbe, ki obsegajo veliko podatkov. Druga možnost je, da sta baza podatkov NoSQL in baza grafov predvsem za analitiko in sta se v zadnjem času povečala. NoSQL je bil prvi in graf se je v zadnjem času začel nekoliko oprijemati. NoSQL se lahko uporablja za transakcijske dejavnosti, grafov pa skoraj nikoli ne uporabljamo za transakcijske dejavnosti. Razlog sem naletel na statistiko, za katero mislim, da je stara vsaj deset let, ki pravi, da ima večina podjetij vsaj tri, pravzaprav je bila ta številka 3, 5, različnih znamk baz podatkov, če pogledate njihov popis programske opreme.
A resničnost je, da se večina podjetij standardizira na določeni bazi podatkov. In večina podjetij je standardizirala bodisi SQL Server kot Oracle kot dve najbolj priljubljeni za, če želite, standardne baze podatkov. Nadomestne rešitve uporabljajo le v izjemnih okoliščinah, ko na primer dobijo programski paket, ki potrebuje drugačno bazo podatkov, ali pa se lotijo nekaterih velikih ciljev za analizo podatkov, ki so se že pojavili.
Če želite, imamo tudi vmešavanje Hadoopa. Hadoop je tako ali drugače postal več kot datotečni sistem, vendar še ne baza podatkov. Vendar ima SQL, ki leži nad vrhom. Toda dokazi kažejo, da v resnici ne izpodrivajo ali kjer koli blizu izpodrivanja relacijskih baz podatkov, ki so si prislužile srca in pamet sveta. In razlog za to so res tiste relacijske baze podatkov, ki so trajale dvajset let, pravzaprav dlje kot dvajset let, da so postale takšne, kot so. In ne gradite samo iskalnega mehanizma ali SQL motorja, ki je resnično uspešen v zelo majhnem času. Enostavno se ne zgodi.
In torej zaključek tega diapozitiva je, da so baze podatkov strateške in se razvijajo, izboljšujejo. In to je gotovo pri Oracle in Microsoft SQL Server. Verjetno se vas le malo spomni tistih dni, ko so se prvič pojavile baze podatkov, jaz pa sem bil takrat fant. Prvotna ideja je bila, da bo obstajala enotna baza podatkov, in to je bila konceptualna ideja, ki absolutno nikoli ni ukoreninila. Poskusil je IBM z AS / 400 dejansko vzpostaviti datotečni sistem, ki temelji na bazi podatkov, vendar tudi ta ni prevladoval. Prepuščeni ste dejstvu, da se baze podatkov razdrobijo. V resnici imate več primerov. Obstajajo težave z razširljivostjo. Podatkovna baza je le na določeni velikosti, resda se je z leti povečevala velikost, vendar so imeli omejitve.
Obstajale so težave z delovno obremenitvijo, največja težava z delom pa je, da obremenitve OLTP in velike poizvedbene obremenitve preprosto niso združljive med seboj. In ni bilo mogoče zgraditi motorja, ki bi to naredil. Kar naletimo na, kar je nekako zanimivo, sem pred kratkim naletel na spletno mesto, ki je imelo več kot tisoč različnih primerkov Oracle. Ne morem se natančno spomniti, koliko DBA so imeli, toda če ste se z njimi dejansko pogovarjali o tem, koliko teh baz podatkov nadzoruje DBA, jih je bilo približno deset. Bazo so v bistvu uporabljali kot omarico in samo metali podatke vanjo, ker ste imeli vsaj shemo in je bil bolj organiziran, kot bi bil kdajkoli že datotečni sistem, vendar nihče ni naredil nič drugega, kot da mu je dal privzeto nastavitev in nastavitev ohlapna.
Nisem prepričan, ali je bila to dobra ideja. Zdi se mi bizarno, če sem iskren, ker sem po mojem mnenju vedno, ko sem delal z bazami podatkov, potreboval udeležbo podatkovnih baz in bi moral tako ali drugače vedeti, kaj se tam dogaja. In ogromno sistemskih soodvisnosti pomeni, da je treba določene vrste storitev absolutno izpolniti, sicer imate težave.
Nedavno je bilo govora, naletel sem na različne zbirke podatkov, ki trdijo, da so samoiniciativne. Tisti, ki so stolpci, ki so nastavljeni za poizvedovalni promet, so večinoma samonastavljeni, ker obstajata dve možnosti, ki ju morate sprejeti glede indeksov. Toda poleg tega področja je treba baze podatkov prilagoditi. In jih je treba prilagoditi, določene relacijske baze podatkov, predvsem zato, ker je ogromno transakcij vključenih v združitve. Pridružitve so drage dejavnosti. Če pravega indeksa ne postavite na pravo mesto, potem se pridruži vzeti nedoločen čas, ko jim ni treba.
Trenutno samostojne baze podatkov obstajajo le na teh področjih, kjer so delovne obremenitve dobro znane. In moja izkušnja je, da večina podjetij zaposluje zelo malo DBA in to zato, ker so draga. Zato je bolje, če lahko izmenjate, kar počne DBA. To so dejavnosti DBA, kot jih razumem. Izvajajo namestitev, konfiguracijo in nadgradnjo baz podatkov. Nadgradnja mimogrede ni nujno nepomembna dejavnost. Razlog, da bi nadgradili bazo podatkov, mislim, da je pravilo, s katerim sem vedno delal, ne dotikajte se, če deluje, in če boste bazo podatkov nadgradili na kakšno novo različico, to storite v testnem načinu najprej in po tem nadgradiš vse. Še vedno se ukvarjate z isto različico. Ampak v resnici na veliko spletnih mest, na katere sem naletel, se to ne dogaja. Obstaja, recimo, poštena stopnja entropije. Upravljanje licenc je težava, odvisno od licence, ki jo imate. ETL in podvajanje podatkov.
Eden od trikov z bazo podatkov je, če imate poizvedbo delovno obremenitev, ki jo je treba razdeliti, lahko ustvarite dva primerka in kopirate, kar se pogosto zgodi, kadar ljudje uporabljajo repliko kot vroče varnostno kopijo, če je treba. Nato je načrtovanje skladiščenja in zmogljivosti del dejavnosti DBA, ker podatki seveda rastejo in to morate spremljati. In potem morate načrtovati različne nadgradnje strojne opreme ali izboljšave strojne opreme. Obstaja odpravljanje težav, ki je bolečina za večino DBA. Kadar gre kaj narobe in varnostno kopiranje ne deluje popolnoma brezhibno, potem morajo zavihati rokave in se spraviti ter poskusiti in obnoviti stvari iz dnevniških datotek. To se dogaja veliko pogosteje, kot si mislim, no, spomnim se, da se je to dogajalo, vendar sem bil iz igre že vsaj deset let, vendar se tega spominjam bolj pogosto, kot bi kdajkoli pričakovali. Spremljanje in uglaševanje uspešnosti je le srce za delo DBA. Obstaja pa tudi varnost v zvezi z upravljanjem dostopa, varnostno kopijo in obnovitvijo, kar ustvarja preizkusne sisteme programske opreme, ki bodo razumljivo vzporedni s sistemom v živo. In celoten podatek o življenjskem ciklu podatkov. Tako da je po mojem mnenju seznam delovnih mest DBA poleg vseh drugih, ki bi jih lahko prosili. Operativna dinamika. Končno je celovitost podatkov in upravljanje ravni storitve glavna odgovornost DBA. In običajno so kritični. In to je vse, kar moram povedati. Grem izročiti Dezu.
Dez Blanchfield: Najlepša hvala. Odpeljal se bom na malo zabavno, anekdotično potovanje, zakaj celotna tema, o kateri se danes govori, in je bolj kritična kot kdaj koli prej. Ne tako dolgo nazaj sem bil vključen v projekt, ko smo preselili državno platformo vlade, ki se uporablja za registracijo licenc in registracijo vozil, in celo vrsto stvari okoli te teme, s platforme Fujitsu mainframe, ki poganja stvar z imenom A + Addition, ki je operacijski sistem Solaris ali z drugimi besedami Unix, ki zažene Oracle in zelo dobro opravlja njegovo delo. In pogled je bil, da se ta stvar stara in je bil čas, da jo prestavimo na nekaj drugega. Zelo zabavno smo vodili Unix na mainframe in bil je zelo stabilen ter zelo varen in dovolj nenavadno platforma SDL in je bil povsem brez strele. Toda modrost je bila, da je čas, da se umaknem iz mainframeja in se premaknem.
Ta pomemben izziv preslikave vseh sistemov in poslovne logike ter okolja SQL za baze podatkov pod seboj in pogled na to, kako bomo arhitektu in inženirju postavili nov dom zanj. In končali smo ga pri eni izmed teh stvari, ki je stara že nekaj let, vendar je eden od najboljših strežnikov strežnika sistema Sun Fick Starfire. In to so verjetno nekateri največji kositer, ki jih lahko kupite na planetu, ki živijo v eni veliki škatli in simetričnem večprocesorskem strežniku. To je bil sistem srednjega obsega v našem svetu. Vodil je Unix in domače vodil Oracle in pogled je bil: "Kaj bi lahko šlo narobe?" No, izkazalo se je, veliko.
Takrat, na primer, o čemer že dolgo ne govorimo, smo morali skozi zelo ročni postopek, da smo odkrili, kaj je na platformi mainframe-a, in dosegli vse. Zlasti dejansko okolje baze podatkov in logika SQL. Torej je bil pogled dokaj enostaven premik Oracle-to-Oracle, premik od baze podatkov do baze podatkov; vsa poslovna logika bi naletela, večina poslovne logike je bila napisana v vdelanih poizvedbah in sprožilcih, in kako težko bi bilo to? Toda nekaj, kar naj bi trajalo mesece, je trajalo ne le eno leto. Če želite fizično in ročno iti skozi vsak del Unixa v okolju mainframe, odkriti, kje so bile vse baze podatkov in koliko instanc se je izvajalo in kaj se je izvajalo na teh instancah, kar je bila nevijalna vaja in na koncu smo to počeli trikrat samo zato, da se prepričamo, da smo vse ujeli. Ker smo se vsakič, ko smo mislili, da smo izkopali tako globoko, kot je bilo potrebno, pod površjem pokazalo, da je tam več.
Drugi izziv smo imeli, kateri primeri se izvajajo in v kakšnem stanju? Je to razvojno okolje? Ali gre za testno okolje? Ali je to del integracijskega procesa? Ali gre za sistemsko integracijo? Ali je to UAT, preverjanje sprejemljivosti uporabnika? Je to proizvodnja? Ali gre za okolje DR? Ker je glavna stvar mainframes-a ta, da lahko zgradite ta mala virtualna okolja, ki jih zdaj vsi jemljemo za samoumevne, in stvari premikate. In morate opraviti, ali ta oseba razvija proizvodne razrede in preizkušanje ali ali se ukvarja s proizvodnjo, ali so dejanski uporabniki tega? Če se spomnimo, da ta stvar izdaja v realnem času vozniške dovoljenja in registracije avtomobilov ter stvari, ki so res pomembne za življenje ljudi.
In trajalo je dolgo časa, da so se varnostne kopije za to stvar začele, da v resnici nismo imeli okna za vzdrževanje, da bi stvar odstranili in videli, kaj se je zgodilo. Ni bilo takega, da bi ga preusmerili. Prav tako smo imeli izziv, da ne samo ugotoviti, kateri instanci se izvajajo in kje in za koga, ampak smo potem morali ugotoviti, katere različice se izvajajo. In tu sem skoraj izgubil svojo ploskvo. Ko sem začel zavedati, da imamo dve ali tri različice proizvodnega okolja, ki tečejo skozi različne ravni testiranja in je bilo orodja in sistematičnih pristopov k temu zelo malo. Dobesedno smo morali prodreti v kodo in v tekoči primerek in v nekaterih primerih tvegamo, da nekaj časa vzamemo nekaj brez povezave. Vse to smo prišli do dna, preslikali smo ga in kot sem že rekel, bil je zelo ročen postopek. In končno smo naredili celotno izmenjavo ETL-ja, jo odvrgli z enega mesta in jo premestili na drugo in na splošno je delovala. In bili smo takšni, v redu je funkcionalna, z njo smo zelo zadovoljni.
Toda potem smo naleteli na številne zelo resne trdne opečne zidove. Zlasti smo našli težave z uspešnostjo. In smiselno razmišljanje dneva je bilo: no, prešli smo na večjo, boljšo, hitrejšo in tršo strojno opremo, ni razloga, da bi slabo deloval pri aplikaciji na ravni baze, zato začnimo iskati drugje. Tako smo omrežje popolnoma prenovili dvakrat. Vsak usmerjevalnik, vsako stikalo, vsak kabel, v nekaterih primerih smo šli od Etherneta do vlaken, nadgradili smo programsko opremo, se popravili, dobili boste pogled. Mrežo smo v bistvu na novo zgradili dvakrat, misleč, da gre za težave glede zmogljivosti. In videti je bilo, kot da je bilo. Šli smo skozi različne varnostne sisteme, različne požarne zidove. Zakrpali smo operacijski sistem. Stvari smo premikali z enega računalniškega rezila na drugega. In porabili smo veliko časa, da smo si ogledali del infrastrukture.
In potem smo ugotovili, da je omrežje, ko smo odklopili strežnike in na njem zagnali nekatere druge aplikacije, delovalo čisto v redu. Tako smo začeli operativni sistem narazen. Ista težava. Zanimivo pa je, da sta bila omrežna raven in operacijski sistem, orodja tam na voljo, pravzaprav je bilo razmeroma enostavno, če smo primerjali in preizkusili ter dokazali, da je vsak od teh kosov deloval. Toda tudi takrat na Solarisu v srednjem obsegu na strojni platformi SPARC orodja preprosto ni bilo, da bi začeli diagnosticirati okolje baze podatkov. Veste, preslikava, ali smo vse primere spravili čez. In tako smo morali dejansko sestaviti lastna orodja in jih nekaj napisati ter sesti in ne glede na to, ali je to znotraj orodij baze podatkov v domačih skriptnih jezikih ali pa je šlo za niz skriptov lupine ali v nekaterih primerih kopico programov C.
Končno smo se poglobili v nekaj zelo zanimivih vprašanj, kjer se je logika pod slojem SQL, dejanskih samih motorjev baz podatkov, izkazalo, da se je, ko je bilo nekaj zgrajeno na poseben način za nekaj, kar je poganjalo v glavni različici Oracle, preselilo v Solaris na SPARC različica Oracle ni takoj prenesla iste zmogljivosti. Torej je bilo to za nas precej boleče potovanje, saj smo to šele naredili in našli vse, zdaj pa smo ga morali diagnosticirati na novem proizvodnem sistemu in spet je ta stvar odpravila mesečno selitev v skoraj eno leto. Preprosto je prišlo do dejstva, da orodja nismo imeli naokoli. Tekač okoli in delati stvari, kot je poskus preslikave metapodatkov.
V nekem trenutku smo se skoraj odločili, da potrebujemo tablo Ouija, ker bo tako lažje samo naključno kazati in pokimati. Preproste stvari, kot je ugotovitev, kdo je imel dostop do starih sistemov in zakaj so imeli tak dostop. In kdo je potreboval dostop do novega in potrditev, pridobivanje nekoga, da se odjavi in potrdi, in to preslika. Celo nekaj tako preprostega, kot je velikost baze, na obeh platformah ni bil skladen. Za to smo morali sestaviti orodje in narediti nekaj primerjave med to, kako velika je baza podatkov v tonaži, v surovih megabajtih ali terabajtih v sistemu A v primerjavi s sistemom B. In se podrobneje poglejte glede zmogljivosti in uspešnega okolja. Spet je bilo treba zgraditi nova orodja. Za nami ni bilo nobene preproste police.
In vse to sporočilo dobite iz tega, ko smo prišli do konca, da se stvar zažene in smo jo dobili stabilno, vsak njen kos je bil zelo ročen postopek, edini način, da smo lahko nekaj avtomatizirali, je bil, če zgradimo novo orodje ali nov skript. In če bi imeli orodja, ki so danes na voljo, bi bilo življenje toliko lažje in toliko boljše. In pri tem projektu bi prihranili milijone. Mislim pa, da je to, o čemer bomo danes govorili, dejstvo, da so orodja zdaj na voljo in da življenje tako olajšajo. Številne pasti še vedno ostajajo. Odkrivanje baz podatkov, ki so tam zunaj in v katerih primerih se izvajajo. V kakšnem stanju so. Koliko jih vodi? Zakaj tečejo. Ali dobro tečejo. Ali jih podpirajo?
To so vse stvari, ki jih s pravimi orodji zdaj lahko na več načinov jemljemo kot samoumevne. Toda v tej posebni anekdoti, kot sem že rekel, je bilo neko obdobje, kjer je bilo to veliko, zaradi česar smo mnogi izgubili veliko las, verjetno smo si vzeli petnajst let življenja in žalili, da orodij zdaj ni bilo. . Z veseljem pričakujem veliko več od našega današnjega gosta, Bulletta. Torej s tem, Bullett, bom šel k vam in veselim se, ko bom zaslišal, kako ste rešili to težavo.
Bullett Manale: V redu. Sliši se super. Eric, da te prevzamem s diapozitivi in se malo pogovarjamo o tem, resnično hitro, o Idera, družbi, preden se lotimo samega izdelka. Tako kot FYI je to vrsta portfelja različnih izdelkov, ki jih imamo na voljo.
Eric Kavanagh: Zvok je nekako vroč, zato če uporabljate slušalke, ga le malo povlecite.
Bullett Manale: Ni problema. Je to bolje?
Eric Kavanagh: To je veliko bolje. Vzemi stran.
Bullett Manale: V redu. Danes se bomo osredotočili na upravitelja zalog, ki je očitno usklajen z veliko temami, o katerih razpravljamo. Želim vam samo malo razumeti, kako je ta izdelek prišel tam, kjer je. Vsakodnevno smo začeli gledati z našo linijo izdelkov, imamo orodje za spremljanje učinkovitosti, imenovano Diagnostic Manager. Imamo orodje za skladnost skladnosti. Torej, veliko različnih orodij okrog SQL Serverja in neizogibno vedno postavljamo vprašanje za licenčne namene: "Kolikšno je število primerkov, s katerimi trenutno upravljate v svoji organizaciji?" In zanimivo je, da na to nikoli nismo mogli resnično dobiti zanesljivega odgovora. V resnici ni bilo pomembno, s kom ste govorili. Vedno je bilo nekako: "No, mislimo, da je približno to število." Vedno so prihajale take stvari in potem bi morali skozi ta postopek ugotoviti, kaj točno je tisto, kar so imeli, da bi želeli licencirati v primerih, ki jih upravljamo.
Očitno smo hitro ugotovili, da se zdi, da je z veliko DBAs nekaj bolečin, povezanih s tem. Očitno je, da je DBA ena od stvari, za katero so odgovorni, to, ker mora ena od stvari skrbeti za njihove licenčne pogodbe, v našem primeru z Microsoft in SQL Server. Očitno imajo veliko drugih različnih področij, za katera so odgovorni, vendar je to eno tistih, ki je nekakšna velika postavka vozovnic, kar pomeni, da so DBA, kakšne so vaše splošne odgovornosti. S tem smo nekako prišli do zaključka, da potrebujemo orodje, ki DBA olajša njegovo resnično razumevanje. Ker imate SQL širjenje, če ga želite poklicati, in to se zgodi iz več različnih razlogov. Mogoče ni toliko nadzora nad tem, kdo namešča programsko opremo in take stvari.
In najslabše, kar se lahko zgodi, je, da nekdo dobi kopijo SQL Serverja, ga namesti, z njim brez kakršnega koli znanja začne delati pri nekaterih drugih organizacijah ali oddelkih v podjetju, nato pa je morda naslednja stvar, ki jo poznate, morda podatkov ni mogoče varnostno kopirati, in takšnih stvari, ki bi se lahko zgodile. Kjer imate zdaj drugo težavo, kjer imate situacije, ko boste dejansko izgubili kritične podatke, ker ne veste, da primerek sploh obstaja.
Ena izmed stvari, ki smo jo morali narediti, je recimo, da ugotovimo, kakšen odkrit del je. In potem lahko poleg tega organiziramo in upravljamo tiste informacije, ki jih zbiramo na logičen način, ki je smiseln glede na to, kaj počne podjetje. In potem bo očitno iz tega mogoče sprejemati odločitve v zvezi s temi informacijami in biti sposoben početi takšne stvari. Od tod se je orodje začelo in od kod prihajalo. Lahko vam povem, da pri rednem pogovoru z DBA-ji resnično obstaja težava, da ne vemo, koliko primerov imajo.
In smešno je, ker izraz, ki ga ne morete upravljati, česar ne morete izmeriti, vedno predstavlja orodja za uspešnost, ki jih imamo, kot je SQL Diagnostic Manager, vendar resnično ne morete ničesar upravljati, če tega ne veste "Svoje" sploh tam. To je tudi velik del tega orodja, ki je sposoben samo vedeti, da je tam.
Zdaj ob tej opombi, ko smo se pogovarjali z nekaterimi večjimi organizacijami ali podjetniškimi trgovinami s SQL strežnikom, je zanimiva stvar, ki smo jo našli pri številnih fantih, s katerimi smo se pogovarjali, ta, da so dejansko v svojem letu postavili čas, v resnici so fizično hodili od enega kraja do drugega, da bi poskusili ugotoviti, kako je videti to število. Lahko si predstavljate, da boste kot DBA prejeli dober denar za fizično hojo od enega stroja do drugega, kar je bilo presenetljivo, kar bomo slišali od nekaterih precej velikih podjetij, ki jih ne bom imenoval. Zanimiva stvar pa je, da bi dva tedna v letu lahko porabili za tovrstne vaje, da bi ugotovili, ali je število njihovih licenc pravilno.
Vse to je povezano s tem orodjem in kako pomaga, toda način, na katerega smo se lotili, je bil zmožnost odkrivanja, ki temelji na številnih značilnostih SQL Serverja. In tako je prvo vprašanje, na kaj kažete ali na kaj poskušate najprej pogledati? Način, kako smo to storili, je bil, da to storimo po območju IP ali pa lahko s članstvom v sami domeni v smislu računalnikov, ki so člani domene. Tako smo se lotili tega dela, samo da bi lahko rekli, da je to področje, na katerega se želimo osredotočiti v smislu odkritja.
In potem drugi del tega temelji na teh značilnostih, pristaniščih in drugih stvareh, registrskih ključih WMI in takšnih stvareh, lahko zberemo in ugotovimo, da se SQL verjetno izvaja in namešča v tem primerku ali v določenem okolju. Očitno je veliko boljša metoda kot metoda sneaker ali sneaker express. Kul stvar je, da so vse te informacije, ki jih zbiramo o primerku, shranjene v skladišču in se lahko spreminjajo, ko se spreminja okolje. Ne gre samo za to, "Hej, obstaja primer, tukaj je seznam, ki smo ga našli", ampak DBA ali oseba, ki upravlja z instancami, lahko ugotovi, ali želijo narediti ta del zaloga, in kdaj ni del popisa, da bi lahko ta primerek razpadla. In tako imajo življenjski cikel celotnega postopka primerka SQL Server, da ga je v orodju res enostavno razumeti.
Ko odkrijemo primere, kaj storimo po tem? Druga stvar je veliko informacij o primerku, ne želim, da jih ročno pridobim in dam v preglednico ali take stvari. In še nekaj, kar je bilo zanimivo v pogovoru z DBA o postopku popisovanja in izdajanju dovoljenj, je, da bi bili presenečeni nad tem, koliko DBA-jev sem govoril, ko jih vprašate: "Kako vzdržujete zaloge?" In govorimo z DBA, ki je res ironičen del tega, da to hranijo in spremljajo v statični preglednici vseh stvari. Kot sem že rekel, je zelo ironično, ko o tem razmišljaš minuto. Vendar je bilo to v veliko primerih in še vedno je pri mnogih organizacijah, kako jim to uspe. Kako to držijo. To je glavna kopija preglednice Excela, ki se plava okrog in jo je treba redno posodabljati.
To je tisto, kar je bil izziv, zato lahko z registracijo tega primerka in vključitvijo v seznam zalog to storite in poberete informacije. Lahko ga avtomatizirate, ne glede na to, ali postane del inventarja, različice, izdaje in drugih stvari, ki jih lahko naredite z njim, lahko ročno dodate morda ta seznam ali Excelovo preglednico, ki jo imate. To lahko uvozite v to orodje, imenovano SQL Inventory Manager. Če že imate izhodišče primerkov, za katere menite, da ste precej samozavestni, jih lahko uvozite v in nato v izdelek ustvarite ta del svojega upravljanega inventarja. Ko imamo primerek in ko vemo, da je to potem, potem postane, v redu, imamo veliko informacij, ki jih lahko izkoristimo, če vemo, da je ta primer tam, tako da gremo ven in zberemo te podatke.
In veliko informacij bo potrebnih za več kot zgolj licenčne namene. Veliko tega lahko uporabimo za to, da očitno vemo, kje so stvari, da lahko po teh informacijah iščemo po teh informacijah. Ključna stvar pa je strežnik, sama strojna oprema. Ker lahko razumemo, za kakšen stroj gre, morda model ali izdelovalec, pomnilnik, količino pomnilnika, ne glede na to, ali gre za fizični ali virtualni stroj in še posebej število fizičnih vtičnic ali jeder in procesorjev ter te vrste stvari.
Glede na število jeder, zlasti pri SQL Serverju, je poznavanje načina, kako izvajajo licenciranje, izračunano po jedru zdaj v novejših različicah SQL, kar postane res pomemben del tega in ni ničesar, kar imate iti ven in se dejansko odkopati. Ko je primerek identificiran, lahko to informacijo posredujemo in jo dobimo ter vam omogočimo, da si jo ogledate in jo razumete in jo očitno lahko izkoristite.
Naslednji sloj navzdol je na primer, ki ima očitno veliko različice primerka SQL Server, bodisi standardni ali podjetniški ali celo izrazni za to zadevo, ali brezplačna različica SQL Server. Ker lahko razumete tudi, katere aplikacije so povezane s tem primerom, in to lahko storite samodejno. Znati razumeti konfiguracijske nastavitve in take stvari ter druge informacije, ki so povezane z primerom samega SQL strežnika.
Nato se spustite do dejanske baze podatkov in si ogledate nastavitve konfiguracije, količino prostora, vezanega na te podatke, kjer se nahaja, vse te stvari se samodejno naselijo, tako da je velik prihranek časa. In še enkrat, ker se dinamično dogaja in vsakodnevno prepoznava nove primerke, je živa stvar, ki jo imate glede na zalog. To je nekakšen cilj izdelka, da bi bil na ta način, je to, da postane nekaj, kar se dinamično spreminja.
Ko so nam vse te informacije na voljo in bomo lahko vse te podatke potegnili vanj, je res smiselno, da začnete v nekaterih primerih ustvariti svoje metapodatke, povezane s temi primeri, in da lahko metapodatke ustvarite na takšen način se prilagaja načinu poslovanja.
Če imate svoje primerke razvrščene po zemljepisni lokaciji ali lastnikih aplikacij ali lastnikih DBA ali karkoli drugega, bi bilo to mogoče glede na to, kako želite združiti te primerke, kako logično želite, da se ti primeri smislijo, potem obstaja vrsta dveh področij v orodju, ki vam bosta dala to sposobnost.
Prva je možnost ustvarjanja oznake primerka ali oznake. Kar v bistvu ustvarja povezavo bodisi s strežnikom, primerkom ali bazo podatkov, tako da lahko ustvarite poglede in odgovarjate na vsakodnevna vprašanja, ki vam resnično pomagajo, da se rešite, kaj imate, kaj upravljate in kako želite napredovati s temi informacijami.
Druga stvar, ki jo imamo, je nekaj, kar imenujemo polja zalog ali polja po meri, in ta so bolj specifična za vrste drobcev informacij, ki jih lahko vrtate v, na primer plast baze podatkov, v katero se bom morda odločil dodati spustni seznam, ki ima vsi DBA-ji in lahko postavim, kdo je odgovoren za to bazo podatkov, odvisno od vrste situacije ali kar koli, ne glede na to, katera baza podatkov je, kdor je odgovoren, lahko to izbere, tako da vem, da so odgovorni ti in zelo enostavno samo s kopanjem v inventar.
Tako ti podatki postanejo zelo dragoceni, še posebej, če imate veliko okolje, saj vam le pomaga, da te informacije razumete in veste, kaj imate in kako to počnete.
Torej, naj grem naprej in prestopim na naslednji diapozitiv tukaj. Zdaj vam pokažem, da vse te informacije, ki jih zbiramo, vse te informacije in podatki, ki jih zbiramo in uporabljamo metapodatke, da bi dobili možnost lažje in hitrejše odločitve, ko gre za povežite licence pri Microsoftu pri obsežnem licenciranju podjetja ali zavarovanju programske opreme pri Microsoftu.
To vam resnično olajša, ne pa da morate to storiti in opraviti veliko ročnega zbiranja podatkov, veliko ročnega zbiranja teh informacij, ki pravzaprav na splošno zelo izboljša postopek. To je nekakšen mandat izdelka, kdaj pa tudi DBA lažje sprejmejo te odločitve v zvezi z licenciranjem.
Zdaj je druga stvar, ki smo jo, kot da bi se pogovarjali z DBA, zelo hitro odkrili in izvedeli, da je - in to se nekako vrne na tisto, o čemer smo govorili prej - v vašem okolju SQL Serverja je morda 300 primerov, toda res je morda le podmnožica tistih, ki jih resnično v celoti spremljamo in upravljamo s tradicionalnim orodjem za spremljanje učinkovitosti.
Če torej greste in dejansko sedite z DBA in rečete: "Poglejte, vemo, da imate teh 20 primerkov ali 10 primerov od 300, ki jih spremljate s tem orodjem, ki je zasnovan za spremljanje tega in skladno z vašim SOA in dobite opozorila in vse takšne dobre stvari, "kaj smo ugotovili tudi, če ste vprašali:" Torej, kaj pa s temi drugimi 280 primeri, ki jih imate? Te skrbijo? "In to jim je vseeno, vendar preprosto ne želijo nujno vlagati, da bi spremljali tiste na ravni globine, ki jih je mogoče narediti s temi primeri v primerjavi s temi 10 ali 20, res kritične primere izdelkov.
Drugi del enačbe s tem orodjem je tudi ta, da pomaga tudi pri zagotavljanju, da ste na osnovni ravni pokrite glede na primer zdravja. Zdaj vam ne bo povedal, ali imate zastoj ali kdo je žrtev mrtvega kota. Ne pridete do te stopnje samih sej in podrobnosti poizvedb. Hkrati pa boste še vedno obveščali, da, če se strežnik zmanjša ali hej, da se glasnost polni ali morate narediti varnostne kopije baze podatkov, je to pomemben del DBA.
Torej so takšne stvari vsekakor še kako pomembne, zato je s takšnim orodjem omogočeno, da imate ulov za svoje resnično kritične primere, ki so veliko, veliko vredni, če so nanje navzdol morate vedeti takoj. Lahko imajo višjo raven spremljanja in lahko počnejo takšne stvari, medtem ko bodo s tem lahko pobrali vse nove primere, ki so dodani v okolje, in poskrbeli, da se bodo upoštevali in tudi naredili prepričajte se, da se te osnovne zdravstvene ocene oblikujejo.
Torej, na kratko, za kaj gre pri upravitelju uvoza SQL Inventory. Zdaj vam bom pokazal demonstracijo. Preden to storimo, vam na hitro pokažem, da je to arhitekturni diapozitiv in da bi to nekako prikazali, primeri SQL, ki jih upravljamo, lahko odkrijemo vse, od SQL 2000 vse do novega različice SQL.
Torej lahko to storimo, ne da bi nam bilo treba kdaj posredovati zastopnike samim primerkom. To storimo prek storitve zbiranja, ki bo šla ven in zbrala te podatke ter jih shranila v skladišče, nato pa bomo lahko s pomočjo končne konzole spletne storitve Tomcat vzajemno komunicirali s temi podatki in si jih ogledali. Torej je precej preprosta arhitektura.
Grem naprej in preklopim in nas dejansko prevzamejo v samem izdelku, da boste lahko dobili občutek za to, razumevanje, kako deluje. Zato je najboljši način za to, da vas najprej predstavimo samemu vmesniku. To je nekakšna nadzorna plošča, ki si jo ogledamo tukaj.
Trenutno vidim, da število primerov, ki jih imam v upravljanju, ni prav veliko. Vendar tudi v zadnjem žepu nimam celega podatkovnega centra. Torej imam približno šest primerov, ki jih vidimo tukaj. Zdaj, ko je rečeno, sem, kar bom storil, je, da se sprehodim skozi postopek odkrivanja in pokažem, kako bi to delovalo.
Zdaj je prva stvar, ki jo boste storili, v razdelku s skrbništvom, ki ga lahko določite, kako želite odkriti svoje primere. Te podatke bi lahko dali tukaj in še enkrat, kar je mogoče storiti s številnimi naslovi IP. Lahko kažete na domeno ali poddomeno in lahko samo na tistih računalnikih, ki so člani te domene, izvajajo ta preverjanja, za katere bi lahko izbrali številne različne značilnosti, ko se bo izvajal SQL, da preverite.
Potem, ko ste to storili in boste lahko avtomatizirali, da se vsakodnevno izvaja in zbira te podatke. Po potrebi boste to lahko storili tudi ad hoc. Ko pa to začnete, je postopek odkritja, ki ga boste začeli videti, ko boste prešli na pogled primerov tukaj. Imate zavihek Odkrivanje in zavihek Odkrivanje nam bo pokazal tiste primere, ki so bili nedavno odkriti. Torej imamo v našem primeru številko tukaj. Kar bom šel naprej in naredim, je to, da nadaljujem in dodam tistega, ki ga bomo uporabili kot primer. Torej gre za primer v Chicagu v tem primeru, kajne? Bom šel naprej in dodal ta primer v svoj inventar.
V redu in tukaj me bo šlo skozi nekaj stvari. Grem naprej in videli boste, da lahko nastavimo poverilnice. Moji mandati bi morali biti dobri tam. Bom šel naprej in opazili boste, da lahko dodelim lastništvo tega, če hočem. Določim lahko tudi lokacijo. Zdaj je mogoče dodati tudi lokacijo in to si bo zapomnil naslednjič naokoli.
Še enkrat lahko temu pridružim oznake v smislu metapodatkov in tega, kako bi želeli te primere SQL, še posebej ta, vstaviti v katera vedra, v katerega ga želimo vstaviti. Torej imamo nekaj trenutnih oznak, priljubljenih oznak, zato si lahko ogledamo kup različnih oznak, ki sem jih morda že vključil. Samo naključno bom izbral nekaj teh in to lahko uporabimo.
Torej zdaj, ko grem naprej in to dodam v inventar. Zdaj, ko je bil dodan, ga bomo zdaj videli pod tem upravljanim pogledom in si ga lahko ogledate tukaj. Torej veste, da je to prvi korak in tisto, kar sem vam ravnokar pokazal, je način, na katerega boste dodajali te primere, ko se vsakodnevno podajate. V nekaterih primerih lahko rečete, da veste, kaj, če gre za podjetniško izdajo strežnika SQL, to samodejno želim dodati v svoj seznam? Ni mi treba ročno iti in se odločiti za to.
Jocelyn: Na hitro vas bom prekinil. Ne vidimo vašega demo posnetka.
Bullett Manale: Nisi?
Jocelyn: Ne.
Bullett Manale: Pa to ni dobro, poglejmo.
Eric Kavanagh: Če se odpravite v zgornji levi kot, kliknite Start, kliknite na to.
Bullett Manale: Ah, v redu.
Eric Kavanagh: Zdaj pa skupni zaslon.
Bullett Manale: Oprosti zaradi tega. Ja.
Eric Kavanagh: V redu je. Dober ulov, producent Jocelyn.
Bullett Manale: V redu, je tako bolje? Se zdaj vidite?
Robin Bloor: Da, res.
Bullett Manale: V redu, zato naj vas kar hitro popeljemo tam, kjer smo bili hitro resnični. Odkrili smo primere, ki smo jih imeli že prej. Pravkar sem dodal primer vrste Chicago in tako, kar vidite zdaj, je to zdaj navedeno tukaj. Upoštevajte, da je že potegnilo veliko dodatnih informacij. Če kliknem sam primerek, boste začeli videti vse vrste informacij, ki smo jih že zbrali o tem primerku. Zdaj je seznam vseh baz podatkov, ki so tam. Vidimo lahko razčlenitev baz podatkov po velikosti in po dejavnosti, glede na to, katere imajo največ velikosti in dejavnosti.
Še enkrat vam lahko takoj sporočimo, katere aplikacije vidimo, da se izvajajo na tem primerku, na podlagi delovne obremenitve, ki jo opazimo na primerku. Lepo je, če to lahko storimo samodejno. Ni mi treba vstopati in vezati vloge na pojav. Glede na to, kar vidimo, lahko to napolnimo. Če želite ročno dodati aplikacijo, to zagotovo lahko storite. Je pa le lep način, da lahko prikažemo povezavo primerka z bazo ali, žal mi je, aplikacijo.
Opazili boste tudi, da imamo na desni strani zaslona trenutni povzetek, spodaj pa povzetek strežnika. Torej, tukaj govorimo o ključnih informacijah o primeru, saj poznamo različico in ne le, veste, SQL Server 2012, ampak dejansko številko različice, ki vključuje, in nam pove, katere popravke so povezane z njo, kakšne servisne pakete so vezani na to, lahko je zelo pomembno vedeti. Očitno je zahteva po pomnilniku pomembna. Vse takšno, ne glede na to, ali je združeno, vse te podatke, mi jih ni treba navajati - že se zbirajo in zbirajo, in ko bomo ugotovili, da gre za odkrit primerek, bo to del našega popisa.
Druga stvar, ki jo boste videli tukaj - in prikazala vam bo - je pod tem primerom. Imamo te atribute, o katerih sem govoril prej, atribute po meri, ki jih je mogoče dodati. Tako lahko dodamo odprte vrste polj z besedilom, lahko naredimo da / ne v smislu, veste, milijarde vrst izbire. Lahko naredimo celo spustne sezname. To lahko storite na primer baze podatkov ali na ravni strežnika.
Če se še malo pomaknemo navzdol, lahko vidimo vse povezane podatke na samem strežniku. Torej veste, da so vse tovrstne stvari očitno resnično zelo koristne, saj so vse zbrane in zbrane, in to je tam za nas, ko se odločimo, da bo to del našega inventarja. Tu lahko pokažemo nekatere razlike glede na CPU, število logičnega in fizičnega, koliko pomnilnika. Tako resnično dobivate res dobre in bogate informacije, ne da bi morali veliko delati.
Zdaj pa drugi del tega, kot sem že rekel, zbiramo te podatke na primer na ravni strežnika. Če se celo spustimo v bazo podatkov, lahko vidimo, da je veliko teh stvari razčlenjeno tudi za nas. Torej, če grem v svoje skladišče skladnosti, bi lahko v tem primeru rekel: dobro veste, da se s tem ukvarja, je to baza podatkov o skladnosti, v kateri je stopnja skladnosti ali regulativna zahteva povezana in je lahko, recimo, Skladnost s SOX ali PCI. Tako lahko izbiram, v katerih zbirkah podatkov naj bo usklajena skladnost z njimi, ki jih moram izpolniti, ali poskrbim, da bom vzdrževal glede na to ureditveno zahtevo.
Torej so se tovrstne stvari izkazale za zelo koristne DBA, saj lahko tam najdejo mesto, s katerim lahko vse te povezane metapodatke ohranijo v svojem okolju in jih lahko, tako kot sem rekel, uskladijo z njihovimi posli. " delaš kot način poslovanja. Če torej pogledamo vse stvari do zdaj, kar smo videli, imaš očitno precej dober pregled nad primerom, če to natančno preučim.
Prav tako lahko iščem, zato sem rekel, da poiščemo to shrambo skladnosti v svojem zalogi. Potem boste tukaj videli, da lahko poiščem te stvari in jih znam prepoznati. Pravim, da - nisem prepričan kaj, gumb za zagon tam ne deluje. V redu. Poglejmo, poskusimo še enkrat. No pa gremo. Torej bi lahko videli razčlenitev tega, kje smo videli, s čimer izpolnjujemo zahteve, in lahko v to razberem in tudi s tega stališča. Torej, dobili ste res hiter in enostaven način za kopanje v te podatke.
Kot smo že omenili, imate veliko različnih načinov za ustvarjanje metapodatkov proti strežniku primerkov in zbirki podatkov. Drugi del tega pa je, da lahko to izkoristite na način, ki ste ga združili, in na način, kako ste ga povezali. Gremo na raziskovalec pogled, lahko naredimo prav to. Lahko rečemo, da želim opraviti število baz podatkov po lokacijah. Torej število baz podatkov na vsaki lokaciji okolij, ki jih podpiram. Ali morda morda temelji na lastniku, ki je lastnik primerkov, ki jih imam tam, v smislu morda števila primerkov. Tako bomo to lahko videli. Tako dobite zares dober in preprost način, kako te slike slikati za vas, glede na vprašanje, na katero poskušate odgovoriti.
Potem lahko to, kar imate na voljo, ustvarite tako, kot ste želeli, lahko pa jih izvozimo v PDF ali različne formate, da jih lahko izkoristimo in pošljemo svojim kolegom ali storimo, kar koli tam potrebujemo. Torej veste, da bi lahko počeli takšne stvari. Vrnimo se k - sem ga izgubil? No pa gremo. V redu, tako upam, da je to smiselno glede na to, o čemer sem do zdaj govoril. Zdaj, ko so podatki, ki smo jih zbrali, je vse to očitno zelo pomembno iz več razlogov - licenciranje in kaj podobnega.
Zadnja stvar, ki jo je treba omeniti, je samo to, da gremo tukaj na to poglavje o administraciji. Tu lahko tudi konfigurirate svoj e-poštni naslov in opozorilo in se prepričate, da lahko za stvari, ki jih želite resnično vedeti, tudi nastavite. Tako lahko nastavimo opozorila po e-pošti, lahko nastavimo možnost vklopa določenih stvari in izklopite določene stvari in nato lahko določimo, kdo bo prejemal ta e-poštna sporočila, in po naročilu teh opozoril lahko povežemo, koga bi želeli biti, ki bi hotel vedeti za takšne stvari.
A kot sem že rekel, je to res lep način, da si vsaj prizanesite, če boste vedeli za celotne primere SQL podjetja - kaj je tisto, kar imate, in poskrbite, da bo tekel optimalno, tudi če ne t, se niso odločili za naložbo v težko orodje za spremljanje uspešnosti za upravljanje tega primerka. To vas bo zajelo, ker je zelo dostopen način, da se odpravite ven, in za veliko primerov boste lahko naredili te zaloge in bili sposobni narediti nekakšno zelo široko vrsto splošnega nadzora, da se prepričate, da dobil ta mir in vedel, kaj se dogaja.
Torej, upam, da je to smiselno v načinu, kako smo ga opisali in vam pokazali. Mislim, da lahko s tega stališča grem naprej in ga prenesem nazaj in se lahko pogovorimo še nekaj.
Eric Kavanagh: Zveni super. Torej Robin? Dez? Kakšno vprašanje?
Robin Bloor: No, imam vprašanja. Pravzaprav je zelo zanimivo, hočem reči, da sem hotel komentirati, da sem bil skorajda povsod, kjer sem že, ne le med DBA-ji, ampak med omrežji, med fanti za shranjevanje, med fanti za upravljanje virtualnih strojev, ponovno obdelajte preglednice.
Eric Kavanagh: Tako je.
Dez Blanchfield: Nekako veš, da je to, nekako veš, da je to v redu, dokler se številke ne začnejo premikati. Ko se številke začnejo premikati, veste, da se bodo znašle v težavah. Torej, vprašanje, ki me zdaj nekako zanima, in vem, da vam bo težko odgovoriti, ampak kaj, če boste šli na mesto, kjer nimajo ničesar podobnega, da bi delali preglednice, zato predpostavimo DBA-ji so zelo pametni fantje in tako naprej in podobno. Kakšen ROI se vam zdi, da bi dobili kaj takega? Imate kakšne podatke o tem ali kakšne smernice o tem?
Bullett Manale: Težko je reči, kakšen je ROI, ker bo okolje nekoliko drugačno. Očitno je, da ko je večje podjetje, večje je okolje, očitno bo bolj donosnost naložbe, če zdaj uporabljajo, veste, ročne metode.
Vem, da sem govoril s številnimi - ko rečem velike organizacije s tisoči in tisoč zaposlenimi in verjetno tudi na tisoče primerov -, kjer imam ljudi, kjer jim to pokažem, in pravijo, da bo to trajalo dva tedna mojega časa nazaj. To sem že rekel že večkrat. Težko je reči glede na dejanski znesek dolarja od nakupa, vendar je veliko, ko imate okoliščine.
Kot sem že rekel, to je precej dosledno, ljudje, s katerimi govorim, večino ljudi hranijo v preglednici. Torej je to le zelo, zelo subjektivna stvar, saj je vsako okolje malo drugače, kar zadeva njihovo licenciranje in kako licenciranje pri Microsoftu je še en del tega, kar je dejavnik. Ampak če bodo morali vsako leto ali vsaka tri leta resnično spremljati, mislim, da bodo Microsoftu tri leta največ, če to bodo, potem hočejo, da se vsaj na vsaka tri leta.
Potem veš, kar je precej, in veš, da je le nekaj, kar veliko olajša. Ker gre za dinamično stvar, ki se vedno spreminja, daje nekoliko več veljavnosti tudi glede na to, kaj gledate v verze, dobro, da preglednice v resnici nismo posodobili v šestih mesecih ali enem letu. Torej, kako pogosto posodabljate preglednico, je še eno vprašanje, da razumete, da je odgovor na donosnost naložbe.
Dez Blanchfield: Ja, mislim, licenciranje SQL, dovoljenje za to je le prekleta nočna mora, predvsem pa nočna mora, ker licenciranje ni enako med Microsoftom in Oracleom in vsemi drugimi, ki tam delajo baze podatkov. Če stvari dejansko hranite v preglednicah, ki se ponavadi zgodijo, veste, da prihaja čas licenciranja, preden ga dejansko zares spoznate, in dejansko nimate podatkov, če veste, kaj mislim, te informacije.
Kakorkoli že poudarite, je dinamičen in osebno nimam pojma, ker se mi v resnici nikoli ni bilo treba pogajati z Microsoftom, tako da pojma nimam, verjetno pa obstajajo zbirke podatkov, ki jih ljudje precej pogosto lotijo testnih podatkov, testiranje okolja in ugibam, da so ti trn v tvoji strani, če delaš dovoljenje. Ste to vi?
Bullett Manale: Ja, ja. Tako je, ker velikokrat na te stvari pozabimo in nato začnemo poskušati ugotoviti, v redu, v redu, imamo osrednje dovoljenje, da moramo ugotoviti število jeder za vsak od teh primerov, in ne Ne vem, da glede na standarde tega, kaj kupujete strojno, lahko kupite precej dobro strojno opremo, potem če te strojne opreme ne uporabljate tako, kot bi jo bilo treba uporabiti, potem preplačujete, ker ste plačilo za osnovne cene, kadar teh jeder ni mogoče izkoristiti, tako da postane težava.
Vsaka različica SQL ima torej drugačen način uporabe licenc, kar celo nekoliko zmede. Torej imate okoli tega nekaj izzivov, zato je to velik del tega, zakaj so te informacije v veliko pomoč, ker vam lahko povemo, katera različica je, očitno vam lahko povemo, koliko število jeder imate, če gre za starejše različice SQL to je bilo ceno na posamezno vtičnico, to lahko še vedno pokažemo. Torej samo, precej preprosteje je rutina, ki jo morate opraviti, ko pride čas, da to stvar izpopolnite.
Dez Blanchfield: Ena stvar, ki mi pade na pamet, oprostite,
Robin Bloor: V redu je, pojdi v Dez, nameraval sem postaviti nepomembno vprašanje.
Dez Blanchfield: Nekaj zelo hitro, ko se ukvarjate s temo, o kateri zdaj razmišljate - opažamo veliko več sprejemanja oblačnih okolij in če to izvajamo v svojem lastnem podatkovnem centru, v našem lastnem okolju, se plazijo okoli in iščejo, odkrivanje stvari je razmeroma enostavno.
Kako to, kako se spopadamo s scenarijem, v katerem imamo morda tri podatkovne naloge, dva oblaka in vidnost v teh okoljih je požarna, pogosto pa je na voljo tudi niz podatkov na koncu cevi ali VPN. Ali lahko odkrijemo vrata s sprednjega dela ali pa moramo začeti odpirati vrata, da bomo lahko v določenem okolju skenirali med oblakom in zunaj prostorov, kjer deluje ta platforma?
Bullett Manale: Ja, res bi bilo treba razmisliti o pristaniščih. Žal si želim, da bi lahko rekel, da se bo prebil skozi vsa ta okolja, vendar obstaja nekaj različnih možnosti, ki bi jih lahko storili s tem. Če počnete nekaj takega, kot je Amazon EC2, bi resnično potrebovali dostop do tega okolja prek svoje povezljivosti, ob predpostavki, da so vrata odprta, nato pa lahko določite svoje naslove IP ali svojo domeno, povezano s tem in se lahko začne zbiranje in začeti odkrivanje.
Torej v tistih okoljih to res ni težava; gre za bolj specifične vrste okolij, kot je RDS, in kjer samo bazo podatkov dobite tam, kjer bo videti in odkrivati to vrsto informacij nekoliko bolj zahtevno.
Dez Blanchfield: Torej po tistem, kar je bilo tam, obstajajo baze in baze podatkov. Tako so na primer dobri stari časi, da imamo zelo, zelo velik motor podatkovnih baz, kot je anekdota, ki sem jo delil spredaj, kjer je le ena velika platforma, in vse, kar počne, je zagotavljanje podatkovne baze. Danes so baze podatkov vgrajene v vse, pravzaprav v mojem telefonu za aplikacijami tečeta dva ali trije.
Kakšne izzive imate pri scenarijih, v katerih imate okolja iz Lotus Notes-a, z aplikacijami za njimi, SharePoint z bazo podatkov na različnih spletnih straneh in podobno? V bistvu vse napaja baza podatkov na zadnji strani. Kakšne stvari vidite tam in s kakšnimi izzivi se srečujete ljudje, ki samo poskušajo preslikati te vrste svetov in kaj vaše orodje naredi za njih?
Bullett Manale: No, mislim, da je stvar tega, kar ste povedali - zdaj vse potrebuje bazo podatkov, zato je velikokrat verjetno veliko, obstaja veliko baz podatkov, ki se vnašajo v okolje, ki jih je sam DBA se sploh ne zavedajo, ker v okolju na splošno ni težko namestiti strežnika SQL.
To orodje določa tudi stvari, kot so ekspresne baze podatkov, zato so brezplačne različice SQL Serverja. Smešno je, da se, ko se spet pogovarjate z DBA, ne dobite doslednega odgovora, ali jim je mar za brezplačne baze podatkov, ki so tam. Veliko teh aplikacij, o katerih govorite, bo uporabljalo brezplačno različico baze podatkov. Toda same organizacije bodo imele drugačen odnos glede tega, kdo je odgovoren za to bazo podatkov, odvisno od tega, s kom govorite.
Nekateri pooblaščeni akterji, s katerimi govorim, lahko pomislim, da sem zadnjič, ko sem bil na SQL Server PASS, ki je v Seattlu, postavil vprašanje "Ali vas zanimajo vaše ekspresne baze podatkov?" In je bilo približno petinpetdeset. Nekateri ljudje so želeli vedeti o njih kot o pooblaščenih osebnih državljanih, ker menijo, da so del njihovih odgovornosti, tudi tistih izraženih zbirkah podatkov, ki bi lahko vsebovali kritične informacije; še vedno morajo skozi varnostno kopijo in še vedno morajo zagotoviti, da vse stvari delujejo z vidika zdravja. Toda samo vedeti, da obstajajo, je prav tako pomembno, če ne še bolj pomembno.
Medtem ko je druga polovica ljudi: "Hej, nismo odgovorni za te baze podatkov in karkoli, kar so vložili v njih, pazi na osebo, ki jih je namestila." Ampak to bi rekel na splošno, kar si Povedano je, da je danes vse, kar je v veliki meri povezano z njim, samo še bolj prispevalo k zapletenosti in nejasnosti, da je treba te podatke popisati.
Dez Blanchfield: Ja, že sem videl, da so vladna spletna mesta verjetno moja najljubša, vendar pogosteje kot zdaj vidim v podjetniških okoljih, kjer je to, kot ste dejali, da ljudje pozabijo tudi mene, ko namestijo nekaj, kot je SharePoint oz. tako kot samo izmenjava, tako da veste, da prihajajo z brezplačno različico, ki je pravkar vgrajena, ker želijo, veste, hitro jo namestite in ne skrbite, da bi morali iti in kupiti licenciranje.
Potem postane velik, nato pa se nekdo začne pritoževati nad uspešnostjo in so kot: "To je samo vaš stari strežnik, vaša shramba, vaše omrežje, karkoli že, " in potem se imenuje DBA in se imenujejo: "No, ti" V to brezplačno različico zbirke podatkov sem pravkar zabeležil vse, kar pa ni tisto, kar bi potrebovali za to veliko. "
Zlasti ko imate scenarije, kot sta Project Manager in Office, izvaja stotine, če ne tisoče projektov v velikem podjetju ali podjetju in uporabljajo SharePoint z Microsoft Project Server in vse svoje PMO stvari odlagajo v to bazo. Toda na sprednjem delu so takšni, no, to je le spletni vmesnik. Res pa obstajajo baze in baze podatkov.
Bullett Manale: Da.
Dez Blanchfield: Pa kaj so to, eden od prvih korakov, ki jih imajo ljudje tukaj, mislim, da imamo nekaj vprašanj, ki jih bomo morda želeli predstaviti iz publike. Eno prvih vprašanj je, kje ljudje začnejo? Kakšen prvi naravni korak je, da gredo: "V redu, moramo narediti anonimno različico Alcoholics?"
Imamo več baz podatkov, kot vemo, kaj storiti. Kakšen je naravni korak, kot je videti, če gremo: "V redu, moramo to spraviti in začeti teči?" Ali grejo hladno puranje ali kasneje res potrebujejo začetek malega in si pridobijo nekaj izkušenj s preslikavo svojega okolja ?
Bullett Manale: No, mislim, da je to moralo preslikati okolje. Zdaj Microsoft ponuja brezplačno orodje za to, Microsoftovo orodje za načrtovanje ocenjevanja, je brezplačno orodje, vendar je statično. Odkrijete to in to je to. Dobiš seznam stvari, ki so tam zunaj. Vzeli smo to in si rekli, poglejmo še korak dlje, naredimo odkritje, poiščimo, kaj je tam zunaj, dajmo ga v repozitorij in naredimo tako, da je dinamično in mu lahko dodamo, odstranimo iz njega.
Toda na splošno je največji prvi korak, da odkrijem, da bi to ugotovili. Ali to pomeni, da naš izdelek prenesete poskusno, ga lahko prenesete in preizkusite 14 dni, lahko pa opozorite na svoje okolje in naredite zbirko.
Zdaj, če že imate preglednico s kopico teh informacij tam, da ste nekoliko prepričani, da so te informacije pravilne, imate tudi možnost, da vam je všeč uvoz CSV-ja, ki je preglednica, z vsemi temi informacijami in naredite tisti del tega, kar ste že imam. Kar pa lahko ugotovimo, česar ne veste, je edini način, da ročno greste ven, naredite to orodje ali pa najdete orodje, ki išče tovrstne stvari, kot je ta. To je odločitev, ki jo boste v nekem trenutku morali sprejeti: "Ali poskušam avtomatizirati to odkritje ali vsaj dobim dobro osnovo tistega, kar je tam zunaj, potem pa morda skrbite za nekatere izjeme?" večinoma verjetno potrebujete orodje.
Dez Blanchfield: Torej samo hitro. Kam gredo ljudje, da začnejo s tem? So zadeli vaše spletno mesto? Kako stopijo v stik in hitro začnejo s tem?
Bullett Manale: Če greš na Idero, IDERA.com, boš videl, in dejansko lahko resnično hitro prikazujem to hitro. Na spletnem mestu Idera boste poiskali izdelke, poiskali upravitelja zalog. Tu boste videli povezavo za prenos. Pravkar določite, katero sestavo želite namestiti na 64 ali 32 bit, in to se bo začelo in odkritje lahko začnete od tam.
Robin Bloor: Fantastična in odlična, odlična predstavitev, najlepša hvala.
Bullett Manale: Hvala.
Eric Kavanagh: Imamo nekaj vprašanj od občinstva in vam jih bomo poslali po e-pošti, ker se moramo danes težko ustaviti, ampak Bullett, spet, odlično delo na demo, odlična naloga našega producenta, ki je ujel, da ga ni bilo ' t prikazuje.
Bullett Manale: Oprosti zaradi tega.
Eric Kavanagh: Ne, to so dobre stvari, dajete prepoznavnost v jedro poslovanja, kajne? Ker podjetje vodi podatke, vi pa dajete vidnost vse do jedra. Torej ni več ročno valovitih stvari; zdaj lahko dejansko kažete na stvari in to rešite. Tako dobro za vas.
Bullett Manale: Hvala.
Robin Bloor: A čudovito je bilo videti, da je bilo to v živo tudi mimogrede, dobro opravljeno.
Eric Kavanagh: Ja, to spletno oddajo bomo arhivirali za poznejši ogled, nato pa jo bomo imeli, upam, v približno uri ali dveh, začetni arhiv se bo povzpel, včasih je malo dlje, vendar bomo ljudem zagotovo pustili vem. S tem vas bomo spustili, ljudje. Še enkrat hvala, da ste se udeležili seznama, v resnici smo vroče tehnologije. Naslednjič vas bomo dohiteli. Pazite, zbogom.
