Od zaměstnanců Techopedia, 30. listopadu 2016
Take away : Host Eric Kavanagh spolu s Dr. Robin Bloor, Dez Blanchfield a IDERA Bullett Manale diskutují o otázkách a jak jejich účinnost může mít dalekosáhlé účinky.
Momentálně nejste přihlášeni. Chcete-li zobrazit video, přihlaste se nebo se zaregistrujte.
Eric Kavanagh: Dámy a pánové, znovu pozdravte a vítáme vás. Ve středu jsou čtyři hodiny východního času a v těchto dnech to znamená, že je čas na Hot Technologies! Ano vskutku. Dnes mluvíme o skvělých věcech. Samozřejmě, jsem váš hostitel, Eric Kavanagh. Název dnešní show je „Klíč k efektivní analýze: rychle se vracející dotazy.“ Správně, lidi, všichni se chceme rychle. Kdo nechce rychle? Je tu snímek o vás, a dost o mně. Zasáhni mě na Twitteru, @eric_kavanagh. Rád se s vámi spojím a budu se bavit v sociálních médiích. Může to být zábava, prostě nemluvit o politice.
Rok je horký. Letos jsme hovořili o různých analytických otázkách a jedno téma pro dnešek je opravdu klíčové pro dokončení práce. Pamatuji si, že asi před pěti nebo šesti lety jsem poprvé slyšel, jak někdo používá výraz „bavte se s vašimi daty“, a přestože to může znít trochu kýčovitě, jde o to, že pokud nemůžete mít iterační zážitek s vaše data, pokud nemůžete rychle upravovat své dotazy, posílat nové dotazy, rychle získávat odpovědi, pak s vašimi daty neprovádíte konverzaci a celý analytický proces je zkrácen. To není dobré.
Když konverzujete s vašimi údaji, znamená to, že jste schopni jít tam a zpět, a podle mého názoru to je, když najdete vhled. Protože velmi zřídka přijdete s perfektním dotazem poprvé. Pokud nejste analytikem Mozartu - a jsem si jistý, že člověk je venku - budete muset strávit nějaký čas úpravou, přidáním nějaké dimenze a pokusem se doladit, co to je, co hledáte .
Protože opět nejedná se o nesmírně chytrá prostředí, se kterými se ve světě analytiky zabýváme; jednáme o velmi těžkých prostředích a velmi složitých a vícerozměrných prostředích. Celá myšlenka dnešního webového vysílání je tedy hovořit o tom, jak umožnit tento druh iterační interakce s vašimi daty.
Máme tři moderátory. Samozřejmě v Hot Technologies máme na rozdíl od Briefing Room dva analytiky; každý z nich si vezme první, pak přijde host, přednáší svou prezentaci a my máme jakýsi kulatý stůl. A vy, naše publikum, v tom můžete hrát velkou roli. Prosím nebuďte stydliví; pošlete své dotazy kdykoli. Pokud je to možné, použijte panel Otázky a odpovědi, jinak je panel chatu v pořádku; Během show se pokusím sledovat oba. A zaznamenáváme je, takže pokud vám něco chybí nebo se o ně chcete podělit se svými kolegy, vraťte se později. Zveřejňujeme je na Techopedia.com a také na InsideAnalysis.com.
A s tím přivedu inteligentní lidi. Jdu to předat Dr. Robin Bloor. Dovolte mi, abych mu dal klíče, změnil přednášejícího, a vy jdete. Robine, vezmi to pryč.
Robin Bloor: Dobře. Díky za toto intro. Asi před měsícem a půl jsem měl chat s vývojářem, který je vlastně DBA. Není to vlastně DBA - byl to DBA v konkrétní společnosti a byl to jediný člověk, který dokázal tyto dotazy skutečně provést. Ale udělal z toho špatně, protože je to opravdu, je to vlastně docela chytrý vývojář. Takže odešel.
A musí pro ně každý měsíc udělat pár dní, protože nemohli najít nikoho, kdo by zaujal jeho místo, a nemají tušení, co databáze dělá nebo jak ji naladit. A já jsem o tom trochu přemýšlel, a prostě, víte, oni vlastně nemají IT oddělení, ale ten chlap jim pomáhal. Ve skutečnosti to byla práce DBA, kterou dělal většinu času.
Pro sofistikované databáze - Oracle, SQL Server, DB2, všechny ty velké, drahé - ladění databází je náročná práce. Je to také bezpečná práce. A důvodem je, že to je to, že se jedná o měnící se krajinu. Trochu to projdu. Víte, relační databáze - obvykle je to velký obrázek, relační databáze stále dominují v popularitě. Pravděpodobně budou dominovat po dlouhou dobu. Ano, existují další databáze, které nyní získají více vysílacího času, ale víte, když se skutečně podíváte na to, co se tam děje, Oracle dělá většinu z toho, Microsoft SQL Server je druhý a v cloudu se dějí různé věci, které může však způsobit výzvu. Jsou to velcí obři ve hře. A jsou to databáze, které můžete použít jak pro OLTP, tak i pro pracovní zatížení datového skladu. Alternativy se běžně používají hlavně v analytických prostředích, a pak je obvykle určeno údaji, proč bychom si vybrali spíše než relační. Většinou to tak není.
Společnosti mají tendenci standardizovat se v jediné databázi. Nedávno jsem narazil na společnost, která měla více než 5 000 instancí Oracle. A tak trochu, s osobou, se kterou jsem mluvil z té společnosti, jsem se jich zeptal na DBA. Řekli, že měli asi 10 DBA a bylo pečováno o 30 databází. A zbytek byl Oracle právě používán jako konečný systém. Na aplikace z aplikací, které je používaly, byl kladen velmi malý důraz. Ale to mě prostě ohromilo - 5 000 instancí Oracle.
A mimochodem, měli licenci Oracle na majetek. No, víte, firemní licence, samozřejmě. Ale také měli jiné databáze, protože někdy, víte, aplikace přicházejí s preferovanou databází. Nebylo to, jako by Oracle byla jediná věc. A stojí za zmínku, že ani Hadoop, ani Spark nejsou vlastně databáze, a bude to dlouho, než získají to, co považuji za pravidlo databáze. Dobré pro datová spojení, samozřejmě.
S aktivitami DBA - pravděpodobně Bullett o tom může říct mnohem víc než já - ale já jimi prostě projdu. Na tohle mám sklon myslet, víš, co dělá DBA. Instalují, konfigurují, upgradují, spravují licence. Dělají hodně ETL a replikační práce tak či onak. Dělají plánování skladování a kapacity. Dělají řešení problémů nebo jsou součástí týmu pro odstraňování problémů. Sledování a ladění výkonu je do značné míry jejich činností, ale všechny tyto další věci, to není malé, víte. Za bezpečnost jsou zodpovědní za zálohování a obnovu. Měly by být zapojeny do systémů testování softwaru a mohly by být zapojeny do životního cyklu dat.
Výkon. Když jsem bývala jedním z nich. Když jsem běžel a ladil databáze, tak jsem tomu rozuměl, víš? Je tu CPU a v dnešní době je CPU docela normálně nečinné, protože by to byl jeden z dalších dvou nebo th - No, problém by způsoboval jeden z dalších úzkých míst. Paměť, mlácení a fragmentace nebo disk nebo saturace diskových I / O, někdy režijní náklady na síť, pokud běžíte ve více uzlech sítě a ve skutečnosti by se vám pravděpodobně mohlo stát nějaké zamykání.
Ale to byl svět, jak jsem to viděl. Nedávno jsem se podíval na Oracle a na počet ladících parametrů, které jsou v Oracle. Bylo to přes 300. Víte, a pokud o tom skutečně přemýšlíte, DBA, která skutečně ví, co dělá, musí mít nějakou představu o tom, proč byste se někdy s některým z nich pohrávali. Takže, víte, je to složitá práce a tím je to komplikovanější.
Víte, právě teď máme CPU, ale máte … CPU už existovaly, GPU na CPU nebo s FPGA na CPU. Takže se děje kříženec toho, co se vlastně děje na CPU. CPU se stala multicore už dávno; vlastně jsem už nehledal databáze, když se to stalo. Nemám ponětí, co to ve skutečnosti znamená, teď, když o tom přemýšlím.
Máme, víte, 3D Xpoint a IBM PCM přicházejí jako další vrstva paměti a máme SSD, ale víte, že nahrazují rotující rez. Ale SSD se mohou lišit v rychlosti. S tolika, můžete mít paralelní přístup, a to jim dělá neuvěřitelně rychle - v blízkosti rychlosti RAM. A máte všechny paralelní hardwarové architektury.
A to je vše, víte, náklady klesají, což je opravdu pěkná věc, ale všechno to dělá - víte, pokud vezmete další vydání databáze a poté ji začnete implementovat na počítačích, dokonce i některé toto jste vlastně ztratili jakýkoli pocit, který byste mohli mít pro způsob, jakým se data chovají, protože latence jsou prostě velmi, velmi odlišné. A tady, víte, máte spíše čtyři vrstvy než tři vrstvy úložiště.
Problémy s databází. Získáte entropii databáze - množení případů je velmi běžné. Databáze se používají jako skříně, což je ten příklad, který jsem ve skutečnosti uvedl. Velmi málo databází je samoladěných a ty, které tvrdí, že jsou samočinně laděny, ve skutečnosti nejsou tak dobré, víte. Druhá věc je, že jen velmi málo databází je správně naladěno. Je to těžká práce, schopnost vyrovnat pracovní zatížení. Myslím, že když přemýšlíte o databázi, co může databáze dělat za 24 hodin, pracovní zátěž může být velmi, velmi odlišná. Databáze musí mít obzvláště pravdivý datový sklad.
A proto, vyladění, které není triviální záležitostí, víte, protože to, co děláte, jsou parametry vyladění, které musely vyhovět celé škále pracovních zatížení v daném časovém bodě. Je to v podstatě těžká práce. A SQL musí být vyladěn zejména pro SQL JOINs. Víte, mohou být extrémně náročné na zdroje. A pokud má databáze zhmotněné pohledy, abych byl upřímný, měli byste prozkoumat jejich použití, protože vše zrychlí neuvěřitelně rychle. A to vyžaduje někoho, kdo rozumí pracovní zátěži a chápe provoz SQL atd. A tak dále.
A většina společností zaměstnává jen velmi málo DBA - velmi drahé. Znal jsem docela velké společnosti, jako jsou tři kluci, víte, s obrovským počtem případů. Opravdu, stojí to hodně, je to těžká práce, pokud jde o složitost. Potřebují nástroje.
A myslím, že to je vše, co musím říct. Jo, jo. Podívejme se na Deza, uvidíme, co musí Dez říct.
Dez Blanchfield: Děkuji, Robine. Toto je masivní téma. Budu se držet věcí, o kterých si myslím, že jsou účinnými každodenními výzvami, kterým čelíme. Vzhledem k tomu, přiznejme si to, existuje celá knihovna knih o tomto tématu. Kdo nešel do technického knihkupectví a nenašel zdi a stěny knih napsané pouze na obecné téma výkonu databáze, ladění databáze a monitorování. A někdy je to skvělý způsob, jak zabít čas.
Obecné téma: získávání dotazů na výkon. Existuje celá řada různých částí organizace, které toto téma potí - na vaší úrovni koncového uživatele, podle mých zkušeností, lidé prostě zažívají výkon, že věci jsou pomalé. Spinning kola se chvilku vrátí, aby se dotazy vrátily. Na opačném konci spektra máte lidi v oblasti infrastruktury a síťového a úložného inženýrství, kteří jsou zbiti odborníky na databázi, protože věci nefungují tak, jak očekávají. A podle mých zkušeností je to velmi široké spektrum věcí, které mohou ovlivnit náš život v tomto spektru.
Pokud přemýšlíte o tom, od fyzického nahoru, víte jen o prostoru počítače. Je to paměť, víš, RAM, jestli máš rád - místo na disku, síť a všechny kousky kolem. V tomto prostoru máme, víte, to ukládá myšlenku, že, řekněme, že je lepší použít surový disk nebo JBOD a jen, víte, co nejrychleji stoupejte a nechte disk databáze třídí vrstvu ochrany dat. Jiní lidé jsou velkými fanoušky RAID, redundantní řady levných disků a mají různé náboženské zkušenosti s RAID 0, 1, 3, někdy 5 a 6 různými typy pruhování nebo replikace na disku v případě selhání pevného disku. I na úrovni úložiště a na technické úrovni máme stále lidi, kteří mají různé názory a zkušenosti ohledně výkonu, na typech úložiště.
Ať už se jedná o přímo připojené disky a samotné servery, nebo zda je propojeno prostřednictvím optického kanálu se sítí úložných prostorů nějaké formy, ať už je to úložiště připojené k serveru někde přes iSCSI nebo je to například Ethernet. A to je ještě před tím, než se opravdu dostanete k databázové vrstvě, kde, jak víte, nejrůznější věci, které považujeme za samozřejmé - víte, jen udržujte to, jak Eric naznačil, víte, co nazýváme konverzací s vašimi údaji . Jen abychom byli schopni identifikovat vzorce a smysluplné vzorce, o kterých si myslíme, že se můžeme začít potápět a hledat problémy s výkonem.
A je to velmi široké téma, takže se chystám ponořit do dvou oblastí, kde podle mých zkušeností čas a energie a vynaložené úsilí získají nějaké dobré výnosy. Dovolte mi tedy rychle přejít na první z nich. A já jsem jen napůl žertem šel hledat obrázek něčeho, co mělo kostru zevnitř a kůži zvenčí, ale Lego blok byl pravděpodobně nejméně strašidelný. V mnoha ohledech si však tímto způsobem představuji a mentálně představuji výzvu, které někdy čelíme analytickým platformám a databázím, které je podporují. A to je to, že opravdu jako spotřebitel a konečný uživatel nebo dokonce vývojář často vidíte vrstvu kůže dýhy, ale ve skutečnosti je to kostra pod ní - je to opravdu problém, na který se musíte soustředit.
Víte, v tomto případě, když přemýšlíme o věcech, které mohou mít vliv na výkon databáze a analytiku vyplývající z tohoto konkrétního dne, o výkonech, základní infrastruktuře a jen o sledování této základní infrastruktury, a jak jsem naznačil před chvílí, kolem disk a paměť a procesor. A jak zdůraznil Dr. Robin Bloor, výzvy ve virtualizaci a problémy, které se dějí v samotných čipech, a výkon až na úroveň jádra a množství paměti, která je nyní vložena do každého čipu v každém jádru. To jsou velmi technické výzvy, které je třeba hledat pro běžného člověka.
Vedení sledování dotazů. Víte, jednou z výzev kolem sledování dotazů a front dotazů je například - mám na mysli, SQL jako jazyk a databázové nástroje, které přicházejí kolem analytických nástrojů, jsou velmi silné, a zejména SQL jako jazyk. Ale s touto silou a jednoduchostí také přichází v mnoha případech a to je, že pokud se nejedná o aplikaci, která opakuje to samé znovu a znovu, napsaná dobrým vývojářem a spatřená dobrým DBA, mohla by být lidmi, kteří dělají nestrukturované dotazy.
A problém s tím je, že je docela snadné se naučit trochu SQL a začít dělat dotazy, ale v důsledku toho nemusíte mít všechny dovednosti, zkušenosti a znalosti, abyste věděli, zda děláte dobrá nebo špatná věc k provedení databáze. Takže nepřetržitý provoz stejného velkého, širokého, špatného může budovu jen sundat. Zajištění sledování dotazů je zajímavou výzvou.
Sledujte pouze dobu odezvy, pokud jde o to, co platforma dělá a co uživatelé dostávají. Znovu víte, že bez správných nástrojů to není něco, na co se prostě intuitivně díváte a myslíte si: „Ach, síť běží pomalu, “ nebo „Uživatelská paměť nefunguje dobře“ nebo „Indexy fungují špatně “Nebo„ nadýmá. “
A pak, jak víte, jak se dostanete do bodu, kdy, jakmile se s tím setkáte, jak jej rozdělíte a oddělíte a vyřešíte celou výzvu špatně strukturovaných dotazů? A víte, je to ad hoc dotaz, že někdo běží ručně, nebo se jedná o analytický nástroj s front-endem dashboardu, který má špatný výkon, protože kladou otázky špatným způsobem, nebo je to jen opravdu, opravdu špatně napsaný kus kódu?
A pak to opakoval, řekl Eric v nastavení zpočátku, víš, prostě iterativně jde znovu a znovu a znovu a dolaďuje ty pracovní postupy. Víte, jaké pracovní postupy běží, jak běží, jak často běží, jaký kód běží proti nim, kde proti němu běží v procesoru a paměti, na disku a v síti? Jo, to je opravdu opravdová technická výzva.
A pak nirvana, kterou lidé v tomto světě hledají, zatímco se přesouvá od historické analýzy a ladění výkonu a upozorňování na vaše prostředí, což je skvělé vidět, protože byste mohli v budoucnu získat plán, pokud víte, proč se věci zpomalily včera ráno v devět hodin. Ale to vám teď nepomůže a nepomůže to vášmu plánu do budoucna.
Myslím si, že plánování kapacit a velikost a škálování a ladění, takže víte, myslím, že je tu trend, který nyní vidíme, kde je posun ve velmi velkých prostředích, kde lidé mají velké databázové platformy a široce rozšířené databázové prostředí, aby mohli jít od historického varování a plánování po prediktivní varování a plánování, kde chtějí vědět, co se právě teď děje, a být schopni plánovat to do budoucna. Nebo nám došel nedostatek paměti a v příští hodině nám dojde nedostatek paměti a co s tím můžeme dělat? Jaké kapacitní plánování můžeme udělat v reálném čase?
Promiňte. Dostane se k bodu, kde, jak víte, se celá výzva objevování těchto překážek dostane do cesty v podstatě tomu, čemu říkáme tekutinová analytika, a učinit z toho normu ve vaší organizaci. Jak vidíte, je to netriviální výzva pro, víš, každodenní velké, nemyté masy. A to je stále netriviální výzva i pro technicky zdatnější.
Víte, pokud je to těžké pro pouhé smrtelníky, jak to děláme věcí, která je možná? Protože víte, většina z nich jsou věci, které běžní uživatelé nedokážou vyřešit, a můžeme mít nějaké speciální databázové inženýry, vývojáře databází, vývojáře kódů, programátory, ale stále musí být schopni oddělit prostředí. Musí se oddělit, víte, problémy, jako jsou lidé, kteří opakovaně používají kód.
Víte, jedna z nejhorších věcí, které jsem v tomto prostoru viděl kolem požadavků na výkon analytických platforem ve velmi rozsáhlých implementacích infrastruktury databázového serveru, jsou lidé, kteří berou kus kódu, kus SQL nebo ukradenou proceduru, kterou neudělali. nenapíšou a nevědí, zda je to dobrý nebo špatný kus kódu, a prostě to znovu používají, protože jim to dává výsledek, jaký chtějí. Ukazuje se však, že to mohlo být jen něco, co bylo napsáno za chodu, aby se získal jeden nebo dva výstupy, například zpráva - někdo spěchal.
A tak lidé používají složitý kód, který nepsali, a jen ho plácli do vývoje aplikací, nevěděli, že ve skutečnosti trestají zadní konec. Dokonce i sledování toho výkonu zasáhlo a při pohledu na to, odkud dotazy přicházejí a vrtají se dolů, to, jak víte, to je každodenní výzva.
Základní věci týkající se chování, jako jsou předběžná data pro výkon, pokud je to možné. Věci, které vás pouze prožívají, vás poučují, jako je například odstraňování indexů, pokud se chystáte provádět hromadný import, a poté je znovu indexujete, takže indexy nebudou při stahování terabajtů dat udržovány. Víš, že bez vhodných nástrojů je to téměř nemožné vidět, protože nevíte, že se index zatěžuje.
Pravidelná optimalizace indexů je asi 101, ale co když víte, když provádíte hromadný import nebo víte, vytvořte tabulku dotazů, pokud někdo provede opravdu velký dotaz? Víte, to může být obrovský hit výkonu a znovu, pokud nechcete monitorovat, nemáte nástroje k tomu, abyste to viděli, že se takový druh prostě děje na pozadí a nevíte jak na to .
Omezení dotazů pouze na počet sloupců, které potřebujete - myslím, že to zní opravdu jednoduše, ale znovu, pokud to nevidíte, nevíte, že se to děje, a pak se to prostě stane na pozadí a bolí vás to, na vás.
Vědět, kdy a kde použít dočasné tabulky, hromadit velké vymazání a aktualizace. Opět platí, že všechny velmi jednoduché věci, ale bez toho, aby viditelnost, bez nástrojů k tomu, že jen sedí na pozadí a stále bolí vás a vy prostě házet více paměti nebo CPU v databázovém prostředí získat lepší analytické platformy výkon, když opravdu byste měli být schopni vrtat do detailů toho, co vás bolí a oslovit tuto konkrétní věc. A pak, víte, věci jako omezení cizího klíče a jak to zjistíte, jak vůbec víte, že je to problém?
To mě vede k závěru mého klíčového bodu, a to je, že víte, že každý den vidíme tyto problémy všude. A jak se databázová prostředí zvětšují, rozšiřují a rozšiřují a jak zde zdůraznil Dr. Robin Bloor, získáváme stále komplexnější environmentální modely s časy databáze.
A pak také potřeba integrace do některých velkých datových platforem, jako jsou Hadoop a Spark, které přicházejí, a stále více a více současně. Podle mého názoru nás nese hledání lepších způsobů a konkrétních nástrojů pro inteligentní provádění výkonu platformy v reálném čase a analytiky a diagnostiky. Protože pro konečné uživatele a skutečné dolary to stojí reálný čas a skutečné peníze a frustrace, pokud se nezačneme dostávat k nástrojům, které se do těchto věcí ponoří.
A s tím se chystám předat našim přátelům z IDERA, protože věřím, že mají dobrý příběh, aby mohli vyprávět, jak bychom mohli tento problém vyřešit.
Bullett Manale: Zní to dobře. Mockrát vám děkuji a já se do toho pustím. Mám tu také několik skluzavek a nechám mě jít dopředu a něco takového vychovávat. Některé z nich se chystáme rychle projít.
Jen proto, abych vám poskytl nějaké nahlédnutí, jsem ředitelem obchodního inženýrství zde v IDERA, a tak to, co děláme, je docela pravidelné rozhovory s DBA o bolestech a výzvách, které mají, v mnoha případech, specifické pro mnohé, sledování výkonu a podobné věci, samozřejmě. A od tohoto publika hodně slyšíme, a proto si myslím, že některé informace, které od nich dostávám, mohu pravidelně sdílet, což dává smysl. Několik z nich se chystám přeskočit, protože si nemyslím, že jsou pro konverzaci skuteční.
Víte, mám zde svůj vlastní seznam povinností DBA - vypadá to podobně jako Robinův seznam a myslím si, že je to docela konzistentní. Myslím, že když mluvíte se správcem databáze, je to vždy - víte, jsou v některých z těchto oblastí soustředěnější více než v jiných a není tam žádný rým nebo důvod, záleží to jen na prostředí.
Uslyšíte docela širší a širokou škálu věcí, které lidé chtějí dělat. A mnohokrát, lidé, kteří chtějí tyto věci, to ne- zeptají se na ně av některých případech začnete vrtat do toho, co opravdu žádají, a pak zjistíte, že opravdu hledám více. Opravdu chtějí více informací, než si původně myslí, že potřebují, a když začnete vrtat do nástroje, myslím, že právě zde můžete začít hovořit s daty.
A myslím si, že je to opravdu zajímavá fráze, a to dává velký smysl, pokud jde o schopnost říct, jo, no, pokud máte špatný dotaz, co je opravdu špatný dotaz? Je to dotaz, který spotřebovává spoustu čtení nebo zápisu nebo CPU? Mohl by to být ten, který běží hodně, mohl by to jeden, víte, to je, jak jste řekl, špatně napsané.
Pokud jde o to, jak to zjišťujeme, existuje několik způsobů, které uvidíte, pokud jde o náš produkt, produkt Diagnostický manažer, že ukážeme DBA, kterým se mohou v tomto směru zabývat. A je to opravdu flexibilní, a myslím si, že je to jedna z velkých věcí - musíte mít nástroj, který vám pomůže s těmito problémy s výkonem, je prostředí každého trochu jiné.
A bude tu spousta, víte, potřeb a možná i nejasných požadavků, pokud jde o monitorování, takže musíte mít něco, co je flexibilní a něco, co bude fungovat a být schopen přizpůsobit se prostředí, které snažíte se to zvládnout. Víte, a já mám spoustu těchto příkladů - nebudu procházet každou z nich, ale potřebujete něco, co můžete otáčet tam a zpět mezi jedním kusem dat a druhým, a tak trochu mluvit o tom, když se dostaneme do produktu trochu a ukázat vám, a pokud jde o to, jak to děláme.
Ale další věc, o které si myslím, že jde o jakýkoli dobrý analytický nástroj, je, víte, že jsou tu některé základní věci, které opravdu hledáte. Samozřejmě v první řadě nechcete, aby nástroj, který ve jménu výkonu způsobí své vlastní problémy s výkonem. Když říkám, že shromažďuji data bez nákladů, nemluvím o nákladech, jak víte, o peněžních nákladech, ale o nákladech z hlediska režijních nákladů a nákladech z hlediska množství zdrojů, které budu používat ve jménu představení. Určitě tam chcete něco, co vám pomůže.
Potřebujete něco, co bude schopno získat údaje, které hledáte, specifické pro problémy, kterým čelíte ve svém každodenním životě, a mohou existovat některé věci, které nepotřebujete a které nemusíte. “ Nechci, a nemá smysl shromažďovat tato data, pokud o nich nebudete nikdy informovat nebo nebudete mít nějaké potřeby kolem pokusu o správu těchto dat. Například pokud jde o metadata spojená s výkonem.
Víte, dobrým příkladem je, že nemusím být upozorněn, pokud je služba Distributed Transaction Coordinator v SQL vypnutá, pokud nechci, aby byla spuštěna na prvním místě. Takže mě nepoznávejte, neshromažďujte proti nim data - tyto informace nepotřebuji. Takže schopnost zapínat a vypínat tyto věci je opravdu důležitá.
Schopnost také, jakmile sbíráte data, mít k nim docela rychlý přístup - nemusíte, víte, spouštět a masírovat data, manipulovat s daty - být schopni to udělat rychle a efektivně. A poté, co budete mít data, je samozřejmě důležité porozumět jim.
Teď, to je místo, kde s naším - například s produktem Diagnostic Manager, který vám dnes trochu ukážu - vám ukážu tento produkt, víte, ráda bych vám řekla, že tento produkt bude nahradit a být DBA v krabici. Realita je taková, že vyžaduje určitou znalost toho, co vaše prostředí je a co se snažíte dosáhnout. Zjevně důležité je pochopit roli samotné DBA.
Nyní se snažíme vzdělávat pomocí pomoci a pomocí jiných metod. Ale budete to vždy chtít spojit s určitým typem zkušeností nebo s někým, kdo ví, co dělat, jakmile obdrží data. Klíčem je samozřejmě mít člověka, který může položit správné otázky k produktu a vést konverzaci s údaji. A pak je zřejmé, že jsou schopna dát data smysl.
Jakmile budu mít tyto informace, budu schopen je dostat ke správným lidem. Moji vývojáři, můj operační tým - ať už je to kdokoli, možná budu potřebovat integraci s jinými produkty, které budou mít háčky, abych to mohl udělat. To vše jsou skutečné důležité věci. A pak, samozřejmě, v neposlední řadě, pokud potřebuji vědět víc, být schopen to udělat. Ať už to znamená zapnout nějaké další, aby se shromažďovaly, nebo zda to znamená jít trochu hlouběji do dat. Doufáte, že s nástrojem, který bude, víte, pomáháte s výkonem, získáte všechny věci, které potřebujete, abyste mohli na tyto otázky odpovědět.
Jednu věc, kterou jsem tu nenavrhl, o které si myslím, že si asi stojí za zmínku, je, že potřebujete nástroj, který vám pomůže rozlišit, co je normální a co není normální. A myslím, že je to velký, protože, jak víte, existuje spousta výstražných produktů a věcí, které jsou tam venku, ale pokud dostanete výstrahu a výstraha je falešná výstraha, nedělá vám to nic dobrého ; je to více ztráta času a sníží se vaše efektivita více, než jim pomůže. Takže, víte, to jsou některé věci, které bych měl na paměti.
Když mluvím o produktu, na který všechny tyto věci navazuji v rámci sady produktů IDERA, myslím si, že to je produkt Diagnostic Manager, který má pravděpodobně hlavní druh vlastností v tom, o čem zde mluvíme z hlediska databáze. ladění a výkon a sledování a podobné věci.
Lidé hledají monitorování na úrovni podniku; chtějí mít přístup, být schopni na jedné obrazovce vědět, že věci fungují tak, jak by měly být. Nebo chtějí být schopni, samozřejmě, pokud existuje problém, zjistit, kde je problém, a pak být schopni vrtat se do něj. Opravdu velká část, myslím, co lidé hledají s těmito typy způsobů, kterými se můžete opravdu zdokonalit ve svém výkonu.
Druhou věcí, která s tím samozřejmě souvisí, je to, že nemůžu operovat jen v současnosti, a musím být schopen vrátit se zpět po určitém časovém období, ať už to znamená hledat dotazy, které běžely špatně, nebo zda to znamená ty vědět, jak se hostitelský VM choval z hlediska zdrojů. Všechny ty věci, které musíš dělat, a ty tam nebudeš sedět a dívat se na svou konzoli 24 hodin denně, 7 dní v týdnu.
Pokud jste na dovolené nebo pokud je uprostřed noci nebo cokoli, co potřebujete, potřebujete něco, co se s vámi bude moci vrátit v čase, abyste mohli říci, co se děje na příkladu v době, kdy jsme měli problém. A to, že to dokážu, znovu, efektivně a rychle a umí se do ní promítnout, je rozhodně důležitým prvkem této diskuse. A řekl bych, že je to pravděpodobně jedna z nejdůležitějších věcí, co lidé hledají. Neustále hledají toto okno do minulosti, protože to je opravdu im- Víte, nechcete tam sedět a čekat, až se něco stane znovu.
Další věc na seznamu je opravdu jen navázání na to, o čem jsme mluvili dříve, se samotným výkonem dotazu. A ukážu vám několik různých příkladů v produktu Diagnostic Manager, jak to děláme, což určitě na konci dne vám nabídne spoustu možností kolem samotných dotazů, pokud jde o to, co chcete se shromáždit.
Pokud jde o to, zda vás zajímají dotazy, které způsobují bolest prostředků, spotřebu procesoru nebo spotřebu I / O. Ať už se jedná o dotazy, které trvat dlouho, nebo dotazy, které prostě obecně nemusí být nejhorší, co se týče výkonu, ale mohou běžet tak často, že naprostá frekvence samotného běhu může být problém. Důležitou součástí je samozřejmě schopnost v průběhu času zaznamenat trendy s těmito dotazy.
Existuje mnoho různých způsobů, jak to dokážeme v tomto produktu udělat, a myslím si, že to je samozřejmě pro většinu DBA opravdu důležitý kus. A i když nemáte vlastní interně vyvinuté aplikace, je stále příjemné jít k dodavatelům softwaru a říct: „Hej, víš co? Víte, dvě hodiny odpoledne každý den, kdy se tato práce rozbíhá, “nebo cokoli, „ Je to vaše aplikace, která to způsobuje, a my jsme ji museli opravit. “Takže i když nemáte úplné kontrolu nad samotným kódem, je stále příjemné vědět, kdy se vyskytují problémy.
A pak, víte, druhá část je prostě proaktivnější. Umět být první, kdo to bude vědět, bude schopen pochopit, kdy se vyskytne problém. Chcete-li být nejen první, kdo to ví, můžete to napravit, ale v mnoha případech, kdy potřebujete, je něco, co dokáže automatizovat reakci, a to i v mnoha případech. Můžete říct, víte, raději než dostávat e-maily, které říkají: „Hej, musíte to opravit, “ pokud jsem na schůzce nebo pokud jsem, víte, na cestách nebo cokoli, co jsem Dělám, je evidentně velmi hezké říci, že mám něco na svém místě, které to dokáže řešit automatizovaným způsobem.
A pokud to není řešeno automatizovaným způsobem, musí být alespoň první, kdo to bude vědět, takže můžete podniknout nápravná opatření nebo kontaktovat někoho, kdo to dokáže. Takže to jsou zjevně velké důležité kousky, jak víte, k těmto typům problémů, s nimiž se můžete setkat, pokud jde o monitorování vašich strojů a vašich instancí a samotné analýzy.
Teď jsem o tom mluvil dříve, což je flexibilita věcí. Nemohu to dostatečně zdůraznit, protože mohu říci, víte, hned po vybalení, pokud existuje něco, co není monitorováno, schopnost mít v rámci produktu funkčnost, aby bylo možné tyto věci přidat do být sledován. A ve smyslu příkladu Diagnostic Manager máme samozřejmě, víte, čítače WMI, čítače, čítače SQL Server, můžete si vytvořit své vlastní dotazy.
Můžete dokonce, víte, pokud chcete, stahovat data ze svého prostředí vCenter nebo z prostředí Hyper-V jako výsledek dotazování, které se odehrává a že můžete, jak víte, dělat to pravidelně a tato data vytáhněte a zobrazte je. A opět se otočte z jednoho místa na druhé, když se díváte na tyto informace.
Takže to jsou ty věci, které, co vidím, lidé žádají, když mluví o nástroji, který jim pomůže, pokud jde o vyladění a výkon - produkt, který vám ukážu v druhý je Diagnostic Manager a podporuje vše od roku 2000 až do roku 2016. Je to specifické pro SQL Server, a proto tyto věci monitorujeme. Na instancích, které monitorují instanci, neexistují agenti.
To se vrací ke sběru informací s malými náklady, že, jak víte, zkusili jsme to zjevně více shromažďovat, nepoužívali jsme příliš mnoho zdrojů, že? Snažíme se využít věci, které nám SQL Server již poskytuje, a vylepšovat je, ať už se jedná o dynamické pohledy na správu, nebo zda se jedná o rozšířené události, nebo o jakýkoli případ, pokud jde o samotnou kolekci. Jedním z našich mandátů je být schopen tyto informace využít a zlepšit je.
Nyní, pokud se na to podíváte opravdu rychle, nebudu procházet architekturou příliš podrobně, ale budu mít úložiště typu back-end se všemi našimi historickými údaji, které můžete spravovat, a můžete je uchovávat tak dlouho, dokud ty chceš. Můžete si dokonce vybrat typ informací, které chcete uchovat, a na jak dlouho. K tomu jde trochu zpět, shromažďování příslušných údajů a zbytečná data jsou vynechána. Pokud chcete uchovat dotazy po dobu pěti dnů, které jsou klíčové, a pak si nechat vaše upozornění po dobu dvou let, je to na vás a je to zcela vaše výsada v tom, že to dokážete.
S tímto produktem je řada různých konzolí. Máte webovou verzi, máte také silnou verzi klienta. A tak je to flexibilita skákání v prohlížeči a sledování toho, co se děje, nebo pokud máte notebook, na kterém je nainstalován specializovaný klient, kterýkoli z těchto přístupů by pro vás pracoval.
Nyní bych chtěl udělat rychlou demonstraci. A rád bych zdůraznil - vracím se k tomuto dalšímu snímku zde - že máme, právě jsme přidali, stejně jako FYI pro lidi, kteří jsou s produktem obeznámeni, máme novou nabídku, která je Diagnostický manažer Pro. Profesionální nabídka, která zahrnuje to, čemu říkáme Analýza pracovního vytížení.
A opravdu je to o tom, že se můžeme interaktivně dívat na velmi dlouhá období a jít z toho, víte, 30denní pohled na, víte, pětiminutový pohled na přibližně tři kliknutí. A když vidíte špičku ve výkonu nebo problém v úzkém hrdle, které byste mohli být schopni, víte, měli byste být schopni vidět na velmi vysoké úrovni a vrtat se na velmi nízkou úroveň. A zejména to, že i dnes je to pro tento produkt nové.
Ale to, co chci udělat, je jen začátek a chci trochu mluvit o tom, jak se točí a jde sem a tam. A přinesl jsem příklad, a já se o to podělím na své obrazovce. A uvidíme … Tak jdeme. Moje obrazovka. A dejte mi vědět, lidi, že to můžete vidět.
Eric Kavanagh: Tady máš.
Bullett Manale: Všechno je v pořádku? V pořádku. Takže to, na co se právě teď díváte - a to je produkt Diagnostic Manager - a já jsem vám chtěl jen poskytnout ukázku toho, co se tady děje. V tomto konkrétním příkladu vám ukážeme dotazy spojené s čekáním. A tak když mluvím o schopnosti jít tam a zpět, vrtat hlouběji a otáčet se, to je - tento pohled je toho dobrým příkladem. Můžu jít z pohledu časové osy, jak tu vidíme, která se nyní zobrazí. V našem případě se díváme na samotné čekání a jejich kategorie. Můžeme vidět prohlášení, která jsou vázána na tyto čekání, můžeme vidět aplikace.
Všimněte si, že se jedná o zobrazení časové osy, takže mohu identifikovat tyto informace lineárně na základě toho, kdy se problém vyskytl, ale pak znovu, pokud chci jen znovu, otočit se a řeknu: „Víš co, pojďme se podívat na to z jiného úhlu pohledu, “pojďme se na to podívat z pohledu:„ Chci vidět dotazy nebo čekání nebo aplikace, které mi způsobují největší bolest, a řadit je. “A to je to, uvidíme podle „dotaz čeká podle délky trvání.“ Nyní vidíme aplikace samotné, které mi způsobují největší bolest, nebo čeká.
A tady je část, která je opravdu nejdůležitější, je schopna tyto věci izolovat. Vidím, že tato aplikace NoSQL začíná zde. Způsobuje mi to dobré množství čekací doby, a to do 25 sekundových množství čekací doby v tomto 30minutovém okně, do kterého jsme vyvrtáni. A pak mohu tuto aplikaci izolovat a vidím prohlášení, v tomto případě, která se přímo týkají této konkrétní instance.
A to je jen jeden příklad toho, jak byste mohli identifikovat úzký profil, být schopni klasifikovat informace, být schopni upřednostnit problémy, které je třeba nejprve vyřešit. To jsou všechny věci, které musíte zvážit. Víte, můžete opravit problémy po celý den, ale pokud řešíte problémy, které jsou na konci seznamu, které chcete opravit, ztrácíte čas. S tím máte spojené náklady na příležitost.
Dám vám další příklad, a to je trochu jiný příklad. Spíše než konkrétně poukazovat na problém nebo poukazovat na oblast, potřebujete také nástroj, který vám bude schopen pomoci v širším slova smyslu, abyste mohli říci: „Hej, měli jsme nějaké problémy?“ Nebo „Jsou nějaké problémy?“ Nebo „Jsou nějaké problémy?“ existují věci, které mohu udělat pro zlepšení výkonu? “a mít něco za zákulisím a sledovat, co se děje. A v tomto případě to může souviset s konfigurací; to může souviset s, jak víte, způsobem, kterým je spravováno zdraví samotné instance. A samozřejmě také výkon.
Pokud sem přejdu na toto tlačítko Analyzovat, ukážu vám, že v rámci tohoto produktu máme také proaktivní výpis věcí, které lze provádět v hodnoceném formátu, což vám v zásadě poskytne informace ve věcech, které vám pravděpodobně v této instanci zvýší výkon nebo zvýší jejich zdravotní stav. A je to v hodnoceném formátu v tom smyslu, že máte schopnost vidět, které z nich pravděpodobněji zlepší váš výkon specifický pro konkrétní typ problému, který byl identifikován.
A tak, když se podívám na tyto věci a identifikuji je, nejen vidím, že mám problém, a také mám v mnoha případech skript, který lze automaticky sestavit, aby tento problém vyřešil. Ale v mnoha z těchto případů máme také externí odkazy, které budou odkazovat na typ problému, se kterým se setkáváme, a proč také dáváme toto doporučení, takže získáte tento vzdělávací aspekt věcí. Což, opět, myslím, že je velmi důležité, když mluvíte, víte, řešení problémů.
Nechci jen slepě dodržovat tato doporučení, chci pochopit, proč jsou tato doporučení vytvářena. A já bych mohl být senior DBA, který to dělá už 30 let a potřebuji něco, co to bude, víš, zkontroluj - nebo tečkuji i a v tomto případě překročím t - nebo možná jsem junior DBA a Potřebuji trochu pomoci, pokud jde o porozumění těmto problémům, když se dějí, a proč jsou tato doporučení vydávána.
Jak jsem řekl, jen vás provedu několika různými částmi produktu. Tento nástroj existuje, víte, existuje zhruba od roku 2004, 2003. A má do něj opravdu spoustu vývoje, spoustu informací, takže by nemělo smysl zkoušet vám zde vše ukázat. Ale myslím si, že jednou z věcí, která stojí za zmínku, je to, že když jdeme dovnitř a začneme mluvit o všech věcech, které můžete sledovat, a o všech věcech, na které můžete upozornit, znovu se vracet k této flexibilitě věcí, zde je seznam všech položek, které sledujeme.
Teď to nutně neznamená, že chci považovat tyto věci ve výstražném stavu, pokud se dostanou z prasknutí co do prahu, takže je můžete zapnout a vypnout. To se vrací k tomu: „Hej, musím udělat určité věci pouze s určitými metrikami. Potřebuji jen, víš, na určité problémy. “A být schopen se ujistit, že nebudeme, víte, saturovat vás spoustou falešných pozitiv. Nejen, že máte schopnost tyto věci zapínat a vypínat, ale v mnoha případech si všimnete, že poskytujeme také pásmo normality, které se vztahuje ke každé metrice. Takže pokud se dívám na tento konkrétní, v tomto případě na základní linii, všiml bych si, že prahová hodnota je pravděpodobně vyšší tam, kde jsou právě teď.
Na druhé straně mince je, co když mám instanci SQL, kde sleduji některé metriky a tyto metriky, z jakéhokoli důvodu jsou prahové hodnoty, které jsem nastavil, nesprávné? Jinými slovy, prahy jsou plácnutí uprostřed místa, kde základní linie skutečně sedí, což znamená, že pokud budu mít na tuto prahovou hodnotu vázanou výstrahu, pravděpodobně dostanu výstrahu na něco, co je normální událostí. A tak v takových situacích vám můžeme poskytnout tento přehled i plošně.
U všech metrik v tomto konkrétním případě vidím ty prahy, u nichž je pravděpodobné, že se zde projeví falešně pozitivní, pokud jde o to, co je normální a co ne. Bude to něco, co by se na paměťové straně považovalo spíše za běžnou věc, a pokud bych chtěl zvýšit tuto prahovou hodnotu, mohl bych, ale je to druh myšlenky se základními liniemi.
A skvělou věcí, která se týká produktu Diagnostic Manager, pokud jde o samotné základní linie, je schopnost nastavit více základních linií. A můžete se zeptat: „Proč bych to chtěl udělat?“ A odpověď zní, dobře, pokud máte okno údržby, které běží od, řekněme, od půlnoci do 4:00, kde skutečně zdaňujete své zdroje, opravdu využívám zdroje co nejvíce, pak chcete být schopni opět se posunout a chcete se trochu otáčet a říkat: „Podívejte, za tím změníme naše prahy.“ A my můžeme skutečně dynamicky přizpůsobit naše prahové hodnoty podle toho, v jakém výchozím stavu se nacházíme, na základě denní doby nebo dne v týdnu atd., Že je. Takže pro nás tyto prahy dynamicky upraví.
Udělejme krok znovu. Jakmile jsme tyto prahové hodnoty určili, jakmile jsme prošli, a pokud jde o nastavování výstrah a oznámení a obeznámení se s těmito situacemi, které by se mohly stát, opět zde je prvořadá flexibilita. Chcete být schopni varovat v konkrétních situacích. V jiných situacích můžete chtít poslat e-mail někomu jinému, možná budete chtít spustit skript PowerShell, možná, víte, seznam pokračuje.
Možná bych se chtěl integrovat s něčím přes SNMP trap nebo dokonce přímo s, například, SCOM. Jde o to, že to máte flexibilitu a můžete nastavit všechny typy podmínek, které by to zaručovaly, ať už jde o velmi široký dosah - víte, můj procesor a paměť nebo cokoli zdroje - ve všech mých případech, nebo možná mám velmi specifický typ věcí, které chci sledovat, protože když zjistím, že porušujeme, chci v tomto problému spustit velmi specifický a směrovaný skript. Tady byste tedy mohli dělat takové věci uvnitř produktu Diagnostic Manager, jen víte, co se týče upozornění a oznámení, a být z tohoto hlediska flexibilní.
Teď nebudu procházet všemi výstrahami a všemi dobrými věcmi. Chtěl jsem mluvit o zprávách. A opět, schopnost získávat informace a využívat tato data mnoha různými způsoby - a to se vrací zpět ke konverzaci s vašimi daty. A spousta lidí, když poprvé uvidí tento produkt, si myslí: „Ach, dobře, budu mít nástroj, který mě upozorní, když budou problémy. To je to, co potřebuji. “A realita je, že potřebují tento nástroj, ale na druhé straně je, pokud opravdu - potřebují také nástroj, který jim pomůže při rozhodování, a mohou využít tyto informace, že jsme shromažďování ve jménu představení a také ve jménu výstrahy, aby vám pomohlo při rozhodování po silnici vpřed.
Víš, dobrým příkladem by byly moje prognózy růstu v mé databázi. Pokud mám konkrétní databázi, která roste, budu schopna ukázat na tuto databázi nebo dokonce na více databází, abych mohla vidět, jaké jsou míry růstu. Neukazujeme vás na základě toho, co víte, co to je dnes; předpovídá to na základě minulého růstu, který jsme zažili.
Pokud tu mám několik databází, které mám náhodou, představte si, že bych mohl jít dovnitř a říci: „Pojďme vzít poslední, znáte, roční hodnotu dat, korelovejte to podle měsíce a ve vzorku rychlost měsíce, pojďme se podívat a uvidíme, jak velký růst uvidíme v příštích třech letech, nebo 36 jednotkách. “V tom případě můžeme na tuto otázku velmi rychle odpovědět. Zkuste to udělat sami, že? Zkuste to udělat za tolik času, jako jsem to udělal sám. Chvíli vás to zabere.
Nyní ještě více zdůrazňuji, že si vezmeme další zprávu, což je zpráva o mých nejlepších serverech. Představte si, že mám sto produkčních instancí, což v tomto případě nemám. Pokud ale někdo přijde ke mně a řekne: „Potřebuju, abys mi to řekl - chystáme dát tuto novou databázi tam pro tuto skvělou novou aplikaci; všechno to změní, jak to víme; život to učiní tak úžasným. Ach, mimochodem, samotná databáze bude opravdu náročná na V / V, nebo to bude náročná na CPU, nebo opravdu náročná na paměť …, “bez ohledu na to, jak je to výplň, chci abych viděl ze všech svých produkčních instancí, kde má smysl dát tuto databázi smysl? A mohu všechny své instance postavit proti sobě, pokud jde o typ kontingentu, ať už jde o procesor, paměť, disk nebo o jakýkoli případ. A proto je zde možné rychle a efektivně odpovědět na tuto otázku a udělat správná rozhodnutí, nikoli hádat, kdy to děláte - to vše je evidentně skutečně důležité a potřebujete něco, co vám pomůže.
A když mluvíme o analytice, může sahat od všeho, o čem mluvíme, s plánováním kapacity, až po varování, do kterých běžíte každý den, které by se mohly zabývat CPU, protože a samozřejmě i samotné dotazy, zda blokují atd. a tak dále.
Dalším příkladem by bylo, kdybych šel sem do administrativní sekce - vlastně si to vezmu zpět, výstražnou sekci sem - a požádám depozitáře našich historických informací o to, co se stalo v minulosti. Měl jsem blokování, ke kterému došlo v mém produkčním prostředí? Nevím, pojďme to zjistit.
Mohu se vrátit ke své produkční značce a mohu říci pro všechny své produkční instance, vzhledem k jakémukoli časovému období, pro jakoukoli metriku, kterou chci identifikovat. Pokud jsem se dostal do výstražného stavu, v našem případě řekněme blokování podle počtu, nikoli sekund blokování, a mohu se vrátit a v tomto případě o několik měsíců, pokud to budu potřebovat - nebo v tomto případ, jeden měsíc - a vidím, že blokování. Vidím, kdy to začalo, vidím, kdy to skončilo, a pokud to potřebuji, mohu si prohloubit některé z těchto intervalů tahu, abych viděl specifika blokovacího incidentu sama o sobě. Musíte být schopni mít něco, co je velmi rychlé, být schopni najít to, co potřebujete a hledat, spíše než točit spoustou cyklů, abyste to dokázali. A tak si myslím, že je to také důležité.
Poslední věc, kterou vám chci ukázat - a ukázat vám tento produkt, produkt Diagnostic Manager - je, že jsme, jak jsem již zmínil, šli jsme dovnitř a do našeho nástroje SQL Diagnostic Manager jsme přidali další komponentu. Pro nabídka. A to je součást Workload Analysis. A toto je jeho webová verze, v tomto případě vám tu ukážeme. Jde ale o to, že vám to umožňuje nahlédnout do opravdu širokého časového období nebo do velmi specifického časového okna, a od, víte, pár kliknutí může vidět kód přímo související s problémy, které by se mohly stát .
Jako příklad toho, když se dívám na čtyřtýdenní pohled, zde vidím, právě zde, všechny výkyvy, pokud jde o databáze a výkon těchto databází a kde jsme v těchto databázích viděli čekací aktivitu. Nyní a jak vidíte, vidím zde bodec, výhodou tohoto nástroje je právě to, že tam může zvýraznit ten malý pruh. A pak, když to udělám, všechno se tady změní. Byli bychom schopni vidět databáze, mohli bychom vidět všechny příkazy vázané na to, co je za touto lištou.
Totéž, když jsem řekl: „Pojďme se podívat na poslední čtyři hodiny, “ namísto posledních čtyř týdnů. Stále to dokážu. Stále mohu zdůraznit, že časové období, a pak odtamtud - tady je znovu, tady jsou moje pivotní body - na všechny tyto věci, na které se mohu připojit. Nejlepší SQL příkazy, vidím ty dotazy, v tomto případě, které způsobovaly čekání, které souvisely se spotřebou CPU. Pouhým vrtáním vidím ty dotazy, které s nimi souvisejí - whoops - a také také programy a co s tím spojené.
Získáte zde spoustu informací a nejen to, ale uvidíte, jakmile se dostanete na úroveň příkazů, vám to řekne věci. Říká vám, zda vidí těžké operátory, pak si můžete prohlédnout plány provádění. Trvá to trochu času, protože načítání tohoto záznamu je dost rozsáhlé. Jde ale o to, že máte mnoho různých způsobů, jak si prohlížet data, vidět, co hledáte, a pak zřejmě budete moci odtud jednat, jak potřebujete, a tento podniká déle, než obvykle, takže to nechám.
A tak s tím řekl, budu to předávat zpět. A snad to byla dobrá ukázka toho, o čem jsme mluvili. A jak jsem řekl, samotný produkt, který jsme používali k tomu, abychom poskytli tyto příklady, byl již poměrně dlouho, a tak se o něm můžeme bavit a ukázat mnoho dalších věcí, ale pokud je to něco, o co se zajímáme z vás můžete vždy jít na náš web a stáhnout ho a hrát si s ním.
Eric Kavanagh: A já jsem rád, že ukážete všechny tyto detaily. Pokud se vrátíte o několik obrazovek - i tato obrazovka je docela dobrá. Protože existuje tolik různých způsobů, jak si představit, co se ve skutečnosti děje, a já si myslím, že je to jeden z méně podceňovaných aspektů práce s počítači v těchto dnech. Je to určitě databázové prostředí, které v mnoha ohledech mám tuto polovinu vtipu, který říkám: „Stále se učíme mluvit křemíkem.“ Stále se učíme rozumět tomu, jak vidět, co se děje, a vašemu bodu, který bylo velmi dobře přijato, musíte mít konverzaci s daty, abyste lépe porozuměli tomu, co se děje, proč se věci dějí pomalu, protože existuje tolik možných problémů. A samozřejmě, IDERA má řadu různých produktů, z nichž jeden jsou staré přesné výrobky, o kterých si myslím, že by k tomu mohly být doplňkové.
Ale možná, Robine, hodím ti to na pár otázek, a pak Dez, pár otázek od tebe, a pak možná někdo z publika, nebuď stydlivý. Pošlete je hned.
Bullett Manale: Robine, jsi na němý?
Robin Bloor: Ano. Je to v pořádku, jen se ztlumím. Musím říct, že je to neuvěřitelně - věc, která mě ve skutečnosti udeřila jako nejdramatičtější o tomto nástroji, protože je to opravdu - zejména vzhledem k tomu, že je zcela zřejmé, že celá řada dimenzí, do kterých jste prostě nešli - věc, která ve skutečnosti Myslím, že na to bylo nejpůsobivější to, že to musí být opravdu, opravdu dobrý způsob, jak trénovat DBA. Víte, je to - takže když se poprvé pustíte do práce s databází a vlastně nevíte mnoho o tom, co se v databázi skutečně děje, je vlastně opravdu těžké pochopit. Používá se to hodně, konkrétně pro výcvik? Použil bych to.
Bullett Manale: Jo. Myslím tím, že když říkáš trénink, máš na mysli něco jako probíhající trénink jako něco jako DBA, že? Z hlediska…
Robin Bloor: Ano, ano, ano, jo. Učební nástroj. Víte,
Bullett Manale: Jo, myslím si, že to tak je, a ještě více, takže jsme přidali tuto komponentu Analyzovat, kterou jsme vám ukázali dříve, která obsahuje všechna doporučení, která s tím souvisí. Ale myslím, že určitě najdete, v rámci pomoci a mnoha různých oblastech v rámci produktu, to vám poskytne, víte, hodně nahlédnutí. Mnoho informací.
A realita je, jak jsem řekl, můžete použít, pokud nejste DBA. Pravděpodobně zjistíte, že děláte některá vyhledávání Google a podobné věci, pouze k obecným znalostem toho, co většina databází DBA má, ale můžete to korelovat a určitě vám to pomůže, pokud jde o: „Hej, víš, hej, co je tato věc se nazývá fragmentace? “nebo„ Proč je tento dotaz spuštěn 6 000krát? “Myslím tím, protože tyto věci budou vyvedeny k vám a oni se vynoří, a uvidíte je. Uvidíte, že jste, víte, co je normální a co ne. Uvidíte věci, které jsou ostré a věci, které nejsou.
Zpravidla se snažíme nastavit tuto věc jako z hlediska osvědčených postupů. Takže, když to ukážete na instanci, ukáže vám věci, které jsou identifikovány jako mimo doporučené postupy. Myslím, samozřejmě, víte, že realita je taková, že osvědčené postupy jsou osvědčenými postupy a ne vždy to jsou skutečné postupy. Ale víte, to vám ukáže odlehlé hodnoty, a to i od počátečního bodu, kdy je nainstalujete a přejdete na instanci.
A odtamtud se můžete pohybovat tak, jak potřebujete, abyste problémy vyřešili a zjistili, zda se jedná o problém nebo o něco, co se běžně děje každý den. A pak, protože máte spoustu informací a doporučení, ano, absolutně.
Robin Bloor: Dobře. A další otázka - ale jsem si jist, že odpověď na tuto otázku je velmi rychlá - je, že máte granularitu jít přímo dolů k jednotlivým dotazům a jednotlivým bodům v čase a podívat se z této dimenze, .
Bullett Manale: Jasně, ano. V závislosti na tom, co chcete dělat, se můžete podívat na jednominutové okno času, nebo se můžete podívat na třídenní časové okno nebo, jak víte, třítýdenní časové období. A víte, jak jsem řekl, záleží na tom, jak se chcete podívat na data, a také na tom, co chcete shromažďovat. V některých případech shromažďujeme pouze dotazy, které dosahují prahu, který jste identifikovali. V jiných případech bychom mohli shromáždit, každý dotaz, který způsobí čekání.
Ale také máte schopnost říci: „Podívejte, ty prahy, které jsem identifikoval, možná je to jen pro čtení, nebo možná je to jen pro čtení, nebo možná je to jen pro CPU.“ Takže za předpokladu, že to překonalo ten práh, pak to je na co chcete sbírat. Poté, bez ohledu na časový rámec, na který se chcete podívat, byste mohli vidět ty dotazy, které jsou urážlivé, na základě toho, co považujete za urážlivé.
Existuje mnoho různých způsobů, jak se podívat na data. Můžete se na to dívat v konsolidovaném pohledu, abyste viděli, víte, jaké dotazy - kolik dotazů za scénami vyrazilo, versus, víte, každý jednotlivý incident tohoto dotazu se rozběhl, abyste sledovali vzorec, pokud bude, jestli se to neustále zhoršuje.
Ale na odpověď na svou otázku můžete určitě poukázat na kdykoli chcete. Tuto věc jste nazvali Prohlížeč historie - a já jsem ji trochu používal - ale v podstatě bez ohledu na zvolený okamžik, bez ohledu na den v kalendáři, který vyberete, můžete přejít přímo k tomuto okamžiku.
Právě teď se dívám 15. listopadu v 19:05 a můžeme se podívat na dotazy specifické pro tuto dobu. Kdybych měl nějaké, které běhaly špatně vzhledem k tomu oknu času, mohli bychom se podívat na podrobnosti relace specifické pro toto časové okno a zjistit, jaké relace probíhají. Myslím, že je tu celá řada dat, a jak jsem řekl, nejtěžší částí je opravdu asi 30 minut hraní s konzolí a vymýšlení, jak to udělat.
Jakmile ale zjistíte, že většina dat je v tomto pásu karet a je rozdělena těmito kartami, a každá karta má svou vlastní sadu dynamicky se měnících tlačítek, která se objeví pokaždé, když na ni kliknete, a pak, zda se díváte na skutečné čas nebo věci, které se staly minulý týden, je to stejný proces. V zásadě se dívám právě teď 15. listopadu, ale stejně snadno se mohu podívat do reálného času pouhým kliknutím na toto tlačítko. A budu komunikovat s daty stejným způsobem.
Ale abych odpověděl na vaši otázku, ano, existuje mnoho různých způsobů, jak zobrazit historické informace, a to se také týká samotných dotazů.
Robin Bloor: Vidím. Je to velmi působivé. A mám ráda skutečnost, že okna se synchronizují, i když se to v dnešní době docela podobá všemu, co se týká dat v reálném čase.
Bullett Manale: Jo. Tak určitě.
Robin Bloor: Zde je jen informativní bod, na který vlastně neznám odpověď. Podle vašich nabídek - SQL Server a cloud - můžete na cloud ukazovat v části Ratio?
Bullett Manale: Můžeš. Můžete to namířit pod cloud. Když skutečně přidáte instance, zeptá se vás, zda je to RDS nebo Azure. Nyní budou existovat určitá omezení založená na tom, co je nám vystaveno z cloudu, takže může existovat - existuje trochu rozdíl v tom, co můžeme sledovat, jednoduše proto, že instrumentace, v některých případech, není Můžeme se shromáždit na základě toho, co Microsoft vystavuje.
Teď, pokud je to něco jako, víte, infrastruktura jako platforma, jako, víte, nebo EC2 nebo něco takového, to vůbec není problém. Dostáváme všechno. A když pracujeme se společností Microsoft a pracujeme s Amazonem; pracujeme na podrobnějším odhalení těchto informací. Ale absolutně ano, podporujeme tato prostředí.
Robin Bloor: Dobře, to je zajímavé. Dobře, podám Dezovi, který vám bude jistě hodit otázky z jiného směru.
Bullett Manale: Dobře.
Dez Blanchfield: Děkuji. Mám pro vás dvě velmi rychlé. Myslím, že víte, první je, stupnice, víte, myslím, že jedna z věcí, která mě zasahuje, je to, že obecné téma představení má tendenci být něčím, o čem přemýšlíme, když dostaneme velmi velký, velmi velký, velmi rozsáhlé a široké a terabajty dat. Při sledování dema mě to zasáhlo, protože to je něco, co se vlastně týká i velmi malých prostředí, jakési jen získání výkonu.
Jaký druh šíření vidíte při přijímání tohoto, a myslíte si, že je to, víte, myslíte si, že je to nástroj, který má dobrý, víte - podle mého názoru ano, takže si myslím, že je to ano - ale já jen chci vidět, co vidíš. Menší organizace vedou stejné rozhovory a hledají nástroj, jak toho dosáhnout, nebo je to opravdu něco na větším konci města?
Bullett Manale: Je to vtipné - to je dobrá otázka. Je to trochu mix, ale řekl bych, že máme spoustu malých zákazníků. A když říkám malým zákazníkům, myslím, víte, nákupy jednoho až pěti instancí za účelem licence ke správě. Nyní, v některých případech, mohou mít 30 instancí, správně, SQL, a oni se opravdu zajímají pouze o těch pět opravdu, opravdu dost důležitě, aby investovali do nástroje, jako je tento, pro těchto pět případů.
Realita je taková, že i v menších obchodech máte hrstku serverů SQL. Ve většině případů nebo v mnoha případech je tento malý obchod velmi závislý na těchto databázích, protože víte, co dělají. A tak to nemohou, nemohou to nechat jít dolů. Nemůžou, víte, musí mít nástroj.
Druhou stranou této mince je, že v některých z těchto menších obchodů nemají vyhrazené DBA, takže ten chlap, který je nejchytřejší v místnosti nebo techničtější chlap v místnosti, skončí jako přidělená DBA. V této situaci tedy určitě hledají pomoc a tento nástroj jim v tomto ohledu samozřejmě pomůže.
Pro vaše větší prostředí, jak si myslím, že to byl Dez, který to zmínil - nebo Robina, nejsem si jistý - ale víte, větší prostředí, budete překvapeni, kolik DBA mají, myslím, že mluvíme o velkém počtu instancí jazyka SQL a máte doslova hrst databází DBA, jejichž úkolem je za ně odpovídat. A tak z tohoto pohledu, ty kluci, víte, hledají nějakou pomoc, protože nemají zdroje opravdu dostačující na to, aby jim opravdu pomohli, a tak nějaký nástroj pomůže některé z nich vyrovnat.
A vidíme to docela dost dobře, kde, jak víte, máte tři lidi, kteří spravují 200 instancí. A tak si dokážete představit logistiku, že pokud nemáte takovýto nástroj, pokuste se přijít na to, i když je problém. Nebude to proaktivní způsob, mohu vás ujistit. Doufejme, že to odpoví na vaši otázku. To jo.
Dez Blanchfield: Ano, jo. Udeřilo mě to - a myslím si, že na to Robin něco zmiňoval -, ale víte, ten druh slibu, který popisujete, když jste dělali demo, myslím, že se nevylučují pouze ve velmi velkých prostředích. Víte, můžete si koupit běžnou platformu, která je navržena pro jednu věc, a vložit ji do databázového sdíleného prostředí pro něco jiného, a to jen potrestá celé prostředí.
Druhá věc, která mě zasáhla - není to ani tak otázka, ale jen pozorování, ale dovedu to k otázce - a to je, že, když organizace již investovaly do své infrastruktury a do svých platforma a jejich databáze a servery a infrastruktura kolem toho, a oni si budou kupovat produkt, ať už to bude cokoli - HR, ERP, nástroj BI - již tak trochu investovali.
Jakou odpověď vidíte, když konverzujete s lidmi a zjistili, že mají problém s výkonem, ale teď cítí, že musí udělat další investici, aby se k tomu dostali? Existuje místo, kde si uvědomí, jakmile si to ukážete, že se jedná o věc, která není lákavá, a není to ani tak prodejní hřiště, ale spíš epiphany. Je to prostě, víte, „Z toho okamžitě uvidíme prospěch.“ Na rozdíl od pouhého prodávání produktu? Zdá se mi, že se prodává sám a návratnost investic pouze přeskočí ze stránky.
Bullett Manale: Jo, a to je vtipné, že říkáte, že protože to, co se bude mnohokrát stane, je, že někdo přijde, jako DBA nebo dokonce obchodní zástupci, a řeknou: „Hej, tito kluci chtějí podívejte se na to, například, list ROI. “A spíše jako něco na papíře, které bychom jim poslali. A demo je vždy 10krát lepší, zejména pak bytí, můžete to udělat se samotnými DBA, protože -
Dez Blanchfield: Jo.
Bullett Manale: Jak jste řekl, produkt se prodává sám. Je opravdu těžké dát návratnost investic na kus papíru a říci: „Dobře, kolik kliknutí obvykle DBA obvykle, víš, klikne za hodinu?“, Protože se týká záloh, víš, nebo ať už jde o jakýkoli případ, víš? A snaží se to dát na kus papíru, je to opravdu těžké udělat. Ale když někoho dostanete a ukážete jim produkt, který vidí, je to přesně to, co jste řekl.
Lidé si to uvědomují. Protože jim to nejen pomáhá porozumět a lépe se rozhodovat, ale také jim pomáhá, aby nebyli zlí. Mohou být první, kdo to bude vědět; mohou problém opravit dříve, než se vůbec zjistí, že se vyskytl problém.
Druhou částí toho je, že víte, jako DBA, ať už je to, víte, skutečné nebo vnímání - a myslím si, že je to vnímání - vlastně máte problémy s výkonem. Jste chlap, který na vás ukazuje prstem, když výkon klesá, a realita je taková, že by to mohl být vývojář, který problém skutečně způsobuje.
Když mám nástroj, který dokáže říci: „Hej, tohle není můj problém, musím to vzít vývojáři a musí to napravit, “ nebo, jak víte, v tomto smyslu. Je to hezký způsob, jak mít ve svém arzenálu něco, abyste mohli říct: „Tady je skutečný problém.“ Víte?
Dez Blanchfield: Jo. Poslední pro vás, a to, co mě udeří, při pohledu na to, jak jsme prošli to bylo, že často, když přemýšlíme o otázkách výkonu, máme tendenci přinášet speciální dovednosti. Přicházejí s 20letými zkušenostmi, dívají se na to, a jaksi víte, klasický vtip toho chlapa, který vejde do strojírny a má malé kladivo a zasáhne stroj na správném místě a pak řekne "To je oprava 15 000 $" a lidé jdou: "Za to neplatíme, " víte, protože je to pět minut práce. A on říká: "No, že pět minut práce vyžadovala 15 let zkušeností a to vám ušetřilo miliony."
Zdá se mi, že víte, že existuje prostřední proces, kdy lidé projdou touto věcí a řeknou: „Dobře, přiveďte speciální dovednosti, vyřešte problém, zmizí.“ Ale to, co udělali, je právě na to nasadili Band-Aid, že? Na rozdíl od scénáře, kde, z toho, co zde vidím, kde, když to jde dovnitř, ano, možná řešili některé problémy s výkonem, o nichž si mysleli, že prožívají, ale zdá se mi, že právě tehdy, když to mám 24 / 7 druh, víte, sada očí sledujících prostředí v reálném čase.
Opravdu skončíte tím, že se vzdáte scénáře, kdy se ráno probudí DBA, protože jsou spuštěny zprávy. Je to tak - a možná je to rétorické -, ale je to tak, že lidé rychle přecházejí od investování do produktu, aby ho vyřešili konkrétním problémem, ale obecně se to stane součástí DNA?
Bullett Manale: Jo, a to se liší od místa k místu, ale myslím, mám několik lidí, kteří si tento produkt původně zakoupili, například v roce 2006, a byli ve třech různých zaměstnáních v různých společnostech a šli dovnitř a když jdou do další společnosti, propagují to jako něco, co mají, protože mají pracovní postup. A říkám tomu, nesnáším to nazývat, ale, jak víte, tento pracovní postup zahrnuje tento produkt a oni jsou na něj zvyklí každý den a pomáhá jim, a tak nechtějí naučit se něco nového.
Ale absolutně. Myslím tím, že většinu času lidi přimějeme ke stažení tohoto produktu, není to proto, že mají rozpočet a že jdou ven a říkají: „Hej, dobře, máme tento výkonnostní rozpočet, musíme udělat důkaz konceptu, a my musíme vstoupit a přijít na to, provést hodnocení a všechny ty věci. “Obvykle se děje to, že mají problém s instancí SQL a hledají nějakou pomoc opravit tento problém. Jdou a stáhnou náš nástroj, vyřeší problém a pak si uvědomí, že tento nástroj sám o sobě udělá víc, než jen vyřeší problém, který měl v té době, že by jim to vlastně pomohlo zlepšit celkový výkon. a zabránit dalším problémům, postupovat vpřed. A to je jisté. A tento nástroj můžete rozhodně nadále používat k neustálému vyladění prostředí, protože vždy uvidíte nejen to, co se stalo právě teď, ale co se stalo minulý týden, minulý měsíc, minulý rok, a porovnejte to s tím, co se stane zítra. Víš? Taková věc.
Dez Blanchfield: Jo.
Bullett Manale: Určitě.
Dez Blanchfield: Perfektní. Takže jsi zmínil, že jsi zmínil něco o - Jdu jen zabalit, než se vrátím Ericovi, abych ho zavřel. Jedna z věcí, které mě vždy zajímají, je, jak na to lidé mají ruce? Zmínili jste se o stažení. Co je to 30sekundové shrnutí toho, jak na to mají ruce, kopii, roztočení a hraní s ní, a to, co by mohli potřebovat, pokud jde o infrastrukturu, stačí, aby si vzali příklad.
Bullett Manale: Takže to bude, jdete na IDERA (idera) .com. IDERA.com je společnost, a pokud narazíte na tento web - a mohu vám to skutečně ukázat zde - nevím, jestli stále sdílím svou obrazovku, ale pokud přejdete na stránku Produkty, pak přejděte na Diagnostický Odkaz na správce, objeví se malé tlačítko Stáhnout a sestavení si můžete stáhnout až poté, co vyplníte své údaje. Požádají vás o 32- nebo 64-bitové sestavení a vy jste mimo závod, jak se říká.
Dez Blanchfield: A bude to běžet na notebooku, aby si s ním někdo mohl hrát, nebo ho musí někde načíst na server?
Bullett Manale: Ne, ne. Ve skutečnosti to, co jsem vám dnes ukázal, bylo všechno z mého notebooku. Nyní má můj laptop 32 koncertů a 8jádrový procesor, ale stále je to laptop. Ale nemusí nutně mít tolik zdrojů, aby odpověděl na vaši otázku. Samotné hodnocení je dobré po dobu 14 dnů, ale jste více než vítáni, abyste mu dali delší zkušební období. Pokud nám jen zavoláte, můžeme to pro vás rozšířit, pokud chcete.
Dez Blanchfield: Myslím, že by to mělo být něco, co by se mělo odnést, protože to určitě udělám. Myslím, že víte, z pohledu věcí, zdá se mi, že ne-přemýšlet stáhnout a hrát si s ním. Pravděpodobně jděte do jednoho ze svých prostředí a jen uvidíte, co vidíte, protože mám podezření, že - jako všechno, co jsem viděl na pozadí databáze za posledních 20+ let, což mi stárne - jakmile uvidíte, co je pod kapuce, to je úžasné, co si uvědomíte, že můžete opravit rychle a jen získat malé zisky ve výkonu.
Úžasné, díky za ukázku. Bylo to opravdu skvělé. Díky za celou tu dobu diskutovat o otázkách.
Bullett Manale: Jste vítáni. Děkuji za-
Dez Blanchfied: Ericu, vracím se ti zpátky.
Eric Kavanagh: Jo, máme opravdu dobrý dotaz od publika. Ve své prezentaci jste o tom hovořil a já jsem o tom vlastně tweetoval, protože to byla taková skvělá nabídka. Řekli jste, že nechcete používat nástroj ke sledování výkonu, který má negativní dopad na váš výkon.
Bullett Manale: Správně. To je správně. To je druh důležité součásti nástroje pro sledování výkonu, protože to nezpůsobuje problémy s výkonem. Naprosto správně.
Eric Kavanagh: Přesně. No, je to jako ty odvážné - je to jako antivirové programy, které mohou v systémech vyvolat zmatek. Myslím, že jsem použil řadu různých technologií pro vysílání, kde antivirový program začíná a zkrátí váš stream. Stávají se tedy věci, které neočekáváte, ale otázka se týká toho konkrétního komentáře, který jste uvedli. A jaké výkonové zásahy vidíte? Jsou to dvě procenta, je to pět procent, je to jedno procento? Máte nějaká čísla, která na nás můžete hodit?
Bullett Manale: No, myslím, že problém s touto otázkou je, že, víte, část diskuse, o které jsme mluvili dříve. Můžu vám dát - obvykle je to kolem jednoho až tří procent, abych odpověděl na vaši otázku. Ale je tu další vysvětlení, které si myslím, že by bylo třeba, což je, poskytujeme vám mnoho způsobů, jak můžete říct nástroji, co chcete sledovat, že? A tak to vrací zpět k tomu. Možná bych chtěl získat vzorek každého dotazu, který běží. Chci tedy mít nástroj, který je dostatečně flexibilní, aby to mohl zapnout, abych to viděl.
A tak část této flexibility zahrnuje, víte, náklady na to. Pokud potřebuji shromáždit více dat, protože chci ukázku každého dotazu, který běží v posledním, víte, 20 minut, můžu to zapnout a může to udělat. A tak, obecně řečeno, ano, jedno až tři procenta je to, co vidíme, pokud jde o režii. Ale to se bude lišit a většina z toho bude záviset na vašich věcech, které zapnete a vypnete, pokud jde o vaše prahové hodnoty, kolik dat chcete shromáždit, intervaly dotazování a vše podobné že.
Ve skutečnosti, pokud jdete na samotnou instanci, kterou spravujete, jedna z věcí, které uvidíte, je, že máme více intervalů dotazování, které můžete určit. A to jednoduše proto, že chceme, víte, nemusím kontrolovat každý - Pokud chci provést srdeční kontrolu na instanci, nemusím dotazovat CPU a všechno ostatní spolu s ním, pokud dělám to každých 20 sekund. Máte tedy více intervalů dotazování, které můžete zadat.
Jak jsem řekl, máte také monitorování dotazů, které můžete určit. A to lze provést pro každou instanci samostatně, takže se můžete opravdu zaměřit na tuto konkrétní instanci z hlediska toho, co chcete sledovat. Pro své statistiky čekání a sledování čekání mohu toto zapnout nebo vypnout. A můžu říct, aby zachytil všechno, vím, co chci zachytit a kdy to chci zachytit. Spousta toho také - Musíte vzít v úvahu to, co děláte, pokud jde o to, co říkáte nástroji, který má sledovat.
Ale obecně řečeno, to, co bych řekl, je, jak jsem řekl, asi jedno až tři procenta to, co vidíme. Tento nástroj prodáváme již dlouhou dobu - protože, jak jsem řekl, asi v roce 2003 nebo 2004 - a máme tisíce zákazníků, takže vás mohu ujistit, že víte, že nemáme - zkusíme naše nejlépe nezpůsobovat problémy s výkonem ve jménu výkonu.
Eric Kavanagh: Jo, to jsou opravdu dobré informace. Jen jsem si myslel, že to byl skvělý citát, protože, jak víte, znovu nechcete porazit účel toho, čeho se snažíte dosáhnout, že?
Bullett Manale: Přesně.
Eric Kavanagh: A já oceňuji také Robinovu otázku; to je opravdu vynikající platforma, která pomáhá DBA pochopit mnoho různých aspektů, dimenzí a vrstev toho, o čem mluvíme. A myslím si, že koncept konverzace s vašimi údaji je zde velmi vhodný, protože k vašemu bodu dříve to obvykle nezjistíte při prvním pokusu. Musíte strávit nějaký čas díváním se na data, díváním se na historická data a dělat tuto syntézu ve své mysli. A to je práce člověka, že? Úkolem profese, která tam sedí a vrací pravidelně teplo podniku, aby tuto práci provedl a udržel vlaky v provozu včas, že?
Bullett Manale: Rozhodně.
Eric Kavanagh: Lidi, tohle byla další fantastická událost. Pokud na jakoukoli otázku, kterou jste položili, nebyla zodpovězena, dejte mi vědět. Pošlete e-mail na adresu. Archivujeme všechny tyto události, takže vždy můžete přejít na InsideAnalysis.com a najít archiv, nebo jít na našeho partnera, Techopedia.com. Pokud se podíváte na pravou stranu své stránky, uvidíte Události a tam uvedená webová vysílání. Pokud kliknete na Další události, zobrazí se vám všechna webová vysílání, která zde uvádíme, minulá, současná i budoucí.
A s tím se vám rozloučíme. Do konce letošního roku máme dalších pět webcastů, lidi. Můžeme naplánovat ještě jednu. Ale jinak to bude do roku 2017. Ed cal je mimo. Dejte nám vědět a pokud máte někoho, kdo chce předvést svou technologii, pošlete e-mail na adresu.
Díky tomu se s vámi rozloučíme, lidi. Ještě jednou děkujeme za váš čas a pozornost, povíme vám příště. Opatruj se. Ahoj.
