Odvzem: Voditelj Eric Kavanagh razpravlja o upravljanju z bazami podatkov in odkrivanju primerkov z Robin Bloor, Dez Blanchfield in Bullett Manale v zadnji epizodi Hot Technologies.
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, prav, čas je za Hot Technologies. Ja, res, moje ime je spet Eric Kavanagh. Najdete me na @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 že malo 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, resnično. 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 zbirka podatkov 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 baze podatkov, v zadnjem času pa se sliši 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 dela. Eden od njih so kratke naključne transakcije, drugi pa dolge poizvedbe, ki zajemajo veliko podatkov. Druga možnost je, da sta baza podatkov NoSQL in baza grafov v glavnem namenjena analitiki in sta se nedavno 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.
Toda resničnost je, da se večina podjetij standardizira na določeni bazi podatkov. In večina podjetij se je standardizirala bodisi na SQL Server in 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 zgradite samo poizvedbe ali SQL motorja, ki je resnično uspešen v zelo majhnem času. To 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 ni dominiral. Imate dejstvo, 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 spomnim se natančno, koliko DBA so imeli, toda če ste se z njimi dejansko pogovarjali o tem, koliko teh baz podatkov nadzoruje DBA, 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 konfiguracijo 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.
Pred kratkim je bilo govora, naletela sem na različne baze podatkov, ki trdijo, da so samonastavitve. 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 pravih indeksov ne postavite na pravo mesto, se jim pridružijo vzeti nedoločen čas, ko vam 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 vedno ukvarjate z isto različico. Toda v resnici na veliko spletnih mest, na katere sem naletel, se to ne dogaja. Recimo, obstaja precej 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 opravljeno poizvedbo, ki jo je treba razdeliti, lahko ustvarite dva primerka in ponovite, kar pogosto storite, kadar ljudje uporabljajo repliko kot vroče varnostno kopijo, če je treba. Potem načrtovanje skladiščenja in zmogljivosti, ki je 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 pogosteje, kot se mi zdi, dobro se spomnim, da se je to dogajalo, vendar sem bil vsaj deset let izven igre, vendar se spomnim, da se to dogaja pogosteje, 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. Torej, po mojem mnenju je seznam delovnih mest DBA poleg vsega drugega, kar 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 reči. Bom izročil Dez.
Dez Blanchfield: Najlepša hvala. Odpeljal se bom na zabavno, anekdotično potovanje, zakaj je celotna tema, o kateri se danes govori, in 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 je bila uporabljena za registracijo licenc in registracijo vozil, ter celo vrsto stvari okoli te teme, iz 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 to. 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 preiti vsak del Unixa v okolju mainframe, odkriti, kje so bile vse baze podatkov in koliko instanc je tekla in kaj se je izvajalo v teh primerih. To 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šino izkazalo, 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 naokoli. In morate opraviti, ali ta oseba razvija proizvodne razrede in preizkušanje, ali se ukvarja s proizvodnjo, ali obstajajo dejanski uporabniki? Ne pozabite, da ta stvar izdaja vozniške dovoljenja in registracije avtomobilov v realnem času in stvari, ki so resnično pomembne za življenje ljudi.
In trajalo je dolgo časa, da smo ustvarili varnostne kopije za to stvar, tako da v resnici nismo imeli okna za vzdrževanje, da bi stvar vzeli brez povezave 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 razumno razmišljanje dneva je bilo, da smo prešli na večjo, boljšo, hitrejšo in tršo strojno opremo, ni razloga, da bi slabo deloval v aplikaciji na ravni baze podatkov, 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 pripeljali vse primere. 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 se je izvajalo v različici Oracle za mainframe, preselilo v Solaris na SPARC različica Oracle ni takoj prenesla iste zmogljivosti. Torej je bilo to za nas najprej zelo mučno potovanje, saj smo to šele izvedli 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 okoli. 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 podatkov, ni bila skladna na obeh platformah. 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 prepovedane police.
In to iz tega izvlečete, 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 bi 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, Bullett. Torej s tem, Bullett, prešel bom k vam in veselim se, ko bom zaslišal, kako ste rešili to težavo.
Bullett Manale: Vredu. 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 tako vroč, tako da, če uporabljate slušalke, ga le malo povlecite.
Bullett Manale: Brez problema. Je to bolje?
Eric Kavanagh: To je veliko bolje. Vzemi stran.
Bullett Manale: Vredu. 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: "Pa 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, ki so jim odgovorni, to, ker je ena od stvari, ki jo morajo storiti, skrb 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 od tistih, ki je nekakšna velika postavka vozovnic, kar je DBA, kar 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 reči, da razmislimo o odkritju tega dela. 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 prišlo. 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. Tako da je tudi to velik del tega orodja, da lahko samo vemo, 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, kjer v resnici so fizično hodili od enega kraja do drugega, da bi poskusili ugotoviti, kako je videti to število. Lahko si predstavljate, da vam kot DBA plačujete precej 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 lahko to storimo 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 odkrivanja.
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 to veliko boljši način kot metoda superge ali superge. Kul stvar je, da se vsi ti podatki, ki jih zbiramo o primerku, hranijo v skladišču in se lahko spreminjajo, ko se spreminja tudi 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 potem? Druga stvar je veliko informacij o primerku, ne želim si, da bi ga ročno dobili in ga dali 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 naokoli 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, lahko uvozite te primerke v in nato sestavite ta del svojega upravljanega inventarja v izdelku. Ko imamo primerek in ko izvemo, da je to potem, postane, v redu, imamo veliko informacij, ki jih lahko izkoristimo, če vemo, da je ta primerek tam, tako da gremo ven in zberemo te podatke.
In veliko informacij bo potrebnih za več kot zgolj licenčne namene. Veliko tega je mogoče uporabiti za očitno samo vedeti, kje so stvari, za iskanje po teh informacijah, ko jih dobimo. Ključna stvar pa je strežnik, sama strojna oprema. Ker lahko razumemo, kakšen stroj je, morda model ali proizvajalec, pomnilnik, količino pomnilnika, ne glede na to, ali gre za fizični ali virtualni stroj, š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 in tako prihranite velik čas. In še enkrat, ker dinamično odhaja in vsakodnevno prepoznava nove primerke, to je živa stvar, ki jo imate v zvezi s svojim zalogom. To je nekakšen cilj izdelka, da bo to tako, da je to 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 kar koli 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 je vrsta dveh področij v orodju, ki vam omogočata 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 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 so se vsi ti podatki zbirali, vsi ti podatki in podatki, ki so zbirali in uporabljali metapodatke, da bi dobili možnost lažjega in hitrejšega odločanja o posodobitvi licenc pri Microsoftu pri podjetju za obsežno licenco ali zavarovanje 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. Tako je to eden od mandatov izdelka, kdaj pa tudi DBA lažje sprejmejo te odločitve v zvezi z licenciranjem.
Zdaj pa smo drugo stvar, ki smo jo, kot da bi se pogovarjali z DBA-ji, zelo hitro odkrili in izvedeli, to, da - in to, da se vrnemo na tisto, o čemer smo govorili prej -, imate v okolju SQL Server 300 primerov, toda v resnici je morda le podnabor 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 ste dobili teh 20 primerov ali 10 primerov od 300, ki jih spremljate s tem orodjem, ki je zasnovano za spremljanje tega in v skladu z vašimi SOA in preberite opozorila in vse te dobre stvari, "kaj smo ugotovili tudi, če ste vprašali:" Torej, kaj pa s temi drugimi 280 primeri, ki jih imate? Te skrbijo? "In res jih skrbi, zanje pa ne želijo nujno naložiti, da bi spremljali tiste na ravni globine, ki jih je mogoče narediti s temi primeri v primerjavi s temi 10 ali 20 resnično, resnično kritičnimi primerki izdelkov.
Drugi del enačbe s tem orodjem je tudi ta, da pomaga tudi pri zagotavljanju, da ste na osnovni ravni pokriti glede na primer zdravja. Zdaj vam ne bo povedal, ali imate zastoj ali kdo je žrtev mrtvega kota. Ne bi smeli priti na to raven samih sej in podrobnosti poizvedb. Hkrati pa vam to še vedno daje vedeti, hej, da strežniki popustijo ali hej, da se glasnost polni ali pa morate narediti varnostne kopije baze podatkov, kar je 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 bodo upoštevani, in tudi poskrbeli za to oblikujejo se osnovne stopnje zdravstvenih pregledov.
Torej, na kratko, kaj vse počnejo upravljavci uvoza SQL Inventory. Zdaj vam bom pokazal demonstracijo. Preden to storimo, vam na hitro pokažem, da gre tukaj za diapozitiv o arhitekturi in če želite to pokazati, primere SQL, ki so upravljali, lahko odkrijemo vse, od SQL 2000 vse do novih različic SQL.
Torej lahko to storimo, ne da bi nam bilo treba kadarkoli napotiti agente na primerke. To storimo prek storitve zbiranja, ki bo šla ven in zbrala te podatke in jih shranila v skladišče, nato pa bo iz prednje konzole Tomcat spletna storitev lahko vzajemno komunicirala s temi podatki in si jih ogledala. Torej njegova precej preprosta arhitektura.
Grem naprej in preklopim in nas dejansko prevzamejo v samem izdelku, da boste imeli občutek za to, kako razumeti, kako deluje. Zato je najboljši način, da se najprej predstavimo samemu vmesniku. To je nekakšna nadzorna plošča, ki so jo gledali 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 rekel, Im, to, kar bom storil, je, da se sprehodim skozi postopek odkritja in pokažem, kako bo 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 strojih, ki so člani te domene, izvajajo ta preverjanja, za katere bi lahko izbrali številne različne značilnosti, ko se SQL izvajajo.
Potem ko to storite in boste lahko avtomatizirali, da se vsakodnevno izvaja in zbira te podatke. Po potrebi bi ga lahko izvajali tudi ad hoc. Ko pa to začnete, je postopek odkritja, ki ga začnete opaziti, 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 nadaljeval, je, da nadaljujem in dodam tistega, ki ga bom uporabil kot primer. Torej gre za primer v Chicagu v tem primeru, kajne? Bom šel naprej in dodal ta primerek v moj zalog.
V redu in tukaj me bo šlo skozi nekaj stvari. Samo 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 spomnimo se, da 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 ne glede na to, katera vedra ž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 prvi korak in to, kar sem vam pravkar pokazal, je bil način, na katerega boste dodajali te primere, ko se vsakodnevno podajate. V nekaterih primerih lahko rečete, da veste, kaj če svojo podjetniško izdajo strežnika SQL samodejno želim dodati v svoj seznam? Ni mi treba ročno iti in se odločiti za to.
Jocelyn: Hitro te bom prekinila. Nismo videli vašega demo posnetka.
Bullett Manale: Nisi?
Jocelyn: Št.
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 za to. Ja.
Eric Kavanagh: V redu je. Dober ulov, producent Jocelyn.
Bullett Manale: V redu, je tako tudi bolje? Se zdaj vidite?
Robin Bloor: Da, resnično.
Bullett Manale: V redu, zato vas lahko le sprehodimo do tja, kjer smo bili hitro resnični. Odkrili smo primere, ki smo jih imeli že prej. Pravkar sem dodal primer Chicaga in tako je zdaj navedeno tukaj. Opazite, 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, da lahko to storite samodejno. Ni mi treba iti v prijavo in vezati vloge. Glede na to, kar smo videli, 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 takojšen povzetek, spodaj pa povzetek strežnika. Tako so se na primer pojavili ključni podatki, ki poznajo 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šni servisni paketi so vezani zanj je lahko zelo pomembno vedeti. Očitno je, da je potrebna spomin. Vsega takega, ne glede na to, ali je bila združena, vseh teh informacij, ne bi smel dajati - že se zbirajo in zbirajo, in ko ugotovimo, da je odkrita primera, bo to del našega popisa.
Druga stvar, ki jo boste videli tukaj - in to vam bo pokazala - je pod tem primerom. Imamo te atribute, o katerih sem govoril prej, atribute po meri, ki jih je mogoče dodati. Torej lahko dodamo odprta polja polj, 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 te stvari očitno resnično zelo koristne, saj so vse zbrane in zbrane in tam za nas, takoj ko se odločimo, da bodo del naše zaloge. Tu lahko pokažemo nekatere razlike glede na CPU, število logičnega in fizičnega, koliko pomnilnika. Torej resnično dobivate res dobre in bogate informacije, ne da bi morali veliko delati.
Zdaj drugi del tega, kot sem rekel, zbira 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.Če torej pojdem v svoje skladišče skladnosti, bi v tem primeru lahko rekel, dobro veste, da se s tem ukvarja, to je 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 se vzdržujem glede na to regulativno zahtevo.
Torej so se tovrstne stvari izkazale za zelo koristne DBA, saj je tam mesto, kjer lahko osrednje obiščejo vse te povezane metapodatke v svojem okolju in jih lahko, tako kot sem rekel, uskladijo z njihovim poslovanjem, kot počnejo. , kot način poslovanja. Če torej pogledamo vse stvari do zdaj na tisto, kar smo videli, imaš očitno precej dober pregled nad primerom, če sem preučil vanjo.
Prav tako lahko iščem, zato sem rekel, da poiščem 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, moji gumbi ne delujejo tam. V redu. Poglejmo, poskusimo še enkrat. No pa gremo. Torej bomo lahko videli razčlenitev, kje smo videli, s čimer smo spoštovali, in lahko vpišem v to in vidim 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, kako ste ga razvrstili in na način, kako ste z njim povezani. 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 šteje primerov. 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, kar imate te podatke, je ustvarjen tako, kot ste želeli, ga lahko izvozimo v PDF ali različne formate, da ga lahko izkoristimo in pri svojih sodelavcih ali storimo vse, kar potrebujemo. Torej veste, da bi znali početi takšne stvari. Se vrnimo nazaj - sem ga izgubil? No pa gremo. V redu, upam, da je to smiselno glede na to, o čemer sem do zdaj govoril. Zdaj, ko smo zbrali podatke, je vse to očitno resnično ključnega pomena 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 svoje in vaše opozorilo in se prepričate, da lahko za stvari, ki jih želite resnično vedeti, nastavite tudi te stvari. Tako lahko nastavimo opozorila, lahko nastavimo možnost vklopa določenih stvari in izklopite določene stvari, nato pa bomo lahko določili, kdo jih bo prejemal, in po naročilu teh opozoril lahko povežemo, koga bi želeli bodi, ki bi hotel vedeti za takšne stvari.
A kot sem že rekel, je to res lep način, da si vsaj privoščite, da boste vedeli za primere celotnega SQL podjetja - kaj vse imate in poskrbite tudi za njegovo optimalno delovanje, tudi če ne, 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.
Tako da upamo, da je smiselno, 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: Sliši se odlično. Torej Robin? Dez? Kakšno vprašanje?
Robin Bloor: No, imam vprašanja. Zelo zanimivo je to dejansko gledati, hočem reči, da sem hotel komentirati, da sem bil skorajda povsod, kjer sem bil, ne le med DBA-ji, ampak med omrežji, med fanti za shranjevanje, med fanti za upravljanje virtualnih strojev, oni so vsi obratovanje preglednic.
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. Zdaj me vprašanje nekako zanima in vem, da bo težko odgovoriti na vas, toda kaj, če grete na mesto, kjer nimajo ničesar podobnega, da bi delali preglednice, zato naj prevzamejo DBA 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 donosnost naložbe, ker bodo okolja nekoliko drugačna. Očitno je, da večje kot je podjetje, večje je okolje, očitno bo bolj donosnost naložbe, če zdaj uporabljajo 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 imel že večkrat. Torej je težko reči glede na dejanski znesek dolarja od nakupa, vendar je precej, če imate okoliščine.
Kot sem že rekel, to je precej dosledno, ljudje, ki jih imam, večina ljudi, s katerimi govorim, te stvari hranijo v preglednici. Torej je samo to zelo, zelo subjektivna stvar, ker je vsako okolje, ki je nekoliko drugačno v smislu, kako opravljajo licenciranje in kako opravljajo licenciranje pri Microsoftu, še en del tega dejavnika. Ampak, če jim bo treba vsako leto ali vsaka tri leta narediti resnične posnetke, se mi zdi, da bi pri Microsoftu tri leta največ, če hočejo, resnično začeli vsaj vsaka tri leta.
Potem se zavedaš njegovega občutnega in to, veš, samo nekaj, kar veliko olajša. Ker se dinamična stvar, ki se vedno spreminja, daje nekoliko več veljavnosti tudi glede na to, kaj gledate v verze, no, preglednice res 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, a še posebej nočna mora, ker licenciranje ni enako med Microsoftom in Oracleom, pač pa še kdo drug tam, kjer delajo baze podatkov. Če stvari dejansko hranite v preglednicah, ki se ponavadi zgodijo, veste, da čas za izdajo dovoljenj nastopi, preden ga dejansko zares spoznate, in dejansko nimate podatkov, če veste, kaj mislim, da bi lažje prišli do teh informacij.
Kakorkoli že poudarite, njegova dinamika in osebno nimam pojma, ker se mi v resnici ni bilo treba pogajati z Microsoftom, zato Ive nimam pojma, toda najbrž obstajajo zbirke podatkov, ki jih ljudje precej pogosto lotijo testnih podatkov, preskusnih okolij in jaz bi ugibajte, da so ti trn v vaši strani, če licencirate. Ste to vi?
Bullett Manale: Ja, ja. Tako je, ker velikokrat na te stvari pozabimo in potem začnemo poskušati ugotoviti, v redu, v redu, weve je dobil osnovno licenco, da moramo ugotoviti število jeder za vsakega od teh primerov in ne vem, kar zadeva standarde, kaj kupujete strojno opremo, lahko tudi kupite precej dobro strojno opremo, potem če te strojne opreme ne uporabljate tako, kot bi jo morali uporabiti, potem preplačujete, ker plačujete za osnovno ceno, ko ta jedra ne izkoristite, 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 in tako je to velik del tega, zakaj so te informacije zelo koristne, ker vam lahko povemo, katera različica je, očitno vam lahko povemo, koliko število jeder imate, če so 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 resnično hitro, medtem ko ste zdaj na temo, ki ste jo zdaj - videli smo veliko več sprejemanja oblačnih okolij in če bi to izvajali znotraj lastnega našega podatkovnega centra, znotraj svojega lastnega okolja, se plazijo in iščejo, odkrivanje stvari je relativno 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 in pogosto je nabor podatkov na koncu cevi ali VPN. Ali lahko odkrijemo vrata s sprednjim delom ali pa moramo začeti odpirati vrata, da bomo lahko v določenem okolju skenirali med oblakom in zunaj prostorov, kjer te platforme delujejo?
Bullett Manale: Ja, res bi bilo nekaj v zvezi s pristanišči. Ž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. Očitno je, da, če počnete kaj podobnega Amazonu EC2, resnično potrebujete dostop do tega okolja prek svoje povezljivosti, če predpostavite, da so vrata odprta, nato pa lahko določite svoje naslove IP ali svojo domeno, povezano s tem in lahko začne zbirati in začnite odkrivati.
Torej, v tistih okoljih to res ni težava; njegove bolj specifične vrste okolij, kot je RDS in kjer samo pridobivate bazo podatkov, kjer bo videti in odkrivati to vrsto informacij nekoliko bolj zahtevno.
Dez Blanchfield: Torej po tem, kar je bilo tam, so te baze in baze podatkov. Tako so na primer dobri stari časi, da imamo zelo, zelo velik motor z bazami podatkov, kot je anekdota, ki sem jo delil spredaj, kjer je njena samo ena velika platforma in vse, kar počne, je zagotavljanje podatkovnih baz. Te dni so baze podatkov vgrajene v vse, v resnici pa te stvari, kot sta dve ali tri, pravkar tečeta v mojem telefonu za aplikacijami.
Kakšne izzive imate pri scenarijih, v katerih imate okolja, ki prihajajo iz Lotus Notes-a, z aplikacijami, 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 velikokrat obstaja veliko verjetno, obstaja veliko baz podatkov, ki se vpeljejo v okolje, ki ga sami DBA sploh ne izdelajo zavedati se tega je, ker na splošno strežnika SQL ni mogoče namestiti v okolje, na splošno gledano.
To orodje določa tudi stvari, kot so ekspresne baze podatkov, zato so brezplačne različice SQL Serverja. Dovolj smešno, ko se spet pogovarjate z DBA, ne dobite doslednega odgovora, ali jim je vseeno za brezplačne baze podatkov, ki so tam zunaj. Veliko teh aplikacij, o katerih govorite, bo uporabljalo brezplačno različico baze podatkov. Toda same organizacije bodo imele drugačen odnos glede na to, 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 njihove odgovornosti, celo tiste izražene baze podatkov, ki bi lahko vsebovale 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, niso bili odgovorni za te baze podatkov, karkoli, kar so jim postavili, pa pazi na osebo, ki jih je namestila." Ampak rekel bi, da je na splošno to, kar ste povedali, vse lepo dandanes je nanjo privezana aplikacija, ki samo še bolj prispeva k zapletenosti in zmedi glede navajanja teh informacij.
Dez Blanchfield: Ja, videl sem nekaj, vladna spletna mesta so mi verjetno najljubša, vendar pogosteje, kot jih ne vidim v podjetniških okoljih, kje je, kot rečeno, da ljudje pozabim tudi mene, ko namestijo nekaj podobnega kot SharePoint ali kot samo izmenjavo, 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, potem 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", nato pa se imenuje DBA in se jim reče: "No, pravkar si vse je natisnil v tej brezplačni različici baze podatkov, kar pa ni tisto, kar bi potrebovali za to veliko. "
Zlasti ko imate scenarije, kot sta Project Manager in Office, na stotine, če ne na tisoče projektov v velikem podjetju ali podjetju, uporabljajo SharePoint z Microsoft Project Server in vse svoje PMO stvari odlagajo v to bazo podatkov. Toda na sprednjem delu so všeč, no, njegov samo spletni vmesnik. Ampak resnično obstajajo baze in baze podatkov.
Bullett Manale: Da.
Dez Blanchfield: Torej, kaj so to, eden od prvih korakov, ki jih imajo ljudje tukaj, mislim, da ima nekaj vprašanj, ki jih bomo morda želeli predstaviti iz publike. Eno prvih vprašanj je, kje ljudje začnejo? Kaj je prvi naravni korak, 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 rekel, da morajo preslikati okolje. Zdaj Microsoft ponuja brezplačno orodje za to, Microsoftovo orodje za načrtovanje ocenjevanja, svoje brezplačno orodje, vendar je statično. Odkriješ to in to je to. Dobiš seznam stvari, ki so tam zunaj. Vzeli smo to in rekli, da gremo še korak naprej, da odkrijemo, poiščemo, kaj je tam zunaj, in ga omogočimo, da ga shranimo v skladišče in omogočimo, 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. Toda v zvezi s tem, kako ugotoviti, česa ne veste, je edini način, da ročno greste ven, naredite to ali pa imate orodje, ki išče tovrstne stvari, kot je ta. To je odločitev, ki jo boš nekoč moral sprejeti: "Ali poskušam avtomatizirati to odkritje ali vsaj dobim dobro osnovo, kaj se tam najprej znajde, potem pa morda skrbim za nekatere izjeme?" Toda za večino del 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 Idera, I-D-E-R-A.com, boš videl, in pravzaprav lahko res hitro hitro pokažem. Na spletni strani Idera pojdite na izdelke, pojdite na upravitelja zalog. Tukaj boste videli povezavo za prenos. Pravkar določite, katero sestavo želite namestiti na 64 ali 32 bit, in to se vam bo zgodilo in odkritje lahko začnete od tam.
Robin Bloor: Fantastična in super, odlična predstavitev, najlepša hvala.
Bullett Manale: Hvala vam.
Eric Kavanagh: Imamo nekaj vprašanj od občinstva in tudi takih do vas, ker se moramo danes težko ustaviti, toda Bullett je spet odlična naloga na demonstraciji, odlično delo našega producenta, ki je ujel, da se ni izkazalo.
Bullett Manale: Oprosti za to.
Eric Kavanagh: Ne, to je dobra stvar, vidnost si dajete v jedro poslovanja, kajne? Ker podjetje vodi podatke in vidnost dajete 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 vam.
Robin Bloor: Bilo pa je čudovito videti tudi v živo, 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 nekoliko dlje od tega, vendar dobro obvestite ljudi. S tem bi vas izpustili, ljudje. Še enkrat hvala, da ste se udeležili sestanka, v resnici so bile vroče tehnologije. Pa vas dohitevam naslednjič. Pazite, zbogom.