Odnést: Host Eric Kavanagh diskutuje o správě databází a objevování instancí s Robinem Bloorem, Dezem Blanchfieldem a Bullettem Manaleem v nejnovější epizodě Hot Technologies.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Eric Kavanagh: Dobře dámy a pánové. Vítejte zpět. Jmenuji se Eric Kavanagh. Věci jsou horké. Věci se zde zahřívají. Nevím, co se děje. To je pravda, je čas na Hot Technologies. Ano, mé jméno je opět Eric Kavanagh. Najdete mě na @eric_kavanagh. Toto je pořad, který je navržen tak, aby hovořil o tom, co je na trhu horké. Název dnes: „Klíče k království: Správa serveru SQL s dynamickým objevem.“ Dobré věci. Opravdu jsou vaše. Dobře, ten obrázek byl z před několika lety. Nebudu lhát, teď vypadám trochu starší, ale to je v pořádku.
Takže mluvíme o tom, jak technologie a SQL Server jsou opravdu, opravdu, opravdu, opravdu horké. Dnes máme spoustu obsahu, takže to hned podám. Vydrž, tady jdeme. Jsou tu naši řečníci. A Robin Bloor jde první.
Robin Bloor: Ano vskutku. Prezentace půjde do hloubky do správy databází, tak jsem si myslel, že budu procházet správou databází nebo, jak víte, databáze bludištěm, aby se lidé dostali do jeho ducha. Kdysi jsem byl DBA, předpokládám, že byste asi řekl, že jsem byl databázovým poradcem asi před 20 lety, a věc, která mě ve skutečnosti překvapuje o databázích, je to, že se toho moc nezměnilo. Hodně věcí se změnilo, pokud jde o rychlost, co se týče objemu dat a podobných věcí, ale většina z nich ve skutečnosti zůstává velmi podobná tomu, co se stalo.
Databáze je podle mého názoru organizovaná rozšiřitelná sbírka dat, která mohou být optimalizována pro konkrétní pracovní vytížení a poskytují možnosti správy dat. Vznikl především proto, že pokud jste chtěli spravovat data v souborech, byla to hrozně obtížná práce. A myšlenka sestavit kus softwaru, který by udělal skoro cokoli, co byste potřebovali, se rozběhla téměř okamžitě, jakmile jsme měli náhodný přístup k mainframům IBM v 70. letech.
Relační databáze byla vynalezena v 70. letech 20. století a vznikla jako prototypy v 80. letech 20. století a její typ na trhu se objevil od začátku 90. let. A relační databáze jsou stále v popularitě naprosto dominantní. Pokud si přečtete tisk, uslyšíte o nich strašně mnoho věcí - databází SQL a v poslední době je o grafických databázích strašně hlučné. A ty jsou zajímavé, pokud se vám líbí, ale ve skutečnosti stále v posledních prodejních číslech, relační databáze mají 95% trhu. A Microsoft SQL Server, o kterém se dnes chystáme do hloubky diskutovat, je pro Oracle druhým nejoblíbenějším.
Věc o relačních databázích, která je činí neobvyklými, pokud jde o motory, které jsou, mohou pracovat jak na OLTP, tak na pracovní vytížení dotazů. Pokud to chcete udělat, musíte je naladit odlišně, ale ve skutečnosti jsou schopni obou typů pracovní zátěže. Jedním z nich jsou krátké náhodné transakce a druhým jsou dlouhé dotazy zahrnující mnoho dat. Alternativa, databáze NoSQL a databáze grafů, je hlavně pro analytiku a nedávno se objevila poměrně rychle. NoSQL byl na prvním místě a graf začal v poslední době trochu tahat. NoSQL lze použít pro transakční aktivity, ale grafy se pro transakční aktivity téměř nikdy nepoužívají. Důvod, proč jsem narazil na stat, o kterém si myslím, že je nejméně deset let, který říká, že většina společností má alespoň tři, ve skutečnosti to bylo 3,5, různé značky databází, pokud se podíváte na jejich inventář softwaru.
Skutečností však je, že většina společností standardizuje konkrétní databázi. Většina společností standardizovala buď SQL Server a Oracle jako dvě nejoblíbenější standardní databáze, pokud se vám líbí.Alternativy používají pouze ve výjimečných případech, kdy například získají softwarový balíček, který potřebuje jinou databázi, nebo jdou za některými z velkých datových analytických cílů, které vznikly.
Máme také, pokud se vám líbí, zásah Hadoopu. Hadoop se tak či onak stal více než souborovým systémem, ale ještě ne databází. Nicméně, to má SQL, který sedí přes jeho vrchol. Existují však důkazy o tom, že nahrazování relačních databází, které vydělalo srdce a mysl světa, není skutečně nahrazeno ani nikde jinde blízko. A důvodem je to, že tyto relační databáze trvalo dvacet let, ve skutečnosti déle než dvacet let, aby se staly tak dobrými, jaké jsou. A nevyvíjíte pouze dotazovací stroj nebo stroj SQL, který je skutečně výkonný ve velmi malém množství času. To se prostě nestalo.
A tak závěr tohoto snímku je, že databáze jsou strategické a vyvíjejí se, zlepšují se. A to je jistě případ Oracle a Microsoft SQL Server. Pravděpodobně, jen málo z vás si pamatuje zpět do doby, kdy se poprvé objevily databáze, ale já jsem byl, tehdy jsem byl chlapec. Původní myšlenka spočívala v tom, že by existovala jediná databáze a byla to koncepční myšlenka, která se nikdy nikdy nezakořenila. Došlo k pokusu IBM s AS / 400 vlastně mít databázový systém souborů, který ale také dominovat nebyl. Zbývá vám skutečnost, že databáze se přirozeně fragmentují. Ve skutečnosti máte samozřejmě více instancí. Existují problémy se škálovatelností. Databáze je měřítka pouze na určitou velikost, tato velikost se sice v průběhu let sice zvýšila, ale měly limity.
A vyskytly se problémy s pracovní zátěží, hlavní problém s pracovní zátěží spočívá v tom, že pracovní zátěž OLTP a velká pracovní zátěž dotazu prostě nejsou vzájemně kompatibilní. A nebylo možné postavit motor, který by to dokázal. Na co narazíme, což je zajímavé, nedávno jsem narazil na web, který měl přes tisíc různých instancí Oracle. Nemůžu si přesně vzpomenout, kolik DBA měli, ale pokud jste s nimi skutečně mluvili o tom, kolik z těchto databází bylo DBA skutečně monitorováno, bylo to něco jako deset. V podstatě používali databázi jako skříň a pouze do ní házeli data, protože přinejmenším jste měli schéma a bylo to organizovanější, než by kdy byl souborový systém, ale nikdo nedělal nic jiného než poskytnout výchozí konfiguraci a nastavit ji volný.
Nejsem si jistý, zda to byl dobrý nápad. Zní mi to bizarně, abych byl upřímný, protože podle mého názoru, kdykoli jsem pracoval s databázemi, databáze potřebovaly účast a vy jste tak či onak museli přesně vědět, co se tam děje. A hrozná spousta systémových závislostí znamená, že určité druhy úrovní služeb musí být bezpodmínečně splněny, jinak budete mít problémy.
Nedávno se hovořilo, narazil jsem na různé databáze, které tvrdí, že jsou samočinné. Ty, které jsou sloupcovými úložišti a které jsou nastaveny pro provoz dotazů, jsou do značné míry samoladěny, protože existují velmi dvě možnosti, které je třeba provést z hlediska indexů. Kromě této konkrétní oblasti však musí být databáze vyladěny. A je třeba je vyladit, některé relační databáze, hlavně proto, že se k připojení připojí obrovské množství transakcí. Spojení jsou drahé činnosti. Pokud nevložíte správné indexy na správné místo, připojí se, když to nepotřebují, zaberou nadměrné množství času.
Samočinné ladění databází v současné době existuje, ale existuje pouze v těch oblastech, kde je pracovní zátěž dobře známa. A moje zkušenost je taková, že většina společností zaměstnává jen velmi málo DBA, a to proto, že jsou drahé. A proto je lepší, pokud můžete střídat, co dělá DBA. Toto jsou činnosti DBA, jak jim rozumím. Dělají instalaci, konfiguraci a upgrade databází. Upgradování, mimochodem, není nutně triviální činností. Důvodem, proč byste upgradovali databázi, myslím, že pravidlo, se kterým jsem vždy pracoval, je nedotýkat se, pokud to funguje, a pokud se chystáte upgradovat databázi na nějakou konkrétní novou verzi, uděláte to v testovacím režimu nejprve a poté vše upgradujete. Stále pořád jednáte se stejnou verzí. Ale ve skutečnosti se na mnoha webech setkávám, to se neděje. Řekněme, že existuje dostatečná entropie. Správa licencí je problém, záleží na tom, jakou licenci máte. ETL a replikace dat.
Jedním z triků s databází je, pokud máte pracovní vytížení dotazů, které je třeba rozdělit, můžete vytvořit dvě instance a replikovat, a to se často děje tam, kde lidé používají repliku jako horkou zálohu, pokud je to třeba. Pak plánování úložiště a kapacity, to je součást činnosti DBA, protože samozřejmě rostou data a je třeba to sledovat. A pak musíte naplánovat různé aktualizace hardwaru nebo rozšíření hardwaru. Řešení problémů, které je pro většinu databází DBA bolestivé. Tam, kde se něco pokazí a záloha nefunguje přesně dokonale, pak si musí sbalit rukávy a dostat se dolů a vyzkoušet a obnovit věci ze souborů protokolu. To se stává mnohem častěji, než si myslím, dobře, vzpomínám si, že se to děje, ale já jsem byl mimo hru alespoň deset let, ale pamatuji si, že se to děje častěji, než byste očekávali. Sledování výkonu a vyladění je prostě druh bijícího srdce úlohy DBA. Existuje však také zabezpečení, pokud jde o správu přístupu, zálohování a obnovu, vytváření systémů testování softwaru, které bude rozumně paralelní s živým systémem. A celý obsah životního cyklu dat. To je podle mého názoru seznam pracovních míst DBA kromě všeho, co by se od nich mohlo požadovat. Provozní dynamika. V konečném důsledku je integrita dat a správa na úrovni služeb hlavní zodpovědností DBA. A obvykle jsou kritičtí. A to je vše, co musím říct. Jdu předat Dezovi.
Dez Blanchfield: Děkuji mnohokrát. Vezmu nás na trochu zábavné, neoficiální cesty kolem toho, proč celé téma, o kterém dnes jde, je kritičtější než kdy jindy. Není to tak dávno, co jsem se zapojil do projektu, kde jsme migrovali platformu státní správy, která byla použita pro registraci licencí a registraci vozidel a celou řadu věcí kolem tohoto tématu, z mainframové platformy Fujitsu provozující věc zvanou A + Addition, což je operační systém Solaris nebo jinými slovy Unix, provozující Oracle a vykonávající velmi dobrou práci. A ten názor byl takový, že tato věc stárne a je čas přesunout ji k něčemu jinému. Běhali jsme s Unixem na mainframe spoustu legrace a bylo to velmi stabilní a velmi bezpečné a napodiv platforma SDL a bylo to naprosto bleskové. Moudrost však byla na čase vystoupit z mainframe a pohnout se.
Tato významná výzva spočívá v mapování všech systémů a obchodní logiky a prostředí SQL pro databáze pod nimi a při pohledu na to, jak jsme pro ni chystali architekta a inženýra nový domov. Nakonec jsme si to vzali na jednu z těchto věcí, která je nyní stará několik let, ale na jeden z nejvyšších konců serverů Sun rack Starfire. A to jsou pravděpodobně některé z největších plechovek, které můžete na planetě koupit, a to vše, co žije v jedné velké krabici a na symetrickém multiprocesním serveru. V našem světě to byl systém střední třídy. Běžel unix a běžel Oracle nativně a pohled zněl: „Co by se mohlo pokazit?“ No, dopadlo to hodně.
Například v té době, o které nemluvíme už dávno, jsme museli projít velmi manuálním procesem, abychom zjistili, co bylo na platformě mainframe, a přinesli to. Zejména skutečné databázové prostředí a logiku SQL. Takže to byl názor, že se bude jednat o docela přímý přesun Oracle-to-Oracle, přesun z databáze do databáze; narazila by na veškerou obchodní logiku, většina obchodní logiky byla zapsána do zabudovaných dotazů a spouštěčů a jak těžké to mohlo být? Ale něco, co mělo trvat měsíce, nakonec trvalo ne úplně rok. Prostě fyzicky a ručně procházet každou část Unixu v prostředí sálových počítačů, zjistit, kde byly všechny databáze a kolik instancí a co běží na těchto instancích a bylo to netriviální cvičení a nakonec jsme to udělali třikrát, abychom se ujistili, že jsme všechno zachytili. Protože pokaždé, když jsme si mysleli, že jsme se kopali tak hluboko, jak jsme potřebovali, pod povrchem se ukázalo, že tam bylo víc.
Další výzvou, kterou jsme měli, bylo, jaké instance běží a v jakém stavu? Je to vývojové prostředí? Je to testovací prostředí? Je součástí integračního procesu? Je to systémová integrace? Je to UAT, uživatelské přejímací testování? Je to výroba? Je to prostředí DR? Protože skvělá věc na mainframech je, že si můžete vytvořit tato malá virtuální prostředí, která nyní všichni považujeme za samozřejmost, a pohybovat se po nich. A musíte se vypořádat s tím, kdo dělá vývoj a testování na úrovni výroby, nebo dělají produkční výrobu, jsou na tom skuteční uživatelé? Pamatujeme si, že tato věc vydává řidičské průkazy a registraci automobilů v reálném čase a věci, které opravdu záleží na životě lidí.
A spuštění této zálohy trvalo dlouhou dobu, takže jsme vlastně neměli okno údržby, abychom věc uvedli do režimu offline a zjistili, co se stalo. Nebylo nic takového jako přesměrování. Také jsme měli výzvu nejen zjistit, které instance byly spuštěny a kde a pro koho, ale pak jsme museli zjistit, jaké verze spuštěných instancí. A tady jsem skoro ztratil svůj děj. Když jsem si začal uvědomovat, že jsme měli dvě nebo tři verze produkčního prostředí, které prošly různými úrovněmi testování, a nástroje a systematické přístupy k tomu byly velmi malé. Doslova jsme se museli ponořit do kódu a do běžící instance a v některých případech riskujeme, že si něco vezmeme na chvilku offline. Dostali jsme se na konec celé věci, zmapovali jsme to a byl to velmi ruční postup, jak jsem řekl. Nakonec jsme provedli celý posun ETL, vyhodili ho z jednoho místa a přesunuli ho na jiné a celkově to fungovalo. A my jsme byli, dobře, je to funkční, jsme s tím velmi spokojeni.
Ale pak jsme narazili na řadu velmi vážných pevných cihel. Zjistili jsme zejména problémy s výkonem. A rozumné přemýšlení dne bylo, že jde o větší, lepší, rychlejší a těžší hardware, není důvod, proč by měl mít špatný výkon na úrovni aplikace na úrovni databáze, takže se podívejme jinde. Takže jsme síť dvakrát kompletně přepracovali. Každý router, každý přepínač, každý kabel, v některých případech jsme šli z Ethernetu na vlákno, upgradovali jsme software, opravili jsme, abyste získali názor. Síť jsme v podstatě přestavěli dvakrát a mysleli jsme si, že jde o problémy s výkonem. A vypadalo to, jako by to bylo. Prošli jsme různými bezpečnostními systémy, různými firewally. Opravili jsme operační systém. Přesunuli jsme věci z jedné výpočetní čepele na druhou. A strávili jsme značné množství času zkoumáním infrastruktury.
A pak jsme si uvědomili, že když jsme odpojili servery a spustili jsme na něm další aplikace, síť fungovala dobře. Začali jsme tedy táhnout operační systém od sebe. Stejný problém. Ale zajímavé, úroveň sítě a úroveň operačního systému, nástroje tam byly, ve skutečnosti bylo pro nás relativně snadné srovnávat a testovat a dokazovat, že každý z těchto kusů fungoval. Ale i poté, na platformě Solaris na střední úrovni na hardwarové platformě SPARC, tam nástroje prostě nebyly, abychom mohli diagnostikovat databázové prostředí. Víš, mapuješ, jestli jsme přinesli všechny instance. A tak jsme museli vlastně vytvářet vlastní nástroje a některé z nich psát a posadit se a ať už to bylo v rámci databázových nástrojů samotných v nativních skriptovacích jazycích, nebo zda se jednalo o sérii shell skriptů nebo v některých případech o spoustu C programů.
Nakonec jsme se ponořili do několika velmi zajímavých otázek, kde logika pod vrstvou SQL, samotné databázové stroje samotné, ukázalo se, že když bylo něco postaveno, zvláštní způsob, jak něco, co běželo na mainframové verzi Oracle, byl migrován do Solaris na SPARC verze Oracle neprodala okamžitě stejný výkon. Takže to byla pro nás v první řadě bolestná cesta, prostě to udělali a našli jsme to všechno, ale teď jsme to museli diagnostikovat v novém výrobním systému a tato věc opět vyletěla měsíční migraci na téměř rok. A prostě to přišlo k tomu, že jsme nástroje neměli. Běží kolem dělat věci, jako je pokus o mapování metadat.
V určitém okamžiku jsme se téměř rozhodli, že budeme potřebovat desku Ouija, protože to bude jednodušší způsob, jak jen náhodně ukázat a hrabat. Jednoduché věci, jako je zjistit, kdo měl přístup ke starým systémům a proč měli tento přístup. A kdo potřeboval přístup k novému a potvrzením, přiměl někoho, aby se odhlásil a potvrdil to a zmapoval to. Ani něco tak jednoduchého, jako je velikost databáze, nebylo na obou platformách konzistentní. Museli jsme vytvořit nástroj, abychom to mohli udělat, a udělat nějaké srovnání mezi tím, jak velká je databáze v tonáži, v hrubých megabajtech nebo terabajtech na systému A versus systému B. A ponořit se do podrobností kolem výkonu a prostředí výkonných. Opět musela stavět nové nástroje. Prostě pro nás neexistovala žádná otevřená police.
A tohle všechno z toho dostanete, když jsme se dostali do konce, kdy jsme věci rozběhli a dostali jsme je stabilní, každý kus byl velmi manuální proces, jediný způsob, jak bychom mohli něco zautomatizovat, bylo, kdybychom stavěli nový nástroj nebo nový skript. A kdybychom měli dnes dostupné nástroje, život by byl mnohem jednodušší a mnohem lepší. A na tomto projektu bychom ušetřili miliony. Domnívám se však, že o čem dnes mluvíme, je skutečnost, že nástroje jsou nyní k dispozici a život tak mnohem jednodušší. Mnoho nástrah stále zůstává. Zjištění databází, které jsou tam a jaké instance jsou spuštěny co. V jakém stavu jsou. Kolik jich běží? Proč běží. Zda běží dobře. Jsou zálohovány?
To vše jsou věci, které nyní můžeme v mnoha ohledech považovat za samozřejmost se správnými nástroji. Ale v této konkrétní anekdotě bylo období, jak jsem řekl, kde to bylo něco, o čem hodně z nás přišlo o hodně vlasů, pravděpodobně jsme si vzali patnáct let z našich životů a bědovali nad tím, že nástroje tam teď nebyly . A těším se, až se o tom od našeho hosta, Bulletta, dozví mnohem více. Takže s tím, Bullette, se chystám předat vám a těším se, až uslyším, jak jste tento problém vyřešili.
Bullett Manale: V pořádku. Zní dobře. Ericu, dovolte mi, abych se sem dostal se snímky a promluvil si trochu o tom, opravdu rychle, o společnosti Idera, než se dostaneme do samotného produktu. Stejně jako FYI je to druh portfolia různých produktů, které máme k dispozici.
Eric Kavanagh: Váš zvuk je trochu horký, takže pokud používáte náhlavní soupravu, stačí ji trochu vytáhnout.
Bullett Manale: Žádný problém. Je to lepší?
Eric Kavanagh: To je mnohem lepší. Vzít to pryč.
Bullett Manale: V pořádku. Dnes se tedy zaměříme na Správce zásob, který je zjevně v souladu s mnoha těmito tématy, o nichž diskutujeme. Chci vám jen trochu porozumět tomu, jak se tento produkt dostal tam, kde je. S naší produktovou řadou jsme začali každodenně hledat, máme nástroj pro sledování výkonu zvaný Diagnostic Manager. Máme nástroj Compliance Manager. Takže mnoho různých nástrojů v okolí serveru SQL a nevyhnutelně se vždy ptáme na licenční účely: „Jaký je počet případů, které v současné době spravujete ve své organizaci?“ A zajímavé bylo, že jsme na to nikdy nebyli schopni získat pevnou odpověď. Nezáleželo na tom, s kým jsi mluvil. Bylo to vždycky něco jako: „Myslíme si, že je to kolem tohoto čísla.“ Tyto věci vždycky přišly a pak bychom museli projít tímto procesem, abychom zjistili, co přesně to je, že oni chtěli udělit licenci, pokud jde o případy, které spravujeme.
Zjevně jsme rychle zjistili, že s mnoha DBA je spojena s bolestí. Je zřejmé, že jednou z věcí, za kterou jsou odpovědní, je to, že jsou za to odpovědní, protože jednou z věcí, které musí udělat, je starat se o licenční smlouvy, v našem případě se společnostmi Microsoft a SQL Server. Je zřejmé, že mají spoustu dalších různých oblastí, za které jsou zodpovědní, ale to je jedna z těch, která je druhem velké položky v podobě DBA, jaké jsou vaše obecné povinnosti. S tím jsme došli k závěru, že potřebujeme nástroj, který umožní DBA snadno pochopit toto číslo. Protože máte rozšíření SQL, pokud jej chcete nazvat, a to se děje z mnoha různých důvodů. Není asi tolik kontroly, kdo instaluje software a takové věci.
A nejhorší, co se může stát, je, že někdo dostane ruce do kopie serveru SQL, nainstaluje ho, začne s ním pracovat bez jakýchkoli znalostí jiných organizací nebo oddělení ve společnosti, a pak další věc, kterou znáte, možná data nejsou zálohována a ty druhy věcí, které by se mohly stát. Tam, kde nyní máte další problém, kde se vyskytují situace, kdy skutečně přijdete o kritická data, protože nevíte, že instance vůbec existuje.
Jednou z věcí, které jsme museli udělat, bylo říci, pojďme na to, najít jeho objev. A pak navíc umí organizovat a spravovat informace, které shromažďujeme, logickým způsobem, který dává smysl na základě toho, co podnik dělá. A pak z toho samozřejmě bude moci rozhodovat kolem těchto informací a být schopen dělat takové věci. Odtud se nástroj začal a odkud pochází. Mohu vám říci, že při pravidelném rozhovoru s agenturami DBA máme opravdu ten problém nevím, kolik případů má.
A je to vtipné, protože tento termín nedokáže řídit to, co nemůžete měřit, vždy přišel s výkonovými nástroji, které máme, jako je SQL Diagnostic Manager, ale opravdu nemůžete nic spravovat, pokud to nevíte „Jeho“ i tam na prvním místě. To je také druh velké části tohoto nástroje, který dokáže jen vědět, že tam je.
Nyní v této poznámce, když jsme hovořili s některými z větších organizací nebo podnikových obchodů se serverem SQL Server, bylo zajímavou věcí, kterou jsme našli se spoustou kluků, se kterými jsme hovořili, bylo to, že si během roku nastavili čas, kdy fyzicky šli z jednoho místa na druhé, aby se pokusili zjistit, jak ten počet vypadá. Dokážete si představit, že jako DBA dostáváte zaplaceno docela dobré množství peněz na fyzickou chůzi z jednoho stroje do druhého, což bylo překvapivě to, co bychom slyšeli od některých docela velkých společností, které jsem nezměnil. Ale je to jen zajímavý bod, který by mohl strávit dva týdny v roce prováděním těchto druhů cvičení, jen aby zjistil, zda jejich počet licencí je správný.
To vše souvisí s tímto nástrojem a jeho pomocí, ale způsob, jakým jsme se zabývali, byl díky schopnosti provádět zjišťování na základě řady charakteristik serveru SQL. A tak první otázka zní: na co poukazujete nebo na co se nejprve pokusíte podívat? Způsob, jakým jsme to udělali, spočíval v tom, že to uděláme podle rozsahu IP, nebo to můžeme udělat členstvím samotné domény, pokud jde o počítače, které jsou členy domény. To je způsob, jak jsme se touto částí zabývali, abychom mohli říci, že je to oblast, na kterou se chceme zaměřit z hlediska objevování.
A pak je druhá část založena na těchto charakteristikách, portech a dalších věcech, klíčích registru WMI a těchto druzích věcí, můžeme shromáždit a zjistit, že SQL je pravděpodobně spuštěn a nainstalován v této instanci nebo v tomto konkrétním prostředí. Je to zjevně mnohem lepší metoda než metoda tenisky nebo metoda tenisky. Skvělá věc je, že všechny tyto informace, které shromažďujeme o instanci, jsou uchovávány v úložišti a mohou se měnit podle změn prostředí. Nejde jen o: „Hej, je tu instance, tady je seznam, který jsme našli,“ ale o to, že DBA nebo osoba, která instance spravuje, jsou schopni určit, zda chtějí tuto součást inventáře učinit, a pak kdy není součástí inventáře, aby bylo možné tuto instanci vyřadit z provozu. A tak mají životní cyklus celého procesu instance serveru SQL Server v rámci nástroje opravdu snadno pochopitelný.
Jakmile jsme tyto případy objevili, co potom uděláme? Druhou věcí je spousta informací o této instanci, nechci to jít ručně a nechat si je vložit do tabulky nebo takových věcí. A to je další věc, která byla trochu zajímavá v rozhovoru s DBA o procesu inventarizace a licencování, je to, že byste byli překvapeni, s jakým počtem DBA jsem mluvil, když se jich zeptáte: „Jak udržujete své zásoby?“ A mluvíme s DBA, což je opravdu ironická část, že to udržují a sledují to ve statické tabulce všech věcí. Jak jsem řekl, je velmi ironické, když o tom přemýšlíte na chvíli. Ale to bylo v mnoha případech a stále je tomu tak u mnoha organizací, jak to zvládají. Jak to udržují. Jedná se o vzorovou kopii tabulky Excel, která se vznáší a musí být pravidelně aktualizována.
To jsou věci, které byly výzvou, a tak zaregistrováním této instance a jejím zařazením do soupisu to můžete udělat a vyzvednout informace. Můžete si nechat automatizovat, zda se stane součástí inventáře, verze, vydání, dalších věcí, které s ním můžete dělat, můžete ručně přidat možná tento seznam nebo tabulku Excel, kterou máte. Můžete jej importovat do tohoto nástroje s názvem SQL Inventory Manager. Pokud již máte počáteční případy, o kterých máte pocit, že jste si docela jistí, můžete tyto instance importovat a pak v rámci produktu vytvořit tuto část spravovaného inventáře. Jakmile máme instanci a jakmile víme, že je tam, tak se to stane, dobře, máme spoustu informací, které můžeme využít tím, že víme, že tam je tato instance, tím, že jdeme ven a shromažďujeme tyto informace.
A mnoho informací bude potřeba pro více než jen licenční účely. Mnohé z nich lze použít k tomu, abyste věděli, kde jsou věci, a mohli tyto informace prohledávat poté, co byly získány. Ale klíčovým materiálem je server, samotný hardware. Být schopen porozumět tomu, o jaký typ stroje jde, možná o modelu nebo výrobci, paměti, množství paměti, ať už se jedná o fyzický nebo virtuální stroj, a zejména o počtu fyzických soketů nebo jader a procesorů a těchto typech věcí.
Pokud jde o počet jader, zejména se serverem SQL Server, které vědí, jak dělají své licence, jsou výpočty podle jádra nyní v novějších verzích SQL, které se stávají opravdu důležitou součástí a není to nic, co máte jít ven a vlastně jít kopat. Jakmile je instance identifikována, můžeme tyto informace poskytnout, dostat je ven a nechat si je prohlédnout a porozumět jim a samozřejmě je mohou využít.
Další vrstva dolů je v instanci, která zjevně obsahuje mnoho různých instancí serveru SQL Server, ať už se jedná o standardní nebo podnikový, nebo dokonce expresní, nebo o bezplatnou verzi serveru SQL. Umět pochopit, jaké aplikace jsou k této instanci vázány, a to lze provést automaticky. Schopnost porozumět nastavení konfigurace a těmto druhům věcí a dalším informacím, které se vztahují k instanci samotného serveru SQL.
Poté přejdete do skutečné databáze a uvidíte konfigurační nastavení, množství místa svázaného s těmito daty, kde jsou umístěny, všechny tyto věci se automaticky naplní, a to je obrovský úspora času. A znovu, protože dynamicky vychází a denně identifikuje nové případy, je to živá věc, kterou máte, pokud jde o váš inventář. To je druh cíle produktu, aby to tak bylo, aby to bylo něco, co se dynamicky mění.
Jakmile se nám všechny tyto informace stanou dostupnými a my je můžeme všechna tato data stáhnout, pak má smysl začít v některých případech vytvářet svá vlastní metadata spojená s těmito případy a tato metadata lze vytvořit způsobem, který tento druh přizpůsobuje se způsobu, jakým podnikáte.
Takže pokud máte své instance seskupeny podle geografického umístění nebo podle vlastníků aplikace nebo od vlastníků DBA nebo cokoli, mohlo by to být z hlediska toho, jak chcete tyto instance seskupit, jak logicky chcete těmto případům dát smysl, a pak je laskavý ze dvou oblastí v nástroji, které vám tuto schopnost poskytnou.
Prvním je schopnost vytvořit značku instance nebo značku. Což v podstatě vytváří přidružení k serveru, instanci nebo databázi, takže můžete vytvářet pohledy a odpovídat na otázky, které se mohou objevit každý den, což vám opravdu pomůže zvládnout to, co máte, co spravujete a jak se chcete s těmito informacemi posunout vpřed.
Druhou věcí, kterou máme, je něco, co se nazývá soupisová pole nebo vlastní soupisová pole, a ty jsou specifičtější pro druhy přehledů informací, do kterých můžete procházet, například do databázové vrstvy, kterou bych se mohl rozhodnout přidat rozevírací seznam, který obsahuje všichni DBA a já mohu dát, kdo je odpovědný za tuto databázi v závislosti na daném typu situace nebo cokoli, podle toho, která databáze je u toho, kdo je zodpovědný za to, aby si to mohli vybrat, takže vím, že jsou to ti, kdo jsou za to zodpovědní a velmi snadno pouhým kopáním do inventáře.
Tyto informace se tak stávají velmi cennými, zejména pokud máte velké prostředí, protože vám to jen pomůže pochopit tyto informace a vědět, co máte a jak to děláte.
Dovolte mi tedy pokračovat a přejít na další snímek zde. Nyní vám ukážu, že se shromažďovaly všechny tyto informace, všechny tyto informace a data, která se shromažďovaly a používaly metadata, aby vám umožnily dělat mnohem jednodušší a rychlejší rozhodnutí, pokud jde o získání licencí u společnosti Microsoft v oblasti podnikového hromadného licencování nebo pojištění softwaru se společností Microsoft.
Díky tomu je pro vás opravdu snadné dělat to, aniž byste museli, musíte jít a dělat spoustu ručního sběru dat, spoustu ručního shromažďování těchto informací, což ve skutečnosti jen celkově z něj dělá mnohem lepší proces. Takže to je druh jednoho z mandátů produktu, někdy proto, aby DBA usnadnila tato rozhodnutí ohledně licencování.
Teď další věc, kterou jsme, jak jsme se bavili s DBA, objevili a naučili se opravdu rychle, je, že - a jeho druh návratu k tomu, co bylo diskutováno dříve - můžete mít 300 instancí ve vašem prostředí SQL Serveru, ale ve skutečnosti existuje jen možná podmnožina z těch, které jsou skutečně plně monitorovány a spravovány pomocí tradičního nástroje pro sledování výkonu.
Takže pokud jdete a opravdu si sednete s DBA a řeknete: „Podívejte, víme, že máte těchto 20 instancí nebo 10 instancí 300, které jsou sledovány pomocí tohoto nástroje, který je navržen tak, aby to monitoroval a vyhovoval vašim SOA a dostávat upozornění a všechny ty dobré věci, “také jsme zjistili, že pokud se zeptáte:„ Tak dobře, co těch dalších 280 případů, které máte? Záleží vám na nich? “A oni jim záleží na nich, ale oni prostě nechtějí nutně investovat do sledování těch na úrovni hloubky, kterou lze s těmito případy dosáhnout oproti těm 10 nebo 20 skutečně, opravdu kritickým instance produktu.
Druhou částí rovnice s tímto nástrojem je tedy to, že také pomáhá, pokud jde o to, že se můžete ujistit, že na základní úrovni jste krytí z hlediska zdraví například. Teď vám to neřekne, jestli máte mrtvý bod nebo kdo je obětí mrtvého bodu. Není to dostat se na tuto úroveň samotných relací a podrobností dotazů. Ale zároveň vám to ještě dá vědět, že hej servery dolů nebo hej, objem se zaplňuje, nebo musíte udělat zálohy databáze, to je druh důležité součásti toho, že je DBA.
Takže tyto věci jsou rozhodně stále důležité, a tak s tímto nástrojem udělal pro vás způsob, jak mít pro všechny opravdu kritické případy, které mají spoustu, hodně stojí za to, pokud k nim dojde, spoustu věcí, musíte to hned vědět. Mohou mít vyšší úroveň monitorování a jsou schopni dělat takové věci, zatímco s tím bude moci vyzvednout všechny nové případy, které jsou přidány do životního prostředí a ujistit se, že jsou zaúčtovány a také se ujistit, že vytvářejí se základní úrovně zdravotních kontrol.
Takže to je v kostce, o čem všichni správci importu zásob SQL. Nyní vám ukážu demonstraci. Než to uděláme, jen rychle vám ukážu, že se jedná o snímek architektury a abych to jen ukázal, instance SQL, které byly spravovány, můžeme objevit vše od SQL 2000 až po nové verze SQL.
Můžeme to udělat, aniž bychom museli kdykoli nasadit agenty na samotné instance. Děláme to prostřednictvím sběrné služby a jejím vycházením, shromažďováním těchto informací a umístěním do úložiště a poté z front-end konzoly webové služby Tomcat, abychom mohli s těmito daty pracovat a prohlížet si je. Takže jeho docela přímočará architektura.
Jdu do toho a přepojím se a skutečně nás vezmeme do samotného produktu, abyste pro něj získali pocit, pochopení toho, jak to funguje. Nejlepší způsob, jak toho dosáhnout, je nejprve vám představit samotné rozhraní v tomto druhu dashboardu, který se zde díval.
Nyní vidím počet případů, které mám pod správou, tolik. Ale také nemám celé datové centrum v zadní kapse. Takže mám asi šest případů, které zde vidíme. Teď, když jsem řekl: „Co udělám, je projít procesem objevování a ukázat, jak to bude fungovat.
První věc, kterou byste udělali, je v administrační sekci, kde můžete určit, jak chcete své instance objevovat. Tyto informace byste sem mohli vložit sem a znovu, což lze provést pomocí řady IP adres. Můžete ukázat na doménu nebo subdoménu a být schopen pouze na těch počítačích, které jsou členy této domény, aby mohly provádět tyto kontroly, které byste si mohli vybrat z řady různých druhů charakteristik, kdy bude spuštěna kontrola SQL.
Poté, co jste to udělali, a můžete nechat automatizovat běžet každý den jít a shromažďovat tato data. V případě potřeby byste to také mohli udělat ad hoc. Ale jakmile to začnete, ten proces objevování pak začnete vidět, když přejdete k zobrazení instancí zde. Máte kartu Discover a karta Discover nám ukáže ty případy, které byly nedávno objeveny. Takže v našem případě máme číslo. Co budu dělat a dělat, je jít a přidat ten, který se chystal použít jako příklad. Takže v tomto případě jde o příklad z Chicaga, že? Budu pokračovat a přidat tuto instanci do mého inventáře.
Dobře a bude to pro mě tady pár věcí. Jen se do toho pustím a uvidíte, že můžeme nastavit pověření. Moje pověření by tam měla být dobrá. Budu pokračovat a všimnete si, že k tomu mohu přiřadit vlastnictví, pokud chci. Mohu také určit umístění. Nyní lze přidat i samotné umístění, a to si bude pamatovat, že příště kolem, samozřejmě.
Ještě jednou k tomu mohu přidružit značky z hlediska metadat a toho, jak bychom chtěli tyto instance SQL, zejména tento, vložit do libovolných skupin, do kterých chceme vložit. Takže máme nějaké současné značky, populární značky , takže se můžeme podívat na spoustu různých značek, které jsem už možná zahrnul. Já jen některé z nich vyberu náhodně a můžeme je použít.
Takže teď, když jdu do toho a přidám to do inventáře. Nyní, když byl přidán, bychom nyní viděli, jak se zobrazuje pod tímto spravovaným pohledem, takže jej můžete vidět zde. Takže víte, že to je první krok a co jsem vám právě ukázal, byl způsob, jakým byste tyto případy přidávali hlavně při každodenním používání. V některých případech můžete říci, že víte, co když je to podnikové vydání serveru SQL, které chci automaticky přidat do svého inventáře? Nepotřebuji ručně jít a rozhodnout se to udělat.
Jocelyn: Budu vás rušit opravdu rychle. Neviděli jste své demo.
Bullett Manale: Nejsi?
Jocelyn: Ne.
Bullett Manale: To není dobré, uvidíme.
Eric Kavanagh: Pokud jdete do levého horního rohu, klikněte na start, klikněte na to.
Bullett Manale: Aha, dobře.
Eric Kavanagh: A nyní sdílejte obrazovku.
Bullett Manale: Promiň mi to. Jo.
Eric Kavanagh: To je v pořádku. Dobrý úlovek, producenti Jocelyn.
Bullett Manale: Dobře, je to lepší? Vidíš to hned teď?
Robin Bloor: Ano vskutku.
Bullett Manale: Dobře, tak vám můžeme jen tak projít, kde jsme byli opravdu rychle. Weve dostal objevené případy, které jsme měli dříve. Právě jsem přidal instanci v Chicagu, takže to, co vidíte, je nyní uvedeno. Všimněte si, že již vytáhl spoustu dalších informací. Pokud kliknu na samotnou instanci, začnete vidět všechny druhy informací, které již byly o této instanci shromážděny. Nyní je uveden seznam všech databází, které tam jsou. Vidíme členění databází podle velikosti a aktivity podle toho, které z nich mají největší velikost a aktivitu.
Ještě jednou vám můžeme hned oznámit, které aplikace vidíme spuštěné v této instanci na základě pracovního vytížení, které vidíme spuštěné v instanci. Takže je docela hezké to udělat automaticky. Nemusím jít dovnitř a svázat aplikaci s dopadem. Na základě toho, co viděli, to můžeme naplnit. Nyní, pokud chcete ručně přidat aplikaci, to absolutně můžete udělat. Ale je to jen pěkný způsob, jak ukázat přidružení instance k databázi nebo, bohužel, k aplikaci.
Také si všimnete, že na pravé straně obrazovky máme okamžité shrnutí a dole pod ním máme shrnutí serveru. Takže jsme zde hovořili o klíčových informacích o instancích, věděli jsme o verzi a ne jen o tom, SQL Server 2012, ale o skutečném čísle verze, které včetně a sděluje nám, jaké opravy hotfix jsou s tím spojeny, jaké aktualizace Service Pack jsou vázány. to může být velmi důležité vědět. Samozřejmě je důležitý požadavek na paměť. Všechno takhle, ať už je to seskupeno, všechny tyto informace, nemusím je vkládat - je již shromážděno a shromážděno a jakmile zjistíme, že jeho objevená instance bude součástí našeho inventáře.
Další věc, kterou zde uvidíte - a její ukázání - je to v tomto zobrazení instance. Máme tyto atributy, o kterých jsem mluvil dříve, vlastní atributy, které lze přidat. Můžeme tedy přidat otevřený druh polí, můžeme udělat ano / ne, pokud jde o miliardu druhů výběru. Můžeme dokonce udělat rozevírací seznamy. Můžete to udělat na instanci databáze nebo na úrovni serveru.
Pak, pokud se posuneme o něco dále, uvidíme všechny související informace o samotném serveru. Takže víte, že všechny tyto věci jsou očividně opravdu užitečné, protože vše, co jsme shromáždili a shromáždili, je pro nás, jakmile se rozhodneme, že se stane součástí našeho inventáře. Zde můžeme ukázat některé rozdíly, pokud jde o CPU, počet logických versus fyzických, kolik paměti. Takže jste opravdu na opravdu dobré a bohaté informace, aniž byste museli dělat spoustu práce.
Nyní, jak jsem řekl, je další část tohoto shromažďování těchto údajů na úrovni serveru. Pokud bychom dokonce jít dolů do databáze, můžeme vidět hodně z těchto věcí je rozdělena také pro nás.Takže pokud půjdu do svého úložiště shody, v tomto případě bych mohl říci, dobře víte, že se jedná o a, jedná se o databázi shody, ve které je úroveň souladu nebo regulační požadavek spojena a může to být, řekněme, Soulad se SOX nebo PCI. Mohu si tedy vybrat, které databáze mají s nimi spojenou shodu, kterou musím vyplnit, nebo se ujistit, že se udržuji z hlediska tohoto regulačního požadavku.
Ukázalo se tedy, že tento druh věcí je pro DBA velmi užitečný, protože existuje místo, kam mohou centrálně chodit, aby si všechna tato přidružená metadata ve svém prostředí snadno nechali a mohou, jak jsem řekl, přizpůsobit se svému podnikání tak, jak to dělají. , jako způsob, jakým podnikají. Takže pokud se podíváme na všechny ty věci, které jsme zatím viděli, máte zjevně docela dobrý přehled o instanci, pokud do toho vrtám.
Mohu také vyhledávat, takže jsem řekl, že se v tomto inventáři mohu podívat do tohoto úložiště shody. Pak uvidíte, že tyto věci mohu vyhledat a umět je identifikovat. Říkám to - nejsem si jistý, co tam moje tlačítka nefungují. Dobře. Uvidíme, zkusme to znovu. Tam jedeme. Takže bychom pak mohli vidět rozpis toho, kde vidíme cokoli, s čím byla shoda, a do toho můžu vrtat a vidět to také z tohoto hlediska. Takže máte opravdu rychlý a snadný způsob, jak se do těchto dat kopat.
Nyní, jak jsme již zmínili, máte mnoho různých způsobů, jak vytvořit metadata proti serveru instance a databázi. Druhou částí je, že je schopen využít to způsobem, jakým jste ho seskupili a způsobem, který jste k němu přidružili. Jdeme do zobrazení průzkumníka, můžeme to udělat jen. Můžeme říci, že chci udělat počet databází podle umístění. Počet databází v každém umístění prostředí, které podporuji. Nebo možná je to na základě vlastníka, který vlastní případy, které tam mám, pokud jde o možná počet instancí. Takže to uvidíme. Takže máte opravdu dobrý a snadný způsob, jak pro vás tyto obrázky namalovat na základě jakékoli otázky, na kterou se snažíte odpovědět.
Poté, co máte tyto informace vytvořené tak, jak jste chtěli, můžeme je exportovat do formátu PDF nebo do různých formátů, abychom je mohli využít a našim kolegům nebo udělat, co tam potřebujeme. Takže víte, že byste mohli dělat takové věci. Pojďme zpět - ztratil jsem to? Tam jedeme. Dobře, tak doufejme, že to dává smysl, pokud jde o to, o čem jsem zatím mluvil. Nyní, když se data, která shromáždili, je toto vše očividně skutečně důležité z mnoha důvodů - licencování a podobně.
Poslední věc, kterou je třeba zmínit, je, že jdeme do této administrační sekce. Zde také můžete nakonfigurovat vaše a vaše upozornění a být schopni zajistit, že pro věci, o kterých byste chtěli opravdu vědět, můžete tyto věci také nastavit. Můžeme tedy nastavit upozornění, můžeme nastavit schopnost zapnout určité věci a vypnout určité věci a poté být schopni určit, kdo by je měl přijímat, a přihlásit se k odběru těchto upozornění můžeme spojit, koho bychom chtěli být, kdo by chtěl vědět o těchto věcech.
Ale jak jsem již řekl dříve, je to opravdu pěkný způsob, jak to udělat, přinejmenším mít naprostý klid vědět o všech instancích SQL vašeho podniku - co to je, co máte, a také se ujistit, že jeho chod běží optimálně, i když nemáte, Společnost havent se rozhodla provést investici do nástroje pro sledování výkonu s vysokým dopadem na správu této instance. Toto vás pokryje, protože je to velmi cenově dostupný způsob, jak jít ven a pro mnoho případů bude moci tyto zásoby provádět a být schopen udělat druh velmi širokého druhu obecné úrovně monitorování, aby se ujistil, že dostal ten klid a věděl, co se děje.
Doufejme, že to dává smysl ve způsobu, jakým to popsal a ukázal vám. Myslím, že z tohoto hlediska mohu pokračovat a předat ho zpět a můžeme si ještě promluvit.
Eric Kavanagh: To zní skvěle. Takže Robine? Dez? Nějaké otázky?
Robin Bloor: No, mám otázky. Je velmi zajímavé to sledovat, myslím tím, že jsem chtěl jen učinit poznámku, že skoro všude, kde jsem byl, nejen mezi DBA, ale mezi kluky v síti, mezi kluky z úložiště, mezi kluky z oblasti správy virtuálních strojů, jsou všichni zpracování mimo tabulky.
Eric Kavanagh: To je správně.
Dez Blanchfield: Víte, že to je, víte, že to je v pořádku, dokud se čísla nezačnou pohybovat. Když se čísla začnou pohybovat, víte, že se dostanou do problémů. Takže na otázku, nyní se zajímám, a vím, že bude pro vás obtížné odpovědět, ale co, pokud jdete na místo, kde tam nemají nic podobného, pro práci s tabulkami, takže můžeme předpokládat, že DBA jsou velmi chytrí kluci a tak dále a tak dále, jaký druh návratnosti investic si myslíte, že byste získali implementací něčeho takového? Máte k tomu nějaké čísla nebo nějaké pokyny k tomu?
Bullett Manale: Je těžké říci, co je ROI, protože prostředí se bude trochu lišit. Je zřejmé, že čím větší je podnik, tím větší prostředí, samozřejmě čím více bude pravděpodobně návratnost investic, pokud nyní používají manuální metody, víte.
Vím, že jsem mluvil s řadou - když říkám velké organizace na tisíce a tisíce zaměstnanců a také pravděpodobně tisíce případů - kde mám lidi, kde jim to ukážu a říkají, že to bude trvat dva týdny mého času zpět. Ive mi to řekl více než jednou. Těžko říci, co se týče skutečné částky dolaru z nákupu, ale je to značné, když máte prostředí.
Jak jsem řekl, je to celkem konzistentní, jeho lidé, většina lidí, se kterými mluvím, uchovávají tyto věci v tabulce. Takže je to jen velmi subjektivní věc, protože každé prostředí, trochu jiné, co se týče způsobu udělování licencí a způsobu udělování licencí společnosti Microsoft, je další součástí toho, co je faktorem. Ale pokud musí každý rok nebo každé tři roky dělat pravá upoutávky, myslím, že tři roky na maximum pro Microsoft, že budou chtít, abyste to provedli alespoň jednou za tři roky.
Pak víte, že je to značné a že to víte, je to jen něco, co je mnohem snazší. Vzhledem k tomu, že se jedná o dynamickou věc, která se neustále mění, dává to také trochu větší platnost, pokud jde o to, na co se zaměřujete, pokud jde o verše, takže tabulku jsme skutečně aktualizovali za šest měsíců nebo rok. Jak často tedy aktualizujete tabulku, je další otázkou, abychom pochopili, že odpověď na návratnost investic.
Dez Blanchfield: Jo, myslím, licencování SQL, licencování je jen zatracená noční můra, ale je to zvláště noční můra, protože licencování není stejné mezi společnostmi Microsoft a Oracle a kdokoli jiný, kdo tam dělá databázové věci. Pokud skutečně uchováváte věci v tabulkách, které mají tendenci být tím, co se ve skutečnosti děje, víte, že čas na udělení licence nastane dříve, než si to skutečně uvědomíte, a ve skutečnosti nemáte data, pokud víte, co tím myslím, snadno se k těmto informacím dostanete.
Každopádně, jak zdůrazňujete, jeho dynamika a já osobně netuším, protože Ive nikdy nemusela jednat se společností Microsoft, takže nemám tušení, ale pravděpodobně existují databáze, které lidé docela často stahují testovací data, testovací prostředí a já bych hádejte, že se jedná o trn na vaší straně, pokud uděláte licenci. Jsi to ty-?
Bullett Manale: Ano, jo. Je tomu tak proto, že mnohokrát se na tyto věci zapomíná a pak se snažíme přijít na to, dobře, dobře, dobře jsme dostali základní licenci, že musíme zjistit počet jader pro každý z těchto případů a já nevím, pokud jde o standardy toho, co kupujete hardware, je dobré si také koupit docela dobrý hardware, pak pokud nevyužíváte tento hardware tak, jak by měl být využit, pak přeplatíte, protože jste platili za základní ceny, když tyto jádra nejsou využívána tak, že se stává problémem.
Každá verze SQL má tedy odlišný způsob uplatňování licencí, což je dokonce trochu matoucí. Máte tedy nějaké problémy a to je velká část toho, proč jsou tyto informace velmi užitečné, protože vám můžeme sdělit, která verze je, můžeme vám samozřejmě sdělit počet jader, která máte, pokud jsou starší verze SQL to bylo stanovení ceny za soket, můžeme to samozřejmě také ukázat. Takže to prostě dělá to mnohem jednodušší rutinou, kterou musíte projít, když přijde čas na to, aby se věci opravily.
Dez Blanchfield: Jedna věc, která mi přijde na mysl, je mi líto -
Robin Bloor: Je to v pořádku, jdete do Dezu, chtěl jsem se zeptat na možná irelevantní otázku.
Dez Blanchfield: Jen něco opravdu rychle, když jste na toto téma nyní - viděli jsme mnohem více přijetí cloudových prostředí a pokud by to běhali uvnitř našeho vlastního datového centra, uvnitř našeho vlastního prostředí, procházejí se kolem a nalézají, objevování věcí je relativně jednoduché .
Jak se máme vyrovnat se scénářem, kdy bychom mohli mít tři datové sady, dva mraky a viditelnost v těchto prostředích, je brána firewall a často je datová sada na konci kanálu nebo VPN. Je tam něco udělat, aby se objevil z front-endu, nebo musíme, začít otevírat porty, abychom mohli skenovat v určitých prostředích mezi jakýmsi cloudem a mimo prostory, kde tyto platformy běží?
Bullett Manale: Ano, bylo by to s ohledem na přístavy. Takže, bohužel bych si přál, abych mohl říci, že to proběhne ve všech těchto prostředích, ale existuje několik různých možností, které byste s tím mohli udělat. Je zřejmé, že pokud děláte něco jako Amazon EC2, vše, co byste opravdu potřebovali, je přístup do tohoto prostředí prostřednictvím vašeho připojení, za předpokladu, že vaše porty jsou otevřené, a pak je možné určit vaše IP adresy nebo vaši doménu, která je s nimi spojena, a může začít sbírání a začít objevovat.
Takže v těch typech prostředí to opravdu není problém; jeho konkrétnější typy prostředí, jako je RDS, a kde právě získáváte samotnou databázi, kde bude trochu náročnější vidět a objevovat tento typ informací.
Dez Blanchfield: Z toho tedy vyplývá, že existuje databáze a databáze. Tak například staré dobré časy, kdy jsem měl velmi, velmi velký databázový stroj, jako je anekdota, kterou jsem sdílel na frontě, kde je jen jedna obrovská platforma a vše, co dělá, je poskytnout databázi. V dnešní době jsou databáze zabudovány do všeho, ve skutečnosti je to, že dva nebo tři z nich právě běží v mém telefonu za aplikacemi.
Jaké jsou výzvy, se kterými se setkáváte se scénáři, kdy máte prostředí přicházející z prostředí Lotus Notes, s aplikacemi za nimi, SharePoint s databází na různých internetu atd.? V podstatě vše je poháněno databází na zadní straně. S jakými věcmi se setkáváte a jaké výzvy vidíte, když se lidé snaží jen zmapovat tyto druhy světů a co pro ně váš nástroj dělá?
Bullett Manale: No, myslím, že jde o to, že to, co jste řekl - všechno nyní potřebuje databázi, takže mnohokrát je to hodně pravděpodobně, je tu spousta databází, které jsou zavedeny do prostředí, které samotná DBA není ani vyrobena vědomi, protože není příliš těžké nainstalovat SQL server do prostředí, obecně řečeno.
Tento nástroj také identifikuje věci, jako jsou například expresní databáze, tedy bezplatné verze serveru SQL. Je dost vtipné, že když se chystáte mluvit s DBA, znovu nedostanete konzistentní odpověď, pokud jde o to, že jim záleží na bezplatných databázích, které jsou venku. Mnoho z těchto aplikací, o kterých mluvíte, bude používat bezplatnou verzi databáze. Samotné organizace však budou mít jiný přístup, pokud jde o to, kdo je za tuto databázi zodpovědný, v závislosti na tom, s kým mluvíte.
Na některé DBA, se kterými mluvím, si pomyslím, že jsem byl naposledy v SQL Server PASS, což je v Seattlu. Zeptáte se otázky „Zajímají vás vaše expresní databáze?“ A bylo to asi padesát padesát. Někteří lidé se o nich chtěli dozvědět jako DBA, protože se cítili, jako by byli součástí jejich povinností, dokonce i těch, které vyjádřily databáze, které by mohly stále obsahovat kritické informace; stále musí projít procesem zálohování a stále se musí ujistit, že všechny věci na nich pracují ze zdravotního hlediska. Ale jen vědět, že existují, je stejně důležité, ne-li důležitější.
Zatímco druhá polovina lidí je: „Hej, nebyly za tyto databáze zodpovědné a cokoli, co na ně vloží, je na pozoru před osobou, která je nainstalovala.“ Ale celkově bych řekl, že to, co jste řekl, všechno hezké v dnešní době je k tomu často připojena aplikace, která pouze přispívá více ke složitosti a nejasnostem s nutností inventarizovat tyto informace.
Dez Blanchfield: Ano, viděl jsem některé, vládní weby jsou pravděpodobně moje nejoblíbenější, ale častěji než ne Vidím nyní v podnikových prostředích, kde je to, jak jste řekl, že lidé zapomenou i na ně, když instalují něco jako SharePoint nebo jako samo výměna, takže víte že přicházejí s bezplatnou verzí, která je právě zabudována, protože chtějí, víte, nainstalujte ji rychle a nemusíte se bát nutnosti licencovat.
Pak se to zvětšuje a pak si někdo začne stěžovat na výkon a je to jako: „Je to jen váš starý server, vaše úložiště, síť, cokoli,“ a potom se zavolá DBA a jsou jako: „No, právě jste vtiskl všechno do této bezplatné verze databáze, což není to, co potřebujete k provedení této velké. “
Zejména když máte scénáře, jako je Project Manager a Office, běží stovky, ne-li tisíce projektů napříč velkým podnikem nebo firmou a oni používají SharePoint s Microsoft Project Serverem a do své databáze ukládají všechny své PMO. Ale na přední straně se jim líbí, je to jen webové rozhraní. Ale opravdu existuje databáze a databáze.
Bullett Manale: Ano.
Dez Blanchfield: Tak jaké jsou, jeden z prvních kroků, které tu lidé podle mě mají, je pár otázek, které bychom mohli chtít přinést od publika. Jednou z prvních otázek je, kde lidé začínají? Jaký je jejich první přirozený krok: „Dobře, musíme udělat nějakou verzi Anonymní alkoholici?“
Weve dostal více databází, než víme, co dělat. Jak vypadá od nich přirozený krok: „Dobře, musíme si to nechat ujít a začít běžet?“ Jdou prostě do chlazené krůty nebo později opravdu potřebují začít malé a jen získat nějaké zkušenosti s mapováním jejich prostředí ?
Bullett Manale: Myslím, že to řekl, že musí zmapovat prostředí. Společnost Microsoft nyní nabízí bezplatný nástroj, nástroj Microsoft Assessment Planning Tool, který je zdarma, ale je statický. Děláte objev a to je vše. Získáte seznam věcí, které jsou tam venku. Vzali jsme to a řekl pohled umožňuje udělat krok dále umožňuje objevovat, umožňuje najít to, co je tam a nechá jej umístit do úložiště a umožňuje, aby byl dynamický a můžeme jej do něj přidávat, odstraňovat z něj.
Ale celkově největším prvním krokem je myslím, že jen zjistit, udělat objev. Ať už to znamená stažení zkušebního produktu na zkušební verzi, můžete si jej stáhnout a vyzkoušet po dobu 14 dní a můžete poukázat na své prostředí a provést sbírku.
Pokud již máte tabulku se spoustou těchto informací, že jste si jisti, že tyto informace jsou správné, máte také možnost importovat do CSV tuto tabulku se všemi těmito informacemi a udělat z toho část toho, co vy už mám. Ale co se týče vymýšlení toho, co nevíte, jediným způsobem, jak toho dosáhnout, je ručně jít ven, udělat to nebo mít nástroj, který hledá takový druh věcí, jako je tento. To je rozhodnutí, které budete muset v určitém okamžiku učinit, je: „Snažím se tento objev automatizovat, nebo alespoň získat dobrý základ toho, co tam venku, a pak se možná obávat některých výjimek?“ Ale nejvíce část, kterou pravděpodobně potřebujete nástroj.
Dez Blanchfield: Takže jen rychle. Kam chodí lidé na to začít? Zasáhli váš web? Jak se k tomu dostanou a jak rychle začít?
Bullett Manale: Pokud jdete na Ideru, I-D-E-R-A.com, uvidíte, a ve skutečnosti to dokážu rychle ukázat. Na webu Idera půjdete k produktům, přejděte do správce inventáře. Zde uvidíte odkaz ke stažení. Jednoduše určujete, kterou sestavu chcete nainstalovat na 64 nebo 32 bitů, a to vás povede a můžete začít objevovat odtamtud.
Robin Bloor: Fantastická a skvělá, skvělá prezentace, moc vám děkuji.
Bullett Manale: Děkuju.
Eric Kavanagh: Máme několik otázek od publika a dobře ty pro vás, protože se dnes musíme tvrdě zastavit, ale Bullett opět skvělá práce na demu, skvělá práce našeho producenta chytající, že se to neprojevuje.
Bullett Manale: Promiň mi to.
Eric Kavanagh: Ne, tohle je dobrá věc, dáváte viditelnost do jádra podnikání, že? Protože podnik provozuje data a poskytuje viditelnost až k jádru. Takže žádné další vlnité věci; Nyní můžete ve skutečnosti ukázat na věci a dostat to vyřešené. Tak dobré pro vás.
Bullett Manale: Děkuju.
Robin Bloor: Ale bylo skvělé vidět to žít také mimochodem, dobře odvedené.
Eric Kavanagh: Jo, budeme toto webové vysílání archivovat pro pozdější prohlížení a pak ho doufáme, že asi za hodinu nebo dvě se původní archiv zdvihne někdy o něco déle, ale určitě to dejte vědět lidem. S tím se tě necháme jít, lidi. Ještě jednou děkuji za účast v Briefing Room, ve skutečnosti byly Hot Technologies. Příště vás chci dohnat. Dávejte pozor, sbohem.